On sensemaking-models and framework-wars

How do we use sensemaking-models in enterprise-architecture? What’s different about this discipline that can so often cause such use to become problematic?

I know I need to move on to more of that current series on power and politics in enterprise-architecture, but to be honest I’m still smarting from some particularly unpleasant attacks during that recent attempt to do a review of the updates to Cynefin’s handling of the so-called ‘Chaotic’ domain, and I really do need to deal with that before I can move forward.

I do acknowledge that, as one of the lesser putdowns in that farrago put it:

I can’t help thinking that it’s possible to think too much

Yet ‘thinking’, and the related reflection and reassessment and the like, is what I do: it’s the deep core of my work, and where I believe I add most value to this ‘trade’. So that’s the way I’ll have to handle this here too.

To go back to the start here: How do we ‘make sense’ in enterprise-architectures and the like? What role(s) do predefined frameworks play within that process? And how do we apply that ‘made-sense’ to our everyday challenges in real-world business-practice?

This isn’t about trying to define ‘the perfect framework’, or ‘the correct way to use a framework’, but about how frameworks are actually used in practice. Which is rarely the same at all…

[Highly-relevant interrupt: I’ve just seen Chris Lockhart’s new post ‘Frankenframeworks‘ – absolutely brilliant! – and essential reading to set the context here. Go there first, then come back here: what follows will make a lot more sense if you do.]

I’ll describe this mainly from my own experience, but it’s what I’ve also seen, in some variant or another, from just about every enterprise-architect I know, so I don’t think I’m unique or even unusual here – perhaps a bit more pedantic about self-observation and suchlike in subjective-research, but that’s about it, I think?

Anyway, the supposed ‘proper’ way to do sensemaking would be something like this:

• 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

Hence, for example, we see a toolset-vendor who carefully catalogues every model-type in the enterprise-architecture space in terms of the Zachman framework, with each model-type assigned to precisely one Zachman cell. Or the rote-oriented use of TOGAF, step by step through the ADM, which in a typical large organisation takes around two years and delivers little to no business-value during all of that time – which is kind of difficult to justify in everyday business terms.

What we actually see most often in enterprise-architecture practice is rather different:

• 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

Or, as Chris Lockhart puts it in inimitable style, in his ‘Frankenframeworks’ post:

We need to do more of more value and do it more quickly. Put aside the endless soul-searching over frameworks. Pick one. Pick ten. Pick two and smoosh them together. Keep them and reuse them. But above all, use what works for the problem you have regardless of what the experts say.

Hence, for example, we find a very wide range of ‘Zachman-like’ frameworks with extra columns or rows or dimensions or whatever, or different labels or applications. (My own usual variant is here, if you’re interested.) And we likewise find a plethora of variations on a theme of Business Model Canvas, with extra cells, extra rows, used for different purposes: Alex Osterwalder has produced a fair few of his own, in fact, such as his new Value-Proposition Canvas [PDF]. Smoosh them together; hack, rinse, repeat; that seems to be the working norm here.

Which would be fine, except for three variously-serious problems:

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

The first problem – the unhappy originator – seems to be less common within enterprise-architecture itself: most people here seem to acknowledge that the hacks are going to happen anyway, so we usually design for hacks rather than against them. For the same sort of reasons, most of us are fairly sanguine about ownership: we generally do prefer some kind of acknowledgement, but we try not to be possessive about it – again, Alex Osterwalder has been a great exemplar here, with Business Model Canvas explicitly published under a Creative Commons licence. But people from outside of enterprise-architecture and the like – particularly those from academia – can get very upset about ‘illegitimate’ use of their models, especially if the model is not robust enough to be hacked in the first place. Yeah, it’s a problem…

