Tom Graves

(This series of posts explores a concept of ‘problem-space’ versus ’solution-space’ which in part demonstrates alternative uses and interpretations of the Simple / Complicated / Complex / Chaotic categorisation originally described in the Cynefin diagram. It must be emphasised that this is not about the Cynefin Framework; for details on Cynefin, please contact Cognitive Edge.)

This post represents yet another attempt to describe certain fundamental differences in approach from twf (aka ‘That Welsh Framework‘ – so-called because we’re no longer allowed to use its official name at all) and to find an alternative term that might reduce the ongoing friction in that quarter.

To do this, we need to go right back to first-principles: the core concept of context-space, which eventually leads us to context-space mapping.

(Another long-ish post: more after the ‘Read more…’ link.)

Read more…

(This series of posts explores alternate uses of the Simple/ Complicated / Complex / Chaotic categorisation originally described in the Cynefin diagram. This discussion is not about the formal Cynefin Framework; for details on the Cynefin framework proper, please contact Cognitive Edge. The term ‘beyond-Cynefin’ is solely a placeholder to indicate this separation of concerns.)

Back to theory again – apologies… – following on from comments on the previous posts, especially ‘On meta-methodology‘.

The aim of this post is to try to create a bit more clarity around the notion of ‘problem-space’ versus ’solution-space’. To do this, I’ll draw on a variety of sources, ranging from dowsing to enterprise-architecture, Sigurd Rinde’s work on ‘barely-repeatable processes’, activity/response-models such as OODA and PDCA, and much more besides.

Will again be long, hence more after the ‘Read more…’ link.

Read more…

(This is part of an ongoing series that explores alternate uses of a generic conceptual categorisation originally described in the well-known Cynefin diagram. This discussion is not about the formal Cynefin Framework; for details on the definition and use of the Cynefin framework proper, please contact Dave Snowden at Cognitive Edge. The term ‘beyond-Cynefin’ is here used solely as a placeholder to indicate this separation of interests.)

Here’s another collection of ‘Cynefin-like’ cross-maps that I’ve found useful for sensemaking in enterprise-architecture and related work:

• ISO-9000 quality-model
• Skill-levels
• Automated versus manual processes
• Asset-types
• Data, information, knowledge, wisdom

More details after the ‘Read more…’ link.

Read more…

(This is part of an ongoing series that explores alternate uses of a generic conceptual categorisation originally described in the well-known Cynefin diagram. This discussion is not about the formal Cynefin Framework; for details on the definition and use of the Cynefin framework proper, please contact Dave Snowden at Cognitive Edge. The term ‘beyond-Cynefin’ is here used solely as a placeholder to indicate this separation of interests.)

Another collection of ‘Cynefin-like’ cross-maps that I’ve found useful in various aspects of my enterprise-architecture work:

• Repeatability and ‘truth’
• Marketing versus sales
• The ‘Plan / Do / Check / Act’ cycle

More details after the ‘Read more…’ link.

Read more…

(This is part of an ongoing series that explores alternate uses of a generic conceptual categorisation originally described in the well-known Cynefin diagram. It should be emphasised that this discussion is not about the Cynefin Framework, which is a distinct body of practices based on scientific research. For details on the definition and use of the Cynefin framework proper, please contact Dave Snowden at Cognitive Edge. As this broader usage of the categorisation does not yet have a specific name, the term ‘beyond-Cynefin’ is here used solely as a temporary placeholder to indicate this separation of interests.)

‘Cynefin-like’ cross-maps

I first started using what we could describe as ‘Cynefin-like’ models several decades ago, such as in my book Inventing Reality (first published 1986, current print-edition available here). I’ve found them immensely valuable in a very wide range of applications, especially in disciplines such as enterprise-architecture that necessarily cover the entire scope of a context. The key to its usefulness is that the model’s categorisation provides a consistent base-map for all manner of cross-maps, each of which provides new insights about the context.

Typical characteristics of a ‘Cynefin-style’ base-map include:

