EA vs EA: When an Architect is(n’t) an Architect

The old adage says that the great thing about standards is there are so many of them, and when it comes to defining the spectrum of Architecture practices, every article on the matter not only proves the adage true, but adds weight to the true collective noun for architects is “an argument”.

So, why yet another article on what we all know? It’s been on my mind more than usual over the last fortnight. It’s a topic that has triggered my frequency illusion by being evident in my LinkedIn, Flipboard and Workplace streams.

Recently, I wanted to clarify the titles and nomenclatures we utilise, but instead find that the multiple certification vendors, the various association bodies, the corporations nor the industry in general have any form of baseline.

If I, as an existing battle-scarred veteran, find the various nomenclatures confusing, then how can I expect others to understand it?

Aside from the frequency illusion, this all came to a head due to a prominent task – namely recruiting.

The marketplace is filled with candidates with resumes that proclaim a range of Architecture themed nomenclatures. Yet, the experience does not reflect well in the content of the documents, and often remains lacking in the few interviews we have decided to entertain.

Who to blame though?

The problem is there is a spectrum which can be visualised in many ways.

The other problem, in my constantly cynical view of the world, is that individuals are involved.

It’s normal, I suppose, that individuals have their own agenda for status, recognition and reward, Perhaps, some of this is fuelled by the “impostor syndrome” that muddies the waters – as some aim to prove that they are worthy and right. Perhaps it is simply an attempt to differentiate one candidate from another.

Add to the confusion is that, seemingly daily, we are seeing new specialist non-holistic versions or sub-disciplines emerge into the industry.

Individuals and firms alike are seemingly trying to add weight to their competency by compounding (confounding?) the nomenclature and offer what I can only label as a level of “expertise through title”.

Furthermore, the freedom of publishing one’s own thoughts (yes, I get the irony *and* the hypocrisy) in the same space and with the same validity as any academic or researched piece, provides us with a huge amount of noise and distraction where instead of refining and furthering the “art” of Enterprise Architecture the communities are instead finding themselves arguing over an opinion of what one or the other “is”.

Supposedly, an “enterprise solution architect” like “enterprise systems architect” is meant to convey that the Individual is somehow more senior and able to provide “enterprise level” capabilities – but does it? A systems architect (aka someone cross-skilled in Data, Applications and Technology Architecture) is a systems architect and should have the ability to design, plan and implement a system whether a single stand-alone instance or one that is globally dispersed.

A “SalesForce business architect” or “SalesForce solution architect” is quite simply a product architect. Neither a solution architect nor a business architect … yet again, compound-titles are seemingly provided to add expert weight to the role.

I propose that one problem may be that certain words have very similar meanings, and perhaps, thus, causing the variability as I often see certain terms interchanged which causes a great deal of confusion and thus misinterpretation:

• ‘enterprise’ and ‘business’
• ‘complex’ and ‘complicated’
• ‘strategy’ and ‘tactics’

Often, the interchanging of terms is utilised across terms and muddying meanings further:

• enterprises are complex
• business is complicated

Add to this the desire to remove any ‘baggage’ from previous roles, and perhaps provide a demonstration of advancement (the aforementioned “expertise through title” qualification) or simply as a narrative logic differentiator. This leads to people who describe themselves as an ‘enterprise business architect’ or an ‘enterprise solution architect’ – neither of whom, when pushed, could truly explain the differences between themselves and those without the compounded titles.

When one looks at the world through the lens of IT centricity, problems are perceived in ways that presume that information systems and technology are there to provide accessibility, speed, accuracy, and capacity for information needs.

Meanwhile, business process views of problems consider ways in which mapping value, capabilities, processes and efficiencies could be utilised to learn and gain advantages.

Hypothetically, a business could meet its needs with an abacus and a notepad. It would likely be manpower intensive, but it could be done … and it may theoretically also be competitive.

Whether all of this lack of clarity with the nomenclature is the fault of anyone is neither here nor there.

These are just some of the issues that I have had to consider and contend with as I have been trying to clarify the role of an EA specifically from the point of view of an independent vendor, integrator or service provider.

Which leaves me where? What call to action could I possibly put out that could resolve this? Perhaps the only answer is to provide a definition … and hope others agree?

— This has been an opinion, but I would still like to hear your thoughts on the matter and garner your feedback.