Assets and services

What is a service? And what do services do? Seems like it’s time to re-explore some of the routine questions that come up almost every day in a service-oriented enterprise-architecture… not least because these questions are right at the core of the Enterprise Canvas model. And, in turn, the discipline and rigour about services that modelling with Enterprise Canvas can enable.

Anyway, to answer the first question first: simplest definition is that a service is something that serves. Or, in very slightly extended form, a service is something that serves some purpose. A service is a means towards some apparent end.

To which you might retort “Huh? – that doesn’t tell me anything!”. But actually it tells us a lot, in part through what isn’t in that definition:

• it doesn’t say what level of abstraction or decomposition the service sits – so it can be at any level at all, from ‘natural-ecology services’ right down at the molecular level, to the overall services provided by an entire company or country
• it doesn’t define what the purpose must be – in fact often ‘purpose’ is more a matter of perception than anything else (as in Stafford Beer’s dictum POSIWID, “the purpose of the system is [expressed in] what it does”)

What this definition does say, or imply, is that:

• a service does something
• a service serves – it usually does whatever-it-does in conjunction with and/or support of something-else (typically, another service)

Which, again, is usefully abstract – it can apply to just about anything.

And in the service-oriented view of the enterprise, it does: in Enterprise Canvas, everything in the enterprise is or represents a service. Or, to put it the other way round, the enterprise consists of layer upon layer of services, each in its own way serving the overall purpose of the enterprise. (To which, again, POSIWID might well apply.)

Which brings us to the second question: what do services do? The short answer is that services act on assets. (Which might be any type of asset – a point we’ll come back to in a moment.) There are all manner of different ways in which services can act on assets, or change them, or whatever: for example, the standard CRUD set – create, read, update, delete – though there are plenty of other ways too.

Also, importantly, services share and exchange assets with each other – often a key part of the way in which each service serves. Services create value for the enterprise by acting on assets and moving assets around the overall shared-enterprise.

(Hence a process is a sequence of actions and exchanges between services – the process being either ‘structured’ or ‘unstructured’ or whatever, according to how we choose to view that set of interactions.)

Which brings us to the next question: what are assets? The simplest answer here is that an asset is any resource for which the service assumes and enacts responsibility. Which, again, is usefully open, and usefully abstract: any resource – anything. (The real key here, actually, is not so much the resource itself, but the fact of the service’s responsibility or ‘response-ability’.)

In practice, though, this definition is probably a bit too open: to be useful, we need to bring the definition down one more level, to describe distinct types or, more precisely, dimensions of assets.

Hence the tetradian asset-dimensions, in which a resource (and hence an asset) may be any combination of:

• physical asset-dimension: physical objects, physical ‘things’ – independent, tangible, exchangeable, alienable
• virtual asset-dimension: data, information – nominally-independent, abstract/non-tangible, non-alienable, ‘exchanged’ via copy
• relational asset-dimension: relations/connections between people – interpersonal/dependent on both parties, both parties are tangible, non-alienable, non-exchangeable but potentially replicable
• aspirational asset-dimension: anchor-point for ‘belonging’, motivation etc (e.g. as represented by brand) – personal / dependent on both parties; one party tangible, the other (e.g. brand) usually not; non-alienable, non-exchangeable but potentially replicable

In practice, an economy (and hence business-model) runs on exchangeable-assets (physical and/or virtual), but depends on non-exchangeable assets (relational and/or aspirational) such as interpersonal-relations and, especially, trust. In a service-oriented architecture, we need to model services that act on non-exchangeable assets just as much as the exchangeable ones – otherwise the overall service-architecture won’t work. (Failure to do this is a very common cause of ‘inexplicable’ wicked-problems in business and elsewhere.)

Which is where the service-content checklist comes into the picture:

It’s just a cross-matrix between that set of asset-dimensions (highlighted here in orange) and a more service-oriented view of Kipling’s (and Zachman’s) ‘Six Honest Serving Men‘ – what, how, where, (who), when and why. (Most of, anyway: it’s a bit different when we look at skills and decisions – ‘why’ and part of ‘who’, the part of the the matrix highlighted in purple – but we won’t worry about that here.)

