We seem to be iterating steadily towards a full description of what I’ve termed context-space mapping (as a more permanent name than the temporary label ‘tinc‘). For example, there’s been some very useful discussion on the previous post, especially by enterprise-architects Paul Jansen and Sally Bean. Paul Jansen followed this up with another Tweet:

@tetradian May the ‘chaotic approach’ be the key to #tinc? http://bit.ly/amJa1o

In fact this leads to what is probably the fundamental difference between twf and context-space mapping (aka tinc): the role of the Chaotic domain. This particularly applies in terms of the respective views of repeatability within the context.

In the hope of preventing yet more repercussions, I won’t say anything about twf‘s approach at this point, other than to express my opinion that, in the terms of context-space mapping, its focus is primarily on the Complex domain, which in turn leads to an emphasis on contexts that are ‘partly-repeatable’ in highly complex ‘unordered’ ways.

Context-space mapping, however, needs to cover all repeatability-types. As twf‘s proponent indicates, the Simple domain of presumed-repeatability is covered by Taylorism et al.; the Complicated domain of analysed-repeatability by hard-Systems Thinking and the like; and the Complex by twf and so on. But there’s so far been little or nothing to cover the Chaotic domain of ‘barely-repeatable’ events and processes. So in practice it’s likely that that’s where whole-of-scope techniques such as context-space mapping will have the most impact.

The central theme in the Chaotic domain of practice is low- to zero-repeatability: some part(s) of the practice cannot be repeated, either because the conditions have changed – including the awareness and experience of the person doing the work. Conventional ‘scientific-analysis’ approaches (Complicated-domain) rely on repeatability, so they’re actually not all that much use in the Chaotic components of any real-world task – in fact will often be misleading because they provide an illusion of predictability. In a way, the same is true of many Complex-domain techniques: they give us a much more reliable picture of an overall uncertain context, but we can’t reliably apply that in reverse to tell us what to do for a specific ‘market-of-one’, such as a specific medical diagnosis.

Ability to engage appropriately in the Chaotic-domain in this sense is almost a definition of skill. It’s also a key component of almost all knowledge-work – which is why this concern is coming much more to the fore, as knowledge-work becomes an increasingly important part of the overall economy.

At the business-process level, one of the key figures is Sigurd Rinde, whose concept of ‘barely-repeatable processes’ is the focus for his Thingamy business-process-execution software. The whole point of Thingamy is that the processes themselves are made up as they go along, by the people doing the work, expressing and applying their expertise. Underneath this, however, is a consistent Simple structure that records every decision, every artefact, every transfer of responsibility – which makes it possible to create any required reports from the process, including conventional statistical analysis. The result is nicely summarised on Sig’s other website, 30megs.com – so-called from his tag-line “Here’s 30 Megs. Now go run Germany”, which in principle is entirely feasible with this kind of decision-support/decision-tracking software. Sig is not alone in this, of course – for example, Stafford Beer developed something similar that in effect ran the entire economy of Chile for a while, way back in the early 1970s – but Thingamy is probably the best example of a software package available today that is designed for true Chaotic-domain processes.

Context-space mapping is part of what needs to happen before we settle on any technique or tool such as Thingamy. It’s about mapping the options available to us, and the decisions that we make within ‘solution-space’, as part of an overall process of sensemaking in order to arrive at appropriate actions for the context. One of the key points in this is an awareness that we are part of the context, part of the ‘solution’: in the classic Chaotic-domain sense, there is a boundary, and there is no boundary, always in the same moment.

We always start from ‘reality’ – that which in twf is termed the ‘disorder’ domain. (Everything does in fact take place within that domain: any purported subdivisions – such as Simple, Chaotic and suchlike – are sensemaking-abstractions that we place onto that domain, but are not actually ‘real’ as such.) From there, we would move into some kind of recursive OODA loop (Observe/Orient/Decide/Act), where sensemaking itself forms one or more of the earliest iterations. In those terms, context-space mapping would typically proceed as follows:

• Observe: What is ‘the context’ here?
• Orient: How do I make sense of what I’m seeing?
  1. What parts of the context appear to be unique (Chaotic), unordered or ‘wicked-problem’ (Complex), complicated but repeatable (Complicated) or universal (Simple)? Using that categorisation, map out the ‘problem-space’.
  2. Given that categorisation, what cross-maps would be useful for sensemaking?
     Note: There are an infinite number of cross-maps that could be used: some examples shown in this series include:
     • here: repeatability and action-tactics; domains and tetradian asset-dimensions; time versus focus; Jungian domains
     • here: twf tactics and types of practice; timescale versus ‘bindedness’; development of embodied ‘best-practice’
     • here: repeatability and ‘truth’; marketing versus sales; the ‘plan / do / check / act’ cycle
     • here: ISO-9000 quality-model; skill-levels; automated versus manual processes; asset-types; data, information, knowledge, wisdom
     • here: cause/effect relationships; decision-mode, timescale and level of abstraction
     • here: nature of boundaries between domains
     • here: phases of matter
  3. Using the categorisations from the cross-maps, what available tools and techniques are ‘situated’ in what regions of the maps’ ‘solution-space’? What can we learn from this?
• Decide: Given what I have learned from sensemaking, what should be my ‘action-plan’?
  1. Select from the available tools/techniques.
  2. Decide on a plan as to how, why, when, where, by whom, with what, and in what order each of the selected tools or techniques should be used.
• Act:  What am I doing as I am doing, and what do I see as I am doing?
  1. Enact the desired action.
  2. Apply the same overall OODA-loop to the action taken – recursively, where appropriate – for review, further sensemaking, decision and action.
• Repeat as appropriate.

(Some people might suggest that this kind of OODA-loop fits more within a twf-style Complex-domain mode than Chaotic-domain. True, there are important similarities, such as the shared focus on ‘unorder’ versus the Complicated/Simple notion of ‘order’. But the key distinction is that this acts on a single, individual, specific context rather than a Complex-domain collective – and is often also much closer to real-time than most Complex-domain decision-making.)

The above is a start towards how we would use context-space mapping, anyway. I’ll leave it there for now: any constructive comments, ideas and suggestions would be most welcome, as usual – over to you?

Previous posts in this series:

• Complexity, chaos and enterprise-architecture
• More on chaos and Cynefin
• Alternatives to the ‘Cynefin’ term, please?
• Solution-space: beyond Cynefin?
• On meta-methodology
• Using ‘Cynefin-like’ cross-maps
• More ‘Cynefin-like’ cross-maps
• And more ‘Cynefin-like’ cross-maps
• More on meta-methodology
• ‘tinc’ – a Temporary Inconvenience
• Context-space mapping and enterprise-architecture

Related:

• ‘Two Cryptic conversations‘

Unfortunately, as can be seen from his comments to those posts, one person who was definitely not happy about such ideas was the originator of Cynefin, Dave Snowden. So there’s evidently a major problem for us there.

What is clear is that, whether Dave likes it or not, a substantial community already uses Cynefin concepts and Cynefin terminology to describe a kind of meta-methodological ‘solution-space’ within which various methods, methodologies and tactics can be situated, and their respective appropriateness for specific contexts can be assessed. What’s also clear is that, as far as Dave is concerned, we are no longer permitted to use the term ‘Cynefin’ for this ‘framework-that-occupies-much-the-same-conceptual-space-as-Cynefin’: we do need to find an alternative term for this.

In short, to describe that ‘solution-space’, it seems we now need to move beyond Cynefin.

To do that, we need to identify:

• the role and purpose of this ‘not-Cynefin framework’
• how it draws from the published Cynefin framework and/or common usages of that framework
• how it extends and/or differs from the published Cynefin framework
• summarise how this framework would be used in practice

Once we’ve done that, we can perhaps start looking for an appropriate alternative term to describe it.

This is again going to be long, so I’ll stop here for a moment with a ‘Read more…’ link.

(Apologies: some of this will necessarily be somewhat technical at the start, but the examples later on should bring it down to the practical and concrete.)

It’ll be obvious that there’s a real risk of confusion here around how people have used the Cynefin framework, Dave’s now more-explicit intent for how the ‘Cynefin’ term ought to be used, and the somewhat different direction that this specific usage of Cynefin-like concepts needs to go. In the hope that it’ll reduce misunderstandings, I’ll use the following labels:

• CF (‘Cynefin framework’): the basic Cynefin diagram of four domains (currently labelled ‘Simple’, ‘Complicated’, ‘Complex’ and ‘Chaotic’) around a central region of ‘Disorder’
• CT (‘Cynefin/Cognitive-Edge techniques’): a specific set of techniques drawing on formal theory of complex-adaptive-systems and related science, using CF in various ways, but particularly as an illustration to describe both the problem-space and where those techniques should be situated in terms of overall ‘sense-making’
• UF or ‘the framework’ (‘unnamed framework’): a framework that, like CF, uses an intentionally-loose categorisation of four domains and central region to describe an overall ‘solution-space’, but also permits multiple alternative yet related ‘views’ into that overall solution-space

