ITIL is a set of design patterns

ITIL

People who’ve spent any time with IT service management will be more or less familiar with ITIL – “the most widely accepted approach to IT service management in the world” (ITIL | AXELOS) (Decent Wikipedia article.) And people who’ve spent much time with ITIL will probably be familiar with the phrase “adapt and adopt”, and the recognition that ITIL isn’t a standard, just a library of good practices.

But still there’s a tendency to see ITIL as a monolithic block of processes and organisational recommendations, which all organisations should strive to adapt a little bit and implement in full, subject to reaching some flexibly-defined level of “maturity”. And this can in practice put people off getting the real value out of ITIL.

It is the best library of good practices we have, but it is not as cohesive and internally consistent as it aims to be, and falls short of being a management approach. Numerous authors, such as the IT Skeptic, have written extensively about the limitations.

Design patterns

People who’ve spent time in development, especially agile development methods, will be familiar with the concept of Design Patterns – generally reusable solutions to commonly occurring problems within specific contexts, as popularised by the 1995 book “Design Patterns: Elements of Reusable Object-Oriented Software” (Amazon). (Wikipedia; some links to pattern catalogues.) Terms like “decorator” or “factory method” are now parts of everyday development language, as “CMDB” or “SLA” are in ITSM.

For those who may not be familiar with the concept, I’ll outline the essential features (as I understand them – I am not an expert) below, with the parallels with ITIL.

I propose that ITIL is best understood as a set of design patterns.

Design patterns arise out of the (obvious) observation that there are a lot of common problems that come up in development work, and that it’s worth learning from people who have solved these problems in the past. … ITIL arises partly from the same need.

But also from the less obvious observations that:

• It can be hard to find the right relevant experience when you don’t know what term to apply to the problem. So design patterns provide recognised labels for specific problem types. … ITIL provides a common language for ITSM professionals. (For example, in differentiating Incidents and Problems.)
• The first “obvious” solution to a common problem is not necessarily the best! There are quite often complications and subtleties that need to be taken into consideration – and this is where the value of past experience can be greatest. … Most chapters of most ITIL books mention common problems and costs.
• The “best” “solution” from past experience (though design patterns tend not to actually use the words best or solution) still has some consequences or implications that will affect other system components and may need work to manage. … Again, the need for documented good practice in ITSM arises from the same need.

What isn’t stated in the development community – because it’s too obvious – is that you don’t implement all the patterns in the book just because it’s good practice. You only investigate them as solutions when you have to address a problem of that type – and you only use a specific design pattern if the details of your problem match the constraints given in the pattern description.

It’s also usually obvious that they are just patterns, not ready-made solutions that you can plug into your code. Many people approach elements of ITIL as if they can be directly implemented, or at least implemented with the aid of a vendor’s tool or a consulting firm’s toolkit. Instead, ITIL is very clear in the books that it describes factors to consider, things to avoid, and models to follow, not a solution.

Conclusion

Your team must have access to a good understanding of what ITIL can offer (which might be via external specialists; that’s not necessarily bad). But ITIL should never come first in the solving of problems: the problems should.

Understand the problem you face. Agree and document the requirements independently of assumptions on what the solution might be. Agree and document the constraints (which could be seen as negative requirements) – and yes, constraints should include your current tool and process environment and may include strategic constraints like incumbent vendors and architecture policies (I deliberately, but with a wink, call these strategic constraints instead of strategic enablers).

Without manageable requirements you aren’t problem-solving, you’re just throwing money at the symptoms.

Then analyse the guidance from ITIL, and other sources (like your tools and consulting suppliers; like DevOps) as design patterns: is this pattern applicable to the current problem? What structures does the pattern require to address the problem, and what is left that you can vary independently? What consequences does this pattern have – trade-offs, pitfalls, dependencies on other components?

Don’t accept that everything in ITIL is cohesive (though it tries to be), or that everything is applicable to all organisations and problem situations. But don’t then lose the value it has to offer!

Caveat

ITIL wasn’t consciously written as design pattern language, but most categories of a design pattern description can be found in the books, except perhaps for ‘applicability’ – describing the situations where the pattern can be applied, and where it may not be useful.

Design patterns should enable local solutions to specific problems, not depending on all the other design patterns in “the book”. I don’t claim this is easy with ITIL – many process areas do make assumptions on other process areas following the ITIL way, and certainly on there being organisational units like “the capacity management function”. But if not easy it’s still necessary. A process and information architecture for IT Service Management is an important way of managing this – start simple, model the direction you intend to take, reflect the capability already in place and usable by new solutions.

---

Standard disclaimer
Many of the points in my blog entries leave me aware there’s a lot more to be said. I have to resist the temptation to hold back on publishing until I’ve written down everything, instead leaving them for future entries. Let me know in the comments which are important!