While the overriding concern of EA governance is the effectiveness of the IT investments, the EA program itself needs to be governed as well, since an incorrectly developed EA could adversely impact the IT investment decisions that are based on it. Therefore the EA governance described in this article addresses two primary objectives: Ensure that the EA program is properly managed and that it produces artifacts and plans that are truly representative of organizational goals and needs. Ensure that the IT investment decisions are being continually aligned with the EA from the point they are initiated until implemented. To address these objectives, we’ll discuss a basic approach called “EA Governance Framework”. The EA Program Governance Framework The EA governance framework discussed in this article identifies key EA activities by phase. The proposed EA governance framework thus provides the “when,” “what,” and “who.” After it is reviewed, finalized, and accepted, the framework can become the basis for designing and implementing the EA governance process. For the governance process to become operational, it will also be necessary to develop some detailed operating procedures (“how”) for selected activities.

 

The following sections describe the proposed EA governance framework for each major phase of the EA program. Each EA program phase is briefly characterized in terms of its key EA activities and the reasons why EA governance for that phase is important and required.

 

Phase 1: Identify EA Program Life Cycle Phases The approach used to design the EA program governance framework encompasses the entire EA program life cycle. Within this life cycle, seven distinct steps of the EA program must be identified:

Step 1—EA Program Authorization and Start-Up: This phase describes the EA activities and related decisions typically required during EA program authorization and start-up and subsequent program reapproval.

Step 2—Develop Baseline EA: In step 2, a baseline EA is developed in strategy, business, application, data, and technology areas including security.

Step 3—Develop Target EA: In step 3, the future architecture is developed. The target architecture based on this vision is developed also in the strategic, business, application, data, and technology areas including security as well.

Step 4—Perform Gap and Opportunity Analysis: This phase utilizes baseline and target architecture information as inputs and identifies the gaps in and opportunities for IT support. Each gap or opportunity must be evaluated in terms of its cost, benefits, and risks and is used to prioritize the gaps and opportunities and to develop the Transition Sequencing Plan.

Step 5—Develop Transition Strategy and SequencingPlan: During this phase, the gaps and opportunities are translated into IT projects. Individual project costs, benefits, and risks are summarized for the entire IT project portfolio and presented for funding approval.

Step 6—Utilize EA to Manage IT Investments:In step 6, the EA is utilized to support management of the IT investment portfolio(s). The IT project is either “inserted” in the appropriate priority slot in the Transition Sequencing Plan, or if it has the highest priority, it is approved for immediate implementation.

Step 7—Maintain EA: As changes specified in the target EA are implemented, both the baseline and target EA must be updated.

 

The EA program activities performed in this step and related governance are the combination of those described in phases 2 and 3.

 

Phase 2: Identify EA Activities That Require Governance Oversight Within each phase, the EA activities that require governance oversight should be identified. EA activities should be maintained to reflect the impact of ongoing changes in strategy, business processes, data, applications, and technology. This will enable the EA to continually support the Capital Planning and Investment Control (CPIC) process so that only the smartest, most effective IT investments are made to support the organization’s strategy. Phase 3: Identify Organizational Entities and Stakeholders Involved in EA Governance The organizational entities and stakeholders involved in EA governance must be identified and should include members from the strategy, business, information technology, and program/project offices to ensure that business processes and technology are accurately reflected in the EA. The governance structure should be responsible for ensuring that the EA provides the best possible information and guidance to information technology projects and stakeholders, and that systems development efforts are properly aligned with the technology standards, data standards, and business processes identified in the EA.

 

Phase 4: Identify and Define Governance Roles and Authorities of Key Organizational Entities and Stakeholders Several EA governance roles and authorities should also be identified. They are defined as follows: “Responsible” Role—The organizational entity or an individual assigned this role “owns” (i.e., has the primary responsibility for) a specific EA activity and is accountable for its initiation and execution. “Work” Role—The organizational entity or an individual assigned this role has the primary responsibility for performing the work required by the specific EA activity. “Provide Input” Role—The organizational entity or an individual assigned this role provides inputs that are required for the specific EA activity (i.e., consultative meetings, brainstorming sessions, providing copies of documents, etc.). “Approve/Disapprove” Authority—The organizational entity or an individual assigned this authority provides interim or final approvals/disapprovals on specific EA activities. The approvals or disapprovals must be based on published and approved organizational procedures, policies, plans, guidelines, and/or strategies. “Need To Know” Role—The organizational entity or individuals assigned this role typically receive information about EA activities and use this information to be cognizant of the status and/or outcome of a specific EA activity, or as additional input to add value in their own business activities. The roles and authorities of the organizational entities and stakeholders are not constant; instead, they may vary depending on the specific EA activity. Phase 5: Map Governance Roles and Authorities to EA Program Activities The operating charters and mission statements of the organizational entities and stakeholders involved in EA governance should be reviewed and their EA governance roles and authorities identified. Additionally, system documentation should be reviewed and analyzed, primarily with respect to IT project governance throughout System Development Life cycle (SDLC).

 

From this analysis, the EA governance roles of the organizational entities proposed for each phase of the EA program can be mapped to phase-specific EA activities. Phase 6: Develop Enterprise Architecture Metrics The ultimate goal of an EA program is not to simply build and maintain information stores and models, but to use them to make effective management decisions. Toward that end, organizations should develop a set of performance metrics to evaluate the agency’s ability to develop, maintain, and use the EA. Moreover, metrics should be developed to evaluate whether EA products being developed are of high quality. Developing performance metrics to evaluate compliance and measure the degree to which the EA is utilized in decisions regarding IT investments is important. EA Governance Implementation Implementation of any EA governance process will require several steps. First, the EA governance framework described in this article must be reviewed and approved by the organizational entities and stakeholders who are involved in or are impacted by the EA program. This is expected to be a lengthy process, but a consensus must be reached before proceeding any further. Second, as the EA program matures, selected EA governance procedures that will describe “how-to” details of the EA governance will need to be developed. The following EA governance procedures are particularly critical: Introduction of a new standard or standard update. Prioritization process and criteria for inclusion of IT projects in the Transition Plan.

 

IT project impact analysis. Alignment of IT projects with EA at SDLC milestones. Waiver requests for noncompliance IT standards with EA. Third, an EA governance implementation plan should be written that will expand on the EA governance framework and provide a schedule for implementing additional items not included in the framework. The implementation of the EA governance process within an organization will be the responsibility of the EA program manager or chief architect. The first step in implementing the EA governance process will be reviewing, fine-tuning, and approving the EA governance framework. Once the framework has been finalized and approved, the supporting EA governance procedures, some of which are identified in this article, will need to be developed and communicated to all parties involved.