Service, product, service – a novel concept?
Service and product as different views into the same space – is that a novel concept? If so, what does that imply for enterprise-architecture and the like?
The next post in this series on the relationship between product and service was going to be about transfers of responsibility in a service/product chain – and I promise that I will get back to that as soon as I can! But the previous post in the series, ‘Service, product, service – implications for architectures‘, triggered off such a storm on LinkedIn – well over 6000 views so far, and more than a hundred comments. Some of the conversations there – particularly those with Nick Malik, Jan van Bon, Kevin Smith and Jordan Julien – are definitely worth preserving in more permanent form, because they do help to clarify and resolve some of the confusions that can arise. So I’ll do a brief side-series here, focussing on each of those four comment-threads, before going on with that exploration on responsibility. I’ll edit some of my replies from there for brevity and/or clarity, but essentially the questions and responses in each case are the same as in the original LinkedIn post linked above.
We’ll start with two important points from Nick Malik, the first which was laid out as a kind of book-end at each end of his comment:
“I found the idea intriguing that a product is a bridge from one service to another. … Your recognition of the product as a connector of one service to another is novel.”
I’ll admit that his description of that as ‘novel’ was a bit of a shock for me, because it implies there’s a crucially important point that I’d missed. I’d always thought of “product as a connector of one service to another” as obvious and self-evident – as in this nearly-decade-old diagram of mine that I’d referenced in my post:
But if Nick is right – and a lot of the comments on LinkedIn and elsewhere now do seem to suggest that he is – then my failure to realise that it wasn’t obvious was a huge mistake for me to make. From what Nick was saying there, I need to go back and do a full step-by-step reasoning on that part first – otherwise much of what I’ve been describing about the implications of the linkage would perhaps never make sense to others. Oops… If anyone has any suggestions as to a best way to do that step-by-step, please let me know?
Nick’s other point – or rather, my response to it – may take a bit more explaining. This part of his comment (which I’ve shortened a bit here) was:
The iPod changed all that [mess of MP3 players and loader-apps] with iTunes. Because the iPod had a service at one end.
Now we have iTunes and the iPhone and we can put a service at the other end as well, with our apps. We no longer think of the iPhone as a product. It’s part of the service of connected voice/video/internet/community.
In terms of what I was saying in the post, this isn’t quite correct – or rather, it depends where we choose to draw the boundaries. If we draw the boundary as “the service of connected voice/video/internet/community”, then yes, the iPod or iPhone would be seen as part of that service. But if we look at the iPhone itself, it’s a product: a static container for services. And the apps on that iPhone are products too – and sold as such, as well. It’s only when the app is in use that it becomes an active container for services. The services run through the product that is the app and, as a container, the iPhone. Even the data that pass into and out of the app and action the services are themselves products – literally, ‘that which is produced’, and then consumed, in a service. But whenever we draw a service-boundary, we render invisible any products within it – they would be seen merely as ‘part of the service’. Which is why an iPhone seems to be just part of “the service of connected voice/video/internet/community” – but to make sense of what’s really going on, we also need to understand it as a product in its own right.
Product is service is product is service… It’s tricky…
That’s why I’d argue that the only way we can make sense of this is understand that product isn’t something separate and distinct from service: the whole notion of ‘product’ is an artefact of how we choose to draw service-boundaries.
And likewise, ‘service’ is an artefact of how we choose to draw boundaries across the overall flow of value undergoing change – with those boundaries most often arising from how we perceive apparent gaps in time or place, or apparent change in responsibility.
To be blunt, we need to be a bit more honest about those boundaries, and how we choose to draw them… But that’s the topic for the next post in the main part of this series: for now, back to those comments on that previous post, with a sub-thread on the structure of a service.
Hi Tom,
Glad to see you are back up and running, welcome back.
May i add another layer of complexity to this discussion. I have also long mulled over this dilemma and have come to the conclusion (right or wrong) that the first service in your Service – Product – Service depiction could either be in-house or provider driven and act as enablement to the product range, the second service would then be enabled by a combination of products to underpin a client need on a repetitive basis. This does not take away the ability of the organization to sell single products to meet a once off need to customers.
Your comments would of course be welcome.
Hi Robert
On “Glad to see you are back up and running”, I’d have to admit it’s kind of limping along on barely one cylinder. This set of posts has taken me literally weeks to write: even a few months back I could have done the whole lot in a couple of days, but just not able to focus at present. Oh well. But doing anything at all is somewhat of an improvement on nothing, I guess? :wry-grin:
On “the first service in your Service – Product – Service depiction could either be in-house or provider driven and act as enablement to the product range, the second service would then be enabled by a combination of products to underpin a client need on a repetitive basis” – actually, those services could be anything at all. That’s the whole point of this exercise: establish a fully fractal description that works the same way for any content or context, any scope or scale. Anything else that we attach to a service/product/whatever description (e.g. “in-house or provider driven”, “underpin a client need on a repetitive basis”) is then just an add-on that we choose to apply that relates to content, context, scope or scale, but is not intrinsic to service or product itself. And service and product are aspects of the same thing anyway – the only difference is that service is dynamic (activity, change is happening) whereas product is static (status, change is not happening).
The reason this is important is that enables separation-of-concerns in a much, much simpler way. It also gives us a core terminology that stays the same everywhere, which really, really helps in disentangling that current mess of special-cases that are applied to arbitrary boundaries and arbitrary sets that are somehow different in every organisation, every discipline, every technology and every context. In effect, the aim is all but force people to make conscious choices about boundaries of product, service, responsibility and more, rather than assuming that such boundaries are ‘obvious’. Given that those boundaries can be layered in many different ways (e.g. composition/decomposition, aggregation, Zachman layering etc) and can also intersect and interweave dynamically in many different ways (supply-chain, sales-process/customer-journey, consortium, jurisdiction etc), any notion that boundaries are ‘obvious’ is pretty much a guarantee of confusion or worse: this approach to service / product / etc gives us one of the few ways we can resolve that kind of mess.
I believe that in some ways we often try to over complicate certain issues and it then becomes a philosophical debate, and an academic exercise. Your point on returning to basics, and to my mind object modelling would address quite a few of these anomalies within cross domain architectures. The extension of architecture into the realms of ecosystems will require this matter to be address when discussing competitive and collaboration issues in ecosystem formulation.
“The extension of architecture into the realms of ecosystems will require this matter to be address when discussing competitive and collaboration issues in ecosystem formulation” – yes, exactly, Robert. Which is why we need to address this issue now, and urgently…
Tom,
Hope you are enjoying life ‘Down Under’.
As usual, a very thought provoking post. I had always seen the chain simplistically as “Service enables (or supports) Product that realises (or instantiates) Service” but your example makes me think that there is another more complex relationship “(Collection of Products) realises (emergent) Service”. It is this emergent Service that is important as all too often it is the combination of elements that drive success or failure; these emergent Services are hard to model/architect but I believe in the current climate are an area that architects need to focus more on.
Kevin, these are really, really important points. Do I have your permission to weave them into another post in this series?