The meaning of service
I’m occasionally accused of being overly pedantic about definitions in enterprise architecture, but there are times when it matters a lot. This came up this morning in a long-running thread on LinkedIn, where someone had been telling me off for using terminology that was not the same as routine business usage. To illustrate his point, he provided a long list of supposedly standard business meanings of key architecture-related terms, part of which was as follows:
10. Services, in the process context, are a synonym of Activities
11. Services, in the capabilities context are a level below Capabilities
12. Functions, in the capabilities context, are a synonym of Services
13. Functions, in the processes context, are a synonym of Activities or Services
Sure, these are the kind of ‘definitions’ that we hear often enough in business; but read that list again and ask yourself if it actually makes any sense at all. Everything is a supposed synonym of everything else, but different, but the same, sometimes, possibly, depending-on, sorta-kinda, ish… Could you build a viable architecture on definitions that are as random and polymorphous as that? I really wouldn’t recommend it…
Let’s take just one of those examples:
10. Services, in the process context, are a synonym of Activities
To be blunt, this is garbage. A service, literally, serves something or someone in some way. An activity is, literally, an activity. Jumping up and down and waving your arms about is an activity. Drinking a cup of tea is an activity. Crying your eyes out is an activity. Yet whom does it serve? How? Why? So how is ‘Activity’ an exact synonym for ‘Service’ in any context? The short answer is that Service is not a synonym of Activity – and it confuses the heck out of the architecture and everything else if we say that it is. So don’t do it!
Let’s be more precise about this, and work towards definitions that do make sense across all required contexts:
An Activity is just action: something happens here. The term says nothing about purpose, or content, or anything else: it’s just an activity.
A Capability is the ability to do something, at some specific level of skill and competence. It doesn’t say anything about what is to be done, or why. It’s also only an ability to do something, not the Activity of doing something. Note too that, on its own, a Capability literally has no function – it simply is.
A Function is where something will be worked on, or changed. It says that change will occur here, on what assets, guided by what parameters, driven by what protocols, monitored by what metrics. It doesn’t says how the change will be done – it’s simply a placeholder for “something changes here”.
A Service brings together a Capability – which can do something – and a Function – where something can change – to guide and define the Activity that each of those requires. (To put it another way, a Service adds protocol and purpose to Activity.) It’s a place where value will be created in some way; it offers a value-proposition to its ‘world’.
A Process is a pathway that traverses Services in some kind of sequence (linear or otherwise, directed or otherwise), creating a value-chain that (in principle, at least) should deliver some form of aggregate perceived-value.
Those definitions work in the same way at every level of abstraction or granularity, from strategic down to microcode. The definitions in that earlier list above may match common business (mis)usages, but they change at every darn level. Which types of definitions would you think are more useful/reliable/whatever in an architecture that does have to traverse every level of the enterprise?
So why does this matter?
In business, an Activity is something that the business pays for.
A Service is something that someone else may be willing to pay for.
It’s all too easy to have Activities that have no links to any Function, and therefore cannot be linked into a Service that anyone would be willing to pay for.
It’s all too easy to present a Function that has no Capability behind it, and hence cannot deliver a Service.
It’s all too easy to have a Capability that is not linked to any Function, and hence represents wasted opportunity.
It’s all too easy to define a strategy where the real-world Services required in that strategy are not or cannot be implemented (i.e. inadequate cross-links moving down the layers of abstraction).
It’s all too easy to have real-world Activities that do not link to any strategy or business-purpose (i.e. inadequate cross-links moving up the layers of abstraction).
Identifying these and similar mismatches, and showing how to resolve them, is where enterprise-architects can add a lot of value to a business.
Tom, I completely agree with you regarding the need for clear definitions. In preparing my thesis, which is exploring synergies between IT Architecture methods and Service Design, I have favoured the following simple definition of a service: “a provider/client interaction that creates value”. It originated in IBM.
Hi Simon – thanks – definitely useful! To me it seems that it’s the same entity all right, but viewed in a different way: the difference between the two definitions is that yours is about the service as seen from ‘outside’ – the interaction, or what it does – whereas mine relates to the service as seen from ‘inside’ – its structure, or what it is. We would use one or other definition dependent on the role and perspective in scope.
“It’s all too easy to define a strategy where the real-world Services required in that strategy are not or cannot be implemented (i.e. inadequate cross-links moving down the layers of abstraction).
It’s all too easy to have real-world Activities that do not link to any strategy or business-purpose (i.e. inadequate cross-links moving up the layers of abstraction).”
HERE HERE
Thanks Tom, this is terrific.
Can you help me out a bit by perhaps offering a couple of examples of a ‘function’ at various levels of abstraction? I understand it from a software/mathematical level, but how would it apply to, say, a call centre department?
Mike – glad this is useful. 🙂
“Can you help me out a bit by perhaps offering a couple of examples of a ‘function’ at various levels of abstraction? … how would it apply to, say, a call centre department?”
Zachman 2: business-model:
The call-centre acts on relational-assets (e.g. relations with customers) – it probably doesn’t act on any physical-assets for example. It uses virtual-assets (information about the customer) and will probably change some of those too, but that’s not the primary focus of the function. A marketing-oriented call-centre will also reference aspirational-assets (brand, and customer-relationship with brand), but may not directly act on those assets. The function has an interface with the service-client (i.e. the customer or potential-customer) but is not described in detail at this level of abstraction.
(Note that we can describe the function separate from capability at this point: we know we need a call-centre function, but we don’t yet need to know what skills will be needed to operate it.)
Zachman 3: logical-model:
We specify the customer-segments for the call-centre function (relational-asset + decision), and the reasons for their connection with the call-centre (decision etc), which helps to specify more of the probable external function-interface (i.e. what will be perceived as the service-interface) and also the information-needs (virtual-assets), requirements for the information-system (i.e. IT-services, as composite of function + capability + virtual-assets etc) to support this abstract function, the reporting-metrics (virtual-asset + decision, with again their own IT and non-IT services), physical and/or virtual location (call-centre building, phone vs net vs in-person), and so on.
(At this point we do need to look more closely at the kinds of skills and skill-levels that would be needed to enact this function as a service.)
Zachman 4: physical model:
A function acts on assets via an interface of some kind: so here we need full detail of the technologies to be used, the actual client-segments to work with, the categories of issues to be addressed (and the mechanisms to forward issues that this function will not address), the actual physical- and/or virtual-locations of this function (and relational-locations in terms of its reporting-relationships in the management-structure, escalation-structure etc), plus all of the delivery-mechanisms (phone-system, screens and operator interfaces, script-delivery engine, search-mechanisms) plus all of the escalation-mechanisms and reporting-mechanisms and so on. A lot of detail – yet in essence it’s just an instantiation or realisation of the same function that was described at Zachman-2.
(And here we must also have full detail of the capabilities required, including the actual or effective skill-levels provided by the operators and the supporting IT; and how these link together to deliver what the outside interface – the calling customer – sees as ‘customer-service’.)
Zachman 5: configuration:
This is the fine-grain detail of what will actually happen at each individual moment – which exact call-line, with which exact system-ID, which exact operator, which exact script, and so on.
(At the moment of action, we always have a complete composite: assets + functions + locations + capabilities + events + decisions. ‘Service’ is a conceptual bundling of function+capability with reference to changes in assets, but it’s essential to remember that everything else comes along for the ride as well! 🙂 )
Hope this helps, anyway?
FYI, I’ve linked to this post from the following LinkedIn Discussion (apologies, may not be accessible from without the ‘walled garden’:
http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=49233841&gid=1822816
Many thanks for the crosslink, Michael – yes, I couldn’t view the LinkedIn discussion, but the group itself looks interesting. 🙂 (Pity I’m already way overloaded in LinkedIn as it is, though… 🙁 )