Blog Posts Enterprise Architecture (EA)

Service, product, service, simplified

Blog: Tom Graves / Tetradian

What is a service? What is a product? How do they relate with each other? And what’s a simple way to describe all of this?

Yes, I’ve written a fair bit about this already – for example, ‘Product and service‘, ‘Product, service and trust‘, ‘From product to service‘, ‘From service to product‘, ‘Service, product, service‘ and ‘Service, product and architecture terminology‘. Yet it’s become clear recently that the point still isn’t getting through – and hence need something even simpler to describe what’s actually going on in that relationship between product and service.

Perhaps the simplest way to do this is not just via a single metaphor, but by combining two distinct metaphors:

In quantum-physics, the simplest way to describe a quantum of energy is as either a wave or a particle. If we describe it as a wave, a vector, a continuity of change, we can tell where it’s going – but not where it is. If we describe it as a particle, a static ‘thing’, we can tell where it is – but not where it’s going. Wave and particle are mutually-exclusive ‘ways of seeing’ – choosing one blocks out our view of the other – yet both of them describe what is actually the same entity, the same overall phenomenon.

So too with service and product: ‘service’ and ‘product’ are actually just different views of the same phenomenon. There is no such thing as ‘service’, or ‘product’: instead, there is only a single ongoing phenomenon that we might describe as ‘serviceproductservice‘, whose appearance changes according to how we choose to see it at any given moment. Sometimes we’d see it one way, sometimes the other, but it’s still the same overall entity:

In essence:

That’s basically it. We can choose to view ‘product’ and ‘service’ as somehow separate and distinct, but the relationship between them remains the same:

The reason why we might see them as distinct relates to how we choose to draw boundaries:

Which also tells us:

Note that we choose where to place those boundaries: even right down to the atomic level, any boundaries we draw are still just a choice. And those boundaries may be layered or fractal:

Yet note also that if products exist ‘between’ services, then:

And also:

Or, conversely:

In a specific sense, the inverse can also be true:

This can be a bit more subtle because what we see as ‘a product’ is always static – the ‘particle’ equivalent for the service-product quantum. Yet the product may contain child-products that are actually ‘services-in-stasis’ – a collection of all the mechanisms and resources necessary to spring into action, as services, as soon as the right conditions arise. The obvious example in the natural-world is a plant-seed – a product of a plant, that then awaits the right conditions to trigger its built-in services for growth as a new seedling. And even in that apparent static product there may be implicit yet subtly-active services that sense for ‘the right conditions’ – again, as in the example of the plant-seed. Which should also warn us that:

Such services-in-stasis embedded within products can also trigger services from other providers, or even force them to provide such services: again, the natural-world provides us with all manner of examples. A virus, for example, is basically, a product that exists only to force others to provide replication-services to create new copies of that product; likewise, if at a higher level, for any type of parasite, or entity that includes some form of parasitism in its lifecycle. Yet the same does also apply in the business-world – and as an enterprise-architect it can be, uh, interesting to note the many analogues for similarly parasitic products that infest the entire field. For example, the literal translation of ‘mortgage’ as ‘death-pledge’ provides us with one such clue, about a whole class of products whose parasitic services-in-stasis can infect our lives in life-draining and sometimes literally-lethal ways…

And for all products – including those that don’t incorporate any embedded services-in-stasis – we also need to note that:

We can imply or suggest services for which the product is intended to be used – but we can’t actually control that. Anything that can use the product in some way, by definition may use the product in its own way. And that list of possible services that could use the product may well include ones that we don’t expect (‘affordances’, again) or even that we really don’t want to access that product (as in security-concerns and suchlike). Which in turn means that we may need to embed into our product some of its own services-in-stasis that can attempt to limit some types of affordances, or to prevent some services from importing them. Which can be tricky, especially in something that, by definition, is nominally inert…

The converse is also true:

…though by definition, as something that’s active rather than passive, a service should have more options to limit, constrain and control what products it would choose to import into itself via its various interfaces. (Should have, we might emphasise – because that’s not always true in practice, of course…)

And, to complete the set:

…although, in principle at least, the service should have full control over what types of product it might choose to output, through what type of interface, under what chosen conditions. (Again, not the ‘should have’ – because that may not necessarily apply in the case of accident, or hacking, or all many of other unexpected or unplanned-for affordances…)

Finally, for now:

In other words, again, a product can do nothing on its own – it always relies on some kind of service to enable the possibilities that it implies.

So in essence what we see as ‘the product’, outside of any apparent service, is actually an arbitrarily-selected subset of another service that has a broader scope, and that we’ve made invisible by drawing all of our service-boundaries somewhere within the scope of that broader ‘containing’ service. So to make sense of a product, we must first understand that larger-scope service that provides the context for that nominal product and any services that might interact with it.

Or, to put it the other way round, we can only see something as ‘a product’ by arbitrarily drawing boundaries that place the ‘product’ supposedly outside of any service, and that render invisible most or all of the other elements that make up any architecturally-complete enclosing service. (The exact same applies to quantum-as-particle: we arbitrarily place boundaries of time – a frozen ‘moment in time’ – in order to make the quantum-entity visible as ‘a particle’.) In that sense, choosing to view something as a product may well be useful at times, but will always be ‘incomplete’ in architectural terms, and hence always at risk of being somewhat misleading. Which has huge implications for enterprise-architecture, process-design and much, much more…

As a simple summary for all of the above:

And since it is a choice, we need to be really careful about that choice! We’ll explore the practical, real-world implications of those choices in the next post in this series.

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