9 years, 3 months ago

Using Cynefin in enterprise-architecture

Link: http://weblog.tetradian.com/2011/10/29/using-cynefin-in-ea/?utm_source=rss&utm_medium=rss&utm_campaign=using-cynefin-in-ea

This is in part an addendum to the previous post. The main aim here, though, is simply to provide some practical guidance on how and where the Cynefin framework should and should not be used in enterprise-architectures and the like. This advice draws on my own practical experience with use of Cynefin since 2003, and with related frameworks over the past two or three decades and more.

[Note: the focus of this post is solely on practical use and avoidance of misuse, and (I sincerely hope) should not be controversial. (In a few places I do state my personal and professional opinion, but that’s about the limit of what might be construed as ‘controversial’.)]

The core purpose of Cynefin is to support sensemaking in complex contexts, such as occur frequently in the business-domain. As such, it would be of obvious interest to enterprise-architecture and related disciplines, especially in strategy-development and in addressing ‘wicked-problems’ and ‘pain-points’ in the business context.

I regard it as important here, for enterprise-architecture, to view Cynefin as ‘just another framework’. In a sense, it’s comparable with other well-known business-sensemaking frameworks such as Business Model Canvas. The main difference is that Cynefin has more potential for general-purpose business-sensemaking, rather than solely in a single domain.

As a quick overview, the Cynefin framework consists of:

  • a core graphic, shown with varying content on a fixed base-diagram
  • a set of methods for narrative-enquiry and the like, such as ‘butterfly-stamping’ and ‘clustering’
  • a software package named Sensemaker, for visual presentation and interpretation of results

I’ll skim through these in reverse-order.

Sensemaker package

I have not used the Sensemaker package, so will make no comment there, other than to say that, from its published description, its use would seem peripheral rather than central to enterprise-architecture.

Methods

Cynefin methods are only available to those who’ve taken the Cynefin/Cognitive Edge training course.

I took the Cynefin course in 2003, and learnt the set of methods that were extant at the time; to my knowledge, not much has been added since then. Of these methods, my personal experience is that in most cases I haven’t found them useful in enterprise-architecture. (They’re no doubt valid, I just don’t happen to have found them useful for the kind of work that I do.)

For most enterprise-architecture purposes, I tend to use other narrative-oriented sensemaking techniques such as Sohail Inayatullah’s Causal Layered Analysis, and, perhaps especially, Nigel Green’s VPEC-T. I’ve also developed a variety of techniques of my own, as documented in my books on enterprise-architecture – particularly context-space mapping in Everyday Enterprise Architecture, Enterprise Canvas in Mapping the Enterprise, and Five Elements and the SEMPER diagnostic in SEMPER & SCORE.

The only Cynefin technique that I do still use regularly is ‘clustering‘, moving annotations on sticky-notes into clusters that seem to make sense. Note, though, that the same technique is common to most other sensemaking-frameworks, such as Business Model Canvas: see the book Business Model Generation for detailed examples of the technique and its use.

Core graphic

The core graphic is the only part of the Cynefin framework that most people see, and hence know as ‘Cynefin’. Although the layout has remained much the same since the start, the content and presentation have changed somewhat over the years. This is the current version as shown on its Wikipedia article:

Most people seem to see this as four domains in a simple two-axis frame, though without axis-labels. In fact there are not four but  five domains, including the central Disorder domain, which is fundamental to the Cynefin model.

[There’s also a sixth mini-domain or sort-of-domain, shown as the little squiggle at bottom-centre. I forget what this represents, but it’s rarely mentioned, does seem to be optional, and does not seem to be fundamental to the model’s use.]

The four domains – Simple, Complicated, Complex, Chaotic – represent distinct ‘ways of knowing’, or ways of making sense of ‘the unknown’, the central domain of Disorder. The central domain always exists; the other domains are, in effect, overlays on top of Disorder.

