Four principles – 1: There are no rules

What rules do we need in enterprise-architecture? At the really big-picture scale?

This is the second in a series of posts on principles for a sane society:

• Four principles for a sane society: Introduction
• Four principles: #1: There are no rules – only guidelines
• Four principles: #2: There are no rights – only responsibilities
• Four principles: #3: Money doesn’t matter – values do
• Four principles: #4: Adaptability is everything – but don’t sacrifice the values
• Four principles for a sane society: Summary

A bit of background first. I’m in the process of sorting out the content and structure for a conference-presentation and book, on the somewhat off-the-wall theme of ‘How to think like an anarchist (and why you need to do so, as an enterprise-architect)‘. The timescales are horribly tight, so I’m gonna need some help on this one – hence this series of posts, as a live exercise in ‘Working Out Loud’.

The aim is to explore some ideas and challenges at the Really Big Picture Enterprise-Architecture (RBPEA) scope – applying enterprise-architecture principles at the scale of an entire society, an entire nation, an entire world – and then see where it takes us as we bring it back down again to a more everyday enterprise-architecture.

As I described in the previous post in this series, for some decades now I’ve been looking for the most fundamental principles upon which long-term viability can depend: principles that will allow the design or self-design of an organism, an organisation or an entire society not merely to survive, but thrive, under conditions of often highly-variable variety-weather – the changes in change itself.

What I keep coming back to is a set of just four closely-interrelated principles: there are no rules, there are no rights, money doesn’t matter, and adaptability is everything. So here’s a bit more detail about the first of those principles for a sane society: the idea – or understanding – that in the real, practical, everyday world, there are no absolute rules that we can always rely on to apply everywhere and everywhen. Once we accept the reality of this, it has huge implications for our enterprise-architectures…

Principle #1: There are no rules – only guidelines

(Or, if you really need some kind of rules, then the only absolute rule is that there are no absolute rules.)

There are no rules: everything’s contextual. What we think of as ‘rules’ are the codified – ossified? – outcome of experiences or intentions that have come out much the same way for enough times for us to think it’ll not only usually come out the same way (a guideline) but always come out that way (a so-called ‘law’). We can illustrate this quite simply, with the SCAN framework:

(The horizontal-axis is the part that’s important here – we’ll ignore the vertical-axis for the moment.)

The horizontal axis describes a spectrum of modality or possibility, from absolute certainty and repeatability all the way over on the left, to absolute randomness or uniqueness over on the far-right. Some way along that spectrum – shown here as halfway, but in reality much further over to the left than most people would prefer – is what we might call the Inverse Einstein boundary: to the left (the blue zone), doing the same thing will lead to the same results, whilst over on the right (the red zone) doing the same thing may or will lead to different results, or we may or will have to do something different to achieve the same results.

To the left, order; to the right, unorder. Rules only ‘make sense’ in an ordered world – but there’s much more to the world than just a made-up structure of order. Rules assume certainty; guidelines don’t make such assumptions, but because they are always somewhat uncertain, they need to be linked to the respective measure of uncertainty. Which can sometimes be tricky – especially where people really really want to believe that things are certain, even if they’re not.

Another useful SCAN-related perspective on this is the classic history-of-science view of the development from idea to hypothesis to theory to law:

The catch is that it’s assumed to be a one-way process – a bit of back-and-forth along the way, to be sure, but once something becomes a ‘scientific law’, it always stays that way. Yet in reality, most so-called ‘scientific law’ only applies exactly under special circumstances that rarely exist in real-world practice. The same is true of so-called ‘constants’: most are only constant in, again, special circumstances. When we bring them all together in a real-world context, suddenly things can often get a lot more complex – and a lot more uncertain.

Take a simple scientific example: the law of gravity. There are definite constants there: we use them to design spacecraft, to plan interplanetary orbits. But once we start mixing everything together in a real mission-context, things can suddenly get a lot messier as all those different laws and constants interact. Just take a look at what the JPL Curiosity team had to do during their ‘seven minutes of terror’ to land their rover safely on Mars: and even then there was no certain guarantee that it would work. There are no rules – there are only guidelines, mixed in with awareness of constantly-varying degrees of uncertainty.

The same applies in the social context. Laws often only make sense in specific contexts: sometimes they may still make sense after centuries,but others may work well for only a few special-cases that barely survive a mere matter of months. The rules of religions are literally made-up myths, stories to fit specific contexts that may well no longer apply in this context, right here, right now. And the social-rules we call ‘morals’ are, in reality, best described as a lazy-person’s ethics, a lazy way to use made-up rules to avoid facing the real complexities of the real world – and, all too often, attempt to export the responsibilities for those complexities onto everyone else.

