DevOps and IT service management (ITSM) don’t mix, right? Wrong! DevOps and ITSM practices are part of the same spectrum of business and technology activities, with them connected by a continuous delivery pipeline. And it’s possible to integrate a DevOps pipeline and the ITSM change advisory board (CAB) without them getting in the way of each other.
By following this blog’s advice, DevOps and the CAB can amplify each other’s unique approaches to help create a high-performance IT organization.
DevOps vs. ITSM
DevOps is a culture and movement – less about the IT, more about applications and business – that’s focused on speed, agility, uptime, and resilience. It asks: “Why can’t you go faster, make more changes, AND have better uptime?” To DevOps practitioners, more change simply means better service, not more outages.
ITSM has been around since the 1980s and, just like DevOps, it’s not about IT – it’s about service and business. The comparisons with DevOps are obvious, the contrasts are in how DevOps and ITSM goes about their business. But they both want to create high-performing IT organizations.
If you look at good industry reports such as the Puppet State of DevOps 2016 you can find solid business reasons as how DevOps will transform your IT teams into a high-performing organization, that:
“High-performing organizations decisively outperform their lower-performing peers. They deploy 200 times more frequently, with 2,555 times faster lead times, recover 24 times faster, and have three times lower change failure rates.”
DevOps AND ITSM
Rather than being at odds with one another, DevOps and ITSM practitioners have something in common – the provision of better service and outcomes to customers. But perhaps they approach it from opposite ends of the spectrum, and this confusion is where the DevOps vs. ITSM arguments start.
So this blog brings those two ends together using the CAB as a focal point, focusing on.
- Understanding how the DevOps pipeline connects to ITSM change management
- Making DevOps more CAB-friendly
- Making the CAB more DevOps-friendly
1. Understanding How the DevOps Pipeline Connects to ITSM Change Management
If you visualize DevOps feeding into ITSM change management, then the product-based pipeline that connects them is a spectrum of activities – a value chain that feeds around clockwise.
The key to this working is to prevent the CAB being a speed-bump in the way of activities. And instead to give the CAB non-intrusive access to the DevOps pipeline while giving DevOps access the CAB perspective of the wider organization.
This is a juncture where DevOps can work well with ITSM. The CAB is aware of organization-wide change and knows about other activities outside of this single-product pipeline. If you need to know what other IT services this product can affect, the CAB can be that glue.
2. Making DevOps More CAB-Friendly
The phrase “Change is like the brakes on a car, it lets you go faster” was coined by the Visible Ops Handbook authors. And the CAB is the probably the most obvious example of a brake! There’s no CAB in DevOps, so why introduce one? Where would it fit?
The DevOps pipeline is a process focused on one thing: deploying an application while removing risk from the application delivery process. This is also what the CAB wants – quick delivery and less risk. The difference is that the CAB is aware of the business context outside of the DevOps pipeline.
The combination of DevOps and the CAB is of real business benefit, as long as one doesn’t negatively impact the other – such as the CAB blocking every DevOps pipeline run.
One way to connect DevOps and the CAB is by connecting DevOps automation tools with the ITSM ticketing and change management systems. DevOps pipelines are flexible, programmable, automated, and highly integrable; with typical integrations from DevOps pipeline to CAB tools including:
- Notifications to the CAB on specific steps of the pipeline. This can be visualized to show work moving through the system, helping the CAB to “see” what’s coming and to plan ahead.
- Inserting decision gates between significant steps such as “deploy to production” to wait for CAB authorization when appropriate.
- Reporting on the quality of the pipeline, increasing CAB confidence in the pipeline to reduce risk and raise quality.
3. Making the CAB More DevOps-Friendly
Nothing infuriates a DevOps practitioner more than working with an ITSM process that “doesn’t get it,” and impacts their ability to be agile and productive.
Putting a big, lumbering CAB (perception or reality) between a DevOps pipeline and production is a sure-fire way of antagonizing the DevOps crowd. Likewise, criticism of DevOps by ITSM teams (“It’s a fad,” “They don’t get it,” or “It’s OK for websites but not for real computing”) signifies a corrosive and toxic environment where clashes will be more frequent than production releases.
The CAB can change this outcome by altering their position, accepting the DevOps approach and recognizing its applicability (it might not work for all systems) as a complementary approach to ITSM. There are three ways this can be done:
- Integrating the DevOps tool chain and pipeline with ITSM tools. Integrating notifications, adding decision points that require an email acceptance, and working together.
- Recognizing that changes that come via the DevOps pipeline are inherently less risky by themselves and of a high quality.
- Focusing the CAB’s efforts – understanding how change by the DevOps pipeline (deploy to production) impacts the wider business, moving from a “stop” sign to a “give way” sign.
Ultimately, DevOps and ITSM have a common goal: improving the business by getting better products into customers’ hands faster. They can achieve this together by modifying their behavior to work better together, then making it happen by integrating their tools and collaborating in respectful manner – effectively proving that the whole can be so much more than the sum of the two parts.
via Technology & Innovation Articles on Business 2 Community http://ift.tt/2nxjGfe