Enterprise Architecture: A Joke, A Failure...or an Opportunity?

Interesting discussion erupting in the EA blogosphere about what Enterprise Architecture really is. Actually, this dialog has been going on for some time now, but a number of bloggers appear to be embracing the issue very recently.

The primary reason that I collect and publish "definitions" of enterprise architecture on my blog is not because enterprise architecture is a "joke," as some revealed tongue-in-cheek, but more that EA isn't defined well enough to model and operate a successful EA organization. EA efforts I've seen that qualify as a "joke" or, more aptly put, failures, generally have one or more of the following characteristics:

1. EA roles, scope, charter, etc. are not well-defined. This has nothing to do with populating Zachman bingo cards or drawing pretty model diagrams that nobody uses, but more on what specific services and value EA is providing to the business and IT. Where things go off the rails is when EA starts paying more attention to the business (which leads into the "PowerPoint jockey" meme) than to IT/developers; or the other way around, which may be architecture of some sort, but not EA (not to mention such lack of overall perspective leading to silo thinking and systems).

2. Expectations are too high. We expect a great deal of business and technical breadth from EAs, which is reasonable, but we also expect deep expert capabilities in all issues and technologies, which isn't. I have yet to see such overall depth in any individual, but I have seen it within well-managed and deployed EA groups that work and collaborate together.

3. Confusing EA with Project Management. Two separate roles with different objectives, although they must and should collaborate when necessary. EA is not about producing/delivering "working software," and I've seen instances of combination EA/PMs fail on projects far more than I've seen them succeed. Specification and delivery of discrete systems is different from planning and describing the overall/strategic technology solution(s) that map to the operating model of the business - now and going forward.

4. Confusing EA with Software Development. Same arguments as (3) above, but addressed to those that feel that EAs should be a part of development teams. That mistake, almost by itself, causes silos to emerge or be reinforced. Software development teams certainly require technically-competent team leads and solution architects. EAs are not in that category - the scope of their work has to be wider for EA to be effective for the organization.

5. Succumbing to Dogma, Silver Bullets, Over-reliance on "Standards," and other Forms of Negative Rationalization. We all have our worldview and biases, even in the face of facts counter to those views. Good-to-excellent EAs, while certainly an opinionated lot, are always learning and leveraging that acquired knowledge in the job. While there are always needs for standardization, part of the "ivory tower" problem some EAs face is that they use them as the absolute, unbending Rule of Law, which does not communicate or sit well to other parts of the organization - and never has.

6. Confusing "What" with "How." This is where folks go off the tracks with respect to frameworks (Zachman, FEAF, TOGAF, etc.). Frameworks and reference architectures (which is what FEAF is ultimately presented as, but not the others) are what I call "concept organizers." Good at organizing repositories of EA work, but not very forthcoming on how work products are to be produced and what value these products have to others besides the producer. If you're a successful EA using a framework, great, but I'll wager the $20 in my wallet that you spent a lot of time filling in the "how" part of leveraging that framework - on your own, of course. What I'm saying here is parading about any framework as the ultimate answer/solution to what EA is and what specifically needs to be produced is asking for trouble. The frameworks don't go far enough in that regard (although TOGAF 8.1 is beginning to get there). I don't know if they really should, just that they don't.

7. Wrong or No Levels of Abstraction. Give a box-and-arrow presentation to the business and I will start a side-bet on how long it takes the business folks in the conference room to check Crackberrys, look at their watches, or fall asleep. Give the opposite to development teams and get accused of "ivory tower," "doesn't get it," "PowerPoint Jockey," etc. One of the main parts of the deal in successful EA is that we can explain the architecture at various levels of abstraction that are comprehended by people in different domains. This isn't easy by any means, but its required for success.

As I mentioned, there is a lot of chatter about what EA is/isn't on the blogs at present. I recommend checking out the commentary of Mike Walker, Nick Malik, Mike Kavis, Steve Jones, and Todd Biske - all with multiple posts and very sound views on these issues.

I'm also very interested in your definitions and comments on enterprise architecture, and if it's good and relevant, your work may make it's way into the Enterprise Architecture Definition Collection...:)

Comments

[Paul Wallis]

Bob,

Your point number 7 is key I think. IT needs to enable the business to easily understand how IT is critical to the business.

I don't have a definition of EA to add but you might be interested in the OBASHI methodology

http://en.wikipedia.org/wiki/OBASHI

which my business partner and I developed during 2001 from techniques used by Oil and Gas engineers.

OBASHI helps you to model, visualise and understand how and why IT assets support business services.

EA is just one of its many fields of use.

[Nick Malik]

I wonder why, in your list of EA definitions, you didn't quote Wikipedia?

Thanks for the plug.

--- N

[Bob McIlree]

Hi Nick - Good suggestion. Never thought about it since I usually read and quote individual or industry group defs rather than wikipedia. I'll visit there and take a look...

Bob

[Louis Rosas-Guyon]

Excellent article! Another problem is that EA has managed to become more complex than necessary. Ultimately EA is meant to serve the business. With so much complexity, the industry has created an environment rife with error.

Death to Complex EA!
http://r2computing.blogspot.com/2008/03/death-to-complex-enterprise.html