Rules, principles and the Inverse-Einstein Test

It started with one of those first-thing-in-the-morning ideas that seemingly turn up from nowhere:

Principles create a bridge between order and chaos. Order is expressed in rules; principles are expressed in story.

Order, principles and chaos: order is an abstraction (or, in enterprise-architectures, often just wishful thinking?), whilst chaos is real.

This started a really useful back-and-forth with one of my regular correspondents, Stuart Boardman,  on rules versus principles. I won’t go into the full details of who-said-what here, but a quick summary would be:

• rules and principles have similar functions, as a guide for sensemaking and decision-making, but are not the same
• rules guide decision-making in a context of certainty, whereas principles guide decision-making in a context of uncertainty
• to use Cynthia Kurtz‘s terms, rules apply only in the ordered sensemaking/decision-making space, whereas principles must also apply in (and are more use in) the unordered space too
• the scope of a rule must be circumscribed, defined, unambiguous – a ‘closed world’
• the scope of a principle must permit ambiguity – an ‘open world’
• however, in practice principles are often expressed as if they are rules – which would make them of limited use, or worse

In effect, a rule is valid only if both the rules and its context are unambiguous and circumscribed. If not, it’s a badly-described, unclear principle, with all of the disadvantages of rules and principles, yet with the advantages of neither. For which there’s not much point, really.

Yes, I know I rant on about this quite a bit, but it’s important – not least because a frightening-small proportion of people seem to recognise the very limitations of ‘business-rule engines’ and the like. Again, rules are only valid within an ordered-context, where the boundaries of that frame of order are fully described and understood: they can be dangerously misleading if we try to use them anywhere outside of those boundaries.

IT-folks in particular often seem to think that their made-up rules actually make sense in the real-world. In reality, though – and especially so in any human context – it’s rare that rules are ever much more than an artificial abstraction, a convenient fiction. If we ever forget that they are only a fiction, we can get very quickly into very deep trouble, without any means to understand how or why we’re in trouble – or often any means to recognise that we are in trouble until we’re likely well past any chance to recover from that trouble. Hence, again, this matters, folks.

The key here is what I sometimes describe – in SCAN and suchlike – as the Inverse-Einstein test. Einstein is alleged to have said that the height of craziness – insanity, even – is to do the same thing over and over and expect to get a different result. Which is true, sort-of, in its own way – but only ‘sort-of true’ or ‘true-for-a-given-value-of-true’, because that applies only in an bounded, ordered, linearly-causal world. In any non-linear, emergent or ‘chaotic’ context – an unordered world – the inverse of Einstein’s dictum could well apply: it would be the height of craziness to do the same thing over and over and expect to get the same result each time. There, doing the same thing can, may or will lead to different results; or we may have to do different things, or come at it from a different direction, in order to achieve the same result. And in the real-world, Inverse-Einstein applies far, far more often than we might like…

The moment we move outside of the limits of a logic, we’re in Inverse-Einstein territory, where the rules of that logic may not work any more. (A simple example: flicking the light-switch on and off won’t make any difference if the power’s out!) And the catch is that when the rules don’t apply, we can’t use the rules themselves to make sense of the context: in fact we’re likely to make sense of the context by identifying that the rules don’t make sense any more. (To use the same example, we might well test whether the power is out by flicking the light-switch to see if the light comes on. Which it also won’t if the light-bulb is broken – another part of ‘the rules’ for the context that we might have forgotten!) But to do that, we need to be aware of a context that is larger than the closed-world of the rules’ logic – a modal context of ‘possibility and necessity’, within which the validity of that logic represents just one amongst many possible subsets of scope.

To put it another way, rules describe an ‘inside-in‘ view – a closed-world – whereas principles describe an ‘outside-out’ view – a semi-open world, constrained only by the porous boundaries of a story. An ‘outside-in’ view explores how that story applies within the closed-world of the rules; whereas an ‘inside-out’ view applies its rules to the broader world as if they were absolutes – often a useful tactic when combined with the cross-check of an outside-in view, but very misleading, and potentially very dangerous, if we ever forget that it’s only an ‘as-if’…

There’s often also a kind of layering of scope, or scopes. This is perhaps best illustrated by the implicit layering in the ISO-9000:2000 quality-system standard:

• a work-instruction defines rules that apply in a defined, specific context
• if any part of that context changes, we must move ‘upward’ to the procedure, which defines the roles and responsibilities that should apply in the context – including the roles and responsibilities for defining a new work-instruction
• if the roles and responsibilities become unclear, we must move ‘upward’ again to the policy, which outlines the current choices and guidelines within the broader context
• if the reasoning behind those choice and guidelines becomes unclear, we move ‘upward’ one final step, to the nominally-unchangeable vision for the overall context

This is the same kind of layering that we’ll often see in enterprise-architectures, using ‘why?’ to move ‘upward’ towards abstraction and generalisation, versus ‘how?’ or ‘with-what?’ to move ‘downward’ towards concrete realisation – the story made real.

In essence, a principle is an actionable expression of a value, which in turn devolves from the vision. (And the vision in turn is a nominally-arbitrary imposition of an arbitrarily-chosen story onto the nominally-infinite possibilities of Reality Department – but that in itself is another story! 🙂 ) Principles describe what the values mean in real-world practice: they’re useful reminders for the ‘why’ behind whatever we do when things seem certain, of course, but they become absolutely essential as guidelines for decision and action whenever our world is not certain – which is the whole point behind principles.

And because principles must deal with an uncertain world, there’s often a lot more to principles than the flat ‘truth-assertions’ of rules. If we ignore its seeming-inevitable IT-centrism for the moment, chapter 23 ‘Architecture Principles‘ in the TOGAF® 9.1 specification has a good summary of how principles should be structured:

• name – a brief phrase that summarises the choices and decisions that the principle asserts
• statement – a ‘succinct and unambiguous’ summary of the context and intent for the principle
• rationale – the ‘why’ behind the principle, as an actionable expression of a value
• implications – a summary of what the application of the principle would look like in practice, and tests to verify that the principle has been applied

To which we perhaps ought to add:

• consequences – a summary of likely outcomes if the principle is not applied, and tests to identify whether the principle has not been applied and/or has been applied incorrectly or inappropriately

But we do need to keep principles distinct from rules, because they have different applicability and different scopes. Rules are valid only within a known, certain scope, a known, definite ‘order’; principles allow for and work with uncertainty, and create that bridge across the Inverse-Einstein test, a bridge between ‘order’ and apparent chaos.