DevOps is an area of focus for everyone these days. DevOps is expected to be a solution to many problems ranging from IT responsiveness to customer satisfaction. However, one com­mon expectation from DevOps is to reduce Time to Market or increase Speed at which organizations can change/adapt/deliver new features to their customers. This capability can be defined as “Agility” or “Busi­ness Agility” that is required for a business to meet its goals. However, most who attempt to adopt DevOps are unable to realize tangible busi­ness benefits or “Agility” from its adoption.

" A DevOps success (meeting of business agility objectives) always needs change across the dimensions of Process, People, Automation (or Tools), Infrastructure and Architecture"

As agility needs of every busi­ness will be different, so will be its DevOps adoption. However, many organizations ignore this fact and jump into DevOps with the assump­tion that it involves primarily tool implementations with the objective of increasing levels of automation across the development and opera­tions lifecycle. There are many tool vendors out there with compet­ing offerings for the DevOps tool­ chain. DevOps, however, is much more than tools and automation. Its adoption requires organizational change effecting multiple dimen­sions of which tool usage is just one of them. Ignoring the others results in lot of wasted investments and a landscape being saddled with multi­ple duplicating tool sets, half-hearted implementations and blame game.

Following are some of the recom­mendations on how to make the DevOps implementation a success for the business.

Recommendation 1: Always define a success criterion for DevOps in business agility terms

Explicitly define what benefit we want from DevOps in business terms and make it measurable. We may be starting DevOps journey small, but de­fining what benefit to expect in business terms from its adoption will go a long way in ensuring its success and expansion. Some examples of such criterion as per my experience are as follows:

Once we have such a goal defined, it needs to be visual­ized, explained to various teams as to why this is important for the business. Creating such a shared goal across various teams (whether traditional or cross functional) goes a long way in lay­ing the foundations of a DevOps success story.

Recommendation 2: Translate the DevOps success criterion into downstream objectives

Once the overall business agility objective is defined, it can then be used to drive downstream agility objectives at the platform, process or team level. Taking an example of the objective of “Be­ing Able to add a supplier within 5 days”, we can define down­stream objectives as:

• Platform Level: Being able to have plug-n-play integrations with suppliers so that we can add or re­move suppliers without having an impact on other integrations. This capability has implications on the architecture of the integration solu­tion, technology choice and infra­structure on which it is deployed and subsequently monitored.

• Process Level: Being able to do feature based releases where change to a specific supplier integration or its addition/deletion can be released independent of others.

• Team Level: Enable the devel­opment teams who are doing the actual code changes, deliver integra­tions that are production ready. This requires developers to take full own­ership of the code they deliver right up into production.

In reality, what most organiza­tions adopting DevOps, do is sim­ply identify areas where automation is lacking. Mostly, this happens to be in various forms of functional & non-functional testing, environment provisioning, deployment, release management and straight away start adopting toolsets which address these gaps. On the process side, they implement various forms of Agile processes and start delivering it­eratively. This bottom up approach may or may not meet the business objective defined initially or worse, it may end up being an over kill.

Recommendation 3: Create a road­map across the dimensions of Pro­cess, Automation, Infrastructure, Architecture and People to really succeed with DevOps

What is really required is to not rush into various tool implementa­tions, as tools are only one dimen­sion. A DevOps success (meeting of business agility objectives) always needs change across the dimensions of Process, People, Automation (or Tools), Infrastructure and Architec­ture. The extent of change required across these will be determined by what are your end objectives. For example, changes required to enable a release cycle of 3 days will be very different from if a release cycle of 4 hours is desired.

Organizations should identify gaps across all these five dimensions and prioritize them based on the business need, investment require­ment and appetite and then move ahead with the adoption. During the journey, continuous inspection and adaptation of the roadmap is required depending upon what is working and what is not.

Anti-Patterns to Watch Out For

• Starting on DevOps journey without a business linked success criterion

• Consider DevOps as being limited to implementation of tools and rushing into their implementation

• Ignoring the people aspects in terms of skills and aspirations. This is one of the most difficult dimensions to address

• Ignoring the architectural limitations of the application(s) in scope. If the architecture is monolithic, then tools, process and automation can only get you so far

• Attempting a big bang approach. DevOps is a journey and not a project.