• rtolido: @tetradian just show me the non-IT people that invented #entarch and / or #bizarch
• tetradian: @rtolido we’re in a circular-definition here: what you call #entarch or #bizarch is whatever was ‘invented’ by IT-people… //  crucial problem is that IT-people labelled as ‘enterprise architecture’ to something that wasn’t ‘architecture of the enterprise’ // likewise with IT version of ‘business-architecture’, which _isn’t_ ‘architecture of the business’ // once we sort out that mess, it becomes obvious IT-people did not invent it – but until then, we have those circular-definitions… // non-IT-people: Deming, Boyd, Beer, Alexander, even Taylor, for heavens’ sake…
• rtolido: @tetradian All true! Just pointing to the actual roots of both #entarch and #bizarch . Not saying it’s a good thing per se.
• tetradian: what you’re doing at present is propping up _fundamental_ mistake: mislabelling of ‘IT-view of business’ as ‘business-architecture’ // ‘Open Group Cert in IT-view of Business’ is fine – just don’t call it ‘business-architecture’, because it isn’t! // Data Architecture 101: don’t assign names to things that don’t mean the same as what those things actually are!

And that last point is actually a good idea: apply a bit of bog-standard data-architecture practice to this problem. Let’s look at this whole mess from the perspective of Data Architecture 101:

– Step 1: A core principle: all entities shall be assigned meaningful names or terms – i.e. that the assigned name shall correspond to the ‘natural meaning’ of the entity.

– Step 2a: If a term that is currently assigned to an entity does not match the ‘natural meaning’ of the entity but is not in common use, the updated name for the term shall be promulgated, and action taken to dissuade use of the former misleading-term.

– Step 2b: If a term in common use is currently assigned to an entity but does not match the ‘natural meaning’ of that entity, an architectural ‘waiver‘ or ‘dispensation‘ shall be issued, acknowledging the current usage of that term.

– Step 3: If a waiver is issued, the waiver does not mean that the misleading usage is acceptable, but rather that although the fait-accompli is accepted in the present, all efforts must be made to prevent the misleading-term from becoming further entrenched, and every opportunity taken to promulgate a replacement ‘natural-meaning’ term.

This is basic stuff, the kind of routine data-architecture work I was doing twenty years ago and more. Software-coders do it every day; web-designers do it; database-administrators do it. But not, apparently, the people who purport to maintain the formal standards for this kind of work. To use a certain famous phrase, “this does not compute…”

Let’s look at this in a bit more detail.

First, that principle from Step 1, the notion of a ‘natural meaning’. A term or entity can of course be assigned any name at all: sometimes projects and the like are intentionally assigned misleading names, for security purposes or because they’re being used only as ‘working title’ or suchlike. Sometimes such names do stick, misleading or not: ‘tank’ is a classic example. But in general – especially in a data-architecture or in any part of an enterprise-architecture – an entity should be assigned a name that aligns with its use and function: for architectural purposes it doesn’t help anyone if we decide to use the label ‘Glue Pot’ for a delivery-truck, for example, or ‘Salmonella Breeding Station’ as the label for the cafeteria business-unit. In general, it’s a lot more helpful if we call a spade a spade, and so on.

[We can take this a bit further, perhaps - hence the old adage that "An Englishman calls a spade a spade, but an Australian calls it a bl**dy shovel"... ]

Hence the notion of ‘natural meaning’, that in order to minimise the potential for confusion, things should be named according to what they are or what they do.

And a simple test for ‘natural meaning’ is inversion of the term: if the inversion gives the same meaning as the assigned term, it’s more probable that, overall, the term won’t cause confusion. (There’s a proper grammatical-term for this inversion, but I’ve forgotten it: someone remind me, perhaps?) Take ‘data architecture’, for example: the inversion is ‘the architecture of data’, which in both cases is what actually happens in the practice of data-architecture – so we can be reasonably comfortable that we have something close to ‘natural-meaning’ there. In practice, ‘data-architecture’ is a term we can trust to make sense.

Likewise ‘security-architecture’, as the architecture of security; or ‘brand-architecture’, as the architecture of the relationships and the like between business brands;  or ‘IT-infrastructure architecture’, as the architecture of the infrastructures of IT-systems. These all make clear sense, whichever way round we put it; and keep the same meaning, whichever round we put it.

But when we try this inversion with the supposedly-’official’ usages of ‘enterprise-architecture’ or ‘business-architecture’, it just doesn’t work:

– enterprise-architecture:

• natural-meaning (from inversion): the architecture of the enterprise (i.e. organisation as a whole, plus extensions into the value-network and overall ecosystem within which it operates)
• common-usage in TOGAF, FEAF etc: the architecture of the IT-systems in use within the organisation, with some reference to the usage of those systems within the organisation’s business

– business-architecture:

• natural-meaning (from inversion): the architecture of the business (or, more specifically, ‘the business of the business’)
• common-usage in TOGAF, FEAF etc: anything not-IT that might impact upon IT, organised and described solely in terms of its actual or potential impact on IT

In both cases the IT-oriented common-usage is a very long way from the natural-meaning of the term – which guarantees confusion as soon as we move outside of the narrow confines of an IT-oriented view. And in both cases that common-usage meaning describes only a very small subset of the scope of the natural-meaning – in other words, wherever the IT-oriented common-usage is dominant, it represents a serious term-hijack that blocks visibility of the remainder of the natural-meaning scope.

Which, in any competent data-architecture, would clearly indicate that have a couple of seriously-invalid term-usages here. Which means we need to do something about it. Which brings us to Step 2.

It’s clear that Step 2a can’t apply here, because both of these invalid terms are very much ‘out there’.

Which means that we move to Step 2b: we issue a waiver.

But we do not forget what a waiver actually means here, and what responsibilities it places on all of us, collectively, in terms of action we must take in future to correct the architectural risk. In particular, it does not mean that we simply throw up our hands in the air and say “oh well, it doesn’t matter” – because clearly it does matter, because equally-clearly that usage of the term will not make sense to anyone outside of the ‘in-group’ cabal. Instead, the waiver says that we must take action to correct the fault – exactly as with any other type of architectural fault.

Which brings us to Step 3. What we actually need in this case is the metaphoric equivalent of a full ‘Cease & Desist’ order, to demand that people not only stop all use of this misleading usage of the terms, but take action to correct all materials in which either of those two misleading usages occur. For example, TOGAF would need to be rewritten from scratch: given the natural-meaning, it wouldn’t be allowed to use the term ‘enterprise-architecture’ just about anywhere in the whole document, and ‘Phase B: Business Architecture’ would either cease to exist, or be reconstructed as a proper multi-domain structure, within which ‘the architecture of the business of the business’ is merely one amongst many other domains that can impact upon IT.

Let’s not beat about the bush here: that is what needs to happen. Anything less represents not only only an architectural risk on a major scale, but an ongoing risk whose impacts increase exponentially with every passing day.

Sadly, Reality Department indicates we’re very unlikely to get this – not least because it would require Open Group, CapGemini, Federal Enterprise Architecture, Gartner, Zachman and all the rest to recall every scrap of their past publications on ‘enterprise’-architecture, and rewrite the whole darn lot. But we need to say, and continue to insist, that this is what needs to happen in future. We do not simply allow them to continue promulgating these (and many other) fundamentally-wrong term-usages in the enterprise-architecture space.

