ITIL & DevOps merge to create DevIL Framework - Matthew Hooper VigilantGuy Digital Transformentalist - Create High Performing IT
ITIL & DevOps merge to create DevIL Framework

Of course there will soon be the LEAN version called LIL’ DevIL.

Rodney Dangerfield said in a film:
“If you want to look thin, you hang out with fat people”.
Rodney was no fit individual.  With no offense to those with weight issues, his comical point was, that you don’t really need to change yourself to be thinner, change the company you keep.
This is sort of how I feel lately with some of the industry content that is being put out in IT Management, particularly around ITSM. ITIL consultants or presenters who have made a career guiding organizations through the complexity and ambiguity of the text books, are desperately trying to find some foot hold in this DevOps movement that is taking IT operations by storm.  Unfortunately, they are putting themselves in the company of individuals who are running very lean, and frankly they sound very heavy.
“Matt you were an ITIL trainer and consultant, and have been speaking on DevOps for years.”  True  & True.  However, I have always been tough on ITIL and pushed for changes.   In 2010 I wrote the blog “Is ITIL loosing its momentum” I broke down the industry pain points and the business pressure for ITIL or away from ITIL.
I spoke of the push for an open standard – Hello IT4IT
I focused on the emphasis of IT Outsourcing and service brokering – Can you say SIAM?
I also pinpointed that there was going to be big push for a consolidation of frameworks and extensive commitment to compliance… and if you had a chance to hear this latest Continuous Discussion  , we had industry experts from Kaimar Karu of Axelos, Robert Stroud of Forrester, Mike Kavis of CloudTP discussing the topic:  “Is ITIL Still Relevant in a DevOps world?”
It is absolutely relevant!  The question really should be, is ITIL’s widely understood practices valuable in the Digital Business where DevOps is proving itself valuable?
In my webinar for ITSM Academy: “Cut the ITIL Anchor; Raise the ITIL Sail – Why Fast IT Organization Win!” I discussed as I did in 2010, the business trends that are driving IT organizational behavior.
Notice how I stated how “ITIL’s widely understood practices”.   That statement is important, as much of ITIL’s content and guidance is debatable on how it should be applied.  There is some excellent guidance in ITIL that can significantly help a DevOps mindset.  However, there are some things that will be very damaging to a DevOps mindset.
Let’s start with some of the guidance that adds value to DevOps:
Demand, Capacity and Availability Management
ITIL’s guidance and information on Demand Management starting in Service Strategy through to Capacity and Availability Management in Service Design, is sound guidance for DevOps Engineers to read and understand.   DevOps minded organizations will frequently have a role called a Site Reliability Engineer or a Service Reliability Engineer.  These engineers frequently find themselves doing scenario building and designing.  These scenarios will lead to fail-over testing, performance testing, infrastructure monitoring and disaster planning exercises to ensure continuity of operation.  The business to component perspectives and considerations in ITIL increase the engineers ability to create more realistic and practical scenarios.
The challenge of the guidance though is the language it uses.  DevOps minded engineers will have a difficult time reading the guidance from ITIL because of it’s tone.   ITIL was written as if IT were a distinct department from the business that provides IT Services to the business as an IT Service Provider.  This is not how high performing IT organizations with a DevOps mindset view themselves.  Thus they are inclined to discredit the guidance as “fit for use”.
Here are some philosophical differences of Traditional ITSM organizations vs. High Performing IT Organizations:

Traditional ITSM

High Performing IT

We must have IT & Business Alignment
IT is the Business
IT is a Service Provider
IT is competency that enables digital agility
We are an IT Service Provider focused on meeting SLA’s
We are an IT company delivering business services focused on customers
The customer is the person who pays for the IT service – anyone not in IT
The customer buys from our company – customer does not work here
We improve IT Services through IT projects
We increase customer satisfaction through business projects
We deliver successful outcome through IT services based on business requirements and agreed service levels
Business requirements are a myth, we learn from customer feedback if our outcomes are successful
Changes will be controlled to reduce service impact and maintain value of IT Services
Control is a myth, we test small changes constantly to validate value and create improved resilience and reliability
Here are some tactical differences of Traditional ITSM organizations vs. High Performing IT Organizations:

i.e. up-time & response time,

Measurements are based on consumption; i.e. latency, usability, abandonment

Channels are created to easily end users get to the single point of accountability.  Developers interacting with end-users is encouraged.

Traditional ITSM

High Performing IT
Any major or cross-functional change goes before a Change Advisory Board (CAB)
Major changes are broken down into a subset of small incremental changes, also known as Epic’s with Stories.  The oversight is led by tight steering committees of made of the people doing the work, also known as a scrum team.
Processes are focused on services; A request for services, an impact to services, a problem with services, a change to services.
Processes are focused on effectiveness; Feedback addressed as part of improvements.
Measurements are based on assets or action;
Configuration Management is something you WANT to do, and you have many meetings discussing how you should.
Configuration Management MUST be in place, no automation or change can happen with out a trusted system of record.
A service desk is promoted as a single point of contact.
And there are many, many more examples.   The differences in intent are not dissimilar, but the difference in execution and mindset is quite different.
And Rodney was wrong, just because you hang out with procurement and HR, it doesn’t make you look Agile.
To truly build high-performance, you need to change your perspective, your expectations, your language, and your mindset on how work gets done.
In my next blog article I’m going to cover the topic of Work In Progress.  How does work come into IT?  How does work get done?
Written by

Digital Transformentalist Twitter: @VigilantGuy Linkedin: Web: Matt Hooper is an industry advocate for Service Management strategies and best practices around Enterprise Service Management. For over 20 years Matt has instituted methodologies for business intelligence and optimization. Leveraging technology to drive business outcomes, he has built an industry reputation for his highly effective approach to creating value through Service Management. Matt is active on Social Media known as VigilantGuy, and co-hosts the weekly podcast: Hacking Business Technology.

Leave a Reply

Matthew Hooper

Digital Transformentalist