One thing I noticed is that there is still no unified answer regarding to what is EA and what should be in it. It is not rare to see that so called “EA” is to use EA tools and/or an EA repository to collect all type of “architecture” artifacts inside enterprise. These “architecture” artifacts are developed in different timeframes, cover different level of content details, and are created from different perspectives for different purpose. While a real EA should consist of “architecture” artifacts in concert by planning ahead with a designated purpose for each view. The level of details is good enough to convey intent and to serve the purpose, no more and no less.
For the questions of “what is EA?” and “what should be in it?”, the recap of EA purpose could be useful. It is generally accepted that EA is to create a blueprint for enterprise, so to have development guidance for long-term. It includes “as-is” and “to-be” architectures and a roadmap for transition. As a best practice, we do the “as-is” architectures just as much as necessary for “to-be” without excessive efforts in exploring “forest”. Since EA focuses on long-term guidance, it should be flexible enough to evolve along technology advancement with physical implementation decisions to be made during each initiative execution. In this regards, the EA scope of focus is illustrated in the following figure in the context of Zachman framework.