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:
- Diagrams explaining the business processes and which systems supported them
- Diagrams showing the logical systems, their inter-relationships and data flow
- Catalog of physical and software assets
- Catalog of capabilities and services (for both staff and software)
- A long-term technology procurement plan and evaluation process
- Worked examples, not templates
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?