“Which EA school do you belong to?”

Over on the LinkedIn Chronicles, we might say, there’s been a long-running thread in which one of the more provocative of ‘the usual suspects’ asserted two things that “are not enterprise-architecture”, and five things that enterprise-architecture “always is” – all of which, to my mind, was either flat-out wrong or so distorted as to be misleading and even dangerous.

It’s dragged on a while, much of it going round in the same old circles, as LinkedIn ‘conversations’ are wont to do. Yet in the last couple of days, though, the thread took a sideways lurch, with this particular participant taking a slightly different tack from his usual strawman-attacks. It’s sufficiently different, in fact, to be worth documenting and expanding somewhat here.

It started with these assertions:

I repeat what industry sources and most of my customers recognise as EA.
You (anybody) may feel confident that your version of EA is the true or better version.
But there are many versions.

The first sentence is actually a re-assertion of one of the most serious errors that we see in enterprise-architecture: the notion that because something was said in the past – in this case, previous mistaken assumptions that EA was ‘obviously’ only about IT – we should and must therefore repeat those same mistakes indefinitely into the future.

The second sentence assumes that scope is merely a matter of opinion – rather than, say, using the explicit linguistic convention used in all other forms of architecture, that the descriptor-term (in this case, ‘enterprise-architecture’) must match up with its inverse (‘the architecture of the enterprise’). If we apply the inversion-test, it becomes immediately self-evident that the usual assertion that ‘enterprise-architecture’ is exactly synonymous with ‘the architecture of arbitrary subsets of the enterprise-IT’ makes no rational sense.

The third sentence represents the first time that I’ve ever seen this person admit that there might be other valid views of enterprise-architecture than his own arbitrarily IS/IT-centric perspective.

But from here, we move on to – no real surprise – yet another strawman: in this case an attempt to pin all others than himself into a single ‘school’ (paradigm or view) of enterprise-architecture. (That last sentence in the quote that follows is something we’ll need to come back to later.)

It seems to me you identify with 4 and 5 of the seven EA schools below.
I identify rather with 6 and 7. Who is “right”?
Please offer references or research in support of your view.

So, here are his seven ‘schools’, and my own reply to each.

1) Are you a modeller who considers EA to be drawing UML or ArchiMate diagrams?
Perhaps you use a tool called “Enterprise Architect” to draw the diagrams.

Modelling: yep – done that. Lots.

As it happens, yes, I do have a licensed copy of Sparx Enterprise Architect somewhere on one of my systems, but I don’t use it very often: a bit too focussed on UML and Archimate for my usual needs (though it does have a metamodel engine to create home-brew notations that I haven’t yet learnt how to use).

More generally, I’ll use just about anything for diagrams: Visio or Omnigraffle, for example. Though the tools I most use for diagrams are a whiteboard or plain old pen-and-paper: by far the most versatile of the lot.

2) Are you a technologist who considers EA to be enterprise-wide technology architecture?
You may use the term EA for the enterprise technology estate. Or for strategic planning that yields road maps for enterprise-wide technologies.

EWITA: yep – done that. Lots.

I’m not foolish enough to believe that it’s all there is to EA, though.

3) Are you a solution architect who considers EA is any architectural work for an enterprise?
There is widespread confusion of solution architecture with enterprise architecture.

Solution-architecture as an element of EA: yep – done that. Lots.

Relating with solution-architecture is a routine part of enterprise-architecture – as per Phase G of the TOGAF ADM, for example. If we ignore solution-architectures, we will fail to understand how change actually works within the enterprise.

Agreed that many self-styled ‘EAs’ confuse enterprise-architecture and solution-architecture – in fact much if not most so-called ‘EA’ these days is still little more than IT-obsessed ‘solutioneering’.

Enterprise-architecture deals with the enterprise as a whole, with all of its dynamics and complexities, over longer periods of time. Solution-architectures mostly deal with a single point-solution applying in a single business-context at a single point in time. Sometimes, to understand some critical theme in an EA, enterprise-architects might need to do a deep-dive right down into the solution-architecture space, and maybe even beyond. With good reason, though, solution-architects do not like enterprise-architects trampling on their turf and trying to tell them what to do: in general, we should keep out of their way unless they invite us in, or if we must engage with them for broader whole-of-enterprise reasons.

4) Are you a business analyst or consultant who considers EA is Business Architecture/Analysis?
You consider EA is what you do, be it strategic or tactical and specific to one line of business.
Some in this school distance themselves from IT, even from IS.
Such BA was done before EA and is done without it. In other words, EA and BA are overlapping sets.

Business-analysis as an element of EA: yep – done that. Lots.

Again, it’s a fundamental requirement in the TOGAF ADM: Phases E/F, to be precise.

I don’t know of any EA who does not explicitly include IT and IS within their scope. The assertion otherwise is merely a strawman assertion popular with those who dislike the idea that EA might need to cover a broader scope than IT/IS alone: an all-or-nothing accusation that if we don’t focus exclusively on IT, we must therefore exclude IT entirely. Absurd.

