So let’s put these questions into practice.

Several people have asked me for a detailed worked-example of the sensemaking-technique of context-space mapping [CSM]. Recently, though, I’ve also ‘enjoyed’ yet another attack from Dave Snowden, in which he made two key assertions:

• that the cross-map process used in CSM is not a ‘mash-up’ but a “hash-up”
• that the entirety of CSM and, by inference, all of the other sensemaking tools and techniques that I’ve developed for enterprise-architecture and related fields are “invalid … in certain essential aspects”

He gave no evidence or reason as to why the cross-map process is supposedly so invalid as to be a “hash-up”, or any details as to what any of those purported “certain essential aspects” might be: so in essence, all we have from him is a circular ‘proof’, that it must be ‘true’ because he asserts that it’s ‘true’. This is a classic form of unprincipled-attack, one which most of us will face at some time or other in enterprise-architecture and the like.

His assertion is that CSM has no value; yet since that assertion itself has no rational basis, there’s likewise little point in trying to use any kind of rational defence. Probably the only meaningful response is ‘proof-of-the-pudding’, to demonstrate in practice that it does have value. And if it does have value – in other words, that it presents insights that had not previously been available, and might not have been available by any other technique – then, in turn, that should demonstrate that the attack does not have merit. We probably wouldn’t expect the attacker to understand this point: but it may help in our relations with others, in a more professional context.

So perhaps I ought to thank Snowden here, because he’s indicated the obvious candidate for this practical demonstration: what I’ll do here is apply context-space mapping to Snowden’s Cynefin framework.

And let you be the judge as to whether this cross-map technique has any practical value.

(This will, again, be long – my apologies…)

