One thing that continues to fascinate me is how after so many years I can still walk into IT organisations and see basic practices not being followed (e.g. Software Configuration Management or Continuous Integration or …). Shouldn’t we all know better?!? I recently came across some slides from the late 90s and early 2000s that pretty much read like something that comes from a DevOps conference today. So I wonder what is it that has prevented us from being better today and I think I found a feasible answer to my question.

For illustrative purposes I have used the Accenture DevOps maturity model, but feel free to use any other model here as the tendency would be similar. I believe that as an industry we used to be better than we are today (of course all generalisations are dangerous, including this one). While it is hard to find hard evidence for this, let me try to justify my perspective.

More than 10 years ago we had much more custom development to solve the big problems and most work was done onshore in collocated teams. The only way to be more productive and reduce cost was to have better engineering practices and leverage more automation, hence companies invested in this. We used to be on the mature end of consistent in many places. Then two trends caused us to regress as far as engineering practices are concerned:

• Offshoring – With the introduction and mastering of offshore delivery, the industry had an alternative to automation and good engineering practices as labour arbitrage was providing a quick fix to cost reduction. It was potentially cheaper to do something manually offshore than maintaining or introducing automation onshore. Of course this couldn’t last as the labour cost offshore increased steadily. Some organisations stayed the course of engineering practices and automation others lost maturity along the way. This trend is similar to the same trend in manufacturing where manual labor became so cheap that automation wasn’t a critical element to cost reduction anymore. Those companies who went offshore did not sufficiently focus on automation and good practices as it was harder to oversea this with across locations and cost reductions were easy to achieve.
• Packaged and proprietary Software – As we leveraged more and more packaged and proprietary software we relied on those vendors to provide the solution to our productivity challenges. This led over time to island solutions, which supported specific packages, but are not open enough to integrate into the IT ecosystem. How do you baseline an enterprise wide software package when configuration management is hidden in a package or worse still configuration is only possible through a graphical user interface with no access to the underlying source code/text files? The pre-packaged software was a quick fix to get functionality, but again the good engineering practices were lost out of sight. And many organisations make so many customisations that they should really treat the original “COTS” just like any other application with the same rigor. The other problem that packaged software introduced is that the people customising them are often considered or consider themselves not to be programmers (which means they don’t have to worry about those practices that the custom application developers use), a dangerous mistake in my view.

“Speed is the new currency of IT and businesses”

This was all well and good when cost as expressed by the cost of a day of labor was the main driver for optimisation in organisations. This paradigm has shifted and nowadays speed to market is driving incentives and behaviour. Organisations across the globe are trying to find ways to speed up their delivery processes without risking quality. But how do you now revert the trend that many organisations followed – your IT organisations is mainly outsourced and/or offshored, you have an application architecture that is a mix of packaged software, proprietary solutions and custom elements and you lack the engineering experience and skills to fix it.

This is where we need to acknowledge that DevOps is a journey that is different for every organisation. Of course there are the engineering driven organisations like Etsy, Amazon and Facebook that have engineers/IT people in their C-suite of executives who intuitively understand the importance of application architecture and good engineering. I believe they won’t ask you for a business case for what is ultimate an optimisation for speed and flexibility – they understand how important good IT is – at least I believe that to be the case. They will also consider which applications to introduce into their ecosystem and making sure that those are open products for which good engineering practices can be employed. In other organisations the adoption of DevOps practices needs to be supported by business cases that are often difficult to create (especially in the middle maturity levels where the pain is not at mission-critical levels and the full benefit of highest maturity is not yet in arms reach). Organisations that are on this journey with the majority of us in the industry need to acknowledge the sometimes intangible nature of improvements. Speed to market and other cycle time measures should be the guides for your journey.

“Everyone is on the DevOps journey, whether you know it or not”

The question whether “you are doing DevOps or not” is not valid in my view. We are all on the DevOps journey, it’s the journey of improving delivery of IT solutions. DevOps is a broad field and provides us with an ever growing toolkit of practices and tools. All of us IT Executives are on the search to improve our organisations and our delivery capabilities. What label we use for that doesn’t matter as long as we keep moving forward and keep experimenting. Is there a goal to this journey? No, I don’t think there is concrete goal, a state when we declare we are done. I think the best of us will keep pushing forward no matter how good we are getting at it and from what I have seen during my travels there is still plenty of road in front of me that I can see and I don’t need to worry about getting “there” anytime soon in any case. Join me on the journey and may our paths cross to share stories of our adventures on the road.

Note: This post was first published on DevOps.com.