Four principles for a sane society: Summary

How do we make sense of the big-picture in enterprise-architecture? The really big-picture?

For those who didn’t (or couldn’t!) read the full series, here’s a (shortish) summary of each of those (rather over-long) posts…

From the Introduction

Part of the work I’ve been doing at present involves exploring some ideas and challenges within the scope of Really Big Picture Enterprise-Architecture (RBPEA) – enterprise-architectures at the scale of an entire society, an entire nation, an entire world – and then see where those themes take us as we bring this back down again to the everyday.

Perhaps the most troubling point that’s come out of that exploration is a realisation of just how dysfunctional our current economics and other large-scale architectures really are. To be blunt, we cannot go on indefinitely with what we have right now. And even if we wanted to cling on to the current scrambled notions of ‘normal’, we soon won’t be able to do so anyway: it’s clear that, certainly in the medium-term of only a few decades from now, we’ll be up against all manner of huge changes – environmental, social, demographic, economic, resource-availability and much else besides – that will hammer home the blunt reality that there is no way to make a possession-based economy sustainable. We’re talking about really fundamental changes here: and our current large-scale architectures are not equipped to cope with them at all.

Hence what I’ve been looking for, from an architectural perspective, are fundamental principles upon which long-term viability can depend, under conditions of often highly-variable variety-weather – the changes in the nature and structure of change itself. These principles can then be used to anchor both the structure and story of the respective architecture – almost regardless of scale.

To me, after several decades of study, there seem to be just four of these principles for a sane society:

From Principle #1: There are no rules – only guidelines

This principle is fairly straightforward, even if its implications often aren’t. The point here is that – as frameworks of fixed, absolute, unchallengeable predefined decisions – ‘rules’ can only make sense in practice if the context always remains exactly the same. Which, in the real-world, they often don’t.

In an ideal world, everything can be certain. In the real-world, there’s always at least a hint of uncertainty – and we often can’t even be certain about what it is that we’re uncertain about. In practice, it seems that the only absolute rule is that there are no absolute rules – and that almost all of what we might think of as ‘the rules’ will only make practical sense in an idealised world that doesn’t actually exist.

True, it’s often useful, and wise, to proceed as if something is an absolute rule, and to teach others likewise. Yet we always need to remember that ‘as if’ is not the the same as ‘is’: and if we ever forget that fact, in the real world, we’re likely to find ourselves in real trouble… We often need to be very clear about the ‘as-if-ness’ of each of our purported ‘rules’.

The one other item we can be certain of is that the only real law is Murphy’s: if something can go wrong, it probably will. To which, once we apply that same recursion as for ‘absolute rules’, also means that if Murphy’s Law can go wrong, it probably will. That’s is how we get the illusion that things are predictable, because most of the time, Murphy cancels itself out. But only most of the time, not all: that’s the catch…

What does work here is a structure of guidelines and principles that work with the uncertainty – rather than trying to pretend that the uncertainty doesn’t exist.

When the context is right, and stays the same for some while, we can continue to rely on rules; but when the context changes, we need to rely more on principles and guidelines. The trick, then, is to know what’s going on in the current context, and which of those approaches – rules for certainty, or guidelines for uncertainty – would apply best at the current time and for the current needs. That’s a process of sensemaking and decision-making – often in real-time – that I describe as context-space mapping.

These days, I tend to base this type of context-space mapping on the SCAN framework:

As we dig deeper into our understanding of what’s happening in the context – often using the frame recursively, or with other overlays – we’ll usually start to see emphases and patterns emerge. These in turn will give us more clarity on where ‘rules’ will probably work – over to the left of the red line of the ‘Inverse-Einstein test‘, the certainty-boundary – and where we’ll need more fluid guidelines – over to the right of that boundary.

This kind of mapping provides a strong foundation for what needs to happen next within the enterprise-architecture.

From Principle #2: There are no rights – only responsibilities

This principle follows directly from Principle #1, in that a purported ‘right’ is a kind of rule that we attempt to impose upon others, usually for our own benefit. The sentiment behind ‘rights’ is usually worthwhile, but there are two fundamental flaws:

