Just Enough Detail.

To which people will, of course, immediately ask, “Okay, but how much detail is ‘Just Enough Detail’?”. And I’ll have to admit that there isn’t a simple. certain, predefined answer. You just have to kinda know when enough is enough, you know? – which is why it’s more art than science, I guess. And why experience – usually gained by not getting it right… – is so important here.

One thing I do know is that one of the most-quoted answers is usually just plain wrong for this. John Zachman has always said that we need to document everything in ‘excruciating detail’. In a sense, yes, he’s sort-of right, especially if you hold to his metaphor that enterprise-architecture is essentially the same as engineering an aircraft. (I happen to believe that that’s a seriously-misleading metaphor, but that’s another story.) Yet in the real world – even in aircraft-engineering, as I know from much first-hand experience – much of the detail won’t stay the same for long enough to make that ‘excruciating detail’ requirement achievable in practice. Tricky…

Reality is that everything changes, everything moves. And the more they change, the more the demand for ever-more-detail becomes a trap. And when the pace of change itself is accelerating fast – as is definitely the case in most enterprise-architecture contexts right now – the more dangerous that ‘too-much-detail’ trap becomes, and the more we risk falling into it.

Yet on the other side, not enough detail means we won’t have enough of an anchor for meaningful sensemaking or decision-making – so we risk making bad decisions on the basis of too many arbitrary assumptions. That’s not a good idea either.

Hence Just Enough Detail.

The point is that that ‘just enough’ of Just Enough Detail varies all the time, from context to context, depending on who we’re with, what we’re doing, what we’re aiming to do, the type and rate of change, and all manner of other factors. Take this example from one of my favourite ‘show this to clients’ books, Matthew Frederick’s 101 Things I Learned In Architecture School:

There’s actually not much detail in that image. There’s no detail at all of the wall – and yet that’s still enough detail to make out that it is a wall (and probably a white-plaster wall at that). Other than the outline, there’s almost no detail of the woman, or her clothing – and yet it’s enough to get a good sense of who she is, what she looks like. There’s a bit more detail of the church and its dome – enough to tell that it is Brunelleschi‘s masterpiece in Florence – and of the townscape around it. Not much detail, then – and yet that’s all the detail it needs to tell the story. Not too much; not too little; Just Enough Detail.

So, over to you: how much or how little is Just Enough Detail in each part of your enterprise-architecture? How do you show that Just Enough Detail to whoever needs to see the story?

How much does Just Enough Detail change between different layers of abstraction, between different audiences, between backbone versus edge?

How do you know when it’s too much detail, or too little? How do you know when it’s just right? – when it’s Just Enough Detail?

How do you learn this delicate, ever-changing balance of ‘just enough’? From where and in what ways do you learn that balance – without causing too much damage whilst learning it?

Just Enough Detail, always. An interesting challenge, yes?

Uh, no. Not a good idea. Not just because it’s a really bad deal from our perspective, but much more that Reality Department really doesn’t work that way: there’s no short-cut to experience.

Yes, it all looks simple enough – in fact that’s the whole point. A lot of simple visual summaries, and surprisingly simple-seeming methods, too. Yet it only looks simple because we’ve been through a heck of lot of hard work to make it that way. Hard-won experience, won the hard way through years and years of practice in many, many different contexts, getting it ‘wrong’ time and time again, in many, many different ways in order to get it right.

The real trap is that these simple-seeming ideas and methods aren’t simple rules, prepackaged sense-making and decision-making that will always work in every context. These are simple principles, simple guidelines, the kind of easy-to-memorise information that helps decision-making in real-time, in circumstances that are subtly different every time. (See my SCAN posts for more on these distinctions.) If you try to use them as ‘rules’ for inherently-uncertain contexts, without understanding why those principles apply, or how they need to be tweaked every time to match each different context, you’re going to be in real trouble – along with everyone else around you. Not a good idea…

The same often applies even to things that really are ’rules’. Take that example of perhaps the greatest simplification ever made: e=mc². All the core information you need to build a nuclear power-station is right there in that equation: but there’s a heck of a long way – a heck of a lot of engineering-experience – to go from that one equation to building a nuclear-power station that actually works.

Same with everything else, really: simplification is essential, but can also be deceptive – especially when people mistake ‘simple’ for ‘easy’…

Which is also why I get a bit hot-under-the-collar about the current proliferation of ‘certification-schemes’ in enterprise-architecture and elsewhere. Some of them are genuinely valuable, but others – to be blunt – are little better than money-spinning scams, in terms of the actual value that they (don’t) deliver. And the crucial distinction revolves around the role and recognition of experience.

For example, the TOGAF Foundation and Archimate Foundation certifications have real value. They verify that the respective person has a credible command of the terminology and language – a requirement that matters a lot for communication across a dispersed and disparate team.

Likewise the ATAC certifications should have real value, because each explicitly tests practical experience in the respective area.

But unless they’ve changed it in the past year or so, the full TOGAF certification is delivered through the absurdly-inappropriate mechanism of a multiple-choice test. And to my mind, that’s not merely useless, it’s actually worse than useless, because it’s exactly how not to test for the kind of experience that that type of competence requires. (When I did the TOGAF 8 exam some years back, I almost failed because I answered several key questions correctly in terms of real-world experience, rather than the theory-based wrong-assumptions that the test thought were ‘right’.) The result of that kind of pseudo-test is a bevy of people who can wave a certificate around, but have no idea how to do the work in any real-world context.

A good training-course can make all the difference, and the better training-providers do take up some of the slack here. (I’ll wave a flag at this point for John Polgreen at Architecting The Enterprise, who’s been doing sterling work for years on adapting TOGAF for the US-government context.) Yet none of that competence carries through anywhere into the actual test: so unless we know each of the training-providers, we have no way to tell whether a candidate does actually know what they’re doing, or merely that they have a piece of paper to prove that they know just enough to get into real trouble, but not enough to get out of it again.

In effect, right now, the full TOGAF certification is of less real-world value than the Foundation certification – which is both bizarre and sadly pointless. And I’ll hasten to add that I’m using TOGAF here merely as one example amongst many: it may well be that most of the so-called ‘certifications’ in this field are even more meaningless than that. And the results can be seen everywhere in the trade…

In short, it’s a mess.

What we need to be testing for is genuine understanding of a context, and the ability to adapt for uniqueness. And that calls for much, much more than can be covered in a crude multiple-choice test delivered through a mindless machine. Sure, that kind of test is cheap, and relatively easy to administer: but it’s also all but meaningless for anything than foundation-level rote-knowledge. It really does take years of painful practice to develop the experience needed to do this work well: and if this trade is to gain the credibility that it needs, we need to stop pretending that we don’t need to test for that experience.

Time to re-think how we do this, and how we respect this, too: there’s no short-cut to experience.

In the past few days I’ve had a fair bit of struggle to get clients to understand the difference between a linear-sequence with a beginning, a middle and an end, versus a true cycle where the end of one sequence links to or becomes the start of the next.

Cycles are literally cyclic: they’re not just linear sequences, they repeat, often in self-similar ways that are rarely ever quite the same. And the problem is that there are a lot of so-called ‘cycles’ that aren’t cycles at all. Some examples:

• Tuckman’s ‘Forming, Storming…’ lifecycle
• Adizes’ organisational lifecycle
• Gartner’s hype-cycle

At root, these are just linear sequences. For example, Tuckman’s ‘Forming’ stage (purpose) leads to ‘Storming’ (the all-too-necessary-yet-often-avoided people-stuff), thence to ‘Norming’ (planning and preparation) and ‘Performing’ (the actual process of delivering the project). And there it stops: if we’re wise, there’ll also be a final ‘Mourning’ or ‘Adjourning’ phase (closure, completions, lessons-learned), but as far as the individual project is concerned, that’s it. The End – the end-point of a linear sequence.

It’s not a cycle.

To make it a cycle, we need to be able to link the end of one sequence to the start of another: ‘Adjourning’ feeds into and informs the ‘Forming’ of the next project.

Once we have a true cycle, iteration-effects such as complexity and emergence start to appear; continuous-improvement becomes possible; agile self-adapting strategy in a fast-changing environment starts to make sense.

Yet those benefits only become available or visible where there’s a true cycle – not merely a one-shot linear-sequence that happens to call itself a cycle, but isn’t.

Cycles enable visibility of iteration-effects; one-shot linear-sequences don’t. And it confuses the heck out of people that we can have those two very different types of structures arbitrarily assigned the same name.

