Services and disservices – 1: Introduction

Services serve: they serve the needs of someone, or, in a broader ecosystem, the needs of something.

Services serve – that’s why they’re called ‘services’.

Yet what do we call something that purports to serve some need, but doesn’t? I’d suggest the proper term for that is a disservice.

And therein lie a huge range of problems for enterprise-architects and many, many others…

This series of posts – and it’ll need to be a series, because there’ll be a lot of it – is kind of a culmination of a whole stream of threads that have been coming together for me over the past few weeks. One of these has been Kentaro Toyama’s book Geek Heresy – a real eye-opener, especially at an RBPEA (Really-Big-Picture Enterprise-Architecture) scale. Another was the work for a formal paper that I’ve been writing for an academic journal, on ‘righting the wrongs of rights‘. Yet another source has been a swathe of articles that I’ve come across recently on the BBC website and elsewhere, on failures in education, health-systems, social-policy and more. And there are also the follow-ons from the recent posts on hidden-risks and concept-failure, and the still-unfinished-business here around ‘anything-centrism‘ and like, which I knew I had to resolve at some point. There are plenty of other threads too, but those should serve as examples enough for now.

The hardest challenge has been to find a suitable anchor around which all of the ideas could coalesce. And for now, the most practical answer seems to be the concept of service that underpins the Enterprise Canvas framework – or, more precisely, the disservices that can and do occur when services are misdesigned, misimplemented or misoperated, either by error or by intent.

For now, I’ll split the series into six parts:

• Part 1: Introduction (this post)
• Part 2: Education example (on failures in education-systems, as reported in recent media-articles)
• Part 3: The echo-chamber (on the ‘policy-based evidence‘ loop – a key driver for failure)
• Part 4: Priority and privilege (on the impact of paediarchy and other ‘entitlement’-delusions)
• Part 5: Social example (on failures in social-policy, as reported in recent media-articles)
• Part 6: Assessment and action (on how to identify and assess disservices, and actions to remedy the fails)

As we go along through the series, I may need to split one or more of those parts into subsidiary posts, but that’s the plan for now. On with the show, perhaps?

What is a service?

There are – to say the least – many different definitions of ‘service’, or ‘a service’. Much of the variation is due to differences in perspective.

For example, we could describe a service as a kind of ‘thing’, often linked in the business-context with ‘capability‘ and suchlike. We’d see this kind of ‘thingness’ described as such on Archimate models and the like.

Then there’s service as an action – that something is done on behalf of someone. That’s what’s typically meant by labels such as ‘laundry service’ or ‘service-station’. As Bob Marshall would put it, in his oddly-named ‘Antimatter Principle‘, a service in that sense is a means via which someone or something could “attend to folk’s needs”.

There’s service as something provided or consumed. In a sense that’s sort of a mix of the previous two meanings, valid in itself as such, but too often with an implicit self-centric twist that leads to a concept I personally loathe, namely viewing real people solely as ‘consumers’ – as if their only reason for existing, as one colleague put it ironically, was to “swallow products and crap cash”. (That view often leads to definite disservices, as we’ll see later.)

There’s service as a promise of future service, a sense that we often see in insurance and the like – though again there’s a real risk of serious disservice if the promise turns out to be an empty one, and the promised action of service is withheld when needed.

And, perhaps most interesting, there’s service as a feeling – a feeling that needs have been served. It’s not so much a single feeling, as a whole range of distinct feelings, all of which revolve around different aspects of satisfaction – such as:

• a sense of completion
• a sense of acceptance, of having been accepted, included, respected, even celebrated
• a sense of relief, of having been heard
• in some contexts, a sense of surprise, that promised service actually has occurred
• even a sense of joy

Note that this emotional response often goes both ways, affects both parties – not just the receiver of service, but the giver of service too. In a human context, these feelings can provide a powerful and often empowering signal that real service has been delivered, and has been completed.

If we’re doing only a conventional ‘thing’-oriented approach to service-modelling, that focusses only on the service-delivering entity itself, it’s quite probable that we wouldn’t track or even notice such feelings, let alone be aware of their crucial importance even at the level of the service-entity on its own:

Yet we probably would, and certainly should, start to notice the relevance of those feelings when we start to map out the responses of transactional stakeholders, using techniques such as customer-journey mapping:

But that’s probably as far as most conventional approaches to service-modelling would go. Yet it’s nothing like far enough, if we’re to be able to understand what really goes on in service-interactions, and thence to be able to distinguish between viable services and potential disservices.

The usual models assume that the only people relevant to a service are the service-provider and the service-consumer, within the service-transaction itself. The assumption seems to be that service is provided by the service-provider and received by the service-consumer, so as long as both of those are happy, that’s all that matters. In Business Model Canvas, for example, that’s what we’d describe in the two parts of the Value Proposition Canvas (the white square and circle in the diagram below); we’d then define in the Customer Relations cell whatever would be needed to monitor the customer-side of that satisfaction, and in the Revenue Streams for our side (if we assume that monetary revenue is the only relevant source of satisfaction, which may not be a good idea…). That’s the basic concept, anyway:

Simple business-to-service-consumer transactional patterns are perhaps the limit of what we can model in the standard Business Model Canvas / Value Proposition Canvas pairing – which is fine if that is the limit of what we need to explore. Yet even at a purely transactional level, we may well need to go further, to perhaps consider the broader supply-chain – and consider, too, that ‘happiness’ of service-providers and service-consumers elsewhere in the chain might impact satisfaction closer to here:

Hence, for example, a hold-up at the supplier’s supplier might not worry our supplier, but if that means that our customer’s customer misses a deadline because we can’t deliver on time to our customer – their supplier – then yes, a fair amount of ‘unhappiness’ might well be found bouncing up and down the line. We also see this happen often with outsourced-services that are inside the organisation’s boundary-of-identity but outside its boundary-of-control. It’s in those contexts that we might start to see service more in terms of interactions across an ecosystem, rather than solely in terms of point-to-point transactions.

But as I explained back in the post ‘What’s the scope of a business-model?‘, the service can have an impact far beyond just that transactional layer. In generic form, the transaction has a direct-context, which – amongst other things, defines shared rules and protocols and the like for transactions, and provides reference-points for verification that service has nominally been delivered:

So for an organisation, its services take place not just within a supply-chain, but also a broader market, which incorporates everything about that market – including not just the current and prospective customers and suppliers, but competitors, regulators, journalists, recruiters, training-providers, auditors and many others in that overall space:

Hence, for example, a regulator could be dissatisfied about the the service just delivered, even though you and your supplier or customer are perfectly happy. (Obvious examples might include a local council missing out on sales-tax because you and your supplier did an ‘under-the-counter’ cash-only deal, or a union expressing its annoyance about your use of a non-union service-provider.)

Looking further outward, though, the impacts can spread not just to or from the transaction’s direct-context, but also what we might call the indirect-context – yet another clustering of stakeholders of whom we do need to take account in service-modelling:

For an organisation and its services – or organisation-as-service – this indirect-context for its overall business-ecosystem is what we might alternatively describe as the shared-enterprise. As the diagram indicates, the kinds of stakeholders who occur in this broader context include communities, employees’ and others’ families, government in broader sense, non-clients and anti-clients, and financial and other investors and beneficiaries:

As described in that post ‘What’s the scope of a business-model’, we would need to zoom-out from the Business Model Canvas a long way in order to be able to see that kind of crucial detail:

Yet although we might often separate out the financial investors and beneficiaries as the nominal ‘the investors’, in fact all of these stakeholders at the ‘shared-enterprise’ level are investors and/or beneficiaries in some sense or other. For example, the employees who provide or support the various service-transactions in turn support their families and their local communities, who in turn provide some of the support that those employees need in order to do their work: in that sense, the families and communities are indirect beneficiaries of each transaction, but also are indirect-investors, without whose support the service could not be delivered, because there would be no-one there to deliver it.

