27 days ago

Service, product, service – implications for architectures

Link: http://weblog.tetradian.com/2020/10/02/service-product-service-implications-for-architectures/

If service and product are different views into the same space, how would we use that in enterprise-architecture, service-design, product-design and suchlike?

In the previous post, ‘Service, product, service, simplified‘, we explored a metaphor that perhaps doesn’t sound simple at first, but actually is: service and product as equivalent of ‘wave’ and ‘particle’ respectively, not as separate things but as views into what is actually the same phenomenon – a flow of value, and changes to value.

In essence, when we look at how value is changing, or the setup that we would use to change value in some way, we would describe it as ‘a service’. When we see take a static snapshot of value, at a chosen moment, we would describe it as ‘a product’. The only difference is in how we choose to view it:

  • for ‘a service’, we take an extended view of time, a wave-like view of how things are changing
  • for ‘a product’, we take a frozen view of time, a particle-like view of how things are not changing

For example, in the graphic below, we might see ‘service’ and ‘product’ as different things:

But in reality, that notion is purely an artefact of where we choose to draw boundaries. In that example, if we were to draw a bounding-box around that whole ‘service, product, service’ set, we would most likely describe that larger entity as ‘a service’ – incorporating that now-hidden product between the two child-services. So to repeat the summary from the previous post:

  • ‘service’ and ‘product’ are different views into the same thing
  • a product is always a subset of some service – specifically, a ‘thing-like’ 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 (‘black box’)
  • any boundary that we draw – defining inside versus outside, or service versus product – is always arbitrary, and always a choice

And also, from that same post:

  • fractality and/or recursion: services may be composed of other services, products may be composed of other products
  • mixing: services may incorporate products (as assets or resources), products may incorporate services (in static or ‘frozen’ form)

For enterprise architecture and related fields such as service-design and product design, and also process design or workflow design, there are a wide variety of implications – particularly around continuity, decomposition and aggregation, and also the nature, flow and change of value itself.

One type of type of tool that would definitely help here is the checklist. We can use checklists to warn us of typical questions or challenges for this type of context – particularly for concerns that are easily missed.

For services, the needs in service-design and service-oriented architectures are reasonably well understood, so it’s not hard to find checklists for services. For example, Enterprise Canvas provides a proven framework that we can use as a visual-checklist for any type of service, at any level of abstraction or fractality, and we can also extend that with its related service-content checklist and service viability checklist. And for any apparent products embedded within that service, or in its interactions with other services, we can use further related tools such as the ‘asset-type’ checklist and the service-cycle checklist.

For products, though, the needs in relation to services do seem far less understood – particularly around the interdependence with services, and ‘frozen’ services embedded within those products. In that sense, we’ll need to develop new types of checklists for products. That’s what we’ll do here.

For a real-world worked-example, this is a product that turned up in the junk-mail in the mailbox outside my house:

We’ll start with the most obvious part of the checklist:

— What is the product?

In this case it’s a composite of two parts: the brochure, and the brush. The brush part of the product has four elements: the handle, bristles and metal binder of the brush itself, which aren’t meant to come apart and that we might view as just one composite-component; and the plastic wrapper around the lower part of the brush, with its printed advertising.

What services does the product connect?

This is somewhat of a guess, but the most likely services are that the product is an output from the company’s marketing and advertising service, and intended to trigger an input to the company’s sales-enquiry response-services. Between those two ‘company-side’ services, there are several intermediate steps:

  • first, the delivery-service that did the mailbox-drops in our street – either the company’s own delivery-service, or more likely an outsourced service
  • next, the collection-service by the recipient, picking up the product from the mailbox
  • then the classic ‘AIDA’ sequence of (self)-services for any sales-prospect – Awareness, Interest, Decision, Action
  • finally, the product from that Action phase, namely the content of a phone-call or web-visit by the sales-prospect to connect to the company’s sales-enquiry service

All of that could have been done just by the brochure component of the product – but such brochures are likely to go straight into the bin, and not be available when the sales-prospect is likely to need the company’s services. So at a guess, the intent of the brush component was to help improve the chances of longer-term Awareness and then Interest, to move the sales-prospect towards Decision and Action that the company desires.

— What are the boundaries and gaps that the product must bridge across?