So if it’s only a linear-sequence, call it a sequence. If it’s a true iterative cycle, call it a cycle. If, like Tuckman’s project-lifetime model, it’s a sequence that can also be linked back to itself to create a true cycle, call it a sequence when it’s a sequence, and a cycle when it’s a cycle. Don’t mix them up!

In short, if it’s not a cycle, don’t call it a cycle. Please?

There’s one significant constraint in this form of publishing: Leanpub uses Markdown text-files for input, which is a fair bit more limited in its formatting than my books normally use. But that constraint fits well with the very tight limitations of .MOBI (Kindle) files – the cause of so many of my conversion-nightmares prior to finding Leanpub – and it also works well with automated import and conversion of blog-posts, which is something I’ve needed for a very long time.

Leanpub also presents e-books as a ‘package deal’, with EPUB, MOBI (aka AZW, for Kindle) and portrait-formatted PDF formats all included in the one price. They also support an automated means to sell via Apple iBooks (for iPad etc) and Amazon (for Kindle), but doing that costs a fair bit and it’s a much lower royalty, so I’ll only be able to do that for books for which there’s a sizeable demand. For everything else, Leanpub is simple enough and cheap enough to make it worthwhile to publish a lot more of my material that way.

A key theme at Leanpub is publish early, publish often. If you buy a book, you not only get all three file-formats, but you also maintain access to all future updates – Leanpub send you an email to let you know whenever a new update is available.

See my home-page at leanpub.com/u/tetradian for the current status of each item – published or in-development – and, if published, the current content.

—-

I’ll be doing three types of e-book publications: books, practice-notes, and anthologies of posts from the weblogs.

Books (Tetradian Enterprise Architecture series)

These are straightforward e-book versions of my existing books, though in some cases with additional content from the blogs. The aim is that these should also move out to Amazon (for Kindle) and probably Apple (for iBooks). Once published, the content should not change – in other words, the same as for a conventional printed book.

Pricing will be a lot less than for the respective printed book.

Already published on Leanpub:

• The enterprise as story - same as for the printed book
• Mapping the enterprise - with an additional appendix on the simplified notation for Enterprise Canvas
• Everyday enterprise-architecture - same as for the printed book

Conversion from Word is not all that simple: each book takes a few days to get ready for publication, so it’ll be a few weeks before all of the existing books are up there. My current priority-order for conversion of the other published Tetradian EA books is:

• The service-oriented enterprise - with some additional notes linking it to Enterprise Canvas
• Doing enterprise-architecture
• Bridging the silos - with some additional notes on working with TOGAF 9.1 and Archimate 2.0
• Real enterprise-architecture
• Power and response-ability
• SEMPER & SCORE

Please let me know if you need my to change that sequence.

(I’ll probably also do all of the books in the other series at some stage, but it’s not so much of a priority.)

Practice-notes (Tetradian EA Practice series)

These will be ‘mini-books’ – typically about half the length of my usual books – that cover a specific topic focused on some practical theme. The content will be based on existing weblog-posts, but will usually be edited quite a bit to make a more consistent structure and story, and there’ll also be a new introduction-chapter to set the context in each case.

These will be updated occasionally, to keep in line with developments in practice, but also to keep the number of updates sent to Apple or Amazon down to a practicable level.

Pricing should be around half that of the full-length e-books.

Titles already in plan include:

• Using SCAN for sensemaking – about sensemaking and decision-making for enterprise-architecture with my SCAN framework
• Modelling with Enterprise Canvas – the simplified notation for Enterprise Canvas, plus model-development methods such as the ‘This’ game
• Backbone and edge - about the architecture trade-offs between slow-changing core and fast-changing edge, waterfall versus agile, and governance to match
• From business-model to real-world practice - conversion from Business Model Canvas to Enterprise Canvas, customer-journey mapping and implementation-layer models such as UML and BPMN
• Modelling service-content - how to use the expanded Zachman-type taxonomy from Enterprise Canvas for whole-of-enterprise modelling
• Whole-of-enterprise architecture - how and why to extend enterprise-architecture beyond its conventional focus on IT

Again, let me know if you want me to add other themes or to change that priority-order – and keep an eye out on my Leanpub page as to when new Practice Notes e-books will be coming out.

Weblog-anthologies (Tetradian EA Topics series)

These will be straightforward anthologies from the Tetradian and Sidewise blogs – the kind of publishing for which Leanpub was initially designed. There’ll be a very simple introduction-chapter, and some minimal clean-up editing, but otherwise each chapter will essentially be the same as on the weblog.

(Note that, for obvious reasons of cross-reference and cross-linking and the like, some blog-posts will appear in more than one anthology.)

The main purpose here is to sort the many posts on enterprise-architecture and related themes (more than 500 posts so far…) into a more usable form, and in a format that’s convenient for offline reading on Kindle and the like.

These will be updated quite often, whenever a suitable set of blog-posts come along – and because of the frequent updates, will probably not go to Amazon’s Kindle-store or Apple’s iBookstore. (You would do a simple file-import to your reader-device instead.) Perhaps the key point is that once you’ve bought the anthology-book, you’ll continue to get all of those updates for free.

Pricing will be minimal – it’s mainly to cover my time for conversion and clean-up. But the price for each book will rise slowly as the amount of content increases – so the earlier you buy the book, the better the deal you’ll get.

Some key topics already identified include:

• Tools and toolsets – including all the discussion around metamodels and the like
• ‘Really Big Picture’ enterprise-architecture – applying EA principles to themes such as economics, sustainability and society as a whole
• The architecture of management – rethinking management and the like from an EA systems-thinking lens
• Story and narrative in enterprise-architecture – the underlying themes behind The enterprise as story

Again let me know if there’s any specific theme upon which you’d like me to develop an anthology.

Comments, anyone?

Full title: The Enterprise As Story: the role of narrative in enterprise-architecture

ISBN: 978-1-906681-34-0

Description:

Most current approaches to enterprise-architecture describe everything in terms of structure. Yet people work better with story than with structure – and people are the enterprise. As we expand the architecture towards a true whole-of-enterprise scope, we need to describe the enterprise as story. Story is everywhere in the architecture – even the enterprise itself is a story.

This ground-breaking book places story at centre-stage for the architecture, itself using a narrative structure to explore the role of narrative in enterprise-architecture. Via business story-structures such as the Market-Cycle, and genres such as We Sell Certainty, it shows how stories underpin every aspect of the enterprise – and how we can use story within the architecture to enhance overall enterprise effectiveness.

Topics covered include:

• how to use story and narrative to assist in sensemaking for architecture
• how to create engagement in the architecture through story
• how to balance structure and story for better business results
• how to identify and use business-story genres to guide overall architecture
• how to change the organisation’s relationships with its ‘anti-clients’ from business-risk to business-opportunity
• how to use story-patterns to identify and resolve strategic business-issues
• how to leverage your own experience to create stronger architecture stories

If you want to create real engagement in the architecture and the enterprise, this is one book you’ll definitely need.

—

You can already order the printed book from Amazon.co.uk or Amazon.com, and presumably most other book-retailers as well.

(Ignore the comment on Amazon about ‘Temporarily out of stock’: Amazon say that for any print-on-demand book that they themselves don’t produce… It’s at most a couple extra days’ delivery-time, that’s all.)

I’ll also be adding it to the book-set deals on Kevin Smith’s Pragmatic EA bookshop: should be set up within the next few days, anyway.

And new - you can now buy the e-book from Leanpub, as a complete set of PDF (portrait-format), EPUB (for iPad, Sony-Reader etc) and MOBI (for Kindle).

I’ll be doing a lot more publishing via Leanpub from now on: not just e-books of the existing books, but also smaller more focussed e-books on topics such as SCAN sensemaking and modelling with Enterprise Canvas. More details on that in an upcoming post, anyway.

The slidedeck is just under 80 slides, split into five sequences:

• “What’s the story?” – introducing the idea of story as a way of working within enterprise-architectures, using the example of Carnaval, in Rio de Janeiro
• “A cast of thousands!” - describing the ‘sharedness’ of enterprises and the enterprise-story, again using Carnaval as its example
• “The plot thickens…” - linking story to process and the practical details of the enterprise
• “To be continued…” - exploring the structure of story, and strategic-structures that cause failure of the organisation’s story
• “Every picture tells a story” - a plea for stronger support of story in our enterprise-architecture toolsets

For once, I did a slidedeck that’s more about visuals than words – and it certainly seemed to go down well with the audience, which is always good fun.

The conference is, for me, one of the highlights of the year, because they cover architectures with such an enormously varied scope: most of the attendees are from defence / security contexts or high-reliability areas such as rail-transport or air-traffic control. I put in a a few sort-of visual jokes that I put in specifically for them – which seemed to go down well, too.

