Implementation Methodology Flashcards
What are the five phases of the EA Implementation Methodology?
Phase I: EA Program Establishment
Phase II: Ea Framework and Tool Selection
Phase III: Documentation of the EA
Phase IV: Use and Maintain the EA
Describe the steps of Phase I: EA Program Establishment
Step 1: Establish the EA Management Program and identify a Chief Architect
Step 2: Establish an EA implementation methodology
Step 3: Establish EA governance and links to other management processes.
Step 4: Develop an EA Communication Plan to gain stakeholder buy-in.
Name the five architecture frameworks.
Zachman TOGAF FEAF DoDAF Gartner
EA Framework
The EA framework is a structure for organizing information that defines the scope of the architecture; what the EA program will document and the relationship of various areas of the architecture.
EA methodology
The EA methodology defines how the EA will be implemented and how documentation will be developed, archived, and used, including the selection of a framework, modeling tools, and on-line repository.
What is an EA implementation methodology?
An Enterprise Architecture implementation methodology is the body of assumptions, methods, and rules that drive the structure for the planning and implementation of an Enterprise Architecture. It defines the ‘how’ of an EA implementation and covers how documentation is to be developed, used, and archived.
To implement an Enterprise Architecture, the Chief Architect, along with the EA team, must identify the steps and procedures necessary to install a successful EA program. This identification is the first step in the process of coordinating the EA documentation approach. As with most planning exercises, devoting time to this activity is a way to reduce the risk of creating an ineffective EA program.
What is the role of an EA framework within the EA methodology?
The Enterprise Architecture framework is used within the EA implementation methodology to define the process of creating, implementing, and updating an EA. The framework identifies the areas within the enterprise that will be covered and how those areas are related to one another. Many frameworks are readily available to be used and modified for use. The more common frameworks are: TOGAF, Zachman, DoDA,FEAF, and Gartner. Each framework has its focus area which lead to different strengths and weaknesses. The choice of a framework is made based on the unique needs, goals, and culture of the organization.
The framework should identify the areas of the enterprise that the EA will cover, and how those areas relate. For example, the EA3 framework identifies five functional areas and three ‘thread’ areas to be documented, organizes different types of components, and then orients the components into lines of business. These relationships are important in conveying how the enterprise uses its processes and resources in accomplishing its goals.
What is the purpose of Phase I activities in the EA methodology?
The Enterprise Architecture framework is used within the EA implementation methodology to define the process of creating, implementing, and updating an EA. Many frameworks are readily available to be used and modified for use. The more common frameworks are: TOGAF, Zachman, DoDA,FEAF, and Gartner. Each framework has its focus area which lead to different strengths and weaknesses. The choice of a framework should be made based on the unique needs, goals, and culture of the organization.
Phase I activities are designed to get the EA program initially started, identify key players, and communicate the EA implementation plan to the executive sponsor and other stakeholders in order to gain buy-in and support. These pre-documentation activities are important to ensuring that the EA program has clear goals, remains focused, and is accepted throughout the enterprise.
Why are Phase III activities dependent on the completion of Phase II?
The activities of Phase III conclude with the development of the EA Management Plan. The plan summarizes the views, current and future, of the architecture and provides a transition plan to realize the architecture. Phase II activities serve as inputs into the Phase III activities and are therefore dependent on them. The outputs from Phase II provide the basis for Phase III deliverables. For example, Phase II is where the EA documentation is developed. The EA document framework is established, and the scope of the architecture is established. Other areas from Phase II that are needed for Phase III are the techniques for modeling current views and the method for developing and modeling future scenarios. These artifacts are entered into the on-line EA repository along with all the EA documentation artifacts. These are necessary for the development of the EA Management Plan.
Phase III activities are where the actual development of the EA occurs in the form of documentation artifacts. Phase II enables this work. The work involves analyzing and documenting the current strategy, business, information, services, and infrastructure of the enterprise. It also involves the development of artifacts that reflect changes in resources in the short-term and the development of a group of long-term future scenarios to identify possible courses of action and resource changes that would be needed in response to different internal and external influences. The activities in this phase of the EA documentation methodology conclude with the development of an EA Management Plan that summarizes the current and future views of the architecture and provides a transition and sequencing plan for short term and long term changes. \nCompare and contrast the purpose of Phase II and Phase IV activities. \nPhase II activities take place when the initial set of EA documentation is developed. This begins with the selection of an EA documentation framework that will identify the scope of the architecture, guide the techniques for the modeling of current views, develop future scenarios and associated modeling, and establish an on-line EA repository that will archive all of the EA documentation artifacts . Phase IV is an ongoing set of activities that promotes the use of EA information by all stakeholders, and establishes an annual cycle for updates. This is where the value of the EA Program is realized, as planning and decision making throughout the enterprise are supported. This value is maintained through regular updates of the current and future views of the architecture. Value is also gained in the maintenance of the EA repository and the maintenance of all associated software licenses for modeling and archiving.
Compare and contrast the purpose of Phase II and Phase IV activities.
Phase II activities are designed to identify develop the initial set of EA documentation. This is where the decisions are made on documentation requirements and framework choices. These choices will define the scope of the EA architecture and the techniques for developing current views. This is also where the on-line EA repository is created. The ‘how’ of EA is decided in Phase II.
Phase IV is, by contrast, the set of activities promoting the use of EA work output by stakeholders and providing for the regular updating of the enterprise architecture. If you take the view of EA as a cycle, then Phase II occurs prior to the entry into the EA cycle whereas Phase IV is the cycle of EA input, review, documentation, socialization, and updates that occurs annually. It is the ongoing set of activities that promotes updating and use of EA information. This is where the business and other stakeholders realize the value of EA.
=====
Can the steps of the EA methodology be changed for different enterprises?
Yes. The EA 3 methodology is generalized so it can be used in a wide variety of public and private sector enterprises, and can support many types of EA frameworks, tools, and repositories. Depending on the type of enterprise, some parts of the EA methodology may need to be changed.
Who is responsible for execution of the EA program and EA methodology?
The executive sponsor must provide the Chief Architect with enough resources (e.g., budget, personnel, hardware/software, and facilities) and the authority to be able to properly establish the EA program. The Chief Architect should be accountable for EA program resources. The second step in the EA methodology is for the Chief Architect and EA team to identify all of the steps in the methodology that the enterprise needs in order to create an effective EA program. The important thing to remember in starting an EA is to have an actionable methodology that will guide program implementation and subsequent documentation activities, as well as reduce the risk of the EA program losing focus, effectiveness, and value.
How often should an EA be updated? Why?
There is no set standard for the frequency in which an enterprise architecture should be updated. The Methodology and frameworks should allow for updates that are in alignment with the company’s needs. The EA should be updated at least annually and/or every time the corporate level strategy, business level strategy, or product level strategy changes. These changes should prompt a review of the enterprise architecture to identify updates needed to support higher-level strategies.
The information in the EA repository is valuable for planning and decision-making only as long as it is comprehensive and accurate. Therefore, it is important to regularly update the current and future views of EA components in all areas of the framework. Further, it is helpful to users of EA information if the updates are made on a regular schedule, perhaps twice a year. Also, it is important to maintain version control in between updates, so that all of the users of the EA information know that they are conducting planning and decision-making activities based on the same information. Since what is planned in the future EA views will eventually become the current architecture (at least some of it), it should be recognized that EA updates are ongoing activities that do not cease. Future EA plans will continue as an organization grows and changes. Consider a time when the enterprise no longer needs changes in future capabilities and resources. Should this occur, the EA program transitions from focusing on the establishment of the EA to maintaining the EA and seeing that it continually brings value to the enterprise.
