What’s the difference between product and service? And in what ways does that difference affect the various aspects of enterprise-architectures?
This question came up as a follow-on to an unusually-good LinkedIn discussion, started on The Enterprise Architecture Network list by Michael Clarkson, on the question “What’s the difference between a business capability, a business function, a business process and a service?”
I gave my usual answers:
- capability: the ability or potential to do something
- function: an interface through which capability may be accessed to do something
- service: the delivery of something that is ‘of service’, in accordance with a service-contract, service-level agreement or some equivalent quality-promise
- process: an aggregation that links services together, in sequence and/or in parallel, in structured and/or unstructured form, to deliver a composite-service
Some people liked that, some people didn’t – which is fine, of course. But whilst we were still on the original questions of definitions, the conversation drifted briefly onto product versus service, and then drifted away again, without any conclusion. So it seems worthwhile bringing a bit of focus back onto that question, because it has a lot of implications in enterprise-architectures.
The two terms – product and service – are often posed as opposites, but there’s a lot of confusion about which is which, and what each of them actually is. Which to me is not surprising, because, the way I understand them, product and service are actually the same. Product and service are not inherently different: the apparent difference is much more about how we choose to see them, rather than an attribute of the entity itself.
Probably the closest analogy is with how we use our understanding of light. One of the more obvious questions would be “Does light consist of waves or particles?” But it’s not as simple a question as it sounds, because there’s what’s known as the wave-particle duality. JJ Thompson won the Nobel Prize in 1906 for proving that light is particles; yet somewhat bizarrely, his son Walter Paget Thompson won the same prize in 1937 for proving that the particles are also waves. Hence the short answer is ‘Both, therefore neither’. Which is kinda awkward…
Light is waves and particles – at the same time. The usual way to describe this is that if we regard light as a particle, we can tell where it is, but not where it’s going; as a wave, we can tell where it’s going, but not where it is. The catch, though, is that the two views are ultimately incompatible with each other, because a wave consisting of just one particle cannot make sense. Yet it also doesn’t make sense to ask which view is true, because both are true – sort-of. The key point, though, is that the different views allow us to do different things: if we describe light as particles (photons), we can explain photoelectricity and suchlike; if we describe light as waves, we can explain phenomena such as refraction and transparency. In other words, it can be useful to choose one view or the other, even though in a strict technical sense neither is ‘true’.
Both views are sort-of true, and sort-of not-true. But they can both be useful, as long as we remember that each view represents a way that we’ve chosen to understand the behaviour of light – and not that it defines what light is.
So too with product versus service. We can summarise them in much the same way as particle versus wave:
- product: particle-like, static, a ‘thing’, represents ‘potential’ rather than ‘actual’
- service: wave-like, active, dynamic, in the midst of change, ‘potential-realised’
Hence, for example, an insurance product represents potential for service, a promise of service if and when needed at some future time.
We can also note that:
- product aligns with asset, in the sense that it tends to be static, in-potential, ‘thing’-like
- service aligns with process, in the sense that (as above), process is active, a compound-action, often changing one or more products over time
And there’s another important distinction, around responsibility:
- most responsibilities for a product, and the future, current or past use of that product, reside with and are transferred to the current holder of the product
- responsibilities for a service are shared between all parties involved in the service, especially those involved in the active realisation of that service
Being cynical, we could suggest that this is one reason why banks and insurers have been so keen to rebadge most of their services as ‘products’…
We could also note that service is sometimes provided in ‘product-like’ form – as something that happens without active engagement of the end-recipient of the service – such as is to often the case with cleaning-services, for example. In those cases, responsibility is often reinterpreted more in the sense of ‘exclusive other-blame’ – the owner of the place being cleaned claims the purported ‘right‘ to blame the cleaners for poor service, regardless of the owners’ responsibilities to make the service-delivery possible. In that context, it might be more accurate to use the term servitude rather than service… 🙁
Implications for enterprise-architecture
In essence, ‘product’ and ‘service’ are different views into the same entity: the creation and delivery (potential and/or actual) of value, usually associated with some form of asset – in turn typically as associated with some notion of ‘value-proposition‘.
Product in effect represents a ‘proto-service’ – the potentiality to deliver service.
A ‘product’ orientation will often seem ‘easier’ to work with, in part because it’s sometimes possible for the ‘producer’ to (attempt to) ignore responsibility in terms of relationships or of use of the product itself. The absence of responsibility for final service-delivery also translates to some relinquishing of ‘control’ – which, interestingly, can sometimes enable a much broader range of affordances.
A ‘service’ orientation builds engagement and commitment, through the requirement for co-creation of the end-result.
Allowing services to to be interpreted through a ‘servitude’ view is really bad news for everyone involved, especially over the longer term: it’s extremely important to construct service-structures and service-delivery in such a way as to prevent or dissuade any fallback to ‘servitude’.
In my own architecture work, I use the view that everything in the enterprise is or represents a service. This makes practical sense because the way in which products can be interpreted as proto-services. It’s important to note, though, that it’s merely a convenience to help in creating consistency across the architecture: think of ‘everything is a service’ as an ‘as-if true’, not ‘is true’.
For most purposes, it doesn’t make practical sense to do it the other way round – to attempt to structure an architecture around a notion of ‘everything in the enterprise is or represents a product’. If we do so, we lose the ability to describe process-flows or any of the dynamics of interaction across the enterprise.