What is the 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?]
Hi Tom,
It does make a lot of sense! And I must emphasize that by accepting that we are responsible for choosing ‘the boundary’ of a service, not only things can get a whole lot simpler but things will also become a lot more “connected”. Which enables us to see a whole new breed of patterns which we never will see when we keep using the current complex modeling notations.
I’m busy prototyping your “everything is a service” mantra on http://peterbakker.wordpress.com/tubemapping-the-enterprise/unbundling-nestle-and-nespresso-simulation/ where I’m at the moment busy with a model of the early years of Nespresso (as a kind of reverse Enterprise Architecture practice). It is far from finished but already you can see that the model will support a new kind of enterprise architecture storytelling. Well I hope that is a bit visible because reading at the text and the pictures won’t give you the same experience that I felt while I was doing the modeling.
Therefore I would like to see more examples of models made out of only simple service concepts and hear about the modeler’s experiences. So that we are able to compare the strengths and weaknesses of different “service only”-based approaches and bring the EA toolset as a whole to a higher level…
@Tom. Totally agree – with the statement and the approach. You could extent the mantra to “everything is a service – except when we decide it isn’t” – with the emphasis on an exercise of intelligence called “decide”
@Peter. Very much looking forward to your Nespresso service model.
I would like to offer something I wrote a few years ago, which illustrates how to build a service model using an approach very similar to what Tom describes. The trouble is that it’s officially IP of my previous employer and the only public expressions are from a very immature stage. I’ll figure out how to do this – it’s far too long for a blog anyway.
@Peter, Stuart – A general point first (after a ‘Thank-you, of course!), then specific replies to what each of you have said.
The general point, and most important is that all of this is a choice. Although I’ve been saying “everything is a service”, it’s much more accurate to say that “if we choose a perspective that ‘everything is a service’, these are the implications that would seem to arise” etc. There’s a crucial difference between ‘this is a fact’ (which I’m not saying) versus ‘this is a view that arises if we proceed as if this is a fact’ (which is what I am saying).
To put it another way, my professional emphasis as an enterprise-architect is not so much on the science (the ‘truth’ of ‘how it really works’), but much more on technology (the value of ‘how it can be worked better’). So to be honest, I don’t greatly care whether or not it is ‘true’ that ‘everything is a service’; I do care that so far it does seem architecturally useful to proceed as if it is true. Yet all the way through, the focus needs to be on usefulness, not ‘truth’: the moment the mantra of ‘everything is a service’ ceases to be a useful metaphor, I’m entirely happy to drop it and do something else.
To some people that might sound a bit cavalier, even callous, but there are plenty of examples even in science where this approach is the only one that works. For example, is light a particle or a wave? The short answer is ‘yes’: both assertions are ‘true’. (In an interesting irony, JJ Thomson won the Nobel Prize for Physics in 1906 for proving that light ‘is’ a particle, whereas his son George Thomson won the same Nobel Prize just over thirty years later for proving that it ‘is’ a wave. 🙂 ) So the slightly longer answer is ‘Yes, therefore no’: both, therefore neither. Yet there are distinct and different things we can do by choosing to act ‘as if’ light is either a particle (e.g. electron to photon) or wave (e.g. refraction, diffraction etc). Same with this: if we choose the perspective of ‘everything is a service’, there are certain very useful things we can do; yet there are also cases where it’s not useful to take that view. Like the service-boundary itself, viewing anything as ‘a service’ is an arbitrary choice, chosen solely because it’s useful at the time to do so – and it’s really not to forget that!
@Stuart: re “everything is a service – except when we decide it isn’t” – I think the above would answer that? Strong agree re “the emphasis on an exercise of intelligence called ‘decide'”, also.
Would also very much like to see your work on “how to build a service model”, if you can find your way round the IP-issues (oh joys…). Thanks on that, anyway.
@Peter: “we are responsible for choosing ‘the boundary’ of a service, not only things can get a whole lot simpler but things will also become a lot more ‘connected'” – strong agree; and also strong agree re your point on patterns, and the way that some of the more useful patterns tend to be somewhat concealed in many of the existing notations (such as in Archimate or BPMN, to unfairly single out just two examples).
Am watching with great interest where you’re getting to with your Nespresso model – it’s also helping me a lot with learning about Petri Net modelling, too.