Why have a 360° perspective when adopting DevOps?

As we discovered through the book’s DevOps definition, there are several elements that contribute to what DevOps is about for an organization. From practices to people and from technology to shared objectives, all these elements need to come into harmony. In this chapter, we introduce the element of 360° in DevOps, explaining its value proposition and applicability.

In mathematics, the term 360° indicates a complete trip around the edge of a circle. Take as an example the rotation of the Earth around the Sun, or the rotation of a clock’s hands in order to complete 12 hours, or to relate even more to our context, take a look at the symbol of DevOps, the loop of infinity. In all these examples, there is a starting point and after a 360° rotation around different phases, we end up again at the starting point. Ending up at the same point where we started does not indicate that we achieved nothing, and we are back at square one. It indicates that we managed to achieve a complete and flawless rotation across DevOps capabilities: complete in terms of we have engaged all necessary capabilities that comprise our DevOps model and flawless in terms of those capabilities were so harmoniously interlinked that it did not interrupt our 360° journey.

In this book, 360° indicates the need to cater to four qualities when adopting DevOps at the enterprise scale (please note that the definitions of the following terms are taken from the Oxford English Dictionary):

• Completeness: We define completeness as the fact of including all the parts that are necessary; the fact of being whole. In our DevOps context, these parts are all the tools, stakeholders, processes, policies, mechanisms, frameworks, metrics, funding, and so on that are necessary in order to perform successful enterprise adoption at scale. The fact of being the whole indicates on the one hand the necessity of involvement of the whole organization, or at least the required parts that directly or indirectly have a role to play in DevOps adoption. And on the other hand, the DevOps capabilities that are to be enabled and adopted need to complement each other, as in being the interconnected and interrelated pieces of the broader DevOps adoption puzzle.
• Continuity: We define continuity as the fact of not stopping. In DevOps, this means going on and on (infinitely) around DevOps phases and the capabilities that enable them, without interruption, but also ensuring that the DevOps adoption is not a one-off activity, and it organically becomes part of the organization’s DNA, characterized by continuous evolution.
• Reconcilability: We define reconcilability as the ability of a concept to coexist with another. In our context, this defines the ability of DevOps to coexist in harmony, on the one hand within its sums, meaning harmony and balance across the concepts that are at its core – for instance, compliance controls being in harmony with release velocity. And on the other hand, it means to be in harmony and balance with other concepts that are also adopted in the organizational context, such as Agile and ITIL.
• Interoperability: We define interoperability as the ability of entities in a network to connect with each other and carry out their functions. In our context, we refer to the ability of the DevOps technological ecosystem and corresponding enabled capabilities being perceived as the backbone of DevOps adoption, to achieve a high level of interconnectedness through full stack engineering. In addition, we refer to the ability to collect data across the technological ecosystem that can be mapped to the end-to-end SDLC, across the DevOps continuity phases, and be utilized as a source for feedback loops, visibility, and continuous improvements.

The four qualities mentioned do have a relation of interdependence among them, and it is necessary to evolve them in parallel as one cannot deliver its full potential without the others. As an example, if in your DevOps adoption, you do not engage the complete set of your infrastructure team’s stakeholders, you will never be able to achieve continuity in the developers’ journey of consuming infrastructure capabilities, which will consequently result in technological solutions’ interoperability gaps and, moreover, fragmentation in your technological DevOps enablers’ reconciliation.

Your enterprise 360° DevOps adoption should be characterized by these four qualities, which should eventually be recalled readily by each participant in your organization and guide ideas, discussions, disagreements, decisions, and solutions. Your adherence to them can be checked by asking the following four simple questions:

• Does approach A fulfill the quality of completeness?
• Does solution B fit in the continuity cycle or does it break it?
• Is solution E reconcilable with concept D?
• Is solution C interoperable with the core technological ecosystem?