How a connected DevOps toolchain can help you scale

As your organization scales its DevOps practices, your teams might find themselves using large, disparate—and disconnected—toolsets. This is a serious bottleneck that hampers visibility and efficiency across the enterprise. You need to remove it as early as possible to avoid delays in delivery to customers.

But how do you solve this problem? The first challenge is understanding that you have a problem at enterprise scale. The second is to deal with it. Here’s how to get started.

How to Build a DevOps Toolchain That Scales

Identify the problem

Many organizations grew their DevOps practices from one or two teams, which they then expanded across the rest of the organization. Because that growth was organic, it’s not uncommon to find teams working alongside each other that use different toolsets. For individual teams, it doesn’t matter because each is working efficiently using the tools that work well for them.

But as you scale DevOps, the problem of not having a standardized DevOps toolchain becomes more apparent—and more critical. When teams need to work with teams from a different part of the organization, there are often considerations that prevent them from forming agile "feature teams" that can deal with the end-to-end implementation.

Since they must continue to work as separate teams from different parts of the organization, they will need to manage the interface between the two teams, collaborating and sharing resources and data. If the two (or more) teams are using different tools, especially if the tools aren’t integrated with one another, coordinating across the teams will consume a disproportionate amount of time.

But even at the local level, it's common to see members of the same team using different tools to do the same thing. It’s not by design—this is usually a holdover from when the team members were on previous teams. When they left to join yours, they brought their favorite tools with them. Unfortunately, even if the tools are integrated with one another, your team isn’t working as efficiently as it could when different team members use different tools and processes to perform the same task.

There are two ways to solve this problem: You can pick one toolset and mandate its use across the whole organization, or you can continue to let the teams use their tools of choice and add the necessary integration glue to help them share more efficiently. 

Why a single DevOps toolset doesn't work

If everyone uses the same tooling, the problem of disparate toolsets disappears. But it’s unlikely to solve the problem in larger organizations, for two reasons:

  • You will need to acquire a new set of licenses for the toolset of choice, but the teams might still be paying for their existing toolsets. Across a large organization, that can work out to be extremely expensive, and it will take a long time before there’s a positive return on investment—if ever.
  • If you mandate use of a new toolset, all the teams that don't currently use it will have to disconnect their current tools and replace them with the new ones. This is likely to involve a major refactoring of the code and the infrastructure, and assumes that the new toolset offers similar functionality to the old one.
  • Your teams will need to learn the new tools. That takes time, you can expect new defects and delays as your teams climb the learning curve, and there’s no guarantee that the newly minted toolset will actually deliver on its promise.

This universal DevOps toolchain approach might work for small organizations that are just getting off the ground, but enterprises with big investments in tools and processes won't want to just rip, replace, and pivot the entire organization around a new toolset.

The solution: Create a connected, inclusive system to support existing tools

A more inclusive approach is to give the teams the option to use whatever tools are best for them and their pipelines, but add a DevOps toolset that can integrate with those tools while providing the communication and collaboration they need—all without causing unnecessary delays. Here’s why this approach is the way to go:

  • Integrated DevOps toolsets are available in the cloud and come pre-configured with the necessary integrations. You can use them immediately, and it’s easy to add and train new users adoption spreads.
  • These toolsets typically integrate with the tools that your teams are already using, so you don’t need to replace any existing tools or update code and infrastructure (although teams can do so if that works better for them). Teams also have the flexibility to replace tools later if they prefer.
  • A good DevOps toolset includes a dashboard showing aggregated information fed in from all tools in the delivery pipeline, so all stakeholders can immediately understand the status without interrupting the process
  • These toolsets usually support new processes and grow with you as your organization adopts organizational frameworks, such as the Scaled Agile Framework, to help your teams scale.

This approach offers flexibility while keeping your organization connected and information flowing freely.

Let the teams decide

Application delivery teams should have the freedom to choose the tools that work best for them, but that approach only works if they can still communicate and collaborate with the rest of the organization—even when others are using different tools and processes.

To minimize disruption as your organization’s DevOps practices grow, bring in a connected DevOps toolset that sits in the middle, providing integrations between the teams and the existing tools that make up your delivery pipeline.

This will give your teams and the organization the best of both worlds: The teams can continue to use the best tools for the job, and their work becomes visible across the organization. Your teams will be able to communicate with one another effectively, and your customers will get the features they need without delay.

For more on this approach, read my whitepaper, "How to Build a DevOps Toolchain That Scales."

Topics: DevOpsDev & Test