Services and Enterprise Canvas review – 1: Core

What is a service-oriented architecture – particularly at a whole-of-enterprise scope? Why would we describe an enterprise and its architecture in that way? How would we describe it? What could we use to describe it?

This is the first in a six-part series on reviewing services and the Enterprise Canvas model-type:

1. Core: what a service-oriented architecture is and does
2. Supplier and customer: modelling inbound and outbound service-relationships
3. Guidance-services: keeping the service on-track to need and purpose
4. Layers: how we partition service-descriptions
5. Service-content: looking inside the service ‘black-box’
6. Exchanges: what passes between services, and why

So, a first question: what is a service? – kind of an important question, obviously, but one that often people seem to miss…

For reasons that will become clearer as we go along with this series, this not as straightforward a question as it might at first seem – in fact it’s riddled with all manner of ‘It depends…’ and ‘Just enough…’ concerns. In practice, probably the nearest I can find to a meaningful answer would probably be this: a service is a means via which someone or something’s needs are served.

Which might at first seem kinda circular – but actually it isn’t. In any service-delivery, something is done, in support of a need, and in a way which intends (or at least purports) to resolve at least some aspect of that need: a service always implies action as a means via which someone’s needs are served. Everything devolves and develops out of that one point.

The complexities of service-design and service-architectures arise not so much from that core point, but more from two other concerns: who (or what) has the need; and what (and/or who) determines ‘resolution’ and/or ‘satisfaction’ in response to that need. We’ll explore those in some more depth as we go through this series.

It’s especially important not to get hung up on the IT-centrism that’s still so endemic in much of enterprise-architecture: a service-oriented architecture for an enterprise may include much, much more than just IT. This series of posts is not about web-services and suchlike (or not much about them, anyway), it’s about services in general – ‘services’ in the widest possible sense. It’s only once we do understand how services work at that larger scope, that it then becomes useful to work our way back down to IT again – if it’s relevant, which is not always the case…

The central theme for a service-oriented architecture is a somewhat-arbitrary assertion: everything in the enterprise is or represents or implies a service. We don’t pretend that there is nothing else: for example, ‘things’ and products and people all certainly exist. For the purposes of the architecture, though, we keep the focus on the services – either in immediate action, or indirectly represented via relationships between things, or implied in how product might be used within or as a service at some future time.

Another key is that, for this purpose, it’s essential to think fractal, not linear. Services are made up of functions and assets and capabilities that are themselves made up of other services in relation to each other, which in turn are made up of other services, and so on, and so on. Keeping track of all those interrelationships between services can be tricky, but it’d be even more misleading if we try to force the term ‘service’ to apply only to a single level, or type of implementation or interface – because then we’d have no consistent means to describe anything else, or the relationships of the whole as whole.

One of the other keys here is the distinction between intended service versus affordance – between what the initial service-designer intended, versus an implicit ‘service’ arising from someone else’s interpretation and use of what exists. Affordances arise from the ways in which the capabilities that underpin services may be re-used for other services. Out there in front of me, for example, the object atop my neighbour’s house is intended to be a television-aerial, and does work as such; but to the crow that’s sitting on it right now, it affords the service of a convenient perch. Services will often also be made up of clusterings of capabilities – and those capabilities can often be used, reconfigured and re-used in a myriad of different ways, to support different needs.

Affordance also gives rise to the concept of ‘platforms’ – related clusters of support-services that enable a variety of other services to be built on top of them. The key there is that we do not know in advance what services will be built upon that platform: what we do know – or at least believe – is clustering the respective set of support-services together in that way will make it easier to build appropriate end-services that will go further towards satisfying some end-need.

Next, what services act on is not necessarily physical. The obvious example of a non-physical service is support for information-flow provided by IT-systems and the like. But to illustrate another type of non-physical service-delivery, and also to illustrate re-use of existing capabilities for other services, take a look at this roadside flower-basket:

It was originally part of the now all-but-abandoned network of civic water-troughs for horse-drawn traffic – which is why it’s in this location, on the millennia-old London road. It no longer delivers that service, of course; the need that it serves instead is civic pride – a key asset for social cohesion and for advertising and confirmation-of-promise in this tourist-oriented town.

Another piece of street-furniture – a mail-collection box:

This is a nice example of the fractal nature of services and service-relationships: in this case, a form of service-capture and service-delivery that’s actually nested ‘inside’ another larger-scope service. What we actually want from this overall service is delivered mail – the physical thing that we send should arrive at its destination. But for that to happen, there must also be a means to collect mail that’s to be delivered. Perhaps ideally, this should be at the door – or the individual mail-delivery box, as is still the case in some parts of the US – but a shared collection-point, as in this case, provides a reasonable compromise between the needs of the customer and the needs of the mail-organisation. Despite the prevalence of email and suchlike these days, it’s still very much in use: in fact I used it the other day to mail my brother’s birthday-card – a necessarily-physical item of mail. The ‘G:R’ (‘George:Rex’ – i.e. one of the later King Georges) below the information-panel indicates that this box has been providing that service for at least sixty years, and perhaps as much as a century.

The service-level is indicated in part by the size of the slot in the mail-box: if you can get it in through the slot, and it also conforms to the pricing and other terms of the service-contract, the mail-service will deliver it. Also once you’ve put something into the slot, neither you – nor anyone else – can get it out, without access to the box’s keys: that’s important, in terms of the mail-provider’s service guarantee.