I also did a audio-recording, but it’s a bit crackly. I’ll try to clean it up and, if so, attach it to the slidedeck to make a bit more of a standalone presentation.

Share and enjoy, anyway?

Competence is where someone knows what they’re doing, and does it. And, oddly, often don’t bother to say that they’re competent – perhaps because they don’t need to say it, their actions say it well enough instead. The outcome of competence is fairly certain, even in contexts of high uncertainty.

Non-competence is where someone doesn’t know what they’re doing, and will either not do it, or will do the best they can, yet with the explicit intent to use it as a learning to improve their competence. Importantly, they will usually say that they don’t know what they’re doing. The outcome of non-competence is uncertain, even in nominally-certain contexts, but at least we are aware of the risks.

Incompetence is where someone doesn’t know what they’re doing- i.e. is non-competent to do the task – but either purports and/or believes themselves to be competent. They will usually say that they are competent, even though demonstrably they are not; they claim to be responsible, yet have limited ‘response-ability’. The outcome of incompetence is fairly certain, and frequently dire, yet lack of awareness of the risks is often rampant, or in some cases the risks actively concealed.

Someone who is non-competent can become competent by learning the respective skills, or be competent by proxy, via finding someone else who is competent at doing the respective type of task. I treasure my non-competence, because it means there’s always more for me to learn. And as an enterprise-architect, I am, almost by definition, non-competent in much if not most of the detail-aspects of areas that I need to cover: hence one of my key competencies is the ability to learn enough of a new area fast enough to be able to guide meaningful exchanges between people who are fully competent in some detail-area but are not competent in others with which they need to connect.

Yet one of the key criteria for non-competence, and to separate it from incompetence, is a willingness to accept that we are non-competent, and say so. If we’re not aware that we’re non-competent, we automatically increase the risk of being incompetent. And if we know that we’re not competent, yet somehow ‘need’ to claim that we are competent, we would, again, automatically be incompetent – with a very high risk of inappropriate or ineffective outcomes of the work.

In part it’s a cultural problem: the risk of incompetence increases wherever a culture exhibits any of these characteristics:

• prioritises content over context, ‘truth’ over context-dependent usefulness
• has an insistent ideological base (leading to the same as above)
• is typified by rampant egotism, self-advertising and self-centrism
• is frequently swayed by tides of hype and ‘following after the latest fad’
• displays an almost desperate need to be ‘right’

Unfortunately, all of these attributes are extremely common in business, and in many cases are actively prized… By definition, they’re also more likely to be common in any ‘truth’-oriented domain, one which operates primarily on ‘true/false’ decision-making – hence, in practice, the tendencies towards IT-centrism and finance-oriented business-centrism, both of which rely on simple true/false logic for most of their operational decisions.

In SCAN terms, all of these are where the Simple certainties of Belief – either as ideology and/or as self-belief – are inappropriately applied to the far side of the Inverse-Einstein Test, where the uncertainties of the Ambiguous and the Not-Known cannot be avoided.

This gives us a dysfunctional ‘diagonal’ decision-path, where Assertion is imposed on the Not-known, or Ambiguity ‘solved’ by arbitrary Belief:

Yet the real problem here is somewhat more subtle:

• someone who is competent will typically not bother to say so, but will just get on with the work instead
• someone who is non-competent will typically say that are not competent, but will often actually be adequately-competent, or at least willing to learn to become so
• someone who is incompetent will typically claim that they are competent, and will usually not be willing to learn how to become so, because to do so would betray to themselves and others the fact that they are actually not competent

Which, in practice, leaves us with a huge dilemma:

• those who do not claim to be competent usually are competent
• those who do claim to be competent frequently are not competent

Hence, again, the kind of mess that we see so often in enterprise-architectures, wherever IT-centrism, business-centrism and the like predominate… Oh well.

Comments, anyone?

What we’ve been looking at in this series of posts is a key architectural concern: at the moment of action, no-one has time to think. Hence to support real-time action, the architecture needs to support the right balance between rules and freeform, between belief and faith, in line with what happens in the real-world context. And it also needs to ensure that we have available within the enterprise the right rules for action when rules do apply, and the right experience to maintain effectiveness whenever the rules don’t apply.

As we saw in previous parts in this series, this implies is that within the architecture we’ll need to include:

• a rethink of ‘command and control as a management-metaphor [see Part 1 of this series]
• services to support each sensemaking/decision-making ‘domain’ within the frame [see Part 2 of this series]
• services to support the ‘vertical’ and ‘horizontal’ paths within the frame [see Part 3 of this series]
• governance (and perhaps also services) to dissuade following ‘diagonal’ paths within the frame

So this is Part 4 of the series, the final part: exploring the architecture of governance – and architecture-governance too – that we need for all of this to work well.

