2 Views of Agile Enterprise Architecture

Most of the EA implementations I have seen (and worked on) involve a tremendous amount of navel-gazing (aka Current State Analysis) followed by a lot of BDUF and BMUF. The resulting documents are usually out of date by the time the initial draft has been blessed by all the reviewers and any of the technical merit in the document reads more like it was generated by the marketing departments of the selected vendors than by the EA team.

When I took the time to read the comment and change request logs for the document, it was pretty easy to see what parts of the document were actually useful to people (lots of comments, complaints) vs. those that simply could have been omitted, entirely. In one case, a 1200 page mini-series could have been condensed into a podcast. Perhaps at it's simplest, this might be a way of practicing Agile Enterprise Architecture, at least in a manner comprehensible by the framework-followers. The most useful sections of the document were:

1. Diagrams explaining the business processes and which systems supported them
   
2. Diagrams showing the logical systems, their inter-relationships and data flow
3. Catalog of physical and software assets
4. Catalog of capabilities and services (for both staff and software)
5. A long-term technology procurement plan and evaluation process
6. Worked examples, not templates

These were the 6 artifacts that the majority of the people in the organization actually found useful, regardless of occupation. What about the future state, you ask? That's the most interesting part. Aside from the execs who liked the large, color plotter posters on the walls and in their offices, only the architects, planners and vendors cared. The rest of the organization only cared about the next phase on the road map. When I walked around the IT organization, the diagram that I saw pinned to most walls was the migration and transition plan from the current year to next year. Think about that for a moment. Furthermore, the meat of that diagram indicated development of new systems that had already been approved plus new paths for systems consolidation identified during the EA exercise. My take-away from this was that the majority of the really useful information could have been published months before the end-state, big-picture was complete. In that case, we missed the boat on practicing Agile Enterprise Architecture.

Now that I'm a bit older and perhaps wiser, I look back at the work I have done and wonder if it was truly valuable? I have never been a big believer of wasting time doing current-state analysis. In my opinion, all of that information and documentation should already exist throughout the organization. What should really happen in the first phase on an EA exercise is to corral all of the existing operations manuals. I know, I'm dreaming but, I digress. Anyhow to answer my own question, I think the value of the exercise was dubious. All we really did was record the tribal knowledge and set forth some common sense guidelines. That's more like Enterprise Archaeology, and there's nothing agile about that! I suppose there was some short-term value but, certainly little that is lasting.

So, as an enterprise architect, what can I do that is valuable? As I stated before, I don't believe that bringing agility to enterprise architecture is very valuable. Necessary, but not valuable. Perhaps a subtle re-statement is all that is needed? When I actually keep my mouth shut and listen to what the people on the business side of the company are actually saying, I hear a lot of words and phrases like process changes, new regulations, nimble, waivers, exceptions, changing market conditions, adaptable product lines, etc. What they really want, in terms of assets I can create, is an Agile Enterprise Architecture. The value of an agile enterprise in tomorrow's business conditions, is obvious, don't you agree?