Showing results for 
Search instead for 
Did you mean: 
Create Post

Why Choosing a One-Size-Fits-All Solution Won’t Work

Level 9

In my previous post, we talked about the CALMS framework as an introduction to DevOps, and how it's more than just “DevOps tooling.” Yes, some of it is about automation and what automation tools bring to the table, but it's what teams do with automation to quickly create more great releases with fewer and shorter incidents. Choosing a one-size-fits-all solution won't work with a true DevOps approach. For this, I'll briefly go into CALMS (but you can read more in my previous post) and the four key metrics to measure a team's performance. From there, we'll look at choosing the right tooling.



Image: Atlassian,

Let's quickly reiterate CALMS:

  • Culture
  • Automation
  • Lean
  • Measurements
  • Sharing

These five core values are an integral part of high-performing teams. Successful teams tend to focus on these areas to improve their performance. What makes teams successful in the context of DevOps tooling, you ask? I'll explain.

Key Performance Metrics for a Successful DevOps Approach

Measuring a team's performance can be hard. You want to measure the metrics they can directly influence, but avoid being overly vague in measuring success. For instance, measuring the customer NPS involves much more than a single team's efforts, so that one team's efforts can get lost in translation. A good methodology of measuring DevOps performance comes from DevOps Research and Assessment, a company that publishes a yearly report on the state of DevOps, “Accelerate: State of DevOps 2018: Strategies for a New Economy.” They recommend using these four performance metrics:


  • Deployment frequency: how often does the team deploy code?
  • Lead time for changes: how long does it take to go from code commit to code successfully running in production?
  • Time to restore service: how long does it take to restore service after an incident (like an unplanned outage or security incident)?
  • Change failure rate: what percentage of changes results in an outage?

Image: 2018 State of DevOps Report,

These metrics measure the output, like changes to software or infrastructure, as well as the quality of the output. It's vague enough to be broadly applicable, but concrete enough to be of value for many IT teams. Also, these metrics clearly embrace the core values from the CALMS framework. Without good post-mortems (or sprint reviews), how do you bring down the change failure rate or time to restore service? Without automation, how do you increase deployment frequency?

Choosing the right support infrastructure for your automation efforts is key to increasing performance, though, and a one-size-fits-all solution will almost certainly be counter-productive.

Why The Right Tool Is Vital

Each team is unique. Team members each have their own skills. The product or service they work on is built around a specific technology stack. The maturity of the team and the tech is different for everyone. The circumstances in which they operate their product or service and their dependencies are incomparable.

So what part of that mix makes a one-size-fits-all solution fit? You guessed it: none.

Add in the fact that successful teams tend to be nimble and quick to react to changing circumstances, and you'll likely conclude that most “big” enterprise solutions are incompatible with the DevOps approach. Every problem needs a specific solution.

I'm not saying you need to create a complex and unmanageable toolchain, which would be the other extreme. I’m saying there's a tendency for companies to buy in to big enterprise solutions because it looks good on paper, it’s an easier sell (as opposed to buying dozens of smaller tools), and nobody ever got fired for buying $insert-big-vendor-name-here.

And I'm here to tell you that you need to resist that tendency. Build out your toolchain the way you and your team sees fit. Make sure it does exactly what you need it to do, and make sure it doesn't do anything you don't need. Simplify the toolchain.

Use free and open-source components that are easier to swap out, so you can change when needed without creating technical debt or being limited by the big solution that won't let you use the software as you want it (a major upside of “libre” software, which many open-source is: you’re free to use it in a way that you intend, not in just the way the original creator intended).

Next Up

So there you have it. Build your automation toolchain, infrastructure, software service, or product using the tools you need, and nothing more. Make components easy to swap out when circumstances change. Don't buy into the temptation that any vendor can be your one-size-fits-all solution. Put in the work to create your own chain of tools that work for you.

In the next post in this series, I'll dive into an overview and categorization of a DevOps toolchain, so you'll know what to look out for, what tools solve what problems, and more. We'll use the Periodic Table of DevOps tools, look at value streams to identify which tools you need, and look at how to choose for different technology stacks, ecosystems, and popularity to solve specific problems in the value stream.


Nice write up

Level 16

Thanks for the write up.

Level 12

Great story, it's funny as my Brother-in-Law (Government worker in Justice Dept) has a saying that seems to apply to many of these One Size fits everyone plans of operation. He refers to them as "One Size Fits no one" . Seems very applicable, not just to Gov't policy but many times in IT tech too.

Level 12

Now how do we get management to accept that one size fits all isn't in their best interest?

I still can't get them to understand that a SQL guy shouldn't be assigned to rewrite routing tables because the router guy was assigned to work on a firewall audit, because the firewall guy was assigned to work with the SQL team on evaluating cloud vs cluster options and doesn't have time.

Level 14

Thanks for the article! 

Level 20

Geesh Atlassian is trying to rewrite/rename everything it seems like these days... I've had to deal with a bunch of their tools lately.  I will say this... they're fairly stable when run on linux so that's good.

Level 14

In my experience "One size fits all" just doesn't fit me (or any of the 22 different organisations I have worked for).

Level 13

Interesting post.  Thanks.  Although I totally agree with the don't buy the one big tool approach, I've also seen where the DevOps folks started chasing every new technology just because it was cool or everyone was doing it (or worse, because they wanted it on their resume).

Level 16

"I've also seen where the DevOps folks started chasing every new technology"


Level 12

I have worked for companies where freeware/open source solutions are frowned upon because, "who would we go to if they software breaks." The management liked having a contract to fall back upon to get outside support, so the one-size-fits-all solution is all that was available. If management would trust their engineers then they could save the company money and potentially improve moral in the process.

Level 15

Fortunately, I have experience first hand at multiple companies the joys of building toolchains that are not the One Size Fits All ideology but more along the lines to actual collaboration between the tools.  This has allowed the teams to develop organically to solve and maintain the solutions without imposing the rules that your work must fit the tools. 

I am very much enjoying this series.  Thanks!!!

Level 12

Oh I hear ya... So many companies' IT policies are created and run by those who have solid Business knowledge but no real IT knowledge/background. They pay good money to hire the IT professionals but then many times refuse to listen to those with the experience/knowledge. It's frustrating, especially when your work ethics are focused on doing the best job possible for your Employer and Clients. I have never understood that. If I approach a professional in another field or industry, I would follow the advice given, otherwise why engage an expert?

Level 7

Thank you for the nice write up!

One only has the option for one-size-fits-all when all are one size.  It's nice that SW allows us to pick & choose modules, add more APEs and Web Servers.

My network is more than three times larger now than it was when I started with NPM and NCM back in 2004.  NAM allows me to grow and fit the need.

„Rightsizing“ your infrastructre/solution is the key to success. It might be the same tool, but implemented in different ways.

Level 11

Thanks for the post, good read.