Pages

Saturday, July 12, 2008

EA Joke or Joker 2

I hope I made it clear in my previous post Enterprise Architect - Joke or Joker that I am not attacking all enterprise architects, or the concept of enterprise architecture (EA). I think there are many excellent practitioners of enterprise architecture, as well as some who don't deserve the job title at all.

In his latest post It's 2008: Is Enterprise Architecture Still a Joke?, James McGovern wants to talk about the value of EA, and I agree this is an important question. I think part of the reason why people sometimes see EA as a joke is because of the large gap between the potential value - what EA could theoretically be achieving in an ideal world - and the actual delivered value. In many organizations the actual delivered value of EA is disappointingly low. (James himself thought this was true of US Government in 2005; the title of his latest post hints that things may have gotten better).

There is not a single explanation for the disappointing results of EA in some organizations. Sometimes it is because the enterprise architects themselves aren't very good at the job; sometimes it is because the larger organization is resistant to some of the opportunities. Jeff Schneider's original post Why Enterprise Architecture is a Joke suggested some additional contributory causes.

(These different types of deliverable can be associated with different personality types or astrological symbols. In ancient Chinese symbolism, support networks and infrastructures are associated with Earth, rigorous conceptual frameworks can be associated with Metal, and actually building things is associated with Wood. Motivation is Fire and insight/inspiration is Water. Water feeds Wood, Wood feeds Fire, and so on.)

James argues that the goal of EA is to improve the quality of the IT ecosystem. Following something like the Goal-Question-Metric paradigm, this leads to specific measures via a set of questions. Here are some example questions extracted from James's post.

Does federated identity enable better security for your business partners?

What is the quality of source code within the enterprise?

Is the enterprise architect participating in user group meetings that help propel the ecosystem forward? Are we working for interoperability across the industry?

How well managed is the enterprise spend? How much money is being spent on compliance? Is this strategic investment being leveraged for other purposes?

But even if we can build a comprehensive measurement framework from such a collection of questions, this still leaves an important question - are we judging the success of enterprise architecture within an organization, or are we judging the success of the whole organization in using and leveraging enterprise architecture?

Of course similar questions apply to the architecture of buildings. Unfortunately, architects are sometimes more highly regarded for producing something that looks good in the architectural magazines, than for producing something that the client actually wants, or something that will evolve well.

The architects of past centuries whose buildings and names survive are not necessarily the ones who had the greatest ability, but those with reasonable ability who were fortunate in having the most supportive clients. Likewise, the most evidently successful enterprise architects will be those who are fortunate enough to be working in the most sympathetic and supportive organizations. But the enterprise architects who perhaps really deserve our praise are those who are working against the odds, achieving small victories in unsympathetic organizations.