• a ‘right’ is usually a declaration of a desired outcome, but without any indication as to how that outcome could be achieved
• a ‘right’ is frequently (mis)used as an assertion of absence of responsibility: “I have rights, you have responsibilities”

Each ‘right’ purports to be absolute, inalienable, non-negotiable – which makes it almost impossible to enact practical prioritisation and the like, to deal with real-world conflicts and uncertainties. All too often, the only available means to resolve a ‘rights’-clash is a reversion to something as dysfunctional as ‘might is right’ – which defeats the whole object of ‘rights’ in the first place.

Most seriously, ‘rights’ tend automatically to create a paediarchy – ‘rule by, for and on behalf of the childish’. Under a paediarchy, selfishness, self-centredness and irresponsibility are actively rewarded, whilst those who do take responsibility are often blamed or punished. Most societies can tolerate small amounts of paediarchy, such as in the temper-tantrums of toddler-age children. However, a ‘rights’-based social model both condones and incites assertions of absence of responsibility – feeding and rewarding a spiralling tendency towards a societal-scale paediarchy such as a slave-culture. No society can survive indefinitely the inherent tensions in that kind of downward-spiral: and in that sense, unfortunately, a Bill of Rights may indeed be well-meant but is actually best understood as a societal-scale suicide-pact. Not good…

In reality, the desired outcome of a purported ‘right’ is actually implemented through a meshwork of interlocking mutual-responsibilities: hence it makes much more sense in practice  to refocus on responsibilities, not ‘rights’. Doing so is the only viable way out of the ‘rights’ mess.

For enterprise-architectures, at any scale, we would typically use tools such as stakeholder-mapping and RACI responsibility-maps, linked to descriptions of processes, assets, services and so on. Customer-journey mapping [PDF] is another useful technique here, to map out the interactions and the mutual-responsibilities at each touch-point within that overall interaction.

In my own work I would also use a ‘power/response-ability’ diagnostic such as SEMPER, to identify the dysfunctionalities introduced into a context by problems such as mistaken notions of ‘rights’. As standard, the SEMPER diagnostic uses a 1-5 scale, but for this purpose it’s probably useful to reframe it as a positive-to-negative scale:

• +2: organisation relinquishes command, to enable individual decision-making and wholeness-responsibility (fully principle-based)
• +1: organisation relinquishes control, to enable individual variance for contextual difference (context-specific adaptation of ‘rules’)
• 0: organisation asserts command and control (‘best practice’, assumed to apply to all contexts)
• -1: organisation inadvertently or deliberately enables evasion of responsibility (‘power-under’, passive-dysfunction)
• -2: organisation inadvertently or deliberately enables dominance-games (‘power-over’, active-dysfunction)

(For the purposes of the diagnostic, ‘the organisation’ is whatever entity it is that specifies rules, roles and responsibilities for the context: it can be at any level, from a web-protocol defined by a standards-body, to the company HR-unit and its rulebook, to the rulings of the United Nations or the International Criminal Court.)

Negative and positive values on the scale also respectively imply a downward-spiral or upward-spiral in overall capability and productivity. In an already-dysfunctional ‘rights’-based culture, there’s an implicit default-tendency towards the negative – which unfortunately is also highly addictive, because it gives the illusion of ‘success’ without actually achieving the desired or necessary outcome. In most present business contexts, the positive-value capabilities can be difficult to attain, and even more difficult to maintain, but can and do deliver ‘above and beyond’ the rule-based expectations of command-and-control – so in an enterprise architecture we do need to build in as much support for them as we possibly can.

Again, this type of architecture-work is a key foundation-stone for viability – especially in the longer-term.

From Principle #3: Money doesn’t matter – values do

This is perhaps the most controversial of the four principles, though in reality it’s an almost direct corollary of Principles #1 and #2.

Most of our current business and economic contexts are all but obsessed about money, and attempt to use it as the main or even sole metric for everything. This is not a good idea… The post explores four themes where people mistake money for ‘value’:

• the distortions introduced by use of money as a performance-metric
• the distortions introduced by use of money as a system design-guide
• the distortions introduced by use of money as an exchange-medium within a possession-economy
• the fundamental dysfunctionality of any possession-based economy

