RBPEA: a quick note on inequalities

This is a quick practical follow-on to the previous post ‘RBPEA: On equality and gender‘.

In the ‘Practical applications’ section at the end, where we shift down from the big-picture and refocus on everyday enterprise-architecture, I asserted that “inequalities are really bad news to enterprise-architecture”. Yet whilst I’d say that that is valid as a general guideline, there’s a really important rider that we’d need to add to that, to understand how equality-type issues apply in enterprise-architecture. In particular, there are crucial distinctions that we need to note around equality in terms of identicality, and equity – fairness or unfairness.

In that post, we touched briefly on some examples where intentionally making something less identical can actually make it more equal, in terms of what we actually want, which is equality (or perceived-equality, at least) of outcomes. As an architect, it’s really important to know when to support such non-identicalities, and when to dissuade them – and again, we touched on that in several places in the post.

Yet it’s also important to note the other side of the equation: about identifying where potentially-useful non-identicalities already exist, and how to leverage those differences to make the best use of them. In the general human context – ignoring gender for a moment, because as such it’s not actually that relevant here – the obvious example is differences in themes such as skills, talents, experiences: non-identicalities in skills, talents, experiences and suchlike provide the driving force for power-with. They’re non-identicalities that we want: in fact, without them, the overall system or context would soon reach a stasis, and stagnate into nothingness. They’re also the drivers behind the values-connections and value-flows that drive a business-model, as summarised in this Enterprise Canvas sketch of mutually-supportive relationships between services:

But notice that crucial point above about ‘mutually-supportive‘. The quick version is that if the support ain’t mutual in some form or another, it ain’t gonna work. Not in the longer-term, certainly, and also certainly not if any severe non-mutuality is maintained over multiple iterations. The catch, of course, is that there’s a huge ‘It depends…‘ attached to that point there about ‘mutual in some form or another‘, because we’re dealing with complex-systems here: a valid mutuality might not be a Simple tit-for-tat, but more a much broader ‘pay it forward‘ or “what goes around comes around”.

So whilst inequality in the form of non-identicalities can actually be ‘good-news’ – in fact we all but depend on them to make a whole-system work – inequality in the sense of maintained imbalances in mutuality such as structural-unfairness is always ‘bad-news’. We might describe it as ‘iniquitous’ or ‘unconscionable’ or just plain unfair, but it’s what will always bring a system to a grinding halt. It’s what will always convert mutual-support:

…into a ‘mutually-assured destruction’ from which no-one ‘wins’:

And once trust in the fairness of the system is lost, it can be very difficult to start it back up again, often far harder than creating trust from scratch.

It’s also why, for example, the presumably well-meant #HeForShe initiative, which no doubt looks wonderful to its promoters, is inherently doomed only to make things worse for everyone, because its actual mutuality-structure is this:

‘HeForShe’ is one of the more sad examples of this at present: it describes itself as ‘a ‘movement for gender-equality’, but in practice is so laughably unequal in every aspect of its design and intent that it is, in short, merely yet one more amongst a near-endless stream of Not A Good Idea that’s come out of that space. Oh well…

Although that example is way out at the Big-Picture social-level from most people’s perspective, it’s likewise Not A Good Idea to allow those kinds of structures to develop in the business-contexts of regular enterprise-architectures. Mapping out mutuality-structures in service-relationships – mutualities both as-designed and as-perceived – can be, uh, somewhat enlightening, let’s say? I’ve seen a roomful of executives turn white after we’d shown them what was really going on in their so-called ‘customer-service’, and the scale of the unacknowledged risks that that disaster-waiting-to-happen really represented to their beloved bottom-line… The post ‘Costs of acquisition, retention, de-acquisition‘ provides some guidance and a set of checklists that can be useful for working on these issues in business-models and service-interactions.

Remember too that all of this applies not just to interactions between people, but between machines and IT-systems as well. Any form of structural ‘unfairness’, in any context, will all too soon turn out to be Not A Good Idea, that at the very least will be a festering kurtosis-risk that could explode without warning at any time.

Yet another You Have Been Warned item, I guess? But some good-news in it, at least, in that point about the real potential value in non-identicalities.

Over to you for comment, anyway.