To make sense of what’s really going on here, we need a fundamental rethink of the meaning of value-proposition. The full detail of how I’d recommend to do this is in the post ‘What is a value-proposition?‘, but the quick summary is that a value-proposition describes how the service proposes to deliver value to the shared-enterprise. Not just ‘deliver value to the customer’, or, for that matter, ‘deliver value to the organisation’, but deliver value to every stakeholder in the shared-enterprise – without exception. That’s where it gets tricky… – and especially so if the business-model fails to identify any stakeholders anywhere beyond the basic transactional-level.

The crucial point here is that, in effect, a service sits at intersection between values (‘vertical’) and value-flow (‘horizontal’) – and they’re not the same as each other. We could summarise this visually as follows:

The service has transactions with its service-partners, its suppliers, customers and so on, which might seem to focus on ‘horizontal’ value-flow, but are actually mediated and, literally, valued in context of the vision and values – the enterprise-story – that, by definition, would be shared in some way by the entirety of the shared enterprise. The service also has interactions – explicit or implied – with every other stakeholder, within which those ‘vertically’-connected values are primary drivers and concerns. We could summarise this visually as follows:

In which case, we can start to map out a service in terms of that intersection – hence something like this:

Given that, we can explore what actually happens within the overall process of service-delivery. From the perspective of the conventional transaction-oriented business-models, it all looks pretty straightforward – a ‘marketing/sales-cycle’ in which we grab someone’s attention, sell them something, pull in the payment, and go back to the start again as quickly as possible:

Yet the overall service is not just about what happens during the transaction, but also everything else that needs to happen both before and after that transaction:

Which, if we need it – which we often do – gives us a way to partition the activities of the service in a bit more detail, as an Enterprise Service Canvas:

For those more familiar with Business Model Canvas, there’s a crossmap between these two ways of describing a service:

(Note that the crossmap isn’t exact, in fact can’t be, because Business Model Canvas is asymmetric and whole-business-level only, whereas services themselves are inherently symmetric and fractal – service-entities provide services to customers / service-consumers, but also consume services from other service-providers, all recurring at every scale from whole-enterprise to a single web-service or whatever. But it’s a close-enough mapping to be useful, anyway.)

This is also where themes such as trust, reputation and satisfaction start to come into the picture – reputation, trust, respect, relations and more before the transaction, and a full set of completions after it, leading towards overall satisfaction. We can summarise all of this as the service-cycle:

Which means that our transaction-oriented ‘marketing/sales-cycle’ earlier above is evidently too-simplistic, and would need to expand out to something more like this:

Which also tells us quite a lot about what each aspect of the service needs to focus on:

• operations focus on delivering transactions and exchanges, in context of tactics within the supply-chain
• tactics focus on creating attention and conversation, in context of strategy within the market
• strategy should focus on building respect and relations, in context of the shared-enterprise
• the shared-enterprise is the anchor-point for reputation and trust, in context of its vision, values and shared-story

Other parties and stakeholders may choose to move deeper in towards the service, from the indirect-interactions of the shared-enterprise that build reputation and trust, to the direct-interactions of the broader market that build respect and relations, which in turn may lead to attention and conversation, and thence potentially to service-transactions. Some stakeholders never reach that depth of connection with the service-provider: yet the respective interactions still (need to) take place, whether the organisation is aware of this or not – otherwise reputation and trust will be lost.

And none of this movement towards transaction will happen if the trust is not there – again, a crucial point whose implications should become all too obvious once we look more closely at the service-failures that are experienced as disservices.

We also need to note that the reaffirmation and maintenance of that trust is dependent upon appropriate conclusion of all of the after-transaction completions. If, for example, an organisation is so focussed on its own profit that it ignores the completions required by the shared-enterprise, the market or even the customer, then that service-cycle will fail – often seemingly ‘without warning’. That type of disservice is a very common cause of business-failure…

This also tells what kinds of interactions each group of stakeholders will have, and how they assess value – in other words, what ‘value’ means to that group of stakeholders:

