Dynamics of DevOps Adoption

Of late, there has been lot of hype and rhetoric about DevOps. Several organizations around the world have embarked on massive adoption of DevOps, and many see this as a silver bullet to 'solve' all their development and operational issues. There are DevOps enthusiasts who believe this is the best thing to have happened in the last thirty years. DevOps, adopted correctly, can bring in immense benefits. But as we know, DevOps demands a cultural change (a paradigm shift in culture) to make it successful. DevOps expects a connected and holistic view, instead of taking a piecemeal approach. This is the central core of systems thinking. In other words, DevOps works well when it weaves in and meshes systemic view into the entire paradigm.

In this article I analyze DevOps adoption by taking a systemic perspective, through a series of system diagrams (causal loop models). These are based on and synthesized from multiple DevOps initiatives I have studied and / or advised.

A culmination of market, economic, technological, regulatory and social factors fuels the means to deliver services through digital channels. This drives demand for digital transformation. This in turn, pushes enterprises to conceive, design and deliver new products and services. Traditional products and channels are shrinking or being rejigged. As a whole, this creates a situation characterized by nebulous ideas that are hard to fathom and solidify. This leads to the need for greater developmental and operational agility, i.e. ability to launch / provision new products and services quickly. This need for agility is manifested as agile and lean for the services sector, with the aim of elevating productivity (doing more with less) and responsiveness (quicker go to market), as these are the cornerstones of the ability of the IT organization to fulfill business needs, and even create new needs. This leads to greater trust and partnership between business and IT. IT is no longer seen to be the bottleneck, slowing down rest of the enterprise. This is depicted in the reinforcing loop R1: The Ideal Scenario. This is the nodal loop, that has the ability to take the enterprise to much greater levels of performance and outcomes, if all the factors shown work in concert. 

The push for developmental and operational agility steers enterprises to look for more efficient and effective means of doing things, which also delivers compelling value to critical stakeholders and customers alike. The manifestation of agile and lean, via DevOps leads to disruption in traditional methods. Gartner summarizes DevOps “as a change in IT culture, focusing on rapid IT service delivery through the adoption of agile and lean principles in the context of a system oriented approach. DevOps emphasizes people (and culture) and seeks to improve collaboration between the Operations and the Development teams. DevOps implementations utilize technology, especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.” As DevOps means a fundamental shift in the IT culture, it brings with it it’s own share of cynicism and doubt. It is not a surprise to find groups who reject any change, and more importantly, even try to derail and obstruct any such efforts to change. This has the potential to undermine the agile and lean thinking, and slow down, if not stop, the ideal scenario. This is depicted as the loop B1: Diverging Agendas, which acts as an opposing set of factors to R1.

Political factors clearly influence the adoption of DevOps. Like with any new initiative, given that such initiatives have funding support, there are groups within the enterprise that are first to jump on to the bandwagon. Usually there are multitude of reasons, ranging from access to funds to being viewed as pioneers within the organization. Such groups take it upon themselves to demonstrate that DevOps is a great idea, and in this belief start up new projects to prove their point. The advantage of having such trailblazers is that it allows enterprises to generate data to validate that DevOps does deliver value. In some sense, if handled well, successful trailblazers are great for internal marketing, to some extent negating the influence of the cynics. Therefore, this acts as tailwind to R1, and is depicted by loop R2: Proof of Value. The downside of having too many of such trailblazers is that they are difficult to manage, and with limited support by way of tools, methods and processes, each of these projects usually go their own way, with limited sharing of knowledge and experience. In the scenario of minimal cross-fertilization of ideas, these multiple initiatives have the danger to producing inconsistent and incoherent outcomes. This is depicted in loop B2: Reverse Pioneers. The impact of B2 is damaging to the entire DevOps journey, emboldening the cynics.