As every doctor on late-night duty on the cancer-ward will know all too well, all those certain-seeming morals and rules and laws around a social notion such as “thou shalt not kill” can be a lot more of a hindrance  than a help when trying to work out how best to help a patient in the agonising last stages of terminal illness… Real guidelines do help in this – especially when coupled with the honesty to respect the harsh trade-offs that so often have to be made in real-time, in the moment of action. But someone else’s morals, laws, rules? Not so much…

And when we look at real-world practice, the only real law is Murphy’s: if something can go wrong, it probably will. (The word ‘probably’ is often omitted, but its inherent uncertainty is the whole reason why Murphy’s is such a true law.)

Yet Murphy’s is so much of a law that it also has to apply to itself: hence if Murphy’s Law can go wrong, it probably will.

In other words, most of the time, Murphy’s cancels itself out. Which is why we get the illusion that things are predictable, that they follow rules.

Which in reality they don’t: Murphy’s law only cancels itself out most of the time, not all – and we never quite know when it won’t cancel itself out.

Hence, in real-world practice, the only absolute certainty is that there is no absolute certainty.

Sure, the myth of rules is useful – no doubt about that at all. Guidelines are hard at times, and uncertainty certainly is hard: that’s why we teach kids the guidelines they need as if they’re ‘the rules’, about road-safety, about where to play and not-play, about what to eat and not-eat, and so on.

But it’s really, really important to remember that although we might use these guidelines as if they’re ‘the rules’, they’re not necessarily the rules that the real world plays by. ‘As if’ is not the same as ‘is’… – and if we ever forget that, in the real world, we’re likely to find ourselves in real trouble…

There are no rules – only guidelines. That’s the core principle – core understanding – upon which everything we do will need to be built.

Implications for enterprise-architecture

I’ll often describe myself as a ‘business-anarchist’, as a somewhat-joking contrast to the more usual ‘business-analyst’. Yet it’s much more than just a joke: business-analysts work with ‘the rules’, tweaking them for best-fit to the current circumstances, whilst the business-anarchist uses a rather different and much broader skillset to take over when the rules themselves no longer make sense. And it’s from the perspective of the disciplined business-anarchist – rather than the more certain worldview of the business-analyst – that we most need to assert that “there are no rules – only guidelines”.

It’s crucial to understand here, though, that “there are no rules” doesn’t mean an absence of all constraints, a random free-for-all. What it does mean is the absence of pseudo-certainty, an absence of arbitrary constraints. That’s a rather important difference…

The point is that rules describe what ‘should’ happen inside a metaphoric box that’s bounded by often-undeclared assumptions. Yet by definition, a logic is unable to determine the limits of its own premisses, or to reassess or redefine its premisses: all it can do is follow the rules of that logic. If the context happens to stray outside of those bounds, the rules are not only likely to give guidance that’s inappropriate for the actual context, but also have no means to identify that the context is outside of the box.

In short, rules can be useful, but result in systems that are inherently fragile or brittle, with little to no resilience or self-adaptation to variation or change.

Hence what we need for most real-world contexts are not rules, but guidelines that explicitly acknowledge the uncertainty, and that can challenge and dynamically reassess their own validity and, where necessary, suggest alternatives, all preferably in real-time.

Unfortunately, most of our existing systems are built around rigid true/false rules and their undeclared assumptions… – a reality that provides many interesting challenges for enterprise-architects…

Some practical suggestions to explore:

— system-design: search out all instances of rules that are deemed to apply in a given context:

• what are the assumptions behind those rules?
• what will (or does) happen if the context moves outside of the bounds of those assumptions?
• by what means will the system identify that the context has moved outside of those bounds?
• what impact will there be on the viability of the system if the context moves outside of its expected bounds?
• what mechanisms will be available to the system to respond appropriately to and, where necessary, recover from a context that moves outside of its expected bounds?
• what guidelines and mechanisms are needed by, and available to, the system in order to adapt itself to localised or broader changes in which the context moves and stays partially or wholly outside of the systems existing expected bounds?

Most of this applies especially to automation – whether IT-based, purely mechanical, or some combination of the two. Most current IT is only capable of following strict true/false logic; most physical machines are only capable of following strict physical ‘laws’; both assume absolute-certainty, and hence both must rely on some form of ‘external help’ to realign their functional-logic to actual reality, or to escalate decision-making when the context moves outside of their predefined scope.