So services act on assets – we’ve seen that part already, but it’s worth repeating here. And we describe those assets in terms of those distinct dimensions – physical, virtual, relational, aspirational – and combinations of those dimensions: a printed book, for example, is a physical-asset that contains information (virtual-asset) that belongs to someone (relational-asset) and that has meaning for the someone (aspirational-asset).

It’s also easy to see that services are triggered by events that we can map in terms of the same asset-dimensions: physical events, virtual-events (a ‘signal’), relational events (a meeting between two people), aspirational events (something that changes personal meaning), and any combination of those all at once (“a man walks into a bar…”).

Next, services have locations, which we describe in terms of schemas that likewise map to those same asset-dimensions. We have physical locations, virtual locations, relational locations and aspirational locations, and, usually, complex combinations of each – such as the corner-office and the phone-number and job-title of the manager whose position you currently covet! (There’s one additional oddity in that we may also describes services’ locations in terms of time, which isn’t strictly an asset since no-one can act on it. But the same principle of location-within-some-schema applies well enough there too, so we’ll use it as-is.) Note, though, that these are all made-up schemas in some sense or other: even a set of GPS-coordinates applied to the physical location of a service is still an arbitrary imposition upon physical reality. A relational-location schema such as an org-chart hierarchy is even more made-up than that – but it’s often a useful ‘location-like’ way to describe the services provided by those people in relation to each other.

Then services have functions – which is often the only part that many people notice, hence ‘functional programming’ and so on, and the too-common tendency to think that ‘functional decomposition’ is the sum total of a service-oriented architecture. (It’s not.) In essence, a function is just a description of an interface: much like a mathematical function such as a=func(x,y) – and like that function, on its own it does nothing at all. (The ability to do something comes from the capability, as we’ll see in a moment.) The key point is that we need different types of functions act on different types of assets: physical functions provide interfaces to act on physical functions, and so on. Which means that, in a service-oriented architecture, we need to track and model the functions that act on the non-tangible assets just as much as the tangible ones – otherwise the architecture won’t work.

And services are actioned by capabilities – which is the part where far, far too many people still get confused about the nature of services. The simplest way to describe this is that a capability is the ability to do something. It’s not the same as function – which is how many people describe it. More specifically, we connect a function – an interface – with a capability – the ability to do something – in order to create a service. The ability to view function and capability as distinct from each other is crucially important in a full-scope service-architecture

[We can sort-of get away with blurring function and capability together in services that are delivered by machines or by IT – because that’s how most people still build machines and IT – but they are very definitely separate as soon as we include real-people in the picture. Failure to separate function from capability will often render certain key types of architectural-substitution – such as in load-balancing, disaster-recovery and business-continuity – either highly problematic or all-but-impossible: You Have Been Warned! 🙂 ]

To extend that tagline somewhat, a capability is the ability to do something appropriate with or on or for something. That rider is important because capability actually splits into three parts [of which only two are shown in the diagram above: my mistake – sorry…]:

• the action – in other words, the asset-types being worked on – physical, virtual and so on
• the agent – the asset-type through which the action takes place – physical (machine) or virtual (IT-system) – or via which the capability is accessed (relational- and/or aspirational-asset link to real person)
• the skill-level – rule-based (machine, IT-system or trainee), algorithm/analysis (IT-system or apprentice), guideline-based (journeyman, some specific types of IT-system), principle-based (usually human only – ‘master’)

So:

• services act on assets
• services exchange assets
• services have locations which can be described in terms of assets
• services are triggered by events which can be described in similar terms to those of assets
• services have interfaces which are often described as ‘functions’, and which in turn can be described in terms of assets acted on and exchanged through those interfaces
• services are enacted by capabilities, which can likewise be described in terms of assets, both as worked-on and as (or link to) agent

Or, in short:

• a service is something that serves some perceived purpose
• an asset is something that is used, with responsibility, within a service

Hope this makes some degree of useful sense?