We also need to distinguish between problem-space and solution-space:

• problem-space is the context of the problem and its underlying factors – for example, in CF terms, whether the factors in the problem can be considered to be Simple (i.e. display linear causality), Complicated (e.g. linear causality with feedback loops and delays), Complex (e.g. retrospective causality) or Chaotic (i.e. display no apparent causality)
• solution-space is the context of the proposed solution and its relationship to the underlying factors of the problem-space – for example, in CF terms, whether the solution-method assumes that everything remains the same (Simple), contextual but predictable (Complicated), highly contextual (Complex) or in some part inherently unique (Chaotic)

CF and UF both describe the problem-space and solution-space; CT is in essence a defined set of techniques that can act on any part of the problem-space but centre on the Complex domain in solution-space.

The reason why this distinction is important is that CT goes “from solution to problem” – in other words, much like most other forms of pre-constructed ‘solutions’, it needs only to seek out those problems for which its techniques are appropriate. But enterprise-architecture, knowledge-management and many other disciplines necessarily operate the other way round, “from problem to solution” – the parameters of the problem need to be identified, and then an appropriate solution identified to match those requirements. The comparison between problem-space and solution-space also indicates the probable consequences of any mismatch. Solution-space is largely irrelevant to CT because for the most part it is already situated in solution-space (specifically, certain regions within the Complex-domain): all it needs to do is find appropriate problems in problem-space to match what it can do.

It should be emphasised that, unlike the CF/CT pairing, no specific problem-space techniques are associated with the framework. (In other words, there is as yet no ‘UT’ equivalent to CT, nor is there likely to be in future. Although both are related to CF, it should become evident below that CT and the framework have fundamentally different functions and purposes: it therefore makes no sense to suggest, for example, that the framework could somehow be ‘better’ than CT, or vice versa.)

Framework role and purpose

The framework (‘UF’) provides a meta-methodology model describing a generic ‘solution-space’, in principle covering every possible method, methodology and pattern of tactics.

The purpose of the model is to provide a means to identify, situate and assess appropriateness of methods within different contexts, and, by corollary, identify probable characteristics of appropriate methods (in solution-space) for different methodological contexts (in problem-space).

The model itself should provide a means to categorise and describe any possible methodological context, including itself.

Similarities to Cynefin

The framework needs to identify distinctive regions or ‘domains’ within the overall solution-space. Terms such as Simple, Complicated, Complex and Chaotic usefully and meaningfully describe such regions.

All potential solutions start from an initial condition of inherent uncertainty (“I don’t know what to do”), described in CF as ‘unknown’ or ‘disorder’.

The regions do not have strict boundaries; there are many contexts in which the regions may overlap or blur. The framework is not a simple two-axis model.

The process of identifying an appropriate solution to a given context in ‘problem-space’ consists of following pathways in solution-space. These pathways may lead to appropriate or inappropriate methods, in relation to the actual needs in problem-space.

The framework provides a means to situate methods and tactics within solution-space. As in CF (but not CT), in itself the framework does not mandate any specific method or technique for use in any given context in problem-space.

The solution-space described by the framework has strong cultural connotations; it is best understood as not so much an abstract concept as an experience, even a way of life, and also has complex connotations of belonging, ‘homecoming’, commitment to and responsibility for place and context ‘as itself’. Aspects are similar in some ways to the Australian Aboriginal concept/experience/etc inadequately translated as ‘the Dreaming’, and also to the Bantu notion of ‘ubuntu‘. In English this may be represented, if somewhat inadequately, by terms such as ‘place’ or ‘space’; Dave Snowden’s use of the Welsh word ‘cynefin’ is particularly apposite here. The framework will need a name that similarly reflects this richness, depth and complexity of meaning.

Extensions to or differences from Cynefin

