Architecture

Enterprise Architecture still lacks definition

Simply put I really don’t think that EA isn’t defined well enough to model and operate a successful EA organisation. EA efforts I’ve seen that qualify as “less than brilliant”,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 specificservices 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 Blackberrys, 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.