Enterprise Architecture Implementation Methodology

The QualiWare Enterprise Architecture Implementation Methodology is a guide for establishing, maintaining and using an enterprise architecture (EA) framework and documentation approach.

Introduction
An EA methodology is a detailed, step-by-step description of how the EA program is to be established and run, and how the documentation of the EA is to be developed, maintained, and used. The establishment of an EA program has many facets and one of the keys to success is to use a detailed documentation methodology to get the program started, and then to guide the EA documentation effort. The EA methodology described in this guide is generalized so it can be used in a wide variety of public and private sector enterprises. The EA methodology presented in this guide is also flexible enough to support the use of many of the popular EA frameworks.

It is important to develop an EA methodology as one of the first steps in establishing the EA program, because it forces the enterprise to ‘think through’ the following important considerations:

• Which areas of the enterprise the EA will cover (scope)
• The approach to EA governance (e.g., centralized or decentralized)
• The types of EA documentation (known as artifacts) that will be needed to support business and technology resource planning and decision-making
• The EA documentation framework that best supports the needs of the enterprise
• The methods and techniques for gathering or developing EA documentation
• The software mode ling tools, web applications, and databases that will be needed to automate documentation techniques and enable future scenario modeling
• How EA users will access and share EA documentation (e.g. an EA repository)
• How often EA documentation will be updated

20 steps
The 20-step process presented on the following is an example EA implementation methodology that contains all of the general steps that would support the creation of a new, comprehensive EA program. It should be noted that the revitalization of an existing EA program will involve additional steps that will vary with each situation. Revitalization could focus on the selection of a different EA framework and implementation methodology, and/or the identification of new vertical and horizontal partitions of the enterprise that is being documented (segments and crosscuts).

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.

Phase II: EA Framework and Tool Selection

• Step 5: Select an EA documentation framework.
• Step 6: Identify EA Lines of Business/Crosscuts and the order of their documentation.
• Step 7: Identify the EA components to be documented framework-wide.
• Step 8: Select documentation methods appropriate for the framework.
• Step 9: Select software applications/tools to support automated EA documentation.
• Step 10: Select and establish an on-line EA repository for documentation and analysis.

Phase III: Documentation of the EA

• Step 11: Evaluate existing business and technology documentation for use in the EA.
• Step 12: Document current views of existing EA components in all framework areas (levels/threads). Store artifacts in the on-line repository.
• Step 13: Develop several future business/technology operating scenarios.
• Step 14: Identify future planning assumptions for each future scenario.
• Step 15: Use the scenarios and other programlstaffinput to drive the documentation of future EA components in all framework areas. Store artifacts in the on-line EA repository.
• Step 16: Develop an EA Management Plan to sequence planned changes in the EA.

Phase IV: Use and Maintain the EA

• Step 17: Use EA documentation to support planning/decision-making.
• Step 18: Regularly update current and future views of EA components, and link information in the EA repository to create high-level and detailed ‘perspectives’ of enterprise activities and resources in the current and future operating environments.
• Step 19: Maintain an EA Repository and related mode ling and analysis capabilities.
• Step 20: Release annual updates to the EA Management Plan.

Key Terms

Key Term: 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.

Key Term: 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.

Key Term: Executive Sponsor
The executive who has decision-making authority over the EA program and who provides resources and senior leadership for the EA program.

Key Term: EA Artifact
An EA artifact is a documentation product, such as a text document, system specification, application interface information, diagram, spreadsheet, briefing slides, and/or video clip.

This EA implementation methodology addresses the establishment of a new EA program and documentation set. The revitalization of existing, but unproductive EA programs, or switching approaches, key personnel, or contracted support should be handled through the addition of Steps in Phase I and/or Phase II to address these changes. The following are more detailed descriptions of each step in the example EA methodology.

Phase I: EA Program Establishment

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.

