I like to ask DevOps teams and engineers what should be a simple question, “What is your devops strategy and what are your priorities?”The answer I get is often a mix of what they are working on now (often CI/CD) and a word or two about the importance of a DevOps culture. I rarely get an answer that sounds like the leadership, team or engineers have articulated a strategy and roadmap.
And that can lead to conflicting priorities and approaches. Since many DevOps practices are driven “bottom-up” – which is something good as it aligns the start of the program with the people and processed that can benefit the most – maturing devops does need a strategy if it will be applied with multiple teams or across an organization.
Why a DevOps Strategy?
There are a few reasons why developing a developing a strategy is important
- Aligning on why DevOps
- Establishing startup versus enterprise DevOps mindsets
- Roadmapping devops priorities
Let’s looks at these three reasons today
Aligning on why DevOps
Many in IT get devops priorities right away. They’ll see the benefits in automating build, integration, and deployment pipelines (CI/CD), or automating infrastructure configurations with Infrastructure as Code (IaC).
But will they align on what KPIs they are targeting? Do they have a sense of what done is and what level of automation is good enough? There’s lots to automate and while application deployments and server configuration are relatively easy, automating testing, database changes, and cloud architectures are more complex. DevOps engineers require some guidance on what areas to focus on and what level of automation drives the most benefits. An articulated DevOps strategy should help define it.
But the strategy should also help align those in and out of IT on the what and why of DevOps. To them, DevOps may be a mystery, a black hole of effort, or something they only hear about through articles and conference presentations. Making sure these groups understand why DevOps is a priority is important because it rarely gets executed in a bubble without others addressing technical debt and making changes to applications to take advantage of DevOps capabilities.
Establishing your organization’s DevOps mindset
In the Driving Digital Workshops that I run on DevOps, I ask participants whether their organizations should be more like startups, or, are they trying to find their way to more enterprise-like standards?
Startup attributes include frequent releases, failing fast, and having infrastructure autonomy while enterprise attributes include standard infrastructure configurations, DevSecOps (security), and more test driven practices.
I always get a mixed answer with some pulling toward startup approaches and others pulling toward more enterprise-like behaviors.
Left unaddressed, these misalignments can slow progress or create blocks. Worse case, instead of DevOps aligning organizations, it pulls them apart!
A strategy helps define priorities, motivations, and characteristics. For example, continuous deployment may not be the right CI/CD target for many applications. Centralized monitoring may be more important for organizations migrating to multi-cloud environments. Organizations will take different approaches to structure Dev and Ops team.
Teams will not know this on their own unless their id a defined strategy.
Roadmapping DevOps priorities
Ask the DevOps teams who their customer is, ie, who their buyers and who their target end users are, and you’re likely to get some raised eyebrows.
If you ask them their priorities beyond their immediate focus, you’re likely to get multiple answers – and some priorities unanswered.
In addition to defining buyer and user personas, articulating priorities ensures that leaders know that a DevOps initiative requires an ongoing investment. It’s not one capability – it’s multiple. Each capability has an MVP and additional work to improve or expand it to support new use cases. Each capability is built on one or more technologies that have their own upgrade and support lifecycles.
So DevOps capabilities need an agile approach to plan, build, and release. But that’s another post!
Leave a Reply