After yet more aggressive unpleasantness and put-downs over my attempts to resolve ‘the Cynefin problem’ in enterprise-architecture, I think I may have at last found the real source of the repeated miscommunications that have taken place.
The clue comes from a Tweet by Richard Veryard:
#entarch Can’t judge “fit” btwn two frameworks from within either framework, you need a metaframework (shudder).
The problem seems to be this:
- Cynefin is a framework – a model and a collection of related practices.
- It is also a metaframework, in a somewhat limited sense of ‘meta’, in that the framework and the related practices are purported to be generic and may be applied in any discipline.
- What I’ve been describing throughout these posts is a usage of the ‘Cynefin categorisation’ (Simple, Complicated, etc) – i.e. the content of the model, without specific incorporation of the related practices. (I have been explicit all along that this is what I’ve been doing, but that point seems to have been missed. 🙁 )
- This usage of the Cynefin categorisation is actually the expression of a metaframework – not a framework itself, but a ‘framework to define frameworks’. The metaframework is based on systems-theory principles, including themes such as rotation (checklists etc), reciprocation and resonance (as in ‘hard-systems’ theory etc), and recursion and resonance (as in ‘soft-systems’ theory etc), and in this specific ‘Cynefin-like’ instance uses the ‘Cynefin categorisation’ as its base-frame, for cross-comparison with other matching cross-maps for the purpose of layered sensemaking. The internal structure and foundation is thus significantly different from that used in the Cynefin framework – and at no point have I made any claim that they are the same.
- One of the key points above – as stated repeatedly in all of the posts – is that this ‘Cynefin-like’ metaframework is not ‘the Cynefin framework’: it merely uses the ‘Cynefin categorisation’ as its base-frame. Multiple ‘cross-map’ frames are then applied to the context: cross-maps from the original Cynefin model (e.g. ‘probe > sense > respond’ etc) might be used, but so might many, many others – none of which ‘are’ Cynefin. The various cross-maps are highly likely to deliver sensemaking interpretations that are different from those that would be achieved by using Cynefin alone – in fact the whole point is that it does deliver different results – and, conversely, any attempt to interpret the results solely in Cynefin terms will often make no apparent sense. It is not Cynefin – attempts to interpret it as such, or critique the results as such, are essentially operating from premises which do not apply in that context, and are inherently invalid for that purpose.
- The usage of the ‘Cynefin categorisation’ as a base-map in this way – as a metaframework – is merely one instantiation of a whole class of metaframeworks that use other key models or frameworks as base-maps. Other base-maps for such metaframeworks include extended-Zachman, Five Elements, the tetradian four-dimensions, OODA, PDCA and so on. (Some of those base-maps might use the Cynefin-categorisation as a cross-map on their own base-map – which will cause even more confusion if someone mistakenly interprets this usage of the cross-map ‘as’ Cynefin.)
- The class of metaframeworks is defined by a metametaframework, referred to as ‘context-space mapping’.
- Trying to interpret a framework (such as a single instance of a base-map/cross-map combination) from another framework (such as Cynefin) is essentially meaningless, exactly as Richard Veryard indicates in his Tweet above – the underlying premises won’t line up, so there’s no sensible or meaningful way to do a comparison between them.
- Trying to interpret a metaframework (use of the Cynefin-categorisation as a base-map in context-space mapping) in terms of a framework (Cynefin) by definition will make no sense – they’re functionally different as well as different in their premises.
- Trying to interpret a metametaframework (context-space mapping) in terms of a framework (Cynefin) will really make no sense.
- Unfortunately, all of this meaningless misinterpretation does seem to be exactly what’s happened here.
Which is odd, because such meta-relationships are not unusual: for example, every enterprise-architect is familiar with the relationship between models (e.g. UML models), metamodels (e.g. UML itself) and metametamodels (e.g. MOF, of which UML is one instantiation). Yet from the above it does seem that the main basis for all of these attacks comes down to one key person failing to understand these rather important distinctions about meta-layering.
Oh well. But I do just hope that this will at last dispose of those utterly pointless arguments, anyway?