• universality: the model purports to cover the entire scope of a given context
• sensemaking: the purpose of the model is to guide sensemaking and decision-support, rather than (for example) design and implementation of a specific ’solution’
• simple partitioning: the model divides the context into a small number (typically 4-5) of regions or ‘domains’ (e.g. the Cynefin set of ‘Simple’, ‘Complicated’, ‘Complex’ and ‘Chaotic’), and often including a ‘none-of-the-above’ region (e.g. the Cynefin central region of ‘Disorder’)
• fluid boundaries: the boundaries between regions are not rigidly fixed (as they are in e.g. a two-axis matrix), and may be allowed to move, blur and/or be somewhat porous
• usage-dependent layout: the layout of the model may not be semantically significant (as it is in e.g. a two-axis matrix) – layouts are often two-dimensional, but may be single-dimension horizontal or vertical, or multi-dimensional such as the four-axis/three-dimension tetradian

(More after the ‘Read more…’ link.)

Read more…

(This is part of an ongoing series that attempts to resolve problems in (mis)interpretation of the Cynefin framework, and in particular the commonly-used Cynefin diagram. For the correct interpretation and use of the Cynefin framework and Cynefin techniques, please contact Dave Snowden at Cognitive Edge.)

The standard Cynefin diagram is as follows:

Diagram by Dave Snowden, Cognitive Edge (image: public domain)

As the Wikipedia article states, “The model provides a taxonomy that guides what sort of explanations and/or solutions may apply.” Unfortunately, this is a generic model that lends itself to multiple interpretations, only one of which is ‘correct’ Cynefin. There are also multiple uses of the concepts and conceptual space summarised in the model’s taxonomy and pathways, of which, again, only a specific subset may legitimately be described as Cynefin.

It is therefore important to state that what follows is not ‘Cynefin’, yet necessarily uses what is in essence much the same taxonomy (see ‘Framework role and purpose’ and ‘Similarities to Cynefin’ in the previous post ‘Solution-space: beyond Cynefin?‘).

The central theme in this ‘not-Cynefin’ framework is the concept of ‘problem-space’ and ’solution-space’.

Problem-space is the context of the problem. Part of this is repeatability, or perceived cause-effect relationships, which can usefully be mapped using the same ‘Cynefin’ taxonomy:

• Simple: very high perceived repeatability, in accordance with simple linear cause-effect rules
• Complicated: linear (repeatable) cause-effect relationships, but may involve multiple factors, delays and feedback-loops
• Complex: cause-effect relationships are context-dependent – for example, where the effect itself becomes the cause
• Chaotic: no perceived cause-effect relationships

(The central region of ‘Disorder‘ is always ‘chaotic’, by definition, because it is the starting-point before any cause-effect relationships can be determined; the Chaotic-domain of problem-space applies where some or all of the problem continues to show no perceivable cause-effect relationships.)

Solution-space is the context and characteristics of the solution – i.e. the methods used to resolve the perceived problem. This too can be usefully mapped using the same taxonomy:

• Simple: the solution uses rules based on linear cause-effect logic
• Complicated: the solution uses analytic algorithms allowing for feedback, delays, etc, but are ultimately based on linear cause-effect logic
• Complex: the solution uses context-sensitive heuristics, guidelines and iterative re-assessment, in which the problem is continually ‘re-solved’ rather than ’solved’
• Chaotic: the solution uses principles to guide creation of uniquely context-dependent results

(Note: these are only one-line summaries, not formal definitions!)

The process of finding an appropriate solution to a specified problem can be mapped as a pathway across solution-space. To succeed (i.e. to be effective), the ultimately-selected solution(s) must map appropriately to the context of the problem in problem-space. Note that although in some cases a problem may be situated in just one specific location in problem-space, it is more common for it to occupy a region or even to have components that spread out across multiple regions. For example, a context might be mostly resolved by a rules-based automated process (Simple) but also ’special cases’ that may need to be ‘escalated’ to an algorithmic system (Complicated), a manual review (Complex) or specialist expertise (Chaotic) for a ‘one-off’ incident. The overall solution must resolve all components in problem-space.

The core concept in the use of this framework is recursive meta-methodology. For example:

• a method in solution-space acts on the problem in problem-space
• a methodology selects an appropriate method
• a meta-methodology selects an appropriate methodology
• a meta-meta-methodology selects an appropriate meta-methodology

…and so on. A methodology is a path within solution-space; a meta-methodology is a path in another layer of solution-space; in effect, the layers may be nested indefinitely, but must ultimately all resolve to a set of methods that address the actual problem in problem-space.

