JUser: :_load: Unable to load user with ID: 660

Latest Blog Posts

What is a Service?

What is a service?


Large fleas have lesser fleas,

Upon their backs to bite 'em,

Lesser ones have lesser ones,

And so on, ad infinitum.



The problem:


The Adaptive Service Model (ASM), produced by the Taking Service Forward initiative (TSF) does an excellent job, resting, as it does, on the shoulders of many others who have worked to define services before. It shows how a service interacts with resources, service suppliers and providers, and the other essentials to deliver value. The site is takingserviceforward.org, and the latest diagram is:




The difficulty is how to define the service itself. There are many different sorts of service, and they all must be served (if you excuse the term) by the definition. For example:

Accounting services

Architectural services

Building services

Car services

Catering services

Cleaning services

Clinical services

Currency conversion services

Dealing services

Delivery services

Electronic services

Financial services

Insurance services

Laundry services

Legal services

Manufacturing services

Pathology services

Personal services

Police services

Prison services

Rental services

Room service,

Technical services

Technical services

Wreck recovery services


..And many more. How is it possible to have a definition that encompasses all these, without it being horribly complicated with lots of exclusions or possible alternatives?


There are other requirements of the definition, including:


  • Not confusing 'service' with process, activity or procedure

  • Not getting involved in trying to distinguish 'produce' & 'service'

  • Making it, if possible, easy to understand and remember


What about using a recursive definition?


It has been done before. For example:


Gnu: Gnu is not Unix

Recursion : See Recursion

There's a problem with these two, they go on, like the fleas, ad infinitum.


Mathematicians and programmers have known a solution to this for some time – mathematicians call it 'induction', rather than recursion, but it's the same thing. The solution, is to have an end-stop. Like this:

