From service to product

We’ve recently explored here the transition from product to service – but what about the other way round, from service to product?

(Many thanks to Michael Poulin for reminding of this point.)

As far as I understand it, product and service and service interweave with each other in a service-oriented architecture. I’ve said earlier that everything in an enterprise is or represents or implies a service. In that sense, a product is a kind of ‘frozen’ service, a static ‘thing’ that is awaiting its time to be brought into action either as, or as an element in the delivery of, a service.

But is the inverse true? – that everything in an enterprise also is or represents or implies a product? The short-answer seems to be ‘sorta-kinda, ish…’: it’s similar, or there are similar principles at play, but it’s not actually the same, and they’re not directly interchangeable. We can’t simply swap over and say that a service-oriented architecture is also a product-oriented architecture: they’re not directly interchangeable.

On the surface it looks like it should be possible, because products do sit between services, and services sit between products:

But the big difference is in the respective content for service or product – what makes them what they are. In Enterprise Canvas, we’d describe the service in terms of a complete set of what, how, where, who, when and why – or, to put it in more detail, the respective combination of physical (‘thing’ etc), virtual (information etc), relational (people etc) and aspirational (brand, purpose etc) dimensions of the respective assets, functions, locations, capabilities, events and decisions or reasons that make up what we see as ‘the service’:

But for a product, as it traverses between services, it’s static, not active – it’s an asset, and nothing else:

(Okay, we might suggest that it might also include a Location – but that tends to be something more assigned to it than of it.)

An asset is a resource of some kind for which someone is responsible – it’s the fact of responsibility that changes it from just ‘the thing in itself’ to an asset that may be (re)-used. Assets (and resources in general) also have CRUD-type actions associated with them – Create, Read, Update, Delete and the like, dependent on the respective asset-dimensions as above.

(Note again that this ‘service / product’ concept or metaphor is just a perspective – a choice of how to view and model particular types of interactions: in no way does it claim to be ‘the truth’ or ‘the only way’. In an object-oriented approach to modelling, for example, the services would be considered to be encapsulated within the asset itself, as object-methods. Object-orientation has proven a useful approach in detail-layer programming, where the capabilities used by a service are inherently embedded in that software-delivered service; but it’s quite a lot less-useful – in fact often seriously problematic and misleading – when we try to extend the same metaphor to apply it to the enterprise as a whole, or to apply to services that are not delivered by software or have to be substitutable or interchangeable with non-software capabilities, as in many real business contexts. A service-oriented approach, by contrast, can be applied consistently at every level and in (almost?) every type of context.)

When we look for boundaries between services, it often seems that the existence or presence of a product represents at least part of the boundary. In any case, it seems certain that when two services have an asynchronous relationship with each other, a product of some kind must exist to bridge the gap.

The product encapsulates content that the receiving or ‘consuming’ services will need, and in a form that the service can use, in order to ‘wake up’ and start the next stage of the respective process. The content could be of almost any mix of asset-dimensions, as above, but would almost always include information of some kind – to trigger the ‘wake-up’, and to indicate the respective expectations of service-action and service-quality.

The point about ‘in a form that the service can use’ is important for two reasons: interface-compatibility, and alignment of affordance with service-purpose.

In service-architectures, there’s a key distinction we need between the external-facing service-interface (the ‘black-box’ view) and the internals that do the work of the service (the ‘white-box’ view). In the model that I’ve been using for service-content, these are respectively the service’s function and capabilities:

For use by a service, a product first needs to get through and past the gatekeeper-role of the service-function – it needs to be compatible with the service-interface that the function presents to products that pass by. Much as in mathematics, or software, the function declares what the service will accept as ‘input’, and, often, what it will return as ‘output’ – the output being yet another product, to be passed on to another service, in a sequence of service-actions that many would describe as a process. The function, in effect, provides and publishes a protocol that indicates what will be accepted through its interface, and what type and level of service will be provided – often described, by analogy at least, as the parameter-set for some form of service-contract or service-level agreement.

For the service to be able to deliver on its service-promise, whatever comes in through the function must align with the capabilities that the service either embeds within itself, or calls upon from other services. If it doesn’t align, the service can’t deliver the outcomes indicated in the service-contract – or the service itself may become damaged, just from the wrong product entering into its enclosed world.

