Metaframeworks in practice: Introduction

If most of the frameworks we use in enterprise-architecture are ‘smooshed together’ from other frameworks, according to the needs of the context, then how do we do that ‘smooshing together’?

More to the point, when and how and why should we do it or not-do it – and if we do it, how do we do it well?

Those are the key challenges that came up from the previous two posts ‘On sensemaking-models and framework-wars‘ and ‘On metaframeworks in enterprise-architecture‘, and also Chris Lockhart’s brilliant ‘Frankenframeworks‘ post.

Hence, clearly, a need for some kind of ‘how-to’. With real-world examples.

The reality is that it’s a personal skill, hence just about everyone does it their own way in the end. Yet there are some themes – some aspects of method – that are probably common across the board, and I’ll aim to pick these out as we go along.

What I’ll do over this upcoming five-part series is to summarise five examples from my own work over the past few years:

• Part 1: Zachman plus tetradian -> extended-Zachman
• Part 2: TOGAF plus PDCA -> iterative-TOGAF
• Part 3: Chinese wu xing plus Group Dynamics plus VPEC-T -> core Five Element
• Part 4: Jung plus swamp-metaphor plus systems-practice plus Kurtz/Cynefin plus OODA plus many-others -> context-space mapping -> SCAN
• Part 5: Business Model Canvas plus Viable System Model plus extended-Zachman plus many-others -> Enterprise Canvas; plus Five Element plus Market Cycle -> Enterprise-Canvas dynamics

For each of these, I’ll describe:

• the business need behind the respective end-framework
• the process and reasoning behind adding each existing framework to the mix
• relations with originators of each existing framework – i.e. to mitigate any ‘unhappy originator‘ risk
• applications for the resultant ‘smooshed-together’ end-framework

Before we go into any of the examples, though, let’s do a quick review of the overall context and process, as described in those posts above.

Metaframeworks: context and process

Chris Lockhart’s ‘Frankenframeworks‘ post summarises the overall need, about the overall sensemaking / decision-making process within enterprise-architecture, and how sensemaking-frameworks are used within that process. From Chris, we can paraphrase the requirements for frameworks themselves as follows:

• easy to interpret, fast to deploy, amenable to adaptation, extensible
• can be put together or merged with others for the needs of a given situation
• shouldn’t fall apart if some part of it is removed because it doesn’t suit the problem at hand
• may be used, not-used, re-used or adapted according to its fit with the business-need (we fit frameworks to a context, not context to ‘the’ framework)
• supports responsiveness, clarity and agility
• helps architecture to deliver value to the stakeholders, and deliver it fast

We then also need methods to use those frameworks in a ‘meta-’ manner – and the discipline to use those methods in a way that will work well.

From ‘On sensemaking-models and framework-wars‘, we noted the fundamental differences between, on the one side, the usual ‘best-practice’-style expectation about how sensemaking ‘should’ happen in enterprise-architecture:

• identify the context
• identify the one correct sensemaking-framework that is designed to apply in that context
• follow the official instructions on how to use that framework
• derive the valid view of the context, as guided by that framework

Compared to the more fluid reality, derived much more from context-specific needs:

• before starting, identify the business-purpose for the sensemaking exercise
• make an intentionally-arbitrary guess about the probable nature of the context
• pick a framework, almost at random, out of the toolkit – whether or not it nominally fits the context
• optionally yet usually, hack the framework in some way, adding or removing or adapting components
• optionally yet often, overlay the framework on any other frameworks that have already been applied to the context
• apply the resultant hack to the current view of the context
• see what comes up from this – including incongruities and mismatches – and note how it changes the view
• repeat the process with other frameworks and/or hacks, until some kind of useful sense is made – where ‘useful’ is defined in terms of the identified business-purpose

We also noted three significant risks to the process and the quality of the overall results:

• the hacks and ‘smooshing-together’ may be done without adequate attention to the metaframework-disciplines and methods that make it all work
• the originator of the framework may be unhappy about any hack of this kind
• people start arguing about which original and/or hack is ‘right’ or ‘true’ or ‘best’ – the dreaded ‘framework-wars’ and suchlike

The last of those risks is best summarised as an ‘occupational hazard’ that applies across the whole of the enterprise-architecture space, and can be tackled as part of a more generic process of getting people to let go of the ‘need’ to hold onto a spurious sense of ‘certainty’ where, almost by definition, no absolute certainty can exist. The first two risks, though, are issues for which we may or must apply explicit mitigation within any application of metaframeworks.

From ‘On metaframeworks in enterprise-architecture‘, we noted that to understand a framework, we need also to understand:

• relations between the ‘boxes’ of the framework
• the dynamics of and for moving ‘between the boxes’
• the guiding context, concept and constraints for the overall frame

We also noted that a metaframework is ‘just another framework’ – it’s not fundamentally different from any ‘ordinary’ framework. Probably the only significant differences are that it often uses layering, or overlays of frameworks on top of other frameworks, in order to build a richer and more nuanced view of the respective context; and also tends to place more emphasis on guiding-principles than on the nominal structure of the framework. The guiding-principles I use throughout my own work with metaframeworks would include:

• rotation – switching between views or ‘boxes’ in a framework or list
• reciprocation – balance across a system
• resonance – feedback-loops in a system
• recursion – self-similar patterns at every scale
• reflexion – the whole contained within the part
• mismatch – cognitive-dissonance to break ‘out of the box’
• serendipity – allow ideas to emerge ‘at random’

Note that these principles apply both to the frameworks being worked on and ‘smooshed-together’, and also to the metaframework itself. For example, that list immediately above is itself a rotation, applied recursively both to and as a metaframework in its own right, to create balance (reciprocation) across the whole framework.

It does take a bit of practice to get used to how metaframeworks really work: but once we do, it enormously opens up the possibilities for the way in which we can work within enterprise-architecture and like.

Anyway, we’ll stop there for now, but we’ll keep a link back to this post as a base-reference as we go through those worked-examples.

The first example we’ll explore, using this, is an extended version of the Zachman framework, developed for a logistics context. Onward, then?