The identity of enterprise architecture
Anyone who doubts that enterprise-architecture has an identity-problem, should take a look at this wonderfully poignant address-slip that did eventually reach enterprise-architect Julius Schaffer at the University of Adelaide:
Nope, enterprise-architecture is not the same as civil-architecture; nor is it building-maintenance; nor is it anything much to do with the infrastructure-office – whatever that might be.
But nor, however, should we misdescribe EA in the way that this person did, in a current thread on one of the LinkedIn groups:
The fact is EA is a specialism within IT.{don’t you just love acronyms /or not}.
No, enterprise-architecture is most definitely not merely “a specialism within IT”: that specialism, as Peter Murchland pointed out a couple of posts later in the same thread, would be more properly called EITA, or ‘enterprise-wide-IT-architecture’, which is a related discipline to EA, but with a much narrower scope. Which misdescription is a darn nuisance, because, to quote another person on that thread:
The EITA thing sure does muddy the EA waters a bit.
More than just a bit, actually: it often muddies the water into utter impenetrability. And, like solution-architecture, EITA is not really ‘part of’ EA – another common mistake, repeated by yet another person in that same thread – but instead is kind of encompassed within the overall scope of EA, but in a different way, somewhat as described in the ‘Governance is not an end in itself‘ post.
To understand what enterprise-architecture really is and does, just swap the two terms around: enterprise-architecture is the architecture of the enterprise. Literally. The architecture of the enterprise. Where ‘enterprise’ is usually much, much larger in scope than merely the scope of the organisation for which we’re developing the architecture:
The role of enterprise-architecture within the organisation is pretty straightforward: it’s tasked with supporting a theme that ultimately is the responsibility of everyone in the entire shared-enterprise – that things work better when they work together, on purpose. Hence, yes, EAs will develop models and diagrams and roadmaps, and do governance-work and guide many, many conversations between various stakeholders and ‘concerned parties’: but the architecture itself still always remains everyone’s responsibility. Much like health-and-safety is, for example, or security, or quality, or financial-probity.
Yet because of that bewretched confusion between EITA (which really is IT-only, for the most part) and real EA (which definitely needs to be about much more than just the organisation’s IT), we’ve reached a point where we almost dare not use the ‘A’-word – ‘architecture’ – at all. Especially if it means that our mail gets redirected at random to the civil-engineers, then the building-maintenance crew, then the plumbers and the cable-guys, and then finally the IT-architects, who might perhaps deign to pass it on to us. Yeah, it’s a mess…
So perhaps it really is time now to give up on this, and use some alternative term instead. Some folks push for ‘business transformation‘: but that might well be misunderstood as applying solely to commercial businesses, whereas our work applies just as much to government, to not-for-profits, and other non-commercial contexts. Some folks push for ‘business-architecture‘ as the all-encompassing superset: but that brings us back into much the same mess with the ‘A’-word again, and in any case business-architecture proper is merely another domain-architecture, much like EITA – in this case, the literal ‘architecture of the business of the business’. To me those kinds of alternatives just don’t work – or at the least don’t work well enough for what we need.
One possible alternative I’ve heard recently, though – from Peter Murchland first, I believe? – is enterprise awareness: our work as EAs is to help the organisation build a better awareness of itself, and of the broader shared-enterprise within which it operates – and from there, develop better awareness of its options, and appropriate actions in respect of those options.
And we could still call it ‘EA’, too. 🙂
Whatcha think? – comments, anyone?
“The EITA folks referring to their domain as EA thing sure does muddy the EA waters a bit.”
There…fixed. 😉
I love Gene’s comment. Very sharp.
That aside, yes it’s a problem that many people see EA as an IT discipline. Are we going to fix that by changing the name? No. Two reasons:
1. All we then do is to gift the name “enterprise architecture” to the folks who aren’t doing it, which is unlikely to solve anything. Calling our work something else would probably lead to marginalization.
2. For better or worse it’s the best term we have. Even though architect is a horribly overused word/title (particularly but not only in IT), the analogy to building architects remains very useful for explaining our work to the layperson. That of course assumes that one does know how a (good) building architect does her work:)
Whatever we call it, we still need to explain to people what it is. I have far more use for your excellent paragraph that begins “The role of enterprise architecture within..” than for a new name that I’ll still have to explain.
By the way, even if one were only talking about IT architecture, to describe that as “a specialism within IT” is a bit like saying the CIO is a specialist within IT.
Why has the term business transformation disappeared from these conversations? That felt to me far more representative of what EA did than the term Enterprise Architecture.
Good point: short answer is, I have no idea. I agree, ‘business transformation’ made more sense in terms of what we actually did – but then, as Stuart says, someone has to look after the architecture of the enterprise, and it sure as heck ain’t the IT/EITA guys, no matter what they might claim to the contrary… 😐
Hi Tom — Having just swum up from the depths of my own work like a whale desperate for a lungful of air, I’m delirious to see your call for renaming/rebranding! In my delirious state, I can’t resist proposing “Organisational Anapsycartography”. I can absolutely guarantee this is not to be found by google at the moment. Belaboring the obvious, this applies to all organis(z)ations. Maybe not so obviously it captures the anatomical, psychological, and environmental aspects of the same.
Of course, y’all are welcome to use the terms I’ve laboring under for a few years, enterprisology and enterprisocracy, to avoid the many issues with trying to co-opt the word “architecture”.
Love the “architecture of the enterprise;” it’s a term I really should write on my wall! It sounds like the EA function you describe is really business transformation of the enterprise.
If you are leaning towards the transformation aspect, which I favor, instead of any reference to technology or architecture, what about a “business enterprise strategist?” To some extent, calling this strategy is no better than calling it architecture. However, strategy is more mainstream and acceptable even though conventional strategy as taught in B-school is about my company’s competitive business posture.
So perhaps some unconventional thinking from a non-B-school enterprise architect is the appropriate domain for a “business (transformation) enterprise strategist?” The transformation is is left off or is silent, as that is a term that will scare everyone away.