Getting IT-development to deliver functionality in a reliable manner absolutely demands the efforts that are included in the concept of DevOps. The name practically means to automate as many manual steps as possible in the process of delivering code to the production environment. Out of many reasons why, these two are enough as incentive to get going:

  1. All manual steps (especially when performed in complex technical environments) are subject to error. This leads to frustration and disappointment.
  2. Manual handling takes time, and cost money. Automation happily works all night at no extra cost.

Working in this area means working with pain relief for both the development teams and the stakeholders, so a clear win-win!

Once the delivery of code to production works smoothly, another costly area starts calling for attention. If one compares the tools and support systems that aid the developer (programmer) with the tools that support the tester, there seems to be a world of difference. While the daily tasks of the developer is getting more and more automated and smooth, the day for a tester still focuses around manual administration tasks. Clearly, it is very easy for a developer to code very complex behaviour with almost no effort at all, and clearly, it is very hard for the tester to produce quality tests for those behaviours. Starting to address this imbalance, the term TestOps comes in handy. TestOps means automation just like DevOps, but with focus on testing. Particularly handling test data, test runs, and test environments in an automated and smooth way.

In my experience the winnings of working in this area is a little less obvious to stakeholders than the DevOps track. Somehow testing still is not always seen as an equally vital activity as the writing of code. However, it is! Actually, I would argue it is probably more important than the production code. Whether celebrated or not, TestOps will make it much easier (read cheaper) to produce and maintain relevant tests, which are needed for quality deliveries on the DevOps trail.

Once testing works smoothly, we have a machinery for delivering high quality digital services at good speed. In essence, we have optimized for making changes. Now it is the requirements that are starting to look like a bottleneck. In my previous experience, requirements were often treated a bit like sketchy ideas. As a way of getting the software engineers going. Once the engineers are on the ball, the requirements are de facto never revisited. The answer to the question "how would this condition be handled in production?" is most often sought after in the source code, and not in the requirements. The fact that requirements serve most of their value before development starts creates an imbalance. A gap emerges between what is needed and what is produced. In addition, more often than not, tests relate directly to a piece of code, rather than directly to a requirement. Typically, a unit test refers to a class and not to a requirement.

The mission to overcome this force one to expand scope from requirements on IT-solutions to how a business documents its values and processes. Regardless of whether there is an IT support or not. This is where the term BizOps emerges. BizOps, or Business operations, is about supporting decision-making. In my view, a business really needs to do two things well to survive and prosper:

  1. Discover if it needs to make a change
  2. Implement needed changes

This is my view of what BizOps is all about, and this is where I am at right now. Working with making the discovery and implementation parts of business operation as smooth as possible. For this to work we need to monitor operations, finances, strategic KPIs, the outside world, and the speed and quality with which we are moving forward. The last part particularly means having a clear view of what requirements we have, which are currently working in production, which are in the pipeline for implementation, and at what speed and quality we do all this.

From the IT-perspective, this means the requirements should be kept alive, as a vital part of the business, for the long run. We need a requirement traceability matrix or perhaps something better still, to know what is currently working or not, and how we are making progress. This essential piece of information is unfortunately rarely seen in the industry.

It is time we do something about that!

Martin Österberg, DevOps på HiQ

/Martin Österberg


Martin is a part of our team that is working with Information Technology that we label IT Systems, Application Management, and DevOps. If you are interested in our offerings in that area, for either to work with us or at us, read more about it here 🤙