Metatheory and enterprise-architecture

Blog: Tom Graves / Tetradian

“What’s the theory of enterprise-architecture?”, a colleague asked the other day. “Is there any kind of coherent and consistent theory behind it that holds it all together?”

Short answer: no.

Slightly longer answer: yes.

Or sort-of, rather. Both no and yes – both at the same time. Which is where this gets kinda weird…

From the outside, the enterprise-architecture discipline – such as it is at present – often looks an absolute shambles: a mess of competing theories and frameworks and self-styled ‘best practices’ that are rarely consistent even within themselves, let alone with anything else.

What’s perhaps hard to explain is that, at the surface level, that’s exactly what it should be. If it wasn’t that seeming mess, that’s when we should be really worried…

But even if there’s no possibility of a single, coherent ‘The Theory Of Enterprise Architecture’ – and believe me, there isn’t – there is the possibility of a single consistent metatheory, or ‘theory of theory’. That distinction between theory and metatheory is somewhat subtle, but utterly crucial.

From a theory-perspective, what we face in enterprise-architecture is a situation much like a reviewer once commented about James Gleick’s book ‘Chaos: Making a new science‘:

It turns out that behind apparent order lies an eerie kind of chaos; yet behind that chaos lies an even eerier kind of order.

Most people expect theory to be consistent, to deliver a set of rules that make sense in real-world practice, to guide that real-world practice. Which actually is true for most theory in enterprise-architecture. The catch, though, is that each specific theory applies to only to a specific subset of the scope of enterprise-architecture – and often doesn’t work well, if at all, with anything else. Hence the mess – especially if we expect a single consistent theory to cover the entire scope.

When we look at the context for enterprise-architecture, it soon becomes clear that it’s built on top of a web of inherent conflicts and trade-offs, including:

machine and human
certain and uncertain
identicality and uniqueness
predictable and unpredictable
controllable and uncontrollable
stability and change
interweaving rates of change, from very fast to very slow
interweaving lifecycles, from microseconds and less to centuries and more
shifting timeframes from past to present to future and back again
shifting perspectives and levels of detail, from vision to strategy to design to implementation to operation, and back again
a multiplicity of domains-of-interest, each with their own entity-sets, standards, jargon, governance and more

Each single theory will, at best, only be able to be consistent and descriptive across part of that overall context-space – not all of it. Hence a quest for a single ‘The Theory of Enterprise Architecture’ would not only be futile, but wrong-headed right from the start.

By contrast, a metatheory provides a consistent description of the context-space itself – the parameters and trade-offs underlying that context-space, much as above. As a theory-of-theory, a metatheory provides a frame in which to identify where each type of theory would work well – and where it wouldn’t.

Hence on complexity, for example, Roger Sessions argues that we should aim to eliminate all complexity; John Seddon argues instead that we should aim to embrace complexity, and that trying to eliminate it only makes things worse. Which of them is right? If we were looking for a single consistent theory, one of them surely must be wrong? But actually they’re both right – in the right types of context. Equally, both of them are wrong – for the wrong type of context. To use a well-worn architects’ expression, “It depends“…

The role of a metatheory is to identify the types of context for which each type of theory is ‘right’ or ‘wrong’. For this example about complexity, we can use SCAN as a visual frame for metatheory:

Which, following hints in the respective theories themselves, suggests:

Roger Sessions’ “eliminate complexity!” would work well with predictable elements such as IT-systems, on the Simple/Complicated side of the ‘edge of uncertainty’ (left-side of the red dotted vertical-line), but not work well with any part of the context on the Ambiguous/Not-known side (right-side of the line)
John Seddons’ “embrace complexity!” would work well with the inherent-uncertainties on the Ambiguous/Not-known side of the frame, but could well make things worse on the Simple/Complicated side

In effect, the metatheory behind the SCAN frame tells us where to use and not use each of those theories. And although there are some additional complications around fractality and recursion – the same patterns recurring at different levels of granularity and context – the basic principles behind that metatheory would apply, consistently and coherently, in just about every type of context. We can summarise the types of theories and tactics that typically apply best in each SCAN ‘domain’ as follows:

Each of the Tetradian tools or frameworks – such as SCAN, SCORE, Five Element, Enterprise Canvas and the rest – describes a context-space in a different way, and emphasises different types of views and hence different types of theories. In that sense, as someone complained to me a while back, there might not seem to be ‘a single coherent theory of EA’ that links them all together.

