Principles and checklists

What is the role of principles in enterprise-architecture? What is a principle? For that matter, when is a principle not a principle?

These were questions that came up in response to a post by Simplicable: ‘101 Principles of Enterprise-Architecture‘. Or rather, to Emeric Nectoux’s tweet about it:

• RT @enectoux: 101 Principles of Enterprise Architecture – Simplicable http://bit.ly/10PS98w #entarch

I took a quick glance at the post, saw that – as is usual at Simplicable – it’s perhaps a bit over-simplified but still useful as a summary, and duly retweeted. Others were not so impressed:

• RT @ricphillips: @enectoux Haven’t read it, but anything that has to follow 101 principles couldn’t tell its arse from its elbow.

Fair enough, in terms of real-world practice. Yet, as I commented:

• RT @tetradian: @ricphillips key point is that there’s a big difference b/w plan-checklists and runtime-checklists – former can be many items, latter v.few

To which Ric replied:

• RT @ricphillips: @tetradian Shamed at my own snarkiness I did read it. I cite “The Checklist Manifesto” in my defense. At times snap judgements are right.

To which the real answer is that that “snap judgement” is sort-of right, and sort-of not – in other words, it’s the dreaded ‘It depends…‘ again. And it’s worthwhile doing a brief exploration here of what it is that it depends on.

Let’s start with a working-definition: a principle is a brief summary to guide decision-making in contexts of uncertainty. A principle may also be described as, or be linked with, associated tests of some kind – such as in an emergency-checklist (the red section on the Cessna checklist below):

As can be seen from that Cessna checklist, a single ‘checklist’ may well be split into several sections, each focussing on a specific issue or concern (nine sections totalling 61 checklist-items, on the ‘Emergency Procedures’ side in that case). By comparison, the Simplicable ‘101 principles’ are split across some twenty sections, so in itself the number of principles is not the real key here: what matters more is how those principles are to be used.

The Simplicable list shows each of its principles as a single assertion, followed by a very brief summary of what the outcome of applying that assertion would look like in practice. To be honest, it’s a bit too over-simplified to be much help as an actual design-guideline, but it’s still useful as an overall summary and check. To do design-principles properly, we’d need the kind of detail specified in the TOGAF section on principles:

• Name: “should both represent the essence of the rule as well as be easy to remember”
• Statement: “should succinctly and unambiguously communicate the fundamental rule.”
• Rationale: “should highlight the business benefits of adhering to the principle” [and also the consequence of not adhering to the principle]
• Implications: “should highlight the requirements … for carrying out the principle – in terms of resources, costs, and activities/tasks”

That’s the level of detail we’d need when we learn about the principle. But at run-time the only thing we’ll likely have time to remember is the principle itself – the ‘Name’, in TOGAF terms.

Which is where we get to the real nub of this, about how principles are used. And for that, we can usefully turn to the SCAN framework – specifically, the decision-making view for that framework:

What we have in SCAN is a mapping of decision-domains in terms of two key axes: modality of decision-logic (horizontal-axis) versus time-available-before-action (vertical-axis), as described in the post ‘Domains and dimensions in SCAN‘). To the left, we have ‘order’, or certainty, and to the right, ‘unorder’, or uncertainty, with a distinct boundary between them – the ‘Inverse-Einstein test‘. The boundary on the time-available axis is far less distinct, but the point there is that the decisions we make in what we plan to do (distant from action) can be very different from what we actually decide to do at the moment of action. This gives us four somewhat-blurry decision-domains:

• plan for things that seem certain (‘order’) – we make assertions about what ‘will happen’
• plan for things that seem variously uncertain (‘unorder’) – we explore a range of options and guidelines to be ready to use
• act on belief that things are certain and that the predefined assertions are correct
• act on faith in the face of the uncertain, making use of personal experience of those previously-explored guidelines and options

(Yes, I do know that those terms aren’t wonderful, and perhaps carry too much ‘baggage’ from other meanings, but they should do well enough for now, okay?)

At the moment of action, all we can do is decide and act: there is no time available for anything else. At any significant distance from the moment of action – both before and after – we can reflect, and review, and reassess: but not at the point of action. These decision-domains really are different from each other: so different, in fact, that in humans they’re enacted by different parts of the brain, nervous-system, hormonal-systems, and so on – or, to be pedantic, different combinations of those various elements. (Conventional IT-systems and machines operate only on rules – or Beliefs – that we give to them, as the actionable expression of Assertions: which can sometimes create the delusion that that’s the only way in which decisions are made…) Yet on the surface, everything looks much the same: it’s just a decision.

So we now bring the notion of principles into this picture: “a brief summary to guide decision-making”. We create and review and reassess those ‘guides to decision-making’ away from the action itself: we need to keep that part of the decision-making process somewhat separate, otherwise we’ll find ourselves at the point of action trying to decide how to decide, rather than deciding what to do.

