Top 5 challenges when scaling DevOps in the enterprise

Source – sdtimes.com

The goals and principles of DevOps should be the same in any organization; however, scaling DevOps practices in large enterprises with hundreds of applications, geographically dispersed teams, and both loosely and tightly coupled architectures presents some unique challenges. Each enterprise has its own DNA that has organically evolved through generations of applications and technologies with its own set of artifacts and processes.

So, if every enterprise looks entirely different than the next, where do you start? First and foremost, you need to understand your business objectives because those objectives and measured outcomes drive the enterprise DevOps transformation, not vice versa. A thorough understanding of the business objectives (i.e. to free up capacity for innovation and eliminate the bottleneck to the business) enables DevOps practices to be appropriately scaled for the enterprise.

As organizations begin their DevOps journey, they will face many hurdles. Here are five common challenges you may encounter along with potential solutions to help establish a foundation for a successful DevOps journey.

1.) Changing to a DevOps Culture

Renowned American scientist, author and founding father of the quality movement, W. Edwards Deming said, “a bad system will beat a good person every time,” and this sentiment captures the main challenge when implementing a DevOps culture. The system, not the employees, is the cause of the problem, and an organization’s leadership team needs to be willing to change the system of work. To start, first define the desired actions and behaviors, then design or update the work processes to reinforce those behaviors.

If continuous improvement and change is desired, you have to ensure the “System” is designed to support these cultural traits. If the Ops teams are measured only by mitigating risk and the Dev teams are measured only by delivering change, there is a conflict in the system that must be resolved, and the leadership team must take the initiative to fix the problem.  Only management can align the resources within the organization to drive the level of transformation that is required, and that management team needs to get on board and be willing to change the system; otherwise scaling DevOps will not be possible.

2.) System Thinking for the Enterprise

The goal of scaling DevOps in the enterprise, as highlighted in Gary Gruver’s book, “Starting and Scaling DevOps in the Enterprise,” is to document, prioritize, and optimize existing deployment pipelines and seek efficiencies to deliver better business outcomes. Every IT organization currently has a software process in place to build and deliver software – the “current” deployment pipeline. In fact, large enterprises have many deployment pipelines, and often, DevOps is first implemented at a team level that leverages DevOps practices within the context of a particular deployment pipeline. By employing system thinking within the scope of their deployment pipeline, the team can ensure that local optimization does not jeopardize the flow of the entire pipeline.

In large enterprises, to be successful, there should be another level of abstraction where system thinking is pitched above the level of individual deployment pipelines and product teams. Building a resilient enterprise requires understanding and anticipating how the whole system is designed to work vs. how it is currently working, and documenting your existing deployment pipelines could turn into a discovery session exposing the local constraints, dependencies, and waste that impact the entire system.

3.) Bridging the Old with the New

After over 40 years of investment, enterprise IT runs the world on applications that span many different development methodologies and infrastructure architectures. The future of enterprise IT depends on the ability to innovate faster while minimizing risk and to unlock the value of existing core business systems while leveraging new disruptive technologies. It’s not only about delivering legacy code faster, but also about optimizing cost and efficiency of existing infrastructures while providing the ability to automate and integrate the DevOps toolchain.

Many believe you have to be agile or implement a bimodal strategy to do DevOps; however, neither is true. Accelerating application delivery is the number one reason companies implement agile development methodologies, but agile by itself is often not sufficient. And, bimodal does not work well either as it just creates bigger silos that do not map with the value stream of the business.  Modern applications are supported across a complex, distributed and heterogeneous set of environments, and frequent changes to the systems of engagement tend to drive changes to the systems of record, requiring organizations to improve the flow of change through all systems in the value chain.

Most organizations have been slow to realize that the same DevOps principles used for loosely-coupled architectures work for tightly-coupled architectures as well. In fact, tightly-coupled architectures provide a unique opportunity to free up capacity for innovation by automating deployment pipelines and removing waste.  At the end of the day, it is important to remember that DevOps is not about what you do on what platform, but what your outcomes are.

4.) Prioritizing Deployment Pipeline Optimization

Once you get a view and understanding of your deployment pipelines, you need to make decisions on which pipelines should be optimized first. Decisions should be made based on the original business objectives. With fixed IT budgets, optimizations should not only reduce lead times, but reduce costs as well. Only by factoring in both cost and lead times will organizations be able to satisfy previously set objectives.

For example, you may have a collection of loosely-coupled pipelines that support high-growth applications and drive a lot of changes. These pipelines may require more resources. You might also have several tightly-coupled pipelines that are low-growth and support your existing revenue stream.  These pipelines may have a high cost of support. In this case, where should you prioritize optimization efforts?

Many would take the tightly-coupled pipelines off the table and focus on optimizing the loosely-coupled, high growth pipelines. But, if your business objectives are to free up capacity for innovation and not be a bottleneck to the business, you can accomplish this by optimizing the tightly-coupled pipelines first, and quite frequently, these pipelines have the longest lead times, so you are satisfying both objectives.

5.) Where to Optimize

Once you have a prioritized list of deployment pipelines, you can begin drilling down into pipeline optimization. Your value stream mapping exercise should provide you with guidance on sources of waste and long lead times, which may include:

• Lack of understanding of the business requirements leading to high development rework costs and long lead times
• Too much manual effort in building, provisioning, testing, and deploying applications and environments
• Too many meetings and slow approval processes around change and release management
• Failed deployments and production incidents

Automation is often times a common place to start in order to reduce long lead times and increase efficiency. Automating your provisioning, testing and deployments will dramatically reduce manual effort, increase deployment frequency, decrease lead times, and produce fewer production incidents, enabling you to recapture capacity for innovation and redeploy it elsewhere – all at a lower cost.  As a result, teams spend less time on delivering applications and more time on doing innovative work that adds real value to the organization.

The DevOps Journey

DevOps is a journey, not something you do, but rather a state you progress toward by implementing many different cultural and technical practices. Accelerating software delivery across deployment pipelines will enable the business to spend more time creating value by confidently delivering software innovation. And by fostering a high-trust culture, organizations will be able to establish a state of collaboration between the business, development and IT operations, ultimately contributing to better business outcomes.