Services and Enterprise Canvas review – 6: Exchanges

What is a service-oriented architecture – particularly at a whole-of-enterprise scope? How best could we describe what passes between services – the Exchanges, or products, that ‘hold the space’ between each service? And how can we use this kind of exploration to help us break out of the IT-centrism that’s crippled both enterprise-architecture and service-oriented architecture for the past couple of decades and more?

This is the sixth and final part of 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
   • 3A: Direction
   • 3B: Coordination
   • 3C: Validation
   • 3D: Investors and beneficiaries
4. Layers: how we partition service-descriptions
5. Service-content: looking inside the service ‘black-box’
6. Exchanges: what passes between services, and why

In the earlier parts of the series, we saw how each service needs support from a variety of other services, to guide and validate its actions, to coordinate its actions with other services and its changes over time, and provide support from and for various forms of investment and the like. We’ve also seen how we can describe the services, and the architecture as a whole, in terms of a set of ‘layers’ of abstraction and/or realisation, and the structure and content of those services in terms of a visual-checklist of elements and dimensions. The last part, then, is to explore what needs to happen between the services – such as indicated by the arrows in this row-3 view of ZapaMex’s business-model:

The arrows above represent Exchanges – something being passed from one service to another.

An alternate term for Exchange would be Product – literally, ‘that which leads forward’. (In some ways – as we’ll see shortly – ‘Product’ might be a more accurate term than ‘Exchange’. But the former can be a bit misleading at times in service-oriented architectures, and the latter is the one that’s been used in Enterprise Canvas descriptions to date, so let’s stick with ‘Exchange’ for now, using ‘Product’ only where it particularly applies.)

Before going on, there are three earlier posts on this blog that are really important here, and probably should be read before going onward:

• ‘Product, service and trust‘ – how maintenance of trust needs to be at the core of all service-relationships
• ‘From product to service‘ – how products are used to enable, trigger and provide the context for future service
• ‘From service to product‘ – how the outcomes of a service-action are packaged-up into products, so as to ‘hold the space’ for future service

There are a stream of important themes and assertions that arise from those three posts, which I’ll summarise as follows:

— Everything in the enterprise is or represents or implies a service. No surprises there – that’s the basis for everything that we’ve explored in this review so far.

— A product represents the promise of future delivery of (self)-service, via use of that product. Notice that there’s an implicit handover of responsibility there: it’s the whole point, in fact, of the Exchange of an asset – particularly a physical one. This can lead to serious problems when the purported promise of future service is not actually delivered…

— When we obtain a product, we trust that that product will deliver on its promise of service-delivery at the required time. Maintenance of trust is a fundamental concern for service-architectures – particularly where ‘repeat business’ in any sense is required!

— (User)-experience is an outcome of service-delivery within an interaction-journey (between two services), and of product-usage in and beyond that service-delivery. There are some crucial concerns here around interaction between the various parties in an Exchange, and how ‘the experience’ for each and all of those parties continues beyond the nominal service-delivery itself.

— The content of an Exchange – the ‘product’ – consists always and only of an Asset, in terms of the ‘asset-dimensions’ and suchlike as described in the post ‘Fractals, naming and enterprise-architecture‘. (We’ll explore this point in more depth below.)

— Whenever two services have an asynchronous relationship with each other, an Exchange of some kind must exist to bridge the gap. This is perhaps not obvious at first, but should become clearer when we realise that the ‘product’ could simply be a timer-setting – information, a type of virtual-asset – to signal a wake-up event for the follow-on service.

(We might perhaps also note that when two services operate synchronously with each other, they’re effectively two parts of what is actually the same larger service with a wider boundary. Much like process-boundaries, service boundaries are largely arbitrary, and in many/most cases are where they are solely because we’ve chosen them to be that way – hence it’s often quite useful to play around with service-boundaries, to surface some of those often-hidden-choices, and start to make more explicit and considered choices instead.)

— A product represents a static phase of service, that needs to be ‘unfrozen’ for the effective service-delivery to continue. To put it at its simplest, services are active, products are passive: whenever service-delivery stops, it ‘freezes’ into a product.

