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