Is Enterprise Architecture a Thing? If so, is it useful?

The ability of the Enterprise Architecture community to ruminate and argue about the definition of EA seems just about limitless. The latest of which is a debate about the Wikipedia EA definition. The predominant argument in the EA community juxtaposes a technology-centric view of EA against a whole-of-business view. The always brilliant Tom Graves has already written the definitive explanation of the Enterprise Wide IT Architecture (EWITA) vs Architecture of the Whole Enterprise (AWE) debate, so if you aren’t already familiar with it please go ahead and read it before proceeding.

(sidebar: Tom calls it whole-of-enterprise architecture (WEA) but I like Architecture of the Whole Enterprise (AWE) because I think EA is AWEsome!)

Last night I had a thought that will no doubt “kick the hornet’s nest” once again but I thought I’d share. I am very interested in other people’s views of what I am about to post, so please comment below.

Recently Nick Malik suggested that EA could be broken into a sub-set of specialties as follows:

• Strategy Architects – these folks are focused on helping business leaders create new strategies, open new markets, develop new products, etc..
• Alignment Architects – these folks are focused on interpreting strategy, making it actionable, and using it to scope and define business change initiatives.  Also referred to as Business Architects
• Process Architects – these folks are focused on improving business processes or reorienting business processes to place the customer first
• Information Architects – these folks are focused on managing information assets at the enterprise level in a consistent way
• Application / Technology / Infrastructure Architects – these folks are focused on implementing successful “enterprise applications” or “enterprise systems.”  Also referred to as Enterprise Wide IT Architects (EWITA)

I personally accept that these categorizations are broadly valid. I also agree with Nick that, whilst each sub-discipline will have some overlap with the others, each sub-discipline requires a set of skills and knowledge that are sufficiently discrete to make each one a specialty. Nick gives a medical analogy to help:

“After all, an oncologist makes a reasonable diagnosis when you have a cold, as would an Emergency Room doctor, but in the event of a car accident, I’d take the ER doc any day, and in the event of cancer, I’m making a beeline to the oncologist.”

The unspoken aspect of this analogy is that each of these specialties requires so much specialty knowledge, that it would be extremely difficult if not impossible for one individual to achieve mastery of all of all of them. Even if it is possible, I would argue that it is unlikely to be optimal. Frederick Winslow Taylor the father of scientific management & the division of labor would turn in his Grave at the idea. Industrial efficiency, the industrial revolution and all modern notions of economic productivity rely on specialization and the fact that specialists know a lot about a little so that collectively we know a lot about a lot.

One potential benefit of acknowledging that we are specialists is that in doing so we are acknowledging that we do not know it all. Acknowledging that we are playing a role within an interconnected system of knowledge will help EAs focus on their role as connectors, communicators, diplomats and influencers.

So, I am wondering this: If we are specialists, does the designator of ‘Enterprise Architect’ really (need to) exist in practical terms? I for one would say that my specialty (using the options in Nick Malik’s post) is as an Alignment Architect. I can and do use my skill set as a Strategy Architect when required. I have a background in Information and Technology architecture as well, but if I am looking for a job that I will most enjoy and I have the skills and knowledge to create the most value for my client or employer, then the category that fits me best is the one that Nick has designated as ‘Alignment Architect’.

(sidebar: There is a very interesting discussion of the term ‘alignment’ vs ‘fit-for-purpose’ by Len Fehskens et al here.)

(Sidebar: there should be a collective term for EAs. How about a “disagreement” of EAs?)

Is it realistic, optimal or even sensible to have a role of Enterprise Architect? For me, it is useful; in the same way that having a title of Medical Doctor is useful but most of the time, when people refer to a doctor they are referring to their G.P. The difference for enterprise architects (ah! there is a use for the term *grin*) is that we don’t all come from the same basic training, we (most often at the time of writing) began as system admins, network engineers, process analysts, DBAs and any number of other things. If we are all starting with a specialty and working towards mastery of a specialty, what is the sense of a generality? For me it is in the overlaps between the specialties. I have been lucky. I have worked as a system admin, a network engineer, in information management, in telecommunications, in project & program management, as a portfolio manager and in strategy. I could just have well ended up focusing on technology architecture but I did end up focussing on alignment architecture. Regardless of the focus I selected, I am bringing the diversity of my experience and the diversity of skills, knowledge and language to my roles as a connector, influencer, diplomat and especially as communicator.

So for me there is merit in having an umbrella term for EA and there is a lot to be gained from having specialties as well. There is merit in specialties if only to achieve two things: to stop recruiters advertising just about everything as ‘enterprise architect’ and to stop EAs wasting any more time debating what we are so that we can move on to discussion how we do it well.