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.

Start ITIL with Continual Service Improvement

People often ask which part of ITIL companies should implement first. They very often get the (correct) answer that you don’t implement ITIL, you use it to improve your service management. But that’s really just rephrasing the question: which part of ITIL should companies use first to improve their service management?

10 Reasons Why Strategic IT Management Initiatives Fail

Dennis Drogseth has published an article 10 Reasons Why Strategic IT Management Initiatives Fail on CIO Update.

Now, I agree with every one of his ten reasons, but I immediately thought of some different angles on the approaches he recommends …

Agile Service Management

I’ve been thinking…

1. I am not a professional software developer or data architect, but I’m very interested in these disciplines through ITSM contact with practitioners and teams. (I often feel there’s a great loss of value in the lack of mutual familiarity between service management and development/data communities.) One of the approaches I have been particularly interested over the past year or so is Agile Software Development, the Agile philosophy – see the Agile Manifesto, and some of the key practices associated with Agile development like test-driven development, refactoring and design patterns.
2. I observe that many ITSM projects (“implementations” or improvements) suffer from issues with long timescales, inability to cope with changing requirements, lack of user acceptance, and so on. Not all, but those that do suffer tend to be blind to the causes and show resigned acceptance to such issues – or even to be blind to these issues.

Those issues, and others I haven’t listed, are very like the kind of things the authors of the Agile Manifesto were experiencing. Agile development is very successful in certain environments (though not all – and more traditional “big requirements up front”, “big design up front” methods have strong defenders). Could Agile principles be applied usefully to IT Service Management problems?