Link: http://weblog.tetradian.com/2012/09/22/service-function-capability-again/
How can we distinguish between service, capability and function in enterprise-architecture models?
This is one of those perennial questions that keeps returning time and time again, and it’s one of the key confusions that Enterprise Canvas aims to resolve. But in a series of great discussions earlier this week with enterprise-architects Nenad Antic, Gerold Kathan and Vitor Mendes, I realised I still hadn’t explained it well enough: there’s one particular clarification that I need to add to the overall description.
Quick background: business-folk tend to use the terms ‘business service’, ‘business process’, ‘business function’ and ‘business capability’ as near-synonyms, which leads to all manner of confusion when we try to build common understanding across an organisation or enterprise. To get round this unwelcome chaos, Enterprise Canvas builds on the idea of ‘everything is a service’, which leads to the following assertions:
- 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)
- a capability is the ability to do something
- a function needs to be linked to a capability in order to do anything
- on its own, a capability literally has no function
- in a service-architecture, we link together a function and a capability (and various other service-content items) in order to create a service
Another way to summarise this difference is to describe it in terms of the structure of service-level agreements:
- the function describes the parameters of the service-level agreement – which should remain essentially the same for all implementations of the service
- the capability determines the parameter-values to be assigned to those parameters in the service-level agreement – which are likely to be different for each implementation of the service
One complication here is that for IT and machines, ‘function’ and ‘capability’ often have a one-to-one correspondence, and are so deeply intertwined that many people would fail to recognise any difference between them. But the picture is very different for real people: there, there’s very definitely a many-to-many correspondence between capability and function.
[By the way, one of the fundamental reasons for the inefficiency of Taylorism as a work-design model is that it treats people as machines, assigning just one capability to each human business-function, as a ‘role’ or ‘job-description’ – in effect locking out all other capabilities that that person might possess.]
So to build an architecture that makes use of people’s skills and capabilities, and to enable load-balancing and business-continuity and suchlike that switch between automated and ‘manual’ implementations of a process or service, we need to treat function and capability as distinct facets of service-content.
For much of our routine modelling, we’ll only model the service as service, perhaps with summaries about its various flows and exchanges with other services, but without much interest in any of its internals:
But once we do want to know more than just a basic ‘white-box’ summary about what the service is and does, and how it works, we’ll need a more detailed description of the service-content – including the functions and capabilities of the respective services. In effect, the function is a more-detailed surface-layer view of the service, whilst the capabilities are hidden away somewhere within its internals:
Yet notice the catch here: from the outside, and to the unaware eye, the function looks exactly the same as the service. Which leads all too easily to the mistake of thinking that they are the same thing, that the function is the service – which it’s not. On its own, a function is just an empty shell, a kind of declaration of desired intent; it’s only when it’s combined into a complete service, with all the other service-content components, that the function can then actually do something useful towards that desired intent. Function is not the same as service, which in turn is not the same as capability: and it’s best all round if we’re clear about those distinctions.
Yes, I know all of this might sound like Yet Another Piece Of Tetradian-Tom’s Prepackaged Pedantry, but seriously, this kind of precision really does help when we’re trying to tease out the tangles of miscommunication around services and the like in our various architectures. If you keep consistently to the definitions in Enterprise Canvas, it really will make that part of your enterprise-architecture work a heck of a lot easier – I promise you that. Fair enough?
