Services and disservices – 5D: Social example (Implications for EA)

Services serve the needs of someone.

Disservices purport to serve the needs of someone, but don’t – they either don’t work at all, or they serve someone else’s needs. Or desires. Or something of that kind, anyway.

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

This is the fifth part of what should be a six-part series on services and disservices, and what to do about the latter to (we hope) make them more into the former. This part ended up being far larger than expected (some 12,000 words), so it’s been split into four sections, of which this is the last:

• Part 1: Introduction (overview of the nature of services and disservices)
• 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 5A: Social-example – Introduction
  • Part 5B: Social-example – Media-examples 1-5
  • Part 5C: Social-example – Media-examples 6-9
  • Part 5D: Social-example – Implications for EA (this post)
• Part 6: Assessment and action (on how to identify and assess disservices, and actions to remedy the fails)

In previous parts of this series we explored the structure and stakeholders of services, and how disservices are, in essence, just services that don’t deliver what they purport to do. We then illustrated those principles with some real-world examples in the education-system context. Following that, we outlined some of the key causes for disservices – in particular, the ‘echo-chamber’ of misplaced, unexamined belief, and ‘power-against’, a dysfunctional misconception of power as ‘the ability to avoid work’ – and derived a set of diagnostics to test for these.

In this post – Part 5 of the series – we’ve started to put all of that into practice, in assessment of real-world services. To complement that previous exploration of education-services, we’ll look at social-services, and the social-policy that underlies them. For reasons explained in the first section of this post, the example of services from social-policy that we’d been exploring here was around identification and resolution of domestic-violence (DV), working through assessments and thought-experiments drawing on set of nine recent media-examples about the DV context.

With that exploration now complete, let’s pull back to the more everyday realms of enterprise-architectures and the like, to assess some of the implications for our more routine areas of work, and how and where we might need to use the same kinds of metaframeworks and assessment-techniques in those domains.

Practical implications for enterprise-architecture

Whilst in a business-context we wouldn’t often come across the specific types of contexts described above (or we hope not, anyway…), as enterprise-architects we do, very often, come across structurally-similar problems, each driven by a similar preselected-belief / ‘policy-based evidence’ loop:

Probably the most common example in our own context is IT-centrism – still running rampant throughout the business-domain and elsewhere after too many decades already, despite the endless stream of failed projects and failed concepts that can be laid at its door…

When we look at how IT-centrism creeps into enterprise-architecture, for example, we see exactly the same mechanisms as described above for the DV context:

• subtle shifts in language, that arbitrarily exclude anything ‘outside’ the echo-chamber loop
• arbitrary selection-mechanisms that presuppose specific ‘solutions’
• arbitrary prioritisation within overt filters (e.g. TOGAF ADM Phase C and D cover c.5-10% of organisational spend between them, whilst 90-95% are crammed into ADM Phase B, as ‘anything not-IT that might affect IT’)
• circular-reasoning (such as where a proposed IT-based option is purported to be inherently ‘the best solution’ solely because it is IT-based)
• review-mechanisms and metrics assess only the pre-selected content, ignoring everything else (e.g. TOGAF’s ADM Phase H)

All of these mechanisms will cause disservices to be created somewhere down the line: it is an inevitable outcome of IT-centrism. And the same applies to money-centrism, shareholder-centrism, organisation-centrism, capability-centrism, process-centrism, management-centrism, whatever-centrism – any form of ‘something-centrism‘ will inevitably cause disservices, as a direct outcome of prioritising theory over reality, a structural disconnect and dissociation from Reality Department.

I’m well aware that some people will have found the earlier content in this post in the series to be somewhat challenging, to say the least: but I emphasise again that that content there was just a worked-example, nothing more than that. The key takeaway that I’d want you to take away from this post is that this is not about any specific content: the same kinds of cognitive-bias echo-chamber, the same kinds of arbitrary priority and privilege assigned to a pre-selected ‘the solution, and the same kinds of problems will occur and recur in just about every context, and result in vast (and vastly-destructive) swathes of non-services, misservices and disservices. Individual context-specific diagnostics and frameworks can help in identifying mitigating these problems – but as soon as we change to a different context, a context-specific framework brought in from another type of context may itself create disservices, by missing some key factors, and over-emphasising others. If we try to stay at that level, we risk falling into classic chicken-and-egg loops…

What’s needed instead, then, is metaframeworks and their concomitant metamethods, that can self-adapt to any context. That’s essentially what we’ve been building towards, throughout this series. In the final part of this series, then, we’ll aim to pin down more of what such a diagnostic-metaframework for disservices would look like, and how we could use it in real-world practice.

See you there.

(In the meantime, over to you for any comments and suggestions, of course?)