Published on 10 June 2019 by

When I started the State of DevOps survey over seven years ago, the landscape looked very different than it does today. The organizations we were working with were struggling with deployments, the functional boundary where Dev and Ops painfully collide. The pressure to deploy faster and more frequently was a big driver behind DevOps.

As more organizations started adopting DevOps and practices became codified and broadly shared, we saw the low performers start to catch up with the high performers when it came to deployment frequency; a good sign that this was a solved problem. But of course, deploying faster and more frequently doesn’t necessarily mean you’re deploying better. And on the flip side, many organizations we work with today actually can deploy much faster and more frequently than the business allows.

Last year, we broke new ground with our report by focusing on the DevOps journey itself. We wanted to answer two burning questions that we kept getting asked over and over again: “How do we get started with DevOps?” and “How do we expand our pockets of success?” From those core questions — and a lot of statistical analysis — emerged the DevOps Evolutionary model (or simply, the DevOps Model, as it’s more commonly known). The model deepened our understanding of how organizations adopt and scale DevOps practices. From there, we set out to provide prescriptive and pragmatic guidance, based on the real-world experience of our authors (both in the trenches and from working directly with IT organizations), to help organizations evolve on their journey.

The importance of normalization and standardization

The 5 stages identified in the 2018 State of DevOps Report

In the 2018 State of DevOps Report, our analysis revealed five stages of DevOps evolution and the critical practices at each stage that help you achieve success and progress to the next phase of your journey. The first two stages of that journey are normalizing the technology stack and standardizing and reducing variability. Normalization is about getting your arms around the chaos and understanding what you have so you can eliminate the one-offs that create management complexity. Standardization is about placing bets on the technologies you’ll use in the future.

Nigel and I have been meeting with and conducting DevOps Workshops with very large, very complicated enterprises and the majority of them are stuck somewhere in between Stage 1 and Stage 2. Standardization is always a sticky topic because everyone recognizes the value of standardization, but often, no one person in the organization really has the power to enforce the standards. And then there are always those pesky dev teams that want to use their own special stack. We advise starting small with the tools and platforms within your direct purview before attempting to standardize your entire software delivery toolchain across hundreds of teams.

A free resource to help you standardize

To help you do that, we’re offering a new resource to help rationalize and standardize your toolkit. It’s a simple spreadsheet that lists key capabilities so you can see where there are overlaps between the tools you’re using today.

You can access the spreadsheet here, and then either make a copy of the Google sheet (File < Make a copy) or download it into a Microsoft Excel file (File > Download as). Then it’s all yours to fill in the tools you use, mark what their capabilities are, and note the overlaps where there may be opportunity for standardization.

Screenshot of the DevOps resource to help you standardize your toolkit

A lot of our customers have found this to be useful so we wanted to make it available to everyone. This one happens to focus on infrastructure automation, but we plan to build out more resources in the future and would love to hear your ideas on what would be most useful. Feel free to email us at [email protected] with your ideas!

Alanna Brown is senior director of product marketing at Puppet and was the original creator of the State of DevOps Report and a co-author since its inception in 2012.

Learn more

Share via:
Tagged:
The content of this field is kept private and will not be shown publicly.

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.