[Important point: for reasons that have been documented all too often on this website, I have had to invoke Bob Sutton's No Asshole Rule: Snowden is welcome to reply in his own website, but will not be allowed to reply here.]

The Cynefin framework

I won’t describe the Cynefin framework in detail here: it’s summarised on its Wikipedia page, but for the full details you’ll need to go to Snowden’s Cognitive Edge website.

(What follows is based on my own background and experience as a ‘registered Cynefin Practitioner’. I did the training-course, delivered by Dave in person, way back in 2003, when Cynefin was still part of IBM – in fact I was told that my colleague and I were the first non-IBMers to do that course. I still have all of the training-material from the course, and not much seems to have changed since then: a few key elements have been dropped – such as the ‘connection-pyramids’ devised by Cynthia Kurtz – but the only significant new element seems to be the ‘Sensemaker‘ software, a simplified adaptation of a public-domain US Government project.)

Cynefin is ‘sold’ as a sensemaking framework. The key idea is that, given an unknown context (the domain of ‘Disorder’), there are four distinct ‘ways of knowing’ that we can apply to that context, and hence four distinct types of tactics that we can then use, as summarised in the Cynefin graphic from the Wikipedia page:

Each of these ‘domains’ has obvious implications for enterprise-architectures and the like:

• we want to keep things simple, and apply best-practice wherever it’s appropriate
• many things we deal with are complicated, requiring good practice and depth-analysis to bring it under control
• when things get complex – such as in business-model development, or the inevitable wicked-problems of a social context – we need iteration and the like to explore the emergent context
• almost every business will face novel or unique elements within their context, and may struggle to avoid it becoming chaotic

So yes, it’s clear that Cynefin sensemaking should be of real value in EA.

There are a couple of other key elements to Cynefin: its theoretical base, and the interdomain ‘dynamics’.

The explicit formal base for Cynefin is ‘complexity science‘: Snowden is emphatic on this point. However, within Cynefin’s own terms, there are two important corollaries from this:

• the effective primary focus for Cynefin sensemaking is the Complex domain
• the focus on science (as opposed to a technology-oriented approach) will naturally pull the emphasis and methods of validation into the Complicated (analytic) domain rather than the Complex (emergent) domain

This implies that there’s an inherent methodological mismatch here, right at the heart of Cynefin. It’s a mismatch that, you may note, is made visible here via a recursive use of Cynefin sensemaking on itself – recursion being a true emergent-technique, yet not a ‘scientific’ one.

[I'll admit that I don't know the science behind the assertion that there are always and only these four decision-making domains: I believe it originally comes from Boisot. To be blunt, though, I'm beginning to doubt there is any fundamental science behind that partitioning of the 'Disorder' space: instead, as with most 'non-exact' sciences, it may ultimately come back to a combination of pragmatics and personal opinion. Useful, yes; but not necessarily 'the truth'.]

The interdomain dynamics are less well-known: it’s possible they may only appear in some of the earlier papers and in the training-course material, and may now be strictly proprietary to the Cynefin brand. In essence, they describe the tactics that we would use to move ‘between’ the decisionmaking domains. In some cases, it may seem that the context forces us to use specific tactics – which in effect also forces us ‘into’ a different domain, where other ‘rules’ than those we expect may now apply.

[For a non-proprietary equivalent of these 'interdomain-dynamics', from a significantly different yet comparable context, see the 'disciplines reference-sheet' that accompanies the book Disciplines of Dowsing.]

Because they may now be proprietary, I won’t go into any detail on the ‘official’ Cynefin-dynamics. Yet there are two ‘moves’ that are described in the earlier publicly-available papers that are especially relevant for EA, that relate to how we should ‘act, sense, respond’ in the Chaotic domain:

• take control (aka ‘the dictator’s move’), to force us into the Simple domain
• find a pattern, to move us into the Complex (emergent) domain

Within those research-papers, these are the only moves (i.e. ‘act’ in ‘act, sense, respond’) prescribed for the Chaotic domain: so in essence, the only decision-choices described in Cynefin for the Chaotic domain consist of getting the heck out of there. (The same can be seen in the much more recent HBR paper: the only examples given for the Chaotic domain can be paraphrased as either ‘take control’ [go to Simple] or ‘set up a crisis-team’ [go to Complex].) Which isn’t exactly helpful advice for when we do have to deal with the reality of uniqueness – which happens a lot in business, and just about everywhere else. We need something that can handle uniqueness as it is – which Cynefin explicitly does not give us.

There’s another worrying implication from those two moves. One of the moves – ‘take control’ – takes us back to an overly simplistic rule-based view of the context, which in real-world conditions will inevitably fall back into the Chaotic again. In other words, it’s not going to be viable. So the only ‘permitted’ move that will seem to be viable is to grab hold of something that seems a pattern, and move to the Complex domain of ‘probe / sense / respond’ – which, strangely enough, happens to be the preferred realm and focus for all usage of Cynefin. Yet Cynefin’s internal focus on the ‘science’ aspects of ‘complexity science’ will in turn tend to drag us into the Complicated domain of ‘sense / analyse / respond’, or even the Simple ‘sense / categorise / respond’ – otherwise known in the business context as ‘hard-systems thinking’ and/or Taylorism respectively, which we know are problematic for any real-world enterprise-architecture. Yet Snowden himself affirms that point, if in a somewhat misleading way, in this diagram from his online seminar on sense-making and complexity-theory:

Concept Lifecycles (© Dave Snowden / Cognitive Edge 2010)

Hence in effect Cynefin here may purport to take us to the Complex domain, but in practice seems to offer us only the choice of ‘take control’, which rarely works well; or a slightly more sophisticated form of ‘take control’, which also doesn’t work well. That’s not good… at the very least, it means that we need to be careful as to how we use Cynefin in EA practice, and constrain its natural tendency to force us to where we least need to be.

A final key concern revolves around whether the Cynefin frame can be used as a categorization-framework. Snowden has asserted here and elsewhere that Cynefin should never be used that way - and he frequently rails against anyone who might seem to do so. Yet oddly, that’s exactly how he himself often seems to use it: for example, the much-cited HBR paper ‘A Leader’s Framework for Decision-Making‘ [PDF] consists almost entirely of a set of descriptions of what happens ‘within’ each of the domains – in other words, a categorisation of contexts. There’s an inconsistency here of which we need to take note – it is important, as we’ll see later.

Context-space mapping

Context-space mapping is another sensemaking framework (or technique, rather) that, like Cynefin, focusses or relies on emergence. Yet it’s fundamentally different from Cynefin in its nature, approach and theoretical basis – which causes some confusion, perhaps especially for Cynefin practitioners. In terms of the SCCC categories:

• Cynefin is a Complex-domain technique with a fallback to Complicated or even to Simple
• CSM is a Chaotic-domain technique with a fallback to Complex

Cynefin’s explicit fallback is from ‘unorder’ into the ‘order’-domains (‘science’); CSM’s fallback is to the other ‘unorder’ domain (Chaotic to Complex). Unlike Cynefin, CSM always remains in the value-oriented ‘unorder’ domains.

[One corollary from that last point is that because CSM resides in the 'unorder'-domains, attempting to use 'order'-domain methods of validation does not make sense. Validation of the technique must always be in value-based terms: in other words, whether it is useful, not whether or not it is 'true' within the terms of some arbitrarily-selected system of 'order'.]

Even more confusing to Cynefin practitioners is the fact that CSM may legitimately use ideas and images and concepts from Cynefin, or any other source at all, in ways that could or would indeed be described as “illegitimate” if the process made any claim to ‘be’ Cynefin or the like – which it doesn’t.

[Therein lie some significant paradigm-problems, which I'd suggest are the real source for a vast amount of flak hurled in my direction by Snowden over the past few years. Oh well. I'll come back to the paradigm-problem later, anyway.]

First, before the demonstration proper, a few key points about how CSM actually works.

As with all sensemaking, the aim is to make sense of what’s going on in some specific context. (When we start off, the bounds of that context may not be very specific at all: perhaps just some vague idea or focus. Just call it ‘the context’ for now.)

By definition, we always start out on this journey because we don’t know something. This space of inherent-unknownness – prior to any sensemaking – is what Cynefin describes as ‘Disorder’, and what I sometimes prefer to describe as ‘Reality Department’. It’s why we do sensemaking: we want to make sense of something in the context that at present doesn’t ‘make sense’.

Some people might want to split that context straight away into ‘problem-space’ versus ‘solution-space’; but enterprise-architects especially will know well the dangers of jumping into ‘solution-space’ too early. So for now, we’ll leave it unpartitioned, and just call ‘context-space’.

A common response to anything unknown is make a map: pick up any fragments of information that we can, and see what they show us. In Cynefin terms, we could perhaps say that this moves us from Disorder into the Chaotic domain. What we need to be careful about, of course, is the old adage that “the map is not the territory”.

In terms of the Cynefin-dynamics, as above, we have two options in the Chaotic domain: ‘take control’ or ‘find a pattern’. This is a key point of divergence between Cynefin and CSM: Cynefin takes the first option, whilst CSM applies an inverse variant of the second option.

As often practised – and certainly as described in the HBR paper - the core Cynefin Framework is not a Complex-domain technique. (Whatever Snowden may claim to the contrary, the Cynefin-dynamics themselves make that point patently clear.) It is a Simple-domain technique, because it ’takes control’: it overlays its map onto the ‘territory’ of the context, and then declares that the map is the territory – or perhaps ‘the only true map’ of the territory, ‘true’ because it’s ‘based in science’ and the like.

At this surface-only level – again, typified by the HBR paper – this makes Cynefin very easy to use and to explain, and to train people in the relatively-rudimentary sensemaking that’s available through a Simple structure of categories, each of whose sub-descriptions have purported ‘truth’-relationships to each other. Commercially speaking, that simplicity is obviously a very desirable trait: but just how valid or usable the end-results would be is a very different question.

Of course it’s true that most of the deeper techniques used by experienced Cynefin practitioners – ‘butterfly-stamping’, ‘clustering’ and the like – are indeed rooted in the Complex domain: but that’s not what most people see or use. Instead, what most people see is just that Simple predefined set of categories and sub-categories – which leads directly to the over-Simple categories-only mistake about which Snowden rightly bewails.

Context-space mapping takes the opposite approach. We first accept the Chaos for what it is – we accept that we don’t know what’s going on. In keeping with the rules of the Chaotic, we throw something else in at random – and then see what happens. We’re not looking for ‘facts’ so much as insights or ideas, something we can use. We play with that for a while, seeing what ideas and images and patterns seem to emerge in relation to those insights – in other words, we move into what Cynefin calls the Complex domain. And whenever a thread seems to peter out, or ceases to be interesting, or whatever, we deliberately drop back into the randomness again. In that sense, context-space mapping is a Chaotic/Complex-domain technique.

In effect, what we do in context-space mapping is run the usual map-making process backwards. In conventional mapping, we pick on some element in the context that can be fixed in some way, either in absolute terms, or relative to some other point; we then keep repeating that process until we come to some usable description that can be described as ‘true’ in some sense or other. By contrast, in context-space mapping, we pick an arbitrary map, and place it into the Chaos of the context to see what coalesces around around that shape. It’s intentionally anarchic: in most cases, any map will do.

A useful metaphor here is that the context-space map acts as a ‘seed’ for crystallisation, with the ‘unknown’ of the Disorder space providing a kind supersaturated solution from within which new ideas and insights can coalesce. And we don’t necessarily expect that what arises will or must align itself to the map: in fact what we’re looking for most often is whatever doesn’t align. And to help that along, we will often deliberately create mismatch – ‘cognitive dissonance’ – in these throw-away ‘true’-only-for-a given-value-of-’true’ temporary maps that we use for this purpose.

The catch is that this kind of technique is highly dependent on skill and experience. It’s not predefined: everything depends on the choices that are made by the person doing the mapping. It’s not science - it’s technology.

[There's a radical difference there that many people miss. In a science the focus should always be on 'truth', on 'how it really works'; whereas in technology the focus is much more on 'value', on usefulness, on 'how it can be worked' - or perhaps even more on 'how it can be worked better'.]

That’s the bad news. The good news is that that’s exactly the kind of skills and experience that people in enterprise-architecture and suchlike do aim to develop over time – hence context-space mapping is a natural fit to EA, whereas a single-function framework like Cynefin tends to be very limited in its usefulness for our needs.

So let’s develop a real example.

Context-space mapping with Cynefin on Cynefin

What we’re going to do here is develop a context-space map that can explore the role and usefulness of Cynefin in sensemaking for the type of business-contexts that are the typical concern for enterprise-architecture, business-architecture and the like.

In context-space mapping, we typically start with some kind of diagram that we use as a ‘base-map’. In essence, as above, any map will do: there are vast numbers of different diagrams and model-types in use in enterprise-architecture and business-architecture and so on, and we could choose any one that, in the moment, seems to fit with our needs for a ‘throwaway’ context-map. (For example, the Enterprise Canvas model-type initially arose from a cross-map between Business Model Canvas, BPMN, Zachman and Viable System Model.) Since we’re talking here about Cynefin, the obvious choice is the Cynefin diagram itself – hence we’ll use the basic layout and categories of Cynefin as the base-map for this exercise.

We could just stick with that for a while, perhaps using that Cynefin base-map recursively to explore itself – applying Cynefin to Cynefin. That’s a form of context-space mapping in its own right – in fact that’s the means via which I derived many of the insights about Cynefin above.

More usually, though, we would overlay other models on top of that base-map, creating a cross-map that incorporates and contrasts often dissonant ideas. For this exercise we’ll use four distinct overlays.

[Note again that there's no 'science' to this choice - or rather, this is as per science as practised, as opposed to the cleaned-up, seemingly-logical but often somewhat spurious 'science-as-presented-for-public-consumption'. The focus for each choice of base-map and overlay is always on usefulness, driven by an intent to elicit meaningful insights - exactly as per the 'Idea' and 'Hypothesis' stages in the classic 'Idea / Hypothesis / Theory / Law' cycle in scientific discovery.]

The first overlay actually comes from Cynefin itself: the concept of ‘order’ versus ‘unorder’. In Cynefin, ‘order’ is usually described as applying primarily to the Simple and Complicated domains, whereas ‘unorder’ (a very useful term invented by Cynthia Kurtz) applies primarily to the Complex and Chaotic domains. Conceptually, order and unorder also align well with notions of ‘truth’ versus ‘value’ respectively. We’ll apply this as a spectrum horizontally across that Cynefin base-map.

For the second overlay we’ll use something that doesn’t seem to be addressed in Cynefin as such: the timescale in which we have to respond to events. (Cynefin tells as that we should ‘act, sense, respond’, etc, but doesn’t tell us how fast we need to do so.) For reasons that will become clear later, we’ll apply this as a spectrum vertically across that Cynefin base-map, from real-time at the bottom to infinity at the top.

The third overlay is about skill-levels and decision-drivers – see the Sidewise posts ‘10, 100, 1000, 10000‘ and ‘Where have all the good skills gone?‘ for more on this. This gives us the following mapping, cross-mapped to the four Cynefin-making domains:

• trainee (>10hrs): rule-based decisions [Simple]
• apprentice (>100hrs): algorithm and experiment [Complicated]
• journeyman (>1000hrs): guidelines and patterns [Complex]
• master (>10000hrs): principles [Chaotic]

The final overlay, about levels of abstraction, or, conversely, repeatability, will need a bit more explanation. The closest analogy is the four states or ‘phases’ of matter: solid, liquid, gas, plasma. There’s a spectrum of variability, of constraints, yet with explicit ‘phase-boundaries’ between them: entities in a solid are fully bounded, in liquid can move around within distinct bounds, in a gas are essentially unbounded, and in a plasma the boundaries of the entities themselves break down. In terms of how the constraints and boundaries operate, we could map those four ‘phases’ of matter onto the same terms as used for the Cynefin domains: Simple, Complicated, Complex, Chaotic.

There’s a spectrum there too, with explicit boundaries: but we can’t do a simple straight-line overlay onto the base-map as we did with the other two spectrum-overlays. Instead, we have to kind of bend it round to make it fit. And yet, when we look the end-result – the cross-map – it does all fit together well:

This gives us a map that we can now use to elicit ideas and suggestions about the context – which in this case is the Cynefin framework itself.

[Before we start that exploration, though, we need to emphasise one essential point: this is not Cynefin. It's not a 'non-standard version of Cynefin', nor a 'new version of Cynefin', nor actually 'an extension of Cynefin', and nor is it 'an illegitimate use of Cynefin', either. It's a context-space map that happens to use some aspects of the standard Cynefin diagram as its base-map - and that's all that it is. And it's laid out in this way because it happens to be useful to lay it out in this way: there's no claim whatsoever that that's somehow 'the truth' - which, by the way, also means that it doesn't make sense to declare that it's 'not the truth', either.

Since some people may still have missed this point, I'll say it again, louder: this is not Cynefin - it's a context-space map. They're not the same thing: don't get confused here.

Okay? Let's move on.]

What comes up for you when you look at that diagram? (“A mess”, some people might say? – fair enough, but bear with me for a moment, if you would?)

What comes up for you when you compare that diagram with the ‘official’ Cynefin diagram, earlier above?

The first and most obvious point is that they’re not the same. Good: that means there’s the potential for cognitive-dissonance there. That’s the whole point: that’s what we want – because it’s from that dissonance that ideas and images and cross-comparisons are most likely to arise.

I don’t know what comes up for you when you compare and explore those two diagrams: that’s up to you, that’s your sensemaking, not mine. We’re dealing with subjective ‘truth’ here, not a purported ‘objective’ ‘the truth’: what makes sense for you is what makes sense for you – and it may not make sense in that way to anyone else at all. In a quite literal sense, it’s none of my business.

But here are some of the things that I see when I do that cross-comparison. I’ll describe them in relation to each of those overlays, though not in quite the same order as above.

[Note again that this is merely what I happen to see - what 'makes sense to me', and so on. None of it purports to be 'the truth': it's only about insights that arise, nothing more than that. The difference here is, unlike with Snowden's unsupported assertion that this technique has no value, here you can see all of the steps via which I arrive at each insight. What we then might do in response to each insight is a different matter, of course.]

The order versus disorder overlay would probably be the least controversial for Cynefin aficionados: it’s in the original description, even if it’s rarely shown on the diagram as such. The mapping with ‘truth’ versus ‘value’ is useful, because it suggests that IT-systems and other processes that depend on a simple ‘true/false’ logic are inherently going to have trouble in the Complex and Chaotic domains – which is exactly what we see in real-world practice.

There’s also another way to interpret the Cynefin description of context-space (which doesn’t contradict the ‘official’ version, by the way). This is that if the ‘Disorder’ domain is, in effect, the whole of a context before we make any decisions about it, then the other four ‘decision-making’ domains can also be seen as the valid way to act on that aspect of the whole: every context will include some proportion for which we can use the Simple tactics ‘sense, categorise, respond’, another proportion where we’d have to use the Complicated tactics, and so on. Every context will contain some Simple, some Complicated, some Complex, and some Chaotic. In which case, any attempt to use, for the whole of a context, a system that can only work on ‘order’, on simple true/false logic, by definition it’s going to fail in Complex and Chaotic ways. Which again is exactly what we see in practice with disaster-areas such as IT-based ‘business-process reengineering’ and many of the ‘business-rules engines’ and the like. The visual simplicity of standard-Cynefin can be very useful here as a tool to help hammer home this harsh fact to the overly-IT-obsessed.

Note, by the way, that the graphic layout is significant here: we probably wouldn’t have been able to elicit these insights without using that specific layout. One up for the Cynefin domain-layout, then – even though it wasn’t designed to be used this way.

Next, let’s look at the abstraction/repeatability overlay, and cross-compare it with the skills-type/decision-guide overlay. These do map cleanly together: we can use rules in domains of high-repeatability, and we can use ‘trainee’ skill-levels to do that type of work – and so on for the other domains. (Yes, the domains are used here as categories: but that’s exactly how the domains are used and described in the Snowden/Boone HBR article.)

We now cross-compare this with the ‘domain-tactics’ from the original Cynefin diagram: ‘sense, categorize, respond’, and so on. This gives us the following table:

• trainee: rule-based decisions; sense, categorize, respond [Simple]
• apprentice: algorithm and experiment; sense, analyze, respond [Complicated]
• journeyman: guidelines and patterns; probe, sense, respond [Complex]
• master: principles; act, sense, respond [Chaotic]

Which for the most part again does make sense: a trainee would sense what’s going on, make a decision based on predefined categories, and respond in accordance with the respective rule. By contrast, someone with apprentice-level skills should start to be able to analyse what’s going on, and identify and act on the respective factors for the required algorithm. The journeyman skill-level fits well, too; yet for me there’s an odd sense that the master skill-level isn’t quite right. Come back to that later.

But there are a couple of booby-traps that aren’t obvious in standard-Cynefin. In fact one of them isn’t even that obvious here: that people often find rules Complex, and guidelines Simple – the opposite way round to this mapping. (There’s more on that in the post ‘A human view of Simple, Complicated and Complex‘.) So in a sense this mapping is ‘wrong’, and could perhaps lead us to seriously-wrong decisions in real-world practice – if we were working primarily with real-people in that context. If we think more in terms of that ‘truth/value’ spectrum, and therefore assign machines and IT-systems to do the Simple and the Complicated, reserving the Complex and the Chaotic for real-people, then the mapping actually is ‘correct’. Remember, though, that ‘right’ or ‘wrong’ really don’t make sense here: the only valid distinction is ‘useful’ versus ‘not-useful’.

The other booby-trap is potentially even more serious in the longer-term, and relates to skills-development in the context. To make sense of it, though, we also need a better grasp of the impact of timescale – hence we’d better turn to that first, and come back to the skills-problem later.

The cross-map with timescale is perhaps the most important of all, because it highlights what is to me a fundamental flaw in standard-Cynefin: its handling of inherent-uniqueness. Or more accurately, its lack of any usable means to handle uniqueness.

Remember that, in essence, Cynefin’s stated method of handling the Chaotic is to ‘get the heck out of there’. Snowden himself has said many times that we’re never in the Chaotic domain as such: instead, he’s said, we should always grab hold of some piece of information and try to make sense of it with some kind of pattern or rule – which would automatically move us into the Complex or Simple domain respectively.

In practice, though, this doesn’t make sense – unless, that is, we happen to use the term ‘Chaotic’ in a circularly-defined way that also doesn’t make sense in terms of real-world practice.

Where does that insight about standard-Cynefin’s paucity in the Chaotic-domain come from? Answer: it’s derived directly from that cross-map between the Cynefin domains and the timescale.

The timescale stretches from real-time (which we’ve placed against the base of the Chaotic and Simple domains) to infinity (which we’ve placed against the top of the Complex and Complicated domains). If we think about it for a moment, that mapping does make sense: one of the classic dangers of decisionmaking in the Complicated domain is ‘analysis-paralysis’ going on to infinity, and much the same happens too with experimentation – ‘probe, sense, respond’ – in the Complex domain. Going the other way, towards real-time, the practical point is that it takes time to do analysis and experimentation: so the closer we get to real-time, the more we’re forced out of the Complex and Complicated, and into the Chaotic and Simple. Yet Cynefin insists that the Chaotic domain doesn’t actually exist, or at least that we can’t do anything there: which means that – according to Cynefin – as time gets more and more compressed, the only possible option is that we go back to the Simple, where everything is strictly rule-based. Which isn’t what happens in the real-world. Oops…

What actually happens in the real-world is that we have analysts (Complicated) and experimenters (Complex) who need time to do their work – which is why we usually find them in the back-room, or somewhere ‘upstairs’, well away from the real-time pressures of the ‘front line’. Down at the front-line, we usually have rule-based systems (Simple), that may be IT, human or machine – it doesn’t matter that much here, that’s just an implementation-detail. And we also have people – usually not machines – with high skill-levels, who deal with the ‘exceptions’ and other uniquenesses and inherent-uncertainties that the rule-based systems can’t handle. That’s the Chaotic domain, as far as anyone in business is concerned. But that’s the domain that Cynefin insists doesn’t exist, or that no-one stays there for anything more the briefest instant: yet the reality is that that Chaotic domain is where anyone with ‘master’-type skills and experience will spend most of their time.

That Cynefin provides no means whatsoever to address this sensemaking-need in the Chaotic-domain, within that domain’s own terms, is problematic enough. Worse, though, Snowden’s required methods for use of Cynefin actively prevent us from addressing that need, because they insist that we shouldn’t be there when, plainly, we not only are there, but need to be there and stay there. We can’t ‘run away’: staying in the Chaotic-domain is what sensemaking in that real-time, often-inherently-unique business-context will demand. Hence I’m sorry, but that aspect of Cynefin is just plain daft.

[There's a real challenge for Cynefin to prove its value here: and, from the above, I don't think it can do so. There's no escaping the fact that, as it stands, Cynefin explicitly makes itself neither useful nor usable for any part of this sensemaking-domain - in fact for the entirety of what is probably the most important domain for business-sensemaking. But that's not my problem, fortunately, so best leave it at that for now.]

Anyway, back to that booby-trap around skills-development and the relationship to timescale. Almost every business will face relentless pressure to shorten turnround times, product-development times, any kind of time-period: in other words, a constant push to compress down towards real-time. The cross-map between timescale and the Cynefin base-map shows us what will happen if – or more likely when – we push that process too far: the Complicated and Complex domains – analysis and experimentation – slowly get squeezed out of the picture, until there’s nothing left. And yes, the business probably can keep going for a while – as long as nothing changes. Even then, the pressures and lack of analytic or emergent backup will cause more and more exceptions, creating more and more overload in the Chaotic, until it finally collapses in a literally-chaotic heap. In other words, that cross-map not only shows us that excessive time-compression is a guaranteed way to kill the business, but also shows us exactly how and why it will happen – and hence the warning-signs to watch for, in case the risk gets too high. That’s a very important point that comes straight out from this cross-map.

If we now add to this picture the cross-map to the skills-development sequence – trainee, apprentice, journeyman, master – we can now highlight the real longer-term booby-trap. Remember that in that time-compression we squeeze out the Complicated and Complex domains. In doing so, we also squeeze out the support for the Apprentice and Journeyman stages of skills-development. The result is that we risk creating a context staffed by people with Master-level skills – doing all the Chaotic-domain work – and people with Trainee-level skills – doing all the Simple work – and no means to develop the trainees’ skills to become the next generations of masters. (There’s more detail on this in the Sidewise post ’Where have all the good skills gone?‘) This is a huge kurtosis-risk for almost any organisation – and yet very few people seem to have acknowledged even its existence, let alone just how serious it really is. So again, this is another very important point that comes straight out of the cross-map.

Finally, there are some disturbing intimations of potential for misuse. These arise from specific points in the cross-maps above:

• Cynefin purports to be a Complex-domain technique, and hence explicitly aims to address true complexity and unorder
• its purported base is in complexity-science, which tends to place it more naturally within the order-domains (particularly the Complicated domain)
• certain key aspects of Cynefin techniques – such as category-selection for filtering in Sensemaker – by definition derive from value-based decision-making (unorder), yet still purport to be ‘scientific’ (order)
• the purported ‘scientific’ base tends to give a spurious sense of ‘fact’ or ‘truth’ (order) in contexts which, by definition, are actually value-based (unorder), subject to arbitrary personal interpretation – a point not acknowledged at all in the basic Cynefin-framework diagram, and barely hinted at in public presentations such as the HBR paper
• most people see only the Cynefin diagram and other base-level categories and cross-maps, which would naturally place it within the Simple domain – yet it purports to be about sensemaking in the Complex domain

Other related concerns not covered in cross-maps above include the way in which the statistical modelling within the SenseMaker tool can give an illusion of working with uniqueness – ‘outliers’ – yet without actually working with the Chaotic-domain in its own terms, as ‘act / sense / respond’ in real-time. In effect, such use of Sensemaker veers dangerously close to ‘Complex masquerading as Chaotic’ – which is not helpful to anyone.

If we put that together with those other points above, which – as we’ve seen earlier – tend towards ‘Complicated masquerading as Complex’, or even ‘Simple masquerading as Complex’, what we’re left with is a framework whose domain-boundaries and discipline-boundaries are almost too blurred and confused to make much sense to anyone, other than perhaps its original creator. And that blurriness of the boundaries also means that many (most?) of the standard checks on safety, professional-discipline, ethics and the like are either unusable, actively blocked or entirely absent – in other words, it’s inherently wide-open for misunderstanding or misuse.

And it’s clear that such misuse could be both unintentional and, unfortunately, intentional. Given Cynefin’s current structure and presentation (as in the HBR paper), it’s all too easy to present something as ‘true’, and then jump around between domains to avoid any challenge. As it stands – to be blunt – the framework is structured in such a way as to make it all but perfect for (mis)use by a consultant who wanted to pander to the fears of worried executives, and provide them with spurious ‘evidence’ that they’re ‘in control’ of something that, by definition, cannot be controlled. To say the least, that’s not good, for anyone: and yet at present that temptation is built right into the very fabric of the framework…

One of the easiest ways in which such misuse can occur is if the framework is presented as a Simple categorisation: hence, I presume, one very good reason why Snowden is so adamant against anyone using the framework in that way – and I do applaud him for that. It’s true that that overall ‘blurriness’ can be helpful, in that it does enable some undoubtedly-useful workarounds in practice; but it also means that usage of the framework needs much more active ‘policing’ than would otherwise need to be the case – and whilst Snowden may be willing to take on that task at present, that inherent fragility means that it will always be an uphill struggle, always somewhat fraught. And behind it all, there still remain those serious ethics-risks – arising from the structure itself – that cannot and must not be ignored.

A difference in paradigm

I suspect that much if not most of the ongoing unpleasantness around Cynefin and context-space mapping has arisen from a clash of paradigms.

Snowden is explicit that he places himself within the scientific tradition, the domain of ‘provable truth’.

I don’t. Almost all of my work is in the technological tradition, the domain of ‘proof by usefulness’. Where the scientific tradition would focus solely on ‘truth’, the primary driver here is effectiveness – which I usually summarise via the keywords efficient, reliable, elegant, appropriate, integrated.

The unorder-domains do have their own ‘truth’ – but it’s a fundamentally-different type of ‘truth’ to that which applies in the order-domains. In fact, each of the SCCC domains has its own distinct form of ‘truth’. And the key point here – too easily missed by too many people, it seems – is that these different types of ‘truth’ don’t mix. For example, I’ll freely admit that some aspects of CSM do have significant similarities with something as ‘unscientific’ as a deck of Tarot cards, because we choose images that are ‘information-rich’, to allow appropriate insights to arise from the ‘chaos’ of intentional cognitive-dissonance. The point is simply this: it works – and the fact that it’s supposedly ‘unscientific’ doesn’t matter in the slightest in this context. (Yes, it might well matter in other contexts, but that’s the point: it’s context-dependent.) We know the conditions under which it works, and which it doesn’t – in other words, it’s a technology. In this particular case, it’s a known, proven technology for working with uniqueness in the Chaotic-domain, where, by definition, no ‘science’-based model is going to work.

But the problem I’ve had, time and time again, from Snowden and other ‘science’-oriented folks, is that they’ve attempted either to apply ‘scientific’ forms of validation – which, by definition, does not and cannot make sense – or else, as in this example, they’ve fallen back to various forms of unprincipled-attack. Neither of these type of tactics are helpful, to anyone. What is needed is solid, rigorous challenge in technological terms – without getting lost in spurious non-’science’.

My real focus here is meta-methodology – the methods and methodologies for developing methods and methodologies. To be blunt, I’m still not sure that Snowden understands the difference: in fact many of his attacks over the years only make sense if in fact he doesn’t understand that point. If one can’t tell the difference between a framework such as Cynefin, versus a metametaframework such as context-space mapping, then clearly nothing much is going to make sense. Either way, the difference in paradigms is enough to cause serious friction in itself: but in practice, all we should need do is take note of that fact, respect that the paradigms are indeed different, and move on.

A practical summary

Okay, I know it’s been long, but I hope it’s been worth it: in any case, thanks for sticking with it this far. All we have to do now is wrap this up, and then we’re done.

The wrap-up is really simple, consisting of just one question: in reading this, did you gain any insights about Cynefin, or about context-space mapping, that you didn’t have before?

If you gained no insights at all – no new information, no new thoughts about how to use either of those two tools or techniques, or anything else – then Snowden has a fair point: context-space mapping is of little value to you.

But if you did gain any insights, of any kind – perhaps not even about either of these two tools – then context-space mapping does have value, for you at least.

Yet you and your experience here are the judge of this: the only judge. The only ‘truth’ here is yours.

Perhaps let me know your results in this?

Thanks again, anyway.

[One urgent point first: this is not about Cynefin. I'm not going there: don't worry. It's in the title only because I thought that if you're a Cynefin practitioner, and you don't already know Inayatullah's 'Causal Layered Analysis', you may well want to add it to your complexity-toolbox. If so, the SCCC categorisation (Simple, Complicated, Complex, Chaotic) may help you to hook that technique into what you already do. That's it: you can ignore everything else here. Just a friendly Public Service Announcement for you, that's all. ]

As you may have noticed, I’ve been doing a lot of thinking lately about ‘the wrongs of rights‘, and why I think they’re seriously problematic at every scale of an enterprise-architecture.

On Causal Layered Analysis

What came up this morning was a thought that Causal Layered Analysis [CLA] might be a useful tool for ‘the rights problem’. CLA was originally developed by Sohail Inayatullah around a decade ago, and has since expanded into a sizeable body of theory and practice, especially in the futures-domain. For more detail on the practical technique and the ideas behind it, see Sohail’s original paper on CLA (as published in Futures, October 1998) and the Wikipedia article. Here’s the introduction to the paper:

Causal layered analysis is offered as a new futures research method. Its utility is not in predicting the future but in creating transformative spaces for the creation of alternative futures. Causal layered analysis consists of four levels: the litany, social causes, discourse/worldview and myth/metaphor. The challenge is to conduct research that moves up and down these layers of analysis and thus is inclusive of different ways of knowing.

The way that CLA works in practice is indicated by the paper’s subtitle, ’poststructuralism as method’: we apply academic-style ‘deconstruction’ (from linguistic-analysis etc) at each those four layers, or four ‘ways of knowing’, moving up and down the layers to elicit more information and experiences about and views on the overall context.

[Before reading any further here, I'd strongly suggest having a wander through those various materials on CLA - not least because without doing so, much of what follows may not make much sense. ]

The view within ‘the litany’ tends to be a bit simplistic, a very polarised, rule-based and often Other-oriented view of the world – “they should”, “they shouldn’t be allowed to…” and so on - a relentless ‘litany of complaint’. The ‘social causes’ view tends to be a bit more nuanced, more aware of real-world complications; the ‘discourse/worldview’ more complex again; and… Well, you can see where where this is headed, because it obviously suggests a crossmap with the SCCC categorisation of ‘ways of knowing’:

Which is kind of interesting. And which suggests a whole stream of other potentially-useful crossmaps.

[Cynefin practitioners might want to stop reading at this point, because everything onward from here is an exercise in context-space mapping - a different technique. Some of it may look familiar at times, but I should emphasise that it's not 'legitimate Cynefin'. (Probably not 'legitimate CLA' either, but I doubt Sohail would mind as much.)]

Context-space mapping with domains of Causal Layered Analysis

To extend this context-space mapping [CSM], we can identify distinct ‘phase-boundaries’ between the domains in this ‘stack’, such as:

And we can also crossmap those domains with other views – for example, a Jungian-derived set of categories that align well with the CLA set, the set of sensemaking/decisionmaking tactics from the Cynefin framework, and another matching set of decision-drivers:

• ‘the litany’ : Simple : inner-truth (‘Priest’) : “sense, categorise, respond” : rule-based
• ‘social causes’ : Complicated : outer-truth (‘Scientist’) : “sense, analyse, respond” : algorithms
• ‘discourse/worldview’ : Complex : outer-value (Technologist/Magician) : “probe, sense, respond” : experiment, patterns, guidelines
• ‘myth/metaphor’ : Chaotic : inner-value (Artist) : “act, sense, respond” : principles, values

This suggests, for example, that ‘the litany’ would have a strong tendency towards over-certain and over-simplified notions of ‘the Truth’, endless blaming of ‘the Other’ without any form of self-reflection or self-analysis, and knee-jerk responses via over-simple categories, usually predefined by some self-appointed ‘Priest of The Truth’ in an opaque and often literally-unprincipled way. Which might kinda suggest a new verb, ‘to murdoch’, as in ‘to murdoch the truth’? (for which the shorthand might be ‘Fox News’? )

[I'm not saying that's 'the truth', by the way: that would itself be an overly-Simple view. Context-space mapping is more a Chaotic-domain technique, a way to elicit ideas that may be of value in a given context, but they may also not be of value in that context. That's the whole key to understanding CSM: its usefulness, but also its risk, is that it depends on having the skills and experience to determine what is or is not of potential value in a context. Please do take care, because misplaced notions about 'true' or 'not-true' can be disastrously misleading here.]

This crossmap also conflicts quite a bit with the standard Cynefin description of the Chaotic domain that kind-of implies the Chaotic is somewhere we’d usually need to get away from as quickly as possible. The CLA mapping here suggests instead that the Chaotic is a valid and important domain in its own right – somewhere that might well be challenging at a deep personal level, but also where we might want to stay and explore for a while, until the depths get a bit too much and we need to come back elsewhere for air. But notice that in context-space mapping, that kind of apparent-conflict is perfectly okay: both views are ‘true’, the concern is more about which view is useful for a given purpose.

Anyway, at present, this is still a single-axis ‘vertical stack’; yet that last crossmap suggests it’s also a kind of two-axis matrix. To resolve that, we can twist the ‘stack’ into a Cynefin-like layout, with a central ‘the-everything’ domain to remind us that both perspectives are ‘true’:

Which is interesting in itself – for me, at least, because it brings up more ideas about how and where and in what contexts to use CLA, and when to switch between the different types of deconstruction that apply in the respective CLA layers.

Causal Layered Analysis, time-compression and social stress

Previous experience with this type of context-space map also suggests another crossmap-overlay, in this case another vertical axis of timescale, from real-time at the base to infinity at the top:

Which for me is a bit of an eye-opener, with important implications for CLA. The point is that any sensemaking and decisionmaking in the Complex or Complicated domains – ‘discourse/worldview’ or analysis of ‘social causes’ – will take time: a fact that will be painfully obvious to anyone who works in those domains. So as the available time gets squeezed – whether because we’re moving towards real-time anyway, or because of social-panic and similar pressures – we end up being forced more and more into the sensemaking/decisionmaking spaces of the Simple and the Chaotic: otherwise known as CP Snow’s ‘Two Cultures‘, the classic worldviews of the sciences and the arts respectively. (We might also note, using CLA recursively, that the assertions of their respective paradigms become more and more extreme as we move towards real-time.)

What this also suggests is that when a culture is under stress, it will automatically tend towards this kind of ‘Two Cultures’ dichotomy between ‘Truth’ (Simple) versus ‘Value’ (Chaotic) - which, yes, is a dichotomy that itself often becomes over-Simple. The ‘Truth’-meme will tend to dismiss anything ‘not-True’ as ‘anarchic’, but its inherently constrained set of categories will, almost by definition, never be sufficient to deal with inherent-uncertainty: hence the kind of ‘collapse into chaos’ described in the Cynefin model. On the other side, the ‘Value’-meme is – again almost by definition – seemingly unlikely to generate any kind of stable categorisation via which a Simple-domain mode can make sense.

What we see in practice is that as the social stress increases and the links between people fragment, those Simple categories of shared ‘inner-truths’ – “what is True for we” - tend to separate out into self-specific ‘inner-truths’ – “what is True for me‘. This also leads a loss of awareness of the necessary mutuality of responsibilities that underpins all social constructs such as ‘rights’, such that ‘our rights’ becomes reframed solely in terms of ‘my rights’: “we hold these truths to be self-evident” morphs into a self-centred demand to the Other to “hold my truths to be self-evident”, and so on.

And without shared-categories, any social structure based on a Simple ‘sense / categorise / respond’ will by definition start to break down. The usual result is a spiralling descent into an out-of-control litany of complaint, first to ‘What’s in it for me?’, then ‘Me first!’, to a fully self-centred ‘Me-only!’, and eventually a truly chaotic cacophony of ’Me! Me! Me!’ – otherwise known as ‘kiddies’-anarchy’. In a very literal sense, the Simple inherently becomes chaotic. And there doesn’t seem to be any direct ‘truth’-based path back from there, other than via some forceful imposition of rule and rules: either the ‘dictator’s gambit’ or, in rarer cases, the ‘Truth of the Prophet’.

Yet from the opposite side of the ‘truth/value’ dichotomy, what does seem to work is a re-focus on ‘inner-value’, on deep-principles and, especially, deep-myth. It has a surface appearance of the Chaotic, but actually develops its own simplicity: a functional and, often, highly-disciplined form of anarchy, rather than a dysfunctional one. Given that sensemaking/decision-making pattern of ‘act / sense / respond’, the very act of expression often means that whatever arises automatically takes on a social form.

Again, from practical experience, these context-specific images seem to act as ‘seeds’ around which directed action can coalesce – much as would happen in a more usual move into the Complex-domain, except that the time-pressures or social-context pressures mean that it actually remains within the ‘pressure-cooker’ of the Chaotic. The more that the focus can be held in this mode of the Chaotic-domain, te more ideas can be created – and the more the emphasis is held on the decision-making guides of the respective principles and values, the more likely it is that these ideas and images will be experienced as ‘of value’ within that context. The ways in which directed-action can coalesce around these ‘seeds’ can sometimes – perhaps often – lead to enough of a structure to enable a Simple-type ‘sense / categorise / respond’ mode of decisionmaking: in other words, something that is more generally actionable than a highly-personal ‘inner-value’. Which, in turn, can provide enough of an anchor for a more balanced and principles-guided way out of the crisis – a ‘values‘-based way back to ‘truth’.

To summarise this in much shorter form, what this suggests is that the key people in a major social crisis are the artists and the storytellers. The military-commanders and managers and the priests – the ‘truth-holders’ who maintain order – may come to the fore before the collapse, or after the recovery has started: but in the midst of the crisis it is those who normally live close to Chaos to whom the baton must be passed.

A practical summary

Cross-mapping Causal Layered Analysis with the SCCC-categorisation and the ‘now’-to-’infinity’ timescale can deliver some useful insights about how to address high-stress social contexts – such as the kind of ‘mess’ that our entire global economics seems likely to be heading into at present. The main points I see arising from the cross-map include:

• Causal Layered Analysis in likely to be a useful technique in whole-enterprise architecture
• time-compression (reduced time for decisionmaking, often combined with high-contextual stress) is likely to squeeze sensemaking-decisionmaking into a tight dichotomy between Simple and Chaotic SCCC-domains
• Simple delivers consistency under high social-stress, up to a critical collapse-point, and the Chaotic appears to be a potentially-dangerous distraction
• under very high social-stress, Simple tends to collapse into dysfunctional-chaos, whereas Chaotic is usually able to regenerate sufficient basis for rule-structures that restabilise the Simple
• use CLA in the Simple domain (‘the litany’) to identify risk of collapse: the risk increases with increasing social-fragmentation from ‘we’ to ‘me’
• use CLA in the Chaotic-domain (‘myth/metaphor’) to identify and support principles and values that can guide directed action during the peak of the crisis

Some points specific to whole-enterprise architectures:

• identify Chaotic-domain ‘natives’ (people who naturally work at the CLA ‘deep-myth/metaphor’ layer) such as design-thinkers, artists and, especially, story-tellers within the shared-enterprise
• work with these people to identify and express key principles and values within the shared-enterprise that would be viewed as ‘normative’ – i.e. a ‘preferred direction’
  [warning: these principles and values must be allowed to emerge from the collective shared-space, and must be respected as such - they will fail if imposed, or even appear to be imposed, from 'outside']
• ensure that the usual ‘truth-holders’ are aware of and accept that there is a critical point at which they must let go of ‘control’, must allow the Chaotic domain to be what it is, must relinquish authority to the ‘story-tellers’, and must accept and renegotiate with the ‘new order’ that arises out of the ‘guided-chaos’
  [warning: refusal to follow this long-proven success-pattern, or attempts to 'take control' too early in the transit through the Chaotic-domain, will guarantee failure for everyone concerned, including the 'truth-holders']

In effect, this is a method to define a governance-process for use in contexts where a conventional rule-based approach to governance will naturally break down – an interesting architectural recursion!

Anyway, enough for now: over to you for comments/suggestions etc?

In Australian parlance, that type of magnificently-misleading ‘wrong answer’ is known as ‘the toad in the road’.

Every ‘trade’ has its toads, in some form or another. In the case of enterprise-architecture, given our necessarily very broad scope, we do seem to have rather a lot of them. Oh well.

It’s a toad. It sits there, blocking the way. In reality, it’s not actually that big, but it somehow demands our attention, making it difficult to deal with anything else. But we can’t just drive over it, stomp on it, squash it into a literally bloody pulp: I know that some people would do that, but it does have its own right to live, after all. Yet we do need to be careful: some toads are downright toxic. And, it’s well, kinda, yuck… no-one seems very willing to pick it up and put it politely out of the way… Oh joys…

Yeah: that kind of problem.

So how do we deal with ‘the toad in the road’?

It’s different in every case, of course.

Some of the toads in our space are really no problem: they’re just in the wrong place, that’s all. Some of them are positively genial, the kind of toad that, if it had a hat, would doff that hat with a broad smile and an offer to share a slightly-chewed slug. Like all toads, of course, they’re stubborn and they’ll stand their ground, which isn’t exactly helpful when they’re in the middle of the driveway and we need to get moving for the day; but they’re usually quite cooperative as long as we’re respectful about how we shoo them back under the strawberries instead.

Roger Sessions‘ IT-oriented version of ‘complexity’ is one such toad: it’s fine for IT, but for enterprise-architecture it’s an over-extension of ‘order’ into a realm of inherent ‘unorder’, and it really doesn’t work. Likewise John Zachman‘s notion of ‘engineering the enterprise’: it would make sense if an enterprise was an aircraft, which, however, it isn’t. Oops. In both cases, it’s definitely “right idea, wrong place”; and yes, we do all kinda know it. Sure, there will always be arguments about the positioning of that kind of toad: but people like Roger and John are unfailingly courteous and polite, so much so that it’s always a pleasure to disagree with them yet again.  It’s just a kind of game we play from time to time, and we all know it’s a game – sort of how a toad would really like it if the driveway would turn itself into a strawberry-patch because that’s what they know best, and it’s somehow our fault that it isn’t.

There are other kinds of toad that are somewhat similar, but they often seem a bit brainless, so it’s lot harder to negotiate with them. The real problem is that there’s just so many of the darn things: they turn up everywhere, all crawling over each other beneath our carefully-tended bushes and shrubs, digging around for worms and grubs, and generally making a right old mess of everything in the process. Their all-pervasive slime and stench is… well, let’s just say we wouldn’t call it pleasant? – and they don’t really help in any way in the garden.

At present, the dominant toad of that type in our space is IT-centrism, though there are signs that a relatively-new species of business-centrism is beginning to move into our enterprise-architecture garden as well. Perhaps we shouldn’t mind so much, but it’s difficult to get any rest with the constant croaks of “Cloud! Cloud!” and the like… Sigh… Unfortunately, it is hard keep them out of the garden – and if we do somehow succeed in doing so, we’d probably block out all the friendly toads as well, which would be a real loss. Other than the mess that they make, though, these toads are fairly harmless, and there’s probably not much we can do anyway until they get the other side of their current breeding-frenzy (otherwise known as ‘sales-hype’ and ‘certification’). In the meantime, we just need to be careful where we tread, and keep on tidying up the mess as best we can.

There are a few types of toad that we really don’t want in the garden – in fact we need to apply considerable care to keep them out of the entire metaphoric country. These are the cane-toads of a trade – so poisonous that they’ll kill off just about everything in sight, just by their mere presence. Yikes… The real tragedy of the cane-toad, though, is that often it’s initially thought of as some kind of saviour – as was true of Taylorism in our industry’s case, for example. But the reality is that they’re seriously toxic, in almost every possible way – and that toxic nature soon wipes out any possible value they may have had. Not a good idea…

Some disciplines – social-work, in particular – seem beset by cane-toads on every side; by contrast, we don’t seem to have any at present in enterprise-architecture, which makes us fortunate indeed. There’s some risk that IT-centrism and the like could turn into cane-toads, but they don’t seem to have done so as yet – though they’re certainly enough of a problem for us as it is. Taylorism and its more recent sub-species such as BPR and over-hyped ‘business-rule engines’ have been fairly serious cane-toads for us in the past, but each seem now to have faded back into a more natural niche in the overall enterprise-architecture ecosystem. The existence of cane-toads, though, should warn us to be very careful of what we introduce into the enterprise-architecture garden, and to be wary indeed of the ever-present risk of unintended-consequences.

And there a few types of toad that are kind of in the middle – literally in the middle, too, because often it seems that all they really want to do is get in the way. In some cases there may only be one individual of a species in our garden: but like the brainless toad, it somehow manages always to be right in the middle of where need to be – and it won’t budge. At all. Unless it can do so in order to get in our way again… It’s perhaps not as toxic as the cane-toad, but it’s definitely in the wrong place – yet will not respond to any kind of reason, or any request to move on. It just sits there, puffing itself up like a bullfrog, making lots of noise, demanding our attention, and generally acting like it’s the only thing that could matter to anything or anyone in any way. It could perhaps be of use elsewhere in the garden: but since it won’t move there, we never really get much of a chance to find out. What it somehow never manages to accept is that in reality it’s nothing special – it’s just another toad. That’s all. A toad in the road: another darn nuisance that we could really do without…

For enterprise-architecture, IT-centrism has been a bit like that, though it is getting somewhat more amenable these days. All the hype around Cloud is getting to be a bit too much of a toad-in-the-road these days, too. But for me at least, by far the worst toad of this type is Cynefin. It seems we can’t ever talk about complexity without Cynefin insisting on getting in our way. We struggle to talk about even the simple or the complicated without accidentally invoking its unwanted presence. We can’t talk about uniqueness or inherent uncertainty – the business sense of ‘the chaotic‘ – without Cynefin demanding that it alone knows the truth about that space – when in reality it has nothing useful to say other than that we shouldn’t be there. Much like IT-centrism, it has perhaps rather too many characteristics of a cult. And whilst in principle it could be useful in enterprise-architecture, we can’t make much use of it in practice, because its promoter endlessly insists on barging into our space, spitting venom at anything he regards as ‘heresy’ - literally, ‘to think different’ in any way from himself.

We’ve all spent too much time hiding in fear from those attacks: I know way too many people – myself included – who’ve had to invoke Bob Sutton’s ‘No Asshole Rule‘ in that person’s direction, too. The bleak reality is that I’ve spent way too much time and effort pandering to his insatiable demands – much like the pointlessness we supposedly ‘must’ go through in order to get round a toad that endlessly insists on putting itself in our way, and then blaming us for the resultant conflict.

After the last attack, though, I took a more careful look at his snarky putdowns, in which he dismissed my work as valueless, a “hash-up”, “invalid in certain essential aspects” – yet notably failing to give any details as to how or why it should be so regarded. Hmm… time to stand up for myself, for once? So I’ve spent the past few days proving, to myself at least, that my work on context-space mapping is of value, by using it to assess Cynefin itself in terms of its usefulness – or lack of usefulness – for our enterprise-architecture discipline.

The results have been, uh, interesting… (I’ll publish it here if anyone wants, though I’d warn that it’s kinda long even by my standards…) It certainly confirms that, in present form, Cynefin is indeed likely to be useful in the Complex domain; but it’s of questionable value in any other domain, and inherently worse than useless for anything in the Chaotic domain. Another interesting point was that, despite its promoter endlessly railing at anyone who dares to use Cynefin as a categorisation-framework, that’s exactly how he himself uses it in ‘his’ much-publicised HBR paper [PDF]. And that analysis also highlights some nagging suspicions that the base-level Cynefin Framework is actually a Simple-domain technique that’s merely masquerading as a Complex-domain tool – which would be neither helpful nor wise.

Perhaps the most disturbing point, though, is what came up from a more detailed cross-comparison from the context-space map. That’s that the simplified version of Cynefin that’s all that most people see, and the way in which it uses its purported theoretical base in complexity-science, make it an almost perfect tool for (mis)use by any consultant who wants to pander to the fears of worried executives, and provide them with spurious ‘evidence’ that they’re ‘in control’ of something that, by definition, cannot be controlled. That’s not good – doing that would be seriously dishonest, so surely no-one would be so unethical as to do that, would they? And yet that temptation is built right into the very fabric of the framework… worrying indeed…

But the most important point this is this: it’s just another toad. Yes, sure, for our own safety, we might well need a shovel to scoop the wretched thing up: and, despite the strong temptation to use the shovel in another way entirely, we can toss that toad into another discipline’s garden where it might be more at home – and then make darn sure that it doesn’t come back again into ours. That’s probably the best way to deal with that type of toad.

So that’s four types of toad-in-the-road we all have to deal with, perhaps rather more often than we’d like:

• the friendly toad that gets in the way a bit, but is really useful in the right place
• the not-much-use-for-anything toad that gets a bit too much in the way for a while, especially when it’s over-excited
• the darned-dangerous toad that we need to keep out of our space at any cost
• the bloomin’-nuisance toad that we’re best off to toss out of the garden, and keep out as best we can

What’s your experience of ‘the toad in the road’? What are the various types of toad that you have to wrestle with in your own work? And how do you best cope with each?

Comments/experiences/suggestions, anyone?

[Update: A reminder, because a couple of people already seem to have missed this point: in this context, the 'toad' is not a person, it's an idea - "a clear, simple, easy-to-understand wrong answer". For example, the idea of IT-centrism is an example of the second type of 'toad'. This is very important indeed: for example, in no way would I describe either Roger Sessions or John Zachman as 'a toad' (though knowing them both, they might quite like the image above of "doffing a hat with a broad smile and offering to share a slightly-chewed slug"... )]

We now do another sideways move, to explore how we might use a modified version of the classic Zachman framework to assess the content and activities of each entity (or service) in scope.

This also helps to demonstrate some of the real power and value of context-space mapping as an enterprise-architecture technique. We always start the mapping process with a suitable base-map – in this case, the Enterprise Canvas – which we use as a base and common cross-reference for all of the current sequence of sensemaking and model-development.

(There are quite a range of other models we could use as a base-map for context-space mapping, such as the Five Elements frame, the modified-Zachman frame, the Cynefin categorisation [simple, complicated, complex, chaotic, 'disorder'], Nigel Green and Carl Bate’s VPEC-T, Richard Veryard’s Lenscraft, and Sohail Inayatullah’s Causal Layered Analysis; we’ve used the Enterprise Canvas here because it’s the best fit for this type of enterprise-architecture work, but other frames may well fit better for other tasks.)

Given that base-model, we can cross-reference to other model-types to give us further information and further clarification, but always anchored back in the same base such that everything links together in a consistent way. In this case we’ll use a modified version of Zachman that leverages the layering of the Enterprise Canvas, and that also covers a broader scope than Zachman’s usual IT-specific examples.

The single-row extended-Zachman frame

Classic Zachman consists of a grid with six columns and five rows. The set of columns have been assigned various labels at various times, but in essence are What, How, Where, Who, When and Why. The five rows represent layers of abstraction, from the overall business-context down to detailed implementation-plans for real-time action.

The layers or rows of the Enterprise Canvas exactly match the Zachman rows – in fact extend them slightly, with one extra row at top and bottom, to include the unchanging enterprise-vision (row-0), and the also-unchangeable past (row-6).

Because we’ve already included the Zachman rows in the structure of the Enterprise Canvas in this way, we don’t need to use those rows in our use of Zachman here – we already know what Zachman row we’re in, because we know which Canvas row we’re in. That makes things much simpler, because we only need to work with one row at a time. Yet Zachman’s easily-remembered interrogatives of  What / How / Where / Who / When / Why turn out to be surprisingly misleading when we get down into the detail of what’s needed for an enterprise-architecture – so we’ll need to amend the column-headers and contents to resolve that. And it turns out that there’s an entire dimension missing in the original Zachman – a set of segments to describe entity-types and/or decision-types – so we do need to include that here.  Overall, this gives us a simplified yet extended version of Zachman that we can use in conjunction with each row of the Canvas:

Zachman classically splits everything into primitives and composites: a primitive is something that can be defined or described in terms of a single cell, whereas a composite straddles across cells. So pure data, for example, is a primitive, a virtual asset, whereas a book is a physical ‘thing’ that contains information, and hence is a composite physical+virtual asset. A function changes assets, yet can do nothing on its own until combined with a capability (an ability to work on an asset-type at a particular skill-level), a combination that we describe as a ‘service’; a ‘process’ represents a sequence of service-requests; and so on.

(A composite should not be able to straddle Zachman rows, but that doesn’t concern us here, because we’re only working with a single row at a time anyway. Note, though, that a pattern can straddle more than one row: for example, one very common design-pattern in data-architecture is that the abstract [row-3] ‘many-to-many’ data-relationship may be implemented [row-4] as a cross-reference-table.)

At the real-world level (Canvas row-5 ‘immediate-future’ and row-6 ‘past’, straddling either side of the ‘Now’), everything must, by definition, be an ‘architecturally-complete’ composite of “with <asset> do <function> at <location> using <capability> on <event> because <decision>“. One of the main roles of architecture is to apply abstraction (moving ‘up’ the rows towards row-0 ‘Enterprise’) to split the composites apart into smaller composites and primitives, so as to enable reconfiguration and redesign into other, more effective ‘solutions’ for the given context.

Assets are entities for which we are responsible. (Note that this is not the same as ‘resources’. There’s a crucial distinction between ‘possession-based’ versus ‘responsibility-based’ concepts of economics which would take too long to explain here. Conventional economics is based on notions of ‘rights’ of possession, whereas internally a business will operate on responsibilities – for example, a process-owner is the person who is responsible for that process, not the person who ‘possesses’ it. The shortest summary is enterprise-architectures only work when we use a responsibility-based model thoughout, and that in essence ‘resources’ become assets when we take on responsibility for them.) As described in the market-metaphor, asset-types include:

• physical ‘things’
• virtual items such as data and information
• relational links between real people
• aspirational links between people and abstract ideas, represented by brands in one sense, but also by morale, by values, and by the idea of the enterprise itself

An asset may also be represented by any composites between these types. In practice, it’s probable that most real-world entities are composites in this sense: for example, a key point in marketing is creating emotional attachment to objects – in other words, a composite of physical and aspirational.

(Some people would argue that financials are a special-case, another type of primitive. A few moments’ thought, though, would show that financials are actually a composite of virtual and aspirational – information about a belief, where each currency represents a brand that implies ‘rights’ to resources. Architecturally speaking, money isn’t a value, it’s actually a belief about value – and often a very muddled belief at that!  So yes, financials are important, especially in any for-profit organisation: yet over-emphasis on financials is a proven cause of failure in enterprise-architectures, and for our purposes we do need to keep them in their place.)

Functions will use, reference, act on, change and/or return assets, and hence can be described in terms of the same asset-types.

(Note that, architecturally speaking, the function is only one part of ‘how’, a description of what usages or changes will apply to those assets: it doesn’t describe the ‘with-what’ aspect of ‘how’, which is represented by the capability that actually enacts the function. In classic machine-design or functional-programming for IT-systems, function and capability are merged within the machine or the program itself; but in fact it’s an arbitrary constraint, and one that doesn’t apply when processes are enacted by real people, or when we move back to the abstract for process- or service-redesign. Architecturally, it’s important to keep function and capability separate at a conceptual level, and be aware of how and why we merge them in each service-implementation.)

Locations can also be described in terms of the same asset-types: physical locations; virtual locations such as a URL or an IP-address; relational locations, such as displayed in an org-chart; and even aspirational locations, such as relationships between brands; or composites of these types, such as the composite physical+virtual location of a data-server. It’s also best to describe time as a kind of abstract-location: for example, events may occur in time – in other words, may be located in terms of time – but are not actually part of time itself.

Capabilities need to be described both in terms of the asset-types they act on, and the skill-levels or decision-abilities used in that action:

• simple rule-based decisions such as following a predefined step-by-step process or checklist
• more-complicated algorithmic or ‘hard-systems’ capability that still assumes predictable rules but can accommodate many branches, delayed-feedback, damping and the like
• heuristic or ‘soft-systems’ capability, often using guidelines or patterns to interpret emergent contexts with complex inherent uncertainties, such as so-called ‘wicked-problems‘
• principle-based decision-making for contexts that are unique and inherently unpredictable

The asset-type distinctions for capabilities are relatively straightforward, but the distinctions about skill-levels become crucially important in process-design, because physical machines, IT and real people have very different capability-curves. In general:

• physical machines can usually only work on physical assets, and are best-suited to following rule-based decisions
• IT-systems can work on virtual-assets and, via control of physical machinery, physical-assets, using rule-based or algorithmic decisions, but are still limited in capability for pattern-recognition, and in general should not be used for decision-making in inherently-unique contexts
• real-people can work on any types of assets, with varying skill-levels, though in many (most?) cases are notoriously not well-suited to the rigid rule-following and mechanical repetitive-tasks assumed and required in Taylorist ‘scientific management’

Attempts to use the wrong types of systems in a given context will usually lead to ineffectiveness and, in many cases, ‘unexpected’ failure. One all-too-common example in enterprise-architecture is the tendency of IT-evangelists to promote the notion that there is an IT-based solution for every possible problem, and that such IT-based solutions are inherently the ‘best’ option in every case. It’s true that IT may be the most effective option in some cases, but it causes catastrophic failure in others, yet the IT-centrism itself blocks out the information needed to identify why the failure will occur.

(Note too that a capability is embedded in or enacted via some kind of asset: in a machine (physical) or a computer-program, or via a relational-asset to a real person. [It's essential to understand, by the way, that real people should never be described as 'assets', either in an architecture, or anywhere else. This is the whole point about relational-assets: the relationship is the asset, not the person - it's the relationship with the person that creates the access to that person's capabilities. If the relationship is damaged or destroyed, almost all value will be lost, even if the person is physically present.] Zachman’s label for this column – ‘Who’ – sort-of makes sense in relation to real people, but makes no sense at all when the capability is embedded in anything else: this would then force us to merge function and capability together for machines and IT, but not for people, further compounding the architectural errors described above.)

Events are triggers for action, and can again be described in terms of the same asset-types: physical events; information-events, signals and other virtual-events; relational events, such as a phone-call or the arrival of a prospective customer at a store-counter; and even aspirational-events, such as a change of brand, or an event causing damage to morale. As usual, many if not most real-world events will be composites of these types, and for many purposes a broader notion of event as a kind of ‘package’ may be more useful – see the VPEC-T framework for more on this. Note also the point above about time: events occur in time, but are not actually part of time itself.

Decisions represent the ‘why’ or ‘because’ of the enterprise. Decisions are usually built up in layers or hierarchies of dependencies, with the question ‘why?’ moving upwards through the layers, and ‘because’ moving down. (The enterprise-vision is the ultimate ‘Because.‘ of the enterprise: note the period/full-stop, which indicates that the layering of ‘why’ stops here! ) There are many ways we could describe this layering – for example, see the Business Motivation Model [PDF] standard – but probably the most useful categorisation is the same set as for the skill-levels in capabilities: rule-based, algorithmic, heuristic and principle-based. Again, most (and arguably all) real-world contexts require composites of those decision-type categories, as a chain of exception-trapping and escalation: a key point is that any real-world process-design will need to ensure that the ability to make appropriate decisions does indeed exist at each escalation-level in the context, otherwise the overall process is guaranteed to fail on some ‘unexpected’ event.

Using the extended-Zachman frame with the Enterprise Canvas

Fine: but how do we use all of this categorisation and theory – especially with the Enterprise Canvas? What use is it?

The obvious point is that we need all of this to tell us what happens within each entity. It also helps us to distinguish between the cells in the entity (or, to put it the other way round, the cells specialise in different areas of the Zachman frame): the core functions of the entity-as-service take place within the Value-Creation cell; the supplier-side or customer-side Channels deal with the main transaction-events; the Relations cells are especially important for dealing with relational and/or aspirational-assets; and so on.

Another option is that we can use this to tell us which Canvas layer we’re working in at any given point. For example, if we’re dealing with records – in other words the past, the ‘as-was’ – then by definition we’re in row-6. If we’re looking at relationships between entities, we cannot be above row-2; if we’re looking at lists of things, we could be anywhere up to row-1, but if we’re looking at attributes of things, we can’t be above row-3. The moment we mention a specific technology or technique, we’re in row-4 or below. These are all fundamental to architecture-driven redesign, and help to prevent us from treating any prepackaged ‘solution’ as an architectural requirement – unless we choose to do so, of course. The only true architectural requirement is the enterprise-vision and its associated core-values: everything else is just implementation, at varying levels of abstraction.

The relationships between primitives and composites is also important here, because the higher up we go in the layering of the Enterprise Canvas, the more we need to be working with primitives – or at least to understand the primitives that make up the core-composites. Conversely, the closer we get to the real world, the more likely it is that we’ll be dealing with complex composites-of-composites, which we’ll probably need to break down into simpler components in order to enable redesign. If we think of a ‘complete’ composite as straddling all cells in the single-row extended-Zachman frame, and a primitive as the least-’complete’ that we can get, then in essence one of our most important architectural concerns comes down to this:

Things are usable to the extent that they are architecturally ‘complete’;
things are re-usable to the extent that they’re architecturally ‘incomplete’.

To enable new architectural options, we need to be able to split our composites apart. So, as an author, I might think of myself as a writer of books. But a printed book is actually a composite, a ‘bundling’ of information in a specific physical form – and as an author, my actual product is the information, not the physical book. (It would be the other way round for someone who worked in a printing business, of course.) Once I understand that point, it opens up a whole raft of new possibilities, new options to deliver the service represented by that information. For example, I could dispense with the physical book, and present the same content in electronic form, as an e-book. I could split up the content in different ways, perhaps serialised in smaller chunks in an online magazine. I could present it another virtual-medium, via video or voice. Or I could deliver it via a relational-asset channel, otherwise known as in-person consulting.

To make something re-usable, we need to move up the layers of abstraction, splitting apart the implementation-composites to expose the ‘bundling’ that could perhaps be recombined in new ways; and to make something usable, we need to go down the layers, linking each item into more and more ‘complete’ implementation-bundles. At the point where it touches the real world, everything must be architecturally-’complete’. That’s what the layering describes.

The other key point about the extended-Zachman is that it acts as a checklist to make sure that we line things up correctly: for example, that we don’t try to use IT for something for which it’s not well-suited, or which it can’t handle at all. Another example (which should be obvious to everyone, but painful experience indicates that it isn’t…) is that a record of a ‘something’ is not the same as the thing itself. The record is information – a virtual-asset – whereas the thing referred to in the record could be any type of asset at all – a physical object, a data-event, a business-relationship, or whatever. So the moment someone mentions that we have a record of something, we need to look for the matching audit-process or equivalent – such as data-cleansing and de-duplication – that ensures that the records do line up correctly with the respective items: because if that audit-process doesn’t exist, we have an architecture that almost guarantees service-failure.

And we can also use the same checklist-approach to ensure proper coverage for disaster-recovery, business-continuity or just everyday operations. Machines fail, computer-systems fail, power-supplies or network-connections fail, whole buildings can be swept away in a natural or man-made disaster: we may well need ‘manual’ processes to take over at a moment’s notice. Which means that we need that processes to exist, and people with the appropriate skills to do them – and know how to switch over to those ‘manual’-processes, too. All of those are items that we can check by using the extended-Zachman checklists, in a layered way:

• Given the asset-types list, what capabilities are needed to work on them?
• Given the decision-types list, what exceptions will cause a decision to be escalated – all the way up to truly-unique yet business-critical events?
• Does the skill and capability exist to resolve that escalation? Via what means will that capability be delivered?
• How can we design the service-interfaces to be ‘transparent’ to the implementation-method – for example, such that people can take over when an IT system fails, or a machine can take over when people are overloaded?
• What are the trade-offs?
• What are the costs – in any sense of ‘cost’?

That’s where this kind of assessment will help, combining the precision and detail of the extended-Zachman frame with the layering and simplicity of the Enterprise Canvas.

A practical example

To put this into practice, I’ll use the example of the enterprise-model for our own enterprise-architecture business.

For row-0 ‘Enterprise‘, there’s nothing to do. Strictly speaking, we could label everything at this layer as being part of the ‘Why’ or ‘Decisions’ column, but in reality that would make relatively little sense. It’s more useful to think of the enterprise-vision – “enhancing enterprise effectiveness”, in this case – as being more like a backplane that sits behind every subsequent use of the extended-Zachman frame in the other layers, and to which everything should connect.

In row-1 ‘Scope‘, all we should have are lists that point in some way to the enterprise-vision and its values. In an earlier post we identified the probable list of players in this enterprise; here we should use the extended-Zachman to identify other key entities in scope for the enterprise of ‘enhancing enterprise effectiveness’:

• assets: mostly information about new ideas and techniques, with some emphasis on person-to-person relationships to support responsibilities; not many physical ‘things’ involved here
• functions: most of the work is in the ‘validation-services’ group – creating awareness of the need and options for enhancements, developing capabilities to create enhancements, and assessing and reviewing enhancements to overall effectiveness – which could apply to any aspects of enhancing effectiveness in an enterprise
• locations: the work may take place in and/or apply to any type of location
• capabilities (action): activities in scope may be about any type of asset, but the capabilities that are actually used in this enterprise mainly involve assessing, reviewing, consulting and training
• capabilities (skill-levels): skill-levels for assessment, review and consulting generally need to be at the high to very-high levels (pattern-based to principle-based), although implementation of enhanced processes may be at any skill-level down to low (simple rule-based)
• events: the main trigger for these activities will be a perceived need or desire to enhance enterprise effectiveness – the actual source of that trigger may take any form, such as a physical failure, a signal about an out-of-range condition, a person-to-person discussion or concerns about flagging morale
• decisions: most of the sensemaking and decisionmaking in this enterprise tends to address complex and/or unique contexts, requiring pattern-based or principle-based decisions respectively – although effectiveness itself may be supported by decisions all the way down to simple checklists

We’d have to admit that this doesn’t tell us all that much, mainly because this specific enterprise itself has to cover such a wide scope, and much of it is recursive in the sense that it uses techniques to look at techniques, or information to look at information, or decisions about decisions. But we can note, for example, some of the items that are not in scope: not many physical items, for example, or simple- or algorithmic-level skills that could be implemented by IT or machines. There may be a lot of information, but ultimately most of that information is going to have to be assessed by real people.

In row-2 ‘Business‘ we start to look more closely at what our own business has, does and uses – which, by comparing this with the row-1 lists, tells us the extended-Zachman items that we expect to be used or implemented or provided by other players in this enterprise. This forms the basis of the relationships between players, that is the core of this layer. From our perspective, this tells us which groups of players might be likely customers for us, and the relative priorities for each; which groups might be useful suppliers and, again, their relative importance to us; which others provide ‘validation-services’, ‘direction-services’ and/or ‘coordination-services’ to help guide what we do and how we do it; and who our potential investors and beneficiaries might be, and what types of values would be in play overall. That’s quite a lot, so the extended-Zachman assessment definitely starts to become useful here.

For the moment, we’ll do this with our ‘as-is’, and then develop a ‘to-be’ from the comparison with row-1. Note that at this stage, in row-2, we’re only concerned with the broad outline that can be used to identify potential business-relationships:

• assets:
  • physical: computers/office-equipment, library, vehicles etc
  • virtual: books, presentations, websites/domains, research-repository etc
  • relational: wide range of business-/peer-contacts
  • aspirational: clear commitment to enterprise-architectures and effectiveness
  • financial (composite): [not disclosed]
• functions:
  • physical: [usually not relevant]
  • virtual: creation of ‘texts’ (especially methods, methodologies, metamodels etc) and analysis/synthesis of clients’ contexts
  • relational: development of contacts for own organisation and between others
  • aspirational: creation of clarity on clients’ direction (e.g. strategy, tactics, motivation)
  • composite: consultancy for business-change, creation of new methods and tools, creation of customised methods and information-structures
• locations:
  • physical: office-based and mobile
  • virtual: web, email, telephone
  • relational: various peer-networks
  • composite: conferences etc
• capabilities (action): methodology and modelling, idea-development, writing/presenting, analysis/synthesis, consultancy; media including pre-press for book-production; familiarity with IT-development
• capabilities (skill-levels): main skills-base is methodology/modelling, idea-development, writing/presenting and consultancy
• events: triggers for action are mainly direct contact (e.g. leading to discussion and/or consultancy) or new idea
• decisions: most decision-types are complex to unique-context (pattern-based to principle-based)

We can now compare this to the row-1 description for the overall enterprise, to identify what we do not do in the enterprise. Anything we don’t have or don’t do, and that is part of the enterprise, will imply the need for a potential business-relationship – it’s as simple as that.

But what kind of business-relationship? To clarify that, we pick some example-organisations and do a quick row-2 for each as above, and then compare against our own row-2 map. In conventional business-terms:

• anyone who covers some other aspect of the enterprise is a potential supplier
• anyone whose focus is another enterprise but could service a specific need here – e.g. travel – is also a potential supplier
• anyone who has need of the types of services that we offer to the enterprise is a potential customer
• anyone who offers the same types of services that we do is a potential competitor, with the implied ‘threat’ dependent on closeness of match – functions, locations, capabilities, skill-levels etc

For any business-architect, this will be familiar territory: SWOT, Porter Five Forces, Value-Chain Analysis, Business Model Canvas and so on. In the Business Model Canvas, for example, most of the content for the ‘Key Activities’ and ‘Key Resources’ cells would come from the extended-Zachman frame. A key difference here, though, is that the Business Model Canvas is optimised for analysing and developing the business model – for example, in a for-profit organisation, the summary of how that organisation makes its monetary profit – whereas the Enterprise Canvas is more about the operating model, the operation of the organisation and enterprise as a unified whole. (Ross, Weill and Robertson’s justifiably-lauded book “Enterprise Architecture as Strategy” also aims to describe the operating-model, but in practice only from an IT-oriented perspective.)

In row-3 ‘System‘ and row-4 ‘Design‘ we start to get into the kind of fine-detail already familiar to business-architects and enterprise-architects: nothing much new here as such. What is different is the way that we can now link all of this ‘upward’ to the decisions and choices in row-2 and above, and ‘downward’ into the fine-detail of implementation. The key distinction between row-3 and row-4 is level of abstraction: row-3 is always in generic terms, so as soon as we mention a specific technology, a specific location, that fact places us in row-4. Note that although we might describe these under the simple extended-Zachman headings, in practice many more of the items are composites, becoming increasingly-complex composites as we move ‘downward’ towards real-world implementation:

• assets:
  • physical: office-equipment, library, vehicles etc, duplicated in both main bases (Britain and Australia); most computers are portables (laptop, netbook, tablet) configured for on-site use, with a mix of Windows, Macintosh and other operating-systems, using text-development, diagramming, modelling and other software
  • virtual: books and other texts are produced in physical and e-book formats, available via online and book-trade distributors; presentations at conferences and online; websites/domains; research-repository for internal use etc
  • relational: wide range of business-/peer-contacts in Australasia / Asia-Pacific, Europe, North America, Latin America
  • aspirational: clear and public commitment to enterprise-architectures and effectiveness, as describes in articles, presentations etc; established brand-names and reputation
  • financial (composite): [not disclosed], requires accounts/accounting in multiple currencies, with separate tax-liability for each main base
• functions:
  • physical: mostly background-activities, but includes travel, manual shipping of books, manual processes of writing and diagramming etc
  • virtual: creation of ‘texts’ (book, presentation, audio, video etc), especially on methods, methodologies, metamodels etc; also models, metamodels, development-plans and other context-specific consultancy-artefacts for clients
  • relational: development of contacts for own organisation and between others, via in-person [relational+physical], web or phone [relational+virtual] and/or reputation [relational+relational/aspirational]
  • aspirational: creation of clarity on clients’ direction (e.g. strategy, tactics, motivation), using visioning, motivation-models, futures techniques etc
  • composite: consultancy for business-change, creation of new methods and tools (such as context-space mapping, Enterprise Canvas, Five Elements enterprise-architecture, extended-TOGAF, extended-Zachman, whole-of-enterprise service-models, SEMPER diagnostic, etc), creation of customised methods and information-structures
• locations:
  • physical: two main bases (Britain, Australia), otherwise anywhere in the world as required
  • virtual: websites, weblogs, Twitter, LinkedIn, Skype, Slideshare, other trade-specific networks, direct email etc
  • relational: various peer-networks
  • composite: conferences on enterprise-architecture, business-architecture, business-transformation etc
• capabilities (action): methodology and modelling, idea-development, writing/presenting, analysis/synthesis, consultancy; also pre-press for book-production, for in-house only; and some limited IT-development (mainly database, website-code and concept-demonstrator prototypes), also mostly in-house
• capabilities (skill-levels): methodology and modelling up to meta-meta levels; idea-development, writing/presenting and consultancy are main public skills-base; pre-press and IT-development are both low-priority and, for IT especially, probably somewhat out-of-date
• events: triggers for action are mainly in-person contact [relational+physical], online contact [relational+virtual] or new idea [virtual, or virtual+relational for collaborative development]
• decisions: most decision-types for enterprise-architectures, consultancy and methodology-design are complex to unique-context (pattern-based to principle-based)

That’s a fair summary of everything that we have and do as a business. We could now, for example, use the underlying Enterprise Canvas to explore in more depth how each of these assets and functions and the like can be split up in terms of the various emphases of each cell in the Canvas: in the Value-Proposition and Relations cells, to build and maintain the business-relationships, for example; or the Channels and Value-Creation cells in terms of what happens in the various transactions with our suppliers and customers – who in some cases can be the same person or entity, of course.

Or we can use VPEC-T (Values, Policies, Events, Content, Trust) across each of the supplier-side and customer-side transaction-flows, and cross-map the results to the extended-Zachman. The VPEC-T ‘Policies’ lines up with the extended-Zachman decision, ‘Content’ lines up with asset, and ’Events’ obviously lines up with event (though in the VPEC-T specification an ‘Event’ will also always include at least some kind of message or other virtual-content within itself).

And we could also apply a RACI matrix (Responsible, Assists, Consulted, Informed) as a cross-map to the extended-Zachman, to the VPEC-T assessment, or to the Enterprise Canvas and cells for our own organisation and/or for any of our related business-organisations. This would tell us who is responsible for or about each item, and what forms each of their respective responsibilities would take. In our own case this is relatively straightforward, given the small size of our organisation; but in a large organisation these matrices can become very complex indeed. Perhaps more to the point, doing this at various layers and with various cross-maps can help to highlight real concerns about mismatches in responsibilities: often there will be two or more people who have ‘exclusive responsibility’ for the same item at different levels of abstraction, for example; and gaps in responsibility-coverage are also disturbingly common, again especially in large organisations, where boundaries and overlaps often become blurred over time through merger, acquisitions and other forms of organisational restructures.

As you’ll no doubt see by now, there are many other ways we could explore this, and this could go on a lot further – all the way into into the dreaded ‘analysis-paralysis’, if we’re not careful. One of the most important skills here is to know when to stop! But whichever way we do it, the principle remains the same: we start from an appropriate base-map – the Enterprise Canvas, in this case, though we could have chosen one of the others – and then use other model-types to provide further cross-maps, further information, further sensemaking, highlighting all the different dependencies, and all the different options. Everything links back to the base-map: that’s why the balance of simplicity, depth and versatility in the Enterprise Canvas matters so much.

But this article is already way too long, so we’d best stop here for now. In the next article we’ll explore how to use all of this in another way, using another core concept in whole-of-enterprise architecture that enables one of its most valuable traits: the ability to start anywhere.

Up until this point we’ve been working top-down, starting from the most abstract layer, the ‘extended-enterprise’. But we do need to to remember that there’s no reason why we have to work only in this direction, and often many reasons why we should make use of the more freeform approach that context-space mapping will allow. And in the usual serendipitous way – via an article in IndustryWeek, ‘Assessing Product Innovation Assets: What’s in your attic?‘ – we now have a useful reminder that the vision and strategy for an organisation may also be reconstructed bottom-up.

Low-cost innovation doesn’t have to be boring or incremental. Sometimes true innovation is as easy (and inexpensive) as evaluating the technologies and capabilities you currently have and expanding them to a new industry or customer base. It is a particularly powerful product innovation strategy during an economic downturn, yet too few companies today are taking advantage of it.

[An] important message for business leaders: “Use something you already own to generate income in a whole new way.” Truly innovative and resourceful manufacturers can embrace this message by reevaluating their existing assets, intellectual property, and product lines to develop completely new streams of revenue with little investment. The assets are already in their “corporate attics.” All a company has to do is unlock the revenue-generating power of those assets.

So let’s use the examples from that article – and a couple of others – to see how this works, in terms of context-space mapping and the Enterprise Canvas.

The examples we’ll use are Swatch, Mars M&M customisation, Oceaneering animatronics, Play-Doh and Nokia. (The middle three examples are from the IndustryWeek article – the respective quotes appear below.) In each case we’ll assess the context and the trigger for change; the relationship between the new market and the old; the role of and impact on technology; and the impact on enterprise-vision, echoing back down through the organisation itself.

For Swatch the trigger for urgent change was the shift in watchmaking from fine mechanical-engineering to digital displays and thence to digital movements. By the late 1970s the Swiss watchmaking industry – with a long tradition of unsurpassed engineering excellence but at high price, even in the mid-range – had been decimated by Japanese competition. The only apparent market that remained was for luxury craftsman-watches, and even that seemed under threat. In the early 1980s Nicolas Hayek combined business-restructure, technological innovation and radically different marketing to reframe the Swiss watch-industry – most of it under the new ‘Swatch’ brand – and reclaim its previous preeminent position.

The market for the new type of watch was actually a new ‘Blue Ocean‘ niche, presenting a new concept of the watch as a low-cost, almost transitory fashion-statement, where the notion of ‘the watch’ is linked less to the raw function of timekeeping than to the statement about self. In effect, this is actually closer in concept to the ‘luxury’ end of the market – both markets are more about the joy of time and relationship to time, rather than time itself.

New technology included the use of plastics and ultrasonic welding, and an almost Taylorist approach to manufacturing and reduction of number of components. This experience was also carefully echoed back into the ‘old’ Swiss-watch industry, retaining its ‘craftsman’ focus but combined with lessons-learned from bulk-manufacture.

The marketing for each of the sub-markets is different, yet interestingly the enterprise remains the same, if anything becomes more explicit, as something like “expressing the joy of time”.

Mars has had the technology to write “M&Ms” on little candies without smudging for decades. Recently, it created a multimillion dollar business using the same machine to let people write customized messages on their M&Ms.

As described in this BusinessWeek article, the trigger for what is now MyM&Ms was an idea from within Mars’ ‘Advanced R&D’ unit – not the marketing department.

The new market (promotions, special events) is significantly different from the regular market for M&Ms (retail candies/sweets), but leverages strongly from the main market in that the underlying product is well-known – in fact the ‘unique selling-proposition’ largely depends on the idea that this is a special personalised version of something that is not new.

The technology is actually much the same as in the main market: real-time labelling of mass-produced product. The main difference is that the new version of the labelling-technology permits mass-customisation. The market would not exist without this mass-customisation technology.

The core enterprise is significantly different from that of the main Mars company: although the enterprises are related, the focus here is on the customisation rather than on the underlying product (a point emphasised by the fact that Mars are also starting to provide mass-customisation of others of their products). The Mars website describes core-principles but no explicit vision-descriptor; it’s notable, though, that MyM&Ms is marketed through its own distinct website. The probable enterprise-descriptor for MyM&Ms would be something like “celebrating who we are”, compared to a probable main-organisation enterprise of something like “the enjoyment of small moments in the everyday”.

Oceaneering once only applied its hydraulic technology to deepwater remote operated vehicles and other oilfield related products – that is until the company met with some Hollywood executives who wanted to use the technology to power large dinosaurs for Jurassic Park. Revenues from the entertainment industry now make up over 15% of Oceaneering’s top line.

As described above, the trigger for the new market appears to have been a chance meeting, or a cross-connection made by someone within the entertainment/animatronics industry rather than by the company itself.

Functionally, the new market is very similar to the old, namely highly-specialised engineering applications for hydraulic technologies and control-systems. The main difference (as with their space-engineering applications) is that the application itself is outside of their main area of expertise in marine and underwater systems for oilfields, and hence will require much closer collaboration with the end-client.

The technology is essentially the same as in their main market – if anything, is actually simpler, or at least for use in less-extreme physical environments.

The enterprise can remain unchanged as long as the focus is on the activity (i.e. engineering) rather than on the purpose or application of that activity (oilfields or animatronics or space any of their other ‘advanced technologies’ areas).  Unfortunately their ‘About’ page includes a ‘Mission Statement’ that is an almost perfect example of what to not do in an enterprise-descriptor (“Oceaneering’s mission is to increase the net wealth of its shareholders by providing safe, cost-effective, and quality-based technical solutions satisfying customer needs worldwide”), and it seems clear that the emphasis of identity is very clearly on the main application (“Oceaneering is a global oilfield provider of engineered services and products primarily to the offshore oil and gas industry, with a focus on deepwater applications”), and the animatronics section does not even rate a mention anywhere in that description (“Through the use of its applied technology expertise, Oceaneering also serves the defense and aerospace industries.”) Despite the Industryweek reference, and the apparently sizeable contribution to corporate income, the animatronics application appears to be a poor fit with Oceaneering’s current identity: if that is the case, it should almost certainly be split off as a separate-but-linked enterprise, much as with the relationship between MyM&Ms and the parent Mars Group.

Play-Doh used to be a wallpaper-cleaning product with dwindling sales. All it took was the willingness to change markets and a clever revenue-sharing agreement with Captain Kangaroo to convert Play-Doh into one of America’s most successful children’s toys.

As described on Wikipedia, the trigger for the new market was a request in 1955 from a school-teacher – a relative of the company founders – for “a safe and fun modeling clay substitute”; they sent her “a sample of a non-toxic compound used to clean wallpaper”, which the children used to make Christmas decorations, with results that were described all round as “a hit”.

The new market is fundamentally different from the old: from trade cleaning-products to children’s toys.

The technology is essentially unchanged; in later developments the formula included colourants and minor changes to improve plasticity, but the basic bulk-mixing technology remains almost identical.

The enterprise is radically different, largely following the change in market: from something like “effective and reliable cleaning for the building-trade” to “safe and fun modelling” (an enterprise which does not restrict the market solely to children). Much as with Mars and MyM&Ms, but even more so, the base-technology is the same but the enterprise-vision are so different that they must be operated as separate divisions or even formally-separate organisations. Over the years, the Play-Doh production and marketing has been acquired and transferred more and more into a ‘toy’-oriented enterprise; the original parent-company Kutol continues as a manufacturer of cleaning-products specialising in hand-hygiene.

Nokia is perhaps the most extreme example of an organisation that has mutated and reinvented itself and its enterprise many times over the decades.

The Wikipedia page shows it starting out in the mid-1860s as a lumber company – initially named after the town in which it was located, Nokia – and later moving into electricity-generation in the 1900s. The trigger for that change was recognition of market-opportunity.

In the 1910s the organisation is essentially taken over by another company, a rubber-products manufacturer, which later, in the 1920, acquired a cable-manufacturer. The trigger in the first case seems to be commercial opportunity, retaining the name because of the location; the acquisition would have been driven by parallel interests, in that rubber would have been for insulation.

In the 1930s, and onwards into Finland’s somewhat tangential engagement in the Second World War, Nokia changes to more of an industrial conglomerate, including products such as paper, bicycle and car tyres, footwear, cables, televisions and consumer-electronics, electricity-generation equipment, communications equipment, plastics, aluminium and chemicals. All of these products and business-lines can be traced back to the four roots of the corporation: lumber, electricity-generation, rubber and cables.

However, the spread of market and and scope of enterprise were far too broad to be practical, causing major financial losses in the late 1970s and 1980s, and arguably a major contributing factor in the suicide of the then CEO, Kari Kairamo.  During the late 1980s and 1990s Nokia refocussed itself around telecommunications, divesting itself of the rubber, cable, footwear and consumer-electronics divisions.

Its current enterprise is summarised by its tag-line “connecting people”. Guidelines for corporate culture are described in the document The Nokia Way; the Wikipedia article indicates that up until May 2007 the defined core-values were “Customer Satisfaction, Respect, Achievement, Renewal”, and redefined as “Engaging You, Achieving Together, Passion for Innovation, Very Human”.

The Nokia history indicates the problems that arise when an organisation grows without an explicit of identity to act as a guide to what should and should not be included as the organisation expands by natural growth and by mergers and acquisitions. Over time, the enterprise – and hence organisational identity – becomes less and less clear, leading to excessive tensions across the entire organisation. The break-up in the late-1980s and 1990s was a necessary foundation for its later growth, because each sub-unit could now align with a more-clearly defined enterprise-vision.

Looking back at all of these examples, it’s clear that strategy can be driven bottom-up as well as top-down. Sometimes, as with MyM&Ms and Play-Doh, the change in strategy requires the creation of a new enterprise, distinct from that of the parent. In both those cases, the technology essentially remained the same, with the new identity linked to the new market. In effect, the new identity is based on a new role for the technology.

In the case of Oceaneering, the new application of the existing technology remained under the old enterprise. It would in fact have been a good fit to the existing enterprise, if that enterprise had focussed around the technology rather than its application. However, the organisation’s declared enterprise is firmly linked to the application (underwater oilfields) rather than the technology (specialist bespoke hydraulic-engineering). The apparently highly-profitable animatronics division barely even rates a mention on the website, and is not included at all in the organisation’s stated vision or mission. It seems likely that a split similar to that of Mars and MyM&Ms will be necessary in the fairly near future.

A few important points have come up in the comments to those two articles, though, which are worth reiterating here before we move on.

One is to remember why we’re doing all of this. It’s not about abstract ‘blue-sky’ thinking: it’s about building a stable platform for organisational change. In enterprise-architecture, this needs to be a platform in which all of the other architectures – business-architecture, process-architecture, skills-architecture, values-architecture, security-architecture and, oh yes, all the IT-architectures too – can all interweave and interlink and intermesh into a single unified, dynamic whole. But although we talk a lot about the extended-enterprise here – especially in these ‘higher’ layers – this isn’t actually for anyone else at all: unless someone seriously-senior decides otherwise, all of this is solely for our own organisation (or client, if we’re doing this work as external-consultants). Working this way, whatever we develop is always in the context of this broader extended-enterprise: but our own organisation (or client) becomes more and more the centre of our attention as we move down the layers. That transition of emphasis starts to happen here. In short:

In enterprise-architecture, we create an architecture about an enterprise, but for an organisation.

It’s really important to remember that point – not least because it’s the organisation, not the extended-enterprise, that’s paying our bills!

Another point that came up in the comments is that the usual nine-cell structure of the Enterprise Canvas can be a bit misleading in these upper levels. The nine-cell structure is really a kind of functional-decomposition – who’s handling what interfaces, and why. But functional-decomposition assumes or describes specific interfaces and relationships – and we haven’t even got that far yet. In row-0 and row-1 we only deal with each entity as a whole, without any internal subdivision into cells. It’s only here, in row-2, that we start to introduce the idea of relationships and roles between entities, which eventually leads us to relationships and roles within entities, which leads us in turn to that nine-cell structure. If you try to use the nine-cell structure in rows 0 or 1, or in most of the work in row-2, you may have missed the point somewhere: at those levels, it’s only about each entity as a whole.

And finally, I would hope that by now you’ll have realised that this can be a lot harder to do than it might seem at first glance. It’s so easy to fall back to organisation-centric habits, where the organisation is placed as the sole centre of everything. The blunt fact is that it isn’t that ‘sole centre’ at all: in fact, the organisation only has a reason to exist if it’s placed within the context of its extended-enterprise. If we don’t understand that broader context, we would have nothing to guide us when that context changes – which, these days, can happen on a literally moment-by-moment basis. One of the keys here is that the description of that enterprise is literally emotive – it drives change. So although a lot of thinking and analysis will be needed here, ultimately it’s not a rational matter – it’s about what feels ‘right’, about identifying what is valued. This is especially true of the vision-descriptor: we need to keep exploring that context-space until we hit upon a phrase that can engender emotions and commitment that are literally strong enough to get people out of bed in the morning.

Anyway, time to move on: time to start looking at the business of the enterprise, and of the organisation itself. To summarise where we’ve gotten to so far with this example, we’d established a row-0 ‘Enterprise’:

We then started a Zachman-style row-1 ‘Context’ with a conventional market-based view of our enterprise, with our own organisation as its centre:

Which didn’t show us many options. But as we started to explore what that enterprise-vision meant in practice, and what kinds of stakeholders would be engaged in that vision, we realised that the actual enterprise was much broader than our current market:

Which should create many more strategic opportunities than we were able to see before. To make this work, though, we first need look more closely at the meaning of a common business-term: value-proposition.

Rethinking the value-proposition

In much of the conventional business-literature the term ‘value’ is linked indivisibly with price, or even equated with price. This is certainly the view associated with neoclassical economics, currently the dominant paradigm in most mainstream economic thinking. (If it can be called ‘thinking’: a more accurate term would probably be ‘superstition’ or, more literally, ‘cargo cult‘. My opinion, for what it’s worth, is that I’m continually astounded by the gaping flaws in both observation and reasoning in most so-called economics: the flaws in key concepts such as ‘rational-actor theory‘ are so blatant and so fundamental that I still find it almost impossible to understand how nominally-sane, nominally-intelligent beings can take those concepts seriously at all. But I digress…)

We also see other value-laden terms – ‘value’ in a somewhat different, broader sense – in the idea of ‘value-proposition as a means of positioning a product or service relatives to those provided by direct or indirect competitors: for example, the product is purported to be cheaper, cleaner, easier to use, more ‘green’, more ‘exclusive’, and so on. That type of modelling and comparison does become relevant when we get down to the fine-detail of business-models and the like in row-3 ‘System’ and, far more, in row-4 ‘Design’. But here, in row-2 ‘Business’ and above, there is a much simpler definition of value:

Value is whatever the enterprise-vision says it is.

The enterprise-vision – and particular the Qualifier in the vision-phrase – defines what is most valued in and by the extended-enterprise. In effect, it’s a condition of membership of the enterprise that the respective value or values are assigned to a high or even highest priority by each player in the enterprise.

The enterprise-values are not always assigned the highest priority, by the way, for the simple reason that every person and organisation exists within multiple enterprises – the enterprise of professional discipline, a family, a community, a country, humanity as a whole, and so on. Technically speaking, an enterprise is a ‘system’: every system – every enterprise – is contained in and intersects with other systems. The enterprise in scope that we’re exploring here is the one that’s of primary business-interest to our organisation – the enterprise about which we’re building an architecture for this organisation – but it’s essential to remember that it’s not the only enterprise that exists.

As part of their membership of the extended-enterprise, each player in the enterprise commits to delivering some kind of value to that extended-enterprise. In the context of this layer (row-2 ‘Business’ and above), the value-proposition is the value that the entity may and can bring to the shared-enterprise. In effect, the value-proposition is the choice of value to deliver, the ability to deliver that value, and the commitment to deliver that value.

Which brings us back to some of the questions with which we started this series: What can I/we do that creates value? Where could I/we add value? What role could I/we play within this enterprise? What capabilities (and hence, when linked with a role, ‘missions’) could I/we bring to make this enterprise happen? Who do I/we need to work with to make this happen?

There’s an important recap we need to do here, though. The enterprise-vision is energising, literally emotive, a literal driver for action. If we feel committed to that enterprise, yet have no apparent value to bring to the party, we perhaps need to do some deeper exploration – which we’ll tackle here shortly. But if we try to force-fit our skills and so on to an enterprise to which we don’t feel that same emotive commitment, the amount of value that we can add will be much less: being in the ‘wrong’ enterprise is literally ‘de-motivating’, certainly passively so, and often actively, and always reduces effectiveness for all parties involved. (This is true for all types of work, but especially so for knowledge-work or decision-work, as Daniel Pink explains well in his book ‘Drive‘.) This is a major reason why Taylorism and monetarist-economics are so ineffective in practice: they force just about everyone to be in the ‘wrong’ enterprise. It’s something we need to watch for, very carefully, if we want our organisations and our own work to be effective, valuable and valued.

The same questions apply to every player in the enterprise: What is their value-proposition? What can they do to make the vision come to life in the real world? That’s the nature of an ecosystem: in principle at least, everyone brings something to the party:

This delineates each party’s role relative to the enterprise – the ‘vertical’ dimension for each Enterprise Canvas element, the commitment to create value in the enterprise.

Their roles relative to each other within the enterprise – the ways in which value moves around within the enterprise – provides the ‘horizontal’ dimension for the Enterprise Canvas element:

In effect, the linkages in that horizontal dimension represent the value-propositions we have for each other within the enterprise. A couple of layers further down towards implementation, this leads us to the kind of value-proposition that would typically underpin a conventional business-model – better, cheaper, faster and so on – but we need to remember that all of that actually comes from here: the value we offer to the enterprise as a whole, and the dynamic flow of value around the enterprise that brings the enterprise-vision to fruition.

Value-relationships

Looking at these ‘horizontal’ relationships is what brings us ‘downward’ to row-2 (‘Business’) in the layering of the Enterprise Canvas. For example, there’s the (very simplified!) example row-2 diagram for the TED Conferences shared-enterprise, from the ‘Layers‘ article in the initial Enterprise Canvas series:

This is also the first point at which we need to start thinking in depth about our own organisation, as an entity in its own right rather than solely in terms of an extended-enterprise.  Whilst still keeping the extended-enterprise as a whole in mind, we need here to be ‘self-centric’ for a while:

• What value could I/we add to the extended-enterprise? – our value-proposition to the whole, the reason we are here?
• Which other players need the value we create for the enterprise in order to create their value for the enterprise? – who are our customers?
• What value (such as in the form of products or services) do we need from other players in order to create that value? – who are our suppliers?
• Which other players deliver complementary value to the extended-enterprise? – who are our partners?
• Which other players deliver the same value to the extended-enterprise? – who are our competitors?
• Which other players will support us to get started (or continue) to deliver value to the enterprise? – who are our investors?
• Which other players will we support whilst delivering value to the enterprise? – who are our beneficiaries?

And we also need to look at this in terms of the extended-enterprise as a whole:

• Which other players help to keep the overall value-web moving? – who are the coordinators, the suppliers of ‘coordination-services’?
• Which other players help to identify direction of the overall enterprise? – who are the futurists and/or historians, the suppliers of ‘direction-services’?
• Which other players will help to keep us on-track to the vision and values of the enterprise? – who are the regulators, the suppliers of ‘validation-services’?

Each of these relationships implies a value-proposition of some kind – a mutual value-proposition, since the aim is that value will be exchanged between the parties. The most problematic relationship, of course, is that of ‘competitor’: whenever we have two or more players purporting to deliver the exact same value, this implies – and potentially creates – ineffectiveness within the overall extended-enterprise. Sometimes there is genuine value in such ‘competition’: for example, redundant-duplication also supports resilience, in reducing the risk associated with any single point of failure. Constructive ‘competition-with‘ also helps to drive innovation and creativity to push the overall enterprise forward towards its vision. Destructive ‘competition-against‘, though, is something we do need to avoid, for everyone’s sake. Techniques such as Blue Ocean Strategy can help a lot here: what we need to look for is a niche that fits well with our own competencies and capabilities, fits well with our sense of the enterprise as a whole, and which complements rather than competes directly with anyone else in the shared-enterprise.

Note that although we’re starting to get closer here to conventional strategy-development and business-model development, we’re still not there yet: in fact the proper ‘business-models’ and the like don’t properly begin to emerge until down in the next layer, row-3 ‘System’. What we really look at here is just one question:

• Given each player’s value-proposition in the overall extended-enterprise, what would that imply in their relationship with us?

Or, to put it the other way round:

• Given our own value-proposition in the extended-enterprise, what relationships with us would that suggest to others?

The answers to either version of that question provide the prototype for our organisation’s business-models. And importantly, by the value-driven nature of those relationships, that would be a self-marketing ‘pull’-type business-model – a huge advantage over the conventional ‘push’-type marketing-model, where the absence of any self-evident reason to relate forces us to manufacture a sort-of-relationship from nothing.

So to apply all of this for our main example here, my own enterprise-architecture consulting-business:

• What is the vision for the overall extended-enterprise? – “enhancing enterprise effectiveness”
• What are the key values here? – examples include the five dimensions of effectiveness – efficiency, reliability, elegance (in the generic sense), appropriacy, integration – and direct derivatives or compounds such as resilience, simplicity and integrity
• What is our own value-proposition to the extended-enterprise? – we provide tools, techniques, training and insight on enterprise-effectiveness, particularly in whole-of-enterprise architectures (the intersection of structure and purpose) and whole-of-enterprise integration (processes, practices, metrics and people-related themes)
• Who would value our value-proposition? – in principle, anyone doing the practice of enhancing effectiveness within organisations

That last line tells us our nominal customer-base, which is huge: in principle, it applies to just about any organisation anywhere in the world. Too large to be practical, in fact – which is a serious problem for us. As futurists and developers of new techniques, the work we do is often a long way ‘ahead’ of the mainstream: our main customers at present tend to be early-adopters or very-early-adopters, but in almost any industry. This means that our current market is very broad but very ‘lumpy’ (“the future is already here, it’s just that it’s not evenly distributed”, as one science-fiction writer put it), so we’re faced with a classic dilemma: do we spread the net wide but risk being too generic to be much use, or limit it to a narrow domain which has a more explicit practical focus but for which there are too few early-adopters to make it viable? Getting the right balance here is going to be crucial to success.

• What products, services and other value do we need from other players? – our ‘product’ is ideas and techniques, hence anything that feeds into that, such as information, practices, test-cases and peer-review

Although this is fairly typical for a professional-services firm with a strong research-and-development focus, it demands radically different relationships from those of, say, a retail outlet or a utilities corporation. In the latter, there are clear distinctions between ‘customer’ and ‘supplier’, and hence (usually) clear boundaries between the respective relationships; whereas in this case, every customer is also a ‘supplier’ in that each context will have always have some aspects that are new and unique, and hence provide us new information, new test-cases and new peer-review. The same applies to our partners and even to our nominal ‘competitors’: we each become most effective when we each provide peer-review for each other. Conventional near-combative relationships based on ‘competition-against’ and proprietary notions of ‘intellectual property’ will guarantee failure here, for everyone: yet we also need to protect ourselves – and everyone else in our enterprise – from predatory types who unfortunately do believe that aggression leads to ‘success’. The key here is to leverage off the enterprise-vision and values: we need to assess all potential relationships – customer, supplier, partner, even ‘competitor’ – against that yardstick of shared overall effectiveness.

• Which other players deliver complementary value to the extended-enterprise? – anyone working on enhancing enterprise effectiveness in organisations, particularly those people or groups working in more specialist domains such as organisational-development, process-improvement, knowledge-management, quality-management, skills-architectures and the like

This again is a huge ‘market’ – and hence again a real risk of spreading ourselves too wide and too thin. The key point is that our emphasis on whole-of-enterprise architectures is a generalist domain, whereas most of these potential partners are specialists. So there’s no ‘competition’ as such: what we look for are synergies, to cross-leverage each others’ work. Building appropriate relationships here would be fundamental to our marketing. One of our key value-points is that as generalists we provide a means to cross-link between the specialist domains; we and our colleagues will often act as facilitators, arbitrators and ‘thought-translators‘ to reduce the risk of getting lost in translation between domains.

• Which other players deliver the same value to the extended-enterprise? – the ‘product’ is ourselves, so there are no direct competitors as such: the real ‘competition’ here is not so much for market-share as mind-share

Our greatest ‘competitive’ problem at present is misuse and misappropriation of key terms by others, which can make it almost impossible to communicate what it is that we do, and the value that we deliver. Perhaps the most important of these are the near-ubiquitous misuse of the terms ‘enterprise’ and ‘enterprise-architecture’, and thence also ‘business-architecture’. It seems that most business-people fail to understand the difference between ‘the organisation’ and ‘the enterprise’ – hence why so many references in these articles to ‘extended-enterprise’, to try to establish those crucial distinctions. And it certainly seems true that very few IT-folks seem able to grasp that serious problems can arise from conflating the term ‘enterprise-wide IT-architecture’ into ‘enterprise-architecture’: in the former, the IT-architecture has an enterprise-wide scope, whereas in the latter the enterprise is the scope. One result of such IT-centrism is that ‘business-architecture’ is often taken to mean ‘anything not-IT that might affect IT’, leaving no space to describe anything which is mostly or entirely outside of the scope of IT.

In our work, we struggle every day with the consequences of these fundamental terminology-mistakes: although there are some signs of change (such as the Open Group‘s dawning awareness that enterprise-architecture must extend beyond the ‘comfort-zone’ of IT), it seems likely that this ‘mind-share problem’ will remain with us for at least another decade or more. In the meantime, just about all we can do is, again, point to the enterprise-values, demonstrate that IT-centrism, business-centrism and the like are in direct breach of most of the ‘effectiveness’ themes – particularly ‘integration’ – and explain quietly what to do to repair the damage. Frustrating, but that’s what happens when mind-share is dominated by major misunderstandings about the nature of the extended-enterprise itself, and by mistaken, much-mangled terminology.

• Which other players will support us to get started (or continue) to deliver value to the enterprise? – our ‘investors’ are mostly ourselves, though we need to remember that many others (especially our partners) invest ideas and personal and/or professional support in what we do
• Which other players will we support whilst delivering value to the enterprise? – our key ‘beneficiaries’, again, are ourselves, though it’s extremely important to us that we also contribute to our partners’ development and to the development of the enterprise as a whole

And, in terms of the extended-enterprise as a whole:

• Which other players help to keep the overall value-web moving? – the short answer is ‘not many’: there’s a real dearth of ‘coordination-services’ across this enterprise, and a real need for an equivalent of the services that SourceForge, for example, provides to Open-Source collaboration
• Which other players help to identify direction of the overall enterprise? – other than our partners, ourselves and some futurist organisations, there don’t seem to be many working in this space: most of the industry-bodies such as Open Group focus solely on subsets such as IT, rather than on the extended-enterprise as a whole
• Which other players will help to keep us on-track to the vision and values of the enterprise? – again, there don’t seem to be any real providers of ‘validation-services’ here: there’s a real need for this

The other key point to note here is that we need to remember to keep in mind that all of the players in the extended-enterprise could play any of these roles, relative to each other, or relative to us – and likewise we to them. This awareness becomes extremely valuable whenever we need to rethink our current positioning or current market, because it greatly increases our options relative to most conventional approach to business-strategy or business-development.

Another example

We could also apply all of the above to the example provided by Pat Ferdinandi in the comments to the previous articles, a real chain of restaurants in the US called Elevation Burger. Using quotes from their website (in double-quotes below), our assessment at this whole-of-enterprise layers of the Enterprise Canvas might go like this:

• What is the vision for the overall extended-enterprise? – tag-line “ingredients matter”, implying an enterprise-vision of something like ‘making food that matters’ or ‘making food matter’

Note that the ‘vision’ on the website is a fairly standard organisation-centric marketing-style vision. It tells us quite a bit about the values and decisions made by the organisation: “a vision for an elevated product that is fresh and flavorful… for authentic, sustainably prepared food… for an elevated experience in a well-appointed and environmentally friendly setting”. But it tells us very little about the extended-enterprise in which the organisation operates – and that’s what we would need to know if we were to be trying to re-think the organisation and its relationships when the market context changes. In essence, what we have here in Enterprise Canvas terms is a (very good) example of a set of drivers at the row-3 ‘System’ layer – which is fine if we’re only refining our marketing based on the current business-model, but not much use if we need to rethink the business-model itself.

• What are the key values here? – examples include “quality ingredients”, “better for you”, “better for the environment”, “passion for good food”, “enthusiasm, drive and passion”, “bright, sincere, engaging and energetic”, “genuine enjoyment in serving others”

There are other values or emphases listed on the website, such as “organic, grass-fed, free-range”, but to me these are more likely to be detail-layer decisions – down at row-3 ‘System’ or even row-4 ‘Design’ – that express beliefs or instantiations around the more core values such as “quality ingredients, better for you, better for the environment”.

• What is the value-proposition that Elevation Burger offers to the extended-enterprise? – the company and its franchisees express the vision of ‘making food that matters’ via provision of burgers, fries, shakes, malts and cookies in a “well-appointed and environmentally friendly setting”, mainly in cities and larger towns in the US

In other words, this is the chosen role that the organisation will play in the extended-enterprise

• Who would value this value-proposition? – anyone wishing to eat ‘food that matters’, those suppliers who would provide such ‘ingredients that matter’, anyone who holds similar beliefs, anyone who would like to be a customer but is not yet resident or visiting any locations at which the organisation operates, potential franchisees (primarily those who hold similar beliefs), food-critics and other media representatives, environmental activists, restaurant-builders and other ancillary-service providers, local government, regulatory authorities and many others
• What value do Elevation Burger add to the extended-enterprise? - the organisation provides a practical instantiation of the enterprise-vision and values, via operation of restaurants that express those values
• Which other players are ‘customers’ who need the value that Elevation Burger create for the enterprise? – those who wish to eat ‘food that matters’ of the types that Elevation Burger offer (e.g. burgers, fries etc), and who place value on the food and the context in which that food is provided (e.g. “well appointed environmentally friendly setting”, via “genuine enjoyment in serving others”
• What value (such as in the form of products or services) do Elevation Burger need from other ‘supplier’ players in order to create that value? – providers of ‘ingredients that matter’ (meat, salads, bread, potatoes, milk, drinks, etc), providers of construction-services (e.g. “well appointed environmentally friendly setting”), real-estate services, marketing services (websites, advertising, flyers etc), logistics services, management and accounting services, etc, all of whom need to align with the enterprise-vision and values
• Which other players are ‘partners’ for Elevation Burger, who deliver complementary value to the extended-enterprise? – other restaurants who likewise commit to the tag-line “ingredients matter”, but who provide different types of food, such as pasta/pizza, fish, Asian-style, French/European-style, bakery etc
• Which other players are ‘competitors’ who deliver the same value to the extended-enterprise? – Elevation Burger claims there are none, at least on the US Eastern seaboard: “our founder couldn’t find the burger he had been dreaming of since he left California in 1999″

Note that although fast-food burger chains such as McDonalds or Hungry-Jacks/Burger-King might in principle seem to be direct commercial competitors, in practice they operate in a different market-segment – a different enterprise – in which price has a higher priority relative to “ingredients matter”. Or, to put it the other way round, Elevation Burger’s clientele would place a higher priority (and premium) on taste, environmental history, restaurant ambience and so on. The competition is therefore indirect (a comparison of somewhat-different extended-enterprises and enterprise-visions) rather than direct (a comparison of near-identical services and values). However, if McDonalds or the others choose (or are pressured) to re-emphasise their positioning on ingredient-quality relative to price, they might move more into the same enterprise-space. Clarity on enterprise-vision would help to mitigate this risk by creating more of a ‘pull’-orientation rather than the fast-food chains’ ‘push’.

• Which other players are ‘investors’ who will support Elevation Burger to get started (or continue) to deliver value to the enterprise? – management, direct financial-investors, franchisees, all employees and other staff, local communities, any of the ‘partner’ and/or ‘supplier’ and/or ‘customer’ groups
• Which other players are ‘beneficiaries’ whom Elevation Burger will support whilst delivering value to the enterprise? – any or all of the ‘investors’, also (in non-monetary values) farmers and other suppliers, community and environment

And we also need to look at this in terms of the extended-enterprise as a whole:

• Which other players are the coordinators, the suppliers of ‘coordination-services’ that help to keep the overall value-web moving? – examples include logistics, event- or media-organisers for shared-marketing across the extended-enterprise, collective sourcing for ‘ingredients that matter’, support-groups for organic-farming and for environmentally-friendly building etc
• Which other players are the futurists, the suppliers of ‘direction-services’ that help to identify direction of the overall enterprise? – examples include the Slow Food movement, food-critics and other writers on food, sustainability and/or urban renewal, futurists on sustainability, agriculture, food and health etc
• Which other players are the regulators, the suppliers of ‘validation-services’ will help to keep everyone on-track to the vision and values of the enterprise? – examples include support-groups for organic-farming and for environmentally-friendly building etc, certification-bodies for same plus sustainability etc

The important point in this last section is that all of the individuals or groups listed there are potential allies – and, importantly, any challenge from any of them should be regarded as a spur to action rather than as an ‘attack’, because their role is to remind Elevation Burger how to keep on-track to their own commitment to the extended-enterprise.

I’d better stop there – this has been more than long enough already! More to follow, anyway, including a look at how to re-leverage assets and capabilities that we already have, in order to support a new strategy or business-model.

We started at the top layer, aiming to identify the core ‘enterprise’ within which I work. From exploring my own professional history, it became clear that the main focus of my work is about enterprises themselves, of any size, and always with the aim of enhancing enterprise effectiveness. From that, we ended up with an initial enterprise-descriptor – or ‘vision’ – of “creating more-effective enterprises”.

Notice, though, what’s happened right here, in that paragraph above. In trying to summarise that initial rather clunky vision-statement – ‘creating more-effective enterprises’ – we’ve accidentally hit upon a better one: ‘enhancing enterprise effectiveness’. It reads better, has a smoother flow to it, a poetry almost. It does describe what I’m passionate about – and finding that passion is central to the success of an enterprise. And ‘enhancing’ is actually a much more accurate term for what I do: I don’t often create enterprises in the sense that, say, an entrepreneur would do, but I do work to enhance their effectiveness. So note that this process is typical of what happens in context-space mapping: for example, we arrive at a ‘solution’ – in this case, the initial ‘vision’-descriptor – which itself quietly dropped us back into the ‘sensemaking’ space. So the trick here is to notice what’s happening, notice these little serendipitous events – and learning how to do that is a real skill in itself. To quote one of my favourite books, William Beveridge’s The Art of Scientific Investigation:

If these discoveries were made by chance or accident alone, as many discoveries of this type would be made by any inexperienced scientist starting to dabble in research as by Bernard or Pasteur. The truth of the matter lies in Pasteur’s famous saying, “In the field of observation, chance favours only the prepared mind.” It is the interpretation of the chance event which counts. The role of chance is merely to provide the opportunity and the scientist has to recognise it and grasp it.

Anyway, that’s what we now have as the ‘row-0′ or ‘Enterprise’ layer for the Enterprise Canvas model of my own enterprise:

Now what? Very pretty and all that, but what do we do with this?

At this point we need to do brief reprise on layering and the Enterprise Canvas. Each entity described in an Enterprise Canvas model is considered to be in just one of seven distinct layers of abstraction, summarised as follows:

• row-0, ‘Enterprise‘: consists of a single entity summarising the overall enterprise, its vision and core-values
• row-1, ‘Scope‘: consists of lists of core entities, such as key assets, key functions, capabilities and services, key events, key players in the enterprise, etc
• row-2, ‘Business-model‘: describes roles and relationships between the key entities in scope
• row-3, ‘System-model‘ (aka ‘Logical model’): includes attributes and events etc to describe more detail about generic ‘families’ of options and ‘platform-independent’ solutions
• row-4, ‘Design-model‘ (aka ‘Physical model’): specifies ‘platform-dependent’ implementation-details, such as specific methodologies, technologies etc
• row-5, ‘Action-plan‘ (aka ‘Operations-model’): specifies individual context-specific instances for final work-plans, such as work-rosters, individual system-configurations etc
• row-6, ‘Action-record‘: detailed records of actual events, actual configurations etc at a specified (past) point in time

(The numbering starts at 0 rather than 1 for compatibility with the well-known Zachman framework, with which layers 1-5 here match almost exactly. Row-0 is unchanging – or should be, because if it does change, it ceases to be the same enterprise. Rows 1-5 represent various abstractions or concretisations of a potentially-alterable plan for the future; row-6 represents the unchangeable past.)

Three points to note about where we’ve gotten to so far.

One is a reminder that although I’ve chosen this as the definition for ‘my’ enterprise, it’s more accurate to say that it chose me: looking at my history and my natural focus and the like, this is the enterprise that I am actually working in, whatever I might think otherwise. Given that that’s the case, it’s more sensible all round if I become more explicit and intentional about aligning my work with this enterprise. And whether the ‘organisation’ in scope is made up of just one person or many millions, the same principles apply.

Next, this enterprise-definition is unchanging: it’s the same for to-be, as-is or as-was. (If it isn’t the same in each case, it’s not an enterprise-definition in the sense that we need here.) As in the ISO-9000 standard for quality-systems, this ‘vision’ provides a permanent anchor for everything that is done in the enterprise. When you work in a business-context that changes on a moment-by-moment basis, it can be very useful to have something that you know will not change whilst you’re working on it…

And note that there’s been no reference yet to the market, to money, or to the organisation itself. That’s intentional – and needs to be that way, too. (As you’ll see later, money doesn’t even rate a mention until we get to ‘System-model’, another three layers further down.) The point here is that the enterprise just is: it’s just an idea, an emotive idea. But until we have that idea firmly in place, and the intermediate layers properly in place too, everything else is at risk of becoming unstable, falling apart without warning – as we can see happening all too often in many large organisations. Yes, the sensemaking and decision-making will often get a great deal messier further down the layer-stack: but for now, in these rarefied levels, all we need to do is Follow The Process.

Anyway, time to move on, to look at the scope in which our organisation exists.

Identifying the scope

In strategy-development, we typically begin ‘top-down’, working our way down through the layers, in a kind of idealised view of the world, until we hit the real-world constraints coming ‘bottom-up’ -which will usually (and usefully!) force us to start being ‘realistic’. So now that we have our row-0 for the Enterprise Canvas, we’ll continue going top-down for a while – which takes us to row-1, ‘Scope’.

Row-1 is always just a list – nothing more than that. Later on we’ll probably come back to make lists of key-assets, key-functions, key-events and so on, but for now all we’ll need is a list of other players – or types of players – within this enterprise. In other words, who else is likely to be interested in the enterprise of ‘enhancing enterprise effectiveness’?

The natural tendency at this point is to start with the as-is, and list my existing customer-groups. I often describe myself as a ‘toolmaker to consultants’, especially in the enterprise-architecture/strategy space, and at first glance it seems that there isn’t much to show:

What’s worse, that market is tiny – probably no more than a few thousand of us worldwide – and, if we jump downward to the Enterprise Canvas row-2 for a moment, most of those that I and my colleagues know are not only our potential customers but potential suppliers and potential competitors as well. Sure, we also do some consultancy, either in setting up enterprise-architecture capabilities or running workshops for executives and in-house consultants – but again, one of the explicit aims there is that we’re training my own future competition each time we do so. And although IT-oriented ‘enterprise’-architecture is quite well-known, true whole-of-enterprise architecture isn’t at all well-known as yet: hence although the need for that kind of work is enormous and all-too-evident, the demand isn’t there – and won’t be, until we’ve created enough awareness of what it is and why it’s so important. The one saving grace here is that the emphasis in this market is always on quality, not quantity: those organisations who do understand what we do are well aware of what it’s worth to them, and are willing to pay for it, so that even a short assignment can fund a fair amount of ‘unbillable’ research and development for the future.

So far, so good – sort of – but in fact this would be setting our sights to far too narrow a scope. Our current market may seem tiny, but by definition the overall enterprise includes anyone with any interest in enhancing enterprise effectiveness. So for a start, it includes almost every consultant and in-house staffer working at a strategic, tactical or operational level to improve just about anything in the organisation: IT, efficiency, innovation, quality, production, skills and competencies, safety, security, risk-management, disaster-recovery – if you can give it a name and it’s anything to do with organisations, it’s likely to be in scope here. What’s even better is that all of these other people are doing work that’s different from ours – so not only may there be potential synergies there for us, but they’re also unlikely ever to be our competitors.

Yet even this is still thinking far too narrow. Who else would be interested in ‘enhancing enterprise effectiveness’, where ‘enterprise’ means anything that the organisation might touch, and ‘effective’ means that the organisation would be more efficient, reliable, elegant, appropriate, integrated, in just about any sense of those words? The short answer is “just about everyone”…

Executives would be very interested. So would investors. Regulators. Government. Business-partners. Business-clients. Standards-bodies. Environmental activists and other pressure-groups. The countries and local communities in which the organisation operates. Even competitors would be interested, if it helps to create a larger or more stable market for everyone. That’s not a small enterprise at all: it’s huge.

So far, this is just a list – a list of players in the enterprise of ‘enhancing enterprise effectiveness’. It doesn’t tell us anything as yet about the relationships between these players – which is what I’ll need to know if I’m to design a viable business-model within the scope of this enormous shared-enterprise. But that’s fine – that’s what we explore in the next layer of the model, which we’ll look at in the next post. For now, though, it’s useful just to bask for a moment in the plain fact that the enterprise – and market – that I’m dealing with is much, much larger than I’d previously believed, providing many more potential opportunities for my business if I make the effort to find them. Food for thought indeed…

On the other side, I haven’t really posted anything here as yet on the ‘final’ version of the context-space mapping methodology. There are a few scattered posts from a few months back, but the main description is in the chapter ‘Day 8: Putting it into practice’, in my most recent book, Everyday Enterprise-Architecture [at present you can still download the complete PDF e-book via that link].

So it seems worthwhile to develop a worked-example to show how all of these tools and techniques fit together in real-world use.

And for me, right now, the obvious example to choose would be my own work and business. I’m a futurist and maker of conceptual tools, working mainly with the arcane abstractions of enterprise-architectures: none of those attributes and emphases are exactly conducive to fame and fortune… It’s true I do get by well enough at present, yet I would like my work to be better known and more commonly used, and – no surprises here – it’d be good if it could bring in a better income, too. So how can I make that happen? What do I need to do that’s different from what I’m doing now? What do I need to change in the architecture of my own enterprise?

And I’m not alone in this: I know a lot of enterprise-architects and others – especially those of us working in the very new field of whole-of-enterprise architectures – who are in much the same boat at present. In our own quiet ways, all of us are wrestling with much the same questions:

• What business am I in? – really?
• Who else would be interested in what I’m working on? What value do I add right now? – if any?
• Where could I add value? In what contexts?
• With whom would I need to work with in on this? Who would be my prospective partners, clients and other business-relationships?
• For whom could I most add value? Who would pay for it? – and why would they pay for it?
• How can I describe that value? How could I prove that value?
• How would I deliver that value? How would I prove that I’ve delivered it?
• How much could, would or should I charge for this?

And so on: all pretty fundamental questions, really – especially in business. Sounds like a good candidate for some serious exploration – which is where context-space mapping and the Enterprise Canvas come into the picture.

This’ll probably take several posts, but let’s get started.

Context-space mapping – a quick review

For many people, the initial problem with context-space mapping is that although it’s a very simple idea in practice, it can be surprisingly hard to explain on paper. The core of it comes down to just four keywords:

• sensemaking – making sense of the context
• strategy – deciding what to do with we’ve discovered
• structures – we look for patterns, for structures, for something that’s stable enough for us to build something on it or with it or around it
• solutions – we identify and/or define the detail of what we’re going to do within the chosen context

At first, that often looks like it would be a straightforward step-by-step process, and in fact it’s portrayed that way in some frameworks such as the TOGAF ADM (Architecture Development Method), which would match up to the above as ADM Phase A-D (sensemaking and some aspects of strategy), Phase E (strategy and high-level structures), Phase F (structures and solution-plan) and Phase G (solution-implementation) [with Phase H as a wrap-round to prepare for sensemaking again in a new cycle]. Reality, though, is a great deal messier than that – hence, for example, why the TOGAF specification describes the process as ‘iterative’, which is something of a polite understatement! So although those four steps above do represent the overall flow of what happens, in practice we’ll usually pass through most of these steps many times, in many different ways, and in just about any order, jumping back and forth between the respective emphases as we go.

In essence, we ‘go for a walk’ in a kind of imaginary-world, in order to make sense in the real one. The imaginary-world is our sense or understanding of the context in scope – in this case, a business and its business-models, including the practical implementation and execution of those business-models. What we want to end up with is a detailed picture of what to do, to make all of that happen back in the real-world, and also – and this is important – some clear hints about what we need to watch for and to do to change that plan on the fly in response to the actual circumstances at the time: “no plan survives first contact with the enemy”, or, more generically, first contact with reality.

To guide us, we start off with some fairly simple map – often just a list of categories of things or ideas or attributes. We then add more and more detail to that sensemaking map as we go. Walking around – metaphorically speaking – gives us many different views over the context, from many different directions, sometimes as a big-picture overview, sometimes right down into the fine-detail. At times, quite without warning, as TS Eliot put it, “…the end of all our exploring // Will be to arrive where we started // And know the place for the first time.” Using different model-types as overlays on the map creates further views – not so much filling in all of the missing pieces on a jigsaw, as adding richness and depth to a hologram where every point contains every other point.

That’s the everyday world of an enterprise-architect. It’s also a quick way to go crazy if we don’t make proper use of that map. Many people get stuck in analysis-paralysis, for example; others mistake someone else’s prepackaged ‘solutions’ for strategies, and wonder why nothing works any more. Everything is built up, layer upon layer, from the base-map with which we start, and to which we return whenever we realise that we’ve gotten lost somewhere. So the maps we use will matter a lot.

Context-space maps have two distinct components: the base-map, which provides a common frame of reference for a set of context-space maps; and any number of cross-maps – other models overlaid onto that base-map – that provide alternate views and categories for sensemaking in the same context. In practice, typical characteristics for a good base-map include:

• universality: it covers the entire scope of a given context – in principle, at least
• sensemaking: its purpose is to guide sensemaking and decision-support (rather than design and implementation of a specific ‘solution’
• simple partitioning: it divides the context into a small number of regions or ‘domains’ (from three or four to a dozen at most), and often including a ‘none-of-the-above’ region
• fluid boundaries: the boundaries between regions may be allowed to move, blur and/or be somewhat porous
• usage-dependent layout: its layout may not be semantically significant, and may take any appropriate form, such as a horizontal or vertical single-dimension, or multi-dimensional form such as the four-axis/three-dimension tetradian

In systems-theory terms, each base-map is a rotation that provides multiple views into the same overall space. Ideally we also want it to illustrate the balance in the context (reciprocation and resonance), and preferably the layering (recursion and reflexion) in that context too.

The Cynefin-categorisation – Simple, Complicated, Complex, Chaotic, and the ‘none of the above’ Disorder region – is one frame that’s proved useful as a base-map; another, especially where the context is mainly about flows of some kind, is the VPEC-T frame – Values, Policies, Events, Content, Trust. Another is the Zachman frame, with its six core questions: What, How, Where, Who, When and Why. The frame we’ll use for this purpose, though, is one that’s somewhat larger in scale and scope: the Enterprise Canvas.

The Enterprise Canvas – a quick review

As with context-space mapping, the essence of the Enterprise Canvas is one very simple idea: everything in the enterprise is (or is part of) a service of some kind, and every service – in principle, at least – adds value to the overall enterprise. Each service sits at a kind of intersection where the vision and values of the enterprise crosses the flow of value (the ‘supply-chain’ or ‘value-web’) around the various players in the enterprise – a point of value-creation, as the core of service-delivery:

Each service has its own value-proposition, which defines and guides what value will be delivered by the service; and its own value-management, which ensures that the respective value is actually created and delivered. On either side of this kind of ‘vertical axis’ are the main flows of value-exchange with other players in the enterprise, either as ‘suppliers’ or ‘customers’ relative to this service; for a variety of practical reasons we partition these flows in terms of what needs to happen before, during and after the main types of value-exchange, which are managed by supplier/customer relations, by supplier/customer channels and by value-outlay/return respectively. In effect, every service in the enterprise can be described in terms of this simple structure.

(If that doesn’t make much sense as yet, don’t worry: it should all become more clear as we go through this worked-example.)

The other important point is that we need to be able to describe these services in terms of layers of abstraction, from most-abstract – ‘the enterprise’ as a whole – right the way down to most-concrete – the fine-detail of action-plans and action-records. There’s more detail about the layers here, but again, don’t worry too much about it just now: the main point to note is that we’ll often see what may seem to be the same service re-appearing in different layers, but actually at different levels of abstraction, going ‘down’ towards real-world implementation, or ‘up’ towards re-structure and redesign.

There are also several different versions of the Canvas – summarised here – depending on whether we’re looking solely at the service itself (for which we’d use the version nicknamed the ‘brick’), its flows and links with other players (the ‘beetle’), or its integration into the enterprise as a whole (the ‘robot’). Most of the time we’ll use the simpler version – the ‘brick’ – which is essentially the same as in that cross-diagram above.

So that’s what we’ll use as our base-map. To get started with the context-space mapping, we’ll move to the topmost layer of the Enterprise Canvas – row-0, ‘Enterprise’ – to address the first question in our review: “What business am I in?”

Identifying the enterprise

Probably best to start by defining what’s meant by ‘enterprise’. (Perhaps it’s best to think in terms of ‘shared-enterprise’ or ‘extended-enterprise’ here: many people use ‘the enterprise’ as a synonym for ‘the organisation’ – which is not a good idea, because they’re not the same, as we’ll see in a moment – but we’ll have to allow for the fact that people do this.) To use the definition from the FEAF document A Practical Guide to Federal Enterprise Architecture:

[An enterprise is] an organisation or cross-functional entity supporting a defined business scope and mission.

An enterprise includes interdependent resources – people, organisations and technology – who must coordinate their functions and share information in support of a common mission or set of related missions.

Again, note the booby-trap here: ‘enterprise’ is not the same as ‘organisation’. The Practical Guide warns:

…it must be understood that in many cases, the enterprise may transcend established organisational boundaries – e.g. trade, grant management, financial management, logistics.

An organisation is a formal structure of some kind, in essence bounded by rules, roles and responsibilities. But an enterprise in this sense is more like something that happens between or ‘above’ any individual organisation: “interdependent resources … who coordinate … in support of a common mission” and so on. The point is not just the processes via which that coordination happens, but the underlying idea – the ‘why’ – that makes it “a common mission or related set of missions” shared across all of those “interdependent resources”, the reason or decision that links everyone together in this shared activity.

Identifying the underlying enterprise will tell me why I work for or with a particular organisation. It tells me why I work in that particular enterprise rather than in any other. And it also indicates who it’s likely I could collaborate with, because they’ll all be people or groups or corporations have an interest in this same enterprise.

Importantly, the enterprise is also emotive: if it’s described properly, it will literally give the people involved in that enterprise a reason to get out of bed in the morning. The organisation is just rules, roles and responsibilities; but the enterprise matters.

What we need up in row-0 of the Enterprise Canvas is a kind of ‘enterprise descriptor’ – usually referred to as the vision – and a related set of core-values that identify the highest priorities to guide decision-making. There’s a lot of discussion about ‘vision’ in business, and unfortunately many of the commonly-promoted examples are no more than empty marketing-puff – almost useless for any practical purpose, especially in enterprise-architectures. A ‘vision’ that does work consists of a very brief phrase – usually no more than four or five words – with a distinctive three-part content and structure:

• a descriptor for the content or focus for this enterprise
• some kind of action on that content or focus
• a qualifier that validates and bridges between content and action

These components may occur in any order, but all of them need to be present. For example, take the vision for the TED conferences, “ideas worth spreading”: ‘ideas’ [content]; ‘worth’ [qualifier]; ‘spreading’ [action] – clear, succinct and emotive. And note that none of these describe the organisation at such – but do describe the focus, the area of action, and the key value-metrics which define the meaning of ’success’. That’s what we need to look for at this stage.

So in my own case, what enterprise am I in? Which enterprise – or type of enterprise, at least – best lines up with what I do? That suits the way I work, the kind of things I want to do, and so on? With the Enterprise Canvas, one tactic is to go right to the other end of scale of abstraction, down to row-6, where options are not so much unchanging (as they should be in row-0), but unchangeable, because they’re in the past. In short, what can I learn from my own history?

(I’m using a personal-business example here, but the principle is essentially the same for an organisation of any size – for-profit, not-for-profit, government or whatever.)

Overall, for me, that’s more than four decades of professional past to explore, across many different industries: graphic design and pre-press, medical education, skills-research, information-systems, aeronautical engineering, telecoms, logistics, banking, utilities, just to name a few of the more mainstream examples. But there’s one common theme that seems to run through every one of these examples: the quest for effectiveness, in almost any of its myriad forms. That’s true for my work with individuals, and their development of skills and competences; for teams and work-groups, or for specific aspects of an organisation; sometimes for organisations as a whole; and more recently, with enterprise-architectures, across groups of organisations or even entire industries. And it’s clear that I’m passionate about it, too – which means it fits that criterion that it needs to be something “strong enough to get someone out of bed in the morning”.

‘Effectiveness’: is that the content, the qualifier, or the action? Not sure yet: so keep wandering around in the context-space for a little while longer.

Try another tack: a descriptor can be either about content, or focus. So what’s the focus here? – would that help to clarify the shape of this enterprise? Somewhat recursively, it seems that the focus of this enterprise is actually enterprises themselves, about coordination and collaboration and competence, again at every level, from the individual right up to the scale of entire economies.

Okay, this seems to be getting somewhere: this enterprise that I’m in is about effective enterprises, or enterprise-effectiveness – something like that, anyway. And ‘effectiveness’, as I’ve come to understand it over the past couple of decades, has five distinct strands that are close to being values in their own right:

• efficient: optimises use of resources, minimises wastage of resources
• reliable: predictable, consistent, self-correcting, supports ‘single source of truth’ etc
• elegant: clarity, simplicity, consistency, self-adapting for human factors
• appropriate: supports and optimises support for business purpose
• integrated: creates, supports and optimises synergy across all systems

In effect, effectiveness happens when everything supports everything else, always pushing towards enterprise purpose, the respective enterprise-vision. And all of that – about enterprises and effectiveness – does fit very well with what I do. Or rather, that’s the descriptor and the qualifier for the vision – I still need to identify that ‘action’-component.

And that last part of the vision still isn’t quite clear as yet. It’s a verb something like ‘creating’ or ‘making’ or ‘building’ – it’s obviously not ‘destroying enterprise effectiveness’, for example. (Don’t laugh: some people really are engaged in the enterprise of destroying enterprise-effectiveness – such as those whose passion is about breaking up the enterprise of organised-crime.) I’ll choose ‘creating’ as the action-verb for now: given the recursive, re-entrant nature of context-space mapping, I can always come back to adjust that kind of fine-detail later.

So let’s put all of this together, to give me a preliminary row-0 for my Enterprise Canvas: the enterprise that I’m in is about creating more-effective enterprises, expressed via those five themes or principles of effectiveness – efficient, reliable, elegant, appropriate, integrated.

Note that unlike an organisation, this enterprise isn’t something I own, or control – in fact it’s more like that it owns me, because it’s such a core driver for everything that I do. In principle I could choose anything as ‘my’ enterprise – but in effect it’s more that this one chooses me.

And that’s the principle here, especially when we move up the scale to a company or an entire corporation: we’re looking for that to which the organisation would naturally align. Once we have clarity on that, then many of the classic organisational problems suddenly become a whole lot easier: we stop arguing about ‘business/IT-alignment’, for example, because both sides can now align to the same enterprise-vision. That’s what all of this exercise is about: creating clarity, enhancing effectiveness.

What happens next is that we use that enterprise-vision to tell us a lot more about the business that we’re in – including all the other players in the same overall enterprise. That’s what we’ll start with in the next article in this series.

Yes, it’s a good article – recommended reading. And I would strongly agree with its implication that there’s a real and urgent need for discipline around business-rules. But the reason for the alarm-bells is that it’s promoting business-rules as ‘the answer’ – and for the most part IT-based ‘business-rules engines’ at that.

Which us places straight back in Taylorist territory, along with all those other classic IT-driven business failures such business-process re-engineering. Not a good idea…

The reasons why it’s not a good idea are three-fold:

• placing all the business-rules into an automated system will lead to a ‘fit and forget’ attitude unless there is a very strong emphasis on rule-maintenance – one of many ‘human factors’ that were forgotten about in BPR’s rush to ‘IT-ise’ all business processes
• identification and codification of business-rules assumes that the rules that can be derived from the people who run the existing processes are sufficient, invariant, accurate and complete – which, as early-generation knowledge-management also discovered, they rarely are…
• the viability of using automation for decision-making is dependent on the context – a fact of which frighteningly few IT-system designers seem to be aware

There seems to be a view that everything can and must be reduced to simple rules, following a cart-before-horse thinking that everything should be done by IT, and simple rules are what IT handles best. In other words, dangerously back-to-front. It’s bad enough trying to get anything useful out of IT for decision-support; but using IT for all decision-making – which is the ‘nirvana’ that the article would evidently prefer – is likely to be lethal. And I don’t quite know what we as enterprise-architects can do to prevent this headlong rush into repeating the exact same mistakes as in BPR and the rest – all that’s different this time is that it’s more explicitly coming from the ‘rules’ part of the process, rather than process-implementation overall.

This is clear if we look at it from the perspective of context-space mapping:

The point is that there’s a spectrum of abstraction of rules: principles sit at the low-abstraction end of this spectrum, rules sit at the high-abstraction end – in fact a conventional ‘rule’ is actually an extreme abstraction of a principle that applies to a specific context. If we try to use the wrong level of abstraction, especially in the wrong context or wrong type of context, we are all but guaranteed to hit serious trouble. And I see little to no awareness of that fact in most of the current literature on business-rules: instead, there seems to be an assumption that just about everything can be reduced to simple binary rules that can be implemented by simple IT, because that’s what we want to happen. In other words, the entire approach seems driven by little more than wishful thinking – which again is not a good idea…

IT-systems and simple business-rules work well together: both operate on a binary true/false logic, and both will enable high-speed binary-logic decision-trees – in other words, over on the lower right-hand side of the usual Cynefin-derived context-space base-map.

Most IT-based analytics – over on the upper-right of the base-map – work on the same binary logic as the simple systems, but introduce the ability to handle more and more layers of complication. The catch is that each layer of analysis takes a finite amount of time – which takes it further away from the ‘Now!‘ demanded by real-time decision-making. And the only real result of increased computing-power has been to increase the levels of complication in the analytics, sometimes beyond anyone’s ability to understand it – as was the case with the software systems used in many of the risk-calculation models that drove the current financial crash.

IT-systems are still not good at handling non-binary modal-logics – “the logic of probability, possibility and necessity”, such as expressed in the MoSCoW set of requirements-priorities of must, should, could and can wait. Humans are very good at modal-logic; IT isn’t. James Taylor’s article refers to pattern-based decision-making, which places it somewhat on the upper left of the base-map – but note again that each pattern-match must always take a finite amount of time, and it does not fit well with the underlying binary-logic of current IT-systems. Using IT as decision-support for human decision-making is generally okay, but the more that IT is involved, the higher the risk of what Dave Snowden describes as ‘pattern-entrainment’ – in other words, premature selection of a pattern, trying to force-fit a pattern to the context rather than ‘listening’ to the context itself. Current IT is getting much better at near-real-time pattern-matching, such as face-recognition or smile-recognition on most present-day digital cameras. Yet as anyone who’s used such systems would know, they’re nowhere near accurate enough to decide when a picture is actually any good – and sometimes we don’t want a smile in the picture. Much the same applies in business: using automated pattern-matching is great for decision-support, but extremely dangerous for decision-making.

And no IT-system is likely to be much good at dealing with real-time chaos, ‘the new’, where no possible pattern exists because it is new – but again, real people can handle decision-making in such contexts via skills and principles. In those contexts, there are no rules – and yet business-rule proponents seem to promote the delusion that their ‘business-rule engines’ can handle everything.

So I’m wary: very wary. Before letting any of such systems loose on any real-world context, I would want to make very sure that they’ve done the appropriate context-space mapping, and matched the decision-making methods to the respective contexts. But I don’t see much evidence of that: what I see instead is way too much wishful-thinking, and an almost desperate desire on both the business-side and the IT-side to try to force the world to fit their respective delusory dreams of ‘order’ and ‘control’. Oh well… Guess we have to wait and let them fail yet again, even more expensively, and then set out to tidy up the mess? – though I do worry that we’re getting close to the point where we’re no longer able to afford such expensive mistakes, in any sense of the word…

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‘