Calculate N! – that is N x (N-1) x (N-2) x …. x 1 [ 6! = 6 x 5 x 4 x 3 x 2 x 1 = 720

A recursive solution could be:


Function factor(N) returns an integer

if N > 1 then N * factor(N-1)


return 1


If you called the function like this:

Print factor(6)

Then the answer would be 720.

Definition of a service:

The Adaptive Service Model describes the context within which a service exists. The service is either:

An Atomic Service (or quantum service)


A service that is supported by other services that contribute to it delivering value.

Definition of an 'Atomic/quantum service':

An Atomic/quantum service is a service at the lowest level of useful description for the circumstances.


The picture below shows the breakdown of a service into its component services. It only goes down one of the trees to the bottom (and there could be services below that), to give the idea.

Usually it would be silly to go below the e-mail service for most purposes, but it's useful to see that you can go as far as you want, if it is useful for a particular purpose.




For much more, including comprehensive information on Service Governance, see Service Governance



What is ITIL? Some ITIL Word clouds

I thought it would be interesting to see what ITIL looked like in word clouds. It's a pretty rough and ready way of seeing what something is about, I know, but I find word clouds interesting and instructive - if you don't, please ignore.

The method I used was to take the raw text, then, using an awk script, count all words and short phrases (phrases of up to four words). I then cut out common English words and phrases (wordle helped cut out more), and turned the remainder into a wordle word cloud.

All the ITIL books have the first chapter in common, and the index repeats what's in the text, so I topped & tailed them to remove these, leaving just the book itself. First, though, I made a word cloud, using the same method of Chapter 2 - which is the introduction to service management. Here it is:



Service Strategy:



Service Design

Service Transition

Service Operation


Continual Service Improvement


Now, What next? The future is Open Source - UK Government Official

Excellent news - congratulations D5! @cabinetofficeuk: D5 charter ‪#‎D5London‬ 
So know it's official. Future development of anything that matters will be open source. This is essential for many reasons, but cybersecurity is the big driver. No Open Source, No privacy.
What next to get the most out of this initiative?
The next important job is the plan to wean Microsoft addicts off their spyware and onto Open Source.
I've suggested that a good starting point would be to give £10M to fund Linux GUI development. Get the EU and Germany to chip in similar amounts, then set up a funded development group. Also, put up a really big prize for the open source solution that meets all the requirements.
That's a tiny amount of money in terms of state funded projects, but it'd pay for lots of top developers to work with enthusiasm. It would be unwise to put up more money - large over-funded projects are disasters waiting to happen.
A competition can produce excellent results - that's how Ada was developed (the French team won)... actually, if it were me, I'd insist that the solution was written in Ada, to grow open source expertise in reliable and secure programming.
Oh, and nobody wins unless they submit their full design work.
Once that's over, the next tranche of funds can go to producing a simple, secure design for the Linux replacement.

http://ow.ly/FK0rl http://twitter.com/cabinetoffi…/…/543088186675957760/photo/1 ‪#‎opensource‬ ‪#‎infosec‬



If Open Offices are so bad - why has CSI not done anything about them

This reminds me of that wonderful book; 'Extraordinary Popular Delusions and the Madness of Crowds'. The attached article from the 'New Yorker' illustrates how many ways the Open Office is so bad for you.


We talk in Service Management of how to influence ABC. We talk of how to measure and improve things to create value and so forth.


Isn't it at least worth wondering why and idea that's clearly anti-productive and destructive of employee morale and health is so universally seen as a 'good thing' that 70% of offices are open plan?


Shouldn't at least one CSI exercise have identified the open plan office as a defect, a root cause, of a loss of value? If not, why not?


If CSI should have identified this, why has it not? What is missing in either the best practice advice on CSI or in the actual practice of CSI that allows such an obvious elephant to remain undetected in the room?



Evolution, homeostasis & CSI - why change is like a diet

'Optimise' is a difficult term to use, because it suggests that there is one, and only one, optimum. Evolution, as beautifully described in Dawkins' 'Climbing Mount Improbable', like us, is very good at finding local optima, which are, 'good enough'.


Evolution is poor at climbing down from one local optimum to another, over all better, local optimum... Actually, that's an understatement, evolution finds it all but impossible to move from one 'good enough' local optimism to another, very close by, but much better one, because it has so much invested in climbing its particular local maximum. It's only a radical, and, usually, fatal defect, a mutation, for example, that allows such optima hopping.

Part of the power of using design to requirements is to allow exactly that, a re-think, radically (and not as in Martin Amis' 'radical rug rethink', which is hardly optimal at all), has a chance also using insights from CSI (though CSI itself is really a requirements gathering exercise) to improve things significantly. It allows us to think up and apply 'mutations' to the organisational behaviour. We'd be wise to learn, from evolution, that such 'mutations' are very, very often fatal.

Life relies on homeostasis. The mass of weight-loss 'solutions' that work, at best, in the short term, is a testament to the power of homeostasis. Our bodies, and those of all living creatures, are full of mechanisms to keep things, our temperature, our blood pressure, our weight, etc., as constant as possible.

Organisations, being full of people, are also keen on homeostasis, and being, possibly, a sort of life form themselves. What's known as 'resistance to change' is actually a sensible, conservative strategy to minimise danger. Radical design (that's 'radical' in the proper sense of 'getting to the roots', not the, understandably, connected meaning of 'extreme' and 'dangerous') is difficult, because it's the organisational equivalent of a weight-loss plan. Short-term discomfort and unpleasantness for the dubious promise of the attainment of a better local optimum, is not attractive.

It's useful to be aware of this as part of the nature of ABC (Attitude, Behaviour and Culture). Resistance is not just subversion, an objection to the new, a political fight against what is clearly a 'Better Thing’; it is part of the nature of successful organisations.

In overcoming resistance, you're actually subverting the homeostasis that keeps the organisation functioning. If you want to succeed, and not be rejected as simply a threat to existence, you need to:

- Make the short term as pleasant as possible

- Make the gain intended as clear, credible and desirable as possible

- Where possible follow existing habits, practices and beliefs - you want to succeed, not alienate

- Be prepared to abandon your initiative if you find out that it's a negative mutation. We never like abandoning things we've convinced ourselves are right, but, be prepared for changes, improvements even, to turn out to be, for, possibly, obscure reasons, bad for the organisation - accept that, as with evolution, this is more likely than not. If 100% of your improvements work and are easily accepted, then you've not being radical, the organisation has the constitution of a jelly and it isn't likely to survive, or you're very good at self-deception (probably all of these).

- Understand what the organisation's local optima are, and why they're there - it's part of what ITIL calls 'Business Relationship Management''. If you don't, you'll not know which is accidental and unimportant happenstance, and which are rocks on which the value of the organisation rests - the two often look, superficially, similar


The tail wags the dog - tools & service desks - PRDDOI rather than PDCA.

The tail wags the dog. The software package insists on, or is configured to insist on, meaningless statuses and priorities, so they're filled in arbitrarily. 

The service desk suffers particularly from having tools that make it easy to measure something. Whatever that something might be, when it is measured and rewarded, behaviour will follow. 

The behaviour will follow the something - most certainly not the something else that the business, the management or the customers actually value.

One good exercise, to drive this problem home, is to run a simulation, or a thought-experiment simulation, where the software tools have all broken. The aim is to develop tools on paper, or laminated cards, or similar mechanical devices that allow proper handling of incidents. [the HP/AXELOS/G2G3's race to results simulation does just this]

Quite a lot of the ITIL advice turns out to be essential. Quite a lot of the stuff that software tools do turns out to be of no value at all.

It is a good way of demonstrating the wisdom inherent in ITIL, which is the value it gives to service management and service governance.

The solution to this situation lies in understanding exactly what the value of a particular incident is to the business and how best to react to mitigate the damage and then, only then, deciding how to design the process and software to support it.

As always, if you don't spend time, effort and money on working out exactly what the requirements are, you'll end up spending much more trying to fix the mess your assumptions have made.

First understand requirements. Then, iteratively, work to produce the best design you can. Then measure how it meets the requirements - don't measure things just because they're there or easy to measure - and improve what you're doing so it meets those requirements better.

Plan - Requirements - Design - Deployment - Operation - Improvement - Plan is not as snappy as Plan - Do - Check - Act, but it's more acurate: PRDDOI rather than PDCA.


Service governance, holacracy and design

Adapt and adopt has, rightly, been the approach ITIL has recommended to service management, and ITIL, I think it is good advice for all frameworks. In the 5 ITIL 2011 books, 'Adapt' and 'Adopt' appear in every volume - 'Adopt' in 210 sections & 'Adapt' in 96.

ITIL has continual improvement at its heart, so it is, itself, always improving - people, rightly, point out things that usefully can be added to it.

Twitter is an odd place to chat. It takes a bit of getting used to the disjointed style - a bit like having a conversation at a cocktail party where, unlike real cocktail parties, fortunately, you can hear everybody else. Last night, I stole a little time from the work mountain I'm currently climbing, to join a twitter chat with Majid Iqbal, Stuart Rance, Charles T. Betz, Daniel Bresto, Bob Sutton, William Goddard and myself. It all started out with the question of whether Kanban was better than ITIL - the wrong question, I've thought, they're both important in different ways, and ITIL would benefit from incorporating more of the Kanban style of thinking.

The discussion ranged over quite a few areas - what ITIL actually does say - whether the advice in Service Strategy is carried through to the other volumes of ITIL - whether ITIL is wrong, deliberately, to avoid discussing organisation. Near the end, Bob Sutton mentioned the holacracy of Zappos (I'd spell it 'holocracy', from the English prefix holo- from the Greek ὅλος ‘whole, entire’ - but it's actually from the Greek όλα, 'all'). For me this tied it all up quite neatly.

'The fault, dear Brutus, is not in our stars, but in ourselves, that we are underlings', was how Shakespeare put it in Julius Caesar. Holacracy is an anarchic way of running a company (I couldn't say 'organising' or an 'organisation', because that's part of the point, it isn't an 'organisation', it is self-organising people), that offers some interesting contrasts to the conventional social hierarchy (there's a nice discussion of it here: http://www.fastcompany.com/3024358/bottom-line/no-managers-required-how-zappos-ditched-the-old-corporate-structure-for-somethin ). As with most things, this isn't a new silver bullet to be jumped upon as the answer to everything - adapt and adopt, remember.

However, it does give a clear picture of one aspect of 'the problem' - if not the whole view of it, which might not be something anybody can see. As I see it, the problem is this:

Workers do not wish to be governed

Governors do not wish to govern

This is a matter of observation, and at the heart of much of what is wrong with the attitude, behaviours and culture of many organisations. The board likes to believe it is in control, but it surrenders (it doesn't delegate, which would be a good thing - but much more difficult to do) governance to the executive, to managers, in the case of IT, to IT - hence talk about 'IT Governance' in Cobit. They're trying to do what the board ought to be doing - which is why, though there is much excellent stuff in Cobit, it, ultimately, doesn't work, unless it is a part of genuine corporate governance.

So, who does want governance? Should we, as consultants, experts in service management, or IT, or policy, be upsetting the applecart by trying to force organisations to go somewhere that they don't wish to be?


The people who want, and need, and require (an important word, because that particular 'require' must be part of the requirements used to design services to solve business problems to produce value) are. The other stakeholders - namely:





The world at large, the rest of us, who are affected by the outcomes (as the Adaptive Service Model, ASM, makes clear, the actual result of a service, including all the unexpected and uncontrollable consequences, as well as just the service outputs).

The importance of the King Commission is that it recognises just that. Corporations have an obligation - they are obliged to the us real humans because we've given them the right, by means of the legal fiction that they are people, to be citizens - to act as good corporate citizens.... Really act.. Not just say they'll act.. Not just fill in a mountain of word documents saying that it is their policy to act.. but actually, day to day, govern themselves so that they act as good corporate citizens.

How can they do this? Boards, at least many directors on many boards, shy away from their responsibility to understand what is going on - in the past they even got away with saying (in court when it had all gone badly wrong) that they knew nothing about the finances of the company, they left all that stuff to the finance director. Similarly board directors like to leave IT to the IT director (if the board is sensible enough to have one) or to the CEO, an employee, a person who is supposed to be governed by the board. The CEO is the Chief Executive Officer because his job is to execute the will of the board.

The answer, of one part of the answer, is that, yes, directors will have to either retire, take up another job or learn how the company functions. They must understand the finances and understand the services.

This is where Service Governance comes in. The service portfolio (not, notice, the 'IT Service Portfolio'), is the portal through which the board can see the company operating. They can understand which services are contributing good value to the stakeholders for reasonable cost and those that are doing the opposite - and, as the governors (the word comes originally from 'A steersman, pilot, captain of a vessel' [OED]) they can steer the ship by dictating what shall by done to the services that are not shaping up and also to provide the ship with the new services that it will need to, for its voyage, design, develop, transition and operate, under continual improvement, in order to increase the value that the company delivers to its stakeholders.

This has the interesting side-effect of freeing up the individuals in the organisation - it deals with the problem, stated above, that workers do not wish to be governed and governors do not wish to govern. The service portfolio becomes the map of the journey, a living map, that the board can use to govern the route, and the workers can use, operationally, to decide how to follow it. This allows for a holacratic company, or organisation. Teams can organise themselves in the way that fits the purpose best - not necessarily an old-fashioned, rigid, social hierarchy. All the advice in the ITIL books and from other frameworks is of value, the structure of services and ways of working and the understanding of the capabilities needed to respond to demand are all part of this dynamic whole, instead of, or as a parallel alternative to, the conventional hierarchies, where they make sense.

Service governance allows services to become the compass, the navigation, the controls and the measurement of success for the organisation to become a good corporate citizen.



University of St.Gallen & Copenhagen Business School ITIL self-assessment study

"A number of itSMF SA members participated in the University of St.Gallen & Copenhagen Business School ITIL self-assessment study. The universities thanks you for your participation and have since improved the assessment. Members are encouraged to take part in the study by going to :http://itil.selfsurvey.org which will be available until the end of June this year. The scientists are now able to provide an updated assessment with more detailed benchmarking functionalities and participants now receive an individualized gap analysis which amongst others:

- differentiates between different types of IT service providers (internal, shared, external),
- provides benchmarks on ITIL domain level as well as on a process level,
- and summarizes the gaps in a roadmap indicating the most urgent improvement needs.

The results of this international survey so far was quite insightful – once again South African companies don't have to stand back for anyone globally and although the level of maturity is sometimes below the global average – it is only marginally so. The results are shown below.






A chance to contribute to improving Business Analysis

The public review of the IIBA's BABOK started yesterday. The announcement is here:


There are a number of guides to Business Analysis, and the BABOK is one of the most popular. It is good that it is created with public consultation.

Both service management and business analysis suffer, often, from mutual incomprehension, so I think it's important that any future advice to either community includes references to help understanding the other.

I made the point a while ago in this paper:


I contributed to the new version of the BABOK during the first round, suggesting a number of areas where the  service management perspective was missing. This review version includes the word 'service' a lot more, rather than just 'system', but, it seems to me, that, this is not enough.

So I'd urge you to help improve the communication between these communities by contributing suggestions above.