Service, product, service – a question of structure?

Do product and service have the same structure? If they’re different views into the same space, what of that shared-structure can we see in each case?

The next post in this series on the relationship between product and service was going to be about transfers of responsibility in a service/product chain. But before we get there, the previous post in the series, ‘Service, product, service – implications for architectures‘, triggered off quite a storm on LinkedIn – well over 6000 views so far, and more than a hundred comments. Some of the conversations there – particularly those with Nick Malik, Jan van Bon, Kevin Smith and Jordan Julien – are definitely worth preserving in more permanent form, because they do help to clarify and resolve some of the confusions that can arise. So I’ll do a brief side-series here, focussing on each of those four comment-threads, before going on with that exploration on responsibility. I’ll edit some of my replies from there for brevity and/or clarity, but essentially the questions and responses in each case are the same as in the original LinkedIn post linked above.

In the previous post in this side-thread, I responded to a comment by Nick Malik that he thought that the idea of product as a bridge between services would be viewed by many as a novel concept. In this post, we’ll look at a thread that started from this comment by Jan van Bon:

If a PRODUCT is always a subset of some SERVICE, then what are the other components of SERVICE?
If PRODUCTS may incorporate SERVICES, and at the same time a PRODUCT always is a subset of SERVICES, isn’t that a contradiction?
And what IS a SERVICE? Can you define it instead of describing it?

On the components for Service, my reply was the list I’ve long used for Enterprise Canvas: Asset, Function, Location, Capability (which, recursively, often contains/calls other Services), Event and Decision. It’s a bit more nuanced than just that list, of course, expanding as we go through the Zachman layers – there’s more detail on that at ‘Services and Enterprise Canvas review – 5: Service-content’, for which this graphic gives a quick visual summary:

On whether there’s a contradiction in how I describe the nested relationships between Service and Product, the key point is that services are embedded in products in ‘frozen’ form as static ‘Assets’ (see ‘Services and Enterprise Canvas review – 6: Exchanges‘) – typically as information, though often other forms as well. (An app is an obvious example: code that is unpacked by another service in order to deliver its own service.) Key service-elements such as Event and Location, and the Decision to unpack the service into active form, are either provided or arise as part of the process of unpacking. So no, there isn’t a contradiction there.

Jan also asked for definitions. These are the ones that I’d recommend:

• Service: a means for changing value, by activities such as creating, reading, updating, destroying or relocating some Asset
• Product: the current condition or perceived status of an Asset, in an arbitrarily-bounded ‘snapshot’ of changing of value, perceived as outside of respective arbitrarily-determined service-boundaries (i.e. as an output of and/or input to one or more services)
• Asset: a Resource for which an agent (person, IT-system etc) can be considered responsible (such as via RACI mapping etc)
• Resource: an identifiable entity that may be comprised of any combination of ‘asset-dimensions’ (physical [‘thing’], virtual [data etc], relational [person-to-person etc connection], aspirational [person-to-abstract connection – meaning, purpose, brand etc] – again, see that post on ‘Exchanges’ for more detail on this).

Note that these definitions apply consistently to all types of services, products, assets and resources, at every scale, down to atomic, and up to planetary or beyond. Definitions for IT-services, business-products etc should be seen as localised instantiations of these abstract-definitions.

Unfortunately this wasn’t what Jan had wanted, and a bit of back-and-forth ensued to try to establish what explanation he did need. During this interaction, I pointed to back to that ‘Service content’ post, to elsewhere in that ‘Services and Enterprise Canvas review’ post-series, and to other sources such as my books ‘The Service-Oriented Enterprise‘ and ‘Mapping the enterprise‘. The eventual question from Jan was this:

I’d like to hear from you how you define SERVICE in a composition-decomposition mode. I see lots of ‘descriptions’ (at least that’s what I would call it), but what I really would like to see is how a service is constructed: what is the ‘material’ it is made from.

Probably the most comprehensive description is the series on ‘Services and Enterprise Canvas review‘, though there are many other posts on Enterprise Canvas, such as the post on using Enterprise Canvas as a service-viability checklist. Enterprise Canvas is a context-neutral visual-checklist for linking services to products (exchanges) and to/within the respective value-webs. It starts with service as value-creation (How) at the intersection of Value (value-flow: What) and Values (vision: Why):

…and then a first-order decomposition of a service into nine abstract child-services – incoming, self, and outgoing (horizontal-axis: facing-direction), and before, during, and after (vertical-axis: timeflow):

We then link this ‘service-in-focus’ to an abstract set of ‘guidance-services’ and other support-services:

…which in turn is anchored to its context, where the Holomap pattern helps us identify its broader set of stakeholders:

For services, we can take the composition/decomposition outward or inward to any level that we might need:

…and describe the service-content to any level of detail that we might need, as per extended-Zachman layering:

Whenever we draw some kind of service-boundary – typically for a change of responsibility or location, or a gap in time – then what we would call a ‘product’ must exist to bridge that gap. Most services handle a lot more products than many service-designers seem to realise: every stakeholder-relationship for a service implies respective boundaries-of-responsibility and potential interactions and exchanges across each relationship, which in turn implies one or more products must exist to bridge the respective gap. Each of those interactions are likely to require further child-interactions before, during and after the main part of each interaction, each of which in turn will imply further child-products, each of which will require within the main service further-child-services to process and interact with those products. Again, even the simplest-seeming of services may actually have dozens of these relationships, each with maybe dozens of interaction-types. And when we look into the detail, even a seemingly-simple interaction can get real complicated, real fast, as we can see with the Service-Cycle pattern:

Which is we we need patterns like these to help us make sense of what’s going on. With the Enterprise Canvas suite, each of these patterns is fractal – the same ‘self-similar’ pattern applies recursively, for type of content or context, any scope or scale – so in that sense it does address composition/decomposition and suchlike.

But note too that they are only patterns – so they don’t (and can’t) specify step-by-step detail for every possible context. Demanding the latter would be unrealistic, to be honest: checklists support skills, they don’t and can’t replace them.