Service, function and capability (an addendum)
How can we clarify the confusion over service, capability and function in enterprise-architecture models?
Andrew Marosy made a comment to my previous post on this that really needs to be brought out here in full:
You can also visualise a Service as being a realisation of a Function, i.e. the people/resource/capability, process, application data and technology to make it happen.
There is also a lot of value to be gained at working at the “atomic business function” level, i.e. the smallest level of useful work.
For an atomic business function, in addition to recording the name, objective, description and measures/emergent properties, we can specify a) the structural business rules/requirements (i.e. semantic/logical data model and or business ontology) and b) the information flows between them.
To which I would reply:
— “You can also visualise a Service as being a realisation of a Function“. All I can say is “Duh…” – that inversion is so obvious and so important that I’d, uh, completely missed it… 🙁 It’s exactly correct, and makes the relationship a heck of a lot of easier to understand.
— “‘Atomic business function’… the smallest level of useful work” – again, that’s a good way to put it, though the boundary indicated by the qualifier ‘business’ is always going to be an arbitrary choice. Every level of work is ‘useful’: each level builds upon the levels below, until it reaches a point where we decide that it’s both ‘useful’ and ‘visible’ – a level at which it’s significant enough for us to take detailed notice.
— “For an atomic business function…” – that’s essentially what we do in the simple-notation for Enterprise Canvas. The Service entity represents whatever’s visible of the service in real or abstract form – and the raw outer-shell of the service is, in essence, the function’s interface-protocols and service-level parameters. The Exchange entity (and flow-relationship) would represent flows and/or interactions between Services. Note, though, that these may be flows or interactions not only of information, but of any Asset-types, including physical, virtual, relational, aspirational and any of their composites.
Also given that pairing of function and service above – Service as a realisation of Function – it’s possibly safer, or less-confusing, to describe this ‘atomic’ layer not as a business-function but as a prototype for a realisable business-service. We’d do this because, to re-invert that pairing, the function is in turn only a partial and intentionally-incomplete description of the content needed for the complete realisable service.
To paraphrase one of my earlier aphorisms, “a Service is usable to the extent that it is architecturally complete; a Service-prototype is re-usable to the extent that it is architecturally incomplete“. The Service is realisable – able to act in ‘useful’ ways in the real world – when all of its service-content components are fully described and linked together in appropriate ways; yet once we unlink those service-content components, or intentionally blur their descriptions into more abstract form – such as in the interface-prototype represented by the function – the service becomes reusable, to make it realisable in a different way or for a different purpose.
Again, many thanks for this, Andrew – I think it helps a lot.
This sounded great: a service is a realization of a function
But then I went to check the definition of a function:
a function is an external view of a service ???
What if:
a capability is the ability to do something valuable
a function is a realization of one or more capabilities
a service is a realization of a function
a service instance is the realization of a service
Have I misunderstood something?
@Aale – you’re right, there’s a circularity of definition here, and a necessary circularity at that, because the definitions need to balance out whichever way we look at them. Yet at first sight it doesn’t quite seem to connect up, as you’ve said.
The cause of confusion here is the word ‘realization’, because it’s actually being used in several different senses: potential versus actual, and class versus instance. We can illustrate this with the definitions you’ve used above.
— “a capability is the ability to do something valuable” – agreed. More precisely, though, it’s the ability to do something: whether that ‘do something’ is considered ‘valuable’ or ‘not-valuable’ is a (business)-decision that’s separate from the capability itself – a decision that belongs more to the ‘value-proposition’ of a service, rather than the capability as such.
— “a function is a realization of one or more capabilities” – sort-of, but not really. It’s more that a function is an interface through which or for which a capability may be applied: it’s closer to the IT sense of ‘Application’ rather than ‘realization’.
— “a service is a realization of function” – I’ll have to agree with that one, ‘cos it’s where we started! 🙂 The catch is that it’s ‘realization’ in several different senses, and we need to be clear as to which is which. In one sense, for example, the function on its own is a literally empty promise; it’s only when all of the other service-content components (capability, asset, location, decision) are brought together in response to events (which I usually also describe as sort-of ‘service-content’) that the promise of the function can be realized. In another related sense, the function alone represents non-realizable potential for service-delivery; the complete service represents realizable potential for service-delivery.
— “a service instance is the realization of a service” – again, sort-of-but-not-quite, because this blurs together two different meanings of ‘realization’: abstract-to-concrete (the potential for service is realized through service-delivery), and class-to-instance (the abstract notion of ‘the service’ is realized via instantiation). Hence, to expand your statement above, “a service-instance is an instance of service-delivery as a realization of (the potential/promise of) service”. (There’s also another meaning of ‘realization’ that’s often blurred in with this: the way in which a process is realized via a choreography of relationships between and sequences of instances of service-delivery.) Again, we need to be clear as to which meaning is which here.
I hope that makes a bit more sense, anyway?
There goes my attempt at nice simplification 🙁
But what I think I am getting is that I have been trying to answer the wrong question. I do not really need to define what is IT service because everything what IT does is service.
The real need may be the classification of IT services in a manner that IT people can understand and apply.
@Aale: “There goes my attempt at nice simplification” – oh… my apologies…
You’re right: we do need context-specific simplifications. (The real reason for all of my seeming-pedantry is that it supports cross-context simplification – which is often a very different need.)
@Aale: “The real need may be the classification of IT services in a manner that IT people can understand and apply.”
In IT-architecture, the most common classification-scheme is ‘Infrastructure’, ‘Application’, ‘Data’ and ‘Business’, where the latter is essentially an arbitrary placeholder, a ‘none-of-the-above’ category. (I don’t have much objection to that classification as long as it doesn’t pretend to cover the whole of the enterprise, as IT-centric ‘enterprise’-architecture usually does.) For IT service-management, though, you’re going to need a much broader classification-scheme, to cover physical-services such as buildings and power-supplies and other ‘facilities’; to cover change-management and the like (as in Archimate’s ‘Implementation and Migration’ extension); and also to cover value-themes such as security, reliability, safety and so on. If you’re willing to tolerate more of my, uh, pedantry, there’s a systematic process to explore this in my rather long how-to post ‘Enterprise Canvas as service-viability checklist‘ – I hope it helps?