The ultimate aim of all of this is to find methods that are appropriate and effective for any given problem, in any business context (such as my primary field of enterprise-architecture), or in any other field, as required.

I’ll stop here for now, but will give more explanation and illustrative examples in later posts in this series.

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?‘

The previous posts on ‘chaos and Cynefin’ were intended to contribute to an ongoing debate about how to use concepts from the published Cynefin framework and the like, and particularly to underpin a systematic exploration of what many Cynefin aficionados would describe as the ‘Chaotic domain’. It’s evident that there’s a real perceived need there, because overall I’ve so far had several hundred reads, several dozen re-Tweets (particularly via knowledge-management thought-leader David Gurteen and management-consultant Paul Jansen, for which many thanks), and a lot of constructive comments and feedback – all of which have been very helpful.

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

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

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

To do that, we need to identify:

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

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

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

Read more…

A few days back, one of my fellow Twitterers (I forget who – my apologies) pointed me to a brief video, ‘Context is King‘, by futurist David Houle. His theme in the video and elsewhere is that we are in an “evolution shift” from ‘the Information Age’ to what he calls ‘the Shift Age’. In the video he suggests that:

In the Information Age, the phrase was “Content is King”. While that may still be true, in the Shift Age, “Context is King”

Yet whilst that also “may still be true”, it doesn’t go anything like far enough. At the very least, we need to add ‘connections’ to that list, and probably ‘purpose’ as well – and, perhaps most important, the integration that links all of those dimensions together.

(Oh dear, yet another one that’s getting a bit long, and probably a bit too abstract too. Mainly enterprise-architecture and the like, so click on the ‘Read more…’ link if that’s of interest to you.)

Read more…

Been having a long interaction on Twitter over the last couple of days with Jon H Ayre (otherwise known as ‘The Enterprising Architect’, @EnterprisingA) and others, about enterprise-architecture frameworks.

(If you’re not interested in enterprise-architecture, probably best to skip this one, as it’s gonna be long; otherwise click on the ‘More info…’ link.)

Read more…

This is in effect a continuation of the previous post on Zachman and capability, following on from some further comments on Microsoft architect Nick Malik’s original post on business-capability.

Nick kindly described my comments as ‘extremely interesting’, and perhaps even more kindly remarked that:

Your model is the first honest attempt I’ve seen to remove “Actors” from the ZF [Zachman Framework] and replace that column with Capabilities under the notion of “Who.”

He was concerned, though, that changing Zachman’s ‘Who’ to ‘Capability’ means that we then lock out what Zachman also parks under ‘who’, namely organisational structures:

I’d be concerned about your approach, however, because you leave no room for the combination of organizational structures with other architectural elements, because you replaced the organizational structures with capabilities.

But from my view he doesn’t need to worry, because organisational structures are in the wrong place anyway in Zachman: the correct place is under ‘Location’ – Zachman’s ‘Where’. Or that’s part of it, at least. The point is that organisational structures are kludged into ‘Who’ in Zachman because his model is missing an entire dimension (or more than one, in fact). We need to resolve this absence before we can make sense of org-structures in a Zachman-like taxonomy. The main ‘extra dimension’ that I use relates to asset-categories:

• physical (’things’)
• virtual (e.g. information)
• relational (e.g. links between people and/or groups of people)
• aspirational (e.g. brand, morale, purpose)
• abstract (’none of the above’, such as finance)

In essence, an organisational structure is a map of relationships between relational locations (i.e. ‘where : relational’ links), in much the sense sense that a physical network is represented by a map of relationships between physical locations. That’s the primitive, but we more often see it as a member of a broader composite: for example, a business-unit is typically a composite of ‘where : relational’ and ‘capability + function’ (i.e. ’service’). Any change to any of the underlying primitives will change the composite, and hence – in that example – the role, purpose and placement of the business-unit.

Nick expressed some concerns about the relationships between primitives and composites, especially in relation to capabilities:

You have correctly stated that capabilities need to be combined with other things to be interesting, and that “molecules can be based on simpler molecules, in the same way that DNA is based on simple molecules.”

Just as you can take a molecule and add an atom to produce another molecule, I believe that you can take a capability and add a relationship to an architectural primitive and get another interesting composite.