That’s Data Architecture 101, as applied in a perfectly straightforward way to current ‘enterprise’-architecture – what the Americans call ‘eating our own dogfood’.

And if we aren’t willing to do it to our own work, why on earth should anyone else trust us to do it to theirs?

Pretty simple, really.

So, whatcha gonna do about it, folks?

—

One separate but related and very important addendum: I am not knocking TOGAF in itself here, nor anything or anyone else in the IT-architecture space. IT-architecture is extremely important, and Open Group and others have been doing sterling work in that space for many years. To my mind, no-one should doubt this, and I’m very happy to sing their praises on that part of the work, and invite and encourage others to do likewise.

All that I’m saying is that what TOGAF etc call ‘enterprise-architecture’ should not be called ‘enterprise-architecture’, for the simple reason that it is not ‘the architecture of the enterprise’.

Likewise the somewhat jumbled collection of bits-and-pieces that TOGAF and its ilk call ‘business-architecture’ should not be called ‘business-architecture’, for the simple reason that it is not ‘the architecture of the business’.

[The latter point should be obvious when we consider that TOGAF's 'business-architecture' assumes that the entirety of the non- IT executive - in other words, the CEO, CFO, COO, CMO, CHO and any non-IT CTO, and all of their respective domains - can all meaningfully be lumped together as 'the business', with only IT needing aany differentiation from the rest. Anyone who's had any dealings at executive-level will know that it's, uh, not quite as simple as that? :wry-grin: ]

Best leave it there for now, I guess. Over to you?

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?

This extends the previous posts on SCAN sensemaking and real-time decision-making, ‘Belief and faith at the point of action‘ and ‘Decision-making – belief, fact, theory and practice‘, this time to explore the linkage – or lack of it – between ‘considered’ decision-making and real-time decision-making.

[As before, most of this is 'work-in-progress', so be gentle with it, okay? It should be usable as-is, but do expect odd gaps, rough-edges and wobbly-bits in various places, and please give constructive feedback where you can. Thanks!]

We started from the SCAN sensemaking-frame:

And reviewed it from a perspective of decision-making rather than sensemaking:

It’s actually the same frame, so the two axes are the same in both views:

• a ‘horizontal’ axis of modality of sensemaking and decision-making, from simple true/false on the left, to infinite-possibility on the right
• a ‘vertical’ axis of time-to-decision or time-to-action, stretching from a real-time ‘now!‘ to a potentially-infinite future (and some symmetry with time-from-decision etc, into the past)

The vertical-axis is essentially continuous, but the horizontal-axis has a distinct phase-shift where the modality of decision changes from a simple-true/false [0..1] to an open n-ary [0..n] choice. To the ‘left’ of this point, the apocryphal Einstein dictum applies: doing the same thing should lead to – or is believed to lead to – the same results; whereas to the ‘right’ of that point, doing the same thing may lead to different results, or doing different things may lead to the same results.

On the left-side, there is what purports to be ‘objective certainty’; on the right-side, there is, by definition, some degree of inherent-uncertainty, always somewhat context-specific, and often somewhat personal and subjective. A conventional ‘control’-based concept of the world assumes that everything can somehow be forced onto the left-side of the frame; Reality Department and real-world practice indicates that such concepts of ‘control’ are still wishful-thinking at best, and that alternate decision-strategies must be available, dependent on context.

Hence one of the key tasks of an enterprise-architecture is to ensure that all required decision-methods are supported, and also ensure that appropriate methods are applied to each context.

The previous post, ‘Decision-making – fact, belief, theory and practice’, mainly looked the ‘horizontal’ dimension of this frame; here we’ll explore the impacts of the ‘vertical’ dimension – specifically, the separation between intent and action.

Two parallel paths

We have a plan. An intent. We’re sure we’ll know what to do when the time comes. And yet, to paraphrase von Clausewitz, no plan survives first contact with Reality Department. What we intend doesn’t happen the way we’d planned. (Or perhaps, even stranger, we were equally sure that we wouldn’t know what to do, and yet we discover that we did know what to do – but have no idea how.)

In short, there’s a difference between intentions and expectations beforehand, and what actually happens in real-time action. And we’d like to find some way to close that gap, and create better results overall – whatever those intended results may be.

That’s where continuous-improvement or continuous-reassessment tools come into the picture – techniques such as PDCA and OODA, for example. Likewise the US Army’s After Action Review, four questions that cross-link with the PDCA cycle:

• “What was supposed to happen?” – to answer that, we need some grasp of Plan or intent
• “What actually happened?” – to answer that, we need to be able to observe what we Do and did
• “What was the source of the difference?” – to answer that, we need to be able analyse, assess, Check and compare
• “What do we need to do different next time?” – to answer that, we need to find the courage to face up to change, and to Act to align our capabilities to align better with that actual or needed change

All of these review/reassess processes cycle through the ‘vertical’ dimension, always returning to real-time action, yet catching a variously-brief breath away from the action to create space for reflection and change. There’s often a lot of recursion in this, of cycles-within-cycles – as is particularly clear in OODA – yet in essence it always depends on availability of some time away from the action. If the only time allowed is the ‘now!‘, that also blocks access to any means to adapt to changes in context – and that’s an all-but-guaranteed recipe for decision-disaster…

So to make it work – to create effectiveness within the enterprise – we’ll usually need a lot of vertical movement in SCAN terms. Yet as we saw in the post ‘Belief and faith at the point of action‘, there’s usually also a lot of to-and-fro across the horizontal direction, between closed belief and open faith. And between those two different movements – cyclical and recursive in one direction, a more context-driven back-and-forth in the other – this can get real confusing real fast if we’re not real careful: mixing up the different modes usually leads to unintended outcomes.

Yet the Inverse-Einstein test – that horizontal distinction between true/false versus modal n-ary decision-making – runs right the way through the frame, giving us something that we can use as an anchor to keep the decision-making and capability-development more stable. That anchor gives us a means to keep the moves separate:

• at real-time and at any given distance-from-action, move back-and-forth horizontally across the decision-modality, to identify or apply appropriate decision-rules
• review-processes apply vertically, at a given level of decision-modality – which often also aligns in practice with a given skill-level

So the Inverse-Einstein test gives us two distinct parallel paths in the ‘vertical’ direction, for review and capability-development: one whose core focus is on ‘truth‘, based in true/false logic; the other on usefulness, or ‘value’ in a subjective sense, based on a fully-modal decision-logic. In effect, that’s CP Snow’s ‘Two Cultures‘:

• the sciences emphasise certainty, linking Simple to Complicated, Assertion to Belief
• the humanities emphasise personal-experience and trust, linking Not-known to Ambiguous, Use to Faith

In reality, of course, they do connect horizontally with each other – technology being the obvious example. But the connection only works well when it’s at the same time-level, the same distance-from-action.

What we don’t want – what we need to avoid – are unintended ‘diagonal’ moves across the frame. Ambiguous ideas will confuse and fail as Simple rules, for example, whilst Complicated assertions applied as certain ‘truth’ in the Not-known at real-time are rarely a good idea:

• markwfoden: RT @webisteme : Simple rules lead to complex behavior. Complicated rules lead to stupid behavior

In short, what we do want is this:

And what we don’t want is this:

The next question, of course, is how we support all of that in our enterprise-architectures.

Implications for enterprise-architecture

Probably the key point for architecture is this: at the moment of action, no-one has time to think. And yet we still have to do the right things, and do them right, without being distracted by the need to think.

Things have to work according to a combination of very simple, immediately-accessible, no-thinking-required rules, and free-form trust and faith, a letting-go into the ‘flow‘ of the moment. In practice, that’s what we most need our architecture to support: or, to put it another way round, everything else exists to support what happens in that real-time action.

Everything we build in the architecture 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.

The key role for an organisation is to help make ‘the right things happen right’, in accordance with the needs of the extended-enterprise that’s shared with that organisation’s customers, clients, suppliers, partners and other stakeholders. The organisation aligns itself with the enterprise-story, and brings its resources and capabilities to bear on some selected subset of that enterprise’s problems, desires and needs. Hence, in turn, the role of the enterprise-architecture and domain-architectures for that organisation is to provide appropriate support to identify, track, design and change those ‘response-abilities’ of the organisation.

All of that should be straightforward enough, I hope. Yet what it 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

- part of which, in turn, requires:

• a radical rethink of ‘command and control’ – especially its (mis)use as a management metaphor

Deal with the last point first, perhaps: rethinking command and control. As described in the post on insuperordination, we’re still often stuck with a legacy management-model that is grossly inappropriate for most current business-needs, and perhaps always was. In conflating genuinely-useful for ‘tree’-type service-oriented aggregation-structures with largely mythical notions of hierarchy and importance, we’ve ended up with management-structures that assign ‘rights of command-and-control’ over ‘subordinates’, regardless of whether the ‘superiors’ actually have the competence and knowledge to make the required decisions – which, in many of the highly-volatile business-contexts of today, they generally don’t. The result, in all too many cases, is a management-mess: the near-total antithesis of efficiency, effectiveness or relevance.

In short, far from being the ‘solution’ that it purports to be, Taylorist-style hierarchies of one-way ‘command and control’ from ‘owners’ to ‘managers’ to ‘workers’ are one of the most serious sources of problems in enterprise-architectures. The way forward, architecturally speaking, is to rethink the nature and role of ‘command and control’, and to separate it from those redundant management-myths.

Perhaps surprisingly – or perhaps not – some of the most active proponents of such a rethink are the US military: in particular, the work of David Alberts and others at the (US) Dept of Defense Command & Control Research Program. To be blunt, they’re literally decades ahead of where most business-organisations are today: see, for example, ‘Command Arrangements for Peace Operations‘ (1993) [PDF] or ‘Understanding Command and Control‘ (2006) [PDF]. (The mini-book ‘Power to the Edge‘ is rather better-known outside Defense circles, and is a must-read for anyone involved in organisation-architectures or enterprise-architectures.)

[Quick note: for enterprise-architects and others, I would strongly recommend any of the work of Alberts' and his team, such as those books above and their most recent book, 'The Agility Advantage' [PDF]. For managers and other business-folk, perhaps think of this as Sun Tzu’s The Art of War, brought up to date? – and just as important, too.]

In essence, the classic hierarchical model assumes that command and control are essentially the same: a command from the ‘superior’ is expressed as orders that control the actions and results of the ‘subordinates’. Alberts’ work indicates that command and control are radically different – in particular, that the concept of ‘control’ only makes sense for things that can be controlled via simple true/false logic, such as machines. For anything else – including real people – the closest that we can have to ‘control’ is ‘commander’s intent’: a ‘command’ that explicitly acknowledges the existence of inherent-uncertainty and, preferably, the degree or extent of that uncertainty. In short:

• ‘control’ applies primarily to decision-making on the left-side of the SCAN frame (Assertion and Belief)
• ‘command’ applies primarily to decision-making on the right-side of the SCAN frame (Use and Faith)

It’s perhaps useful to compare this with the Cynefin framework, especially at real-time. On the left-side or ‘control’-oriented side of SCAN (the equivalent of Cynefin’s ‘Simple’-domain), the Cynefin dictum of ‘sense > categorise > respond’ does make practical sense: whatever is sensed is matched against predefined categories, which then elicits responses in terms of that structure of ‘control’. Yet on the right-side of SCAN at real-time (equivalent to Cynefin’s ‘Chaotic’-domain), the Cynefin dictum of ‘act > sense > respond’ makes little to no sense at all: in effect, it assumes the absence of any guiding ‘commander’s intent’ or equivalent – which could indeed lead to the wrong kind of chaos.

[Cynefin works well enough at a good distance-from-action, but in this sense can be actively misleading relative to any real-time context. Yet real-time is literally where the action is. It's a problem...]

This again is where the distinction between ‘organisation’ and ‘enterprise’ is useful. An organisation is bounded by rules, roles and responsibilities, which does allow for the possibility of something that resembles ‘command = control’, though only within the scope of that organisation. Yet once we move beyond that scope, or have to work with partners and other stakeholders who are beyond the remit of the organisation’s rules, and may well conflict with them (as Alberts describes in ‘Command Arrangements for Peace Operations’), we are then in a context which is literally ‘beyond control’ – and we need a form of ‘command’ that does not assume indisputable equivalence with ‘control’. For those purposes – in fact for anything on the right-side of the SCAN frame – we need to move to a form of command based more on the shared-enterprise, bounded by shared (or at least agreed) vision, values and commitments.

Hence enterprise-architecture, rather than solely organisation-architecture – and rethinking ‘command and control’ to match that broader scope.

(I’ll split this here and tackle the remainder in another post. Any comments so far, though?)

I’ve given it a temporary home on my Sidewise server:

• http://ea.sidewise.biz

No doubt it should have a proper domain of its own, but that’ll do for now to get us started.

[By the way, this is another follow-up to my post 'Helping others make sense of my work' - the need for a wiki was a suggestion that came up several times in the comments there.]

It’s a fairly straightforward wiki, based on the WikkaWiki framework – probably the cleanest and simplest wiki-framework I’ve come across. (I’ve struggled with many such frameworks over the years, of which Wikipedia is almost the worst…) Like all wikis, though, it does have its own quirks, hence some quick comments:

– Anyone can read, write or comment. (That’s the default: there’s actually a full access-control system for read, write and comment, all the way down to individual page-level, but that’d take too long to explain here.)

– However, to write, comment or edit, you’ll need to register a user-account. (There’s no charge for this, of course, and should be no privacy-implications: it’s just to stop spam-bots using the site.) There’s a quick summary on how to do this on the wiki home-page.

– One minor ‘gotcha’ is that user-names need to be in wiki-format – what’s known as ‘CamelCase’, beginning with a capital-letter and with at least one additional capital-letter after the start. For example, my user-name is ‘TomG’; you might make yours ‘FredBloggs’ or VikusVdM’.

– Editing is straightforward: click the ‘Edit’ link on the left side of the page-footer, or double-click on the page itself. The ‘Store’ (save) and ‘Preview’ buttons are at the lower-left when you’re editing.

– Formatting is a lot simpler than most wikis: in many cases it’s two repeated-characters. See the ‘Wiki formatting guide’ that’s linked from the home-page. Links are straightforward: ‘[[', then the page wikiname (internal link) or URL (external link), then a space as separator, the link-text, and ']]’.

– Usefully, a page can include a FreeMind-format mindmap: paste the FreeMind XML into the edit-space as the page-content. Read-only, unfortunately, but it’s an easy way to share mindmaps.

– Upload of images and other files is a bit more difficult, and at present only administrators can do it. I’ll hack the code as soon as I can, to allow a broader range of users to upload, but in the meantime, if you want to upload a file, send it to me and I’ll upload it for you.

I’ve put up some initial content to get started – a few dozen definitions, a couple of articles, and a whole load of links to other posts elsewhere – and I’ll continue putting more material up there over the next few days and weeks. But the rest is up to you, really: it’s everyone’s site, not just mine.

Anyway, it’s there, and usable: over to you?

This extends the previous post on real-time decision-making, ‘Belief and faith at the point of action‘, to crosslink with the earlier ideas on SCAN and sensemaking, and especially about where there is more time available to review and reflect on action.

[A gentle warning and polite request: much of this is still 'work in progress', so do beware the rough edges and knobbly bits, and use it with some caution; and whilst I do need critique on this, please don't be too quick to kick down the scaffolding that's holding it all together. Fair enough?]

The previous post was about how options for sensemaking become more constrained as we approach real-time. Right at the point of action, the options reduce to either a Simple interpretation in terms of of true/false categories, versus a Not-simple interpretation based on a modal-logic of possibility and necessity, which is much harder to explain or even to describe to anyone else. In SCAN we’d depict that compression as follows:

In much the same way, decision-making becomes compressed down to Simple belief versus Not-simple faith – neither of which are actually explainable, and both of which, at the root, are primarily emotional rather than ‘rational’:

In both sensemaking and decision-making, the crucial distinction – indicated in SCAN by where the red-line time-axis crosses the green-line axis of decision-modality – is what I’ve termed the ‘Inverse Einstein test’. Einstein is said to have asserted that “insanity is doing the same thing and expecting different results”: but whilst that’s true in a simple rule-based world, it’s not true – or not necessarily true, anyway – in a more complex world where many things are context-specific or even inherently unique.

So our ‘horizontal’ test is this: if doing the same thing leads to the same results – or is believed to lead to the same results – then it’s a Simple decision; if doing the same thing leads to different results, or if we need to do different things to get the same results, it’s Not-simple.

[Yes, I do know that that's a Simple true/false distinction across a spectrum that in reality is fully modal. If you want to apply the appropriate recursion here, please feel free to do so: I thought it wisest here to keep it as simple as possible, because this can get complicated real fast, and unless we're careful to keep the complexities at bay we could end up with a right old chaos of confusion. Which is, yes, yet another recursion... Hence best to keep it simple for now, as best we can, acknowledge that much of it isn't Simple, and allow the recursions to come back in later when there's a bit more space to work with it.]

The crucial point about real-time is that there’s no time available for a distinct sensemaking-stage: decision links directly to action, and vice-versa. (That’s why it’s called ‘decision’: the same linguistic roots as ‘incision’, it’s literally ‘cutting away’, ‘cutting apart’, the cutting-edge for action in the ‘now’.)

For sensemaking to take place, there must be a gap in time between one decision to the next. The key to John Boyd’s ‘Observe, Orient, Decide, Act’ (OODA) loop – which, importantly, is also not a loop as such – is that it still allows distinct sensemaking (‘Orientation’) to take place, but keeps it as close to real-time as possible: that’s what’s meant by ‘getting inside the opponent’s OODA loop’.

As time-available – the red-line ‘vertical’-axis in SCAN – extends outward either side of real-time, the OODA-’loop’ can become recursive, and thence, given enough time, simplified-out to a Deming-style ‘Plan, Do, Check, Act’ (PDCA) continuous-review cycle, such as is also implied in the US Army’s ‘After Action Review‘:

• “What was supposed to happen?” – what was our Plan?
• “What actually happened?” – what did we Do?
• “What was the source of the difference?” – what do we need to Check?
• “What do we need to do different next time?” – about what do we need to Act?

As I’ve described in other posts, sensemaking-choices tend to split as described in SCAN: there’s a ‘bump’ on the path, indicated by the jump between simple true/false logic versus fully-modal logics of ‘possibility and necessity’ on the ‘horizontal’ axis, contrasted with a much smoother spectrum of choices as available-time extends in the ‘vertical’-axis. Although the ‘vertical’ boundaries are less clear-cut than the ‘horizontal’ ones, this gives us the four SCAN quadrants – Simple, Complicated, Ambiguous, Not-Known:

Those distinctions determine the appropriate tactics for sensemaking, as described in those earlier posts.

Decision-making seems to follow a similar, closely-related pattern – though that’s the part I’m having trouble pinning down right now.

[Boyd's OODA is in part another attempt to pin down the same relationships; likewise Snowden's Cynefin, if rather less so. Jung's frame of 'psychological types' is probably a closer fit than Cynefin for this: I've used a generic decision-types adaptation of it for some decades now, though it's still not quite right. Hence this exploration here.]

So again, it’s ‘work-in-progress’, but this is where I’ve come to at present:

It’s a decision-making frame based on the same horizontal (decision-modality) and vertical (time-available) axes as in SCAN, and hence the same sort-of-quadrants but with a decision-oriented re-labelling: Belief (Simple), Assertion (Complicated), Use (Ambiguous) and Faith (Not-known).

On the left-side of the Inverse-Einstein test, the mechanism that links Assertion and Belief is a drive for certainty, for ‘control’. On the right-side, linking Use or ‘usefulness’ with the real-time openness of Faith, is more a focus on experience, underpinned by a deeper kind of trust – a trust which is often conspicuously absent in any concept of ‘control’.

[For this post I'll focus more on what happens across the horizontal-axis, the relationships between theory and practice, or 'truth' versus 'usefulness'. I'll explore more closely the interactions along the vertical-axis - between what we plan to do versus what we actually do - in a following post.]

In terms of decision-making tactics:

• on the left-side, theory takes precedence over practice – or, in some contexts, ideology rules, which is much the same
• on the right-side, practice takes precedence over theory

In essence, this is CP Snow’s classic ‘The Two Cultures‘, the sciences (left-side) and the arts (right-side). Notice, though, that technology sits on the right, not the left: it uses theory, but that isn’t its actual base – hence the very real dangers in the often-misleading term ‘applied science’.

Bridging the gap, from left to right, is praxis,”the process by which a theory, lesson, or skill is enacted, practised, embodied, or realized”; and from right to left, is pragmatics, “a process where theory is extracted from practice”. As enterprise-architects would be all too aware, the latter always starts from pragma, from “what is expedient rather than technically ideal”: and it usually includes the joys of ‘realpolitik’, of carefully filtering reality to fit in with other people’s prepackaged assumptions…

That boundary denoted by the Inverse Einstein Test is all too real: whether the beliefs in question are ‘scientific’, religious, political or whatever, the ‘need’ for certainty will often trigger huge resistance against anything that doesn’t fit its assumptions. For example, there’s a very close mapping between this frame and the classic scientific-discovery sequence of idea > hypothesis > theory > law, which align with Faith, Use, Assertion and Belief respectively.

In real scientific practice, it’s not a linear sequence, there’s a lot of back-and-forth between each of the steps. And in principle, it should be a continuous-improvement cycle, a broader-scope form of PDCA. But as Thomas Kuhn and many others have documented, that same ‘need’ for certainty often places a near-absolute barrier between supposed ‘scientific law’ and any new ideas – in other words, between Belief and Faith – that brings that cycle to a sudden halt, sometimes for years, decades or even centuries. All too often, in practice, if we take the real-time ‘short-cut’ from Belief to Faith, we will be forcibly forbidden to return along the same path: instead, we’re forced to go ‘the long way round’, via Use and Assertion (hypothesis and theory) – which we may not have time to do. Which is a very real problem. And one that applies as much in enterprise-architecture as in any other field – as we’ve seen with the inane IT-centrism that has dominated the discipline for far too long.

It gets complicated…

What I’ve been seeing, as I’ve explored this frame, is a whole stream of often-subtle misunderstandings and ‘gotchas’ that I’ve noticed time and again in practice in enterprise-architecture and elsewhere. These seem to be where many unnecessary complications and confusions arise – so it’s worth noting them here.

For example, fact arises from experience: its basis is on the right-side of this frame – not the left. What’s on the left-side often purports to be fact: yet it’s not fact as such, but interpretation of fact – a very important difference. The left-side operates on information, an interpretation of raw-data – but it often has no means to identify the source or validity of that information, or its method of interpreting it. (This is the same inherent problem whereby a logic is incapable of assessing the validity of its own assumptions: by definition, it must call on something outside of itself to test those premises.) So on the left-side, there’s actually no difference between ‘real’ and ‘imaginary’ – which can lead to all manner of unpleasant problems if the left-side is allowed to over-dominate in any real-world context…

Importantly, there’s no real difference here between ‘objective’ versus ‘subjective’: that distinction is actually another dimension that’s somewhat orthogonal to this plane. What I feel, or sense, is subjective, but it’s still a fact; whereas how I interpret that feeling or sensation is not a fact – it’s an interpretation. Telling someone that they should or shouldn’t feel something is just plain daft: the feeling itself is a fact – something about which we don’t actually have any choice – whereas the ‘should’ is an interpretation arbitrarily imposed by someone else.

[What we do in response to a feeling is a choice - literally, a 'response-ability' - and is something that can be guided by 'shoulds' and the like: but not the feelings themselves. That's a very important distinction which, sadly, surprisingly few people seem to understand...]

There is a specific sense in which subjective versus objective aligns somewhat with the ‘less-time’ versus ‘more-time’ on the SCAN vertical-axis. More-time means more time available for experimentation and analysis – and that can allow us to identify what’s shared (‘objective fact’) across many people’s experience, versus experiences that are more specific and personal (‘subjective fact’).

But there seems instead to be a tendency to conflate the objective/subjective distinction with the SCAN horizontal-axis – objective-fact as ‘truth’ on the left-side, subjective-fact as ‘not-truth’ on the right-side. There are ways in which that conflation can work – it’s at the core of the Jungian frame, for example – but we need to be careful about it. Using that conflation to dismiss all subjective-fact as ‘irrelevant’ – as the classic ‘command and control’ models would do – not only makes no sense at all, but is extremely unwise in real-world practice…

There also several other key distinctions across either side of the Inverse-Einstein test:

– ‘science’ versus technology, which also parallels ideology versus practice: on the left-side, there’s an assertion that something is ‘true’, whereas on the right-side we proceed as-if it’s true – which is not the same at all.

– organisation versus enterprise: the nature of an organisation is that it’s about left-side themes such as control, beliefs, repeatability and certainty; the nature of an enterprise is that it’s not certain, “a risky venture” and suchlike – with all that that implies.

– structure versus story: most structures within current enterprise architectures will, again, have a left-side focus on providing repeatability and certainty; story and other forms of narrative-knowledge provide an alternate kind of ‘structure’ that holds many of the right-side themes together

– sameness versus uniqueness: another key enterprise-architecture theme, sameness and repeatability is very much a left-side theme, whereas uniqueness is just as much a right-side theme

– ‘best-practice’ versus ‘worst-practice’: the notion of ‘best-practice’ assumes that practice that worked well in one context will be directly applicable to another, the same success repeatable in another; by contrast, maintenance engineers and others who work extensively with unique or near-unique contexts share their learning more through ‘worst-practice’, stories of what didn’t work in a given context. (I think I first heard that one from Dave Snowden? – credit where credit’s due, anyway.)

The trade-offs across each of these dichotomies all have direct implications for the design and structure of any enterprise-architecture.

Implications for enterprise-architecture

Take a look at those dichotomies again: which side do you think is emphasised by current enterprise-architectures?

The obvious answer is that, almost invariably, the left-side is given priority over the right.

However, this has huge consequences for the effectiveness of the overall enterprise, and for the enterprise-architecture that describes it:

• interpretation takes priority over fact: never a good idea…
• theory and ideology takes priority over practice and experience: that’s almost a definition of (misused) Taylorism…
• the need for (spurious) ‘certainty’ and ‘control’ takes priority over trust of anything or anyone: ditto on Taylorism…
• the reliance on true/false decision-methods can render the organisation unable to cope with any form of uniqueness
• the need to force-fit everything into sameness of content – ‘best practice’, IT-centric BPR and the like – fails to grasp the differences of context
• the over-focus on organisation – ‘the letter of the law’ – literally kills off the spirit of enterprise…

Look at most of our existing EA toolsets, too: can you find any toolset that’s actively designed around anything other than true/false logic? Other than in rare model-types such as ORM (Object-Role Modelling), there’s no means to describe modality in relationships – hence, for example, no directly-supported way to describe a usable reference-model that allows for real-world ifs, buts and perhapses.

And whilst every toolset focusses on structure – and most do that very well, too – how many of those toolsets also help us to focus on the counterpart of story? They might support few use-cases, perhaps, but that’s about it: there’s a huge gap in capability there…

What we need, urgently, is a better balance between structure and story, between theory and practice, between organisation and enterprise. And without adequate support in the toolsets, that means that we have to create that balance ourselves.

The crucial point is that this balance is not an ‘either/or’, but a much more modal ‘both/and’:

• theory and experience
• ‘objective’ and ‘subjective’
• ‘science’ and technology
• certainty and trust
• true/false and fully-modal
• organisation and enterprise
• structure and story
• sameness and difference
• ‘sense’ and ‘nonsense‘
• certainty and uncertainty

We will only achieve a real effectiveness in the architecture via a fully-nuanced ‘both/and’ balance across all of these dimensions, and more.

So take a careful look at your own organisation, your own enterprise-architectures and the like: where is it out of balance, in this sense? In SCAN terms, how much does it over-emphasise the left-side at the expense of the right-side? And what can (and must) you do to bring it back into a better balance overall?

Comments/suggestions/experiences on this, anyone?

The first has a working-title of The enterprise as story: the role of narrative in enterprise-architecture. This has been a major theme on this blog for the past couple of years or so: more than 40 posts here on various aspects since ‘The enterprise is the story‘. And as in the post ‘The no-plan Plan: architecture as story‘, it’s one of the five key-themes in my ‘no-plan plan‘ for my current and future work-direction. So it’s something I need to get down on paper, in more direct, usable form.

There’s a definite deadline of end of February for this one, because I’ll need it available in time for my presentation ‘The enterprise is a story: a narrative approach to enterprise-architecture‘ at the Integrated EA conference in London on 6-7 March 2012.

The second has a working-title of The business-anarchist: enterprise-architectures for the edge of chaos. This has perhaps been a less prominent theme on the blog, but it’s turned up quite a few times, such as in the post ‘Analyst, anarchist, architect‘. In essence, it’s about being deliberate and responsible about working with disruption in the business-context, preferably before that disruption is thrust upon us – a concern which is rapidly becoming more and more important almost by the day.

I’ve been nibbling at this one since mid-2009, and even wrote a fair chunk of it at various points last year, but didn’t finish it then, in part because it didn’t feel like the right time. Now, post-Occupy and suchlike, it does feel more like the right time, so I need to get it done. It’ll have to come after The enterprise as story, but with luck and lack-of-distraction it should be ready somewhen in April.

There’s also another enterprise-architecture book I’ve been working on for quite a while now with a colleague in Guatemala, Michael Smith. We don’t have a working-title for this one yet, and it’s rather further away in time – somewhen mid to late next year, probably – but it’s probably worth mentioning at this point. It’ll focus on the Five Elements theme that comes up in quite a few places in my work – for example, the structure of the effectiveness model used in SCORE strategy-assessment and the book Real Enterprise-Architecture, and the core of the market-cycle that’s used in conjunction with Enterprise Canvas.

Will let you know when any of the books become ready and available, but thought I’d keep you up to date with this part of work-in-progress, anyway.

Reality is that those ideas are very much in the ‘work in progress’ stage at the moment, and as yet still quite some way from a form that might make much sense to anyone else. To illustrate, for the past couple of weeks I’ve spent rather too many hours staring at and tweaking of a set of whiteboards that look like this:

In other words, it’s coming together, sort-of, but it’ll take a bit more time yet to clean it up into usable form. Watch This Space, perhaps?

One reason is implied this Tweet by Belgian consultant Patrick Van Renterghem:

itworks: Big discussion now about what happens when cloud vendors go bankrupt or out-of-service. Should [be] in the contract… #BAEA

“Should be in the contract…”: yes, indeed – but what should be in that contract? And why?

Without an enterprise-architecture that covers a broader scope than just the bare IT-transactions, we have no way to know what actually needs to be in that contract – and also in the parts that can’t be covered by contract, and that really do depend on relationships and trust. Which could be a serious problem from a business perspective. Hmm…

I’ve covered a fair bit of the detail of this in other posts here, such as ‘Enterprise-architecture and the Cloud‘. Some people seem to have misunderstood the questions there as somehow being ‘anti-Cloud’, or even ‘anti-IT’: it’s not. It’s about really looking at the whole context – about the whole ‘market-cycle’, about understanding the full implications of a customer-centric view, about maintaining consistency of service across all in-source and out-source relationships, and so on. And we do need to do that: because if we don’t, it can get really expensive.

Yet cloud-outsourcing is only one small example. As enterprise-architects, we also need to be able to extend out to a much broader business-picture, as Steve Denning describes in his Forbes post, ‘Clayton Christensen: How Pursuit of Profits Kills Innovation and the U.S. Economy‘

when a firm calculates the rate of return on a proposal to outsource manufacturing overseas, it typically does not include:

• The cost of the knowledge that is being lost, possibly forever.
• The cost of being unable to innovate in future, because critical knowledge has been lost.
• The consequent cost of its current business being destroyed by competitors emerging who can make a better product at lower cost.
• The missed opportunity of profits that could be made from innovations based on that knowledge that is being lost.

Failure to apply a proper enterprise-scope architecture-assessment of such themes can be more serious than merely expensive: mistakes at that level can easily kill a corporation. In short, it matters.

That kind of in-depth EA assessment might at first seem pernickety and pedantic, especially to those who just want to get moving. But as John Seddon warns, most of the ‘conventional’ methods to save money and effort usually end up costing far, far more: if we do need to cut costs, for example, we need to take more systemic, whole-of-context view in order to find the real places where those costs can be cut back. And the reality is that often they’re not where we’d expect them to be: hence, again, the need for a true enterprise-scope architecture.

Cloud-IT and other forms of outsourcing often look like the quickest, easiest and most practical way to cut costs. But Steve Denning quotes John Maynard Keynes to warn:

Practical men, who believe themselves to be quite exempt from any intellectual influence, are usually the slaves of some defunct economist.

Most often, those ‘defunct economists’ have failed to account for the hidden costs of a context – particularly the real human costs, which can be ignored only at our peril, especially in the longer term. There are good reasons why those ideas became ‘defunct’: but unfortunately, it seems each new generation has to re-learn those reasons time and time again…

In our domains, those forgotten lessons are reflected in IT-centrism and the like, and the over-simplification of otherwise-valuable ideas such as ‘scientific management’ and ‘business process reengineering’, and, now, cloud-based IT-services. A key role of a whole-of-enterprise architecture, here in the context of outsourcing, is to remind us of why those lessons about the real complexities of outsourcing and the like are so important, and what they mean in real-world practice to Keynes’ ‘practical men’.

In short, use enterprise-architecture to help identify the real hidden-costs of outsourcing – so that your business doesn’t get hit by the bill when those hidden-costs come back to bite…

A lot of this is still tentative, very much ‘a work in progress’. Yet what I’ve found myself returning to again and again over the past few days, whilst working on the design and workflows for the SCAN app, is a pairing of two words: belief, and faith.

[Don't worry, I'm not going to go all religious on you. (Well, probably not, anyway. ) This is still the same enterprise-architecture exploration about the context of SCAN, about sensemaking and decision-making at real-time, particularly in what some would term the 'Chaotic domain'.

Minor warning, though: this is written in English, and from the perspective of an Anglo culture. I think (believe? guess?) that what follows is close to generic across all human cultures, but note that you may well need to do some translation here, both linguistic and cultural.]

Where SCAN’s ‘Simple’ and ‘Not-simple’ are about about how to describe sensemaking, belief and faith seem more about decision-making – the actual moment of choice that immediately precedes each moment of action. In other words, decision-making in real-time. And because sensemaking, decision-making and action are all intertwined with each other within real-world practice, belief and faith also map onto the SCAN frame in much the same way as for real-time sensemaking.

[There's also a mapping to the full SCAN, that extends this outward to the scope where there is more time available for review, but I'll describe that in another post.]

In short, belief maps to the known, the certain, the Simple; whilst faith maps to the unknown, the uncertain, the Not-simple:

As in sensemaking, the crucial distinction occurs where the modality of the decision-choice changes from a Simple deontic true/false to a Not-simple true alethic logic of ‘possibility and necessity’:

– over on the left-side, belief provides a straightforward black-or-white choice: true or false, right versus wrong, culturally ‘proper’ versus ‘politically incorrect’;

– over on the right, choices are more blurry, more uncertain, more ‘shades of grey’ – or more colourful, perhaps – and the only guide we have is faith or trust that what we do is right. (Right in its own way, but still ‘right’ in some sense.)

Both of these are actually about the individual, about ‘I’. Which it should be, of course, because that’s all we have at the exact point of action: our own choice, and our own ‘response-ability’.

Belief is fast, and importantly doesn’t demand any personal skill as such: the whole point is that they’re deemed to be ‘true’ for all who enact them, regardless of who or what enacts them. (A belief may be believed to apply only to self – such as ‘nothing goes right for me’ – but is still held as an ‘absolute truth’ in that sense.) This has both advantages and disadvantages, mainly relating to how well the belief does match up to actual reality. Advantages include:

• simple beliefs are useful when the person enacting them has only a limited level of skill and ‘response-ability’ – “just follow the instructions, kid…”
• even for those with skill, simple beliefs are useful as a structured fallback for whenever the faith falters in the context and in one’s own ability – “when all else fails, follow the instructions”
• advising acceptance that some contexts are constrained by ‘laws’ of some kind – particularly the physical-world constraints implied by ‘scientific law’ and the like
• beliefs are also useful as a disciplined means to temper excess enthusiasm – “trust to Allah, but tie the camel first”

A classic example of a structured belief of that last type is the checklist - mapping out essential safety-checks and other ‘known truths’ prior to or during any activity that is inherently uncertain.

The disadvantages of ‘prepackaged’ belief-structures are more complex, and often rather more subtle:

• the usefulness of beliefs ultimately depends on the myth of ‘control’, the myth of predictability and certainty – none of which may be valid in a real-world context
• beliefs themselves can and do act as perceptual filters, potentially rendering invisible essential contrary information from the context
• as guides for choice and action, beliefs can apply inappropriate constraints to action in any given context – following ‘the letter of the law’ rather than ‘the spirit of the law’
• in much the same way, beliefs can be used to evade difficult or challenging choices – for example, ‘morals’ as ‘the lazy-person’s ethics’

Faith is often the only choice-mechanism available whenever the context is inherently uncertain. It also correlates closely to skill – so much so that, in essence, ‘skill’ is a proxy for the real-world reliability of faith in one’s own ability to work with the inherent uncertainties of a given type of real-world context. In other words, skill is what determines whether we really can do what we believe or hope we can do in that kind of context.

Sometimes, though, it isn’t about skill: it’s just about faith, or trust. Every change of belief requires ‘a leap of faith’; innovation or experimentation always requires us to accept that we don’t know what the outcome will be. (That’s very different from belief, where we do expect the outcome to be what we expect.) A modal-logic of possibility and necessity is the only place where ‘the impossible’ first becomes possible – and thence, through skill, becomes probable, then predictable, and eventually something resembling certain, a kind of ‘law’ in its own right. It may end up as a checklist or some other pre-packaged set of beliefs – but it always starts with faith, in the midst of a moment of inherent uncertainty.

As with belief, there are disadvantages to faith too: not least what we might describe as ‘misplaced faith’, where lack of skill – or plain old lack of awareness – leads to inappropriate outcomes. Whether we like them or not, sometimes the constraints of belief do apply – such as in most (though not all) assertions of ‘scientific law’ and the like.

So in practice we need to be able to bounce back and forth along SCAN’s ‘horizontal’ axis of modality. Sometimes we need to hold to a Simple true/false belief; sometimes we need to let go into the Not-simple world of faith and trust. And of course, recursively, there are no set rules about which one should always apply at any given moment – which means that this too is a skill in itself. It’s Complicated, perhaps, or Complex… yet in real-time action we don’t even have time for either of those. All we have is this decision, right here, right now – no time for anything else. Belief that we know what to do; or faith that the results we need will arise from within the chaos itself.

All of which means that, as enterprise-architects, we need to understand how belief and faith work within our organisation and enterprise, and provide structures to support them in real-world practice.

Enterprise-architecture implications

It’s essential to draw a distinction here between the individual and the organisation. Belief and faith are expressed in practice directly by the individual, or indirectly by proxy, such as via the design or operation of a semi-autonomous machine or IT-system. Yet in an organisational context, it’s the collective belief and faith that we want expressed in action – expressed by the individuals on behalf of the organisation, the collective.

In effect, that’s the key role of organisational culture – and despite the wishes of executives and others, it’s not as simple as it looks… For enterprise-architects, it also means that we often have to address aspects of organisation-architecture that are more usually the territory of HR and change-management and the like – which means that we have to tread carefully at times, and engage in some potentially-challenging negotiations. But the payoff is an enterprise-architecture that really works – for everyone.

The organisation’s beliefs-in-action are expressed in definitive statements such as work-instructions, reporting-relationships and business-rules. One of the architectural concerns here is to provide support such that these business-rules and the like are actually implemented in practice, in real-time decision-making.

To make this work, we in effect need each individual to take up those shared-beliefs as if they are their own personal beliefs. This is especially important wherever these rules must normally be followed ‘to the letter’ – such as in regulatory compliance.

It’s crucial to understand, though, that rules cannot be imposed onto individuals from outside, whether by fiat or threat of force. Although as an organisation we can give ourselves the illusion that this has been done, it rarely works in practice: instead, there will usually be a myriad of small ‘failures’, ranging from unconscious errors to covert rebellion, which effectively sabotage the intended functional impact of the rules. (The former will tend to occur more often in collective-oriented cultures, the latter especially so in individual-oriented cultures.)

What does work is to engage people in the rules – the ‘why’ as much as the ‘how’ and ‘what’. To use the terms from Hagel, Brown and Davison’s The Power of Pull, we create that engagement by shifting from ‘push’ to ‘pull’. In an enterprise-architecture, we do this by treating organisational-beliefs in much the same way as for organisational-values. The Enterprise Canvas model describes a generic structure for this purpose:

• create awareness of the rules-structure, its purpose and rationale, and the context for its use
• build capability to apply the rules-structure in real-time practice
• apply the rules-structure in run-time decisions
• verify and validate the usage of the rules-structure
• derive lessons-learned from the (attempted) usage of the rules-structure

Working with HR, change-management, process-management and others, we create what is in effect a PDCA-type learning-loop, to develop, apply and revise the business-rules and other belief-structures for the organisation.

The faith-in-action side of that decision-making modality-spectrum deals with anything that isn’t covered appropriately by business-rules and the like – which is a large part of most real-world organisational contexts. For enterprise-architecture, the two key focus-areas are skills-development, to enhance individual ‘response-ability’; and vision, values and principles, to enhance consistency in decision-making across the collective.

The skills-issue is one that is almost completely missing from most current-enterprise-architectures, especially those of an IT-centric bent. That’s rapidly becoming a lethally-dangerous oversight – see the Sidewise post ‘Where have all the good skills gone?‘ – and one that we need to address, working in conjunction with HR, organisational-development units and suchlike. EA will come into the picture by mapping out skills-requirements and competency-levels needed within enterprise-capabilities; the actual skills-development would usually be out of scope for EA, of course, though overall much of it would follow that generic structure for values as above.

The values-issue is one I’ve been pushing for a very long time as the true core of the enterprise-architecture: for example, it forms the topmost layer of abstraction in Enterprise Canvas, and thence acts as the anchor for the generic structure described above for values-management services. The reason why it’s important is that if the organisation isn’t clear about its values, then what will be used instead – as the drivers for ‘faith’-type decision-making – will be whatever values happen to be around for that individual. Which could be anything at all. Including not just a destructive ‘me-first’, but a really destructive ‘me-only’. In other words, not a good idea… clarity on values matters.

A lot more that could be said on all of that, but I’d probably best leave that for the moment. The only point that does need to be added here is the importance of story – the enterprise as story, the enterprise is the story – as the ‘glue’ that holds all of this together.

Overall, the real point here is this: that at the point of action – and despite whatever we might plan beforehand – decisions seem to be taken primarily on the basis of belief, or of faith or trust. Which means that, architecturally, we need to design for that fact. Not a trivial point, then.

More on this in another post soon, but any comments so far, anyone?

I’ve been tussling with this one for quite a while, most recently culminating with a simple sensemaking framework called SCAN:

The horizontal green-line axis here represents the decision-type, from a simple true/false choice to a not-so-simple modal choice of possibility and necessity; the vertical red-line axis is the amount of time available before must make a choice and take action.

[For more on SCAN and its technical background, see the posts '"Let's do a quick SCAN on this"' and 'Domains and dimensions in SCAN'.

In a sense, though, that red line of 'available-time' goes both sides of the 'now', extending outward both into future plans and past record:

Time and distance and even social-distance all compress down towards the point of decision, the moment of action, the now. That 'now'-moment is the only one that matters: prior to that point, every 'decision' may be nothing more than a vague statement of intent, which may not actually happen in practice - as I know only too well...

At each moment of 'right here, right now', it's always our responsibility - our 'response-ability', our individual and personal ability to respond.

The 'now' is the still-point at the centre of action. Yet it's an active stillness, and there are still choices there in that moment. So what we aim for in this kind of real-time sensemaking is to create just enough space to enhance that 'ability to respond' - enough space to enable appropriate choice for appropriate action.

If we don't create that space for choice, the only 'choices' we have come from habit - which may not be appropriate to to the context - or the various 'hard-wired' reflex-responses, such as 'fight', 'flight' or 'freeze'.

[The other natural-reflex is 'fornicate', but we'd, uh, best leave that out of the conversation for now...? ]

Whilst it’s easy enough to describe what goes on either side of that choice-point, it’s surprisingly hard to describe the choice-point itself without sounding somewhat mystical. Rather like the cosmological moment of the Big Bang, it’s both technically and literally a moment of chaos, within which the ‘normal rules’ break down, and which contains within itself every possibility and every other point.

This is the literal meaning of Pan, by the way – ‘the everything’. If we can’t cope with this infinity of (im)possibility, we’re like to fall into panic. And that’s what leads to those three reflex-responses – each of which rejects the uncertainty in their own distinct way:

• fight: grab at a single possibility and ‘take control’ (whether or not that single chosen option is appropriate to the needs of the context)
• flight: ‘run away’ from the choice (such as to a ‘considered-sensemaking’ framework which cannot work at real-time, and hence leads to some variant of ‘analysis-paralysis’)
• freeze: do nothing and hope that the need for choice will go away (which only works if there’s no actual need for choice or action)

What we need to do instead is stay within the ‘chaos’ for as long as we can, to allow the appropriate choice to emerge from and with the context itself. Describing this as ‘act / sense / respond’ is way too simplistic: it’s more like a real-time dance of choice and action, a transitory yet immensely powerful condition of flow that is often experienced as a kind of ‘no-time’ that is seemingly beyond time.

[People who can hold that space are often described - or derided - as 'eccentric', 'the crazy ones'. Yet 'eccentric' is literally away from the centre - and that's the place where change can happen, because that distance also provides leverage for change. Being seen as 'eccentric' can be difficult at times, but it's certainly important...]

What I’ve been working on over the past few days or so is trying to a detailed mapping of what actually happens in the real-time space, using this specific question of real-time sensemaking as the ‘target problem’ to keep in focus.

[As usual, I've gone back to first-principles to do this, so in effect I've been watching myself at work whilst doing this work. What I've been seeing may not be the way that others do this, of course, but it actually does match up quite well with what's in the rather eclectic mix literature that I happen to know, from Lao Tse's Tao Te Ching to Csíkszentmihalyi's Flow, and from Zen and the Art of Motorcycle Maintenance, to The Art of Scientific Investigation. So no claims to be 'academic' as such, but that isn't the point: I'm a practical toolmaker, not a 'pure' theorist, after all.]

For this, I’ve used the ‘time-compressed’ version of SCAN, in which everything is squeezed down to a real-time choice of tactics, between ‘Simple’ and ‘Not-simple’:

The crucial boundary on this dimension is what I’ve called ‘the Inverse Einstein test’:

• if we do the same thing and get the same results, it’s on the Simple side of the story – so we would attempt to use Simple-side tactics
• if we do the same thing and get different results, it’s on the Not-simple side of the story – so we would need to use tactics from the Not-simple side

In real-time sensemaking we actually swing back and forth between these ‘domains’, using a variety of real-time checks to tell use which side we need to be on at any one moment. They’re different disciplines: but by swinging back-and-forth in a conscious and deliberate way, we maintain an overall discipline at all times.

[First-hand example: doing a formal back-massage. At first, I'll follow the rules, following the standard sequence of moves and work-patterns, using that pattern itself as a focus. At some point it switches into that 'flow-state', and I'll find myself doing something subtly different, applying pressure in a different way, following kind of 'inner instructions' that seem to come through my hands themselves. Then, just as suddenly, the 'flow-state' fades, leaving me feeling a bit lost, like I don't where I am, I don't know what to do. That's when the key-phrase 'Don't Panic!' comes in, and reminds me to go back to 'the rules' - back to the Simple-side - and follow that pattern until the 'flow-state' returns. Which it may not, of course - but at least I'll have done something useful simply by following 'the rules'.]

If I use the tags ‘[S]‘ for Simple-side, and ‘[N]‘ for the Not-simple side, these are some of the points I’ve noticed during this week about that real-time back-and-forth:

– [S] is about following the instructions, following ‘the rules’; [N] is about allowing ‘the answers’ to arise in whatever way they seem to choose.

– [N] is what we do while that ‘inner knowing’ lasts; [S] is what we do when the knowing fades.

– Both sides need calm, and need discipline – including the discipline about how and when to switch back and forth between them.

– [S] has notions of ‘truth’, of ‘control’, of certainty, “I know what to do”; [N] calls for a kind of faith, a lot of trust, perhaps Susan Jeffers‘ “feel the fear and do it anyway” – and often a difficult balance between “do something, don’t just stand there!” and “don’t ‘do something, just stand there…”.

– In a rework of the old slogan “think global, act local”, [S] seems to focus on ‘act local’, whilst [N] seems to allow the broader space of ‘aware global’ – no time to stop and think at real-time, yet use that deep-space of ‘the everything’ to help maintain the big-picture awareness.

– [S] seems to work best with rules or checklists – which is hardly surprising since in essence it thrives on real-time certainties. Some of the rules and checklists I use a lot in real-time sensemaking for enterprise-architecture include:

• allow the uncertainty to be uncertain (i.e. keep gently returning to the Not-simple side)
• don’t try to control – allow ‘the answers’ to arise in their own way
• use the ‘checklist for checklists‘ to create checklists on-the-fly with whatever ideas I’ve gleaned from the Not-simple side
• use quick enquiry-techniques such as ‘Five Whys‘ to push into the Not-simple side for new ideas and information
• use Five-Whys to move up the scale of abstraction towards core-purpose
• use Five-Hows to move down the scale of abstraction towards real-world implementation
• use the R5 set of system-thinking principles – rotation, reciprocation, resonance, recursion, reflexion – to look for factors and patterns in the context
• use the REAL checklist – reliable, efficient, appropriate, elegant – to test for effectiveness themes (sometimes extended to ‘LEARN’ with the addition of ‘integrated’)
• use the tetradian set – physical, virtual/conceptual, relation/emotional, aspirational/spiritual – to review asset-dimensions in a context
• use the Five Elements set – Purpose, People, Preparation, Process, Performance – to assess balance across strategy, tactics and operations (which also aligns with the Tuckman project-lifecycle sequence ‘forming, storming, norming, performing, adjourning’)

– Almost by definition, [N] doesn’t seem to have any clear patterns: the only ‘patterns’ I see myself doing all too often on that side are ones about how to avoid making sense, such as running away to check emails or make yet another cup of tea…

Anyway, that’s it for the moment. It’s just a work in progress, as usual, but make of it what you will.

Comments/suggestions, anyone?