Why service, function and capability
Blog: Tom Graves / Tetradian
Ah definitions, definitions – so many to choose from!
But somehow, only a limited number of labels to go around, to share out amongst all those definitions?
Which means that people end up using the same labels for different things, and different labels for the same things, and then wonder why we get into such a mess of miscommunication.
Oops…
Which kinda suggests that along with the definitions themselves, it’s probably a good idea to say why we choose those definitions – and why we use that label with each definition, too.
Hence this post.
For some of the definitions I use, anyway. Or, to be specific, the definitions that I use for service, function and capability.
(This post is only about the why for the link between labels and definitions. For more detail about the definitions for those three terms, and a lot of other terms central to whole-enterprise architecture, see the post ‘Fractals, naming and enterprise-architecture‘. For examples on how those definitions are used in practice in service-oriented whole-enterprise architecture, see the series of posts on service and Enterprise Canvas, starting with ‘Services and Enterprise Canvas review – 1: Core‘.)
Where this started was that Luis Mariottoni came across my now quite old (September 2012) post ‘Service, function and capability (again)‘, apparently liked it, and then decided to tell people all about it, on LinkedIn and Twitter. (Thanks, Luis!)
Which in turn led Archimate-grandmaster Gerben Wierda to add another comment to the already great discussion on that post:
If you write:
– everything in the enterprise is or represents or signifies a service
– a process links services together in some way to achieve some kind of outcome
– a function is an external view of a service – in effect, a description of its interfaces (‘black-box’ view), often together with a summary or overview of what it does and how it does it (‘white-box’ view)
you are exchanging the terms ‘service’ and ‘function’ with respect to how I’ve seen it used so far (e.g. in ArchiMate but also elsewhere).I’ve seen service more often described as the external ‘side’ of some behaviour (such as a process or a function). Service is what the user of the service sees (uses).
I’ve also often seen a process described as linking together functions to produce some sort of outcome. Anyway, there are many, many ways to do this and there is no agreement between practitioners, also because in today’s modern complex landscapes there is both IT behaviour and human behaviour closely intertwined and the IT-culture and the Business-culture have separate languages on the subject.
I like to see a service as ‘the usable part’ of a function/process. The service cannot exist separately from that what makes it happen (unless you define service as the ‘requirements’ and not the ‘actual service provided’).
Or, in short, and in less-polite form, “You’ve got it all wrong, Tom!” 
But have I?
Hmm… – kinda “It depends…”, I’d suggest?
And that’s the real point, because, actually, this is a great illustration of the difference between single-domain architecture and whole-of-context architecture. There are short-cuts and easy fudges that we can get away within a single domain, that we can’t get away with across the whole of a large, complex context – and terminology is definitely one of them.
In most cases it doesn’t matter much if people misunderstand each other somewhat: in fact being over-pedantic about it mostly puts people off, as Seth Godin reminded us this morning. Yet for architectures, we do need people to have a clear shared-understanding of what our technical-terms are and what they all mean. If we don’t, we risk creating our own equivalent of the Mars Climate Orbiter. And the problem becomes more and more extreme as the communication necessarily extends across more and domain-borders.
Mars Climate Orbiter is perhaps the most famous example of this. The US aviation industry has long-since standardised on its own literally-peculiar ‘English units’: inches, pounds, pounds-force and so on. Meanwhile, the rest of the world, in just about every industry, including the space-industry, has long-since standardised on ‘SI units’: metres, grams, newtons and the like. The spacecraft manufacturers were from the US aviation-industry, and specified thrust in pounds-force. The flight-controllers were from the space-industry, and specified thrust in newtons. No-one, apparently, had thought to cross-check – because to each of the players, it was ‘obvious’ that these were the units to use. The end-result was embarrassing, sad, and very, very expensive…
So, to here. Gerben sets out his view thus:
you are exchanging the terms ‘service’ and ‘function’ with respect to how I’ve seen it used so far (e.g. in ArchiMate but also elsewhere).
I’ve seen service more often described as the external ‘side’ of some behaviour (such as a process or a function). Service is what the user of the service sees (uses).
I’ve also often seen a process described as linking together functions to produce some sort of outcome. … I like to see a service as ‘the usable part’ of a function/process.
Right, okay, that’s one position, one set of definitions. He’s also telling me, in effect, that I’m wrong for not using the same label/definition pairings as these. And that the main justification there for asserting that I’m ‘wrong’ is that it’s the other way round from the way that Archimate does it.
Hmm… – kinda red-rag-to-a-bull time, that one. Allow me to be blunt here: I’ve never seen anything resembling sense or consistency in Archimate’s terminology – or structure, for that matter. It’s a mess. Even at first glance it’s a mess; and digging deeper down into its internal anatomy, as I did in that long post a few years back, demonstrated just how much a mess it really is. True, it did start off with a couple of very good ideas, but it got dragged off into the IT-centric booby-trap early on, consistency and logic falling apart very quickly after that, and it’s been downhill all the way from there – especially since Open Group barged into the story. To again be blunt, there’s almost no part of Archimate now that is not a scrambled, inconsistent, IT-centric mess: good example of well-thought-through terminology it definitely ain’t… So let’s just not go there, okay?
Sigh.
The broader argument that “everyone else in IT does it this way” is somewhat more defensible, up to a point – as long as we stay only in that one domain. Once we do need to spread out beyond that one domain, we’re gettin’ dangerously close to Mars Climate Orbiter again. In fact Gerben himself makes exactly this point:
Anyway, there are many, many ways to do this and there is no agreement between practitioners, also because in today’s modern complex landscapes there is both IT behaviour and human behaviour closely intertwined and the IT-culture and the Business-culture have separate languages on the subject.
Yes, they do: and that’s why we need to take some real care about this – otherwise, again, it’s Mars Climate Orbiter time.
To put it at its simplest, what we really need – and what I’d aimed for in my own definitions – is a terminology-set that would be completely consistent:
- at every level
- in every usage
- in every aspect of the enterprise
- for every instance
- in every form of fractality
Virtually every other attempt at service/function/whatever terminology that I’ve seen has thrown away at least one of those concerns, and often all of them. Which doesn’t help…
The trade-off (and yes, it is a trade-off) is that something that’s consistent is going to clash with other terminology-sets wherever they are either inconsistent, or themselves clash with other terminology-sets. Which means that we’d need ‘translation’ wherever there’s a clash – again, exactly as for what should have happened for Mars Climate Orbiter. And that’s fair enough – as long as we do remember to expect it, and expect the resultant need for explicit ‘translation’ wherever required. But the key point here is that a consistent terminology-set, because it’s consistent, can act as a known, common, shared reference-point around which all other conflicts and clashes can be resolved.
In short:
- for a domain-architecture, and within a domain-architecture, we can use whatever terminology-sets we like
- for whole-of-context architectures, and for links between domains, we can’t use “whatever we like” – we must use terminology-sets that are fully anchored and internally-consistent, to act as a stable base for any and all cross-links
The US aircraft-industry uses units such as inches, pounds, pounds-force, and gallons. Within that industry, it all works well enough. But there’s no direct translation between any of those units – instead, there are horrible ‘a cube of five-and-a-bit of those makes seventeen of these’ crossmaps, and so on. And the pound isn’t the same as the French livre, which translates as ‘pound’ and is likewise a measurement of weight, and US gallons aren’t the same as so-called ‘Imperial’ gallons, and short-tons aren’t the same as long-tons even though they’re both measured in pounds… Well, you get the idea: it’s a mess – especially if we need to translate between domains.
So the practical way by which we sort out that kind of mess is that we turn to the SI-units set. Which at first might perhaps seem to make some odd choices – or unfamiliar choices, anyway – but has the huge advantage that it is internally-consistent. Not only can we convert inches to metres, and pounds to grams, and pounds-force to newtons, and gallons to litres, but we can also crosslink between metres, grams, newtons and litres, in a clean, simple, completely-consistent way. It’s a whole-of-context terminology-set, in which each term and its definition is crosslinked cleanly to every other.
In other words, the kind of terminology-set that we need for a whole-of-context architecture.
Which is where we come back to service, function and capability, whose relationships I would summarise visually as follows:
Which Gerben tells me is the wrong way round, relative to the way the IT-industry typically describes it.
Yet, as Gerben also says, we could do it any way round that we like.
So, rather than arguing about which way round is ‘right’, a more useful question would be, which way round is better? – in the sense of providing better support for whole-of-context consistency?
And to decide on that, we need to look beyond the IT-industry alone. What descriptions can we find that do provide consistency across all the domains? – in the same sense, and for the same reasons, that SI-units are a darn sight more of an international-standard than the US aviation-industry’s ‘English units’?
So instead of the arbitrary and frankly-arrogant assumption that only IT is right, and everyone else is wrong, all we need to do is look around in the world that extends beyond IT alone. And what we’d typically find out there is as follows:
– Service is ‘that which serves’ – it’s active, not passive. A service serves someone’s or something’s needs. That’s a generic that’s used just about everywhere, including in most aspects of IT (such as ‘microservices’, for example).
– Function is passive – it’s waiting for something to happen. Or it’s a label attached to something that’s waiting to happen – a somewhat-mangled variant of ‘Business Unit’.
– We talk about ‘product or service‘, not ‘product or function’.
– We talk about ‘IT Service Management’, not ‘IT Function Management’ – though we might well also talk about ‘the IT Service-Management function‘, which again is a kind of label for a somewhat amorphous business-unit.
– We talk about product as a kind of frozen-service, ready to be ‘unfrozen’ to be used in service – the word ‘pro-duct’ literally as ‘that which leads towards’.
– In mathematics, a function is a placeholder for ‘something that will happen’ – for example, ‘outcome = function(withasset1, withasset2, usingthisflag)‘. There is functionality behind the function, but the function itself does nothing at all – it’s just a placeholder.
– Functionality is, in essence, a near-synonym for capability – ‘the ability to do something’. The difference is that functionality tends to be capability that’s hardwired onto some external interface, to deliver some kind of service. In other words, functionality as capability behind a surface-level interface that is described as ‘the function’. A very common usage in IT and in some forms of physical-engineering, but quite unusual elsewhere.
– Capability is ‘the ability to do something’ – it’s the bit that actually does stuff. But it’s also fractal: capabilities can be made up of other services, which are themselves made up of functions and capabilities and more, that themselves can be made up of other services that are made up of… – again, you get the idea.
As terms, they’re used in all but random ways in general business – look at the hopeless inconsistency around terms such Business Function, Business Capability, Business Service, Business Process and Business Unit.
In IT, the terms and the meanings behind them are very often bundled together, with service, function and capability all hardwired together as a single compound unit. And because they’re all bundled together, there’s a strong tendency to use the terms as if they’re interchangeable synonyms for each other. The catch is that we can – and often do – end up with hopeless and near-random inconsistencies of terminology, especially as we switch between levels or contexts or ‘layers’.
But the key to all of this is to keep those terms consistent, and keep them separate. If we do that, we can then describe how different forms of capability can be interchanged, behind the same surface-level interface. Unless we do that, there’s no way to describe the interchangeability or substitutability that we need for concerns such as load-balancing, multi-channel switching, or emergency substitution in disaster-recovery.
The fractality and nesting of ‘capability’ can sometimes seem kinda like a cheat, a kludge, a fudge – but it works. And it’s consistent, and consistent, and consistent – all the way down, all the way round, and all the way back up again.
So that’s why I’ve ended up with definitions such as these:
– Service: literally, ‘that which serves’ – something that enables action, or takes action, to serve a need.
– Process: a perceived sequence of invocations of services, where the perceived sequence may be either structured (repeatable) and/or non-structured (non-repeated).
– Product: an asset acting as static intermediary between services.
– Asset: a resource of some kind, either used within a service or acting as a product between services.
– Function: external-facing interface for a service (‘black-box’ view), responsible for the respective protocols, service-contracts, service-level agreements etc; accepts and returns assets and other resources.
– Capability: the ability to do something (part of ‘white-box’ view of a service), itself typically made up of other services and/or products at deeper levels of recursion. Capabilities use an agent to apply an action upon a specific type of asset, using a specific competency or skill-level.
I don’t claim that this is ‘the proper and only way to do naming’ – which Gerben does kinda suggest for his Archimate-oriented version of ‘function’, ‘process’ and ‘service’. I don’t claim that it’s perfect – it isn’t, and it never can be. But at least it’s a darn good try, and it is defensible, every step of the way – in contrast to the arbitrariness and randomness of most everything else that I’ve seen.
And the key differentiator here is that this naming is consistent everywhere: the same term is used for the same type of thing everywhere, every level, every recursion, every context. Which is a lot more than can be said for anything else that I’ve seen so far… Sigh.
So, what labels do you use, for what terms, what definitions, what usages, where, and why? And can you defend that ‘why’ for each case? Over to you…
Leave a Comment
You must be logged in to post a comment.
