Service, product, service
Blog: Tom Graves / Tetradian
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!
Leave a Comment
You must be logged in to post a comment.