— The creating-service needs to freeze not only the effective current-state of service-delivery, as a product, but also the metaphoric or literal instructions on how to ‘unfreeze’ it as an active service. The simplest example of that is an instruction-manual, or a so-called ‘intuitive’ or self-describing user-interface. At a deeper level, think of the self-wakeup mechanisms for a macrophage, a virus, a fungal-spore: all of these represent ‘frozen’ services (even if, to us, mostly unwanted services!) that can wake themselves up as services when the conditions are right to do so.

— A product is not complete without the information to ‘unfreeze’ it into an active service. That’s a direct corollary from the previous point, yet one that seems too often missed: instead we’re often left guessing as to how use something in the most effective way, or even at all.

(I also like Alan Klement’s notion of replacing the Agile-style ‘user-story’ with what he calls a ‘job-story‘: “When <event> I want to <action-with-motivation> so I can <achieve-outcome>“. The ‘<event>‘ is a trigger for action, but also in effect something identifiable by or as a ‘product’, something that sits between two services to identify the conditions under which the wakeup should occur. The service itself is the ‘<action-with-motivation>‘, with the ‘motivation’ component also linking upward to the respective value-proposition, values and shared-vision; the signal to indicate ‘service-complete’, or ‘<outcome-achieved>‘ then becomes the content for a ‘product’ that awaits activation by or as the next service in the respective service-chain.)

As per above, the content for an Exchange or ‘product’ is always an Asset, which in turn can be composed of multiple assets, themselves consisting of any combination of the asset-dimensions:

The characteristics and attributes are described in more detail in the previous post ‘Services and Enterprise Canvas review – 5: Service-content‘ and again in the post ‘Fractals, naming and enterprise-architecture‘, but as a quick summary:

• physical: tangible, independent (it exists in its own right), exchangeable (I can pass the thing itself to you), alienable (if I give it to you, I no longer have it)
• virtual: non-tangible, semi-independent (exists in its own right, but requires association with something physical to give it accessible form), semi-exchangeable (I can pass a clone or imperfect-copy of the thing to you), non-alienable (if I give it to you, I still have it)
• relational: semi-tangible (each end of the link is tangible), dependent (it exists between its nodes, and may be dropped from either end), non-exchangeable (if I have it, I cannot give it to you – though I can create conditions under which you could create your own equivalent copy), inherently non-alienable (there is nothing that can be given to others)
• aspirational (‘meaning’): semi-tangible at best (one end of the link may be tangible, but at least one node will be virtual), dependent (it exists between its nodes), non-exchangeable (as for relational-asset), inherently non-alienable (as for relational-asset)

When we look at an interaction within a value-flow – or any other flow, for that matter – it will usually go through multiple stages, with different Exchange-assets being involved at different stages of the interaction. Even for a web-service, for example, all manner of messages will pass back and forth, specifying the protocol to be used, establishing identity, connecting with servers, doing name-to-IP-address DNS conversions, and so on, all before we get to the actual ‘payload’-transaction for the service – and probably quite a few closing-off messages and log-records to be handled after the main transaction as well.

For the web-service, all of those Exchanges will be virtual-Assets – all of them copies, of course, not ‘alienable’ one-of-a-kind objects as in a physical transaction. But across the whole of a broader interaction, following the ‘before / during / after’ pattern that we saw in the ‘Suppliers and customers‘ post in this series, we’ll often see the full range of asset-types and asset-dimensions in play, typically following the pattern of the service-cycle:

In the earlier parts of the service-cycle, and in the closing-off at the end, we’ll typically see more aspirational-asset types in play: establishing shared-vision, values, value-proposition and so on. In effect, aspirational-assets are also in play when there is a person-to-virtual connection, such as through a website, or interaction with a brand – in other words, it’s all about trust, and trust reaffirmed.

