Capacity or Availability Management?

We all know (or should know) that ITIL originally was written as one process in one book, often by completely different authors. This is where the L for Library in ITIL comes from. Consequently one of the downside of ITIL v1 is the inconsistency across the various processes/publications.

ITIL v2 (around the turn of the century) packed a number of processes together (Service Support and Service Delivery most notably), but barring some minor changes, modifications and updates it still seems it was mostly a copy of v1, and thus the inconsistency remained.

And whilst v3 (2007) was more of a rewrite (than a ‘mere’ copy), different writers contributed to different publications of the lifecycle and thus the inconsistencies across these processes & publications wasn't completely removed. In fact the introduction of new processes caused some additional discrepancies (Release & Deployment Management still called Release Management in Service Design, Problem Management not referring in any shape or form to Knowledge Management, CSI hardly mentioned at all in any of the other lifecycle publications).

The most recent 2011 ‘update’ tried to remedy some of this, by swapping writers around (writers of one publication, reviewed & updated another) and by introducing further structure within and across the publications. And admittedly they have not done a bad job, but I am still left with the suspicion that some of the text in the current books is an almost verbatim copy of the original version 1 processes.

Of course: universal truth remains universal truth and common sense doesn't change over time. And thus some of the v1 ‘goodness’ certainly deserves its place, even in the current publications, more than 25 years later. But I cannot escape the feeling that this has been a missed opportunity where a bit more consistency & standardisation would have made some the more ‘difficult’ processes a lot more accessible to the audience.

All this was triggered this week, when I was delivering the PPO (Planning, Protection & Optimization) Intermediate Capability course. I have always thought that Capacity and Availability Management have a lot in common, but this week I played the game whereby I showed the Capacity Management slides (theory) and replaced the word ‘Capacity’ with ‘Availability’ and surprise, surprise it still made sense.

Actually no surprise as both processes are trying to achieve the same objective or goal of ‘ensuring cost-effective meeting of the current and future needs of the business’ (one for Capacity, one for Availability). They both have a plan (forward looking plan, describing the current situation, SWOT, foreseeable future scenarios and recommendations), they both have a MIS (Management Information System, storing relevant information for the process), they both support Service Level Management and they both have activities to do with impact assessment (Change Management), design, monitoring & analysis (Operations) and proactive improvements (CSI).

Sure, there are differences: Capacity Management has three sub-processes which look at capacity at business, service and component level. But really, don’t those sub-processes also exist in Availability Management: looking at the availability of a component, a(n end-to-end) service or a business (PBA)?

IMHO the only real differences are the specific terms in Availability Management (availability, reliability, maintainability & serviceability) and the techniques used (CFIA, SOA, FTA, …).

Although some of those do translate to Capacity Management. After all reliability include things like resilience and redundancy which requires capacity. And in the end an incident which impacts capacity (for instance performance degradation) could also impact availability (if for instance the response time become too slow to be ‘workable’).

So, my suggestion is to rather than look at Availability and Capacity Management as two separate processes, each requiring separate process manuals etc.etc., it would be beneficial to leverage both (with perhaps specific roles and procedures at a lower, more technical level).

Also realise that many of the activities (design, test, monitor, analyse, report) will already be there, especially at a technical level, and ‘the trick’ is to combine or centralise these across the technical functions and ‘lift’ them up to a service level and to provide a business-centric focus on capacity and availability. The next challenge is then to involve the customer (through Service Level Management) to obtain enough forward-looking information to increase the effectiveness of the processes.

It will remain a challenge for many organisations, but hopefully slightly less so …

the ITIL Zealot
May 2013

ITIL is version-less and timeless

I realise I am almost a year behind the times here, but I have to give the Cabinet Office (, OGC, APMG?) credit for removing the version number of ITIL. No more ITIL v3, but plain ITIL; or ITIL (2011) if you want to be pedantic.

When in 2007 ITIL v3 was released, or perhaps even earlier when the name was made public, automatically the previous version became v2 and the original one v1. This then became the topic of many a debate about what was wrong with version 2 and whether organisation needed to ‘upgrade’.

I actually wrote a white paper in those days comparing ITIL v3 with Windows Vista (remember, this was early 2007). Vista had sparked similar debate where people admired some of the new functionality and visuals (mainly aero) but were unconvinced about the need to upgrade from Windows XP. To a large degree the same discussion can still be had about Windows 7 and Window XP (and with Windows 8 just around the corner get ready to revisit this discussion once more).

I’ll digress slightly here by going off-topic and tackling the issue of justifying a change (sure to be a topic for future blogs as well). One of my favourite ways of stirring up people is to say there is no such thing as an IT project! There are projects with IT deliverables, but ultimately a project should be done for a business reason\benefit. Thus the business case for Windows (8, 7, Vista, …) should not be about niceties, but about utility and\or warranty improvements. The moment Microsoft stops providing support for a product, is when the case for upgrading can be made, not before (unless the new version offers additional and needed functionality). With this in mind now try to write a business case for an iPhone!

Anyway, back on the topic of the debate of ITIL v3 and v2. To a degree I myself partook in these discussions. As a self-confessed ITIL-dinosaur and conservative I believed that the new ITIL version 3 was nothing more than v2 in a shiny coat and didn't add any real value. I have to admit the error of my ways and over the years have found appreciation for the lifecycle ordering, the process ‘refinement’ and the Strategy ‘add-on’ (I guess all of them worthy of a blog at some stage).

I concluded in my white paper that unlike Windows, ITIL is not a product that gets installed or upgraded, but instead it is a framework of structured activities (processes).  And these activities are generic or perhaps common sense (I now, common sense isn’t always common … and doesn’t always make sense either! Hence the need for frameworks to help us follow common sense). The fact that ITIL v3 had added new activities (mainly Strategy) or had moved them around (‘old’ v2 incident management split over new v3 incident, request and access management) did not invalidate the ‘common sense’ activities but provided merely a new way of structuring these same activities (i.e. in the Lifecycle).

So when last year the rumours of v3.1 (let alone v4) surfaced I was bracing myself of a repeat performance of these discussions. Never mind the commercial mistrust where many believed ITIL v3 was just there to increase book sales and training opportunities. Therefor I was more than pleasantly surprised when not only there was no training upgrade required, AND the updates were logically and improved or enhanced the existing theory but that ITIL had dropped the v3 moniker and had gone back to being ‘just ITIL’, the best practice framework for IT service management (another return after a short dalliance with good practice).

Of course PRINCE2 has applied this way of version numbering for a long time. After the initial 'upgrade’ from PRINCE to PRINCE2 in 1996, several subsequent versions have followed in 2002, 2006 and 2009 without making it PRINCE3 or PRINCE2.1. The new version comes out and 6 months later all publications and training of the old version is gone and PRINCE2 (and now ITIL too) remains THE framework it always was (and will be).

We ‘experts’ are often positioning ourselves as critics, with better or improved interpretation, application or communication of the theory, but I think it is important to recognise the goods things too. And ITIL (2011) is such a good thing, a common sense improvement on a common sense framework. Makes sense really!

the ITIL Zealot