The second problem – lack of metaframework-discipline – is probably more serious, not least because (in my experience, anyway) a disturbing number of people seem not to know what those disciplines are or how to use them, or even that they’re needed. In the same way that a metamodel defines the structures for a model, a metaframework and its associated methods define how to hack a framework: and there are clear, consistent disciplines about how that should or should not be done. What those disciplines are, how they work, and how they should be used for best effect, will be the main focus of what I’ll describe in the next post, on metaframeworks. When those disciplines not applied correctly – well, yeah, that’s a problem too…

The third problem – that which Chris Lockhart delightfully describes as the quest for the SUFFE™, the Single Unified Framework For Everything – is what leads to all of those dreaded ‘framework wars‘ on LinkedIn and elsewhere. The point is that there is no ‘true framework’: it’s not about purported ‘truth’ here, but about value, about usefulness, about fitness-for-purpose – which is a very different type of requirement. There is a real need for the kind of debate that creates shared-understanding: as I put it in the post on ‘The social construction of process‘, “exploring and answering the question ‘What is the process?’ is itself part of the process”, and much the same applies to frameworks too. But arguing about which framework is ‘true’ – yeah, that’s another real problem… especially in terms of the vast amounts of everyone’s energy that it wastes, and the ire that it raises…

When all three problems combine together – well, that’s when it gets decidedly un-fun… 🙁 On LinkedIn it tends to be ‘newbies’ or ‘fish out of water’ types who frankly don’t have a clue what they’re talking about, but are very keen to tell others how wrong those others are because they’re not following some supposedly-‘official’ model. Elsewhere it tends to be some outsider to the trade, or the ‘in-trade’ acolytes of some such outsider, who again don’t understand much if anything about metaframework-disciplines, but are utterly certain that they alone know ‘the truth’, and – to link it back to the discussion in those other posts on dysfunctional ‘power’ in the workplace – are very keen to prop themselves up by putting others down. The reality is that no-one wins from those kinds of games: but it’s pretty unpleasant at the time, especially for those on the ‘receiving end’ of that kind of behaviour…

To give a concrete example of what I mean, take a look at this Tweet, one of a stream of infuriatingly childish attacks that came up around the ‘Cynefin and the Chaotic domain’ review-posts:

someone who argues “biz contains chaotic, so it *is* chaotic” only needs the smallest of hints 😉

Whatever the intent, the reality is that this tittering sneer holds about as much weight as a wet paper-bag. It’s a ‘strawman’ put-down, of course, in that it doesn’t accurately reflect what I’d said in the post. But the key point is that it shows a serious lack of understanding – or even awareness – of one of the metaframework-fundamentals, namely reflexion: in this context, that ‘the chaotic’ will inherently echo outward to the larger scope. If a context contains Chaotic-type elements, then any solution there must also include capabilities to address those Chaotic elements – otherwise the solution will fail as soon as it hits up against any such elements. Failure to understand this point indicates quite serious incompetence on the author’s part: and attempting to cover up that incompetence by mocking me instead merely compounds the offence – in every sense of the term. Oh well.

Anyway…

There’s not that much we can do about the ‘unhappy originator’ problem: it’s just an occupational hazard, really. Do what we can towards keeping them as happy as possible, of course: but the reality is that this type of work does use a lot of hacks, whether they like it or not – and in most of our work, the business-need will always take priority over the ‘purity’ of the model.

And sadly, there’s probably not all that much we can do about the ‘framework wars’ problem either. Despite (or perhaps because) this ‘trade’ is riddled with inherent uncertainties, many people will try to cling on to whatever certainties they can find: and pre-packaged frameworks and overblown egos will often seem to be the only ‘certainties’ on offer. So it’s not a problem that’s ever likely to go away: all we can do is a slow, patient process of education, reminding people of the importance of ‘I don’t know‘ and ‘It depends‘, and aiming to bring the current batch of trainee-level tyros and shallow-thinkers up to speed before the next batch will barge their way onto the scene.

The one problem that we can tackle – and that should also mitigate the other two problems as well – is that of becoming clear about metaframework-discipline: about how to do those framework-hacks, do them fast, and do them well. So that’s what we’ll turn to now, in the next post in this series.