In essence, finance is an overlay on a money-based economy; money is an overlay on barter; and barter is an overlay (or exchange-mechanism) for a possession-based economic model. The catch, again, is that there is no way to make a possession-based economy sustainable, at any level, especially over the longer-term. The only viable option is to rethink and rework everything, almost from scratch, around clear understandings of principles, mutual-responsibilities and a much-broader understanding of value.

For enterprise-architectures, I would typically use service-oriented modelling with Enterprise Canvas, to map out the values in the context, and the respective value-interactions and transactions. The start-point would be to map out the tension between what has been achieved versus what is desired – such as in the desired-outcome of ‘rights’ – and identify the desired-ends in terms of a vision for change, and the concomitant values that arise from that vision. A service represents a means towards achieving the desired-ends:

We can then expand the description of this service, to give a more detailed view of the effective structure and content and operations of that service, and the various roles and responsibilities that are enacted within it. This also clarifies the key difference between values, (the ‘vertical’ axis in the diagram below) versus the flow of value around an enterprise (the ‘horizontal’ axis) that assists each of the players in reaching towards the respective vision:

Expanding the service-description still further, we map out the relationships between this service and other services, and the exchanges and interactions that take place between them. In visual form, an overview of the relationships and interdependencies for a viable service looks like this:

Note in particular the service-relationships described as investment and dividend, with Investor and Beneficiary respectively. Attempting to force-fit everything in these relationships into monetary form – or worse, ignoring all non-monetary aspects of those interactions – will guarantee failure of the service over the longer term. To make the service viable – whatever its level or context – the architecture must focus first on the respective vision, values, responsibilities and overall guiding-principles.

From Principle #4: Adaptability is everything – but don’t sacrifice the values

This principle might at first seem less controversial than the other three, but perhaps only until we start to fully understand its implications – because this is where the action really takes place.

If our world changes, we need to change with it, otherwise there’s a real risk that we die (whatever the  ‘we’ is in that respective level and context). That’s reality. And the kind of ‘variety-weather‘ that the various global and other indicators suggest we’re heading into over the next few decades is that fundamental that it’s likely to challenge our adaptability to the limit – yet adapt we must, if we want not merely to survive, but thrive, on the far side of that tsunami of change. Those same principles and challenges apply in every aspect of enterprise-architecture – not solely at the ‘really-big-picture’ level.

That post reviews the other three principles in terms of how they support adaptability, and illustrates this with some real-world examples, at a larger scale in the UK National Health Service, and in a more mundane case of personal-responsibility expressed as civic-action.

For enterprise-architects, we bring all of this together in a role I sometimes describe as the business-anarchist, working directly with radical change and transformative action – in contrast to the conventional business-analyst, who works more with rule-based optimisation and ‘inside-the-box’ incremental-improvement.

The challenge here is that whilst organisations need to be able to respond to change, they also need at least some things to stay the same, if only to retain some sense of identity and purpose. There’s also a need for a kind of ‘meta-governance’, to bridge across all of the different dependencies and uncertainties and rates of change that apply with the respective context. One architectural pattern that fits this need well is one that I call backbone and edge, using a service-oriented approach to architecture to map out the crucial distinctions between stable purpose-based ‘backbone’ and fast-changing context-facing ‘edge’:

To identify what needs to be in the backbone – and, for that matter, the respective domain-repositories, and the smaller not-quite-throwaway systems and services out on the edge  – we’d use techniques such as layered modelling with Enterprise Canvas, together with fitness-landscape and variety-weather maps. For example, vision lives in the backbone; values live in the backbone; core-services, core data, core capabilities and functions all live in the backbone; and we need to choose what those should be. That’s the whole point of enterprise-architecture: to identify and provide the right structures and story for the enterprise as it changes over time.

Note, though, that although it’s essential to the enterprise, the backbone is also one of the greatest constraints on enterprise-agility – so in practice we do need to keep it as simple and compact as possible. The same applies to the overall meta-governance – it needs to be simple and self-explanatory. Once we do get it right, though, we get the best of both worlds: an organisation that is agile and responsive to its customers’ needs, yet also reliable and predictable wherever it needs to be. That’s what we’re aiming for here – and at every possible scale, all the way up to the Really-Big-Picture level.