Link: http://weblog.tetradian.com/2012/09/23/service-function-capability-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.