But what I’ve come to realise over the past few months is that the various ‘hooks’ and crosslinks between each those frames do make it possible to link them all together as ‘a single coherent metatheory of EA‘. Not that seemingly much-desired ‘a single coherent theory of EA’, of course – but probably closer to what we actually need for real-world practice.

In effect, it’s another illustration of what I’ve long described as the core-principle and core-purpose for all architectures: that things work better when they work together, on purpose. But here, rather than domains or databases or whatever, it’s the various forms of theory that we need to get to work better by getting them to work together, on purpose. And to do that, we need metatheory and metaframeworks that can bridge across the silos formed by each of those clusters of self-consistent but seemingly-incompatible theory.

For example, another Tetradian framework that works well as a visual-frame for metatheory is the maturity-model described in my book Doing Enterprise-Architecture:

Each of the steps presents and makes use of what are actually quite different theories of the enterprise:

Step 1 (‘Know your business’): There is an underlying human-story – enterprise as ‘a bold endeavour’ – that underpins decision-making and choices for capabilities and services within the enterprise.
Step 2 (‘Clean up the mess’): There are clear and identifiable rules that determine clean-up activities such as simplification and de-duplication.
Step 3 (‘Strategy and stuff’): Strategic choices – however complicated – can be determined and implemented via algorithms and analytics.
Step 4 (‘Work with the real world’): The real-world is inherently uncertain and ambiguous, but actions can be guided by patterns and probabilities.
Step 5 (‘Pull together’): When faced with uniqueness or the not-known, the most useful guidance is provided by principles that anchor back to the original deep-story.

The architecture-development is not literally step-by-step in that sequence: step-by-step is what we’d prefer to do, and should do wherever practicable, but Reality Department so often gets in the way towards that ideal! What the model does warn us, though, is that activities for each step in effect depend on completion of the respective parts of the ‘previous’ step(s): hence each time that we do have to do things out of step, we’re creating technical-debt – literal or metaphoric – that we’ll have to come back to and clean up again later.

(For a more detailed overview of the maturity-model, see the slidedeck ‘Stepping-stones of enterprise-architecture‘ on Slideshare.)

Each of those maturity-model steps and their respective decision-guides in turn align quite well with the decision-guides of the SCAN domains – the key difference being that Step 1 links with the overall story of the context being described via a SCAN frame:

Note that the paradigm-shift that we need in order to transition between maturity-model Step 3 and Step 4 also aligns with – in fact is demanded by – the transition across SCAN’s ‘edge of uncertainty’, or ‘boundary of effective-certainty’.

As described in the post ‘Context-perspectives and enterprise-architecture maturity‘, the maturity-model steps also align quite well with the distinct perspectives to a given context – inside-in, inside-out, outside-in and outside-out:

Which, in turn, links the perspectives-set to the SCAN frame:

This also identifies probable links between the respective skill-levels (from SCAN) that are needed in order to work with contexts for the respective maturity-model steps and perspectives:

And the perspectives-set also describes what happens between services in a broader shared-enterprise:

Which therefore provides us with further metatheory-links to the Enterprise Canvas service-modelling framework, where the perspectives-set apply to each link and flow, in every type of service:

And the shared-story that links the respective actors together:

Including governance, futures, and the broader context of the shared-story, in the market and beyond:

And thence onward to the service-context model from Enterprise Canvas, both at whole-organisation:

Or in the generic form that applies at any level of service-interaction:

Each of those frames from the Tetradian model-set has its own distinct theory, or more often a theory-set linked together via its own distinct metatheory. But the connections between the frames – as summarised in visual form above – in turn link each of those theories or theory-sets into one unified, complete, consistent metatheory (or, to be pedantic, metametatheory) of enterprise-architecture and beyond.

So no, there isn’t a single ‘The Theory Of Enterprise-Architecture’ – and there can’t be one, ever.

But there can indeed be a single metatheory of enterprise-architecture – and you’re looking at one, right there, in this post.

Hope it’s useful to someone, anyway. Over to you for comments, anyone?

Metatheory and enterprise-architecture

Blog: Tom Graves / Tetradian

Leave a Comment Cancel reply