• those involved in transactions – customers, suppliers and the organisation itself – should gain value from the ‘horizontal’ value-flow (as per a conventional ‘value-proposition’)
• all stakeholders should gain some form of value from interactions in context of the ‘vertical’ vision, values and story of the overall shared-enterprise

A key point here is that even though they’re often described as ‘the owners’, the financial investor / beneficiaries are only one class of ‘indirect’ stakeholder groups – and we need to take account of the needs of all of those stakeholders, financial or not. In the same way, the value invested and/or withdrawn by investor / beneficiaries may take many different forms, of which money is only one. Most current business-model frameworks – as in the Business Model Canvas ‘Revenue Streams’ cell, for example – seem to assume that money is the only form of value that matters: in practice, though, that’s a fundamental error in values-architecture, and one that is very likely to cause serious disservices, especially over the longer term. To make sense of what’s actually going on in that part of business-architectures, we need to understand the distinctions between price, value, worth and cost, and explicitly manage the transforms between money, price and value in the architecture.

I developed the Enterprise Canvas framework specifically to address these types of service-design problems, including the value-themes managed in the lower three cells of the main Canvas, and somewhat-external ‘Validation-services’. There is, I admit, an awful of detail that we could delve into in the overall framework, but the basic visual-summary for the Canvas looks like this:

Perhaps the most accessible detail about service-oriented whole-enterprise architecture with Enterprise Canvas is in a series of posts from a few months back, the ‘Services and Enterprise Canvas review’:

• ‘Services and Enterprise Canvas review – Introduction‘
• ‘Services and Enterprise Canvas review – 1: Core‘
• ‘Services and Enterprise Canvas review – 2: Supplier and customer‘
• ‘Services and Enterprise Canvas review – 3: Guidance-services‘
  • ‘3A: Direction‘
  • ‘3B: Coordination‘
  • ‘3C: Validation‘
  • ‘3D: Investors‘
• ‘Services and Enterprise Canvas review – 4: Layers‘
• ‘Services and Enterprise Canvas review – 5: Service-content‘
• ‘Services and Enterprise Canvas review – 6: Exchanges‘
• ‘Services and Enterprise Canvas review – Summary‘
• ‘Services and Enterprise Canvas review – worked-example‘

For our purposes here, probably the most immediately-relevant of these posts are Parts 2, 3C, 3D and 6 – though the rest of the posts do help outline the context for how services work overall, so it is worth the effort of reading through all of them if at all possible.

But to go back to the start here, the key points perhaps to remember are that:

• services serve – and that ultimately what they each serve is a human need
• the value of services is determined by all stakeholders – not solely the customers or providers, nor solely the financial-investors
• services need to serve the respective value-needs of all stakeholders – not solely those of customers, providers or financial-investors
• there are distinct feelings associated with successful service-delivery – feelings such as satisfaction, pleasure, relief, a sense of respect and inclusion, and more

We need to keep each of those points very much in mind as we start to explore disservices.

What is a disservice?

Perhaps the simplest definition is that a disservice is a service that fails to deliver on its promises, its overall value-proposition – explicit and implicit. Conceptually a disservice is the same as a service, in fact ‘is’ or should be just another service, but somehow is broken – sometimes very badly broken – in its structure, operation, governance or connection to the broader shared-enterprise. Where a service would “attend to folks’ needs”, a disservice is typified by the ways in which it does not “attend to folks’ needs”.

(Or, often, will attend only to the needs of a select subset of stakeholders in the shared-enterprise – a key point that we’ll need to return to, many times, throughout this series.)

We recognise a service in terms of what it will and does deliver; we recognise a disservice perhaps more in terms of what it doesn’t deliver.

And in the same way that we can recognise real service as a feeling, we can likewise recognise disservice as a feeling. Again, it’s not so much a single feeling, as a whole range of distinct feelings, all of which revolve around different aspects of dissatisfaction – for example:

