The ITIL® DevOps Blog Response

Colleagues in discussion sat around desk with laptops

Everyone’s favourite IT service management (ITSM) puppet blogger, Joe The IT Guy, published an article a couple of months ago on the alignment of ITIL® and DevOps. It had some great insights, and Joe suggested that I pen a follow-up … so, here it is.

Akshay AnandBefore I start, I’d like to make a general comment: We (as an industry) need to address the delineation (or even if one should exist!) between service management and product management, and between the service owner and the product owner.

The relationship between product (or “digital goods”) and service has rapidly changed over the last decade, and the “4Ps model” is creaking under the stress of this evolution. For example: when I wire money from my bank account using an app on my phone, am I primarily using an IT product to consume a business service, or am I consuming a technology service of which the app is a component product?

This leads to the next question: should the service owner manage the overall value stream of the technology service (and IT sub-services), or should the product owner have responsibility for the overall health, maintainability, reliability, serviceability, performance and security? I suspect the answer lies somewhere in between those two poles.

Now that I’ve gotten that out of the way …

In his blog post, Joe gets a lot right when talking about ITIL and DevOps. Capabilities (and note: I said capabilities, not processes) that allow the IT organization to deploy code quickly, get actionable telemetry and feedback from operations, and keep a relentless focus on seeking out better ways of working are key components in successful DevOps adoption. And I applaud Joe for highlighting that service owners should think and act with an “outside-in” bias.

My observations on the conversations and debates around ITIL and DevOps have led me to believe that many practitioners in both camps have lost sight of the fact that ITIL is a body of knowledge within the domain of IT service management, not application management.

What do I mean by that?

It means that when adopting and adapting ITIL guidance, we should constantly remind ourselves that they apply to services not just to products (hence my remark earlier about clarifying the delineation between the two). If we go back to the 4Ps model, then we can see that a service includes not only products, but also partners, processes, and people. With a lot of focus on DevOps and Agile software (product) development, I feel like we risk losing sight of the larger picture.

For example, planning and designing a service *can* include planning and designing products, but it could be limited to changes to partners or processes … with no changes to products. A service release *might* include a product release, but the converse isn’t true; not all changes to service components have a direct effect on the service and the user experience. We shouldn’t be transferring the full rigour of service management processes and procedures to manage products.

A topic that isn’t adequately addressed in current ITIL guidance is where service development (and thus product development) sits. The service V-model has it at the bottom of the V-shape, essentially occupying a grey area between service design (the left arm of the V-shape) and service transition (the right arm of the V-shape).

© Copyright AXELOS Limited 2011. Used under permission of AXELOS Limited. All rights reserved.

Moreover, continual service improvement (CSI), whilst written about in detail in a separate book, has always applied to the entire service lifecycle, as opposed to something that happened “post-operations”. Similarly, part of the DevOps ethos is to continuously measure and manage capabilities across the value stream. So, I thought I’d be a bit cheeky, and recreate Joe’s map like this. It’s broadly the same, but with some minor differences.

Let me leave you with six more hacks to align ITIL and DevOps:

  1. Make sure the cadence of service management across the lifecycle syncs with the cadence of product management. Joe mentioned this in the context of CSI, but I believe this hack is too important to be left to the review and reporting processes mentioned in his article. So, for example, organizations could look at aligning the frequency with which the service design package is updated with DevOps iterations. The same applies to the frequency of service portfolio reviews, or the frequency of knowledge article updates. It can even go down to the level of making sure your service operations teams have daily stand-ups similar to development and technology operations teams (or perhaps it’s the same meeting!)
  2. Joe mentioned using the CSI register to feed the product backlog. But to make that work effectively, consider using the same mechanisms to prioritize the CSI register and the product backlog. For example, if the product backlog prioritization is driven by potential revenue generation and by technical debt reduction, try to view the CSI register with the same criteria. The converse also holds true. When an organization decides to build a new product to deliver business services, they should look at reusing the CSI prioritization techniques when managing the product backlog.
  3. Extend cross-functional teams that include Dev and Ops to include service management. This allows the service management function to directly observe the challenges and successes of DevOps work, allowing them to develop easier ways of working.
  4. Remember, not all changes to service components (i.e. people, processes, partners, and products) are significant changes to services, or likely to lead to a service outages. Trust the development teams and aggressively pursue standard change models. Introduce approvals to deal with exceptions, rather than a default approach to all changes.
  5. Carrying on from the previous hack, extend the automation of the DevOps toolchain to service management systems as well. For example, when deploying new product increments, consider automatically recording a standard change and updating the configuration management database at the same time. Alternatively, change the deployment toolchain workflow to wait for an approval trigger to come in from the change management tool.
  6. Adopt an outside-in perspective of services, and look at defining service management from a customer or user point of view. Design appropriate governance to protect the user’s service experience first, and not the service provider’s ability to operate efficiently and effectively.

There is one point in Joe’s article that I disagree with. He mentions under service strategy that governance rules should include how stories are prioritized and Scrum activities managed and conducted. This is against the spirit of the Agile and Scrum movements, where self-governance by the Agile team is a core tenet. It might be necessary to impose some hard constraints such as people’s behaviours and the management or governance outcomes required, but the Agile team should be left to decide how best to achieve the outcomes.

I hope this article has been useful. What do you think about aligning ITIL with DevOps? Leave a comment below!

Current rating: 0 (0 ratings)

Comments

7 Dec 2017 Jon Hall
Alternate text
I think this is a good article. I feel like the conversation around ITSM and DevOps is starting to mature. This is something that is much needed: we have to move forward from simple assertions that "DevOps fits just fine into ITSM". Some of the practical suggestions here, such as incorporating service management people into DevOps teams, are things that I'm already seeing taking place in a few organisations, and they tie in nicely to concepts like Swarming which are definitely getting traction in the DevOps community.

I'm not sure I'd agree that DevOps is quite so polarised just on Product development, though. Organisations doing DevOps well are doing so with a full focus on both the customer and the culture of the organisation. Partners, too, are a big part of the picture, even if that's focused largely "under the bonnet".

Look for instance at the influence AWS, Azure, Pivotal, and the like are having not just at the technology level, but also in the context of "working with you to transform the way you deliver things". I was recently listening to a podcast with Kelsey Hightower talking about how they go into companies and get them started by standing up one of their application services on the new environment, and handholding the teams as they get started.

This article series deserves praise for addressing, at last, the fundamental disconnect that has evolved here: one which will never be solved just by pasting framework illustrations together on one slide, and pointing out that they're pretty much compatible (please, everyone, let's stop doing that!).

But where we need to go next, I'd suggest, is to figure out how to sell genuine *value* to the DevOps community out of this effort. Attitudes to ITSM at DevOps events tend to range from grudging acknowledgement through to outright hostility. A culture built on self-organisation and the Andon cord will always feel it's in a position to say no to things that are not obviously creating value for them.
You must log in to post a comment. Log in
Forum Leaderboard
Our “Leaderboards” are just one way we show off the best and brightest of the AXELOS Community. This is a list of our top users with the highest post counts in the AXELOS Community - select "View the full leaderboard" to find out where you are on the list!