I’ve not seen any explicit description as to why the domains are placed in this specific layout. The one part that often is explained is a distinction between ‘order’ – Simple and Complicated – versus ‘unorder’ – Complex and Chaotic – which in this layout is, in effect, a kind of horizontal axis. Yet there does not seem to be any vertical axis as such, and there are certainly strong assertions that it should not be interpreted as a two-axis frame.

Various texts are overlaid onto the four domains to identify and describe these ‘four ways of knowing’. Two of these sets of texts are present in the diagram above; I’ve seen perhaps half a dozen other sets over the years, in various versions and presentations. These texts would represent the ‘official content’ for the framework.

There are also two other parts of the framework that are less well-known, and in general only appear in certain earlier versions of the diagram: the Cynefin-dynamics, and the relationship-mappings. The Cynefin-dynamics represent moves between sensemaking-domains, and are important in making sense of a total context, especially over time; the relationship-mappings – typically shown as little ‘pyramids’ – represent strong or weak ties in relation to a hierarchy, and are significant for social-network mapping and the like.

So to summarise, the core diagram consists of:

  • mandatory: central domain of Disorder
  • mandatory: four sensemaking domains, currently labelled Simple, Complicated, Complex and Chaotic
  • mandatory: graphic layout, including curved boundaries (not straight boundaries) between domains
  • mandatory: specified sets of text-content, mapped to each of the four sensemaking-domains
  • optional: sixth (unlabelled) domain
  • optional: order / unorder axis, implied as horizontal on this graphic-layout
  • optional: Cynefin-dynamics
  • optional: relationship-mappings

There may be a few other optional items, but essentially that’s it. So if we turn this round, we can then see some of the constraints on the potential use of the Cynefin core-diagram in enterprise-architecture and elsewhere:

  • any model that does not include a central domain of Disorder is not Cynefin
  • any model that does not use four sensemaking domains, or uses other labels for the four domains, is not Cynefin
  • any model that uses a different graphic-layout, or that uses straight domain-boundaries, is not Cynefin
  • any model that uses any domain-partitioning other than as specified is not Cynefin
  • any model that uses any text other than that formally specified, is not Cynefin
  • any model that applies any vertical axis is not Cynefin
  • any model that applies any horizontal axis other than order/unorder is not Cynefin
  • any model that describes any inter-domain dynamics not otherwise formally specified is not Cynefin

In practice, what this comes down to is the following:

  • there are very tight constraints on what can be called ‘Cynefin’
  • in enterprise-architecture, most usages of what is described as ‘Cynefin’ are actually not Cynefin

Clearly there’s a very important distinction here between usage of Cynefin-proper, and the use of ‘Cynefin-like’ concepts that are either incorrectly described as ‘Cynefin’ and/or used in ways that differ from those specified in Cynefin-proper.

I perhaps need to emphasise this point, for everyone’s sake: anything that does not conform exactly to the Cynefin specification should not be called ‘Cynefin’. In practice, this probably applies to most usage of what is called ‘Cynefin’ in enterprise-architecture.

On usage of Cynefin-proper in enterprise-architecture, my own personal experience is that it can be useful, but is incomplete and even misleading in certain areas – particularly for sensemaking and decision-making on uniqueness and the like in the Chaotic domain, as I’ve described in several posts here. Cynefin does have some potential uses in enterprise-architecture and the like, but for almost all of these there are appropriate alternative tools, techniques and frameworks. Overall there seems to be so much confusion, so many misconceptions, and so much baggage around the whole framework, that, wherever practicable, it’s far safer and far wiser to use those alternatives instead. To be blunt, I would strongly recommend that, unless absolutely unavoidable, Cynefin-proper should not be used anywhere in enterprise-architecture and related disciplines.

Use and re-use of Cynefin-related concepts

Some of those alternatives may incorporate use or re-use of concepts that are either directly or indirectly related to some of those within Cynefin-proper. Key examples include:

  • the SCCC categories – Simple, Complicated, Complex, Chaotic
  • the order / unorder axis – Simple/Complicated versus Complex/Chaotic
  • relationship-strength mapping
  • context-space mapping using the Cynefin core-graphic as a base-map
  • domains as disciplines, and inter-discipline dynamics

