Enterprise Architect: Breadth, Depth, and Interchangable Parts

Alan Inglis has posted a second time about the need for an Enterprise Architect to be oriented more towards breadth than depth.  I agree but I feel the squeeze.

Enterprise architecture is there to bridge business and IT concerns.  Therefore, they need to be talking to business representatives and business leaders to build trust, listen to strategy, offer insight and ideas, and clarify requirements.  They need to be talking to IT architects and leaders to build rapport, deliver actionable plans, influence, and sometimes, enforce.

As you become more immersed in the EA role, you begin to lose your technical depth.  I haven't coded significantly in two years now.  There are technologies that I understand but have not coded.  That is good (to a point) and bad (to a point). 

If our industry were more mature or if the rate of change was more moderate, I would not need to code to keep up.  But it isn't.  Our industry is changing daily, and there is no widely available model to allow an architect to understand a new technology quickly without experiencing it directly.  There is no standard parts mechanism that drives people there, and therefore, no economic incentive for vendors to publish their products with model elements that would allow an architect to make direct comparisons in any kind of depth.  Marketecture rules.

And therefore, the Enterprise Architect is limited.  We can never get far from the level of technical depth required to deliver decisive insight, yet that heavy burden of constant learning prevents us from being able to reach up to a higher level of business effectiveness.  The fact that we are a hybrid means that we can neither job terribly well. 

And that, I think, is long term, the biggest reason why we are not often enough seen as valuable.  Both sides (Business and IT) can produce someone who knows their side better and deeper than the EA.  In a cooperative environment, it won't matter.  But in many IT shops, there's not enough cooperation to butter one side of a piece of toast.

There is a way out, but it is long term.  We need to get a consistent taxonomy of systems and features, make it available, have the vendor community contribute to the definition of it, and then provide incentive for them to map their own commercial systems to it.  Then architects can make the comparisons they need to make without needing a direct and deep engagement with every new technology. 

That's the transition to interchangable parts.  That won't be easy.