A product acts as a bridge between services – or, conversely, if a gap exists between services, there will need to be at least one product to bridge across that gap. Sometimes gaps are created by arbitrary decisions, such as departmental boundaries within an organisation – though that probably doesn’t apply in this case. Sometimes a gap arises because there are clear boundaries of responsibility – such as, here, the different roles, decisions and actions for the company and for the sales-prospect. The most obvious gap here, though, relates to time: for this example of building-maintenance services, there’s a probable time-gap between the sales-prospect receiving the product, and then taking action in response to the product, that could well be measured in weeks, months or even years. It’s likely that the brochure would probably be tossed into the bin almost straight away, but the brush might well sit in someone’s drawer for any length of time until its embedded information becomes relevant. For example, it might be noticed, and action then taken, only when the sales-prospect moves to a different house that now needs that type of building-maintenance – a gap of location as well as time.

— What ‘frozen services’, if any, are embedded in the product?

The main embedded-services in this example are provision of information for the sales-prospect. Those information-services are activated when the sales-prospect reads the brochure, or the text on the brush-wrapper or on the brush itself – the phone-number and web-address printed on the handle. We could of course regard that information just as a product in its own right, and argue that the only service at that point consists of the sales-prospect reading the information; but since we’re likely to describe the action more as delivery or provision of the respective information (by the product), rather than capture of information (by the sales-prospect), it does make sense – architecturally, at least – to describe that as an embedded-service.

— How does the product indicate the service(s) it is intended to connect with?

If the product as a bridge between services, it typically need to indicate what service(s) should use it, and how it should be used within those services. This is the core concern that’s addressed by the classic design-principle of ‘form follows function’: the design of the product should indicate its intended role and purpose, and how to use it for that purpose. In this case, the brochure and the brush-wrapper have an intended purpose that is clear: they should be read, to gain the information provided by the product. However, the purpose for the brush itself is not clear: it too does carry information, printed on the handle, but this point is not immediately obvious, and the form of the brush indicates a very different purpose than that of ‘providing information’.

What other services could the product connect with?

When services connect directly to each other without any apparent gap – in other words, that in effect make up one combined service – then any embedded products are carried through via hard-wired connections, and there is no uncertainty as to which services those products would bridge. But wherever there’s a gap, in effect the product can be left dangling in the middle of that gap, and it can suggest, imply and/or be used in entirely different services than those are nominally intended. Such possibilities for unintended connection are described as ‘affordances‘. In this case, the affordances obviously include the ‘form-follows-function’ usage as a paint-brush, but also not-so-obvious options such as use as paperweight, a duster, or even in the kitchen for pastry-glazing.

— How well does the product connect with and support the intended overall outcomes?

Another way to put this would be to ask how successful is the product at supporting its intended bridge, and also as a link in any broader sequence-chain of intended service-connection. In the case of the brochure and the wrapper, the answer would be straightforward: they indicate that they’re carrying information, and we can apply all the usual marketing-metrics for conversion-ratios and so on. The main challenge there is that there’s likely to be a significant gap in time between information-arrival and information-use – and on its own, the brochure is unlikely to be able to bridge that gap. That’s where the brush is supposed to come into the picture, as something that people are more likely to keep around until such time as the information does become relevant to them. Yet there’s a mismatch here that’s… well, odd, is perhaps the best way to put it. The brush implies a relationship to the (self)-service of painting – yet the brochure makes it clear that the company’s aim is to sell weatherboard that doesn’t need paint. And even if they did want to sell painting-services, the brush is not the type that would be used for that work anyway. We could argue that the presence of brush would trigger a sales-enquiry when the sales-prospect realises they do need to maintain existing weatherboard, and might be attracted to a replacement product that doesn’t need painting – but that’s a rather contorted chain of reasoning that the brush alone might be unlikely to bridge.

Anyway, let’s wrap this up for now with a more step-by-step repeat of that checklist:

  • What is the product?
  • What services does the product connect?
  • What are the boundaries and gaps that the product must bridge across?
  • What ‘frozen services’, if any, are embedded in the product?
  • How does the product indicate the service(s) it is intended to connect with?
  • What other services could the product connect with?
  • How well does the product connect with and support the intended overall outcomes?

Another kind of boundary between services relates to changes in role and responsibility. These often occur naturally, whenever there’s a change in agent – the person or system that enacts a service within the overall value-flow. Unfortunately, such boundary changes can also be misused, either to offload responsibilities inappropriately onto others, or even to evade responsibilities entirely. We’ll explore that point more in the next post in this series.