Why does it seem like no one really knows what DevOps is?
Confusing and unclear messaging at this early stage is both natural and inevitable, because DevOps means different things to different people, as they interpret their own experiences with the movement.
For many grassroots technologists —indeed, this is where the origins of both Agile and DevOps lie— the understanding of DevOps is captured primarily in its focus on the technologies that enable automation of the development pipeline and delivery into production systems.
Conversely, for those in leadership roles, DevOps is better summarised by the non-trivial challenges of engaging people and process in organisational culture change to align two groups with traditionally deep-seated conflicts in their fundamental understanding of the value they each contribute.
Neither of those views are incorrect, and indeed there are many more valid interpretations of what DevOps is and how it adds value to organisations.
The reality is fortunately somewhat simpler than most of the descriptive theory makes it out to be. As the anecdotal recounting in my previous post (“How did DevOps come about?“) accurately purports, DevOps takes a holistic view within the Software Development industry. What is more, is that —in similar fashion as the Agile movement that came before— DevOps has the intent and capability to transform every area of an organisation or enterprise into a cross-functional and highly automated machine of efficiency.
Allow me to reiterate that last point… DevOps is not only useful for Software Development. Of course it comes into its own when applied across a software delivery area, because that is where it came into being, but it can also be extremely valuable in, for example, digital media production, automation of HR processes, Identity and Access Management, workflow automation, and countless more.
Viewed from that understanding, it’s no wonder that different groups of people have different expectations of DevOps, and therefore also different interpretations of what it is.
Is it even possible to give a definition for DevOps?
Amidst such persistent confusion, the best one can do to arrive at some sort of consistent statement is to find as many definitions as possible, and distil them into something coherent that resonates with one’s own experience and interpretation.
The obvious place to start such a quest for a single version of the truth is —of course— Wikipedia, which offers this:
DevOps (a clipped compound of “development” and “operations”) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.
Webopedia takes this organisation-focused view:
DevOps (development and operations) is an enterprise software development phrase used to mean a type of agile relationship between Development and IT Operations. The goal of DevOps is to change and improve the relationship by advocating better communication and collaboration between the two business units.
The Agile Admin has a view focused more strongly on the people involved:
DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.
The primary reason that such varying viewpoints abound is that the authors would typically favour certain aspects of DevOps over others. Specifically, in most places where DevOps has manifested naturally, the cultural aspects were already in place, and so those interpretations are largely centred around the toolchain. Others are trying to get there, but outdated traditional organisational structures are tripping them up at every turn, and so their descriptions of DevOps focus on those cultural notions.
Seeing as I interact with various clients who find themselves at varying degrees of modernity along this journey, it made sense for me to digest the most credible sources into a holistic view that describes the true nature and intent of DevOps, irrespective of the environment in which you view it.
Here’s what I’ve come up with (so far)…
One consultant’s understanding of DevOps:
DevOps is the alignment of people, process and technology —across the entire value chain in the agile enterprise— to continuously improve the delivery of value to the customer.
Let’s break that down and consider the various implications contained therein.
DevOps wants the whole organisation to share responsibility for the same goals. Alignment is a Good Thing ™, we all like alignment.
That’s not to say that there won’t be various intermediate objectives along the way, or that different disciplines will not place different priorities on certain things, but simply that those differences are to be considered subsequent and subject to the unifying notion of delivering value to the customer.
Furthermore, it suggests that organisational structures may need to be changed in order to enable said alignment, with the focus of reporting lines shifting toward business capabilities and associated outcomes and away from business units built around specific disciplines.
DevOps recognises that there are organic beings behind everything the organisation is trying to accomplish, and this speaks to the concerns of Culture and Mind-set within the organisation.
It is especially noteworthy for companies that are still largely divided into vertical silos. To bring about the cultural change required to reorganise around business capabilities, instead of functions or disciplines, is a complex but essential part of true digital transformation.
Here we bring the organic side of the organisation into focus, and say that we are willing to change the way we work and the demands we place on each other in order to work better.
The relationship between people, process and technology is best described by the first tenet on the Agile Manifesto, namely: “Individuals and interactions over processes and tools”. To extend on that, processes in an organisation should be intentionally designed so that they support the people and the way they prefer to work. Similarly, the technology should be intentionally designed to support the processes that the people choose to adopt.
Perhaps an obvious point, is that DevOps is both built on and built upon by technology, and is similarly both enabled by and an enabler for technology. A driving aspect in much of the technology and tooling with a DevOps intent, is to enable automation of routine tasks in order to free up expensive human resources. In fact, a popular mantra colloquially shared in DevOps circles is: “Automate all the things!”
DevOps is intrinsically linked to certain types of technology tooling in the value stream, insofar as those tools specifically support the notions underpinning some of the elements of DevOps. It is therefore customary to refer to the DevOps “toolchain”, as there are a number of separate but interdependent tools that work together throughout the value stream to enable efficient delivery of work.
This quite simply means that our interest doesn’t end when the code compiles, or when the tests are green. In fact, it also points out that we’re not only concerned with development and operations, but with all areas of the organisation that contributes to delivering customer value.
At the very heart of DevOps lies the notion that, while any single discipline contributes only partially to the outcome, many others similarly contribute before the outcome can be successfully delivered. Therefore, to achieve success, we have to empower the people, improve the process, and enable the technology across all of these contributing areas.
Organisations shouldn’t adopt DevOps unless they also adopt (or have adopted) Agile throughout the value chain, because DevOps builds on the foundations laid by Agile to deliver at velocity.
While it is certainly possible to implement certain elements of DevOps with a fair amount of success in traditional organisations, most of the benefit of DevOps is only realised within an ecosystem supported by an Agile mindset.
DevOps is fundamentally intent on regularly and consistently getting better at things. Simultaneously, DevOps recognises that the ability to do so also implies the availability of the required monitoring and feedback mechanisms to enable it. As such it is equally intent on building such feedback mechanisms throughout the value chain, often introducing requirements into the design up-front in order to enable feedback post deployment.
In the current context, this means a few things:
- the capacity to deliver;
- the quality, velocity and certainty of that which is delivered; and
- the quality, velocity and certainty of the delivery itself.
In the disruptive digital economy, businesses are constantly challenged to be increasingly better at responding to changing markets. The four aspects of delivery highlighted above also constitute the key aspects for success in this dynamic environment:
- “capacity” means that one is able to meet demand without delay;
- “quality” means that one delivers the right thing without need for rework;
- “velocity” means that one delivers swiftly without lagging the market; and
- “certainty” means that one has the ability to act with confidence.
DevOps aims to ensure that what gets delivered creates value for the customer. To that end, it also requires that there exists common understanding about:
- who “the customer” is;
- what said “value” looks like; and
- how it gets measured.
Modern businesses understand all too well that the only way for them to remain viable and relevant is to deliver value that their customers want and are willing to pay for. DevOps enables them in this through transformation that not only brings about the kind of cultural change that is required, but also provides cutting edge tools aimed at eliminating waste, reducing overhead and freeing up valuable resources — and doing all of it in ways that are scalable, sustainable, adaptive to change, and open to learning.
The first step for any organisation that intends to start on the DevOps journey, is to come to terms with who they are, where they’re at, and what exactly DevOps means *for them*. Crafting a mission statement out of this understanding will subsequently prove invaluable, whether as an anchor for cultural change initiatives or a reinforcement of the organisational sense of unity.
As always, I welcome your thoughts and feedback… Leave your reply below…