Service, product, service
What’s the relationship between product and service? And if, as in the Enterprise Canvas model, we assert that ‘everything is or represents a service’, what then is a product?
The short-answer is that a product is a ‘frozen’ service – a way to ‘freeze’ service-delivery (or some aspect of service-delivery) so that it can restart and continue at a later time.
Or, to put it another way, wherever service-delivery is asynchronous – whenever there’s a gap in time or space between two parts of what we would otherwise consider as ‘the same service’ – then a product must exist, to bridge the gap between those services.
We can think of a product as being ‘in-line’ between those services:
These kinds of products are easier to identify, particularly if they’re primarily physical. For example, a tin of beans might be a product that sits between the services of food-preserving, at the factory, and food-delivery, as part of the meal on your plate. There’s a gap between those services, perhaps measured in years and thousands of miles, in the case of a tin of beans: the tin bridges across the gap in space and time, in effect connecting the two services together.
Alternatively, we might also view some types of product as kind of ‘off to one side’ between the respective services:
For example, an ‘insurance product’ isn’t the end-product of insurance – the repair or replacement or suchlike of whatever is insured is far closer to the actual end-point of service-delivery. Instead, the ‘insurance-product’ is a record of a promise of future service-delivery, under the conditions specified in the promise – conditions which, we note, in some cases may never be met. (The real follow-on service from an ‘insurance product’ itself is actually the maintenance of an emotional / aspirational-type asset, namely ‘peace of mind about the future’ – but that’s a separate topic I won’t go into much here.)
The product triggers and enters the respective follow-on service by matching up with one of its interface-templates or functions:
(See the post ‘Fractals, naming and enterprise-architecture‘ for more details on the terms ‘function’, ‘capability’ and ‘service’, and other terminology used here.)
An actionable service must be ‘architecturally complete’, in the Zachman sense: in other words, a complete Zachman set of What, How, Where, Who, When, Why – or, as we get closer towards implementation and actionability, the Enterprise Canvas set of Assets, Functions, Locations, Capabilities, Events and Decisions.
By contrast, a product can’t do anything on its own. It’s not ‘architecturally-complete’: in effect, it is, always and only, an Asset, a ‘thing’ that can be passed between services – though often stored somewhere along the way. A service can be triggered by and use any number of products – as long as they match the constraints and requirements of its functions’ interface-templates. And each product itself can consist of any number of sub-products, each consisting of any appropriate mix of the asset-dimensions:
A tin of beans is an Asset that is primarily physical; a database-record is an Asset that is primarily virtual; a printed book or paper form is an Asset that is both physical and virtual, and often a bit more as well.
An insurance-product is typically represented by several Assets – for example, a variety of records in different databases, and a probably a whole swathe of paper forms tucked away in various places. And various sub-products of that one nominal product may themselves trigger off related subsidiary services – such as the annual notification and billing for the maintenance of that insurance-product.
Anyway, for more on how services interact with products (‘Exchanges’), see the post ‘Services and Enterprise Canvas review – 6: Exchanges‘. And for more on how services need to act on Assets in different ways, according to their respective asset-dimensions, see the post ‘CRUD, CRUDE and other action-acronyms‘.
So to summarise:
— a service is a means to deliver value
— a product is an asset held between services, that is output by one service for future use in another service
In a service-oriented view of architecture, a product does not and cannot deliver value on its own – it always does so through some kind of service. So if a product is perceived to have some kind of intrinsic value, it can be a useful and often eye-opening exercise to go looking for the implicit services that deliver the actual real-world value of that product. These hidden-services can often be quite abstract-seeming at first, with complex and subtle emotional or social drivers – yet are real services nonetheless, and often extremely important to the overall architecture of the enterprise.
Hence, recursively, should we view this blog-post as itself a product awaiting use in some future services of your own? 🙂 I hope you find it useful, anyway!
If we accept that product sits between two services, then, in the instance where one service exists in our organisation and the other exists in the customer organisation, we may know absolutely nothing or very little about the service in each of our 1,000,000 customers purchasing our product. How do we deal with that? Do we need to deal with that?
My opinion is that, from an enterprise-architecture and/or business-architecture perspective, we do indeed need to know about those customers – or at least, a lot more than most organisations bother to do.
Two key reasons for this are the risk of anticlients (see http://weblog.tetradian.com/2018/07/25/who-are-your-anti-clients/ ), and the related problem of the crucial distinction between boundary-of-identity and boundary-of-control (see http://weblog.tetradian.com/2012/08/10/boundary-of-identity-vs-control/ ).
Tom – there is no doubt that an organisation needs to know about their customers and about how they will use the product or service that we offer. I agree that some organisations don’t know enough, and in fact, that IT functions within organisations don’t know enough about their organisation as their customer. This accounts for the popularity of design thinking (imo) as it is a methodology that requires us to stand in the shoes of the customer / be in the mind of the customer to appreciate their needs, how they will potentially use our product or service, and what outcomes they are seeking to achieve through use of our product or service.
But … we cannot afford to go and analyse the processes of each of our customers (that underpin their consuming service), we often may not be able to do this when they are geographically remote from us, they may not let us. There is a substantial difference in what we can effectively do when the consuming service is within our organisation vs part of the customer organisation – remembering of course, that each customer may be architecting, designing and changing their services at the same time as we are doing this to ours.
So … a product is actually a very “stable” interface object that provides substantial independence between producer and customer. It is quite different to a service scenario where the service is a series of interactions with the customer and is adaptive to the responses of the customer. The most adaptive entail people who can dynamically change and adjust the interaction process “on the fly” where as digital interactions have limits as to the degree of variety that they can accommodate.
In line with a fundamental aspect of engineering which determines solutions that are feasible and affordable, the act of architecting must also be feasible and affordable – otherwise, it places a cost burden on the organisation that will make the cost of operation exceed the income able to be earned.
This is one of the biggest challenges that any EA needs to learn how to manage – as you advocate, learning when is “enough”. It is easy to criticise organisations for “not doing enough” – but we often do not appreciate the cost burden that “doing more” will impose or know enough to ascertain whether “doing more” will be offset by significant downstream cost reductions or income increases.
Tom, great article on the distinction between the boundary of identity and boundary of control.
I would express the issue you are raising in a different way. Every system needs to be viewed through the system-as-whole lens and through the system-as-part-of-containing-systems lens. We must unavoidably understand the environment – I prefer to say ecosystem to emphasise the system dynamics – in which any organisation operates and the enterprise that the organisation pursues necessarily entail understanding and reflecting our understanding of that ecosystem. We will inevitably know less about the ecosystem than about the enterprise-as-system that we create and operate. Sound and successful organisations have numerous different capabilities for attending to this – and it is important as enterprise architects that we understand, respect and engage effectively with these parts of the organisation.
One of the hazards for EAs is that they behave in a way that makes people in these parts of the organisation think that EAs know-it-all and that the existence and operation of the EA implies that they can’t or aren’t doing their job well. The best example is thinking about what an EA might infer in a conversation with the CEO – the master architect of any organisation. Firing off on issues, based on impressions, without having any appreciation of what they do, where their strengths are, etc, etc puts us EAs in the position of creating anti-clients out of our most important clients and prospective advocates. (Minor aside – composing this comment has helped me appreciate what I think is probably one of the most important facets of the anti-client concept – being alert to how we as EAs so easily strengthen the position of our anti-clients – the Executives of any organisation – thanks).
So … I guess my conclusion (as I think out loud here) is that I agree that we must understand the ecosystem in which an organisation operates, and our first step in that direction should be the diagnostics we would apply to ascertaining the health of those aspects of any organisation that are responsible for attending to that. This requires us to be in listening and sensing mode so that we do not come across as judgemental – and it requires us not to make broad generalisations that could so easily create more anti-clients than clients in the organisation in which we are engaged.
I tend to think about this in a slightly different way.
Whether product or service, each is used. Good design requires attention to the use to be made of the output, whether it is a product where there is no direct interaction between provider and consumer, or a service where this is interaction.
So, the distinguishing features are more about the nature of the “use”, the nature of “ownership and responsibility”. A product allows for separation of time, location, ownership, responsibility – which is particularly important for some outputs.
I like to use some simple examples to explore ideas – consider the product is an apple or a lawnmower.
How does it help me to think about the service of eating an apple, in attending to the architecture of a greengrocer’s organisation selling an apple as one of their products or mowing my lawn as a service in attending to the architecture of a hardware store selling lawnmowers?
In both cases, thinking about the services in which your apple or lawnmower might be used would a) help with identifying useful affordances that you hadn’t previously recognised (see http://weblog.tetradian.com/2012/11/26/function-capability-and-affordance/ ), and b) perhaps help to identify risks and liabilities that were not previously visible (for a related example, around kurtosis-risks, see e.g. http://weblog.tetradian.com/2012/12/11/what-happens-when-kurtosis-risk-eventuates/ ).
Affordances is an interesting and helpful thinking construct – but we need to appreciate that “the sky is the limit” on affordances – take the repurposing of a plane from transport device to weapon in 9/11. Could we or should we have taken that into account in our architecture and design of planes? What affordances can we afford to consider – this gets us into the whole question of the cost and value of EA – and the longstanding problems of EAs spending time on considering issues which are not sufficiently significant to warrant time and attention being given to them.
How do we determine what should be given attention and how much attention is enough? I know you are conscious of these questions – they are critical to the success of any EA – if we can’t self-assess on this, then we risk being perceived as a burden rather than value-adding-function-service.
There are quite different limits in the degree of attention that needs to be given to the external consuming service, dependent on whether our output is a product or a service. Thinking of everything as a service, whilst helpful in one sense, throws out the value of thinking and operating with products as the output and the boundary around which we judge how much attention to give beyond the boundary, recognising that we must do so, but that a product acts as a valuable mediating point between two organisations – so that we don’t end up architecting the enterprises of our customers!!