Analysis & Documentation Framework Flashcards
Why does an EA implementation methodology begin with the selection of an EA framework?
An EA framework provides the standardized and hierarchical views of the enterprise from the perspectives of the business, strategy, and technology. To create the EA framework the program must go through a thorough analysis and documentation process within the enterprise. The value of this process and the EA Framework is that it defines what the EA program will document. The documentation is a prerequisite for the EA implementation methodology which defines how the documentation will be developed and used.
“The EA framework defines what the EA program will document, and the EA methodology defines how that documentation will be developed and used.”
What are the basic characteristics of an EA framework?
The EA framework provides multiple enterprise views and defines how the documentation will be developed and used.
An EA Framework has the following basic characteristics:
It provides multiple views of the enterprise that are useful for executives, managers, and staff.
Organizes planning and documentation, and information exchange activities.
Defines the scope of the architecture by defining what parts of the enterprise are included in the EA.
Documents & Communicates the interrelationship of the component areas of the EA.
Why are hierarchical levels of an EA framework helpful in documenting an enterprise?
The EA3 framework consists of five levels in a hierarchy that are integrated via vertical and cross-cutting components. The framework areas are arranged from high-level strategic goals at the top to support applications and network infrastructure at the bottom. This structure removes the dependency on the sub-architectures to describe the enterprise’s different levels and functional areas. The form also demonstrated the alignment between strategy, information, and technology, which benefits decision making and planning.
Why is it necessary to show current and future views of EA documentation?
The current and future views are present in the EA documentation to show how the organization must change over time to meet the business objectives. Considering the business strategy, the EA documentation creates a view of the organization from the business, organizational, and technology perspective. The EA documentation then makes a view based on the future’s strategic objectives and goals across these dimensions. Having these views helps prioritize and sequence projects for the transformation from current to future state. It also helps to communicate the need for this transformation. The views are ‘living’ because they are not static, and they change over time. The current view changes as the organization realize the future view. The future view changes as the enterprise’s strategic drivers, business requirements, and technology change over time.
How does the Spewak Enterprise Architecture Planning approach relate to the Zachman EA framework?
Steven Spewak’s Enterprise Architecture Planning (EAP) is based on the business systems planning (BSP) approach developed by John Zachman. There are seven phases in Spewak’s EAP that are grouped into four layers that create an implementation sequence. The EAP method is useful for developing the top levels of the Zachman Framework.
Would the Federal EA Framework be useable in private sector (business) enterprises? If so, how? If not, why?
The Federal Enterprise Architecture Framework (FEAF) was established in 1999 in response to the Clinger-Cohen Act of 1996. The goal of the FEAF was to increase the shared development of information and standard processes among federal agencies. The framework provides a taxonomy for an EA practice and a methodology. The purpose for its development was to promote a higher level of EA effectiveness across government agencies and a means for ensuring a high degree of integration between federal agencies (‘enterprises’).
The ideas behind the FEAF are transferrable to the private security. That is the development of a taxonomy for an enterprise with several enterprise architectures. This effort will provide additional standardization and information sharing across the enterprise. Other parts of the FEAF are not transferrable. For example, the outer circles of the model may not be easily transferrable to the public sector.