On the ‘certain‘ side of the ‘world’, we develop assertions about what should and should-not be done at the point of action. At some distance from the action, the equivalents of ‘principles’ are actually those assertions – the premises for the decision-logic. And at the point of action, the equivalents of ‘principles’ are things like step-by-step work-instructions – rules that we use in the belief that they are ‘true’ for that context.

The work-instructions themselves can be of any length, but note that the decisions at any point tend to be very few: think of a BPMN model, for example, or a state-transition diagram or UML sequence-diagram. In that sense, Ric is right: the applicable principles – more conventionally called ‘rules’, in this context – should be very few in number. Yet he’s also ‘not-right’, in that overall there can be any number of those principles/rules. Once again, ‘It depends…’: in this case, it depends on how we choose to see it, and on the time-window through which we choose to see it.

On the ‘uncertain‘ side of the ‘world’, we explore ways to approach and use whatever we have: for example, in this space, we often use ideas and beliefs as tools, in an ‘as-if true‘ sense, rather than an assertion that it ‘is’ true. What makes it more complex here is that the extent of the uncertainty can go from almost-certain all the way near-infinite unpredictability or uniqueness – and in many contexts we have no way to know whereabouts on that spectrum of uncertainty the issues will lie.

Much as with the assertions on the ‘certain’ side, we would aim to do the exploration and experimentation at some distance-in-time from the action, to devise principles that are of practical use in the action – and in that action, we take it on faith that the principles will usefully apply in that context.

(Just to clarify those terms again: ‘belief’ is what guides real-time action in supposed certainty; ‘faith’ is what guides real-time action in known or experienced uncertainty.)

In practice, these principles must be few in number – usually no more than would fit on the back of a business-card. Sometimes they’re explicit principles; sometimes they’re described as ‘vision’ or ‘values’; but either way the key is that they guide real-time action within unorder – a stable reference-point in the midst of seeming chaos.

Action-checklists are somewhat different, because they kind of straddle both sides of the order/unorder boundary:

• a checklist-item starts out as a belief – an expectation that the world will either be or respond in a certain way
• if the world is not that way, in effect this throws us over to the ‘unorder’ side – because we don’t now know what’s going on
• we then use faith that’s drawn from our own skills and experience, using the principle and/or test outlined with the checklist-item as a guide for action
• if the world does now respond to that action in a known way, we’re back on the ‘order’ side again, and can proceed as per the recovery-checklist
• if the world doesn’t respond to the action in the way that we’d expect or hope, the checklist gives us another checklist-item to try, as a further test and guidance

Look at the detail of the emergency-procedures side of the Cessna checklist. Each of the checklist-sections deals with one specific problem-type – never more than one. None of those checklist-sections has more than ten items, and most are shorter than that – which agrees with Ric’s critique above. All of this happens in real-time: there is definitely no time to think. (So much so that one of the sections includes the stern reminder ‘FLY THE AIRPLANE’!) It isn’t a substitute for skills and experience; but it does provide explicit support for that experience, during real-time actions and conditions under which the connection to those skills could easily be lost. That’s really the point here – and the point of that type of principles.

The other type of principles we see on the ‘unorder’ side are design-principles – the kind of ‘principles’ typified by those in the TOGAF specification or the Simplicable list. In general these aren’t used for real-time action, because they’re too abstract or require too much thought, and hence can be more of a hindrance than a help for those types of run-time decisions. In a sense they’re an exact analogue of action-checklists, but at a greater distance-from-action:

• a design-principle starts out as an assertion – that things should be done in a specific way
• if the world does not allow it to be that way, the assertion is refined in terms of use – working with the ambiguity or uncertainty, rather than by asserting that it ‘shouldn’t exist’

The difference here is that there can be any number of design-principles, because there is time available to explore them, and the trade-offs and conflicts and relative-priorities between them. In these cases, Ric’s critique is not quite fair – though keeping the lists as short as practicable is probably wise. To paraphrase the classic Einstein quote, “our sets of principles should be as simple as possible, but not simpler”.

To summarise the answers here to those questions with which we started:

• a principle is a guide for decision-making, especially where uncertainty exists
• rules, algorithms, guidelines and principles are central to decision-making, and hence all are of key importance to enterprise-architecture
• each enterprise-architecture will also include its own guiding-principles to guide its own actions and decisions
• the term ‘principle’ (without a qualifying adjective) is best reserved for guidelines used in real-time action in ‘unorder’ contexts
• terms such as ‘design-principle’ or ‘data-principle’ or suchlike (with a qualifying adjective) are best reserved for guidelines used in decision-making distant-from the point-of-action (e.g. planning, design, etc)

Hope that’s useful to someone, anyway. Over to you for comment, perhaps?