An interesting remark I heard at a recent CIO gathering was “DevOps is the first genuinely strategic topic that IT suppliers have promoted in years”. This same CIO went on to suggest that cloud computing has been great to enable tactical optimisation of IT delivery, and big data potentially has its place in the marketing department, but neither could be considered a strategic enabler of IT transformation.
This view was met with general nods and murmurs of agreement from other CIOs around the table, although it was clear from subsequent conversations that experience of DevOps varied widely among the group.
Since this encounter (towards the end of last year), I have had the opportunity to speak with quite a few IT leaders and practitioners about DevOps, what it means to IT teams, and its significance in more of a business context. Something that has come through strongly from these conversations is that DevOps activity can unfold differently depending on who seizes the initiative early on.
In case you are still learning about DevOps yourself, which, by the way, would put you in the company of most of your peers, the basic idea is to streamline the software delivery process from design and build, right through to deployment and operation. As part of this, you explicitly address the traditionally cumbersome and inefficient hand-offs and interactions that take place between development and operations teams (hence the name).
The other thing you need to know is that DevOps, done properly, includes mechanisms to allow experiences from the live environment to be fed back to development, in effect creating a continuous optimisation and improvement loop. Together with the faster flows enabled by more streamlined and efficient processes, this allows IT teams to deliver output in the form of new, updated or enhanced software on a more rapid and ongoing basis. And by rapid we mean reducing cycle times for software delivery from months or weeks to days or even hours, depending on what makes sense to the business.
The shorthand for this faster and more iterative way of working is ‘continuous delivery’, which is arguably a more apt and meaningful term than ‘DevOps’ as it relates to what you are trying to achieve rather than how. The concept of continuous delivery (especially if you tack ‘of value to customers’ or ‘of capability to users’ on the end of it) also resonates very well with senior execs and other business stakeholders. Couch the conversation against the backdrop of an accelerating pace of change in the way your industry operates, particularly in light of trends in digital business, and it all makes perfect sense.
From an adoption perspective, one of the biggest advantages of DevOps is that it started as a grass roots movement so tends to have a high degree of enthusiastic buy-in from practitioners. A pivotal early event that cemented activity and kicked off the formation of today’s thriving DevOps community was the ‘DevOpsDays’ gathering in Belgium back in 2009, which turned out to be the first of many.
The community is known for its open exchange of ideas and best practices, though evangelists can occasionally come across as a little elitist, creating the impression that DevOps was created ‘by the smart for the smart’. This is undoubtedly an unintentional result of genuine enthusiasm leading to a degree of tribalism, but it’s relevant when you consider how DevOps is adopted in your organisation.
I say this because I have spoken with a number of CIOs who are aware of DevOps related tools and practices being adopted bottom-up within their department, and are conscious of a sub-culture emerging. This can be good or bad depending on how you handle it. Allow it to follow its own course and you could end up with disjoints and friction that impede higher level progress. You could also confuse IT stakeholders by creating a ‘two speed’ IT service, making it harder to manage expectations. Think of practitioner-led activity as a catalyst for the introduction of modern practices more broadly, however, and it could open the door to an IT transformation opportunity at a more strategic level.
Of course this is easier said than done. Such transformation means driving cultural change across your organisation, which takes time, persistence and an absolute top-down commitment from management. At a more practical level you may then find that some of the tools and practices adopted to enable tactical DevOps don’t scale that well when you break out of the initial silo into the complex enterprise IT environment as a whole.
Open source tools that enable automated self-testing software builds, or allow rules-driven provisioning and deployment of resources remain essential, but may need to be augmented with higher-level orchestration capability. If you are going to aim for the continuous delivery nirvana of deployment of the latest software release at the push of a button, then things like release management need to be industrialised in a way that isn’t dependent on deep-space scripting expertise.
The good news is that IT vendors who are used to dealing with the often unglamorous reality of enterprise IT are now in on the act. While some DevOps purists don’t necessarily welcome such encroachment by ‘the establishment’, the truth is that commercial vendors like IBM, CA Technologies, Serena Software, BMC and others are providing solutions to problems that are less comfortable to address through the pure community route.
Despite the challenges, with appropriate cultural change and the right blend of open source and commercial software, it is perfectly possible to implement DevOps at a strategic level today. Continuous delivery then joins good governance, modern application architecture, user empowerment and an open approach to sourcing, as one of the key mechanisms for creating a fully agile business.