DevOps Practice

Overcoming the Awkward Teen Years of DevOps Adoption with Process-Centric IT

DevOps adoption is all over the map. Just last year, xMatters and Atlassian surveyed more than 1,000 companies on their DevOps maturity and found only 65 percent were getting the benefits from their DevOps initiative that they expected. Sixty-six percent described their maturity level at or below intermediate. And another 1,000 organizations were excluded from the survey because they didn’t have a DevOps initiative at all!

With so much misalignment and insecurity, you might say that organizations are going through their awkward teen years. While many businesses recognize the importance of DevOps and agile methodologies, most are still struggling to truly embrace them, and therefore reap the real benefits. So what’s holding us up? The answer is people issues. Gartner recently surveyed organizations about their biggest barriers to DevOps adoption, and resistance to change was No. 1.

Becoming Process-Centric

It’s a complex challenge, but it does have a solution. The best way to enable continuous delivery while supporting legacy initiatives such as major incident and IT service management is to ensure your IT teams are process-centric. This entails mapping out the business processes required to achieve IT objectives and identifying the data, tools and people needed to optimize existing workflows while driving real change. If you’re not sure where to start, here’s how you can get started.

Map Out Essential Processes

IT teams frequently make the mistake of buying a checklist of tools they believe are necessary, but this can make it difficult to know where to start when evolving IT to support continuous delivery. Without a business process strategy in place, it’s virtually impossible to integrate your tools and optimize collaboration between teams.

Enable IT to be a driver in achieving business goals by clearly defining your business objectives and the activities that directly support them, as well as managed entities and available response types. For instance, common business objectives include increasing the frequency of code releases, reducing the number and severity of major incidents, minimizing lead time for product updates and improving SLA standards of uptime.

Identify and Connect Your Process Ecosystem

After mapping out your business processes, you’ll need a connected ecosystem of data, tools, people and teams to drive them forward. This ecosystem is possible only if you understand the different types of contextual data you need for each managed process, from monitoring insights to system logs to stakeholder communications.

Next, choose the tools to manage the processes and data flow. For instance, application performance monitoring and management, ChatOps and issue tracking are all common tool types. Then, pinpoint the people (or teams) that need to be involved in each type of process so that you can keep the right people informed—no more, no less.

Finally, you should ensure that your teams within development, operations and support have an efficient and streamlined way to collaborate so that processes always advance to completion.

Operationalize Steps for Collaboration and Resolution

Now let’s get more specific. What are the steps required to facilitate collaboration and drive resolution? By defining these steps, you can optimize and effectively templatize processes that can be reused, thereby improving both consistency and efficiency each time a recognizable  incident comes into play.

For each process, start by outlining the tasks necessary to resolve the issue, then detail the tools needed and the personnel or teams that should be involved. Repeat this for all of your processes to define the necessary technology investments.

Automate and Curate Manual Work

Operationalizing processes improves efficiency to a certain degree, but you can go a step further to really maximize the benefits. This is where you can leverage both automation and curation of manual work. For each managed process, drill down at the task level to determine whether you can either fully automate or, if human intervention is needed, efficiently curate work.

For instance, routine tasks that have a defined set of triggers and can use software-driven logic to determine and execute on next steps can be fully automated, whereas tasks that have a defined set of triggers but require that human intervention determine which next steps should be curated. There are, of course, different levels of curation and automation based on associated triggers and response types, so you’ll need to gauge these and plan accordingly.

Extract and Archive Contextual Information

It’s important to maintain a repository of information on your business processes and how they are handled. This kind of data gives you complete visibility into issues as they progress, and ensure you’re taking consistent, proven responses to similar situations when they arise in the future. Some stakeholders will, of course, also need access to this information.

The way to maintain this repository is to understand the unstructured data (such as FYI communications) versus structured data types (such as ChatOps) managed within each process. Once these are identified, you can map the unstructured data into structured data. The rule of thumb for aligning stakeholders is that the business and customers require data from structured sources; they’re looking for the information concerned with status and real business impact.

In contrast, subject matter experts will often rely on unstructured data. They benefit more from the in-depth insights from system and application logs, performance metrics, and other essential data points to help them assess, resolve and manage situations.

In Conclusion

The journey to becoming process-centric may seem daunting, but there is a proven approach that can guide you toward the dream of becoming a mature DevOps organization. Figure out which processes you can automate, which require human intervention, and be sure to let your teams work within the systems they know and trust to ease the resistance to change.

One persistent danger is that multiple systems can create silos of data that stand in the way of collaborative work. A process-centric IT organization with integrated systems can help move data to enable collaboration, more informed decisions and better outcomes. And nothing takes the awkwardness out of a teenager like better outcomes.

Kristin Apgar

Kristin Apgar

Kristin is responsible for technical sales cycles from online demonstrations to security proposals at xMatters. She has over 15 years in the technical software sales industry. Previously, Kristin was an engineer with Skytap and ResultsPositive.

Recent Posts

To Devin or Not to Devin?

Cognition Labs' Devin is creating a lot of buzz in the industry, but John Willis urges organizations to proceed with…

29 mins ago

Survey Surfaces Substantial Platform Engineering Gains

While most app developers work for organizations that have platform teams, there isn't much consistency regarding where that team reports.

16 hours ago

EP 43: DevOps Building Blocks Part 6 – Day 2 DevOps, Operations and SRE

Day Two DevOps is a phase in the SDLC that focuses on enhancing, optimizing and continuously improving the software development…

18 hours ago

Survey Surfaces Lack of Significant Observability Progress

A global survey of 500 IT professionals suggests organizations are not making a lot of progress in their ability to…

18 hours ago

EP 42: DevOps Building Blocks Part 5: Flow, Bottlenecks and Continuous Improvement

In part five of this series, hosts Alan Shimel and Mitch Ashley are joined by Bryan Cole (Tricentis), Ixchel Ruiz…

18 hours ago

Is Backstage the Right Internal Developer Portal for You?

There has never been a better time to be a software developer. There is a language and framework to solve…

23 hours ago