This article draws on perspectives originally published at bmchelix.cio.com (2019) and quotes from industry practitioners in the ITSM and DevOps space.
The Growing Tension Between DevOps and ITSM
Enterprises are steadily adopting DevOps as development and operations teams push to deliver and improve applications faster. But this momentum creates an organizational friction point: development teams and IT operations teams often rely on parallel—yet distinct—toolchains, processes, and cultural norms.
A common example is incident tracking. A DevOps team may log and manage incidents inside a developer-native tool such as Jira, while the IT Service Management (ITSM) function runs a separate system entirely. The result is duplicated effort, missed context, and unnecessary risk.
“So what you end up doing is forcing developers to use some process that’s outside of their norm in order to address issues.”
Donna Knapp, Curriculum Development Manager, ITSM Academy (via Tech Beacon)
The answer is not to force one team to abandon its tools. Instead, the industry is moving toward integrating DevOps and ITSM toolchains so that both teams can work in familiar environments while sharing data and workflow automation.
Automation: The Common Ground
Automation is arguably the single most important capability that DevOps and ITSM share—and the strongest basis for integration. In the DevOps model, the software delivery lifecycle (build, integration, testing, deployment) is automated to achieve both speed and consistency. Manual handoffs are replaced by pipelines that run with minimal human intervention.
ITSM has traditionally relied on manual service delivery—approvals via email, change tickets filled in by hand, and linear review processes. Applying automation to ITSM workflows—change requests, issue tracking, approvals—produces the same benefits it delivers in DevOps: faster throughput, fewer errors, and a better experience for the end user.
When DevOps automation pipelines and ITSM automation tools are connected, value compounds. Changes that originate in a developer’s tracking system can automatically trigger the appropriate ITSM workflow, and vice versa, with no manual re-entry of information.
“In this multi-cloud world, most enterprise organizations want to more tightly integrate IT service operations with DevOps tools.”
Nayaki Nayyar, President of Digital Service Management, BMC
The Change Management Collision—and How to Resolve It
Change management is historically one of the sharpest points of conflict between DevOps and ITSM cultures. Traditional Change Advisory Boards (CABs) were designed for infrequent, high-risk changes reviewed in scheduled meetings. DevOps teams may push dozens or hundreds of changes per day. A manual CAB process simply cannot keep pace.
“Change management has often been where DevOps and ITSM collide. The stereotypical Change Advisory Board must radically revise its approach to be in sync with the enormous amount of change that DevOps can produce in a day.”
Roy Atkinson, service management market analyst, HDI
One architectural solution is automated risk scoring. Rather than routing every change through a human review board, an integrated ITSM platform can calculate a risk score for each change automatically—taking signals from the originating Agile tool (such as Jira or Azure DevOps) and generating a corresponding ITSM change request. Risk data then drives an intelligent routing decision:
- Low-risk changes can be auto-approved and flow directly into the deployment pipeline.
- Higher-risk changes are flagged for human review before deployment proceeds.
This approach lets organizations sustain the velocity that DevOps demands while maintaining the governance that ITSM exists to provide.
Practical Integration Patterns: ITSM and DevOps Toolchains
When an ITSM platform is integrated bidirectionally with developer tools, several workflow patterns become possible without requiring either team to leave their preferred environment:
- Developer creates an issue in Jira → A corresponding change request, incident, problem record, or work order is automatically created in the ITSM system. ITSM teams work in their tool; developers work in theirs.
- Change coordinator raises a change in ITSM → A corresponding user story or task is automatically created in the Agile development tool. Developers can view change context without leaving Jira.
- Automated incident-to-change linking → When a production incident is detected, integration can automatically link or create the associated change or problem record, reducing mean time to resolution (MTTR).
The key principle is bidirectional synchronization: neither team should have to duplicate data entry or context-switch into an unfamiliar system just to satisfy the other team’s process requirements.
Self-Service Provisioning as a DevOps Enabler
Self-service provisioning is rapidly moving from a nice-to-have feature to an operational requirement. The 2018 State of DevOps Report indicated that organizations that reach higher levels of DevOps maturity typically secure cross-departmental commitments—including from ITSM—to provide automation and self-service capabilities to engineering teams.
A unified service catalog—accessible to both IT staff and end users—delivers several concrete benefits:
- Developers can provision environments, request access, and obtain tooling without waiting for manual fulfillment queues.
- ITSM teams gain visibility into what is being provisioned and by whom, preserving audit and compliance requirements.
- End users experience a consumer-grade, single-pane-of-glass interface rather than navigating multiple portals or raising tickets through email.
What a Converged DevOps–ITSM Model Looks Like
When change management, DevOps toolchain integration, and self-service provisioning are addressed together, the result is a service management model that is both more flexible and more reliable:
- Speed: Automated workflows eliminate manual handoffs and approval bottlenecks.
- Visibility: Shared data between ITSM and DevOps tools gives all stakeholders a consistent view of what is changing and why.
- Governance: Risk-based automation ensures high-risk changes still receive appropriate scrutiny without slowing low-risk deployments.
- Developer experience: Teams work in their native tools rather than being forced into unfamiliar ITSM interfaces.
- ITSM relevance: Service management evolves from a gatekeeper function into an enabler of engineering velocity.
Key Takeaways
The integration of DevOps and ITSM is not simply a tooling decision—it represents a cultural and organizational evolution. ITSM frameworks such as ITIL are themselves evolving (ITIL 4 explicitly addresses DevOps alignment) to meet the pace at which modern software delivery operates. Organizations that treat DevOps and ITSM as complementary rather than competing disciplines are best positioned to deliver reliable, fast, and auditable software delivery at scale.
If your organization is beginning this journey, start with the highest-friction integration points: change management approval flows and incident-to-ticket synchronization. Automation in those two areas alone typically yields measurable reductions in lead time and manual effort before any broader platform consolidation is required.