Note also the information-system elements within this service-delivery component:

— The promise of service – the days and times and times of collection – is indicated by the panel below the collection-slot. It’s static, or at least changes only very occasionally – with the organisation’s service-policy, in fact.

— The status of service – the applicable collection-day (and, in some cases, time) – is indicated by the small panel above the slot. This is changed each time the box is opened, using one of a set of small metal plates stored inside the mailbox. Note that the information-technology here is physical, not electronic – and for good practical reasons, too.

One more example – the cluster of services around a bus-stop:

Notice again the fractal hierarchies and interrelationships of services here. For example, the bus-stop is itself a service in support of the service of bus-service, as an instance of shared (‘public’) transport, in support of the service of personal-transport. Everything that we see here either is or represents a service in support of another service.

The service-cluster right here includes the bus-shelter; the telephone-box (if you can see it beneath the blockade of advertising, a service-delivery in support of yet another entirely different type of service); and the bus-services’ information-sign:

Which, as it happens, is an interesting example of a disservice or anti-service – a nominal service that, in practice, provides almost the exact inverse of ‘service’ as far as the actual end-user is concerned. What’s shown on the board is actually just a repetition of the nominal timetable, which the buses rarely follow anyway: in the town, these information-signs are jokingly referred to as ‘a work of fiction’, because any connection between the displayed information and the real-world is unreliable, erratic, tenuous at best. It’s hopelessly misleading, because the buses usually arrive in a different order than that shown, and may well leave earlier than the timetable says – or not even arrive at all.

Yes, it looks useful, it looks ‘modern’, it looks ‘hi-tech’, the kind of all-encompassing technology that IT-obsessives advocate everywhere: but in practice it’s almost worse than useless. And the reason that it’s almost worse than useless is that key inter-service links in the service-completeness are missing: in this case, the real-world connection to the actual location – or even the existence! – of the bus that should be delivering the nominal service according to that timetable. At best, the only useful service that the auto-display board delivers is a concatenation of the different bus-companies’ timetables: other than that, it’s a hugely expensive duplicate of the printed timetable that’s already on display on the wall of the bus-shelter.

Anyway, let’s summarise some of the key points so far:

• a service is a means via which someone’s or something’s needs are served
• everything in the enterprise is or represents or implies a service
• service-relationships and structures are often fractal and recursive, with services clustered together to provide broader or more abstract services
• to make sense of services, it’s all but essential to think fractal, not linear
• affordances – ‘unexpected services’ – arise from the ways in which the capabilities that underpin services may be re-used in or for other services
• a platform is a cluster of related services used as a base for affordance of other services
• what services act on, and deliver, may take many forms, including physical ‘things’, virtual information, relational links between people, or an aspirational sense of meaning or purpose
• to make sense of a service, we also need to explore themes such as service-contract, service-policy, service-level, service-guarantee, service-status and service-completeness
• without adequate verification of service-completeness, a service may fail, or deliver a ‘disservice’ or ‘anti-service’, destroying value rather than creating value

Given all of that, let’s go all the way back, right out to absolute first-principles for services and service-design. And as I see it, we can simplify all of the core drivers for services right down to a kind of visual-summary of ‘why anything happens’ – as the tension between what we have in the real-world (the ‘realised-ends’) versus the vision of what needs to happen, or could happen (the ‘desired-ends’):

In effect, that desire towards the vision – whatever that vision might be – represents the need that a service would aim to serve. In that sense, a service is an active means towards the desired-ends:

Which brings us all the way back to where we started here: everything in the enterprise is or represents or implies a service, because every activity in the enterprise exists to support the vision or aims of that enterprise. (In principle, at least… 😐 )

Yet there’s one very important further twist that arises from the above. That diagram just above shows only a fairly-rare special-case – a specific form of self-service – where only one entity acts towards a vision entirely on its own, without any reference to or help from anyone or anything else. In almost all real-world contexts, services collaborate together in various ways, in order to reach towards their various respective ends, creating a kind of ‘horizontal’ value-chain in context of those various ‘vertical’ needs. From the perspective of a single service, it usually sits an intersection between the desired-ends that it itself serves, and a broader value-flow that circulates around each shared-enterprise:

By convention, a service from which the main value-flow is towards our selected service is described as a service-provider or supplier; whilst a service for which the main value-flow is from our selected service is described as a service-consumer or customer:

Those are ways that we’d typically describe relative positioning in service-relationships, though we need to note – as we’ll see in the next part of this series – that, in most cases, the interrelationships and interactions are actually a lot more complex than a simple one-way ‘provider’ or ‘consumer’.

The key here is that a service-oriented architecture models everything as services, with these kinds of relationships going on in many different directions and many different ways between the various needs and services covered by the scope of the architecture. What we’re working towards here, in this series of articles, is a set of common themes and checklists that can be used consistently at any level of the architecture. Once again, though, think fractal, not linear – because thinking fractally in this way delivers huge dividends in terms of simplicity, comprehensibility, self-documentation and much, much more.

Let’s leave it at that kind of overview-level for now, anyway: in the next part, we’ll look a bit more at what actually needs to happen in those relationships with ‘service-providers’ and ‘service-consumers’.

Comments, perhaps, anyone?