Blog Posts Enterprise Architecture (EA)

Service, product, service – start with product

Blog: Tom Graves / Tetradian

If service and product are different views into a continuous sequence of value-creation, what can we learn if we start the sequence from product rather than service?

In the earlier parts of this series – such as ‘Service, product, service, simplified‘, ‘Service, product, service – implications for architectures‘ and ‘Service, product, service – responsibilities‘ – I’d always taken a service-oriented perspective. In practice, though, many people would prefer to start from a focus on product. So let’s do that here.

A quick recap of the themes in this series:

So far, I’ve always shown the chain of views as starting from a service:

Or, optionally, looking inside a service that has a broader scope (otherwise known as a ‘white-box’ view of that service):

Yet in principle it’s just a chain of views, so there’s no reason why we can’t start the same chain from a product instead:

However, there are disadvantages of doing so. The first of these is that whilst we always know the parent-service for a product, we don’t necessarily know the service in which a given product will be used. The only time when we can have some degree of certainty on this is when we draw a service-boundary broader than the scope of the respective product (as in the example in that previous graphic above), and also have full control of everything that happens inside that broader-scoped service – which we usually don’t have when a product is released out ‘into the wild’.

If we don’t have full-control, such as via a hard-wired linkage from service to product to service, then the product may be used in any service that can accept that product – otherwise known as an affordance relationship between a given product and potential services. For example, many cyber-attacks depend on using a data-record (or some other product of a previous data-service) in a different service from one for which that the record was intended – a service that is instead under the attacker’s control.

Or, to give a more tangible example, here’s a tin of beans:

But whilst we might show an example-usage – in this case, combined with other products to provide the service of a meal:

… the product itself doesn’t actually mandate its own usage. If we want the beans to be part of a meal, we could use it with almost any possible combination of other products. We could use just the beans themselves as the sole content for the meal. We could pour them out onto a plate, or eat them direct from the tin. We could heat the beans first, or eat them as-is at room-temperature. To help in eating the content, we could use a fork, a spoon, chopsticks, or no utensil at all. Or we might not even open the tin, and instead use the tin itself as a paperweight, a hammer, a door-stop, a roller to help move a piece of furniture, or a projectile to hurl at a midnight-caterwauling cat. Or, for that matter, never use the product at all, other than leaving it in the stores-cupboard until the end of time.

The product may not be intended for use in those other ways, and may not work well for those other purposes, either. But there’s not much to prevent the product from being used in that way. Which is when ‘product liability’ can become an interesting challenge… This is where instruction-manuals, warranties and the like act as metadata, to help guide the usage of a product towards services for which it was actually intended, and warn of possible consequences if it’s used in a service for which it was not intended.

Remember, too, that software is usually packaged as a product – an app, for example. It’s only when it’s in use, in action, that we would view it as an actual service. The danger here, again, is that our static software-product may be used to deliver a different service than the one for which it was intended – not necessarily because of bugs, or from cyberattack, but often simply because its usage is combined with other software-products in unexpected ways. This often arises because the software-designer has thought only about the ‘happy-path’ – where the product connects to the expected user-service – and failed to consider other affordances that may actually exist.

We also need to note that a service may output any number of products. These would include not just the obvious ones that we would describe as ‘the product’, but all manner of others, such as action-records, metadata, ‘waste-product’ and many more. In a well-designed system, each of those other products should have identifiable services in which they too would be used, moving onward in their own chains of value; in a badly-designed system, we often have little to no idea as to where those other products may end up, and hence potential or actual value lost or even destroyed.

So if we do choose to take a product-oriented or ‘product-first’ view of value-creation, note that:

In the next post in this series, we’ll explore how this plays out in a sales-context. In the meantime, any comments so far on this? Over to you…

Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples