Service Design - ITIL v3
Integrating IT with the business
This time, we are looking at Service Design, the next book, which starts to look at the practicalities of integrating IT into the business. Note: not "aligning IT with the business" any more. The world has moved on.
Sharon Taylor , ITIL's chief architect, summarises the aims of Service Design rather well in the foreword to this volume: "In the past, the IT world has been viewed in two parts – the development world and the operational world. A lack of synergy between these worlds often produces a serious side effect – the business objectives are not met."
According to Sharon, "a main objective of Service Design is to eliminate this old-world view and bring IT service into a single consolidated view" of live business operations.
So, how do the authors of this book go about this and how well do they succeed? Well, coverage is pretty good. It starts with fundamental definitions and then looks at the processes and principles of service design. We particularly liked one set of key messages (ITIL is definitely operating in the process maturity improvement space):
- If you don't measure it, you can't manage it
- If you don't measure it, you can't improve it
- If you don't measure it, you probably don't care
- If you can't influence or control it, then don't measure it
The book then moves onto technology-related activities (requirements engineering; data/information management and application management). It next covers some of the practicalities: functional roles analysis; activity analysis; roles/responsibilities; and even service design and management tools. However, the coverage of some of this is pretty brief, which is OK if it isn't entirely new to you.
More space is, usefully, allocated to the implementation of your service designs: business impact analysis; service levels, risk management and service design metrics (Kaplan and Norton's Balanced Scorecard is mentioned). There are even three pages on challenges, critical success factors, and risks.
Finally, there are practical examples of design deliverables in the 11 appendices, including example process documentation templates; an example service catalogue (surely, this is central to any service delivery approach and, as this book points out, should be under configuration management); and even an example invitation to tender. Oh, and typical capacity and recovery plans aren't overlooked.
One slight concern is that this book covers a lot of ground in some 300 pages. All good stuff, and if you are an experienced IT architect or manager it collects "good practice" into one place as part of an IT service management lifecycle.
However, if you are new to service design a lot of it may fall into the "easy to say, less easy to do" category. This isn't the sort of book you can just give to a new graduate and tell them to get on with it. You'll either need a lot of experience or good mentoring and classrooom-based training to execute it successfully. And, supplementary material should grow up around ITIL with time.
There's not much point in going on about the cost of the ITIL manuals again – although if this worries you, you might consider the cost of not using its recommended "good practices". An electronic version is available more cheaply, although this must be mainly useful for quick reference after training. However, TSO does offer a decent quantity discount for buying all the volumes at once.
Verdict: This book isn't about producing a high level and possibly impracticable design - that is simply tossed over the wall to the unhappy developers and operations staff who have to make it all work. It is full of practical insights such as that over 80 per cent of errors are introduced in requirements - "developers are developing things right, but frequently not developing the right things" - and that "capacity management should not be a last-minute 'tick in the box' just prior to customer acceptance". Of course, we all know all that, but showing your harassed (or harassing) boss that a successful service delivery framework supports your insights into the service delivery process may just help him/her to take you seriously.
Authors: Vernon Lloyd and Colin Rudd
List Price: £85.00
Current Reg price: £76.50 inc. VAT (discount 10%) Buy this book at Register Books at Reg Developer's special discounted price (subject to change).
A discounted collection of all 5 ITIL V3 manuals is available here, for £269.10 (subject to change).
Don't bother with metrics?
Yes, there are a lot of intangibles, but that doesn't mean that pursuing *appropriate* metrics isn't worthwhile...
Have you noticed that IT has a reputation for delivering Late, Over Budget and Wrong? As it happens, I believe that this is often unfair to IT, and that IT is often blamed when the business doesn't really know what its own business process is - but, without metrics, how do you prove this?
And, in its unmanaged, chaotic way, craft-IT does often build systems "right" (until they get maintained); the trouble is, they are not always the "right systems" when the business starts to use them... The IT status quo isn't held in universal respect - outside of IT.
about your comment.
Hi - I both agree and disagree your comment, it is too simplified. ITIL is great as are SOA, SDLC, XP, agile, etc. Unfortunately for most business they are just words, something to attach to reports. ITIL is very nice framework but there is no fixed model that fits in all cases. And nothing new here, any and all these methods / architectures were used a log time ago, they just didn't have names attached. Weird, it has been known a long time that following some organized way to do things is good for both business and IT as long as they work together and we still need someone to tell us how ?
ITIL is yet more snake oil by those who know little except how to b*llsh*t.
Just take one little part of this, that "if you can't measure it you can't manage it and shouldn't even try". Total rubbish and the cause of most IT screwups. Most of the important factors to do with business success are intangible. They are things like 'innovation', 'customer service', 'efficiency'. By their very nature they are not the type of thing you can put a number on - but people who love ITIL will try. They create 'fake' metrics that stand in for the item under consideration. Maybe they will count patents, or survey the customers, or measure some abstract utilisation figure.
And then it really goes wrong.
People work to these 'fake' metrics. They optimise, they modify, they cheat. Pretty soon the metrics are way up, and the real performance is way down as the fake metrics drives paradoxical behaviours that are against the businesses best interest.
In IT that means measures of effectiveness that totally ignore the staff screaming at a system that doesn't help them deliver their job, and an IT staff that actively gets in the way and prevents change. "But we're following our ITIL approved plan and all our metrics are up."
Save the hundreds of pounds they want for this paperwork jamboree and get a clue instead.