Service, product, service, simplified

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:

• a quantum metaphor: service and product as wave and particle
• a boundary metaphor: service and product as within a boundary or between boundaries

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:

• when we see something happening to it or in it, it’s a service
• when we don’t see something happening to it, it’s a product

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:

• if it’s inside of where we draw the service-boundary, it’s a service
• if it’s outside of where we draw the service-boundary, it’s a product

Which also tells us:

• products exist between services
• products are outputs from services (hence ‘product’ – literally ‘that which is lead from’)
• products are inputs to other services (hence affordances etc)

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:

• services may contain other services (decomposition and aggregation)
• products may contain other products (components and assemblies)

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

• services may contain products between their ‘child’-services

And also:

• those ‘contained’ services and products are made invisible whenever we set the service-boundary around the containing service (‘black-box’)

Or, conversely:

• those ‘contained’ products become visible only when we look inside the containing service (‘white-box’)

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

• products may contain services within themselves or within their ‘child’-products

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:

• those ‘contained’ services become visible only when look for them as ‘services-in-stasis’ hidden within the product

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:

• a product may be used as input for many different types of services

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:

• a service may use as input many different types of product

…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:

• a service may output many different types of product

…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:

• a service is ‘architecturally complete’ – by definition, it must incorporate all types of service-content (assets, functions, locations, capabilities, events, decisions)
• a product is ‘architecturally incomplete’ – it consists of a packet of one or more assets (in any combination of asset-dimensions), without any of the other service-content elements

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:

• ‘service’ and ‘product’ are different views into the same thing
• a product is always a subset of some service – specifically, an ‘asset’ element within a broader service
• we make a product ‘visible’ by drawing boundaries that will seem to place that product-asset ‘outside’ of any service
• drawing a service-boundary always renders some service-elements invisible
• any boundary that we draw – defining inside versus outside, or service versus product – is always arbitrary, and always a choice

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.