For the last couple of years I’ve been struggling a bit with the idea of DevOps. At the root of it was my own lack of clarity about what it is. My question remained unanswered and it wasn’t for the want of trying.
I went to conferences, attended talks, read articles and met with people in our business. I gathered logically inconsistent lists of things that it was and wasn’t. In the end, I concluded that there isn’t a consensus, so I had to work out what DevOps means to me.
Well, I’m pretty sure it’s about development and operations being closer together! Not too many people will dispute that (he said confidently!). But I’m not sure it’s really helpful. The context can vary wildly and getting closer can look really different in different situations.
On one hand consider a five supplier global program of work lasting three years in a highly regulated industry and on the other think about a two team program delivering value for an autonomous product owner. Context matters.
I was at the Gartner conference in Barcelona last year and I listened to a presentation by Yve Morieux from Boston Consulting. He reminded me of a story I’d heard before. A car company had problems with high servicing costs (no focus on repairability). They compared two methods of resolving the problem:
- Put your money where your mouth is and create a bonus scheme to encourage higher repairability
- Tell the design team that once their vehicle moves into production, they will all move into the warranty department.
The bonus scheme was bolted onto the existing framework, percentages compounded together and in the end, a massive improvement in repairability generated a 0.6 percent increase in pay. People could legitimately choose to ignore it and they did.
By contrast, warranty department costs are massively driven by repairability and the prospect of picking up responsibility for a money pit was truly terrifying. To avoid the terror, small, but thoughtful changes now could create huge savings and they would soon be living in the land of milk and honey.
I’m not sure if the story is true, but in many ways, it doesn’t matter. The point is well made. End to end responsibility makes people care more. When we care more, we try to make things better and we do it much more effectively.
I’ve come to believe that caring about the end to end process is the most important ingredient for DevOps to work. And caring is important for the teams, the management and the client. As soon as smart people care, if they have the appropriate resources, they can collaborate and do all the things that are appropriate in their context. Of course they have to trust each other and believe that no one is trying to screw them over. Of course they have to be empowered and able to self organize. But they can learn any new concepts and choose the best ones to apply. If they care, they can review what they’ve done and check how well it works.
Management must take care to set the priorities correctly and ensure enough resources (people and cash in general) are allocated. Development teams have to care that their application is going live, and know it will need to be looked after and that it will serve real customers. They have to care that it will perform and if it falls over, they have to care about that and care about the people who will need to fix it and build instrumentation to help them. They need to care about the future teams that will add and remove features. Operations teams have to care about the development process, and all of the environments needed from dev through to disaster recovery. They have to care about the ease of initiation and migration through those environments to live. They have to care about all the stakeholders and be hungry to engage and act as one team to make everyone’s life better: customers, development teams and of course operations. All collaborating to break down the silos and get the job done in the best way.
In some contexts, the lines between dev and ops can be blurred to the point of removal. The same people can take responsibility for application development and the design, deployment, operation and support of the live environments. In other contexts, there still needs to be some separation with teams responsible for the live operation of a huge estate.
In my opinion the DevOps journey starts with smart, responsible people who care about all the stakeholders, are empowered and have the resources to make a difference. Everything else will follow.
Peter Brookes-Smith, group managing director, Objectivity.
Published under license from ITProPortal.com, a Net Communities Ltd Publication. All rights reserved.
Image Credit: alphaspirit / Shutterstock