How to chalk out your Enterprise DevOps adoption strategy

There are a lot of steps from product build to deployment, and also a lot of things that can, and do, go wrong. A few of these might sound familiar:

• The Dev team adds a new feature right before release and the QA team does not have enough time to run the whole gamut of tests. The code is pushed to live and it’s too late before you realize that you missed a few bugs.

• You update your product and release a new version. It worked fine for the developers and testers, but not when deployed on the production servers. Because the Dev team missed informing the Ops team about updating a library or the database on the servers.

• Your code is ready to go, but the Ops team says they will need a couple of days to configure all the environments to the given specifications. Or maybe a server goes down, and they take hours to get it back up, manually configuring it all over again.

Every product team has faced these challenges at some point in time. If your product development and delivery pipeline is largely manual, the only way to avoid these challenges is to work steady and double check to make sure you haven’t missed anything.

Meanwhile, that new disruptive start-up in your industry has already released the second version of a competing product. They are able to do this because of shorter and faster release cycles, ability to deploy quick fixes for bugs, and recover faster from system failures.

And this is probably why your enterprise has to start looking towards DevOps adoption. If you wish to stay ahead of the curve with your products and services, this is no longer a matter of choice. Besides resolving some of the current challenges your siloed teams face, DevOps is key to a faster product delivery pipeline.

However, enterprise-wide DevOps adoption is easier said than done. There is, of course, the initial resistance to changing established practices. Additionally, convincingly showcasing the value of DevOps to the entire organization is a challenge.

Micro Hering, Principal Director at Accenture, points out one of the key reasons why DevOps adoption is derailed: “Some group goes off and implements DevOps practices (for example the testing center of excellence or the operations team) and they have great successes. Their individual results improve so that the automated regression now runs in minutes not hours and giving developers a development environment from the cloud takes hours not weeks. Yet the organization as a whole fails to see the benefits because the different practices are not compatible or too many dependencies continue to hinder real results.”

Hence, what is needed is a well-planned and executed DevOps adoption strategy, that will produce measurable results. What we suggest is a two-phase roadmap:

Phase 1: Showcasing DevOps ROI
Phase 2: Identifying and Side-stepping the Trip Wires

Showcasing DevOps ROI

To accelerate time to market with DevOps, it has to be adopted by all teams across the organization. And that is easier to achieve when stakeholders get behind the idea of DevOps adoption. So the first step is to demonstrate to all stakeholders how DevOps can bring in significant benefits.

Here’s how to do that:

Evaluate Your Delivery Pipeline

Understanding the existing delivery pipeline is the first step. Get together all the process stakeholders. Map out your pipeline in complete detail, understanding each process, highlighting if it’s manual or automated, and how long it takes to complete it. Identify any inherent cause-effect relationships and dependencies in the pipeline.

Identify Process Bottlenecks

The next step is to identify all the existing process bottlenecks. 

This could be in terms of time taken by the Ops team to configure a production environment. Or the time taken by the QA team to thoroughly test every feature addition. Or mismatch in configurations between development and deployment servers. 

Identifying these bottlenecks helps you and other stakeholders realize that there is a need for adopting better practices. It also demonstrates where the distinct DevOps practices like infrastructure-as-code, automated test scripts, configuration management etc. will fit in.

This is also the right time to identify certain base performance metrics, which will help showcase the improvements made with DevOps.

Choose Your Experimental Set

A lot of times, applying DevOps principles to an isolated process is not enough to convince stakeholders of the benefits. It gets viewed as a one-off incident and not something that would be replicable across the organization.

Your experimental set, i.e. the specific set of processes on which you want to apply DevOps practices, has to be chosen carefully. 

Ideally, it should meet the following criteria:

• The processes are integrated and need to change together in order to work

• They are important for the enterprise and whose improvement will deliver significant benefits

• Can be optimized within a short period of time

For example, let’s say you choose server configuration as your experimental set, which will involve:

• How you configure a development, testing, or production server, and how long it takes

• How do you update the servers when new product versions are released

• How fast can you reconfigure a server that went down

This inter-related set of processes can be tackled with the DevOps practices of infrastructure-as-code and configuration management. And an improvement in your server configuration times means a huge acceleration in your delivery pipeline. 

Practise DevOps

With your experimental set of processes identified, start integrating DevOps practices from the ground up. The earlier on in the process you introduce it, the better. The key here is to be conscious of the process changes and making sure the team sticks with them. Tight feedback schedules and team’s complete alignment with the final goal would be crucial. 

As you work on optimizing these processes, the benefits of DevOps would start reflecting. In the time taken to delivery, the number of bugs reported, the automations introduced and their impact on performance. These benefits must get documented and mapped against the base metrics identified. 

Now your work is ready to be showcased to stakeholders as an example where DevOps created significant ROI for the enterprise. Once they see the measurable value additions, it’s easier for them to buy into the idea and make a strong push for DevOps adoption across the enterprise. 

Identifying and Side-stepping the Trip Wires

With key stakeholders on-board, the next phase is to make sure you foresee the challenges that can come up, and how to get over those. This involves taking a look at three key factors:

Organizational Practices

DevOps demands close collaboration between Dev and Ops teams and a work culture that is focussed on accepting and correcting mistakes rather than pointing fingers. This kind of cross-team cooperation could be difficult to get right at the first go. But recognizing the need for it, and enabling it across the organization is the first step here.

Enterprise teams should also consciously extend the development methodologies of agile, to the operations teams. This allows both teams to communicate in stand-ups and retros, building a greater understanding and collaboration.

Legacy Modernization

Here’s where most enterprises trip up because they feel:

• DevOps practices would only be effective with modern applications and platforms

• Legacy modernization would mean completely doing away with the old architecture, which will involve significant expenditure

However, DevOps practices can work as easily with legacy platforms as with modern ones. Continuous integration, one-touch deployments, agile release cycles are all possible on legacy platforms, with the right tools.

Moreover, legacy modernization does not always mean an expensive upheaval. In most cases, it can be achieved through adapting your heritage systems to modern methods. And DevOps practices can actually let you do this faster and in a more efficient manner.

System Reliability

The speed of delivery achieved through DevOps often raises concerns around system reliability.

As a concept, DevOps embraces failure as inevitable and concentrates on designing systems that can get back to work fast, after a breakdown. There are examples like Netflix’s Chaos Monkey, that are designed to trigger randomized system failures. This pushes their teams to build systems that are capable of healing fast in such conditions. 

So DevOps moves beyond reliability, towards achieving more resilient systems.

While this two-phase roadmap is a great starting point as enterprises start thinking about DevOps, you will have to tweak it suit your particular organization. 

There are, of course, a lot of decisions to be made once you start down the DevOps way. The most important of those is choosing the right DevOps toolchain for your teams. This is also where  DevOps consulting services like ours could lend a hand. 

Let's start the conversation about how we can power your competitive advantage with DevOps.