Many organizations are taking steps to adopt devops best practices, investing in version control, continuous integration, automated testing, continuous delivery, deployment containers, infrastructure as code, centralized monitoring, and other approaches to automate and systematize aspects of managing applications and infrastructure.
The list of practices, tools, and maturity levels is growing and it’s no longer a trivial matter for devops teams and technology organizations to easily determine what areas to prioritize, what approaches are most viable, and what level of maturity is good enough.
For example, organizations doing a lot of application development may look to fully implement CI/CD (continuous integration and delivery) so that they can release code more frequently and reliably. But organizations that perform only a limited number of deployments a year may elect to automate parts of their deployment pipeline and then look to centralize monitoring to improve their response time to production incidents.
Devops teams have more practical choices as tools for AIops, managing microservices, automating security, , and other devops trends become mainstream. With that in mind, devops teams need a strategy to prioritize their efforts and level of sophistication on why, where, and how much to invest in any one area.
Here are seven questions to help determine your strategy.
1. Who are your customers and what are their priorities?
This question surprises many of the devops teams that I work with as they’ve never thought of their devops objectives and priorities as customer facing. But assigning a user persona and a separate buyer persona to every technology initiative and especially devops can lend clarity to where to focus, what problems need solving, which technology solutions to consider, and how best to implement automation.
Devops practices that aim to make development teams more efficient (such as CI/CD) are likely to be prioritized by software developers whereas AIops and centralized monitoring are more likely to be preferred by operational engineers. That’s why devops teams should also consider a buyer persona, or more specifically, the leaders in the organization who sponsor and invest in devops practices. If they aren’t specific on their strategic needs, then ask them directly.
2. What is your technology operating model?
This second question eludes many devops teams. Is the organization employing devops practices and culture changes to drive more startup-like behaviors and capabilities? Or is its greater priority to enable enterprise-like capabilities and performance indicators?
Here are some examples. Is your CI/CD driving at more frequent releases or more reliable ones? Are you trying to enable developers with cloud-native development sandboxes, or is it more important to have cookie-cutter infrastructure deployments to enable spinning up and down consistent development environments? Are you deploying basic health checks around the infrastructure and operations, or are more robust monitoring tests required to support expected performance and other site-reliability metrics?
The obvious answer is that many devops teams want all of the above. The practical answer is that each approach needs differing implementation and investment. Knowing the culture your organization is striving for can help set priorities and implementation options.
3. What are your operational deficiencies?
Another topic to address is the operational issues the technology department is experiencing. What are business leaders complaining about? Where are customers and users suffering? What areas in the technology organization are failing from an execution standpoint and can devops practices and tools drive operational changes and impact?
This line of thinking can help create a focus area. For example, organizations suffering from outages may look to deploy centralized monitoring and AIops; others that have experienced defect-plagued deployments may start with automated testing.
4. Where are you growing and scaling?
If it’s not operational deficiencies that drive devops practices, then consider what activities are growing and can benefit from more automation. Organizations that are adding development teams may look to invest in infrastructure as code so that it’s easier to spin up new development and test environments. Other organizations requiring portability so that applications can be deployed to multiple clouds or geographic locations may look to invest more in containers. If applications are becoming more mission critical and users are expecting higher service levels, then AIops may be an appropriate area to prioritize.
For larger organizations, this type of analysis may yield an all-of-the-above answer as different applications drive different needs. Combining the answers with an analysis of user needs and operational deficiencies should yield a clearer picture of priorities.
5. Where is there room to improve collaboration?
More established IT organizations look to devops to drive culture change. In these organizations the divide from software development teams who are under pressure to make frequent code deployments is a disconnect from the charter that operating teams have to ensure the reliability and performance of business operations. Devops practices that help balance these drivers can help teams find common ground and new ways to work together.
Look for dysfunctional areas or places where interactions between technology disciplines are stressful. This can often happen in change advisory boards where application deployments are reviewed for operational readiness. These meetings can often be stressful to developers who are not aware of all the requirements and risks, and even more difficult for engineering managers who must halt or delay deployments when applications haven’t addressed all the compliance and risk checks. Automating aspects of deployments can help standardize approaches and change an expected behavior to one that is automated in code.
6. Where is technical debt impacting daily operations?
Technical debt is a broad term capturing everything from code that needs to be refactored all the way up to end-of-life legacy systems that need to be replaced. Many technology organizations also use the term to highlight areas of their technology that are slowing development efforts or making it difficult to support business operations.
But technical debt isn’t just embodied in code and systems. It’s also a factor in how technology teams operate. For example, if support teams need to follow manual steps as they respond to an incident or request, it's probably a byproduct of technical debt. Complex operational procedures that are error prone often point to an area that should have been automated. Other areas with thin support coverage or that require hands-on steps done by only one subject-matter expert may point to a significant business risk or technical debt.
The question is whether these operations are better automated than documented, and where new devops tools can help simplify things.
7. What key performance indicators are you addressing?
Technology organizations should use metrics to evaluate their performance and illustrate where technology and practice improvements drive impact. Once basic devops practices are deployed, select and use devops key performance indicators (KPIs). This tool determines where new focus areas are needed and what level of maturity to target.
One KPI many development organizations focus on is frequency of application deployments. They may elect to automate more CI/CD pipelines with greater sophistication in order to enable more frequent deployments. But if they also see an increasing number of defects discovered in production (the defect escape rate), then they should invest more in test automation.
Similarly, organizations that experience frequent lengthy outages may elect to measure their mean time to recovery. Investments in centralized monitoring, AIops, automated testing, and infrastructure as code can all help improve this performance indicator.
If you’re using KPIs to drive priorities, then a key question to explore is whether the ones selected align with business need and address things that matter. KPIs should be the final tool for prioritizing devops but they should embody user needs, strategic priorities, deficiencies, growth considerations, and the other factors driving devops priorities.