DevOps - Crossing the Chasm

By Balaji Parthasarathy, Director IT Applications, VMware

According to Maverick Research, by 2021, Bimodal IT Will Be for Digital Losers.

The DevOps forms the foundation of this digital transformation; eventually this will determine the Digital Winners and Los­ers. In the DevOps adoption survey con­ducted by Gartner (August 2016), less than 38% are in the DevOps transition with 19% still struggling in pilot phase and remaining 19% using DevOps for pro­duction system (in some form). This is clear indication of crack in the adoption curve between "Early Adopters" and "Early Majority" - The chasm (concept inspired by Geoffery A. Moore).

The typical adoption cycle follows the pilot model (the early adopters) and transition the pilot into mainstream - production ready (early majority).

What creates this Chasm, and why it is hard to overcome?

The Early Adopters/ Visionaries, in our case the pilot pro­jects are driven by dream. The Early Adopters is buying a revolutionary change agent (DevOps) and have following expectations viz.

• Expect a clear discontinuity between the old model and the new model - DevOps

• Expect clear strategic advantages of adoption DevOpos

• Tolerate imperfections and glitches

The Early Majority are more pragmatist, very loyal to what works &are proven. They are risk averse, but rather prefer incremental improvements on proven models/solu­tions.The Early Majority is buying for productivity improve­ment for existing operations and their expectations are -

• Want to minimize the discontinuity with the old way (seamless transition to DevOps)

• Wants innovations to enhance established business pro­cesses

• Expect a more or less disruption free product (consistency in SLAs)

This chasm is already hard to cross dealing with two different mindset of folks and we make it harder by trying to repackage the solution that appealed for Pilot group for Larger Early Majority - One size does not fit all.

How to cross the chasm?

You can cross this chasm by targeting on the niche first.

First:We might need to pick a very targeted and specific niche inside the early majority to focus upon; this is like first securing a beachhead in an invasion.

The typical challenges of the mainstream/ early major­ity are around“Developer Productivity Killers! “ which eats into Speed, Quality and Costof a project viz.

1. Infrastructure agility ->Solve: Virtualization & Cloud Strategy [Speed]

2. Reducing Multiple Instance paths –>Solve: Trunk-based development [Cost]

3. Code Stability/ Instance stability challenges –>Solve: Continuous Integration [Cost & Quality]

4. Technical-debt of Legacy monolith ->Solve: Loosely cou­pled architecture [Speed]

5. Security Vulnerability –>Solve: Shift Left on Security (DevSec) [Cost & Quality]

6. Last Mile Problem –>Solve: Continuous Deployment [Speed and Cost]

Please note that a Pragmatist would not buy into 80% solution, it is 100% or none.

Second: Target the point of attack

It is very importantto clearly define the FINAL goal and the incremental KPI targets that would enable the Pragma­tist to see value to reinforce the confidence for the early majority. Clearly articulate the goals that is tangible and understood by all for each quarter, build means to measure and course correct.


• Production Ready code any time

• Deploy when Ready (done)

• No touch deployment (address the last mile problem - FIRST )

Third: Assemble the invasion force - Define your framework Definition of Done (DoD)

The Definition of Done (DoD) varies significantly across organizations.

Survey by dZone research 2015 edition - 79% say its when all code compiles and builds for all platforms. Other common answers were: Fea­tures reviewed and accepted by Prod­uct Owner (65%), Unit tests are im­plemented for new functionality and are all green with known failures not­ed (63%), New features are system-tested (59%), and Acceptance/story tests are written and passing (52%).

I suggest keep it flexible as 2 or 3 models (not more) which can be used by each team based on their business needs -

• DoD 1 — When Feature is ready to be deployed (all validations done)

• DoD2 — When Feature is delivered in the product

Bite sized requirement (Features)

The ability to breakdown the require­ments into discrete BITE sized fea­tures will determine the success of the continuous delivery framework. The key advantages with this is-

• It brings full control for delivery, testing, build, release, fix and roll-back (to meet the MTTR if needed)

• It can be handled by a small team (full stake delivery teams)

• Business validation is short and simple (no need for full integration).

This is more easily said than done and need a thoughtful process even from the stage of requirement analy­sis and backlog grooming

Built in Quality (part of delivery)

The culture that “DevOps (Devel­opers in the old terminology) owns quality -” is very important. Make this a DevOps accountability rather than silo QA, build quality in your development lifecycle through auto­mation and services testing.

Continuous Integration (CI)

This logically takes us to the Contin­uous Integration (CI), clearly define the framework-

• Frequency of build (Daily orHourly)

• Scope of automated testing (Re­gression + Impacted Regression+ Feature driven testing)

Once you define your scope of automated testing, and then work backwards for each sprint in terms of tools and means to shift left to get the Feature and Impacted regression within the sprint. This could be very challenging and this is where the au­tomation and delivery teams give up.

Full Stake Delivery teams

I like the phrase “God cannot be eve­rywhere, so he created mothers”. So that is the message, admins cannot be everywhere, enable all developers to handle admin tasks that is routine. The same applies for all stacks - mid­dle ware, database, UI etc. A team should have a good composition of developers who can handle multiple tech stacks (one above-one below, will do to start with).Bring in the cul­ture of self-reliant full stake delivery teams.


Make “Kanban” or any one single framework as your single pane of glass, internal and external. This bring in transparency and make it available for stakeholders.

Fourth: Define the battle

Positioning is key for success. It is important to position this new model (DevOps) to be compelling and make strong claims in the niche that is se­lected say last mile problem, infra­structure agility etc (refer first step). Pragmatists want to know where you stand with respect to your competi­tion (current model that they are fol­lowing. In case some of this niche does not align to traditional IT, de­fine your competition yourself i.e. set goals for the niche.

Fifth: Launch the invasion

The weakest link determines the strength of the chain, focus on Achil­les heel of the niche within the Early Majority be it daily deployments, code stability, last mile problem etc. Force old methodology out of that niche area and use it as a base for expanding DevOps offerings to the mainstream.

Finally: Getting Beyond the Chasm

Going back as Geoffrey puts it, we need to recognize that prechasm commitments are simply unmaintain­able in the postchasm period. In our world, the DevOps Pilot and Main­stream. DevOps pilots may promise a level of performance or reward that is hard to meet. This leads to a situa­tion that we need to manage our way out of the contradictions imposed by prechasm agreements.The first and best solution [is] to avoid making the wrong kind of commitments during the prechasm period i.e. Pilot Projects and focus on setting realistic targets for early majority from pilot stage.

Don't Miss ( 1-5 of 20 )