[Those two key reminders again: this is 'work-in-progress'; and all of this is recursive - so you'll likely need to do some work of your own here too.]

Within the architecture, we will need governance and governance-services to cover all of the issues that we’ve seen in the previous parts to this series. This would include guidance and governance on the services that support each of the SCAN sensemaking / decision-making domains and the links between them, and on any changes to those services and facilities.

Governance itself is usually outside of the remit of architecture – or probably should be, even if architecture sometimes ends up being landed with the role by default. A better role for architecture here is to identify what it is that needs governance, what kind of governance it will need, and where in the overall structures and story are the gaps that need to be filled – in other words, the governance to help create and maintain what does not yet exist.

As we’ve seen, the overall themes here that governance would need to cover would include:

• techniques for sensemaking and decision-making at the point of action, across the whole range of modality of possibility and necessity (described in SCAN as a spectrum between Simple <-> Not-known, and between Belief <-> Faith)
• techniques for sensemaking and decision-making at varying distance-from-action – loosely categorised as operational, tactical or strategic – and again across the whole spectra of modality (described in SCAN as between Complicated <-> Ambiguous, and between Assertion <-> Use)
• techniques to bridge across the sensemaking and decision-making at real-time (Simple <-> Not-known, Belief <-> Faith) and at distance-from-action (Complicated <-> Ambiguous, Assertion <-> Use) for operational, tactical and strategic distance-from-action
• improvement-processes that link between techniques at distance-from-action and at real-time action, constrained at distinct levels of modality, from true/false (Complicated <-> Simple, Assertion <->Belief – eg. Six Sigma, Taylorist ‘scientific management‘) to fully-modal (Ambiguous <-> Not-known, Use <-> Faith – eg. OODA, improv)
• processes and techniques to develop skills and competence across the full range of modalities applicable within the context
• validation of, training in and usage of all of such techniques

And as we’ve also seen, the governance would need to maintain a balance across all of these themes:

• theory and experience
• ‘objective’ and ‘subjective’
• ‘science’ and technology
• ‘control’ and trust
• true/false and fully-modal
• organisation and enterprise
• structure and story
• sameness and difference
• ‘best-practice’ and (understanding of) ‘worst-practice’
• ‘sense’ and ‘nonsense‘
• certainty and uncertainty
• caution and agility
• rules (‘the letter of the law’) and principles (‘the spirit of the law’)

Ideally the governance should also cover any applicable management-structures, with a strong emphasis on ‘management as a service‘ rather than as a dysfunction-prone pseudo-hierarchy. At present, though, that’s still likely to be too ‘political’ and problematic for architecture alone to face… – for now, probably best to class it as an architectural-waiver, to be addressed if and when the opportunity should arise.

Decision-physics

There’s a further point that I don’t think has come through clearly enough in the previous parts in this series. This is what we might term ‘decision-physics’, by analogy with mainstream physics.

Mainstream physics has three distinct layers: the very-small, the mid-range, and the very-large.

Most of what we deal with in terms of ‘the laws of physics’ is in the mid-range: Newtonian physics and the like. Everything seems to follow identifiable rules or ‘laws’; classical physics focusses on the direct impacts of those apparent laws, whereas in some cases there are contextual ‘emergent properties’ that arise from interactions between entities – though note that it’s still the same physical-laws beneath those interactions.

Our mainstream ‘decision-physics’ – what I’ve described as ‘considered’ sensemaking and decision-making – likewise seems to make sense across a very broad mid-range, from strategy to tactics to operations. And we see much the same distinction between all-predictable ‘hard-systems’ (Complicated / Assertion, in SCAN) versus complex, iterative, emergent ‘soft-systems’ (Ambiguous / Use) – though note again that’s still ultimately the same ‘laws’ on either side of that spectrum.

Yet some of those key ‘laws’ break down when we move to the far extremes. In cosmological-physics, for example, the speed of light seems to be an absolute constant across almost all timescales – yet not for the first infinitesimal instants of the Big Bang, or for the furthest reaches of time. Somewhere our present physics, there’s presumably some kind of circular self-referential assumption – but we don’t yet have the means to work out what it is.

Much the same applies in our ‘decision-physics’. Most of the time – such as in most enterprise-architecture work – the usual assumptions and decision-methods work well enough. Yet once we move to the scale of the very-large – with longer timescales, for example, or what I’ve termed ‘really-big picture enterprise-architecture‘ – some of those assumptions begin to be more evident, and become much more problematic. When we do have to work at those scales – and some enterprise-architects do so already – then we need to be aware that a somewhat-different decision-physics may apply: for example, conventional notions of ‘possession‘ and the like may no longer make sense.

The certainties of mainstream physics also tend to break down at the scale of the very-small, as we move into quantum-physics and the like. It’s actually the same underlying physics, but all manner of assumptions that we could get away with at the everyday Newtonian scale become visible as assumptions. This applies particularly around certainties versus probabilities, which at the quantum scale gives us seemingly-impossible phenomena such as ‘particles’ that can be in more than one place at the same time. (This also gives us occasional oddities in larger-scale physics, such as in signal-theory, where to guarantee perfect signal-transmission we would need a conductor of infinite size.)

In the same way, many of the assumptions of mainstream ‘considered’ sensemaking and decision-making start to break down once we get at or very close to the moment of action. The key ‘takeaway’ that I hope you get from this multi-part exploration with SCAN is that what happens at the point of action is real: everything else is an abstraction.

And it’s an abstraction that may not have much connection with reality at all. All of so-called ‘rationality’ is an abstraction: hence, for example, why ‘rational-actor theory’ and much of current mainstream economics has been such a disastrous bad-joke, and why ‘control’ is a such a misery-inducing myth in most current forms of business-management.

What we actually have at the point of action are literally-emotive decisions made on belief and faith. Just as quantum-physics underpins the larger-scale Newtonian-physics, all of our abstractions are actually underpinned by real-world emotion – literally, ‘that which moves’.

Thinking is extremely important, of course, because it clarifies intention. But neither thinking nor intention actually do anything on their own: for something to happen, we need to link intention to emotion. Which in most cases also means that we need to link the type of intention to the matching type of emotion-that-drives-action – and likewise match the emotion back to the required intention, to get the maximum effectiveness from expenditure of energy.

[Not every emotion is effective, of course: aggression, panic or 'awfulising' - otherwise known respectively as 'fight, flight or freeze' - can use up a lot of energy without achieving anything useful at all... Likewise the same does also apply to machines and IT-systems, but kind of at one step removed: plenty of motion without emotion as such, it's true, but it's human emotion and human choice that links all of that activity back to intent.]

So at the point of action – the quantum-level of our ‘decision-physics’ – what we actually have is a range of emotion applied across that scale of modality. And it’s here that the Inverse-Einstein Test becomes crucially important, because it provides the key distinction between what I’ve termed ‘belief’ and ‘faith’:

– belief is grounded in certainty, and in the centrality of self

Belief expects the world to work in a specific way: doing the same thing will – or should – lead to the same results. We proceed with the conviction that this is true. An abstract idea – a ‘law of physics’, perhaps, or a more mundane work-instruction or checklist-item – becomes actionable in real-world practice when we attach ourselves to it, as a personal commitment to its ‘truth’.

[Perhaps the starting-point for all belief is faith - as we'll see in a moment - but belief itself provides a stable anchor from which to act.]

For the most part, this how most things are actioned in business and elsewhere: we follow the rules, to get the same results. For the most part, and in many if not most everyday contexts, this is what we want in business and the like: the right beliefs deliver the right results. Yet there are couple of important catches that we need to note here, both of which have their roots in that personal commitment, and both of which are common causes for ineffectiveness and overall failure.

The key to both of these is the Latin word ‘credo’ – literally, ‘I believe’. Note the ‘I’ here: I, me – the commitment of self to the belief. The commitment is what creates the drive to action, power as ‘the ability to do work’. Yet if we shift too far over to a self-centred view, ‘I’ as the centre the world, we risk falling into the social misperception that power is the ability to avoid work: ‘the rules’ are deemed to apply to others, and to drive others’ actions – with those others being viewed as extensions of self that ‘should’ be under our control yet without requiring any actual action or responsibility on our part. Hence those endless ‘shoulds’ – applied to the world in general, to machines and systems, and even more to other people. (‘They should’; ‘everyone ought’; ‘it must’; so many phrases like that – though noticeable is the relative rarity of ‘I should’…) In effect, the emotion shifts away from doing useful action, and toward trying to ‘control’ others instead – a well-proven recipe for wasting all one’s energy in ineffectual anger… There are some real governance-issues here, and some useful tools for this, such as the SEMPER diagnostic I developed some years back.

The other side of this is a classic give-away for dubious discipline in the sciences and elsewhere: getting overly emotional about the ‘truth’ of ideas, theories and beliefs. Belief is emotional, a driver for action; yet in itself, thought is neither emotional nor actionable. So when we see someone getting emotional about ideas, aggressively asserting that their ideas are ‘the truth’ – or, more especially, that someone else’s ideas are ‘wrong’ – it’s not actually about the ideas at all: it’s about that person’s ego, a demand that others’ action should place that person at the centre of their world. This is the basis of ideology, where the ‘truth’ of the belief-structure deemed to be more ‘true’ than the messy complexities of the real-world – and where those who hold that ‘truth’ deem themselves to be ‘better’ than any others, solely because they hold to that ‘truth’. (There’s a nice Freudian pun here: ideology as ‘id-eology’…) Hence, again, why ‘office-politics’ is actually a hugely-important governance-issue in enterprise-architectures.

The key effect of both of these is a disconnect from the real-world: a demand that the world ‘should’ conform to our expectations, and an assertion that the world itself is ‘wrong’ if it fails to conform to those expectations – all often coupled with a daft dependence on circular-proofs and ‘other-blame’. So whilst emotion and ego are essential to get things going, we do need to keep them in their place… hence, again, the need for appropriate governance right down to this level, all the way across the whole enterprise.

– faith is grounded in uncertainty, and in relation to ‘that which is greater than self’

Faith is what happens when we’re in the Not-known – where doing the same thing leads to different results, or to get the same result requires that we do different things. Faith is the emotive mechanism that we use when we don’t know what to do, yet don’t allow ourselves to get caught up in the classic Belief-driven panic-responses of ‘fight, flight or freeze’ – in other words, to use Susan Jeffers‘ phrase, we ‘feel the fear and do it anyway’.

Whenever we come across any context that has some component of Not-known or None-of-the-above, this is what we have to do. Somehow. Some people find this easy; yet for many people, so important is the sense of safety that comes with certainty, that this kind of ‘letting-go’ can be very hard to do… and organisations and organisation-structures that assert the absolute primacy of ‘The Rules’, and deny the inevitability of the Not-known, will make that letting-go that much harder. Hence there are some significant design and governance-issues here for enterprise-architecture.

What doesn’t work well in this space is ‘flailing’ – doing something just for the sake of doing something. Often what’s needed first is the exact inverse of the old adage: “Don’t just do something, stand there!”. We keep the panic at bay – and avoid a fallback to literally-incompetent Belief – by coming to a calm centredness within the space, and (usually metaphorically, though sometimes almost literally) allow the space itself to speak to us, to show us what to do. And at that point, take action – all in real-time.

At the first point of contact – and especially so at the further extremes of modality – this is literally a context of chaos: in principle at least, anything is possible there. That’s the advantage of the Not-known; it is, obviously, also its disadvantage, since any number of things that we don’t want to happen also become equally possible at that point. Hence the need for appropriate tactics that work within the chaos, and provide guidance towards the results that we need.

There are any number of well-known tactics that don’t work well here: for example, ‘take control!’ might be the preference for any Taylorist manager, but in practice all it does is pull us back over to Simple Belief – which is not where the solution to a Not-simple problem is likely to reside… And there are a fair few would-be ‘The Answer’ options that contain fundamental flaws in this regard – a point we’ll come back to later.

Although there’s an element of Schrodinger’s Cat in this, what does seem to work is ‘seeding the chaos’: bringing explicit aims and intentions into the space, yet also allow the space to be what it is. (I’m at some risk of making this sound a bit like “hey, ’60s counterculture, man”, but actually there’s a lot of practical sense in Timothy Leary’s notion of ‘setting and set‘, even within everyday business-contexts.) Hence, in enterprise-architectures, the real importance of ‘setting the scene’ with vision, values and more-actionable principles – all of which provide an anchor of a direction and intent which is ‘greater than self’. ‘Success-stories’ in business – especially those about the grass-roots operational levels – will often revolve around use of such ‘seeding’ to guide context-appropriate action in unexpected circumstances.

Dysfunctional diagonals

One of the key points that came up in the previous post was the importance of having explicit processes and methods to link intent and action, and also to link across the modalities. In SCAN, we would describe these as ‘vertical’ and ‘horizontal’ links:

What we don’t want, though, are ’diagonal’ transitions that link one type of modality at the ‘considered’ level with a different modality at the point of action – such as Assertion misapplied to a Not-known context, or introducing the Ambiguous at the very moment of Belief-based action:

Probably the classic example of this is the myth of ‘control’, typified by the many, many misuses of Taylorism and its descendants and derivatives. For example, Six Sigma makes perfect sense, and is very valuable, when applied to contexts with very low variation; but it doesn’t make sense, and is often dangerously misleading, when attempts are made to apply it to anything other than a context consisting solely of literally millions of nominally-identical events. Business-process reengineering was another infamous example: one of its leading proponents, Michael Hammer, is quoted on the Wikipedia-page as later admitting that:

“I wasn’t smart enough about [the human impact]. I was reflecting my engineering background and was insufficiently appreciative of the human dimension. I’ve learned that’s critical.”

In SCAN terms, each of those is a ‘diagonal’ link of Complicated <-> Not-known – which doesn’t work. We also get the same effect, though, if we take something that does work well as a link of Complicated <-> Simple, and implicitly apply it to a modality beyond its specific true/false constraints. One example that comes to mind here is Roger Sessions‘ work on Simple Iterative Partitions as a method to reduce or eliminate ‘complexity’. It does work extremely well within the relatively-narrow scope of IT-systems themselves – where, in SCAN terms, ‘complexity’ is an undesirable excess of Complicated, leading to system-applications that are not Simple enough to work effectively in real-time action. Yet it’s misleading if we use the same concepts to talk about the application of IT-systems in real-world contexts which, because they’re real-world contexts, frequently must deal with a different type of ‘complexity’ that can’t and sometimes shouldn’t be ‘eliminated’. In effect, that’d be Complicated <-> Simple applying an Assertion that Ambiguous <-> Not-known doesn’t actually exist – taking us straight back to the Taylorist myth of ‘control’, which is not a wise move.

[A quick somewhat-personal note here: Roger has always been a great sparring-partner on this question - perhaps best described on my part by the old phrase "I disagree with every word you say, but I will defend to the death your right to say it"? ]

Going the other direction, we could use the example of Andrew McAfee’s ‘Enterprise 2.0‘, ”the use of emergent social software platforms within companies, or between companies and their partners or customers”. Nothing wrong with that definition itself, but the point here is that the application is about collaboration across the organisation – Ambiguous <-> Not-known, or Use <-> Faith – whereas McAfee placed inordinate emphasis on the technologies instead, or Ambiguous <-> Simple. Ignoring the real complexities of the human-factors was exactly the same mistake that caused so many business-process reengineering projects to fail – a point which was quickly picked up by many practitioners with real-world experience. Surprisingly, McAfee took a long while to acknowledge the problem, eventually coming out with a blog-post ‘It’s not not about the technology‘ – which was true, but still kind of missed the point.

Another example has been a bane of my professional life for the past few years: David Snowden’s Cynefin framework. In SCAN terms, it purports to cover the Ambiguous <-> Not-known link – somewhat like McAfee’s ‘Enterprise 2.0′, but with more emphasis on complexity-theory and social-systems in general rather than in one specific application. The problem here – and despite many, many explanations of this, Snowden still emphatically refuses to acknowledge the problem – is that Cynefin explicitly locks out the linkage to the Not-known / Faith space, for which the nearest equivalent in Cynefin is termed the ‘Chaotic domain’.

The Cynefin framework states that the standard tactic in the Chaotic is ‘Act > Sense > Respond’: which in principle might seem fair enough, except that in many cases – as described above – ‘doing for the sake of doing something‘ is exactly what we should not do as a response to ‘chaos’. Even when action is appropriate, the catch is in what happens next, because the documented ‘Cynefin dynamics’ in effect insist that our only method of dealing with the Chaotic domain is to not be there: our only apparent options are to ‘take’ control’ and collapse back to the Simple domain, or return to ‘considered’ sensemaking in the Complex domain. In SCAN terms, the former is a diagonal-link of Ambiguous <-> Simple, which is clearly not a good idea; the latter is a self-referential loop of Ambiguous <-> Ambiguous, which looks impressive and gives us more and more information about complexity and emergence and the like, yet clearly is not going to go anywhere that’s any actual use. In that sense, Cynefin actively prevents us from applying its insights in real-world practice: it’s valuable for ‘considered’ sensemaking, but literally useless for real-time decision-making. So although Cynefin does claim to cover the whole ‘complexity’ space, the only way to use it in practice is to not use it – which is not exactly helpful…

[There's more on this in other posts here, if you're interested: for example, see 'Using Cynefin in enterprise-architecture' and 'Comparing SCAN and Cynefin'.]

For a final example, we could turn to something that’s perhaps more familiar to many enterprise-architects: Agile software-development. In principle, it’s a good response to the reality that software-development takes place in a world that has a great deal of Not-known about it. And it’s also a response to the ‘traditional’ Taylorist-style Waterfall model of software-development, in which everything would be rigidly defined ‘up front’ without acknowledgement of the reality or probability of changes in the context. In effect, it aims to take the Assertion <-> Belief link on which all conventional IT-systems depend, but apply it via a disciplined Ambiguous <-> Not-known link such that the overall development-process can adapt in near-real-time to changing needs.

That’s the principle: and with experienced, adaptable developers who know what they’re doing and how to work with inherent-uncertainty – in other words, Master skill-level, or Journeyman with a bit of mentoring from Master – it does work well. Unfortunately, it doesn’t work well with developers who don’t have that kind of skill or experience – the Apprentice or, worse, the Trainee. So what we get there instead, all too often, is an undisciplined mess: not enough skill or discipline to work with Faith-style uncertainties and the Faith <-> Belief axis, coupled with a rejection of the formal disciplines demanded by the Complicated / Assertion domain. In other words, not only a problematic ‘diagonal’ of Complicated <-> Not-known, but the worst of both as well. Oops…

And yet somehow we do still need that agility: hence this is one aspect of enterprise-architecture governance where the need for balance is perhaps better-known and better-understood. You’ll find various posts here on what I’ve termed the ‘backbone’ – for example, see ‘Agility needs a backbone‘ and ‘Architecting the enterprise backbone‘; there’s also a good summary by Vikas Hazrati on the InfoQ website, ‘Agile and Architecture Conflict‘. But perhaps I ought to leave the last word here to a software-architect I greatly respect, Simon Brown, who’s frankly brilliant at describing the practice of how to ‘seed the chaos’ to get the best results in agile-development: see his presentations and videos to explore the trade-offs that we need so as to derive an agile-architecture that works, and how to resolve the architecture-challenge of “How much architecture is ‘just enough’?”

—

Okay, that’s it for now. Plenty more to say on all of this, of course, but I’d guess it’s been more than enough already?

And many thanks reading this series: hope it’s been useful? Over to you for any comments and questions, anyway.

What we’ve been looking at in this series of posts is a key architectural concern: at the moment of action, no-one has time to think. Hence to support real-time action, the architecture needs to support the right balance between rules and freeform, belief and faith, in line with what happens in the real-world context. And it also needs to ensure that we have available within the enterprise the right rules for action when rules do apply, and the right experience to maintain effectiveness whenever the rules don’t apply.

As we saw in previous parts in this series, this implies is that within the architecture we’ll need to include:

• a rethink of ‘command and control as a management-metaphor [see Part 1 of this series]
• services to support each sensemaking/decision-making ‘domain’ within the frame [see Part 2 of this series]
• services to support the ‘vertical’ and ‘horizontal’ paths within the frame
• governance (and perhaps also services) to dissuade following ‘diagonal’ paths within the frame

So this is Part 3 of the series: exploring the architecture of how we link together the various domains of sensemaking and decision-making within the enterprise.

[Two key reminders here: this is 'work-in-progress', so expect rough-edges and partly-baked ideas; and although I'll aim to keep the descriptions as simple of possible, note that all of this is recursive, with many intersecting layers of simple and definitely-not-simple - so please do expect to have to do exploratory-work of your own here too.]

On services to support the ‘horizontal’ and ‘vertical’ transitions:

We can summarise this part in terms of the following diagram:

Although sensemaking and decision-making tend to be blurred together within these transitions, there’s usually a clear set of distinctions:

• services that work across the modalities in real-time action
• services that bridge between certainty and uncertainty in planning for action and reflection on action
• services that improve how we apply certainty in action
• services that improve how we work with uncertainty in action

The first two sets of services are primarily ‘horizontal’ across the SCAN frame, linking across the modalities but at a single timescale; the other two sets are primarily ‘vertical’, crossing timescales but on either side of the Inverse-Einstein boundary. There’s obviously enormous scope here, but to keep things simple I’ll stick to a single scenario for each.

For real-time, imagine starting this off with a checklist – a pilot’s pre-take-off check for an aircraft, perhaps.

This gives us a Belief-based structure for decision-making – ‘belief’, because the ‘correct method of working’ is embedded in the sequence of the list. It also gives a Simple true/false method for sensemaking – ‘simple’, because either something checks off against the list, or it doesn’t. After much repetitive practice, using this checklist is ‘second-nature’ to the person doing this work – yet the list is also followed with care and attention.

And because the checklist is followed with care – as ‘the truth’ – the pilot notices that something doesn’t check off correctly. For this example, we’ll assume it’s the radio: there’s no response and no apparent signal from the control-tower.

The moment that we hit something that ‘doesn’t fit’, by definition that throws us across the other side of the SCAN frame, into the Not-known. Notice that for a (very) brief moment, there’s a sense of panic – at which point all the previous training and skill and experience should kick in, together with Faith-based decision-making, to cope with ‘a context larger than that covered by the rules’.

[I've deliberately chosen a fairly minor yet everyday example here: an incorrect radio-setting. For a far less everyday example where the same principles and processes apply, moving back-and-forth across the real-time spectrum, see the section 'Sensemaking in real-time' in the post 'On sensemaking in enterprise-architectures [Part 2]‘.]

In a fully-structured process, there would be another checklist here, specifically to guide sensemaking and then decision-making around what’s (not) happening with the radio – in other words, a tool to pull this back over to the left-side of the frame again, with Simple / Belief. But if the checklist doesn’t exist, or isn’t found, the sensemaking and decision-making remains over on the Not-known / Faith side of the frame.

It’s a high-risk context, so the pilot can’t afford to ignore the problem, and also can’t ‘go on faith’ – the checklist makes it clear that that radio must be working correctly before take-off can be allowed. So notice what happens next: the sensemaking remains on the unorder side, but drops out of real-time. Everything slows down: the pre-take-off process has to stop whilst the pilot carries out a quick series of experiments – in other words, moving somewhat up into the Ambiguous / Use space.

Most of these are Simple true/false tests (is the radio switched on? is the headset connected? is the frequency-setting correct?), which in principle are rule-based, except that the pilot is creating these tests on the spot, from past experience and knowledge of the equipment, rather than following a (non-existent) checklist. One of these tests shows that the frequency has been set for the destination airport rather than this one. The pilot looks up the correct frequency from a reference-chart – another Simple tool – and then changes the channel – a Belief-based decision.

Going back to the original checklist – in other words, now back in real-time again, over on the left-side of the SCAN frame – the pilot re-checks the radio-call: this time it does confirm correctly. The pilot then completes the pre-take-off checklist without any further Not-known interruptions.

From an architecture perspective, notice two points here.

The first is that real-world sensemaking and decision-making at the point of action will often bounce back and forth between Simple / Belief and Not-known / Faith. Most typical business-processes will start over on the Simple / Belief side of the frame – in other words, ‘follow the plan’; yet anything unique, anything different, anything unexpected that doesn’t fit the predetermined ‘the Rules’, will automatically force a transition over to the Not-known / Faith side of the balance. And in most cases, only skill and experience will bring it back over to the Simple side again, to deliver the required result. That’s what skill is, and largely what it’s for.

The second point is that systems which can only work with rules – which in practice includes almost all machines, and most IT-systems – cannot actually cope with that transition into the Not-known. And many if not most real-world contexts do include uncertainties of some kind or other. In such cases – which, again, is most cases – rule-based systems cannot be used to address the whole context: there must be a human skill-based component both to identify when the rule-based system is out of scope, and to take over when it does go out of scope.

The danger here is that IT-systems can sometimes simulate full-context capability from sheer speed applied to a sufficiently large rule-base – which gives the illusion that it can cope with the full context. Fact is that it probably can’t – that uncertainty again – but if we design on the assumption that it can, we’re going to be in real trouble when (not ‘if’) it fails. The architecture needs to take great care on this point: yet the sad fact is that most current architectures – especially IT-centric ones – don’t take anything like enough care with fallbacks and the like here. You Have Been Warned?

For reflection-time – moving back-and-forth across the frame, but at some distance from real-time – what we need are processes that focus on pragmatics and praxis: distilling theory from practice (right-to-left on the SCAN frame), and applying theory to preparation for practice (left-to-right on SCAN) in the unordered-realms.

This is the transitions between what’s described in SCAN as Complicated / Assertion and Ambiguous / Use. What we’re looking for here in the architecture is support at various different timescales – strategic, tactical, operational – for a whole swathe of interactions and trade-offs across the two sides of the frame. As mentioned back on the post ‘Decision-making – belief, fact, theory and practice‘, some of the keywords we’d look for on each side of that balance would include:

• theory versus experience
• ‘objective’ versus ‘subjective’
• ‘science’ versus technology
• ‘control’ versus trust
• true/false versus fully-modal
• organisation versus enterprise
• structure versus story
• sameness versus difference
• ‘best-practice’ versus (understanding of) ‘worst-practice’
• ‘sense’ versus ‘nonsense‘
• certainty versus uncertainty
• rules (‘the letter of the law’) versus principles (‘the spirit of the law’)

For example, this is – or should be – the ‘applied science’ transactions between the assertions of science and the usefulness of technology, each lifting the other to new levels of capability. And we’ll only achieve a real effectiveness via a fully-nuanced ‘both/and’ balance across all of these dimensions, and more – which is what the architecture needs to support.

At present, though, most enterprise-architectures and their subsidiary domain-architectures will be hugely skewed towards the left-side of that balance: theory and ideology, ‘objective’, ‘science’, structures, sameness, ‘sense’, rigid rules, near-random re-use of others’ supposed ‘best-practice’, true/false ‘proof’, abstract organisation (rather than human enterprise), and, above all, certainty and predictability. Yet the end-result of such imbalance is an architecture that is all but incapable of coping with either uncertainty or change – and relies instead on a stream of management-fads to give a spurious sense of certainty where none actually exists. Which is not a good idea, especially in the increasing uncertainties of most present-day business contexts. We need that balance…

The simplest way to work towards a better balance is that, for each item that seems to fit in either the Complicated / Assertion domain or the Ambiguous / Use domain:

• what is its counterpart in the opposite sensemaking or decision-making domain on the other side of the frame?
• what processes link these two items together, such that each can learn from and support the other?
• how do these processes vary at different distances from the point of action?
• how do these processes vary for different skill-levels or for use with different real-time process-implementations?

(We’ll come back to that last question shortly.)

So, for example, Complicated-domain analytic, algorithmic hard-systems theory has its Ambiguous-domain counterpart in experimental, emergent soft-systems theory: in what ways do these link together? How do they support each other, inform each other, conflict with each other, enhance each other? How do we identify (make sense of) which approach would apply better to any given context? What are the trade-offs that would guide such decisions?

[For some great examples of how this kind of interaction works in scientific research, see WIB Beveridge's 1950 classic The Art of Scientific Investigation.]

Using those tests and guidelines, work your way across all aspects of the architectures, to identify gaps and imbalances across the SCAN domains.

For improvement of real-time action, the processes would, in principle, be partitioned across either side of the Inverse-Einstein test: those processes that focus ensuring that the same actions lead to the same results, versus those processes that focus more on skills-development, such that we can achieve the required variation in similar contexts or the required ‘sameness’ in different contexts. In very quick summary:

• improvement on the left-side (‘order‘) will focus primarily on efficiency (typically described in quantitative terms, and often regarded as synonymous with effectiveness)
• improvement on the right-side (‘unorder‘) will focus more on broad-spectrum effectiveness (with an emphasis on qualitative factors and human-concerns)

That order-versus-unorder partitioning is valid in itself – the Simple true/false methods used by machines and IT-systems, versus the full modality of methods available within skills-work. Yet it’s also in itself too simple, or too simplistic, rather: we need the framework to give guidance on skill itself.

This is where we come back to that question about reflection-processes that vary according to skill-levels. In essence, it’s not really a skill unless there’s some inherent-uncertainty involved in the context: before that, all the way over onto the Simple side of the spectrum, everything is literally mechanical, rule-based.

For this, we can turn to a cross-map of the SCAN frame with a spectrum of variability or predictability – shown as the blue curve in the diagram below:

The diagram is perhaps slightly misleading here, because the impact of variability doesn’t come out well enough: the blue line is itself another kind of continuous spectrum, rather than the Simple true/false implied by the colour-shading here.

[Part of the reason is that I don't yet know how to how to do multi-layer multi-colour graded-shading in Visio: accept it as it is for now, if you would?]

What is relevant here is the the way in which skills-development follows the same effective path of increasing variability – including that increased distance-from-action in the middle of that curve.

What we actually have in skills is not so much a Simple ‘either/or’ – Simple or Not-simple, order or unorder, as implied on the diagram – but more a ‘both/and’ mix of order and unorder. Higher levels of skill also implies or requires the ability to cope with higher levels of modality, variability and unorder. We can split this in terms of five distinct skill-levels:

• Robot: no skill as such – Simple rule-following only
• Trainee: low level of skill – mostly Simple / Belief, aware only of ‘here and now’, requires active supervision to cope with variability
• Apprentice: some level of skill, still primarily order-based but able to manage more Complicated / Assertion contexts with broader factors and feedback / feedforward loops, with some active supervision
• Journeyman: significant skill, able to cope with higher levels of Ambiguity and context-dependent Use, with supervision mainly in the form of mentoring
• Master: high skill, able to cope with inherent-uniqueness, balance of ‘big-picture’ with ‘here and now’, and ‘supervision’ only in the form of peer-review

So when we look at the ‘vertical’ improvement-processes implied by the SCAN frame, we tend to find that they work best when they act on specific mixes of order and unorder, sameness and uniqueness – in other words, in alignment with these skill-levels.

We can also see the classic ISO-9000 quality-system derivation-sequence at work here, between each of those steps:

• work-instruction: context-dependent rules used by Robot and initial Trainee – emphasis on What and How
• procedure (basis for new work-instruction): used by Apprentice and above, defined by Journeyman and above – emphasis on Who, Where and When
• policy (basis for new procedure): used by Journeyman and above, defined by Master – emphasis on Why
• unchanging-vision (permanent-anchor for quality-system, used as basis and cross-check for new policy): used by Master, defined by Master in peer-review – the ‘Because.’ behind the Why

There are many, many types of review / improvement-processes – PDCA (Plan, Do, Check, Act), for example, or AAR (After Action Review) or OODA (Observe, Orient, Decide, Act). Yet almost all of them have this ‘vertical’ character, to link:

• from real-time action – where there’s no time to think
• to distance-from-action – which creates thinking-space and review-space, to enable improvement
• then back to real-time again – to apply that improvement in real-world practice

There’s a usually a slight sideways-move in there somewhere – because wherever practicable the aim should be to enhance those skill-levels, not leave them solely as they are. But what we don’t want are ‘diagonal’ moves that try to link one type of order / unorder mix at ‘thinking-time’ with a very different mix at real-time – because it all but guarantees failure in practice. We’ll explore that point in more detail in the next part in this series: for now, we’ll focus more on the ‘verticals’.

We can again summarise these processes in terms of those five distinct skill-levels:

– Robot: Simple / Belief only (typically machines or real-time IT-systems) – aim is to optimise efficiency within a specific defined context

This is the classic realm of Taylorist time-and-motion study, of Six Sigma and suchlike: if we assume that everything in the work-context remains the same, what can we do to improve the efficiency of that ‘sameness’?

The crucial point here is that the Robot can only follow the rules that it’s given: it can’t change anything by itself – or even adapt to any significant change in its context. The Robot must rely on an external ‘expert’ to redefine its rules whenever the context undergoes any significant change, yet the ‘expert’ does not have to deal with real-world consequences: a fact which, if misused, can lead to a dangerous co-dependent relationship between Robot and ‘expert’, based on mutual evasion of responsibility – something that we see far too often as an outcome of dysfunctional blame-based management-structures.

– Trainee: Simple / Belief <-> Complicated / Assertion – aim is to develop ‘rule-following’ efficiency and to develop awareness of the ‘larger picture’, to place own work in context, and to begin to cope with variability

We typically see two types of review-processes here. One type concentrates on practice – embodying ‘the rules’ through constant repetition, mainly focussed on method, on the ‘what’ of those rules as applied to real-time action. The other type, typified by the US Army’s ‘After Action Review’, begins a focus on enhancing personal ‘response-ability’ – a concern that will continue all the way through the skills-development sequence.

– Apprentice: Complicated / Assertion <-> Simple / Belief (with some bridge over to Ambiguous, e.g. via experimentation) – aim is to develop ability to use formal-theory to redefine own rules as the context changes

This is the classic realm of formal education, with an emphasis on theory and on the mechanics of the skill, the ‘how’ behind its processes and methods. However, the focus is almost more on ‘order’ than at the Trainee level, defining rules as ‘objective truth’ to be applied by others in real-time action. The main contextual-shift is a developing awareness of more and more Complication in those ‘rules’ – a layering nicely described by Jack Cohen and Ian Stewart as an increasing sophistication of “lies-for-children” – in which additional factors, interaction-loops and delay-impacts are added to the rule-definitions. One of the hardest parts of this stage is re-simplifying these ever-more-complicated algorithms and ‘rule-sets’ down to a form that can be used in real-time action…

– Journeyman: Ambiguous / Use <-> Not-known / Faith (with some bridge over to Complicated, e.g. as ‘applied science’) – aim is to enhance ability to work with increasing levels of variation and near-uniqueness, such as by applying patterns and guidelines

This is typified by the crucial shift in awareness that theory alone is not enough: in the real world, ‘truth’ is often highly contextual. This is the realm of ‘real’ complexity, of emergence, of iterative exploration and experimentation, and also a more explicit acknowledgement of the inherent unorder that underlies wicked-problems and the like. It’s also a realm of probability and improbability – hence a strong focus on concerns such as the uncertainties of statistics, on kurtosis-risks, long-tail opportunities, and so on.

[Note the danger of failure to understand the probabilistic nature of statistics - that they always embed and embody some degree of unorder and uncertainty. It has its rules, but they're not the same order-based rules as in the Complicated domain: for example, it's true that chaos-mathematics can enable us to be very precise about the degree of uncertainty in a context - but it does not remove the uncertainty itself. Another important 'You Have Been Warned' that we need to pass on to our architecture-clients?]

There would also be a stronger emphasis here on guidelines and patterns, and on what we might describe as the approaches to each skill – the unorder of the ‘other mechanics’ of the skill, such as in the psychological and emotional drivers, and in ergonomics and individual difference. Continuing and expanding the theme of the After Action Review, this is the realm of responsibility-oriented continuous-improvement processes such as PDCA and kaizen, of simulators and ‘sandboxes’ and other ‘safe-fail’ learning-spaces, and also of context-exploration tools such as the skills-labyrinth.

– Master: Not-known / Faith <-> Ambiguous / Use – aim is to enhance effectiveness, being able to work with any level of variability and uniqueness at real-time, in line with overall vision and values

It’s at this level that we return to real-time practice, but this time aiming to be able to work with unorder, rather than fight against it (or even pretend that it doesn’t exist…), as in the rule-based assumptions of the Robot space. Here there’ll be a strong emphasis on enhancing capability for improvisation, and for coping with inherent uncertainty, such as with innovation and with Black Swans and other opportunities and risks at the extreme end of unorder. For skills, this would also bring together the previous themes in active acknowledgement that method = mechanics + approaches – hence true skills are both same and different for everyone at every time. On a practical level, there’s also a strong emphasis on the use of principles, vision and values to provide a stable anchor for guidance amidst inherent-uncertainty.

[Notice that, again, all of the above sequence is recursive: we may well be at Master level in some skill-domain, but barely at Trainee-level in another - a fact that can at times be somewhat challenging... ]

Implications for enterprise-architecture

For enterprise-architects, there’s a lot to review here, because all of those items need to be in place if the overall architecture is to work well for the organisation and enterprise:

• services that bridge across the modalities of certainty and uncertainty in real-time action
• services that bridge between certainty and uncertainty in planning for action and reflection on action
• services that improve how we apply certainty in action, how we work with uncertainty in action, and the skills of each person to work with these

We’ll need to identify each of these items, for each of the respective ‘horizontal’ and ‘vertical’ contexts; and wherever there are gaps in the needed support, identify what needs to be done to create and embed the respective items.

We also need to be aware of and act on some really nasty booby-traps that, if we’re not careful, can damage or even destroy the entire enterprise. Dysfunctional management-structures and misapplied Taylorist ideas are well-known examples of these: the real problem there is that the illusion of ‘control’ is so comforting to so many that these muddle-headed mistakes keep on coming back to bite us time and time again, like the proverbial ‘bad penny’.

Another serious danger that’s a bit more subtle can arise from those seemingly-relentless demands to do more and more, faster and faster. Part of this is that the sheer pressure to produce can cause a disconnect between strategy and tactics and even between tactics and operations: when everything has to happen now, there’s no time to think about what’s being done, or why. Not a good idea…

But a corollary of that is that if there’s no time to think, there’s also no time to develop skills – a point which again is made clear in that cross-map between SCAN and the variability-curve above. All too often we’ll come across an organisation that in essence consists of Masters and Robots (such as machines or IT-systems, or ‘crowdsource’ structure such as Mechanical Turk which in effect treat real-people as Robots), with nothing in between – perhaps a few Trainees to do the grunt-work, but that’s about it.

There’s little question that this can be highly profitable in the short term. Yet it’s a model that, almost by definition, cannot and does not scale – hence the constant complaints we see about ‘skills shortages’ and the like – and why so many startups seem to crash-and-burn so soon after their first flush of sweet success. And if there’s no means within the organisation’s architecture to develop those skills, there’s also no way to learn the contextual information needed to create the next generation of Masters – see the post ’Where have all the good skills gone?‘. Ignoring the skills-development issues may seem profitable at first, but it’s actually a guaranteed path to commercial suicide. Once again, You Have Been Warned?

Anyway, enough for now: more on this and other related themes in the final post in the series.

Any comments or questions so far, anyone?

This is Part 2 of this exploration: the first part is in the post ‘Decision-making – linking intent and action [1]‘. (Once again, please note that this is ‘work-in-progress’, so expect rough-edges and, uh, partly-baked ideas in various places?)

What we ended up with the previous post is that we what we do want is strong ‘horizontal’ connections across the modalities at the same time-distance to action, and strong ‘vertical’ connections across the time-scales at the same modality:

What we usually don’t want – unless intentionally, and with considerable extra care – is ‘diagonal’ connections across both timescale and modality in the same link:

The key point for architecture is that at the moment of action, no-one has time to think. Hence everything that we build in the architecture to support real-time action also needs to support the right balance between rules and freeform, belief and faith, in line with what happens in the real-world context.

It needs to ensure that we have the right sets of rules for action when rules do apply, and the right experience such that the fallback into faith is as effective as possible whenever the rules don’t apply.

What this implies is that, within the architecture, we’ll need to include:

• services to support each sensemaking/decision-making ‘domain’ within the frame
• services to support the ‘vertical’ and ‘horizontal’ paths within the frame
• governance (and perhaps also services) to dissuade following ‘diagonal’ paths within the frame

It also implies the need for a radical rethink of ‘command and control’ as a management-metaphor, which is where we finished in the previous post. What we’ll turn to here is the other items in that list immediately above.

Before we start, though, one important point to note: all of this is recursive. For sanity’s sake, I’ll need to keep things as Simple as possible here, using bullet-point lists and the like: but in reality all of it is also Complicated, Ambiguous and None-of-the-above – and each of those aspects likewise has components that are simple, not-so-simple and so on. It’s clear-cut and simple, and it’s blurry and messy – all of it recursive, ‘self-similar’ and different, all at the same time. Which gets more than a bit complicated or complex or even chaotic if we try to describe it all in one go…

So for now I’ll take the easy way out: I’ll aim for just a brief-as-I-can-make-it summary, and go into more detail where necessary in later posts. Or you can ask for clarification in comments here: it’s up to you. Point is that, of necessity, this is only scratching the surface: I’m well aware that it ain’t as Simple as I may make it seem, and I’ll trust that you’re aware of that too.

On services to support each domain:

For this section we’ll explore both sensemaking (left) and decision-making (right) together:

In both cases, the domains here split into two distinct sets, ‘horizontally’ either side of the Inverse Einstein test:

• on the left-side (‘order‘), our sensemaking and decision-making tactics (Simple / Complicated, Belief / Assertion) assume that things are predictable – and hence that doing the same thing should lead to the same result
• on the right-side (‘unorder‘), our sensemaking and decision-making tactics (Ambiguous / Not-known, Use / Faith) assume that things may not be predictable – and hence that doing the same thing may lead to different results, or achieving the same results may require doing different things

The vertical distinctions between the domains are often rather more subtle, but it’s crucial that our architecture does provide support right down to the exact moment of action. We need to make a point of this, because there’s an all too common tendency to assume that what works well distant-from-action – Complicated analysis and Complex experimentation, for example – will also work well at the point of action. Yet as the old joke warns us:

In theory there’s no difference between theory and practice. In practice, there is.

‘Distant-from-action’ and real-time action are related, yet qualitatively different, in much the same way as Newtonian physics differs from quantum-physics. Hence these pairs of domains in the ‘vertical’ dimension as well.

So: order-domains:

What support do you have for Simple sensemaking: ordered, ‘controlled’, at real-time? What kinds of sensemaking are needed within the work at or close to the exact moment of action?

• examples: checklists, comparison-charts, mechanical sensors, real-time signals

What support do you have for Complicated sensemaking: ordered, ‘controlled’, predictable, but some distance away from real-time – either before the event as preparation, or after it, to make sense of what happened? What different types of support do you need for different ‘distances’ from real-time, from seconds to minutes to hours to days to months to years to decades and beyond?

• examples: analytics, dashboards, computational filters, aggregation

Going back the other way, from sensemaking to decision-making:

What support do you have for Assertion-based decision-making: decisions that assume the existence of order, ‘control’, predictability, yet also are some distance from – usually prior to – the moment of action? What different types of support are needed over the different timescales that we might describe as strategic, tactical and operational?

• examples: algorithms, hard-systems theory, computation or business-rules IT-systems

What support do you have for Belief-based decision-making: real-time decisions based on certainty, on rules, on assumed predictability? In what ways does this decision-making differ when there’s no time to think, no separation between decision and action?

• examples: rule-sets, rote-learning, step-by-step checklists and work-instructions, physical machines, real-time IT

And: unorder-domains:

What support do you have for Ambiguous sensemaking-contexts: some distance from the action, yet still known-uncertain? What different types of support do you need before and after action, and for different ‘distances’ from real-time?

• examples: experimentation, pattern-matching, statistics, trend-analysis, futures techniques, crowdsourcing

What support do you have for None-of-the-above sensemaking-contexts: right at the moment of action, yet inherently uncertain in some or all aspects? What kinds of sensemaking need to take place here?

• examples: listening, ‘flow‘, managing panic, social structures for ‘safe to fail’

(Note that most of that last set of examples would address not so much the sensemaking itself, but providing appropriate conditions for real-time sensemaking in inherent-uncertainty.)

From sensemaking to decision-making:

What support do you have for Use-based decision-making: decisions that are some distance from the action, yet do not assume certainty or predictability? What different types of support are needed over the various different timescales of distance-from-action?

• examples: patterns, guidelines and values, soft-systems theory, prioritisation, probability and necessity (modal-logic), social methods (from meetings to voting-systems etc)

What support do you have for Faith-based decision-making: decisions that must be made in the heat of the action in the midst of inherent-uncertainty?

• examples: principles (i.e. actionable values), skills and experience, context-design to maximise safe-fail or ‘graceful failure’, trust in ‘that which is greater than self’

(That last item is by far the hardest to describe, but it’s a key reason why I use the term ‘Faith’ here. I suppose this might perhaps be a kind of ‘hive-mind’ effect, but the point is that decisions here will often carry a feeling of ‘it was the right thing to do’, an ‘intuitive’ decision that aligns with a broader collective-purpose without conscious knowledge or certainty of how it does so. Deep familiarity with shared principles and values is a known key driver and anchor for this type of decision-alignment – hence their importance as and at the core of an enterprise-architecture.)

Review those lists above: which of those items would you currently include in your enterprise-architecture or process-architecture? Most conventional architectures will describe only the left-side (‘order’) items – yet support for all of these forms of support will need to be in place for the enterprise and its architecture to work well. Note any gaps in the architecture, and, even more important, gaps in support; and then move on.

In the next part of this series we’ll explore the architecture of how we link all these domains together. Any questions for now, though? Over to you, anyway.