• a sense of frustration at being balked, at needs not being met, or agreements broken
• a sense of annoyance or impotence, of having not been heard
• a sense of isolation, of having been rejected, excluded, disrespected, even mocked
• a sense of resentment, ‘a demand that the other feel guilty’ – even though they apparently don’t
• a sense of betrayal or disgust, or even of violation, at apparent promises that have not been kept or responsibilities not upheld
• in some cases, even a sense of fury or rage

Note that, unlike with true service, this emotional response often applies only to one side of the story. Typically, this would apply to the receiver of the disservice. The immediate provider of the failed service may not share those feelings at all – in fact in the case of automation is not even capable of such feelings anyway. Yet the presence of such feelings should definitely warn someone on the provider-side that trouble is looming. What’s worrying, perhaps, is the extent to which such warnings are missed or ignored, at every level of organisations – which is probably Not A Good Idea…

Conversely, though, the same one-sided sense of betrayal may also occur on the provider-side. The classic example is the purported customer who comes into a full-service store, looks at a range of goods, asks detailed questions, is given extensive advice, but then goes away and buys the final item from a cheaper no-frills supplier that provides no support-service at all. In those cases, the full-service shop has carried all of the service-costs but received none of the returns – which leads to an understandable feeling of betrayal by the purported ‘customer’.

When trust is lost in this way, on either side of the service-story, the overall service-cycle is put at risk. In the case of the betrayed full-service store, it’s likely to treat future customer-prospects with suspicion, and put up defences against the risk of another betrayal, such as demanding a deposit before providing technical-information – which in turn means that those prospects are likely to feel distrusted, and thus less likely to put in the effort to push onward in their side of the service-cycle. In short, ultimately everyone loses from every disservice – and yet those feelings of disservice can often be the only clue that something is at risk of going seriously wrong.

(Most so-called ‘enterprise’-architectures that I’ve seen still won’t have much if any means to track such feelings-based concerns – or even understand what they are, let alone how or why they’re so crucial to the viability of the enterprise. Often the only place in which feelings might be modelled at all is in some forms of customer-journey mapping – which even now still seems to be relatively rare even in business-architectures, let alone at the broader scope and scale of enterprise-architecture. To remedy that gap, the last part of this series will include detailed how-to and checklists to address these issues in whole-enterprise architectures.)

Many of the hidden risks in business-models will arise because of unnoticed or ignored disservices on either side of the service-story: as architects, this is not something that we can afford to ignore…

Before going on to some worked-examples, we perhaps ought to distinguish between non-service, misservice and true disservice. All of them can trigger the same ‘feelings of disservice’ as above, but people’s responses to and tolerance of the respective type of disservice can be significantly different, and the underlying drivers different too:

— A non-service occurs where a service would appear to exist but is not actually available. The typical emotional response here is what we might call a ‘let-down’ – in other words, still somewhat of a sense of betrayal, but often merely a minor mythquake in the broader scheme of things.

The key here is in what happens next. If the shopkeeper says “No, we don’t stock it, go away!”, then yes, there’s a real risk that this would then be experienced as a full-on disservice, triggering much more serious levels of those feelings of disservice. But if the shopkeeper says “No, we don’t stock it, but that shop down the road will have it“, then it’s likely to switch to the feelings of service – the transaction part of the service-cycle has not been completed, but the interaction parts of the service-cycle have been fully completed and respected, in context of the enterprise-story, and hence ‘true service’ is what is experienced. In short, a simple shift in response can make an enormous difference to the way that trust is maintained (or not) within the service-cycle.

This mechanism for resolving non-services is the basis for the concept of ‘coopetition‘, or ‘cooperative competition’. An individual service-provider may opt out of a potential transaction within context of the enterprise-story, but supports other service-providers to ensure that service is fully completed in terms of the overall shared-enterprise – all providers competing and yet also cooperating at the same time. A now-classic example is the Welsh Border town of Hay-on-Wye, whose bookshops operate as a coopetitive circle: each shop’s narrow specialist focus means that it is quite likely to present non-service, but the co-marketing across the coopetitive circle means that true service overall is likely to be achieved.