Consider what happens when a pollen-grain hits the stigma of a flower. As any hay-fever sufferer will know, there may well be vast amounts of pollen – the mobile genetic-material product of various flowers – blowing about at flowering-time; but the stigma’s interface attempts to filter all of those down to exactly one type of pollen – the type that matches exactly for that respective plant-species. If the pollen does get through that interface, it triggers off the respective services in the flower’s stigma, style and ovary, to connect the product-content – the pollen’s genetic-information – to the seed-germ and its seed-growing capabilities.

That’s what happens in normal conditions: the ‘gatekeeper’-function keeps out out any ‘alien’ genetic-information. But consider what happens with a virus-attack: the virus will often mimic the interface-elements of the pollen, so as to get through the gatekeeper, and re-use the seed’s cell-building capabilities to its own purpose. Or, in bio-engineering, that gatekeeper is bypassed entirely, and instead genetic-information is inserted directly into the seed-germ – again, re-using the cell-building capabilities of the flower in a form different from their ‘pre-designed’ intent.

The other point to note here is that the function-interface also constrains the affordances that the product may otherwise provide to the service. For example, in current microservice design, each microservice should deliver precisely one type of activity, through precisely one interface – we shouldn’t have the polymorphism or multi-functionality typical of classic object-oriented design.

The more open the function-interface, the more affordances are likely to be available to the receiving-service – the options that the product affords to that service, or to services in general. In software and – as above – often in nature, the affordances will be tightly constrained: the product provides only a narrow range of affordances. But when humans provide the underlying capabilities for a services, the affordances from a single product may be stretched very wide indeed: so much so that it’s often jokingly said that, for humans, the very first response to anything is to assess whether to eat it, and then – in accordance with the four classic adrenalin-responses, ‘fight, flight, fear or fornicate’ – explore whether it can be used as a weapon, run away from it, fear it, or attempt to have sex with it… :wry-grin:

But we perhaps need to bring this back, not so much to the service that uses the product, but the service that creates it. A product represents a static phase of a service, that needs to be ‘unfrozen’ for the effective service-delivery to continue – which means that 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.

To take a literal example, consider an electric kettle. The eventual service-delivery is that of boiling-water: the kettle is a product that encapsulates that service-delivery. And as a product, the kettle is provided with its two-part service-interface – the power-lead, and the various orifices to add and remove water – and two key pieces of information: the instruction-sheet, and the warranty. The former item shows how to ‘unfreeze’ the service that’s encapsulated in the product; and the latter, together with the instruction-sheet, spells out the parameters and applicable-values of the service-contract and service-level agreement – in other words, the content published by the service-function, the ‘frozen’ service-interface. Without those items of information, the kettle exists as a product, sort-of: but only in the sense that exploration would probably highlight some potential affordances – some of which may be as intended, but others might indeed void the warranty! A product is not complete without the information to ‘unfreeze’ it into an active service.

There’s a perhaps-unfortunate tendency these days to assume that the ideal is that products should somehow be self-documenting – or ‘self-unfreezing’ in the sense described above – and that therefore the instruction-sheet or whatever should be redundant. It’s certainly considered the ideal for smartphone apps and the like. In practice, though, the instruction-sheet does still exist in every case, if only in implicit form, as the software’s user-interface. The app design, in that sense, is part of the work that the software-development service needs to do, so as to ‘freeze’ the service-delivery into product-type form.

The same is true for physical-products, of course. Consider the example of the two types of ketchup-bottle that we looked at in that previous post:

In each of these two cases, there is text that describes key aspects of the service-contract: it’s on the back-label. There are also various aspects that sort-of describe an instruction-text, though much of it is implicit or near-subliminal: the front-label, which describes the content of the bottle, and hence implies an intended use; and the nutritional advice and serving-size, also on the back-label, that again suggest recommended use. (Sometimes there might even be a recipe-leaflet, either on an extended back-label or a separate sheet.) But the core part of the ‘instruction-sheet’ is actually presumed familiarity with bottles of each of these two types – in other words, how to open the respective cap-types to get at the sauce, and thence the service-delivery of the sauce-itself.

What’s easy to miss here is how much is actually done in the ‘creating-service’ that creates this product. Most times we’d probably dismiss all of that encapsulation and ‘freezing’ of the future service of ‘tomato sauce on my food’ as ‘just something that gets done in manufacturing’: but it actually is part of the overall service-delivery. Once we see a product as a ‘frozen’ intermediate stage in service-delivery, as a boundary between two active services, service-modelling gets to be a lot more interesting – and makes a service-oriented architecture much easier to understand, too.

Any comments, on this, perhaps?