Link: http://weblog.tetradian.com/2011/09/29/what-is-boundary-of-a-service/
“What would be the smallest service? Did anyone ever look for the/a boundary condition of a service?” – an important pair of questions from Jan van Til in an earlier comment here.
The first question is a bit difficult, because the only correct answer would be that ultimately it’s right down at the sub-cellular level – which isn’t likely to be much help in most business-contexts…
So in practice the way we need to answer that question is actually the same way we would answer the second question: the ‘smallest’ service, and the boundary-condition for a service, is whatever and wherever we choose it to be.
I’m not being facetious here: I’m serious. This is actually a crucial point in all service-design – yet it’s a point that many people seem to miss.
First, another key question: what is a service? The short answer is that a service is ‘something that serves’. Which again might at first seem a bit facetious: but seriously, it’s not, because it encapsulates everything that really matters here. At this level, we need to keep to the abstract: hence we deliberately don’t say what the delivered service might be, but instead focus on the fact – or action – of ‘service’. And a service is a service because it serves: and, usually, that it serves or services the needs of something other than solely of itself.
Yes, very abstract – but actually very important from an architecture perspective, because it provides explicit constraints whilst at the same time keeping everything open.
To give a concrete example, consider a kidney. (Okay, you might prefer not, but it’ll do as an example, surely? 
) What does a kidney do? From a services perspective, what does it provide? Assuming a living body, the kidney provides a number of services, such as removing excess water from the system, filtering out impurities, breakdown of certain by-products of digestion, some specific functions for the immune-system, and so on. We can then look at various service-interfaces at that layer (mainly the bloodstream and the bladder), the biochemical protocols and exchanges, whatever. All of this would make perfect sense to someone who’s studied anatomy, physiology and the like.
But notice that we’ve invented an arbitrary service-boundary here. We could go up a level, and bundle all of the functions of the kidney under the heading of ‘digestion services’. Or we could go down a level or two, to the individual services that the kidney provides. We could go down quite a lot further, such as to the ‘containment-services’ provided by certain types of cells that denote and delimit the outer edge of what we would generally think of as ‘the kidney’. Yet there’s nothing concrete or explicit that would always define for us ‘the‘ service-boundary: instead, we choose the level, and the service. The boundary of the service is whatever we choose the boundary of ‘the service’ to be.
So, to bring this back to business: what is a ‘business-service’? What denotes the boundary of a ‘business-service’? In practice, we’ll see exactly the same as with the example of the kidney: a ‘service’ is something that serves in some identifiable way, that we happen to describe as ‘a service’.
That’s it: there is no explicit ‘the boundary’ for ‘a business-service’. Which is why we end up with all sorts of names and terms being used, often interchangeably, for all sorts of different ‘services’ within business, with all manner of intense arguments as to which term fits what and which service is ‘above’ or ‘below’ or contains others, and so on. For example, look at all of the chaos and confusion around the following terms:
- business service
- business unit
- business process
- business function
- business capability
In architecture, each of those terms would have a distinct meaning: for example, in Enterprise Canvas, a service is a conjunction of function (a description of what should be done) and a capability (the ability to do something), whilst a process would chain various services together to deliver an overall effect on something. But in most business-usage they’re just alternative terms for ‘a service of some kind, at some level of abstraction’ – with different terms used almost at random as sort-of-synonyms for each other, at different levels of granularity or abstraction. Hence all the confusion, because that arbitrary scrambling makes it very difficult to work what the heck any of those terms actually mean in any given context…
But the quick solution is to recognise that in practice all of them are ‘services’. And once we accept that we are responsible for choosing ‘the boundary’ of a service, suddenly things can get a whole lot simpler. Choosing a boundary will itself imply the service-interface for that particular view or granularity of service. Identifying the interface then also leads us towards identifying the exchange-content, the interface-protocols, and the probable functions and capabilities that this service would require. And because we have that choice, we can move any or all of these around as appropriate, for better fit to what we have available in our architecture or whatever, simply by choosing a different boundary for the service. The boundary isn’t something that’s fixed, predefined, preordained: it’s our choice.
(By the way, we can see exactly the same kind of thing happening with the ‘mote’ concept in the metamodel-structure that I described in earlier posts. Several people asked “what is the boundary of a mote?”, “how big is a mote?”, “which metamodel layer does a mote sit in?”, and so on. The actual answer is “whatever we say it is”: it’s determined by our choice of the context, not by the structure itself. Technically, the mote-structure is defined at the M3/M4 level, but in fact any mote could be used directly at any layer, right the way down to the M0 model-level. And the size of the mote is “whatever it needs to be”: a tag-mote, for example, is tiny – we could almost describe it as being at the atomic level – whereas an complete model and its entire change-history would also be represented by the full related-mote tree of another single mote.)
Hence we come back to the core theme of a service-oriented architecture: everything is or delivers a service. Again, that applies at every level: in Enterprise Canvas, for example, the ‘service-in-focus’ might be anything from a single line of code to the entire enterprise – there’s no inherent difference other than as determined by context. Everything is a service; and the boundary of a service is what we say it is.
Hope that makes some degree of sense?
[Many thanks to Jan for suggesting the topic – and yes, please do comment on this if you wish?]