Step 1: Establish the EA Management Program and identify a Chief Architect.
The first step is for an executive sponsor to establish an EA program and identify a Chief Architect to lead the Program. The EA program is initially a start-up project (Phases I-Ill) and then an ongoing program (Phase IV). 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. One of the Chief Architect’s first actions should be to establish an EA team that consists of trained EA architects and representatives of various stakeholder groups.

Step 2: Establish an EA implementation methodology.
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. In starting an EA practice, it can be nice to have a detailed yet pragmatic methodology that will guide program implementation and subsequent documentation activities, in order to reduce the risk of the EA program losing focus, effectiveness, and value.

Step 3: Establish EA governance and links to other management processes.
The third step is for the executive sponsor and Chief Architect to codevelop an approach to EA governance that enables effective policy, planning, and decision-making within the EA management program. This approach to EA governance should include links to other management processes for strategic planning, capital planning, project management, security, and workforce planning.

Step 4: Develop an EA Communication Plan and gain stakeholder buy-in.
The next step is to develop an EA Communication Plan that articulates the EA documentation methodology and a schedule for Phase 11 and III activities. The EA Communication Plan should be written in plain language to gain stakeholder buy-in from non-technical executives, line of business managers, support staff, and other potential end users of EA documentation. The Communication Plan should include statements about the purpose and vision of the EA, examples of how the EA will bring value to the enterprise, where EA documentation will be available for access, a summary of the methodology used, and the general principles that will be used for EA development.

Phase II: EA Framework and Tool Selection

Phase 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 mode ling 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.

Step 5: Select an EA documentation framework.
The first step of Phase 11 involves the selection of an EA documentation framework by the Chief Architect, with input from the EA team and stakeholders. 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.

Step 6: Identify the EA Lines of Business/Crosscuts and the order of their documentation.
The second step of Phase 11 involves the identification of vertical Lines of Business (also known as Segments) and horizontal crosscutting initiatives within the enterprise that can be separately architected, and when combined, will represent the EA for the entire enterprise. Sometimes distinct vertical LOBs are readily apparent such as functional sub-units of an organization (e.g., the Manufacturing Division, Sales and Marketing Division, Research and Development Division, Administration and Finance Division). Sometimes however, the LOB/Segment is something that makes sense within the EA and is not an established organizational boundary, so it must be identified through work with stakeholders (e.g., vertical supply chains, missionspecific capabilities). Crosscutting initiatives are those horizontal activities which function in a “common operating environment” across several LOBs. Examples of horizontal crosscuts include web services, knowledge warehouses, network infrastructure, security solutions, ERP modules, and back-office systems/applications (e.g. email, document tracking, finance and accounting, human resources).

Step 7: Identify the EA components to be documented.
Step 7 of the EA documentation methodology is to identify the EA components that will have to be documented in each functional area of the framework. For example, the EA3 framework has six functional areas (strategy, business, information, services, networks, and vertical threads). Each of these areas represents a distinct set of activities that extend across the enterprise, which are represented by EA components. EA components are plug-and-play goals, processes, measures, projects, data, services, and IT resources in the various functional areas. An EA component therefore is unique in the capability and resources that it represents within the EA framework. Each EA component is documented using information gathering methods and mode ling techniques that are appropriate for the type of things that are contained in the EA component. For example, at the strategic level the enterprise’s strategic goals, activities, and outcome measures are the primary items to be documented. At the business level, the line-of business services and associated measures are documented. At the information level, the flows of information, databases, knowledge warehouses, and data standards are documented. At the services and applications level, the various web services, office automation services, and software applications are documented. At the technology infrastructure level the voice, data, and video networks, as well as associated cable plants and equipment facilities are documented. For the vertical threads, IT security information, IT standards, and IT workforce information are gathered for associated activities and resources in each of the five other functional areas.

Step 8: Select documentation methods appropriate for the framework.
The next step is to select the methods that will be used to gather and develop EA documentation artifacts. For example, the following are methods for modeling in the six functional areas of the EA3 Cube framework (five levels and three threads). Read more about the EA3 artifacts.