With the need to create and service new products, characterized by VUCA, the need to achieve developmental and operational agility becomes paramount. There is a general consensus that adoption of tools and other mechanisms of automation does bring on predictability, quality and consistency for and within the enterprise. This has a role to allay cynicism and doubt to some extent. This is shown in loop R3: Enabling Infrastructure. That said, there is no dearth of tools in the market and vendors trying to ‘pitch’ theirs’ as the best. The enterprises have to trade-off between adopting less number of tools (and less vendors) but better integrated, or more tools (more vendors) and face integration challenges. This is because, tools coming from different vendors are not naturally integrated (they are not meant to work together), but with the need to cover the entire Development and Operational chain, leads to increased efforts to get the tools ‘working together’. This is depicted in loop B3: No Free Lunch. 

With the propensity to adopt tools and automation, to elevate its effectiveness, there is a need to enhance and embrace processes, methods and people. The adoption of tools coupled with standardization leads to significant upside to skills and competency levels of people involved in DevOps projects. These, working together, leads to improvement in overall proficiency. This further drives the ability and willingness to adopt automation, thus further reinforcing the need to sustain improvements in processes, methods and people skills.

This is depicted in loop R4: Invest in Resources. R4 has a significant impact in reducing cynicism and doubt, leading to greater receptiveness towards DevOps. One of the ways to deal with VUCA, is to embrace standardization by way of processes, tools and automation. Standards enable economies of scale benefits thereby driving the overall costs down, and also act as catalysts for development of skills and competencies. This has a positive influence in the overall proficiency in the organization, leading to higher predictability, quality and consistency. This, in turn, addresses the issue of cynicism and doubt. This depicted in loop R5: Network Effects, which works in tandem with R4, both shown the diagram above.  

With the adoption of standards, there is a direct positive influence on the cost efficiency. The organization derives economies of scale benefits due to standardization. In tandem, the adoption of tools and automation across the DevOps value chain, also contributes to economies of scale benefits. As these factors play out, there is a great likelihood that the organization is able to institutionalize the DevOps culture and practices across all aspects. These are depicted by loops R6: Scale Benefits and R7: DevOps@Scale depicted below.

Despite all benefits that come with the adoption of standards, there’s always a chance that complying with standards reduces likelihood of exploring new technological possibilities that emerge out of constant advancements. This discourages the propensity to experiment and encourages all groups to conform, as an innovation dampener. As a consequence, there is an emergence of ‘shadow IT’ operations, who typically dabble with new technologies and more or less operate ‘under the radar’. While shadow IT is acceptable as long as such instances are few, but if it becomes wide spread, it defeats the very purpose of having common processes, methods and tools across the enterprise, entrenching silos even further, and negatively impacting predictability, quality and consistency. This phenomenon is shown on loop B4: Perils of Standardization as shown below.

Putting all the above diagrams together, the full system model is shown below depicting a confluence of factors that impact the adoption of DevOps. Patterns (and anti-patterns) of adoption and diffusion are clearly visible in the model.

The full system model, capturing the dynamics can be used to identify interventions that can push DevOps adoption by strengthening the enablers (i.e. the reinforcing / positive loops) and weakening the impediments (i.e. balancing / negative loops). Impediments add 'friction' into the system which cannot be completely eliminated, and these also have some benefits in terms of providing a reality check from time to time. Through interventions, the aim is to ensure that the combined impact of impediments does not exceed the combined impact of enablers, else the program derails. However, success and effectiveness of DevOps adoption will lie on the quality and impact of the identified interventions. All interventions are not equal. The diagram below shows different levels of interventions, their effectiveness in driving adoption along with a few examples.

In conclusion, DevOps is an advancement in thinking that requires a massive cultural shift. As an enterprise architect, we ought to take an integrated view of the whole paradigm with situational awareness, without getting dazzled by all the media hype and rhetoric. Identifying and understanding the impact of factors gives the ability to calibrate and fidelity to get to the desired state. The intervention points act as levers (like a pilot in a modern airliner) to steer the DevOps journey. The skill is to get the combination right. The idea is simple, the organization's architecture (structure, governance, policies, accelerators, infrastructure) should be in support of DevOps to make it successful and the journey carefully strategized and executed.