But, can we say that capabilities are, or are not, constructed from existing primitives?  That’s an interesting problem, and one that I don’t have an easy answer for.  Just as the effort to move up or down a row in the ZF is more of a transformation than a construct, is it possible that the capability is a construction that sits on a fictional row, above row zero, that represents not one owner’s viewpoint, but ANY owner’s viewpoint?  That, in fact, the capability is a transformation above a composition of people and process?

To me this stems from a slight misunderstanding about the roles of primitives versus composites in architecture: we need to resolve back to primitives in order to understand our options for re-use and redesign, yet almost everything in the real world will be some kind of composite.

For example, on its own a ‘capability’ is almost meaningless: until it’s combined with a function (Zachman ‘How’) into a service, it literally has no function. But by modelling capabilities separately, as distinct primitives, we enable alternate combinations of capability and function to give different effective services (and hence support different processes). This also gives us a better understanding of what’s needed when we substitute one capability for another whilst maintaining the same nominal function, such as in process-reengineering or disaster-recovery.

To me, capability is a nominal primitive, though it has some characteristics of a kind of ‘compound-primitive’. On one side is the asset-type(s) to which it applies: physical, virtual, relational, aspirational, abstract, or any combination of these. (For example, a sales-capability applies primarily to relational assets, but is usually linked to other asset-categories as well – information, brand, product and so on.) On the other side is what we might call the ’skill-level’: rule-based, analytic, heuristic and principle-based. Crucially, machines are only well-suited to the first skill-level, and IT to the first and second; IT can be used for decision-support (but not decision-making) in the third; and is all but unusable in the fourth. Capability-modelling allows us to determine the extent to which IT should and should not be used in a given context, and what human skills will be needed to fill in the gaps.

I would agree that any move up and down the Zachman rows is a transformation rather than a construct. As described in the framework summary – http://tetradianbooks.com/2008/12/silos-frame-ref/ – each row upward is another level of abstraction, and each row downward adds another component to the modelling-requirements. The vertical dimension is also in effect a spectrum of time, from nominally infinite (row-0) to unchangeable past (row-6). So the same nominal ‘capability’ can be viewed in multiple ways, sometimes as “one owner’s viewpoint”, sometimes “ANY owner’s viewpoint”, depending on the chosen level of abstraction – much as the multiple perspectives in data-modelling, from business to logical to physical and so on.

I do take Nick’s point that we could view a (business) capability as “a transformation above a composition of people and process”. Yet if we do so, we’re actually using the same word – capability – to mean two very different things: a primitive of “ability to act on something” (hence ‘capability‘), contrasted with the complex composite of people, business structure, business-relation, function, process, service and capability that we would describe as “the capabilities and role of a business unit”. We can get away with such blurrings in everyday business conversations, perhaps, but we can’t do so in a taxonomy for enterprise-architecture: we need the precision of proper usage of terms, or we’ll end up in an unworkable tangle.

Nick also dropped in a final comment about dimensionality of a taxonomy:

IMHO: The only real limitation of the ZF is the arbitrary notion that any three dimensional representation has to be in the shape of a cube.

I don’t agree that we have to presume a cube (or equivalent ‘pure’ n-dimensional structure) for an architecture taxonomy. For example, the modified Zachman I use is more like a wedge: that ‘asset-categories’ dimension (physical, virtual, relational and so on) is crucially important at the real-world levels (rows 5-6), but we deliberately focus and de-focus on those categories in reviewing the logical-to-physical trade-offs (rows 3-4), whilst the categories are often almost irrelevant in the true abstract layers (rows 0-2).

Some of these points might sound pernickety – as indeed they probably are for basic-level IT-architecture in information-centric industries, for which Zachman’s simple two-dimensional overview is probably adequate enough. But once we extend the architecture to other industries or contexts that deal more with other types of assets – such as manufacturing, logistics, sales, defence – we must cover the full range, or we end up with an artificially restricted scope that is riddled with gaps labelled ‘Magic Happens Here’, because we have no means to describe what needs to occur there.

This also applies to any business-oriented view of IT-architecture, such as SOA, security-architecture or Enterprise 2.0, or enterprise-scale uptake of cloud-computing capabilities. A true enterprise architecture is the architecture of the enterprise as a whole – not solely the architecture of the enterprise IT.