The dilution of enterprise-architecture

“What concerns me is the dilution of what EA means to the point it has no meaning.” That’s what he said. But is this a real concern that we should be worried about in enterprise-architecture? Or a red-herring that arises only because of mistaken ideas about what EA is and does?

This was another item from that same LinkedIn thread as in the previous post. We’ll start it with a long quote from the same participant, that ends with that sentence above:

SA is a job title used by systems integrators in the bid, and sometimes delivery phase. The person responsible for solution outline or high-level design. Must join everything up into a coherent solution architecture, identify and mitigate all manner of technical risks, with the delivery time and cost in mind.

EA is a job title used by people for the manager, leader or member of a strategic and cross-organisational function, responsible for optimisation of the enterprise system estate. Often, the job is described as requiring engagement with senior executives and their strategies.

You call this a subset of EA. I say it is the EA people expect me to explain to them. It is a tough, challenging role, fraught with political difficulties.

Everybody else we have mentioned, perhaps every role you are interested in, contributes to EA. But to call everything they do, however small-scale, tactical and parochial “EA” would be to put EA history into reverse gear. What concerns me is the dilution of what EA means to the point it has no meaning.

I’ll be pretty blunt about this: This is a concern that is directly one of his own making. It would be a heedless concern – in fact would barely exist at all – if he and others like him did enterprise-architecture properly, in its literal sense of ‘the architecture of the enterprise’, rather than mangling it into arbitrarily fragmented sub-domains (“the enterprise system estate” and suchlike)… But he doesn’t. Therein lies the problem: not just for him, but for all of us.

Large-scale / large-scope architectures work by maintaining the emphasis at the meta-level, the level at which all of the domains intersect. Unlike TOGAF, for example, we don’t focus primarily or solely on the nuts-and-bolts details: that’s a solution-architect’s job, and we should not barge into their turf unless we’re either invited to do so, or we really do need to do so for whole-of-context reasons.

Metaframeworks and their related metamethodologies provide the means to develop context-specific frameworks and context-specific methodologies and methods that are able to work together in ways that are still consistent with the whole, that self-adapt over time and with changing circumstances. In other words, we dynamically create our own equivalents of TOGAF and the like, each of which is subtly different, according to the context and the specific needs, yet still compatible with and interoperable with – for example – the small IT-centric subset represented by a TOGAF implementation.

If we teach academic-style single-function “the right way to do it” content-oriented frameworks for enterprise-architecture – as that person seems to do, and TOGAF and its ilk certainly do – then yes, with each expansion or variance of scope, it will seem like the discipline becomes too diluted and/or too broad for us to be able to teach it. Hence the seemingly-desperate attempts to constrain the scope of the entire discipline to something that we could ‘control’.

By contrast, if we teach pattern- and principle-oriented metaframeworks and metamethodologies, based on ecosystem-type concepts such as fractal recursion, then there is, in effect, little to no difference between one domain and another – and changes in scope or scale barely matter at all. Here are three examples from my own work:

— Enterprise Canvas – a fully fractal whole-of-context approach to service-mapping:

— SCAN – a fully fractal approach to the sensemaking / decision-making / action loop:

— Five Elements – a fully fractal approach to guidance and governance of change:

And yes, enterprise-architecture requires that someone be subject-matter expert in every aspect of the context-in-focus. Yet rather than supposedly trying to teach an enterprise-architect how to be a subject-matter expert in everything – which no-one can do or be – we instead focus on the relationships and linkages via which the EA can bring all the respective subject-matter experts together, across all of the boundaries of language, expectations and disciplines. That demands a fundamentally different approach to what we teach, and how we teach, too.

This is why I’ve said that people who push a ‘content-oriented’ (usually IT-centric) approach to enterprise-architectures are causing damage to the EA discipline: a content-oriented approach is fundamentally the wrong pedagogic model to apply in this type of context, where scope and scale and focus-of-concern can vary so drastically on a day-to-day basis. In essence, they’re trying to teach tame-problem methods for wicked-problem contexts – and that’s a guaranteed sure-fire way to make difficult problems worse whilst pretending to ‘solve’ them.

It’s fine to call the usual ‘EA’-what-you-teach as something like “training in how to do cross-organisational strategic service-oriented IS/IT system-description” – that’s a valid, useful and concrete chunk of content that some people might well need, for real business-purposes. But don’t mislead people by calling it ‘enterprise-architecture’: it’s barely ‘architecture’, let alone ‘enterprise’…

Architectures of all kinds – and especially at the huge scope and scale implied by ‘the architecture of the enterprise’ – work at a fundamentally different level to what they’re teaching: dynamic self-scaling abstract, not single-function fixed-content concrete. In themselves, architectures work primarily at the meta-level, with metaframeworks and suchlike: and whilst metaframeworks are themselves frameworks of a kind, technically speaking, they’re not the kind of frameworks that those people teach. Don’t confuse the two – please?