• Strategic Level: Strategic Plan, Scenarios, Balanced Scorecard
• Business Level: IDEF-O Diagrams, Flowcharts, Swim Lane Charts
• Information Level: Data Models, Object Diagrams, Data Dictionary
• Solutions Level: System Diagrams, Web Service Models, APIs
• Technology Level: Voice/Data/Video Network Diagrams/Documents
• Vertical Threads: Security Diagrams, Standards, IT Workforce Plans

It is important to choose documentation techniques that will provide the information that is needed for resource planning and decision-making. Therefore, the Chief Architect should consult with EA stakeholders and the EA team in selecting the methods for artifact development and what type of information will be gathered.

Step 9: Select software applications/tools to support automated EA documentation.
Once the functional areas/levels of the framework and the types of EA components are known, EA documentation and artifact mode ling requirements can be established. Without doing Steps 7 and 8, it would be difficult for the Chief Architect and EA team to know the particular modeling techniques that they will have to support. For example, if object-oriented methods are being used to develop artifacts at the information level of the framework, then an EA modeling tool that has capability with the Unified Modeling Language (UML) is called for.

Step 10: Select and establish an on-line EA repository for documentation.
The last step in Phase 11 is for the Chief Architect and EA team to select an EA repository software application and database. The EA repository should be hosted on the enterprise’s internal Local Area Network for security and ease of access to EA documentation. The EA repository is a database and file directory where all EA documentation is archived. One method to promote ease-of-use is to establish an EA web site that is the “front door” for all EA Program activities and documentation. This website’s homepage can be designed to promote a clear view of the scope of the EA documentation that is available.

Phase III: Documentation of the EA

Phase III activities are where the actual development of the EA occurs in the form of documentation artifacts. This 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.

Step 11: Evaluate existing business and technology documentation for use in the EA.
The first step of Phase III is the beginning of actual EA documentation activities. Preceding activities established what would be documented, how it would be documented, and who would do the documentation. The current view of EA components is what is now being documented through the identification of what the EA components are at each level of the framework and then using existing and new artifacts to document the EA components that currently exist. In many ways this activity is like taking an “inventory” of the components (strategic goals, business services, measures, data, services, and IT resources) that already exist in the enterprise and mapping them to existing documentation.

Step 12: Document current views of existing EA components in all framework areas.
The second step of Phase III is the development of new artifacts to complete the documentation of all existing components. The documentation methods and tools identified in Step 8 are used to gather and standardize existing artifacts, as well as to develop new artifacts. These documentation artifacts are organized by levels of the framework and are stored in the EA repository that was established in Step 10.

Step 13: Develop several future business/technology operating scenarios.
Prior to developing future views of EA components, it is helpful to gain a high-level understanding of the possible future directions that the enterprise could take, depending on how it responds to internal and external influences. Three or more future scenarios should optimally be developed with EA and line of business stakeholders to reflect what may occur if (1) the status quo is maintained; (2) an optimal business/technology operating environment is encountered; and (3) a high threat survival situation. There are several beneficial outcomes from the development of the scenarios. First, the enterprise is more prepared and organized to handle future situations and plan needed resources. Second, a number of planning assumptions are identified in each scenario that reveal what the priorities of the enterprise might be if that scenario is pursued. Third, the planning for future capabilities is more coordinated, as opposed to simply gathering separate inputs from line of business managers and technology managers. Separate inputs are known to perpetuate stovepipe capabilities.

Step 14: Identify future planning assumptions for each future scenario.
Each future scenario describes, in story form, a possible business/technology operating environment that the enterprise might pursue or face. In this step, the key elements of each future scenario are analyzed to reveal what things are important to the enterprise and what changes have to occur for the scenario to become reality. For the purposes of the EA, these key elements become the planning assumptions that can then be grouped together to represent changes in each of the functional areas of the framework. One of the benefits of having the scenario and planning assumptions is that they were developed with stakeholder buy-in, which will help when future changes are implemented.

