How A Single Platform Can Improve DevOps and ITSM Collaboration

In 2011, Marc Andreesen published his groundbreaking essay in the Wall Street Journal, “Why Software is Eating the World.” Nine years later, this observation holds truer today than it did then. We live in an increasingly technology- and software-driven world. As the world at large becomes inextricably software dependent, the world of ITSM has grown increasingly complex. ITSM teams find themselves facing more incidents than ever before, while resolving them is increasingly complex. Key drivers for this complexity include the transition toward more federated application design and the use of microservices; an increased number of mission-critical, SaaS business systems—living both behind and outside the firewall—that need to talk to each other; and a deep understanding of and appreciation for how these business systems drive value—and profits—for organizations.

How Federated Application Design and the Use of Microservices Drive Complexity

Organizations today are investing heavily in application design, driven in part by consumer demand for improved performance, functionality, and reliability. Increasingly, organizations are turning away from monolithic applications and embracing a more federated approach to application design using microservice architecture. While microservices bring undeniable benefits—and a big one is that if a microservice goes down, it does not necessarily take down the entire application—they contribute to the complexity and difficulty of diagnosing issues.

ITSM professionals, particularly support engineers with perhaps ten or so years of experience, may recall what it used to be like to get a page that triggered an incident response. While the calls were always likely to cause trepidation, at the time, the response was often scripted. Start with the application itself. Next, move on to the app server, then the physical server. If there were no issues with those layers, then the problem was likely network or database related—both which were likely some other team’s concern. Different teams wholly owned different domains and would handle different types of investigations independently.

That approach has changed significantly as microservices have been introduced. First, multiple teams, in some cases a half-dozen or more, may need to be called in up front just to determine what application is causing a given issue. Further, the issue may not be confined to one microservice. Instead, the issue may be caused by how two or more microservices are talking to each other. So, to diagnose an issue, much less resolve it, may require significant, cross-functional collaboration and communication before teams can drill into and resolve the actual issue.

At the same time, customer expectations are much higher. The kind of outages that were tolerated several years ago when monolithic applications dominated the landscape, are simply too disruptive and too costly now. Taking an entire system down and restarting it is no longer a viable solution—the cost is too great, both in term of customer trust and the bottom line.

How Organizational Reliance on an Increased Number of Business Systems Drives Complexity

According to Okta’s 2020 Business at Work report, respondents to its survey indicate that their organizations use an average of 88 different applications, with 10% of respondents saying their organizations use more than 200. Clearly, organizations today rely on an ever-growing number of applications to power essential parts of their business. It is important to note that among these critical tools are security applications that protect organizations from ransomware, malware, phishing scams, and other IT security threats.

Adding to the complexity of the situation, some are running within the firewall and others outside of it, and many of them need to talk to each other by exchanging information and data. An organization, for example, might have Salesforce hosted externally talking to an ERP hosted on the inside talking to a set of project tools hosted both externally and internally. With these types of complex chains of tools, if an issue occurs, it is not necessarily confined—the effects of that issue ripple downstream.

For the ITSM teams responsible for keeping these tools running and resolving issues, the landscape is infinitely more complex and the stakes are infinitely higher than ever before. Individual ITSM team members would be hard-pressed to be an expert in every domain that they are trying to resolve an issue with, and yet there has never been a greater understanding of the business value of each of these tools.

Back to Top

The Atlassian version of the DevOps infinity loop below (Figure 2) shows how, by implementing Jira Service Management (formerly Jira Service Desk), the Atlassian tools already in use daily by development and operations teams across the world can bridge the gap between ITSM and DevOps at the critical feedback stage.

To better understand how the Atlassian platform can streamline the handling of incidents while pushing feedback into the DevOps cycle, we’ll walk through a hypothetical example of an incident and describe how Atlassian tools can be used to streamline management and resolution of the incident while creating visibility into the incident for DevOps teams.

A Hypothetical Incident

When an incident occurs, information will likely be coming in from a number of sources: users opening tickets, servers throwing errors, applications throwing alerts—even emails coming in. The first step toward resolving these issues is to take in all that noise and make sense of it. That’s where Opsgenie can help. Opsgenie recognizes an incident and gathers all the information, feeding it into a single place, thereby minimizing the noise and enabling the people charged with resolving the incident to focus on the work at hand.

Because Opsgenie is now incorporated into Jira Service Management (JSM), an alert is automatically generated in JSM. Users going to the service desk will see this alert and can click on the notification to learn more.

This takes them to Statuspage where the user community can find more in-depth information about what is happening and follow along from wherever they are, if they choose to do so. Statuspage can even pull in information from relevant third-party applications as necessary. For instance, if Salesforce is experiencing an issue, an organization’s sales team can see that information in Statuspage

.As the incident progresses, Statuspage continuously identifies changes and automatically updates the incident status. This allows internal teams working on the incident to focus on tasks that are critical to resolving it. In addition, end user visibility into the issue results in a better customer experience, one that—despite the incident—engenders confidence in the organization through transparency and responsiveness.

DevOps teams working in the Atlassian platform will likely be using Jira as the command center to orchestrate their work. Since JSM sits on top of Jira, they can be @ mentioned or assigned to the incident so they receive updates. It’s much more straightforward to collaborate on the same platform rather than trying to integrate two platforms or multiple applications and keep them in sync.

Once the incident has been resolved, the status warning goes away. And after that, even the incident postmortem can be done on Confluence. Since everyone is operating on the same platform, the right teams can easily be pulled in, and issues and incidents can be linked so everyone has consistent, complete information to work from.

Ultimately, a single platform with both DevOps and ITSM tools, like those from Atlassian, creates a fully-connected environment that simplifies the complexity ITSM teams face, streamlines incident resolution, and drives end user feedback and insight from the service desk into the DevOps process where those teams can act on it.

Back to Top