Next in the service-cycle – especially if it’s a person-to-person interaction – we’ll tend to see more relational-asset types. Note that, as for the aspirational-asset types, these cannot be exchanged as such – instead, they’re created, read, updated, maybe even deleted, as a ‘between’-type of entity that bridges across the gap, and is the responsibility of both parties in the interaction. Unlike a physical-asset, it can’t be given to anyone else, and unlike a virtual-asset, it can’t cloned or copied: the most that we can do is to create conditions under which another person could create their own equivalent version of that aspirational- and/or relational-asset. As with that earliest and last parts of the service-cycle, there’s a wrap-round at the end, confirming satisfaction for both parties in the ‘between’-asset.

At this point in the service-cycle we reach where many marketers and business-folk seem to think the cycle begins – with gaining the other person’s attention, and starting a conversation of some kind. At this point the value-flow tends to focus more on virtual-asset types – messages and suchlike. The wrap-round on the far side likewise includes messages that indicate completion of the attention-oriented part of the cycle, often including indication of payment, for a commercial-type transaction – a point at which, again, many marketers and business-folk mistakenly think that the service-cycle has come to an end.

Finally – or rather, in the middle of the service-cycle – there’s the main point at exchanges of physical-asset types (if any) will take place. Unlike all of the other ‘exchanges’, physical-assets are ‘alienable’, and really are exchanged and transferred from one party to the other. The wrap-round here typically consists of messages indicating that the main-transaction is complete – but as per the above, there’s still a long way to go before the whole of the service-cycle is complete, closing off with reaffirmation of trust to enable the cycle to start again, perhaps with other players.

As an exercise, perhaps consider this version of that row-3 ZapaMex business-model, expanded out to include more of the company’s business-context. What are the Exchanges that take place back and forth across each of these flows? What happens during each of the respective service-cycles: what stages do they go through, and what assets of what asset-types are in play at each stage? What changes – Create, Read, Update, Delete and more – apply to each of those assets, and in which stages of the respective service-cycle? Yes, it’d be a lot of work to map out everything that’s going on here – but pick out enough to build a sense of what’s really going on even in a business-model as ‘simple’ as this might at first appear to be:

A couple more points before we bring this to a close. One is a reminder about a crucial difference between the physical- and virtual-dimensions on one side, and relational- and aspirational-dimensions on the other:

— Assets with physical- and/or virtual-dimensions are transferred across the flow, from one side to the other: there is, in effect, a transfer of responsibility for that asset from one side to the other. (Remember that an asset is a resource for which someone acknowledges responsibility.)

— Assets with relational- and/or aspirational-dimensions will bridge across the flow, linking both sides to each other: creation and maintenance of the asset is and remains the responsibility of both parties to the interaction.

The final point is perhaps more of an exploratory idea than a definite assertion, perhaps, but it’s this: that it’s possible, and maybe even probable, that there is no such thing as ‘service-delivery’. The term ‘service-delivery’ is useful – I’ve used it a lot above – but it may actually be misleading, because service is just an action: nothing more than that. It doesn’t ‘deliver’, as such: there’s nothing to deliver to, it’s a relationship, across a gap, whilst an action that we call ‘a service’ takes place primarily on one side of that gap. Something is done with and to Assets, as specified and agreed in a Function, at a Location, using a Capability, as triggered by an Event, and in accordance with Decisions such as principles and business-rules. Something may be passed across the gap, sure: but as we’ve seen earlier above, that’s kind of the end or outcome of the service-action – the moment when active Service ‘freezes’ into static Product, not the action itself.

‘Delivery’ is not an action as such, but actually a status-change – most probably a message of some kind, though not always so – as part of the wrap-up of the service-cycle, indicating that both parties are satisfied that the action has been done and finished as per the service-promise of the service’s Function and, behind it, the original Value-Proposition. Given that, then the concept of service-delivery is actually a bit misleading: it blurs together the action and the status-change, despite that in practice they actually occur at different stages of the overall service-cycle. Again, as I said above, I’m not certain about this – but something to discuss in the comments-section here?

Anyway, that’s it: that’s the completion of this ‘services and Enterprise Canvas’ review. After this, we’ll move on to a wrap-up summary of the whole blog-series, and then that much-promised worked-example, around the services of a hairdresser.

Comments on any of this so far, perhaps? If so, over to you; if not, see you in the wrap-up summary in the next post.

And thanks for sticking with me this far, of course… 🙂