5) Are you an Aussie, where an EA school appears to have evolved along the business analysis lines of 4 above?
I am told Aussie Clive Finklestein’s version of Information Engineering headed off in that direction. 
TOGAF’s approach to Business Architecture – within EA – is based on James Martin’s Information Engineering.

Australian influence: yep – done that. Lots.

(No idea who Clive Finkelstein is, though.)

One of the main things I learned from the Australian influence – though it took a move back to Britain to discover the painful reality of this – is how backward EA still is in the ‘big countries’ such as Britain and the US, where so many self-styled ‘EA’ people still seem to believe that IT is the centre of everything, and for the most part barely seem to understand architecture as architecture at all. In the ‘small countries’ such as Australia, Canada, the Netherlands, Sweden, South Africa and the like, the small technical pool means that almost all of us have had to learn to think like architects, as a matter of habit, just to get the job done; in the ‘big countries’, by contrast, people can stick in a single subdomain perhaps for the entirety of their career, and never need to connect anything to anything else at all. To be blunt, much if not most of the so-called ‘EA’ that I see here in Britain is still a full decade behind where we were in Australia when I left there. Laughable, if it wasn’t so disastrously destructive.

6) Are you TOGAF-trained and consider EA to be defined by the architecture development method (ADM)?
TOGAF awards EA techniques like “structured analysis” and “business data model” less than one sentence each.
And many use the ADM for project-level solution architecture.

TOGAF-trained: yep – done that.

TOGAF 8.1 Certified, to be precise. (I haven’t bothered to do TOGAF 9 or 9.1: as far as I’m concerned, they’re still essentially the same as 8.1 – a few extra bells-and-whistles, but still based on the same disastrous IT-centrism.)

But I don’t consider EA to be defined by TOGAF’s ADM: crucially, Phases B-D arbitrarily constrain everything to a narrow IT-centric scope, in which so-called ‘Business Architecture’ is, in essence, ‘anything not-IT that might affect IT’. A true ‘architecture of the enterprise’ may need to cover any subset within the enterprise – which will often be much larger in scope than a simple IT-centrism, and in certain cases (mainly in relation to human aspects of the architecture, or some aspects of disaster-recovery) may not touch IT at all.

Unlike many self-styled ‘EAs’, I’m well aware of the need to balance TOGAF’s Phases A-D (strategy) with Phases E-H (implementation) – the stuff this person dismisses as ‘solution-architecture’. Without which no architecture would be implemented. Oops.

7) A follower of mainstream EA history and modern resources (e.g. TOGAF and “EA as Strategy”) likely has another view of EA.
Members of this EA school look to strategic and cross-organisational systemisation of business roles and processes.
The focus is on improving business processes that can be monitored, supported or directed by business information systems.
Moreover, it is on cross-organisational optimisation, via standardisation or integration, of those business roles and processes.
This kind of EA recognises solution architectures can be contrary to the strategic EA, but may allow them by time-bound dispensation or waiver.

Beyond TOGAF: yep – done that. Lots.

(Seriously lots. Including rewriting the ADM to work at a whole-of-enterprise scope rather than solely IT/EWITA. I literally wrote the book on it. Several books, in fact.)

Almost all of the ‘mainstream EA history’ he describes either asserts or assumes that IT is the sole centre of the enterprise. Anyone not trapped in the IT-hothouse would recognise instantly the arbitrariness and absurdity of that assumption. It’s precisely because I have studied much of that ‘mainstream EA history’ that I can see its flaws and self-centric fantasies, and therefore design around them.

The notion that EA should solely be ‘strategic’ is equally absurd: placing it there would place it in an ‘ivory tower’, disconnected from reality – which is exactly how many people elsewhere in business would view it and/or experience it. By contrast, a literal ‘architecture of the enterprise’ would need to intersect with all scopes and all timescales, from the nominally-permanent ‘vision’ or ‘promise’ above strategy, all the way down to design, implementation, deployment, operation, usage, decommission and recycle, and all the way back again, leveraging all forms of benefits-realisation and lessons-learned. Constraining EA solely to a ‘strategy’ role is as arbitrary and ill-advised as is constraining its scope to IT-centrism.

(The notion that this person could place himself ‘in’ this ‘school’ is also a bit laughable: pretty much all of his published views are straight TOGAF-style IS/IT-centric, with business-architecture as ‘anything not-IT that might impact on IT’ – there’s no concept of the enterprise as enterprise there at all.)

Anyway, that’s my response to all of those seven ‘schools’. For me, the real answer to his “Which EA school do you belong to” is ‘all and none’ – whereas, strangely, he seems to want to force-fit me to just one ‘school’ alone. How absurd!

Yet the schools of EA I most identify with are two that he somehow doesn’t mention:

8) The school of disciplined eclecticism

That’s what I learned at the literal ‘schools’ that I studied at, such as Hornsey College of Art (London), the Architectural Association (London), the Royal College of Art (London) and Swinburne University School of Management (Melbourne).

That’s also where I learned the practical implications of those three key phrases that every competent EA needs to learn:

• “I don’t know… (but I know how to find someone who does)”
• “It depends… (but I know what it depends on)”
• “Just enough… (but I know how to get to that right level of detail)”