The framework differs from and extends CF by permitting multiple alternate views into the overall solution-space, whilst still always using the primary set of regions as a guide for comparison and as a base for common interpretation. (Note that some of these views may be simple two-axis matrices, or two-axis spectra. However, this does not mean that the framework ‘is’ a two-axis model – each is simply a selected view into the solution-space, not the solution-space itself.

The framework differs from CT (and to some extent from CF) in that it is not explicitly based in one specific category of science or methodology. Instead, as a ‘umbrella’ description of solution-space, it permits multiple bases of theory, considering theory to be another type of view into the overall solution-space. The model does not inherently privilege any theory over any other: in principle, the overall frame should be theory-neutral. (Note that the purpose of the framework is meta-methodology, not methodology. Any methods used to assess the nominal ‘appropriateness’ of any other method should themselves be situated and assessed recursively within the solution-space. This recursion would apply, for example, to all the methods and techniques within CT.)

The framework differs from CT and extends CF in that it does not privilege any one domain within solution-space. (From all its descriptions, CT appears to privilege the Complex domain in solution-space.)

The framework differs from CT in that the emphasis throughout is on recursive, layered meta-methodology, not method; its methods apply to recursive assessment of appropriateness of methods within solution-space, not to resolution of specific problems in problem-space. In framework terms, CT represents only one amongst a near-infinite range of possible categories of method within the solution-space.

The framework differs from CT in that its methods apply to solution-technique selection, not end-problem; it relates to an earlier stage of problem-resolution than does CT, which assumes that the technique(s) to be used have already been selected. The emphasis is on identifying an appropriate solution-technique before problem-solution can take place. The methods used in conjunction with the framework will often include those familiar in other forms of quality-management and process-improvement, such as the PDCA cycle and After Action Reviews, but in some cases might well draw on CT methods.

The framework contextually differs from CT and extends CF in its description of solution-selection pathways. For example, within the framework, in principle all solution-selection pathways leave the initial ‘disorder’ domain via the Chaotic domain, and may traverse into other domains from there; some solution-techniques remain primarily or wholly situated within the Chaotic-domain of solution-space, though most do not. For CT, all solution-selection pathways should traverse through the Complicated-domain of solution-space (for evaluation in formal scientific terms), and should ultimately lead to regions that are situated primarily or wholly in the Complex-domain of solution-space.

Suggested practice

The previous posts ‘Complexity, chaos and enterprise-architecture‘ and ‘More on chaos and Cynefin‘ summarise the principles for use of the framework, though should now be read in terms of the above description rather the standard Cynefin (CF and/or CT) concepts.

Within solution-space, specific techniques tend to go through the standard Gartner hype-cycle:

• ‘Technology trigger’ (though note that the trigger for a new solution-technique is not necessarily technological): the technique becomes available (i.e. known) within solution-space, usually closely matched at first to a single narrow region in problem-space
• ‘Peak of inflated expectations’: usage of the technique is extended outward into broader and broader regions of solution-space, in some cases to the point where it is believed to be ‘The Answer To Everything’
• ‘Trough of disillusionment’: repeated failures with use of the technique outside of its appropriate region(s) in solution-space lead to increasing rejection of the technique (and often abandonment in search of the ‘next Best Thing’), to the point where it is sometimes believed to have no useful application at all
• ‘Slope of enlightenment’: there is a belated awareness that the technique is neither an ‘answer to everything’ nor ‘useless’, but needs to be situated in appropriate regions of solution-space (i.e. matched to appropriate contexts in problem-space)
• ‘Plateau of productivity’: once the appropriate regions in solution-space have been identified, it becomes ‘self-evident’ as to which types of end-problems the technique applies best, and the factors that drive process-improvement for contexts in which this specific technique is used

For example, Taylorism and Six Sigma apply very well to contexts which have very high repeatability (i.e. are firmly situated in the Simple-domain in solution-space); but they are not well-suited for use outside of that region (hence the misuses of Six Sigma that Dave Snowden decries as ‘sick stigma’). The slide from Dave’s seminar that contrasts Scientific-Management, hard-Systems Thinking and (CT) Sense-Making shows the historical progression of the early stages of the hype-cycle in each case, but crucially it does not situate each category of techniques in solution-space. It correctly describes how techniques have arisen in part as a response to the downward trend of ‘failures’ after the hype-cycle ‘peak of inflated expectations’, but the overall result is a misleading impression that each category is somehow ‘better’ than the previous category in the sequence, when in reality ‘better’ is actually a highly contextual term.

Concept Lifecycles ((c) Dave Snowden / Cognitive Edge 2010)

As suggested in the slide, these three examples also provide stereotypes for techniques that are primarily or wholly situated in specific regions of solution-space:

• Scientific Management: Simple-domain
• hard-Systems Thinking: Complicated-domain
• (CT) Sense-Making: Complex-domain

But crucially there are no techniques listed for use in the Chaotic-domain of solution-space, in which the context is primarily or wholly non-repeatable. (An example given in one of the previous posts was sales, in which each individual sale is ultimately a unique ‘market of one’.) Although systematic processes exist for identifying and validating techniques in the Simple, the Complicated and, increasingly, the Complex domains, very little seems to have been done in the Chaotic domain in solution-space – it seems instead to have been dumped into the ‘too-hard’ basket as ‘outside the scope of science’, and hence all but abandoned.

Yet most if not all real-world problems incorporate elements of inherent uncertainty. Hence disciplines such as enterprise-architecture, quality-management and knowledge-management, which of necessity cover the whole of problem-space and solution-space, do definitely require meta-methodology techniques that are able to work within the Chaotic region. Since the other regions of solution-space are already fairly well covered (such as with narrative-knowledge techniques, statistical quality-analysis and so on), transits into, out of and within the Chaotic regions of solution-space (i.e. low-repeatability to non-repeatability) will probably provide the most urgent uses for the framework. Dave Snowden alludes to this in the quote used in one of the previous posts:

I have a strong bias towards the natural sciences and the Cynefin framework is built from a science based position. However … I have seen too many examples of dowsing not to believe it works in some way, I can also see that in all the cases it is a deeply embodied skill that cannot be taught. …  I also have to respect the fact that all controlled tests have failed to establish authenticity. This provides an interesting dilemma. On the one hand I have seen it work with water engineers, and with the man/jcb symbiosis that dug out the drive to the side of my house, on the other hand controlled tests have failed to validate. That means we have a really interesting anomaly that requires investigation.

Dowsing therefore provides a good test-case for the Chaotic-domain of the framework’s solution-space: the techniques must produce concrete real-world results, yet by definition operate in inherently non-repeatable conditions.

Perhaps relevant here is that there is now a fully-worked example for this, documented as the book Disciplines of Dowsing, which I co-authored with archaeographer Liz Poraj-Wilczynska. (Archaeography is a relatively new sub-domain of formal archaeology, providing a disciplined, structured bridge between conventional ‘objective’ archaeology, art and culture.) Within it we used a variant of the framework with domains described as follows:

• Simple domain (‘inner / truth’): ‘Mystic’ mode (aka ‘Priest’)
• Complicated domain (‘outer / truth’): ‘Scientist’ mode
• Complex domain (‘outer / value’): ‘Magician’ mode (aka ‘Technologist’)
• Chaotic domain (‘inner / value’): ‘Artist’ mode

A set of characteristics are defined for each mode:

• its role within the overall discipline or practice (of dowsing, in this case)
• the type of ‘world’ (region of solution-space) which the mode will cover
• the core emphasis and types of response within the mode
• when to use this mode within the overall discipline
• how to identify when this mode is already in use – “You’ll know you’re in this mode when…”
• rules, guidelines or principles that inherently apply within this mode
• warning-signs of potential problems within this mode (i.e. misalignment between problem-space and solution-space)
• ways to bridge across to other modes (i.e. triggers for transitions and/or pathways within the solution-space)

These are summarised in a two-page reference-sheet and described in more detail in pages 31-70 of the e-book version of ‘Disciplines of Dowsing‘, which can be downloaded for free from here.

During live field-work, the practitioner will, in effect, frequently return to solution-space to tackle routine methodological concerns, including:

• “Which mode am I in now?” (i.e. which region of solution-space) – compare the roles for each mode, or the “You’ll know you’re in…” lists, or work it out backwards from the rules or guidelines in use at present
• “If I’m in this mode, which rules apply?” (i.e. intersection between problem-space and solution-space) – look up the rules from the list for the respective mode – and check against the respective ‘warning-signs’ list to test if they’re being blurred with the rules for another mode
• “Which mode do I need to be in?” (i.e. selection of region within solution-space) – look up the “You need to use when…” lists, and pick out the appropriate mode for the task in hand (i.e. in problem-space) – and remember also to use the new mode’s rules, not those of the previous mode
• “If I’m in this mode, how do I switch cleanly to another mode?” (i.e. transition within solution-space) – look at the respective ‘bridge’ list – though note that switching to the ‘diametrically-opposite’ mode (i.e. Chaotic <-> Complicated, or Complex <-> Simple) may well seem hard at first

The book also includes (in pp.71-95 of the e-book) what are described as ‘Seven Sins of Dubious Discipline’, which exemplify particular ‘clusters’ of common errors within solution-space:

• The Hype Hubris – in effect the same problems as described at the ‘Peak of Inflated Expectations in the Gartner hype-cycle
• The Golden-Age Game – similar to the Hype Hubris, but frequently coupled with an extraordinarily arrogant ‘holier-than-thou’ type of self-image
• The Newage Nuisance – a kind of half-baked misuse of techniques, in effect a complete mismatch between solution-space and problem-space
• The Meaning Mistake – a specific class of of errors that can occur in relation to the Complicated-domain of solution-space (for a real-world example, see my earlier post ‘Dowsing the flames‘)
• The Possession Problem – a specific class of errors that occur at another level of meta-methodology, when understanding of both problem-space and solution-space is forced into the Simple-domain via mistaken notions about ‘possessing the truth’ about a given problem and/or solution
• The Reality Risk – a more subtle class of risks (and sometimes genuine dangers) that may occur in the Chaotic-domain of solution-space
• The Labyrinth Lessons – issues that arise as a consequence of specific stages in the sequence of skills-development, both in implementation of the actual skill (i.e. in problem-space) and in developing and understanding the principles and practice of the skill (i.e. in solution-space)

These tactics are all directly applicable and re-usable in just about any other discipline or business-domain, especially those that of necessity must transit into or through the Chaotic-domain of solution-space. For example, we’ve already adapted these for use in archaeography and archaeology; I’m currently in the process of adapting them for use in values-architecture and enterprise-architecture.

Constructive comments, suggestions and other ideas most welcome – there’s a lot we can do with this.

Over to you, anyway – and thanks.

The point I’m trying to address here is this: what methodologies do we need to use to assess the validity of methodologies? As with the previous posts, this is still very much a work-in-progress: there’ll necessarily be a certain amount of ‘feeling my way’, and almost certainly a few mis-steps along the way. So please do allow me some room and leeway as you read this; and also, to get the best out of this for yourself and your own work-context, please do expect to have to do some in-depth thinking and cross-correlation of your own.

What I’m trying to tackle here are some of the most complex and paradoxical problems in the methodology of methodology itself: none of this is ‘kiddies’-level’ stuff, and you’ll need a solid background in theory and practice of methodology before you can make much sense of it. So please don’t assume automatically that I’m ‘wrong’, or that I’m some kind of religious nut, because you’ll miss the whole point of this if you do. This does also need to be a collective development, so as before, constructive comments and criticism would be most welcome!

Read on, anyway.

At first glance, assessing the validity of a methodology might seem simple and straightforward: it’s either scientific or it’s not, for example. But in practice that task is nothing like as simple as it seems, and it’s all too easy to misread what’s actually being described and said, especially when emotions come into the picture – which they always do whenever something new or unfamiliar is being assessed. For example, at one point during our somewhat unhappy interaction over the past couple of posts, Dave Snowden commented that:

Your language in this later post is now the language of cults by the way. You are not understood, you can’t really explain the concept to an unbeliever, you are in a different place. … . People who do not agree with you are not listening so you will have to withdraw from the argument. You are the possessor of disciplines that prevent you falling into error, lesser mortals who do not appreciate this are dogmatic, they disappoint you.

And he’s right: if you choose to read my posts in that way, you can find all of that in there. So if we use only simple language-analysis based on those rules above (i.e. Simple domain, in Cynefin terms), “he’s speaking like a religious fanatic” or suchlike is an automatic conclusion we could reach. (This would especially apply if we’ve thrown in a bit of unconscious pre-filtering – or ‘pattern-entrainment’, in Cynefin terms – to interpret others’ views as ‘cult-like’. This kind of pre-filtering is particularly likely to occur in a Simple-domain context because of the need for fast response rather than considered reflection, as per the Complicated and Complex domains.)

But the problem is that this kind of language isn’t unique to cults. We’ll see exactly the same phrases being used during the exploratory-phase of any new development. Almost by definition, new ideas are hard to describe to others – “you are not understood, you can’t really explain the concept to [others]” – partly because of pattern-entrainment in the critics (in everyone, actually), and partly also because the speaker’s framing and conceptualisation may well be a rickety mess, especially in the early stages of a development-phase. In a metaphoric or even literal sense the speaker may indeed be in a “different place”: that’s the whole point about multiple-viewpoints in enterprise-architecture, for example. That’s also the point of the old story of the blind men and the elephant: each one of them experiences something different, and interprets it in a different way, because each has an incomplete view. In other words, there’s an irresolvable logic-clash: to quote Edward de Bono, “everyone is always right, but no-one’s ever right” – each point of view is ‘true’ within itself, but fails to describe the whole picture.

That’s the rational side of the problem. The remainder of Dave’s summary of “the language of cults” accurately describes common emotional responses to the rejection that follows the logic-clash. The critics are “not listening” because they’re equally certain that they’re ‘right’ – which they probably are, from their point of view. Rejected, it’s quite likely that the speaker will “withdraw from the argument” – the passive side of the old ‘fight or flight’ response. Conversely, the active side of ‘fight or flight’ often leads to ‘propping self up by putting others down’: hence “lesser mortals” who are “dogmatic” and “disappoint you” and so on. We’ll see this kind of interaction all the time in any development environment: it’s one of the most common causes of conflict in business, for example.

But is it a dysfunctional ‘cult’-mentality, or is it the normal logic-clash that we expect to get during a functional, healthy development-process? The problem here is that the simple language-analysis can’t tell the difference between them. And whilst it’s technically correct to say  ”Everyone is always right, and no-one’s ever right”, it doesn’t mean that everyone’s point of view is always valid – and as Dave correctly indicates (or implies, rather) in another comment, a random, rampant ‘anything-goes relativism’ will invariably end up in a seriously dysfunctional mess. To resolve this, we’re going to need better methods – which is where methodology comes into the picture.

The catch is that methodology, and particularly the more abstruse areas such as meta-methodology or ‘methodology of methodology’, has never had a very good press – especially in the Western academic tradition. For example, the clash with Dave reminded me of this incident in Robert Pirsig’s Zen and the Art of Motorcycle Maintenance:

When the Chairman did appear an interview took place which consisted essentially of one question and no answer.

The Chairman said, “What is your substantive field?”

Phaedrus said, “English composition.”

The Chairman bellowed, “That is a methodological field!” And for all practical purposes that was the end of the interview. After some inconsequential conversation Phaedrus stumbled, hesitated and excused himself, then went back to the mountains.

(Quote is from p.145 on the Scribd version of the book: would recommend also to read at least the rest of that page. I’ll admit that I’ve been strongly influenced by Pirsig’s work on quality and ‘gumption traps‘, though I dislike his subsequent work on value.)

‘Retreating to the mountains’ risks withdrawing into cult-like behaviour, or even to psychiatric illness or worse – as Pirsig’s all-too-literal alter-ego Phaedrus discovered to his cost. Yet it’s also unlikely that anything useful will arise from a fight – especially with someone as bull-headed and over-certain as Phaedrus’ Chairman. So whatever approach we  take here, it needs to steer well clear of those two extremes.

First, we need to acknowledge that, as Pirsig explains, methodology is itself a substantive field. And we need methodology in turn to validate the procedures and techniques used for each substantive field: so in this case we need a methodology for deriving methodologies, a ‘meta-methodology’. (Enterprise-architects would recognise this kind of recursion in that the first of our architecture-principles needs to assert the primacy of principles;  quality-management folks also know that the first procedure we need to write is the procedure on how to write procedures.) Substance and method are fundamentally different in their natures, yet each also includes the other within itself, much as in the classical Chinese ‘yin-yang‘ symbol – hence the Zen allusion in the whimsical title of Pirsig’s book. Getting the right balance between them is critical here – otherwise we end up with the kind of situation above, where the wrong tools are used to assess the required context.

To me, one of the keys to this is systems-theory, because it allows us to create a sense of the whole from whatever small fragments we have – such as the blind men’s different stories of the same elephant. Interestingly, the yin-yang symbol incorporates within the image at least three key-principles from systems-theory: rotation, recursion and reflexion. In my own consultancy-work I add two more – namely reciprocation and resonance – to provide a reasonably complete set of principles for whole-of-enterprise architecture; other people might use others, but these in particular do help to manage the complexities of that need for balance.

Rotation is probably the simplest of these principles: a systematic process of assess­ing a context from multiple perspectives, and then synthesising the result to approximate a picture of the whole. That’s what the blind men would do about their elephant – once they stop arguing about which of them is ‘right’, that is. All of us use this principle frequently in some form in our professional work: for example, even a simple checklist is a form of rotation in this sense. To give a more complex example, the methodology described in my book Real Enterprise Architecture is a kind of rotation through different views on the role and practice of architecture at the whole-of-enterprise scale.

Reciprocation draws on the understanding and experience that, with one key exception, systems must always balance out some­how. What makes it difficult to analyse is that this reciprocal balance is not necessarily direct or immediate. (Incidentally, this highlights one of the key differences between the Cynefin ‘Simple’ domain, which often only deals with real-time,  versus the Complicated domain, which is still rule-based but does have to deal with complex interactions over time and space and context.) In many cases balance may only be achieved over time at a system-wide level, with ‘energy-transfers’ often occurring between the dimensions – a classic business-example being a ‘slash and burn’ tactic which gives a short-term financial gain, but balances out by destroying the organisation’s ability to do work, soon wiping out all of the supposed gains. Again, this is a relatively straightforward principle, one which most of us will use in one form or another in our everyday practice.

Resonance – the feedback-loops which can be found in all complex real-world systems – provides the exception to that reciprocal balance. In systems-theory this can occur through ‘positive feed­back’ or feed­forward – both of which increase the ‘snowball effect’ towards self-propagation – or as ‘negative feedback’, or damping, which reduces the effect. This principle is especially important in assessing methodologies for use in social-systems: whilst most physical-systems operate a ‘win/lose’ dynamics (if variously Simple or Complicated, in Cynefin terms), most social-system operate a genuinely Complex dynamics in which simple reciprocal-balance is relatively rare, and the real choices spread across a very broad spectrum from ‘win/win’ to ‘lose/lose’ – with ‘win/lose’ being an interestingly illusory form of ‘lose/lose’.

Recursion is a ‘nesting’ of a pattern within the same kind of pattern – of which one of the most common forms is the hierarchical  structure of the everyday ‘org-chart’. These are patterns of relationship or interaction which repeat or are ‘self-similar’ at different scales, and again are common in the Complex space: identifying such recursion can make it possible to reduce complex-seeming processes into a much simpler – though rarely Simple – set of patterns. Methodologies that are recursive (and, in most cases, also iterative) are highly desirable for many different reasons: training is simpler, for example, because the same pattern is used on many different scales, and the overall pattern is much the same at every level of skill. In the IT industry, common examples of methodologies that are either overtly or implicitly recursive include TOGAF 9 (enterprise-architecture), ITIL (IT service-management), RUP and EUP (Rational/Enterprise Unified Process for IT-systems development) and the various Agile development-methods.

Reflexion is perhaps the strangest aspect of systems-theory, although it’s a direct corollary of recursion. It suggests that, as indicated in the yin-yang symbol, the whole, or aspects of the whole, can be identified or inferred from within the attributes and transactions of any part at any scale. Everything is connected to everything else, is part of everything else; every point is contained by and contains every other point. A useful analogy here is a holograph: unlike an ordinary photograph, even the tiniest fragment of a true hologram will contain a complete picture of the whole, albeit with less detail. (Fragmentation of a photograph reduces the accessible scope of each fragment, whilst still retaining the same level of detail;  fragmentation of a holograph reduces the level of accessible detail within any given fragment, but not the scope.) The same is true of business systems, social systems and so on: and once we develop an eye for reflexion, and see how it works in practice, we can create change-methodologies that can start anywhere, in any appropriate part of the system, and leverage the results out into the whole.

Use of any of those system-principles provides support for a good balance of flexibility and rigour, especially for methodologies that need to operate in the Complex or Chaotic space. And from almost forty years’-worth of experience developing methods and methodologies of many different kinds in many different industries and contexts, I would argue that any method or methodology that is used to assess other methods and methodologies – a meta-methodology, in other words – should always aim to incorporate all of these principles within its structure and design.

If we don’t do so, the methodology is almost guaranteed to give us ambiguous or seriously-misleading answers to key questions – as can be seen in the problems caused over-simplistic use (or misuse) of Beyerstein’s checklist for ‘pseudoscience’. And use of those principles not only makes the methodology more reliable, but usually also easier to use. Rotation, for example, helps us to balance simplicity with breadth and/or depth of scope. Reciprocation and resonance help us cope with potential problems of balance and perspective. And the combination of recursion and reflexion not only helps to keep things simple without becoming simplistic, but also allows a properly-designed methodology or meta-methodology to be used to assess itself in exactly the same terms as it assesses any other methodology.

That last point is especially important, because it’s one of the few ways in which we can resolve the ‘logic-bootstrap’ problem described earlier. We can only resolve that problem by going into the Complex or Chaotic domains, where we can test the validity of assumptions, but where by definition logic is unreliable. The recursion/reflexion combination provides us with an alternative approach, with a similar level of precision and discipline as in formal-logic, that reflects back on itself in every possible way – top-down, bottom-up, sideways-in, spiral-out. The resultant reflections shine the light of enquiry into every dark corner of the methodology – a process which may well unearth fundamental flaws that must be fixed before using that methodology in significant real-world practice.

The point here is that if this reflection isn’t done, the methodology may be left with gaping holes that can’t be seen from within the methodology itself, because they’re beyond the scope of the chosen logic. Perhaps the most common faults are circular-reasoning and invalid assumptions about supposed ‘universals’ – often from a complete failure to recognise even that the ‘logic-bootstrap’ problem exists. (Self-styled Skeptics’ frequent misuse of ‘scientific’ notions provides us with many examples of this, as we saw with Beyerstein’s ‘pseudoscience’ checklist.) Other serious problems arise from misuse of Complex-domain techniques such as post-structural linguistics: this is particularly common in political and social analyses which ‘deconstruct’ everyone else’s text to find structural flaws, but fail to apply the same analysis to their own reasoning. (When we do apply the same analysis reflexively to itself, the flaws that become evident can sometimes be startling. Some of the methodological errors in many of the models currently used in the domestic-violence ‘industry’, for example, are so fundamental, so blatant, and so horrendous in their consequences, that in a political/military context the promoters of equivalents of those models would be classed as war-criminals or worse: the methodologies really are that bad… Which is worrying, to say the least.)

But there are also plenty of examples where the reflection has been applied properly, resulting in methodologies that are simple (yet not simplistic), versatile, flexible, self-correcting and often self-adapting. Some industrial examples that come to mind immediately include variants of kaizen, kanban, Deming’s 14 Principles and much of the work of the Agile movement. In the futures context (professional futurists, not ‘futures’ in the finance-industry sense) one of the most powerful tools is Sohail Inayatullah’s Causal Layered Analysis, which applies recursion and reflexion to post-structural linguistics (hence its tagline “postructuralism as method”) to assess a context in many different views, from everyday ‘litany of complaint’ to deep-myth, in a manner which in some ways resembles Cynefin. Stafford Beer’s Viable System Model provides a similarly versatile means to model and manage information-flows at every layer within an overall enterprise, and can also be used in conjunction with his dictum POSIWID (“the [effective] purpose of a system is [expressed in] what it does”) to provide a reflexive means to review and contrast the nominal and actual drivers for an organisation:

“According to the cybernetician the purpose of a system is what it does. This is a basic dictum. It stands for bald fact, which makes a better starting point in seeking understanding than the familiar attributions of good intention, prejudices about expectations, moral judgment or sheer ignorance of circumstances.” [Stafford Beer, University of Valladolid, October 2001]

(My book The Service-Oriented Enterprise explores how to extend Stafford Beer’s system-principles to all other aspects of the enterprise, to create a recursive and reflexive ‘Viable Services Model’. See also the Slideshare presentation ‘Enterprise architecture and the service-oriented enterprise‘ for descriptions of how to link those principles to existing enterprise-architecture tools such as TOGAF and Zachman.)

Finally, one other reflexive theme is an essential for every meta-methodology, and preferably every methodology too: the old ‘Golden Rule’, “do as you would be done by”. Developing a methodology is invariably messy, with many mis-steps: it’s rare that we “get it right” all at once, and even rarer to get it right on the first attempt. This is true for anyone who takes the risk of developing something new, something different. On the other hand, it is very easy to sit on the sidelines from a position of certainty – “that which is already proved” – and tell others that they are ‘wrong’, even though the logic being used to judge ‘right’ from ‘wrong’ may not apply in the respective context. It’s also much easier to demolish a temporary lash-up of a ‘work-in-progress’ than a rigid structure of cross-links and cross-braces – even though in reality it may be the latter that is actually ‘wrong’. So we do need to respect that fact, and respect the aim and intent of any ‘temporary lash-up’, rather than immediately reach out to tear it down.

Or tear down the person, for that matter. There are very good reasons why Deming included the phrase “Drive out fear!” as one of his ’14 Points’; for much the same reasons, one of the few rules for an After Action Review is “pin your stripes at the door”. Similarly, one of the core principles of 12-Step programmes is the explicit rejection of blame – whether from others or from self – and instead emphasising the centrality of personal and mutual responsibilities. Power enables change, but power is also the ability to do work, not the ability to avoid it – especially avoid it by dumping all of the work onto others and then punishing them for trying to do their best in doing that work, as is all too characteristic in destructive ‘critique’ of new methodologies and tools. More details on the business implications of that, if you’re interested, in this ‘manifesto’ on functional power-dynamics in the workplace.

Better stop there for now, I guess. Hope it’s been useful, anyway, and, as before, constructive comments most welcome.

(This has turned out to be an enormously long post – I’d better put a ‘Read more…’ link in here before continuing.)

This time the Tweet was from Cynefin creator Dave Snowden:

• snowded: NLP as Cargo-Cult psychology. Great paper http://jarhe.research.glam.ac.uk/media/files/documents/2009-07-17/JARHE_V1.2_Jul09_Web_pp57-63.pdf

The link points to a 7-page academic paper [PDF] by Gareth Roderique-Davies of University of Glamorgan, which purports to indicate that NLP (‘Neuro-Linguistic Programming‘ – a kind of self-hypnosis psychological tool) has no scientific basis, and is therefore ‘cargo-cult psychology’. I do take his point that there are some worrying flaws in NLP itself, and even more worrying flaws in many of the ways in which NLP is promoted and used these days. But I’ve seen this kind of ‘scientific’ review before, and I said so in my re-Tweet of Dave’s first message:

• tetradian: @snowded: “NLP as Cargo-Cult psychology. Great paper http://tr.im/IjbF ” <disagree: NLP has serious flaws but this is just a hatchet-job

The problem is that the reviewer is trying to assess NLP in conventional scientific terms – which makes no sense right from the start, though his world-frame would itself make it impossible to see why it makes no sense. (For enterprise-architects, by the way, this is the same underlying reason why IT-centrism or organisation-centrism is such a problem: the frame itself makes it impossible to see beyond the frame.) The title of Bandler and Grinder’s original book that defined NLP way back in the 1970s gives the reason why the scientific frame won’t work: it’s called The Structure of Magic.

Yup, that’s right: magic.

Most self-styled ‘scientists’ treat that word in the same way as IT-centric ‘enterprise’-architects treat business-architecture and beyond: namely a randomised, undifferentiated grab-bag of all the bits of reality (or business-reality, in IT-EAs’ case) that they don’t understand. And then complain that it’s a mess, and doesn’t make sense in their own chosen terms, and therefore doesn’t exist. Which is not exactly honest – and it’s certainly not helpful in practice, because magical-thinking is often the only way out of many everyday scientific, technological and business dilemmas and problems.

A small tale here. Everyone ‘knows’ that Isaac Newton was one of the world’s greatest scientists, yes? (Which he was, of course.) But not many people know that he was also interested in a great many other subjects, including religion, alchemy, astrology and much else besides: in fact he wrote more on alchemy, for example, than on all of his scientific studies put together. Edmond Halley, the then Astronomer Royal, was berating Newton for the latter’s studies of astrology: it was all nonsense, he said, ridiculous, utterly unscientific – or words to that effect, anyway. Newton’s short, sharp retort: “I have studied the subject, sir, and you have not!” End of conversation…

Which brings us back to NLP, and the structure of magic. As it happens, I have indeed “studied the subject, sir” – for more than forty years, in fact – and I guess most people reading this blog probably haven’t, so it might be useful if we do a quick tutorial here on the role and limitations of the scientific frame and mindset, and the contrasting role of magical-thinking. To do this I’ll pick up on another of today’s Tweets, from knowledge-management (KM) guru David Gurteen:

• DavidGurteen: Is KM a Pseudoscience? #KM http://www.greenchameleon.com/gc/blog_detail/is_km_a_pseudoscience/

This link points to an article by another key figure in KM, Patrick Lambe – much better thought-through and much more considered than the previous piece. Using a checklist from an article by Barry Beyerstein, he scores KM overall as having a score of only 5.4 out of 10 as a ‘rational endeavour’, and concludes that it is too close to a pseudoscience: “must do better”, he says.  But what that article misses, yet again, is the bald fact that trying to assess most of KM in scientific terms makes no sense. The only way we can make sense of it is via a magical approach.

(Yes, I know I still haven’t explained yet what I mean by “a magical approach” – give me a chance, I’m getting to that in a moment! )

Before we can look at magic, we need to understand science – as much for what it isn’t as for what it is. What it isn’t – as any competent scientist would admit – is “the answer to Life, The Universe, Everything”. Instead, it’s a particular body of knowledge, developed in terms of a specific set of methods and assumptions, and which can only make sense – or be useful and valid, rather – within a very specific set of constraints. Science has been extremely successful within those constraints - so successful, in fact, that many people fail to realise that by its own definitions it is not and cannot be successful outside of them. Therein lie many huge problems for KM, for enterprise-architecture and for many other disciplines – including magic.

This is perhaps best described in one of my all-time-favourite books, WIB Beveridge’s The Art of Scientific Investigation. First published in 1950, it’s been continually in print ever since, and remains one of the great classics of scientific research. I’ll have to quote from memory, as my copy is back in Australia, but his introduction starts like this:

Complex equipment plays a central role in the science of today, but it should never be forgotten that the most important instrument in research must always be the mind of the researcher.

Beveridge expresses concern that “perhaps not enough attention is paid to making the best use of it”. To this end he focusses on the actual practice of science, rather than solely on the end-products of that practice. Hence his book includes detailed descriptions and examples on strategy, hypothesis, the use of chance and intuition, and “the hazards and limitations of reason”. (Most of his examples come from his own field of biology and biochemistry, but they’re just as applicable to every other branch of science.) The summary in his chapter on reason is particularly important, though forgive me if I again have to quote from memory:

The origin of discoveries is beyond the reach of reason. The role of reason in science is to come afterwards, to review and reassess and to build a general theoretical scheme. … Most biological ‘facts’ are so uncertain that at best we can only reason on probabilities and possibilities.

And that last sentence remains just as true as ever, despite the advances of molecular biology and the like over the past half-century: the only certainty in science is that many things will always remain uncertain. But it’s all too easy to forget that fact: that’s where the problem starts.

It’s also all too easy to forget that ‘the scientific method’ depends entirely on its base-assumptions: it cannot be relied upon outside of their remit. For our purposes, the most important of these assumptions include:

• causality – all events are connected via cause/effect chains in a linear ‘arrow of time’
• repeatability – given the same conditions, all experiments and results must be repeatable by others
• falsifiability – every hypothesis must be framed in such a way as to enable its negation by experiment
• consistency – the results and hypotheses in each domain of science cannot contradict those of other domains of science

Within those constraints, science works extremely well – and likewise, usually, any technology based on that science. But it’s essential to realise that it only works within those constraints – and there are plenty of conditions where those assumptions break down. Repeatability and falsifiability will seem to make sense whilst we’re dealing with the mid-range of scales, but in fact they break down as we move more towards  the very small – down into quantum levels, as per Heisenberg’s Principle - or to the very large – where experimentation and repeatability are often inherently impossible (at least on the kind of time-scales that we live in!). The same applies as we move more towards unique events: chaos-mathematics makes the level of unpredictability more predictable, but does not reduce the unpredictability itself. Consistency also frequently breaks down between domains: last I heard, for example, the most likely theory of star-formation requires a universe much older than ‘permitted’ by the most likely theory of cosmology. And out at the fringes of science – particularly in nuclear physics – there are plenty of examples where any linear concept of causality will break down, and at times looks remarkably like traditional magic. For example, the old magical notions of ‘action at a distance‘, teleportation and telepathy are all ‘permissible’ in current quantum-entanglement physics, and in some cases have even been demonstrated in laboratory-experiment – even if only at quantum scales.

And there are plenty of real-world, everyday examples of where those assumptions will break down – especially in KM and the like, where we’re often dealing with contexts which, by definition, are either unique or near-unique. So complaining that KM might be considered by some to be a ‘pseudo-science’ is to miss the point, because there’s no way that it can be a ‘science’ in those formal terms above. Instead, to make sense of what’s going on, we may well need to turn to other approaches: science is one approach that we might use, but it’s not the only one.

Which, by a round-about route, brings us back to where we started, with Dave Snowden and the Cynefin framework. Starting from the unknown – what Dave describes as the domain of ‘Disorder’ – we have four distinct methods to ‘make sense’ of what’s going on:

• the Simple domain: apply rules to ‘categorise – sense – respond’
• the Complicated domain: apply algorithms and logic to ‘sense – analyse – respond’
• the Complex domain: apply guidelines and heuristics to ‘probe – sense – respond’
• the Chaotic domain: force change through action, to ‘act – sense – respond’

I know Dave can get ‘curmudgeonly‘ when we place these Cynefin domains in a simple two-axis frame, but in this case there’s one frame that aligns extremely well, and does add quite a lot to our understanding of Cynefin itself. These two axes are value versus truth, and inner (personal) versus outer (collective), which gives us four domains: inner truth, outer truth, outer value, inner value. These domains map almost exactly to those four main Cynefin domains and their sense-making tactics:

• ‘inner truth’: Simple domain – rules or supposed ‘universal truths’ that purport to apply to everyone, everything, everywhere
• ‘outer truth’: Complicated domain – algorithms and the like, often with multiple factors and complicated interactions and delays, but always amenable to causal analysis
• ‘outer value’: Complex domain –  use ‘seeds’ and experiments to probe into the context, to allow meaning to emerge
• ‘inner value’: Chaotic domain – any meaning that may be derived is context-dependent and probably personal only

(The chapter ‘Can’t we explain this scientifically?‘ in my 1990 book “Inventing Reality” likens each of these modes with a means to survive within a swamp: run too fast to sink; climb up a pole; weave a platform between a group of poles; or spread your weight on swamp-shoes. The advantages and disadvantages of each mode are summarised in some detail there: might be worthwhile to read that chapter now and then come back here.)

In practice we would – or should – usually switch between each of these modes, much as Beveridge implies in The Art of Scientific Investigation. But the key point here is that a ‘scientific’ approach – which depends on causality and logic – can only make sense in the two ‘truth’ domains. Trying to use ‘truth’ tactics in the ‘value’ domains is not a good move: we risk ending up with what Dave Snowden calls ‘pattern entrainment’, such that in effect we use a quasi-religious belief as a substitute for true science or sense – which is not a good idea. (For more on this, see, for example, Amory Lovins’ video on “How the practice and instruction of engineering must change“.). Which means that we need to use entirely different approaches in the two ‘value’ domains. We could use terms such as ‘non-rational’, ‘arational’ or ‘meta-rational’ for this, but we might as well use the term that already exists for this: magical.

Magical-thinking isn’t a mistake: it’s what we need to use in the two ‘value’-domains – or, in Cynefin terms, the Chaotic domain and, especially, the Complex domain.

This post has rambled long enough already, so I’d better not go into too much detail. But one of the key tactics here is to deliberately use beliefs as tools, especially in the Complex domain, using them as if they are true whilst still recognising that they may not necessarily be ‘true’ in absolute sense. In classic scientific terms, another name for this tactic is hypothesis, as contrasted with idea (Chaotic domain), theory (Complicated domain) and law (Simple domain). It’s what we do in most technology-development: for example, we might use ideas from science, but we might also use analogy, metaphor, serendipity or even images from a tarot-deck – what works is whatever happens to work. And the fundamental question here is not science’s ‘How does it work?’, but ‘How can it be worked?’ – not how do we make it more ‘true’, but how do we make it more effective, more efficient, reliable, elegant, appropriate, integrated.

(Incidentally, this is one of several reasons why using the term ‘applied science’ as a synonym for ‘technology’ is misleading and even dangerous, because we end up applying the wrong criteria to measure that technology’s value – assuming ‘technology’ in the original sense of ‘tekne‘, a body of knowledge and related practices rather the rather incomplete sense as ‘machines and stuff’. Another concern is that by purporting to be ‘science’, a usage of technology can also attempt to claim science’s status as ‘value-free’ – and hence supposedly not subject to the ethical and other value-constraints that, by definition, are actually the core of every technology. And magic too, for that matter . In this sense, technology and science are fundamentally different from each other, whereas technology and magic are fundamentally the same. In fact the only real difference between the latter is that magicians tend to be a bit more ‘way out’ in their choice of beliefs, especially when the technology is more about mind than matter.)

Whichever mode we use at any given time, the key to all of this is discipline. (This applies in magic as much as in any other technology: as the pseudonymous author of the influential SSOTBME put it, “all those boring meditation books are just the magical equivalent of a school chemistry primer”. But that’s another story… ) Which, finally brings us to why I wrote this post in the first place, because we need a disciplined approach not only to the use of each domain, but also to how not work work within each domain, and how instead to switch between the domains in an effective, intentional manner.

Most readers of this blog would know me as a specialist in whole-of-enterprise architecture. But my real interest, and real work, is in methodology and meta-methodology – the design of methodologies to suit each specific context and need. Behind that, what really concerns me is the process of developing skills as true skills capable of dealing with the complexities and chaos of the real world – rather than as glorified ‘trainings’ that are only usable in the safe, easy purported-predictability of the ‘truth’ domains. I’ve been engaged in this work for well over forty years: for example, one of the tools I developed that you may have seen is the Skills Labyrinth, a live-metaphor for the skills-learning process.

But one of my primary test-cases for this – mainly because it’s almost the closest I can find to a ‘pure’ interpretive-skill, with very little manual-skill and technical-knowledge required to get started – is what’s known in Britain as dowsing, the generic for ‘water-divining’ and the like. (Each country has their own term for this: Americans would know this as ‘water-witching’, for example, whilst Dutch might call it ‘wichelen’.) It’s a classic ‘magical’ skill, sufering – as so many do – from an overdose of idiots, and much-derided by self-styled ‘skeptics’ who rely only on ‘scientific’ theory rather than technological practice and hence don’t have any real grasp of what they so obsessively dismiss. (As it happens, we know a great deal about the physics, physiology and psychology of the skill: one key point we now know for certain is that there is no single mechanism involved, but rather a complex ‘weighted-sum’ merge of multiple mechanisms. Hence most of the classic means of scientific enquiry – “how does it work?” – make little sense, whereas technological enquiry – “how can it be worked – does indeed work well here.)

Worldwide, I’m actually better known as a writer on dowsing and related subjects than on IT or enterprise-architecture: my first book on this – nowadays known as The Diviner’s Handbook – was first published in 1976, translated into some dozen languages, has been in print continuously ever since, and is regarded as one of the standard reference-works on the subject (or learning-guide, rather, because that’s its real purpose). And I apply exactly the same rigour to my work in that field as I do to anything else: I insist on keeping myself, and others, strictly to the correct discipline in the appropriate domain. Which at times is not ‘scientific’, of course – but so what? If the ‘scientific’ mode is not appropriate in that part of the technology, don’t use it! Which is exactly the same principle as we need to apply in KM, or enterprise-architecture, or anything else that is inherently complex and in any way inherently unique, and hence where the usual constraints of ‘rational repeatability’ and the like do not and cannot always apply.

Hence yet another book of mine, co-authored with the archaeographer Liz Poraj-Wilczynska, and published late last year, called Disciplines of Dowsing. (You can download the e-book version for free from the website, though please consider buying the print version if you’re going to use it in practice!) Parts of this work have also been published in the Berg peer-reviewed academic journal on archaeology, Time & Mind. In it we explore the application to dowsing practice of the same four approaches to sense-making and action, linked to Cynefin as above, and cross-linked to standard quality-improvement tactics such as kaizen, the Deming/Shewhart PDCA cycle, ISO-9000:2000 and reflective methods such as After Action Review. It’s the same principles, applied in a slightly different area to what most KMs and EAs might know, but otherwise no different at all. What is different – and which we haven’t seen anywhere else – is an explicit emphasis on how and when and why to switch between each of the disciplines. Which, in turn, we could – and, I would argue, we should – apply in turn to our other everyday work-domains such as KM and EA and the like.

There’s also a strong emphasis in the book on how to identify and avoid some all-too-common pitfalls, the ‘seven sins of dubious discipline’ such as the Hype Hubris, the Newage Nuisance and the Meaning Mistake. (‘Newage’ is perhaps a more accurate term for much of what purports to be ‘new age’: it rhymes with ‘sewage’, ‘the discarded remnant of what was once nutritious’… yup, I can be a cynic too! ). But the point here is that, again, there are exact equivalent of the ‘seven sins’ in every other kind of skill, including those in the sciences: for example, Roderique-Davies’ paper on NLP includes several all-too-obvious examples of the Meaning Mistake. If we don’t understand the limitations of science, and worry too much about seeming ‘unscientific’ or ‘pseudoscience’, we’re likely to end up damaging the quality of our skill and our results rather than improving it. In that specific sense at least, magic is real – and as Cynefin shows us, it matters just as much as science and the like to the quality and validity of our practice.

In addition to the e-book of Disciplines of Dowsing, there’s also a two-page reference-sheet that summarises the four sets of disciplines, and that’s perhaps more immediately usable in practice. (The material on the ‘seven sins’ is only in the book, though.) It’s written for dowsers, of course, but it doesn’t take much translation to apply it direct to KM, EA, software development or any other complex-domain skill. Download it, perhaps, and let me know how it works for you? And thence it might be worthwhile writing another version specifically for KM or whatever. Something different to play with, anyway.

Being an ‘alternative’ field, dowsing does suffer from more than its fair share of kooks and flakey ‘New Age’ types, but at present there’s a much stronger emphasis on practicality, professionalism and discipline – hence my book on Disciplines of Dowsing that I co-authored last year with archaeographer Liz Poraj-Wilczynska, and a set of related articles (see summary [PDF]) that we wrote for the society’s journal, which was the reason why I was at the conference. An interesting bunch.

So for me it was no surprise to find some innovative ideas there – some of which were definitely relevant to other fields, including business-architecture and enterprise-architecture.

One which bridged the gap between dowsing and technical world was a lovely Google Earth ‘mashup’ by Hugo Jenks, linking traditional dowsing techniques to current GIS (geographical information systems) with a purpose-built embedded-controller and an ingenious software hack. One of the standard dowsing techniques uses a single horizontal rod with a vertical handle as a mechanical amplifier to highlight small hand-movements. Hugo had made up a version of this with twin sensors to record the deviation either side of straight-ahead (the dowsing ‘signal’); he then fed this in real-time into a laptop which also had a GPS card to record position. A button on the dowsing-rod handle could also be used to trigger a GPS ‘waypoint’ marker to record specific key points of interest. With this array, he was then able to map the signal – again in real-time, if required – onto Google Earth, as a direct trace of response. A simple grey-scale indicated response-intensity, using a mid-grey as neutral, with white and black as the two extremes. The demonstrator video showed a clear mapping of below-surface structures on an archaeological site. Given the increasing use of dowsing in archaeology as a rapid non-destructive survey technique, this looks to be a really useful addendum to that toolkit – especially as this approach enables us to do away with the cumbersome stick-and-string survey-grid typical of many site-surveys, and also allows arbitrary granularity of search. Interesting.

Somewhat earlier I’d had a lengthy conversation with an engineer (whose name I forgot to record, much to my chagrin) about Stafford Beer’s Viable System Model – one of the cornerstones of systems-theory in organisations, that I reworked into a whole-of-enterprise ‘viable services model’ for my book The Service-Oriented Enterprise. This guy had done his Masters degree with Raul Espejo – Stafford Beer’s right-hand man on the Cybersyn whole-of-nation information-system in Chile in the 1970s – so was able to tell me a lot more about that ground-breaking work on organisational complexity.

Finally, an excellent conversation with an architect (Elizabeth Phillips or Catharine Fortlage, I think?) about physical architecture supporting organisational architecture, and the need to link the organisational silos or ‘tribes’:

Design the floor-plan to be like a wandering path through the jungle; each tribe has its own patch, its own personal space, yet there are shared ‘watering-holes’ – neutral spaces owned by everyone and no-one – where anyone from any tribe may meet any other.

This reminded me of some work we did a few years ago with state-police in Australia, where our brief from the executive was to create a metaphoric ‘totem pole’ to “unify the tribes” within the police-force itself. That conversation pointed me to the burolandschaft (literally ‘office-landscape’) movement of the 1950s; then to a really useful 1993 article – “A Vision of the New Workplace” – on the impact of management-theories such as Business Process Reengineering on office-design; and thence to ‘Origins of the Office’, another useful resource on working environments, office paradigms and interplay between management-theory and workspace, embedded in a website by architects Caruso St John for the Arts Council of Britain.

The moral of this story? Innovation and ideas can arise from anywhere, and the most useful ones often arise from unexpected places. As Louis Pasteur once put it, “in the field of research, chance favours the prepared mind”; if we only allow ideas to come from the expected places, we’re limiting our chances!

Nielsen’s ‘Alertbox’ post on ‘Social Networking on Intranets‘ summarises his team’s extensive research on how so-called ‘social software’ is actually applied within real-world enterprises. Perhaps the most important point that comes out of that research is that McAfee’s definition of ‘Enterprise 2.0′ is either flat-out wrong, or too misleading to be usable in practice. McAfee, and, of course, all the vendors on McAfee’s ‘social software’ bandwagon, assert that the tools should be the centre of all attention; but as Nielsen demonstrates, the tools are actually almost peripheral [emphasis as in the original post]:

People instinctively latch onto specifics to illustrate broad concepts. With Web 2.0 ['Enterprise 2.0' in this context], the specifics are the tools. … But in truth, social software isn’t really about the tools. It’s about what the tools let users do and the business problems the tools address.

A uniform finding across all of our case studies is that organizations are successful with social media and collaboration technologies only when the tools are designed to solve an identified business need. … Although picking the tool to support the need sounds obvious, it runs contrary to the technology fetishism that characterizes much talk about the latest Internet fads.

So, rather than saying: “[tool] X is hot on the Web, let’s get it on the intranet,” say: “We need to accomplish Y; can X help us?”

In other words, the focus must always be on the business needs and the human issues – not on the tools. (Hence the importance of business-architecture and a true ‘architecture of the enterprise’, to identify business needs and existing business capabilities.) And Nielsen also warns that:

An old lesson that holds true with social software is that a bunch of stand-alone tools will provide a disconnected user experience, causing employees to waste inordinate amounts of time moving between environments. For more than a decade, we’ve talked about the need for a unified intranet user experience, consistent design, and features organized around humans rather than technology. All still true.

The other key issue is communication within the enterprise, in the broadest sense of both those terms [again, emphasis as in the original]:

Widespread use of internal social media breaks down communication barriers. That sounds good, but it can threaten people accustomed to having a monopoly on information and communication. Ironically, corporate communications departments sometimes resist the move to broader communication. They’re better served, however, in finding ways to increase the value of new media rather than in trying to suppress it.

Corporate communications must adapt to social media’s real-time culture and become much more proactive than in the past. Procedures that required days or weeks for approvals need dramatic streamlining, or the story will run away on its own. Yet again, business and organizational change is what it’s about, not just the “2.0″ tools themselves.

Nielsen’s research also indicates that behind communication – or lack of it – lies corporate culture, hence a few interesting warnings about the dangers of ‘control’:

Before implementing intranet collaboration tools, you must consider company culture. If people are strongly committed to the “knowledge is power” tenet and don’t want to share, then sharing technologies will obviously fail.

It can be unnerving for traditionalist executives to see employees freely discussing company strategies. But loosening control of information on the intranet is a way to control a much bigger risk: that employees will spill the beans on Internet-wide social media. When people have internal media at their disposal, they’ll post their questions and comments there, as opposed to going outside.

And finally, a reminder that, perhaps unlike what happens on the Internet, changes in the corporation must be allowed to take their own time:

When you consider that successful adaptation of Enterprise 2.0 tools requires the organization to change its ways, it becomes clear why these projects don’t happen overnight. Yes, pilot implementations can go live in a matter of days, but the political and cultural changes needed for useful and widespread use take longer.

Although there’s no single answer, across our case studies, 3–5 years seems to be a common timeline for social intranet projects. This is a good time to remind you of the French general: when told that it would take a hundred years for newly planted trees to grow big, he said, “better get started now.”

If you want to know more about how ‘social software’ really works in a real-world context, go read the whole post: very strongly recommended.

• Visio 2003 stencil for function-models: shapes for Function/Activity, Business System and Dependency
• Visio 2003 template for the stencil, creating a default base-document
• Word 2003 instructions-document (an edited extract from the Services book)

More detail at http://tetradianbooks.com/2009/01/services-model/ , if you need it.

Share and enjoy?

What is Business Architecture? What does a Business Architecture Framework look like?

I think of Business Architecture as a subset of Enterprise Architecture that describes the business from the Strategy down to the enterprise business models (process, data, business rules, etc.). Business parts of the Zachman Framework? Thoughts? Comments?

My response was as follows:

I’d agree that Business Architecture is a subset of Enterprise Architecture, as long as you don’t fall for the TOGAF-style trap of thinking that enterprise-architecture is only about IT!

Business-architecture proper is the strategy layer (Zachman row-2 and upward, also bridging down into row-3).

The jumbled mess of what’s otherwise called ‘business architecture’ only exists because TOGAF and the other IT-centric ‘EA’ frameworks essentially used the term as a generic dumping-ground for ‘everything not-IT’. Instead, think of the remainder of what TOGAF calls ‘business architecture’ as two distinct layers: the logical or integration layer – the equivalent of TOGAF’s ‘Information Systems Architecture’, Zachman row-3 to row-4 – and the physical or implementation layer – the equivalent of TOGAF’s Technology / Infrastructure Architecture, Zachman row-4 to row-5.

Zachman’s structure of layers still works fairly well for this – the only essential change is an extra ‘row-zero’ for compatibility with the Vision layer of ISO-9000:2000. But it does need some serious rework on the columns: for a start, there’s an entire dimension missing, to handle distinctions between physical assets (things), virtual assets (data etc), relational (what your CRM is all about!), aspirational assets (morale and the like), and abstract (such as the financials that your business people do want in their models!); the same for locations (physical, virtual, relational etc) and so on. Still a month or a so away from finishing my book on this, “Bridging the Silos”, but see the ‘Framework’ chapters in the current draft at http://tetradianbooks.com/2008/04/silos/ .

One point that Zachman did get right, but most of the EA-toolset vendors seem to have forgotten, is the key distinction between primitives and composites. As Zachman says, architecture is about primitives (TOGAF’s ‘Architecture Building Blocks’, or ‘ABBs’), whilst solutions come from composites or patterns (TOGAF’s ‘Solution Building Blocks’, or ‘SBBs’). The Zachman Framework is a taxonomy of primitives – root-level entities, some of them fairly abstract; composites are structured collections of primitives that straddle the columns, making up patterns for re-use.

Composites are usable to the extent that they’re architecturally ‘complete’ – i.e. straddle all of the columns – but are re-usable to the extent that they’re incomplete: for example, a BPMN process-model says nothing about ‘Where’ or ‘Why’, so can be re-used in different locations and (in principle) for different purposes. At the mid-layer of the framework, you need to be able to describe a process in abstract terms, to identify KPIs and CSFs and so on; you’d define different SLAs as you go down towards different implementations – manual, machine, IT, etc, but they should all use the same KPIs etc. This is important because if you’re not able to anchor the detail-layer composites into their component sub-composites, all the way down to their root-primitives, you won’t be able to see options for redesign, such as for disaster-recovery or process-reengineering. Think of the classic IT-centric blunder of assuming that every problem must always have an IT-based solution… your only way to avoid that trap is to use a non-IT-centric framework that covers the true whole-of-enterprise space.

Over the past few years I’ve done quite a bit of work on a ‘service oriented enterprise’ framework, based on the classic Stafford Beer ‘Viable System Model’ – see the Wikipedia summary at http://en.wikipedia.org/wiki/Viable_System_Model . We extended this at Australia Post and elsewhere to include support for quality-systems, security-management and so on. Again, there’s still some way to go, and the book is probably at least six months away, but there’s a summary in my article on the service-oriented enterprise in the current itSMF “IT Service Management Global Best Practices” book (see http://www.vanharen.net ) and in my presentation to the TOGAF Glasgow conference back in April (see PDF at http://www.tetradian.com/download/togaf_ea-soe_apr08_FV.pdf ).

Her first question was on business-architecture tools:

Which tools are in the Business Architect’s toolkit?

to which I replied as follows:

If you come from an IT-centric architecture background, the first need is to realise that the standard EA view of business-architecture is a mess – it’s essentially a random grab-bag of ‘everything not-IT’. So you need first need to sort it into the business equivalents of TOGAF or FEAF’s three layers, such as:

• strategy and policy (real meaning of TOGAF’s ‘Business Architecture’ – Zachman row-3 and above)
• tactics and system design (equivalent of ‘Information-systems Architecture’ – Zachman row-3 to row-4)
• process implementation (equivalent of ‘Technology Architecture’ – Zachman row-4 to row-5 [and, in past tense, row-6])

For the strategy layer, one obvious tool is BRG / OMG’s Business Motivation Model [PDF]. It has some flaws – particularly its dangerous mishandling of ‘Vision’ – but it’s a good starting-point. Several EA toolsets implement the BMM, though sometimes under different names: for example, IBM/Telelogic System Architect calls it the ‘Enterprise Direction’ model.

For the middle systems-layer, to be honest, I don’t know: we’ve been doing a lot towards modelling that space – see my book “Real Enterprise Architecture: beyond IT to the whole enterprise”, at http://tetradianbooks.com/2008/04/real-ea/ and the current draft of “Bridging the Silos: enterprise-architecture for IT-architects”, at http://tetradianbooks.com/2008/04/silos/ – but there’s still a fair way to go yet. Troux‘s ‘Metis Enterprise Architecture Framework’ covers [covered? it may not still exist...] a lot of the space, but as usual ends up being too IT-centric for real business-architecture use. Even so, Troux is probably the best bet at present: in my experience, to be blunt, most of the other well-known EA toolsets are so obsessively IT-centric that for business-architecture they often seem more of a hindrance than a help.

At the process level, there are plenty of tools and models available, many of which are not inherently IT-centric, such as all the IDEF and TQM and Six Sigma toolkits. Some IT-centric tools can be re-used in a non-IT-centric way, too: you can use BPMN for implementation-layer business-architecture modelling, for example, once you realise that the Process entity doesn’t care how it’s implemented unless you really need to translate across to BPEL; and the ‘Data Object’ entity doesn’t need to be data, but can actually be any type of asset – physical, virtual, relational or whatever.

Another tool I’ve found invaluable for understanding complexity in business-architecture, and the boundaries between what can and can’t be handled by IT, is Cynefin – see the Wikipedia summary at http://en.wikipedia.org/wiki/Cynefin , also Snowden, D & Boone, M “A Leader’s Framework for Decision Making” Harvard Business Review November 2007.