The SCCC categorisation is enormously valuable in enterprise-architecture, with applications in a very broad range of types of sensemaking and decision-making. The categories are often used within a single-axis or two-axis layout, in a wide variety of forms, in a very wide variety of cross-maps. Note, though, that unless it uses the exact layout of Cynefin core-graphic and other constraints as above, this is not Cynefin.

The order / unorder axis and its crosslink to the SCCC categories is also enormously valuable in enterprise-architecture. It indicates, for example, where current IT-systems are likely to work (order) or not-work (unorder). It also indicates the crucial transition from ‘controllable’ (true/false logic) to ‘not-controllable’ (modal-logic, ‘direction’ rather than ‘control’) at which the Complicated transitions into the genuinely Complex – a point which many IT-folk still fail to grasp. And it also marks a key distinction that is fundamental to service-design and much more: that in the order-domains Einstein’s dictum applies, that ‘madness is doing the same thing and expecting different results’, whereas in the unorder-domains the dictum inverts, such that ‘madness is doing the same thing and expecting always to get the same results’. Although it’s used in Cynefin, the ‘unorder’ term was originally developed by Cynthia Kurtz: see her weblog for more details about her own Confluence framework. Note, though, that if used outside of the context of Cynefin-proper, this is not Cynefin.

The relationship-mapping is useful mainly in specific aspects of enterprise-architecture, such as social-network mapping or organisation-architecture. It was incorporated into early versions of Cynefin, but was again originally developed by Cynthia Kurtz: see the updated ‘Braid’ model on her weblog. Again, though, note that if used outside of Cynefin-proper, this is not Cynefin.

As described in the previous post, context-space mapping is a sensemaking technique that uses an arbitrary base-map and arbitrary additional overlays – all selected according to context and need – as a ‘seed’ around which appropriate insights may coalesce. Because of the usefulness of the SCCC-categorisation, the Cynefin core-diagram is often used as a base-map for this purpose. Yet because the core-diagram is used here in a manner that is different to Cynefin-proper, this is not Cynefin.

There are many other frameworks that use a similar layout, typically describing domains as disciplines, and the concomitant inter-discipline dynamics. For example, the book Disciplines of Dowsing highlights an adaptation of the classic Jungian frame, cross-mapped to the SCCC-categorisation, in a format that, with some ‘translation’, is directly reusable in enterprise-architecture. That frame includes a summary of inter-discipline (inter-’mode’) context and dynamics, such as:

  • Role of mode is…
  • This mode manages…
  • This mode responds to the context through… (i.e. prioritises, for sensemaking)
  • Mode has a typical decision-sequence of…
  • Use this mode when…
  • We are in this mode when…
  • ‘Rules’ in this mode include…
  • Warning-signs of dubious discipline in this mode include…
  • To bridge to [other mode], focus on…

Note, though, that although this and similar frameworks may use Cynefin-related concepts such as the SCCC-categorisation, and may even use the same terms, they are not the same as the Cynefin framework. In other words, this is not Cynefin.

Cynefin-proper is very tightly constrained, and has only a narrow range of potential uses in enterprise-architecture.

‘Cynefin-like’ or ‘Cynefin-related’ ideas and frameworks, as summarised above, are not so tightly constrained, and have a very wide range of potential uses in enterprise-architecture. For example, in practice, most so-called ‘Cynefin’ in enterprise-architecture – such as in Nigel Green’s ‘A thinking framework for Business/IT ‘Systems’ behaviour based on Cynefin‘ – is actually some form of context-space mapping under a somewhat different guise. It’s unfortunate that the term ‘Cynefin’ is used for this, not least because it gives the impression that Cynefin-proper is used far more often in enterprise-architecture than it actually is.

But perhaps the most important point there is that, in the vast majority of usages of ‘Cynefin’ in enterprise-architecture, this is not Cynefin.

And if it’s not Cynefin, we shouldn’t label it as such. Simple, really. :-|

Over to you?