What What? and other taxonomic tangles

One of the huge challenges of trying to make things simple in a complex context is that often it can make at first make things seem more complicated. For a while, anyway, until things settle down a bit, and the reasoning behind the simplification starts to become more clear.

I’ve been tackling a lot of that kind of challenge lately…

A main focus for me over the past few years, and past few months especially, has been around developing methods and frameworks for the kind of deeply-fractal, inherently-complex contexts that we’re facing more and more in whole-enterprise architectures and the like. By crosslinking and cross-comparing between a whole swathe of different methods and metaphors – including PDCA, OODA, ISO-9000, ITIL and TOGAF-ADM – I’d arrived at a core-method that’s both simple enough and fractal enough to be usable for any scope, any scale, any type of context, any type of content, and still remain essentially consistent everywhere across that range. We could summarise that method visually as follows:

And that’s where the fun began…

• “Where’s ‘Where’? Where’s ‘When’? It should have the full set of interrogatives!”
• “How and What should be the other way round!”
• “People are part of Process!”
• “Where comes before Why!”
• “Who comes before Why!”
• “When should come before How!”

And so on, and so on…

All of which is valid, sort-of, yes.

And yet all of which kinda misses the point.

Or two points, actually.

Maybe three, in fact.

The first point is that, regarding the ‘Why’, ‘Who’, ‘How’, ‘What’ and ‘Outcome’ in that metamethod-diagram above, they’re just labels – nothing more than that. More to the point, they’re just shorthand for the actual labels for those phases:

• ‘Why’: focus on the Purpose for that architecture-iteration
• ‘Who’: focus on the People-issues in that iteration
• ‘How’: focus on the Preparation for the actual investigation- and/or design-work for that iteration
• ‘What’: focus on the Process, the actual work for the iteration
• ‘Outcome’: focus on Performance, on what was discovered and done in the iteration, and what to do next

In other words, it’s not a big deal, and the ‘Why’, ‘Who’, ‘How’, What’ are in no way an exclusive or exhaustive list. The only reason that they’re in that sequence is because it aligns nicely with the sequence in Simon Sinek’s ‘Start With Why‘, with a small additional tweak described in my post ‘Why before Who‘. That’s all it is: it’s no big deal. Honest.

The second point is that this approach does work to provide some kind of clean, simple, consistent, reliable structure to something that’s otherwise immensely confusing, inconsistent and ‘messy’. To give some idea of just how messy these kinds of explorations really are, and how assumptions about those various interrogatives are usually hopelessly simplistic, take at look at just some of the kinds of questions that actually arise in this kind of work, and how this simple five-part structure provides at least some chance of finding a way through the mess:

— Purpose / Why:

• What’s going on here?
• What’s the question?
• Who’s asking, and why are they asking?
• Who’s paying for this?
• Who’s really paying for this?
• What’s the real question here, their real ‘Why’?
• How do we find out what the real question is?
• What are the real vision, values and principles that must apply here?
• When and where is this about?
• What timescale applies to this?
• Where should this be done, and by whom?
• Why should it be done by those people, and not someone else?
• When does the requester need an answer?
• How will we know when we have a useful and usable answer?
• What are the criteria for a useful answer?

— People / Who:

• Who’s involved in this?
• Who are the stakeholders here?
• What kind of stake are they holding?
• What kind of sharp-pointed stake can they point at us…?
• What are their drivers, their own ‘Why’ in each case?
• What kind of power-issues are there within this?
• Who’s avoiding what, and why?
• Who’s dumping what, on whom, and why?
• What will make each of the stakeholders happy?
• Who can we engage in this, how, and why?
• Who can we not engage in this, how, and why?
• How can we make this easier, for everyone?
• What are the rules, regulations, policies, guidelines, principles here?
• Who decides on each of those rules, and why?

— Preparation / How:

• What are we going to do?
• How are we going to do it?
• What framework or method fits best for what, and why?
• When should we use each method, in what sequence?
• Where should we apply each method, and with whom, for whom?
• What resources do we need to make this happen, where, and when?
• What kind of plan do we need for each stage of the action?
• How do we plan for how to change the plan, where, when and why?
• What information do we need to capture as we go along?
• What structure and more do we need for any information that we capture as we go along?
• When do we start, what’s the trigger for when we start?
• When do we stop, what’s the signal to stop?

— Process / What:

• What’s happening right now, with whom, where, when?
• What information and ideas are we capturing as we go along?
• How and where do we store any information and ideas that we’re capturing?
• How do we switch between methods and frameworks, in the midst of the action?
• Who’s responding, how, where, when and why, to what?
• What do all those rules, guidelines, principles, values and so on mean here in practice?
• How are we managing the Architect’s Mantra of ‘I don’t know‘, ‘It depends‘ and ‘Just enough detail‘?
• How do we know when to keep going, and why?
• How do we know when to stop?