It can also go the other way, where non-service from the customer-side can be turned into true-service for providers. This is the basis for the ‘disloyalty card’, a concept first pioneered by a champion barista in London, and now increasingly common elsewhere, mainly for coopetitive independent-cafes, but also beginning to happen in other enterprises too.

(Note though, that this kind of tactic can backfire badly – experienced as a true disservice – if it’s used against some stakeholders’ needs: Starbucks’ so-called ‘loyalty-card’ that actually penalised loyal customers is one of the better-known examples.)

— A misservice occurs where there is an unintentional failure of service. The keyword to note here is the word ‘unintentional‘: the misservice may occur because of someone’s non-competence or incompetence; it may be the result of a design-flaw, a mis-connection across the enterprise – all too common in siloed organisations; it may be caused by a system-failure somewhere, a breakdown, bad weather, whatever. In each case there, the key point is that the service-failure is not deliberate, ‘an act of malice’, but in essence ‘just one of those things’ – y’know, ‘sh*t happens’ and all that. Yet the feelings of disservice are all too real – and should not be ignored…

As with non-service, what we most need to watch is what happens next, after the initial misservice. If clear efforts are made to recover from the misservice, the overall outcome can well be experienced as a true service, with all of the feelings that go with true service – even if the promised transactions were not and could not be completed. But if there’s a cover-up, for example, a pretence that the misservice never happened, responsibility-evasion or ‘blaming the customer’ and suchlike, then the experience is all too likely to switch over into that of a full disservice, with all of the concomitant feelings of disservice – with the potential for very much unwanted-outcomes for any stakeholder on the receiving-end.

(Most often, though the outcome kind of sits in the middle between those two extremes – a miserable mess that leaves everyone unhappy and dissatisfied, and that tarnishes everyone’s trust in the overall enterprise: see the post ‘Where is the information when we need it?‘ for one first-hand example.)

— A true disservice occurs where there is an intentional failure of service, an intent that some stakeholders’ needs will not be satisfied, often so as to create benefit for certain stakeholder-groups at the expense of others. Again, the keyword to note here is the word ‘intentional‘: there is intent here – not necessarily ‘malice aforethought’, in fact more often just selfishness or self-centred stupidity, but intent nonetheless. There’ll often be some kind of cover-up to pretend that the disservice didn’t happen, or is in some way ‘fair’ when evidently it is not: but either way, the feelings of disservice will eventually make their presence all too well known.

Unlike with non-service or misservice, there isn’t an easy way out of this one: the only way that can be used to recover from the mess is to ‘fess up and make honest amends. Which is where the problem resides, of course, because honesty here is usually conspicuous only by its absence – often backed by a full-on paediarchy at its blame-laden worst. Hence, for architects, it’s generally wise to pre-empt these as much as we can – although doing so can be a professional risk all in itself…

(One of the classic examples of a true-disservice is the misnamed ‘customer-service’ provided by too many of the airlines, telecoms providers and the like – misnamed because such ‘services’ are seemingly designed and operated in such a way as to intentionally frustrate any possibility of customers gaining service or recompense for losses caused by the respective provider, such that the ‘provider’ can in effect force the customer to take on those costs themselves. This may look profitable for the provider in the short-term, but represents a hidden kurtosis-risk that can backfire badly on the provider – as illustrated well by the now-famous ‘United Breaks Guitars‘ incident.)

One final point, about languaging. In effect, these four terms denote a spectrum of experience, from highly-positive to highly-negative – a spectrum from true-service to non-service to misservice to true-disservice. Unfortunately, for English at least, only two of these terms currently exist in the language: service, and disservice. Given that limitation of the language, we’ll probably have to work with that simple two-way distinction for the rest of the series – but please do remember that in reality it isn’t so binary, and that each service-delivery context may well incorporate elements of ‘success’ and/or ‘failure’ across the entirety of that spectrum. I’ll comment on that where relevant, anyway.

Okay, enough on this for now: the next part in the series will move on to some examples from the education-industry and the like that can illustrate the key themes of this post.

Right now, though, over to you for your comments so far, if you wish?