IT Operations – the engine room of our organisations and seen as an unglamorous workplace area.

When we picture a software development lifecycle, we often picture it like this…

A business sponsor has an idea or identifies a Customer need, they ask the software development teams to build it and then it gets implemented into the production environment so that the business area can serve better experiences to our Customers.

In this picture, the operations teams are seen as being far away from the Customers and treated as a ‘back of house’ function.

But there is another way to look at this picture.

In this one, the only way that our Customers can receive any value is from the operational (production) version of our systems. The operations teams are much closer to our Customers as it is their role to ensure that the production version of the systems are resilient and stable.

If we use this second way of looking at the software delivery process, the needs of our Customers are pulling the delivery of value into the operational environment. In order for that value to get there, the teams from operations, development and the business sponsor areas all need to work together. This goes to the heart of what DevOps means to me.

For those of you who have spent some time doing operational roles, the following will be obvious – for others, if you get a chance to spend some time in the operations department, please do – it will provide many insights.

I once worked with a team where the developers and the operations people were co-located and we changed our development processes to consider the impacts to the operations team right from the start of design. We called it Minimal Operation Intervention and below are some examples of this principle.

• When we designed a batch process, instead of expecting the operations team to find out what was wrong and restart it manually, we would design in the ability for the batch process to detect common fault conditions and rollback/restart without operator intervention.
• There can be a temptation to save money and time during development by making some processes manual – this goes directly against the principle of minimal operational intervention. In my view, if our operations team members spend most of their time in the operations room just monitoring our systems and nothing else – that is good design built in.
• I’ve also heard of a case where development teams were doing the right thing by building alarms into their new features – but they never updated or retired pre-existing alarms. The operations team were left with a confusing array. We need to consider the experiences that we want our operators to have at the same time as we focus on the Customer experiences and value that we are delivering.

In summary, our operational/production environment is the only one that we can deliver value from – all other activities in the development process need to focus on making the production environment resilient and a seamless experience for our Customers, Users and Operators.

Thank you again to Torbjörn Gyllebring and Steve for the conversations inspiring this post – any quality or factual defects are all my own however.