Step 15: Use scenarios, program inputs, and scheduled updates to drive documentation of future components in all framework areas.
This step involves the documentation of changes to EA components in the near term (1-2 years) and the longer term (3-5 years). These changes should be derived from the input by the leadership team (CXOs) via the operating scenarios’ planning assumptions, and from program and project managers who know what the future business requirements are, as well as planned system implementations, upgrades, and retirements.. By doing it this way, the changes are more coordinated and aligned with the strategic direction of the enterprise. Future views of EA components should be developed using the same artifact documentation and mode ling techniques that were used to develop the current views. This helps to more clearly identify what the changes are in each of the functional levels of the EA framework, which helps in planning and decision-making.

Step 16: Develop an EA Management Plan to sequence planned changes in the EA.
The final step in Phase III is the development of an EA Management Plan. This Plan serves to articulate how the EA was developed and provides a synopsis of the current and future views. The Plan also provides a transition and sequencing sub-plan for the near term changes, which may already be in the project pre-implementation stage. Also, a long-range sequencing sub-plan is provided that covers the potential changes associated with the future scenarios.

Phase IV: Use and Maintain the EA

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 mode ling and archiving.

Step 17: Use EA documentation for resource planning and decisionmaking.
Upon the completion of Phase Ill, the current and future views of the architecture are stored in the EA repository and are ready to be used by the enterprise to support planning and decision-making. These EA stored artifacts become a baseline of reference information that can be used in a wide variety of executive, management, and staff activities. When this is done, a greater level of understanding is developed of capabilities and performance gaps among a wider group within the enterprise. Further, by having the EA documentation in an on-line repository, this information can be called up and referred to in meetings, which reduces the time it takes to convey an idea, increases comprehension, and reduces interpretation errors among meeting participants. For example, if in a planning meeting, one of the participants wanted to show needed improvements in information exchange within a particular line of business, EA documentation on the current and possible future views of that information flow could be called up from the repository and projected at the meeting. This, along with information on the associated business services, support applications, and networks can be referenced meaningfully. The time to convey the ideas is significantly reduced when diagrams and text are being shown to everyone at the meeting. This can stimulate more productive discussions and informed decisions.

Step 18: Regularly update current and future views of EA Components.
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.

Step 19: Maintain the EA repository and modeling capabilities.
The Chief Architect and EA team need to ensure that the EA repository and support applications/tools are kept current in terms of licensing and functionality. The requirements for archiving and modeling should be reviewed annually, and new products should be regularly reviewed to ensure that the EA team has the right application support capability. The team should be on the lookout for new improvements in tool functionality so that these improvements can be applied to the advantage of the enterprise. The costs for software purchases and license renewals should be part of the annual EA program budget.

Step 20: Release yearly updates to the EA Management Plan.
The Chief Architect needs to regularly inform EA stakeholders about the status of the EA. This is done through the annual release of an updated EA Management Plan that discusses changes that were made to the current and future views of the EA during the past year. The communication should provide a transition and sequencing plan for changes anticipated during the coming year. Also, the ongoing value of the EA needs to be communicated through the citation of examples of where EA documentation supported planning and decision-making, helped reduce duplicative capabilities, saved costs, improved alignment, and increased communication.

Summary of Concepts

This guide presented a comprehensive methodology for the implementation of an EA program and associated documentation activities. The four phases and twenty steps of the example EA methodology are generalized so they can be used in many types of public and private sector enterprises. Phase I activities serve to establish the EA program, identify a Chief Architect to lead the program, create an EA governance capability to run the EA program in a way that integrates with other IT management processes, and issue an EA Communication Plan to gain stakeholder buyin and support. Phase 11 activities serve to select an EA framework that defines the scope of the architecture, the EA components that will make up the architecture in each functional area, and software applications/tools to automate the documentation of EA components. Phase III is where the actual documentation of current and future views of the architecture occurs, as well as the development of an EA Management Plan to describe how the architecture will transition over time. The final Phase IV activities are where the EA is used throughout the enterprise to support planning and decision-making and regular updates are performed to keep the EA relevant and adding value.