Enterprise Architecture is becoming popular in private
enterprises due to the practical needs in this era of IT, after its noticeable
fading in public sectors. At this stage, the lessons learned from public
sectors could be very helpful to the EA practice in private sectors.
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.
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.
As a
matter of fact, the Zachman Framework is actually “A Collection of
Architectures in Enterprise”. To be successful in EA and in its adoptions in
solutions, initiatives, programs, and projects, the clear scope of focus in
each phase and stage is important. The Federal Enterprise Architecture
Framework is a variation from the Zachman Framework. One reason it could be the
diverse focus and content in EA efforts causing difficulties in EA practice. By
the way, the Zachman Framework is still very useful in categorize all the
architecture artifacts and products inside an enterprise.