Not just theory, but honed and revised and reworked continuously throughout some forty years of full-time practice so far. That’s a school in itself, yet which also brings us to the real school that every EA needs to know and respect…

9) The school of hard-knocks (as taught by every place I’ve worked…)

If you’d insist on placing me into a single ‘school’, that’s the one I’d acknowledge; that’s the one I’d sign-up for.

As for the question “Who is ‘right’?”, the question itself comes from the ‘repeatability/truth’ delusion – and hence in itself is often inherently-absurd…

In many ways there’s no real doubt that just about anyone could claim that their own view of EA is ‘right’, according to their own chosen circularly-self-referential definition of ‘truth’. Yet EA is, above all, a practical discipline: the notion of ‘right’ barely makes sense here. Instead, the emphasis is more on what is ‘better’ or ‘more appropriate’ for the specific context – for which much of the usual approach, and the usual notions of ‘right’, are often a distracting, irrelevant and sometimes darn-dangerous damn-nuisance.

For the tiny, tiny subset of EA in which too many self-styled ‘EAs’ prefer to work – and which they’ve so insistently yet so wrongly claimed is the entirety of EA – the usual IS/IT-centric models and methods may sometimes be ‘right’; but if the need is to work with the literal ‘the architecture of the enterprise’, then that approach is not right at all. That’s the difference.

But let’s get back to this:

“Please offer references or research in support of your view.”

In my own case, all of the research and more I’ve derived from schools 1-9 above (and much, much more) are documented in publicly-accessible form in:

• eleven books so far on enterprise-architecture (see http://tetradianbooks.com and https://leanpub.com/u/tetradian )
• this blog – more than 1000 posts so far totalling around two million words, equivalent to perhaps 200-300 full academic papers
• * a fair few formal papers (see my LinkedIn profile)
• * around 30 slidedecks from EA-conferences and the like (see http://www.slideshare.net/tetradian)

All of it cross-referenced to others’ work as and where appropriate, and all of it openly published (other than some of the ‘academic’ papers – a constraint that’s outside of my control).

And the people I’d most regard as my research-sources would be those that most ‘EAs’ would never have heard of: people like Helen Mills, Graeme Burnett, Peter Tseglakof, Bob MacDonald, and many, many more. They’re practitioners – not academics or armchair-theorists.

And that’s because the real point here is that by definition, real-world EA is not something that could ever fit comfortably into an ‘academic’-style model.

Classic ‘references and research’ assume a context of mass-sameness: the fundamental concept is that of repeatability – because once it’s repeatable, it can be ‘taught’. In professional terms, that’s where that person lives (metaphorically speaking): a context of ‘proof’, certainty, past-repeated-into-present as ‘the truth’ – often without, it seems, ever checking the validity of its premises or past assumptions.

Yet the reality of EA and suchlike is a context of mass-uniqueness, messy, inherently-uncertain, only partially-repeatable at best – in fact often non-repeatable by intent. In that world, any assumptions about repeatability and suchlike – and, perhaps even more, the absurd reliance on the past as ‘proof’ for the present – are often not merely not much of a help, but an active hindrance.

In that kind of real-world ‘mess’, everything interweaves with and is interdependent with everything else: arbitrary boundaries and demarcation-disputes can easily be lethal to the effectiveness and viability of the whole. An architecture that works in this space must be able to cover the whole of that space – a literal ‘architecture of the enterprise’ whose scope may and often does extend far beyond the borders of the organisation itself.

By contrast – to be blunt – what’s commonly taught as ‘EA’ is a tiny, tiny subset of that scope. Yes, there are times when it’s useful to proceed as if a subset is the whole of the scope-in-focus; yet if we do so, we should never confuse ‘as-if’ with ‘is’, we should never delude ourselves or others into thinking that the subset is the scope, and that there is nothing else.

And yet that’s exactly what way too many in ‘EA’ have done: they’ve been foolish enough and, bluntly, arrogant enough to assert and pretend and protect the delusion that that tiny subset of EA that they personally know and understand is the whole of the scope, that anything outside of that tiny subset either does not exist or cannot be described in its literal sense of ‘the architecture of the enterprise’.

To again be blunt, that kind of misrepresentation is false-advertising, or even a form of fraud: it cannot be described as anything more than that. And because of the damage that that behaviour can cause, it would in almost any other discipline be classed at the least as a professional misdemeanour; if we tried to do the same in building-architecture, for example, it would literally be a criminal offence, with a serious fine, and a possible jail-sentence as well. So why should it be any different in IT or IS? Do the IT-obsessives in ‘EA’ have any idea yet as to how dangerous a position they’ve put themselves and others in?

Sigh…

What’s often taught as ‘EA’ is – to use that person’s own words – “cross-organisational strategic service-oriented IS/IT system-description”. It uses and teaches methods that, for anything than a relatively small subset of IS/IT, is fundamentally inappropriate, outdated and misleading for current real-world needs in EA. And in many ways it seems explicitly designed to prevent ‘the architecture of the enterprise’ from even being possible. Please, please can we stop pretending that that kind of myopic mess is all there is to EA?