What are your teams’ DevOps priorities today? Are they looking to improve continuous testing, increase observability, or advance their CI/CD pipelines?

Six years ago, I published a post on seven questions to help you prioritize your DevOps backlog. One year earlier, I published a simple formula to help create a prioritization score based on three pain points

• in managing the application in production,
• in delivering application changes required by the business,
• and the business importance of the application.

In updating the DevOps Workshop that I deliver for StarCIO, I created a slide listing the most common DevOps practices. I counted over forty! How did DevOps become so rich in methodologies – and so complicated?

As a CIO, I easily see the need for many of these practices, even in the simplest applications and technology stacks. How can you deploy without agile continuous planning, version control,  and basic data management practices? Even teams configuring SaaS workflows and developing with low-code platforms should have these practices in place.

Developing cloud-native apps or deploying AI models? These DevOps teams will need to have basic versions of at least half of these practices.

But if I put my business leader hat on and review all the DevOps jargon, I’m floored by all the work required to deliver applications to production frequently and reliably.

DevOps is not a free lunch

DevOps is needed if you’re developing custom software and want to “operate like a software company” with frequent deployments, reliable releases, automated scalability, and robust security. The alternative includes broken user experiences, chaotic deployments, defects released to production, bridge calls to resolve major incidents, security vulnerabilities that take too long to patch, and many other issues.

Low-code and no-code platforms will help your teams move up stack when these platforms include DevOps capabilities. For example, you may not need CI/CD or IaC in a no-code platform running in the cloud. However, you should still implement basic version control and invest in automated testing. The gotcha is when a low-code platform doesn’t natively support a needed DevOps practice, and dev teams must resort to manual workarounds. For popular enterprise SaaS, there may be a third-party DevOps tool that’s one of the few working with the SaaS, but they can be expensive.

Promoting DevOps practices without getting carried away

DevOps practices provide significant benefits for organizations looking to develop competitive, differentiating technology capabilities. Business leaders who don’t “get it” can attend one of my digital transformation workshops to learn more.

However, the other peril is overinvestment or investing too much in the wrong practices. For example, a few years ago, I asked whether continuous deployment is right for your business. I then followed up with another article specifying the prerequisites for continuous deployment.

Continuous deployment extends CI/CD and aims to automate code delivery to production environments. The practice provides huge advantages to SaaS companies that have the scale, sophistication, and customer demand to deploy new production versions daily or even hourly. However, it’s a significant investment to have the prerequisite environment standardization, continuous testing, and other disciplines to ensure frequent deployments do not undermine reliability or security.

Set realistic DevOps practice requirements

When I encounter DevOps teams aiming too high, I walk them back to reality by drafting a vision statement, documenting business requirements, and providing agile estimates around the implementation. I ask them to consider the underlying technical debt that will inflate the actual work above estimates. It doesn’t take long for these groups to recognize when costs and complexities outweigh the benefits.

Much like business initiatives and new end-user capabilities require prioritization, so does selecting DevOps practices. But even more importantly, DevOps practice leaders should propose a minimal reference architecture and requirements. Implementation is not a one-size-fits-all approach, and technology leaders should enable some self-organization on how and when to implement a practice.

Here’s the advice I shared in Digital Trailblazer:

Create one‐pagers for each role. One‐pagers to describe reference architectures, data models, customer personas, roadmaps, service level objectives, security fundamentals, user experience standards, and style guides—each with a context, scope, and authorities to evolve them over time. Use simple to understand, Twitter‐length language. Add pictures and diagrams where they truly simplify a thousand words.

Keep DevOps simple. Focus on minimal requirements, then add on where more advanced capabilities provide real business value.