— Performance / Outcome:

• What was supposed to happen?
• What actually happened?
• What was the source of the difference, and why?
• What did we learn from this?
• How did that answer the initial question?
• What was the value that we gained from exploring the question?
• What needs to change, for whom and by whom, to do it better next time?
• What commitments do we each need to make, to make that happen?
• What new questions do these answers raise, why, and for whom?

And yeah, there’ll be lots and lots and lots and lots more ‘Who’, ‘What’, ‘When’, ‘Why’, ‘Where’, ‘How’, ‘For-whom’, ‘Which’, ‘With-What’ and suchlike questions there – as anyone who’s worked in the field for any length of time would know all too well. So no, that five-part structure isn’t an exclusive list: it’s just one way to stay somewhat sane within the onslaught of the mess…

The third point is, please do remember that in reality it’s a metamethod, not a method. And yes, a metamethod is itself a kind of method, but there are crucial differences in how they’re used, or can be used – very similar to the respective relationships between Procedure and Work-instruction in ISO-9000, if you’re familiar with that.

— A method is a work-instruction that is hardwired to a single context, and can only be used reliably within that single context. In some cases, the method may be used somewhat fractally and/or somewhat recursively, yet such fractality will still be constrained to the boundaries of the initial hardwired context.

— A metamethod is a procedure from which context-specific methods can be derived. Although each individual derived-method may cover only a narrow scope, the total scope that can be covered by the set of derived-methods is bounded only by any built-in constraints of the metamethod.

The trade-off, of course is that a method looks easier to use, because everything’s already provided for us; whereas a metamethod always requires us to be much more careful about assumptions, and to think carefully about scope and scale and boundaries and so on. But the latter are very necessary things to do when we don’t or can’t know beforehand what the scope or scale or context-boundaries would be, and where we have to be very careful indeed to avoid the dangers of ‘anything-centrism’ and suchlike.

In enterprise-architecture, the TOGAF ADM is probably the classic example of this distinction. It has some limited capability for customisation, recursion and fractality, which gives it some matching capability as a metamethod. Yet overall, and despite frequent claims otherwise, it is inherently hardwired to be centred solely around IT – to be usable or reliable for IT-infrastructure architectures – and in practice is therefore much more method than metamethod.

By contrast, the method described here is explicitly designed as a metamethod. It is fully fractal and recursive – we can spin off a subsidiary iteration at any point within the cycle – and we can use almost any other type of method or framework to provide context-specific ‘plug-ins’ to the core method.

In that sense, it’s a mistake to worry too much here about what What or how to How or which Why or whatever, because they’re all just plug-ins anyway. We need to know which plug-ins to use – which is where the skill and experience of the sensemaker come into the story – but they are all just plug-ins.

Hence, for example, take that perhaps over-beloved Zachman-set of interrogatives, of What, How, Where, Who, When, Why:

They’re nicely simple, of course – easy to understand and all that. Yet the reality – much as we’ve seen earlier above – they can instead be dangerously simplistic and misleading. In practice, they’ll often only make sense at the highmost levels of abstraction, and need to undergo significant ‘translation’ and change as we move toward the real-world, first to a more realistic set of labels and emphases:

And then expand further again, with a whole new dimension that’s missing from the original:

That itself needs further expansion into its two somewhat-different yet related forms, for asset-types:

And for skills/decision-types:

And so on, and so on, and so on… – lots and lots and lots and lots more methods and frameworks where they came from, all of them suited for some contexts and usages, and not for others…

So if we tried to pack all of that into a hardwired-method, using the same approach as in TOGAF, we’d end up with something so vast and so unwieldy that it would be all but useless in practice. Instead, in the metamethod here, we use our experience to choose which methods and frameworks are appropriate to the needs of the context, and swap them in and out as the needs of the work would require.

Simplicity itself. Sort-of, anyway…

Doing it this way round might seem more complicated at the start – but once we get used to it, and how it works in practice, this really is a whole lot simpler. And the added advantage is that we really can work with any scope, any scale, any content, any context.

Yes, to make it work, we do have be more careful, to apply a lot more rigour, be more explicit about assumptions and so on. Yet we also need to know where to apply that rigour, and where not to apply it – and getting overly hung-up about ‘what What‘ and suchlike in what are merely just a bunch of labels is just not one of those useful places. In short, don’t worry about the labels, worry about the meanings – because that’s where the real value lies.

Comments, anyone, perhaps? Over to you, anyway.