Why I believe in SPACL

Sparkle by Ian Varley at Flickr - Some rights reserved

I believe in SPACL (Service Portfolio and Catalog Language) for it is focused on the service, on the people that use them. And it is in the middle of quite a lot of Service Management activities.

It is open, freely available and addresses hard problems for customer, service providers and vendors:

• Aims to define clearly what is a service and other too often conflicting Service Management core concepts
• Covers interoperability needs. It includes independent specification for service offerings, service requests. This is vital for cloud models, virtualization, multiple and changing supplier scenarios.

So. Visit them, get in. Help balancing it more for you (vendors “sparcled” it – someone had to!). Do something.

ISO 20000: A strange case of new or changed services

20000 squid Nautilus viewbay from Jules Verne masterpiece "20000 Lieues Sous les Mers" at Commons Wikimedia

Back to governance and ISO 20000, a rather different one from the previous Service Management System examples can be found within 5 Planning and implementing new or changed services.

This section marshals top management in to play regarding decision on significant changes to existing services or new ones (the last one truly is strategic thus should not be handled like other Changes are).

The idea behind this higher level process is to address a recurrent issue: the adequate handover of in-house development projects final product to the “other side”, the service management domain.

Although project deliverables are usually formally accepted, their introduction into live environment not always follows a similar clear approval path and neither development management or service management are independent advocates on this.

By making new service approval go through this steps, top management becomes an active decision maker. And service management will know about new services of big service changes way sooner.

Here I think ISO 20000 favors [using Peterson’s approach to governance] a combination of processes, relational mechanisms (promoting collaboration between conflicting departments)  and IT structures (like IT project steering committees and IT strategy committees for communication and participation of all interested parties) that lead to a particular governance model.

Interesting example on how IT structures  can tie to processes at various levels (strategical/tactical/operational).

Governance lurking on ISO 20000

Platanus bark, by Vilseskogen at Flickr - Some rights reserved

There’s some governance on those ISO 20000 clauses.

The most obvious is under Requirements for a management system which features a not-so-subtle first section:

[3.1 Management responsibility]

d) appoint a member of management responsible for the co-ordination and management of all services

Next, the first section of the Deming Cycle has this for the service management plan:

[4.1 Plan service management (Plan)]

d) the framework of management roles and responsibilities, including the senior responsible owner, process owner and management of suppliers

And still within Deming Cycle, for the implementation phase:

[4.2 Implement service management and provide the services (Do)]

b) allocation of roles and responsibilities

[side note: I’ve been at Lynda Cooper’s ISO 20000 Audit training and it has been though provoking. Lynda really gave a crisp distinction between service changes and components changes. More on this in the next post]

Have the ITIL elephant in small portions

One way to do it for a given process is to group its setup and maintenance activities like this:

Startup – Here you can put process description including roles. Don’t go too far – you want people to understand it. Most processes have one or two key well-defined deliverables that can signal the initiative and make it easier both sharing and get momentum for next phase. Here you concentrate on documenting (proof of intention).