A couple of weeks ago I was party to another event, this time hosted by IBM. At short notice I was asked to facilitate a session on defining services, which was interesting in the extreme as it very quickly became clear in the earlier sessions that there was no clear definition of what a service was—particularly as there were two types of people in the room—business analysts and technical architects.

So, I decided to take a different tack. Rather than trying to fix a definition of service, I thought we would go round the room and ask what characterised a “good” service. Here’s what we came up with:

• Value – the benefits of accessing a service should outweigh its costs.
• Reusability – it should be possible to access the service repeatedly, with the same level of interaction and service quality.
• Meaningfulness – it should be possible to describe the service in clear, relevant terms.
• Autonomy – the service should be cohesive, i.e. clearly bounded.
• Independence – the service should also minimise dependencies with other services.
• Contract – the service should offer its own guarantees in terms of what it delivers, and how: such terms should be subject to prior acceptance by the service user.
• Uniqueness – the service should minimise overlaps with other services.

With hindsight, there is possibly some honing that could be done with the above list—the difference between “Autonomy” and “Independence” for example, is not all that clear. What was interesting however, was that even as the debate raged around what a service should look like, there was relatively little controversy about what separated the wheat from the chaff. For organisations looking to develop their own service strategies, this would appear to be a good place to start.