In practice, that ‘external help’ will usually need to be human – a real person, working in real-time. Most automated mission-critical systems will need a human-in-the-loop somewhere in the system, to handle exceptions and to override the automation where necessary. Where an automated system must be entirely self-contained – such as in a remote sensor or space-probe – its operation must include active guidelines such as pattern-matching or goal-seeking and the like that operate ‘above’ the base-level logic. Design-implications include:

• each overall system needs the ability to identify when the context moves ‘out-of-bounds’, and to accept and acknowledge that the context has (necessarily) moved beyond the ability of a closed-logic to adapt to the context, and therefore must ‘escalate’ the decisions (recursively, if necessary) to a sub-system that has the competence and authority to handle such ‘out-of-bounds’ cases
• each such escalation or transfer of decision-making authority may (and often will) change some aspects of the effective service-level agreement – rule-based decision-making is usually a lot faster than free-form guideline-based decision-making, but also a lot more brittle
• the need for escalation means that the qualitative-parameters (time-of-response, accuracy-of-response, etc) of the effective service-level agreement can be context-dependent, and in some cases may be highly variable – the overall system-design needs to be aware of those variances, the potential impacts of those variances, and the inherent uncertainties around those variances
• some form of manual-override will usually be necessary somewhere in the system, to cope with any out-of-bounds ‘special-cases’

A real-world example of the latter was an automated system for management of child-protection casework, which broke down – with extremely embarrassing results for the agency – because its requirement for date-of-birth as a key-field for the record for the child couldn’t cope with a special case of protection required for a child who was not yet born and therefor had no date-of-birth…

— organisational design: Almost by definition, most organisations are built around rules. However, the real-world moves onward all the time, in its own way, which means that rules can often become irrelevant or out-of-date – hence likewise for any organisation that insists on running everything ‘according to the rule-book’.

The primary purpose of rules in organisations is to speed up decision-making and to clarify roles and responsibilities. Since organisations are also systems in their own right, all of the notes above about the limitations of rules in systems-design also apply here. The natural decay over time of relevance and appropriateness of rules is also a key source of organisational entropy, which, if not addressed, will eventually cause the decay and death of the organisation itself. In addition to the system-design implications above, implications for organisation-design include:

• every organisational rule needs to be subject to regular review, to reassess its relevance or appropriateness to the current organisational context
• most rules should be assigned a metaphoric ‘use-by’ date that should trigger automatic review
• explicit mechanisms to manage the practical implications and impacts of changes of rules need to be in place, for each type and scope of rule
• to guide response to broad-scale change, organisations will usually require some form of stable ‘vision‘ or ‘promise’ that describes the permanent anchor or driver for a shared-enterprise broader in scope than the organisation itself

The ISO-9000 quality-system standards provide a useful worked-example of layered structure to manage rules in an organisational context. At the point-of-action, work-instructions provide explicit step-by-step rules, and guidance on how to address expected variance. When the work-instruction becomes insufficient, we turn to procedures that, in effect, describe how to adapt or redefine the work-instruction to fit the context. When procedures prove inadequate to cope with the actual variance, we turn to current policy for that overall scope; and if and when a context occurs where policy will not fit the case, we turn to the vision, as the ultimate anchor for the overall organisational-system.

There will always be variance in any real-world context; there will always be something that doesn’t fit the current rules and expectations. As the old joke goes, “As soon as we make something idiot-proof, along comes a better idiot!” Guidelines take over whenever the rules fail: yet since the rules will always fail somewhere, the wisest design principle we can use is to assert that there are no rules – only guidelines. And then, as designers, work with – not against – the implications that fall out from that fact.

[Update (later the same day)]

A bunch of really obvious points that I forgot to include on the first pass through this post… (my apologies):

• almost every instance of innovation demands the rejection of one or more existing ‘rules’ – for example, “it is impossible for a heavier-than-air craft to fly”, “it is impossible for any person to run faster than the four-minute mile”, “it is not possible for typesetting and layout to be done by anyone other than a trade-apprenticed craftsman”
• almost every change – whether in business or elsewhere – implies either a blurring or repositioning or abandonment of some existing ‘rule’
• every organisational restructure is, in effect, a suite of changes to the ‘rules’ governing interpersonal-relationships across the organisation
• every change of legislation is or implies a literal rewriting of ‘the rules’
• every amendment or redesign of a business-model implies a rewrite – often on many different levels – of the ‘rules’ that specify how the business operates

Any other equally-obvious ‘there are no rules’  items that I’ve missed?