• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
US EPA: OEI: Enterprise Architecture Governance Procedure ...
 

US EPA: OEI: Enterprise Architecture Governance Procedure ...

on

  • 1,193 views

 

Statistics

Views

Total Views
1,193
Views on SlideShare
1,193
Embed Views
0

Actions

Likes
0
Downloads
55
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    US EPA: OEI: Enterprise Architecture Governance Procedure ... US EPA: OEI: Enterprise Architecture Governance Procedure ... Document Transcript

    • U.S. Environmental Protection Agency ENTERPRISE ARCHITECTURE GOVERNANCE PROCEDURE April 4, 2006 CIO 2122-P-01.0 (no former number)
    • Table of Contents Purpose..................................................................................................................................... 3 Audience................................................................................................................................... 3 Background ............................................................................................................................. 3 Procedure................................................................................................................................. 4 1. Overview .......................................................................................................................... 4 1.1 Overview of the EA Governance Procedure ..............................................................4 1.2 Enterprise Architecture Framework ..........................................................................6 2. Segment Architecture ..................................................................................................... 8 2.1 Segment Architecture Development, Review and Approval ......................................8 2.2 Segment Architecture Compliance Certification Process .......................................10 3. Solution Architecture.................................................................................................... 12 3.1 Solution Architecture Development, Review and Approval ....................................12 3.2 Solution Architecture Compliance Certification Process........................................13 4. Enterprise Architecture................................................................................................ 16 4.1 Integration of Segment and Solution Architectures................................................16 4.2 Enterprise Baseline Maintenance ............................................................................16 4.3 Annual EA Review ....................................................................................................16 4.4 Target Architecture Review and Approval...............................................................17 4.5 Transition Strategy Review and Approval ...............................................................18 4.6 Sequencing Plan Review and Approval ...................................................................19 5. EA Program Management Document Review and Approval Process..................... 21 Waivers .................................................................................................................................. 23 Roles and Responsibilities .................................................................................................... 23 Definitions.............................................................................................................................. 29 Additional Information ........................................................................................................ 30 APPENDIX A: RELATED DOCUMENTS ....................................................................... 31 2 EA Governance Procedure
    • Approval Date 4/4/06 Review Date 4/09 Subject The Environmental Protection Agency (EPA) Enterprise Architecture (EA) is a strategic information asset base that describes the Agency’s business, the information necessary to operate the business, the technologies necessary to support the business operations, and the transitional processes necessary for implementing new technologies in response to changing business needs. Purpose The purpose of the Enterprise Architecture Governance Procedure (the “EA Procedure”) is to address how the business processes of the EPA Enterprise Architecture Policy (the “EA Policy”) are implemented (see also section 1.1.1). Audience The primary audience for the EA Procedure is individuals who have direct responsibility for the strategic planning of EPA’s business, data, applications, and technology including, but not limited to: members of the Quality and Information Council (QIC), Quality Technology Subcommittee (QTS) and Information Investment Subcommittee (IIS), Senior Information Officials (SIOs), Information Management Officers (IMOs), National Program and Regional Managers, Segment Architects, members of the Enterprise Architecture Coordination Workgroup (EAWG), System Owners, Project Managers, Solution Architects, and the EA Team. Background The Clinger-Cohen Act of 1996, Executive Order 13011, Office of Management and Budget (OMB) Circular A-130 and OMB Circular A-11 require that each federal agency establish an EA program that focuses on the results achieved through capital investments, enhances collaboration, and ultimately enables transformation of the federal government into a citizen-centered, results-oriented, market-based organization. EPA has developed an EA that must be maintained and updated under formal direction and governance in alignment with the Federal Enterprise Architecture 3 EA Governance Procedure
    • (FEA) to support Presidential Initiatives and Executive Orders, and to assist in the Agency’s execution of its mission. The EPA EA provides a performance-oriented framework for documenting the cross-cutting and mission-specific business activities of the Agency, from alignment of strategic objectives to flow of processes and the technologies that support them. The EPA EA also provides a federally compliant approach to developing documentation in a manner that is consistent across EPA. Ultimately, the EA leads to the creation of a strategic information base that provides EPA managers with the enterprise-wide knowledge needed to make more informed business decisions. Authorities The Clinger-Cohen Act of 1996 (also known as the Information Technology Management Reform Act of 1996) (Pub. L. 104-106, Division E); Executive Order 13011, Federal Information Technology, FR 61-140, July 19, 1996; OMB Circular A-11, Preparation, Submission, and Execution of the Budget (revised November 2, 2005); OMB Circular A-130, Transmittal Memorandum #4, Management of Information Resources (November 28, 2000); EPA Enterprise Architecture Policy, Directive 2120.3 Procedure 1. Overview 1.1 Overview of the EA Governance Procedure 1.1.1 Purpose The purpose of the EA Procedure is to institute the business processes for implementing the EA Policy . The EA Policy establishes the high-level governance of the EPA EA program, sets direction for how the EA will be developed and maintained, and establishes how information technology (IT) investments will be evaluated for compliance with the EA. The EA Procedure accomplishes its objectives in a number of ways: 1. Expands on the EPA EA Program’s existing governance structure established in the EA Policy and documented in the EPA Enterprise Architecture (EA) Governance Framework in order to: i. define in detail the roles and responsibilities for developing and approving the EPA EA and its artifacts, 4 EA Governance Procedure
    • ii. ensure Agency participation throughout the entire EA development, review and approval cycle, and iii. ensure Agency review and approval at formal levels when issuing the Agency’s authoritative EA. 2. Directs readers to the supporting EPA procedures, standards, guidance, and tools for developing and maintaining the EA in conformance with the FEA, utilizing a common framework and methodology agency-wide (including EA standards, guidance, tools, and templates, the authoritative architecture repository, the Capital Planning and Investment Control (CPIC) Procedures, and the System Life Cycle Management (SLCM) Procedure 1 ). 3. Establishes and documents the review and approval processes for ensuring the development of a compliant architecture at all levels (enterprise, segment, and solution) including: i. review and approval of segment architectures, and certification of compliance with the Agency’s EA, ii. review and approval of solution architectures, and certification of compliance with the Agency’s EA, iii. maintenance, review, and approval of the enterprise baseline and target architectures, transition strategy, and sequencing plan, including integration of certified compliant solution and segment architectures, and coordination of the Annual EA Review, and iv. review and approval of EA program management documents. 4. Establishes the process for evaluating conformance of IT investment solution architectures with the Agency EA and applicable requirements of the CPIC Procedures and SLCM Procedure. 1.1.2 Content and Organization The table below lists and describes the sections of the EA Procedure and how they correspond to sections of the EA Policy: EA Procedure Section Description EA Policy Section 1. Overview Provides an overview of the EA Procedure, including I its purpose, contents, and organization. 1 EPA’s Interim Systems Life Cycle Management (SLCM) Policy and Interim SLCM Procedure have been extended until superseded. However, this EA Procedure references updated versions which are currently in review, therefore, references are contingent on Agency approval of final SLCM Policy and SLCM Procedure. 5 EA Governance Procedure
    • EA Procedure Section Description EA Policy Section 2. Segment Architecture Establishes and documents the process for II, III developing, reviewing and approving segment architectures, and for certifying their compliance with the Agency EA. 3. Solution Architecture Establishes and documents the process for II, III, IV developing, reviewing, and approving solution architectures, and for certifying their compliance with the Agency EA. 4. Enterprise Establishes and documents the processes for II, III Architecture developing, maintaining, reviewing, and approving the Agency EA, including integration of solution and segment architectures, and conduct of the Annual EA Review. 5. EA Program Establishes and documents the process for reviewing I, II, III Management Document and approving EA program management documents. Review and Approval The EA Procedure also includes sections covering the process for obtaining waivers from the procedure, roles and responsibilities, and definitions of EA terms and concepts. Also included in the EA Procedure are an appendix for related documents and related attachments. 1.2 Enterprise Architecture Framework The EPA EA Framework, as depicted in Figure 1, is consistent with best practices as defined by the Federal Enterprise Architecture Framework (FEAF). The framework includes 1) a baseline architecture, 2) a target architecture, and 3) a transition architecture that describes the migration from the baseline to the target and includes the transition strategy and sequencing plan. As shown, the framework also describes all five layers of the architectural pyramid (strategic, business, data, application, and technology). In accordance with best practices as specified by OMB, federal agencies should have the ability to integrate the architectural content of all of an agency’s constituent organizational units at all layers of the architecture. Consistent with this best practice, the EPA has further adopted the concept of architecture tiers. As shown in Figure 1, the EA Framework now includes enterprise, segment, and solution tiers. Federal Enterprise Architecture FEA EPA Enterprise Architecture Framework Baseline Architecture Transition Architecture Target Architecture Enterprise Tier Enterprise Tier Performance Improvement Plan Segment Tier Segment Tier Transition Strategy Solution Tier Solution Tier Sequencing Plan EPA Non-Federal Partner Architectures Figure 1. EPA Enterprise Architecture Framework 6 EA Governance Procedure
    • The Agency EA Team is responsible for development and maintenance of the enterprise tier of the architecture. The enterprise tier enables the integration of multiple segment architectures. Segment architectures 2 are individual architecture programs within the EA that are developed around groups of business or service functions supporting a common goal. In EPA, these groups can be: 1) programmatic, based on business or service functions within a program (e.g., Drinking Water Protection architecture); 2) organizational, based on business or service functions within a Program Office (e.g., Office of Water architecture); and 3) cross-cutting, based on business or service functions performed across multiple Agency organizations and programs (e.g., Geospatial architecture). Segment Architects are responsible for developing segment architectures. However each segment may use a team of architects to assist in the effort. These various segment architectures comprise the segment tier as depicted in Figure 1 above. Governance structures within segment architectures can be tailored according to the size and complexity of the segment. An example of an existing governance structure is the Administrative Systems Architecture (ASA). The ASA Steering Committee is the standing governance structure which encompasses the segments of the architecture that relate to activities within the management of government resources and support delivery of services areas of the FEA Business Reference Model (BRM). The common underpinnings for these business areas are the federal statutes that require appropriate financial and administrative systems controls in place to ensure compliance with the requirements to provide sound financial and other administrative services. This governance structure also ensures an integrated approach to identifying and building solutions that require cross organizational collaboration to deliver value to the agency while meeting legislative requirements. SIOs responsible for segment architectures under their purview are encouraged to establish governance structures within their segments to ensure synergy between other segments, particularly in cross-cutting segments that involve multiple program offices. The final tier of the EPA EA Framework is the solution tier. A segment architecture may contain one or more solutions. Solution architectures are specific investments or initiatives that solve a particular business problem (typically technology-based solutions). Solutions, if they are investments, are subject to the Agency’s CPIC Procedures and SLCM Procedure. It is important to note that, while a single segment may contain a solution, multiple segments may use that solution. In this manner, the Agency’s EA Framework seeks to support the objective of reuse while ensuring clear lines of responsibility for the architecture and implementation of solutions. Solution Architects are responsible for developing solution architectures. In order to ensure the development and ongoing maintenance of the EPA EA at all levels in conformance with the EPA EA Framework utilizing a 2 The EA Policy uses the term “Component Architectures”. 7 EA Governance Procedure
    • common methodology, two supporting documents have been developed: 1) the Architecture Development Content Standard, which establishes the required contents of the EA (i.e., the “what”), and 2) the Architecture Development Methodology, which provides guidance on a methodology for developing the EA (i.e., the “how”). The Architecture Development Tools and Templates have also been developed, which unite the two documents and facilitate the implementation of the EA development methodology and the population of the architecture repository via easy-to- use tools and templates. Additional standards and guidance may be prepared as deemed necessary. 2. Segment Architecture 2.1 Segment Architecture Development, Review and Approval This section of the EA Procedure establishes and describes the roles for developing and the process for reviewing and approving segment architectures (see Figure 2). Who: Assistant Administrator (AA), Regional Administrator (RA), Laboratory Director, CIO, QIC, CTO, SIO, Chief Architect, Segment Architect What: EA standards, tools and templates, authoritative architecture repository (see Appendix A). How: EA Guidance, tools and templates, authoritative architecture repository (see Appendix A). When: As determined by the QIC Process: 1. Each year, the Chief Architect, in conjunction with the EAWG, develops recommendations for segment architecture priorities. The Chief Architect recommends list of priorities to the QIC SC for review. The QIC SC then recommends segment architecture priorities and suggested programmatic leads to the QIC, which in turn, recommends to the CIO for approval. 2. SIOs, or designees, assume accountability for segment architectures under their purview. NOTE: SIOs are encouraged to establish governance structures within their segment architectures. For example, the ASA and Research and Science Architecture (RSA) segments have established governance bodies including a workgroup and steering committee comprised of cross-office representatives. 3. SIO assigns development responsibility for each of their segment architectures to a Segment Architect and structures governance of their segment architectures based on the size and complexity of the segments. 8 EA Governance Procedure
    • 4. Segment Architect develops the segment architecture, using EA standards, EA guidance, tools and templates, to accurately address the business needs of the segment. 5. Segment Architect provides segment architecture to the SIO, or designee, for validation. NOTE: Segment Architects are to submit their segment architectures to the SIO throughout the year as significant portions of them are developed. This ensures segment architectures are properly maintained in the Agency EA. Segment Architects are notified by the Chief Architect four weeks prior to beginning of Annual EA Review (see section 4.3) so as to allow time for them to update their architecture information prior to analysis. 6. SIO, or designee, reviews segment architecture. SIO validates that segment architecture accurately addresses segment’s business needs OR indicates areas needing modification to Segment Architect. 7. SIO submits segment architecture submission to the Chief Architect for EA compliance certification (to Section 2.2). 8. Once segment architecture is certified EA compliant (or appropriate waivers have been obtained), SIO forwards segment architecture to his/her AA, RA, or Laboratory Director (or a designee) for final approval. 9. AA, RA, or Laboratory Director approves segment architecture and uses it to better inform budget and capital planning decisions OR requests modifications from the SIO (return to Step 6). 10. Once AA, RA or Laboratory Director approves segment architecture, EA Team integrates it with the Agency EA (see Section 4.1 below) following change management procedures (See EA Configuration Management Plan). Transition: Chief Architect, in conjunction with the EAWG, develops recommendations for segment architecture priorities. The Chief Architect recommends list of priorities to the QIC SC for review. The QIC SC then recommends segment architecture priorities and suggested programmatic leads to the QIC, which in turn, recommends to the CIO for approval. SIO identifies Segment Architects to develop segment architectures under their purview. Segment Architects become members of the EAWG and work in collaboration with EA Team. The EA Team releases standards, guidance, tools and templates in a phased approach, working closely with the Segment Architects phase by phase to 1) assist with architecture development and 2) fine-tune the standards, guidance, tools and templates in response to Segment Architect feedback. The EA Team coordinates with the Segment Architects to set appropriate timelines for collecting architecture information. 9 EA Governance Procedure
    • 2.2 Segment Architecture Compliance Certification Process This section of the EA Procedure establishes and documents the process for certifying segment architecture compliance conducted by the Chief Architect (see Figure 2). Who: SIO, Chief Architect, Segment Architect, EA Team What: EA standards, tools and templates, authoritative architecture repository (see Appendix A). How: EA guidance, tools and templates, authoritative architecture repository (see Appendix A). When: As significant portions of the segment architecture are developed. 1. Segment Architect provides segment architecture to the SIO, or designee, for validation. NOTE: The Segment Architect is to submit segment architectures to the SIO throughout the year as they are developed. This ensures segment architectures are properly maintained in the Agency EA. Segment Architects are notified by the Chief Architect four weeks prior to beginning of Annual EA Review (see section 4.3) so as to allow time for them to update their architecture information prior to analysis. 2. SIO, or designee, reviews segment architecture. SIO validates that segment architecture accurately addresses segment’s business needs OR indicates areas needing modification to Segment Architect 3. SIO submits the segment architecture to the Chief Architect. 4. Prior to integration with the Agency EA, the Chief Architect (or designee) conducts a compliance certification review to assess segment architecture alignment with the Agency EA using predetermined criteria defined in EA standards. 5. If segment architecture is compliant, the Chief Architect certifies it as such and provides EA certification documentation to the SIO. 6. If segment architecture is not compliant, the Chief Architect indicates areas of non-compliance to the SIO. The SIO submits revised segment architecture OR applies for a waiver (see the “Waivers” section of the document for a description of the waiver process). Transition: Segment Architects develop their segment architectures in collaboration with EA Team. The EA Team releases standards, guidance, tools, and templates in a phased approach, working closely with the Segment Architects phase by phase to 1) assist with architecture development and 2) fine-tune the standards, guidance, tools, and templates in response to Segment Architect feedback. The EA Team coordinates with the Segment Architects to set appropriate timelines for collecting architecture information. The segment architecture compliance certification process will be implemented once CIO, or a designee, approves and issues EA standards. 10 EA Governance Procedure
    • 11 EA Governance Procedure
    • 3. Solution Architecture 3.1 Solution Architecture Development, Review and Approval This section of the EA Procedure establishes and documents the roles for developing, and the process for reviewing and approving solution architectures (see Figure 3). Who: Chief Architect, Segment Architect, Solution Architect, EA Team What: EA standards, tools and templates, authoritative architecture repository (see Appendix A). How: EA guidance, tools and templates, authoritative architecture repository, SLCM Procedure, authoritative information resource inventory and EPA registries and repositories (see Appendix A). When: SLC phases, project-level reviews and Control Gates 1 and 2 (see SLCM Procedure). Process: 1. Solution Architect develops solution architecture to accurately address segment’s business needs using EA standards, EA guidance, tools, and templates and the SLCM Procedure for the solution development process. Solution architectures are required for any solution meeting CPIC or CPIC Lite criteria (see CPIC Policy and CPIC Procedures). 2. The solution architecture (created during the Definition Phase of the SLC) is evolved through the SLC with more detail added at each phase. Solution architectures are used by the Chief Financial Officer (CFO), CIO, IIS, and System Owners to better inform budget and capital planning decisions throughout the SLC. NOTE: As part of the Agency’s CPIC process, Solution Architects attach solution architectures to their CPIC and CPIC Lite business cases to better inform budget and capital planning decisions made by the CFO, CIO, IIS, and SIOs. Chief Architect uses solution architecture to certify IT portfolio as EA compliant as part of the annual CPIC cycle. 3. Throughout the SLC, the solution architecture is reviewed after each phase of the SLC. There are two types of reviews: i. Project-level Review: The System Owner and Segment Architect(s) ensure 1) solution architecture accurately addresses segment’s business need and 2) checks for compliance with the EA. Project-level reviews occur at the end of every SLC phase (see SLCM Procedure). ii. Control Gate Review: The SIO and Chief Architect certify solution architecture as EA compliant twice during the SLC at Control Gate 1: System Selection and Control Gate 2: EA Compliance Certification Review. Control Gate 1 occurs at the end of the 12 EA Governance Procedure
    • Definition Phase and Control Gate 2 occurs at the end of Acquisition/Design sub-phase. For details of the compliance certification process, see Section 3.2 below. 4. Solution Architect submits the solution architecture to the EA Team at the successful completion of each review described above (both project-level and control gate). 5. EA Team integrates solution architecture with the Agency EA (see Section 4.1 below) following change management procedures (See EA Configuration Management Plan). Transition: Solution Architects develop their solution architectures using current EA and SLCM standards relevant to SLC phase. To successfully complete a project-level or control gate review and move to the next SLC phase, Solution Architects must complete their solution architectures to the standard required for the particular SLC phase. 3.2 Solution Architecture Compliance Certification Process This section of the EA Procedure establishes and documents the process for solution architecture compliance certification conducted by the Chief Architect at Control Gate 1: System Selection and Control Gate 2: EA Compliance Certified Review of the SLCM Procedure (see Step 3ii in Section 3.1 above and Figure 3). Who: SIO, QTS, Chief Architect, Solution Architect, EA Team What: EA standards, tools and templates, authoritative architecture repository, authoritative information resource inventory and EPA registries and repositories (see Appendix A). How: EA guidance, tools and templates, authoritative architecture repository, SLCM Procedure (see Appendix A). When: SLC Control Gates 1 and 2 (see Attachment 2) Process: 1. Solution Architect provides the solution architecture to the System Owner and Segment Architect for EA compliance check during all SLC reviews. Solution architectures are required for any solution meeting CPIC or CPIC Lite criteria (see CPIC Policy and CPIC Procedure). 2. As part of Control Gates 1 and 2, System Owner forwards solution architecture to SIO, or designee, for review. 3. SIO, or designee, reviews solution architecture and conducts a compliance certification review to assess solution architecture alignment with the Agency EA using predetermined criteria defined in EA standards. SIO validates that the solution architecture accurately addresses segment’s business needs and is EA compliant OR indicates areas needing modification to Solution Architect. 13 EA Governance Procedure
    • 4. If solution is following Full Sequential Work Pattern (determined by SLCM Procedure), SIO forwards the solution architecture to the Chief Architect for additional EA compliance review during Control Gates 1 and 2 (proceed to step 7) 5. If solution is not following Full Sequential Work Pattern (determined by SLCM Procedure), SIO certifies solution architecture as EA compliant and issues documentation of compliance certification to Chief Architect and Solution Architect. 6. Solution Architect submits the solution architecture to the EA Team at the successful completion of the control gate review (proceed to step 11). 7. Chief Architect, or designee, conducts a compliance certification review to assess solution architecture alignment with the Agency EA using predetermined criteria in EA standards. As part of Control Gate 2: EA Compliance Certification review, the Chief Architect also forwards solution architecture to QTS for concurrent technical feasibility review (For Control Gate 1: System Selection reviews, skip Step 9). 8. QTS reviews the solution architecture for technical feasibility and CTO either approves technical feasibility OR indicates areas needing modification to Chief Architect. 9. If the solution architecture is EA compliant, the Chief Architect certifies it as such and provides EA certification documentation to the SIO. 10. If the solution architecture is not EA compliant, the Chief Architect indicates areas of non-compliance to SIO. The SIO resubmits the revised solution architecture OR applies for a waiver (see the “Waivers” section of the document for a description of the EA Waiver process). Transition: The solution architecture compliance certification process will be implemented once CIO, through consultation with the QIC Steering Committee (QIC SC), approves and issues EA standards. Until such time, the Chief Architect will continue to use the CPIC business cases to certify solutions as EA compliant as part of the annual EA certification of the IT Portfolio. Solution architectures that are developed prior to development of their parent segment architecture must demonstrate alignment with the EA during compliance certification reviews. 14 EA Governance Procedure
    • 15 EA Governance Procedure
    • 4. Enterprise Architecture 4.1 Integration of Segment and Solution Architectures This section of the EA Procedure establishes and documents the process for integrating certified segment and solution architectures with the Agency EA (see Sections 2.2 and 3.2 above). Who: EA Team What: EA standards, tools and templates, authoritative architecture repository, authoritative information resource inventory and EPA registries and repositories (see Appendix A). How: EA guidance, tools and templates, authoritative architecture repository (see Appendix A). When: Throughout the year as certified submissions are received 1. EA Team performs a quality assurance (QA) check on released EA- compliant solution and segment architectures 2. EA Team integrates quality-approved, EA-compliant segment and solution architectures with the Agency EA by enabling population of the architecture repository with the solution and segment artifacts (bottom-up management of EA). 3. EA Team updates and maintains the Agency EA architecture as needed. 4.2 Enterprise Baseline Maintenance The baseline EA is maintained through periodic segment and solution architecture submissions (see sections 2, 3, and 4.1). As the segment and solution baseline architectures are incorporated into the enterprise model, the baseline EA is populated with up-to-date information. Architecture information that is inherent to the enterprise tier (i.e. EPA reference models) is incorporated by the EA Team following the EA Program Management Document Review and Approval Process (see section 5.0). 4.3 Annual EA Review This section of the EA Procedure establishes and documents the annual Agency EA review process. Who: Chief Architect, EAWG, EA Team What: EA Baseline, EA Target, EA standards, tools and templates, authoritative architecture repository, authoritative information resource inventory and EPA registries and repositories (see Appendix A). How: EA guidance, tools and templates, authoritative architecture repository (see Appendix A). 16 EA Governance Procedure
    • When: Annually, beginning in October 1. Chief Architect, EAWG, and EA Team use decisions made during the Agency’s strategic planning process (Agency’s strategic architecture) to perform a review of the integrated Agency EA, including the baseline “as is” architecture and the target “to be” architecture. EA review includes analysis across all baseline and target segment architectures. As a result of the Annual EA Review, the Chief Architect may or may not elect to update the target enterprise architecture in response to new Agency Strategic Plan, Government Performance and Results Act (GPRA) goals, Agency initiatives, legislation, OMB mandates, FEA guidance, data and metadata standards, records management requirements, security requirements, and emerging technologies. 2. Chief Architect, EAWG, and EA Team re-visit and refine Agency target architecture for business, data, applications, and technologies (top-down management of the EA). 4.4 Target Architecture Review and Approval This section of the EA Procedure establishes and documents the process for reviewing and approving the enterprise target architecture (see Figure 4). Who: CIO, QIC, QTS, CTO, Chief Architect, National Program and Regional Managers, Segment Architects/EAWG, and EA Team What: EA standards, tools and templates, authoritative architecture repository (see Appendix A) How: EA guidance, tools and templates, authoritative architecture repository (see Appendix A). When: As appropriate based on 1) the importance and impact of the changes submitted by the Segment Architects and 2) the results of the analysis conducted during the Annual EA Review (see Section 4.3 above). 1. EA Team works with Segment Architects in conjunction with the EAWG and National Program and Regional Managers to redefine and update the Agency target architecture based on the analysis conducted during the Annual EA Review (see Section 4.3 above). NOTE: The target EA refers to the target enterprise, target segment and target solution architectures collectively. Target segment and solution architectures 1) are developed in alignment with the Agency target EA and 2) serve to populate the target EA. The Target Architecture Review and Approval process manages change at the enterprise level —the target to which all segment and solution architectures will be built. This process is driven by analysis performed across segment and solution architectures and by the Annual EA Review which serves to identify external and internal initiatives that necessitate a change in the target EA. 17 EA Governance Procedure
    • 2. Chief Architect reviews target EA and concurs OR indicates areas needing modification to the EAWG and EA Team. 3. Chief Architect presents target EA to QTS and CTO. 4. QTS and CTO review technology and security architecture. 5. QTS and CTO concurs with technology and security architecture OR indicates areas needing modification to Chief Architect. 6. Chief Architect presents target EA to QIC. 7. QIC reviews the target architecture. 8. QIC concurs with the target architecture and recommends to the CIO OR indicates areas needing modification to Chief Architect. 9. CIO reviews, approves, and issues the authoritative target architecture OR indicates areas needing modification to Chief Architect. 10. Target Architecture is used to better inform Agency budget and capital planning decisions. 4.5 Transition Strategy Review and Approval This section of the EA Procedure establishes and documents the process for reviewing and approving the Agency transition strategy (see Figure 4). Who: CIO, QIC, QTS, CTO, Chief Architect, National Program and Regional Managers, EAWG, EA Team What: EA standards, tools and templates, authoritative architecture repository (see Appendix A). How: EA guidance, tools and templates, authoritative architecture repository (see Appendix A). When: As appropriate based on the Annual EA Review (see Section 4.3 above) and the issuance of the authoritative Agency target architecture (see Section 4.3 above). 1. EA Team works with Segment Architects and National Program and Regional Managers to redefine and update the Agency transition strategy based on the analysis conducted during the Annual EA Review (see Section 4.3) and the redefinition of the Agency target architecture (see Section 4.4 above). 2. Chief Architect reviews transition strategy and concurs OR indicates areas needing modification to EAWG and EA Team 3. Chief Architect presents transition strategy to QTS and CTO. 4. QTS and CTO review transition strategy for technical feasibility. 5. QTS and CTO concurs with transition strategy OR indicates areas needing modification to Chief Architect. 6. Chief Architect presents transition strategy to QIC. 7. QIC reviews the transition strategy. 18 EA Governance Procedure
    • 8. QIC concurs with the transition strategy and recommends to the CIO OR indicates areas needing modification to Chief Architect. 9. CIO reviews, approves, and issues the transition strategy OR indicates areas needing modification to Chief Architect. 10. Transition strategy is used to better inform Agency budget and capital planning decisions. 4.6 Sequencing Plan Review and Approval This section of the EA Procedure establishes and documents the process for reviewing and approving the Agency sequencing plan (see Figure 4). Who: CIO, IIS, QTS, CTO, Chief Architect, EAWG, EA Team What: EA standards, tools and templates, authoritative architecture repository (see Appendix A). How: EA guidance, tools and templates, authoritative architecture repository (see Appendix A). When: As appropriate based on 1) issuance of transition strategy (see Section 4.5 above) and 2) significant changes affecting sequence of milestones. Process: 1. As appropriate (see “When” above), EA Team works with Segment Architects on the EAWG to revise sequencing plan. 2. Chief Architect reviews sequencing plan and concurs OR indicates areas needing modification to EAWG and EA Team. 3. Chief Architect presents sequencing plan to QTS and CTO. 4. QTS and CTO review sequencing plan for technical feasibility. 5. CTO concurs with sequencing plan OR indicates areas needing modification to Chief Architect. 6. Chief Architect presents sequencing plan to the IIS. 7. IIS reviews the sequencing plan. 8. IIS concurs with sequencing plan and recommends to the QIC OR indicates areas needing modification to Chief Architect. 9. QIC reviews the sequencing plan 10. QIC concurs with sequencing plan and recommends to the CIO OR indicates areas needing modification to Chief Architect. 11. CIO reviews, approves, and issues the sequencing plan OR indicates areas needing modification to Chief Architect. 12. Sequencing Plan is used to better inform Agency budget and capital planning decisions. 19 EA Governance Procedure
    • 20 EA Governance Procedure
    • 5. EA Program Management Document Review and Approval Process This section of the EA Procedure establishes and documents the process for reviewing and approving EA Program documents (see Figure 5). EA Program Management documents include EA Governance (policies, procedures, standards and guidance), EPA Reference Models and the EA Program Management Plan. Who: QIC, QIC SC, QTS, Chief Architect, EAWG, EA Team What: EA Program Management Documents How: EA Program Configuration Management Plan When: Ongoing as needed 1. As it receives FEA guidance, senior management direction, and change requests, the EA Team develops new or updates existing EA program management documents. 2. EA Team submits EA documents to the EAWG for review and recommendation of approval. 3. EAWG reviews EA documents and submits them to the Chief Architect with its recommendation OR indicates areas needing modification to EA Team. 4. Chief Architect reviews EA documents and either concurs or non- concurs. If Chief Architect concurs, he or she may decide to elevate documents for additional review. If Chief Architect non-concurs, he or she indicates areas of non-concurrence to EAWG (Step 1). 5. If Chief Architect does not elevate document for additional review, Chief Architect approves and issues document. 6. If Chief Architect elevates the document for further review, he or she submits the document to either the QIC SC, QTS, or other governing body depending on the nature of the document (i.e. EA policies and procedures go to the QIC SC, technology standards go to the QTS and all other governance documents follow a review and approval process set forth by the CIO). 7. QIC SC, QTS or other governing body reviews the documents and either concurs OR indicates areas needing modification to Chief Architect. 8. QIC SC, QTS or other governing body submits approved documents to the QIC for review (unless otherwise directed by CIO in Step 5). 9. QIC reviews the documents and concurs OR indicates areas needing modification to Chief Architect. 10. CIO reviews the documents and approves OR indicates areas needing modification to Chief Architect. The CIO may also choose to not approve the document. 21 EA Governance Procedure
    • EA Program Management Document Review and Approval Process EA Team New or Updates to Update/Develop Program Program Mngmt No Mngmt Document Document No EAWG Review Document Concur? Yes Chief Architect Elevate Approve document for Review Document Concur? Yes No and Issue additional Document review? Yes- Elevate to Appropriate Body IIS/QTS/ QIC SC Review Document Concur? Yes Approve CIO Review Document Yes Approve? Yes and Issue Document 22 EA Governance Procedure
    • Waivers Requests for waivers from the EA Procedure are addressed to the CIO or his/her designee through the IT Waiver Process (See Attachment). Offices have the right to appeal a CIO decision to the Deputy Administrator as outlined in the QIC Charter. When a solution or segment architecture is determined to be non-compliant with the EA, the Solution or Segment Architect may apply for a compliance waiver via the IT Waiver Process. If the waiver is not approved, the Solution Architect or Segment Architect develops an EA compliance plan for approval by the Chief Architect or designee. Waivers are not permanent. Waiver terms are documented for each waiver specifying 1) a time period after which the solution or segment architecture must comply with the Agency EA, 2) the modifications that shall be made to the Agency EA to accommodate the solution, or 3) some combination of the two approaches specified. Whenever an EA requirement is waived, the Chief Architect and EAWG will determine if a change to the Agency architecture is necessary. If such a change is necessary, the Chief Architect initiates measures as may be necessary to accommodate the non-compliant architecture. The changes are subsequently approved by the CIO during the next annual update of the Agency architecture. Roles and Responsibilities The Chief Information Officer (CIO) (who also is the AA for the Office of Environmental Information (OEI)) is responsible for: • Approving and issuing the EA Procedure, EA technical standards, and guidance. • Ensuring Agency compliance with the EA Policy and EA Procedure. • Approving and issuing the enterprise architecture, transition strategy, and sequencing plan. • Approving waivers to the EA Policy, EA Procedure, and standards. The Assistant Administrators (AAs), Chief Financial Officer (CFO), General Counsel, Inspector General (IG), Deputy Chief of Staff to the Administrator, Associate Administrators, and Regional Administrators (RAs) and Laboratory Directors are responsible for: 23 EA Governance Procedure
    • • Ensuring compliance, within their organizations, with EA policy, procedures, and standards. • Providing business expertise to target enterprise architecture and transition strategy development efforts. • Approving segment architecture submissions and using architecture to better inform budget and capital planning decisions. The Chief Technology Officer (CTO) is responsible for: • Approving technical feasibility of solution architectures following Full Sequential Work Pattern during Control Gate 2: EA Compliance Certified Review. • Approving technical feasibility of transition strategy and sequencing plan. • Concurring on technology and security layers of the target EA. • Concurring on EA technology standards. The Chief Architect is responsible for: • Leading the development, maintenance, review, and approval of the Agency’s EA, including the baseline architecture, target architecture, transition strategy, and sequencing plan. • Notifying Segment Architects of upcoming Annual EA Review four weeks prior to commencing. • Facilitating the Annual EA Review. • Certifying and providing documentation of EA compliance for segment architectures. • Certifying and providing documentation of EA compliance for solution architectures following Full Sequential Work Pattern during Control Gate 1: EA Compliance Review and System Selection and Control Gate 2: EA Compliance Review. • Certifying IT Portfolio as EA compliant during annual CPIC cycle. • Providing templates, guidance, and toolsets to support segment and solution architecture submissions. • Ensuring timely response to OMB annual assessments and quarterly progress reports. 24 EA Governance Procedure
    • • Approving EA program management documents (except for EA policies, procedures, and standards). • Developing segment architecture priorities, in conjunction with EAWG, and recommending priorities to the QIC SC. • Communicating and implementing approved EA documents. The Chief Acquisition Officer (CAO) is responsible for: • Ensuring the EA Policy and the EA Procedure are incorporated, as appropriate, in requests for proposals (RFPs) and contracts. The Senior Information Officials (SIOs) are responsible for: • Ensuring compliance with the EA Policy and the EA Procedure. • Maintaining segment architectures under their purview and validating that segment architectures accurately address the business needs of the segment. • Validating that solution architectures accurately address the business needs of the segment. • Ensuring EA compliance of segment and solution architectures (during Control Gates 1 & 2 of the SLC) prior to inclusion in the Agency EA. • Forwarding solution architectures to the Chief Architect for EA compliance review during Control Gates 1 & 2 of the SLC (SLCM Procedure). • Certifying and providing documentation of EA compliance for solution architectures not following Full Sequential Work Pattern during Control Gate 1: EA Compliance Review and System Selection and Control Gate 2: EA Compliance Review. • Assigning Segment Architects to segment architectures. The Information Management Officers (IMOs) are responsible for: • Supporting SIOs in ensuring compliance with the EA Policy and the EA Procedure • Coordinating with Senior Budget Officers (SBOs) to ensure consistency of IT Portfolio during the annual CPIC process. The Quality and Information Council (QIC) is responsible for: 25 EA Governance Procedure
    • • Reviewing and concurring on the EA, including, but not limited to the target architecture, transition strategy and sequencing plan. • Ensuring compliance with the EA Policy and the EA Procedure. • Recommending segment architecture priorities and suggesting programmatic leads to the CIO for approval. The Quality and Information Council Steering Committee (QIC SC) is responsible for: • Reviewing and concurring on the EA Policy and the EA Procedure. • Reviewing and concurring on EA compliance standards. • Reviewing and recommending segment architecture priorities and suggesting programmatic leads to the QIC. The Information Investment Subcommittee (IIS) is responsible for: • Ensuring compliance with the EA Policy and the EA Procedure. • Ensuring projects are certified EA compliant before approving inclusion into the IT investment portfolio. • Reviewing and concurring on the Agency’s sequencing plan. The Quality Technology Subcommittee (QTS) is responsible for: • Reviewing and concurring on EA technical standards. • Reviewing and concurring on technical feasibility of solution architectures following Full Sequential Work Pattern during Control Gate 2: EA Compliance Certified Review. • Reviewing and concurring on technical feasibility of technology and security layers of the target EA. • Reviewing and concurring on technical feasibility of the transition strategy and sequencing plan. The Enterprise Architecture Coordination Workgroup (EAWG) is responsible for: 26 EA Governance Procedure
    • • Leading segment architecture efforts, including developing and maintaining baseline and target segment architectures, and transition strategies using EA standards and EA guidance. • Reviewing and concurring on EA management documents. • Analyzing across segment architectures during the Annual EA Review and reviewing and recommending solutions to issues identified during the Annual EA Review as appropriate. • Assisting Chief Architect in the Annual EA Review; evaluating internal and external business drivers that may influence change in the target EA. • Reviewing and recommending segment architecture priorities to Chief Architect. • Communicating and implementing approved EA management documents. The Segment Architects are responsible for: • Developing and maintaining their segment architecture using EA standards and EA guidance and ensuring alignment with the EA.. • Reviewing solution architectures with System Owners during project-level reviews (see SLCM Procedure) and ensuring solution architectures reflect the best practical solution to serving the business needs of the segment while remaining in alignment with the Agency EA. • Participating as a member of the EAWG. • Assisting Chief Architect in the Annual EA Review; evaluating internal and external business drivers that may influence change in the target EA. • Providing their segment architecture to the SIO for periodic validation and EA compliance check. • Obtaining waivers from the EA Procedure and the EA as appropriate. The Solution Architects are responsible for: • Developing and maintaining their solution architecture using EA standards and EA guidance and ensuring solution architectures reflect the best practical solution to serving the business needs of the segment while remaining in alignment with the segment architecture and Agency EA. • Providing their solution architecture for EA compliance check during SLC project-level and control gate reviews. 27 EA Governance Procedure
    • • Forwarding their solution architecture to the EA Team upon completion of project-level and control gate reviews. • Obtaining waivers from the EA Procedure where appropriate. NOTE: Solution Architects are responsible for developing solution architectures; however Project Managers can also be designated as having the responsibility for solution architecture. The System Owners are responsible for: • Assigning Solution Architects. • Ensuring solution architectures reflect the best practical solution to serving the business needs of the segment. • Ensuring compliance with the EA Policy and the EA Procedure. • Performing EA compliance checks (with Segment Architect) on solution architectures during project-level reviews. The Enterprise Architecture Team (EA Team) is responsible for: • Day-to-day functions of managing the EA Program including developing, updating, and facilitating review of EA management documents. • Integrating segment and solution architectures with the Agency EA following change management procedures. • Maintaining EPA’s EA using EA standards and EA guidance. • Providing templates and tools to support architecture submissions for integration with the Agency EA. • Facilitating and managing Agency EA business processes (including the Annual EA Review), and development of and updates to the Agency target architecture, transition strategy, and sequencing plan. • Performing analysis across segment architectures and evaluating internal and external business drivers that may influence change in the enterprise target architecture. • Responding to OMB annual assessments. 28 EA Governance Procedure
    • • Communicating and implementing approved EA program management documents. Definitions Architecture: 1) A structure representing an orderly arrangement of parts; 2) a method of design and construction; 3) a blueprint for design and construction (i.e., a description of structure and method); 4) a discipline dealing with the principles of design and construction. Architecture Repository and Tool: ART is the authoritative reference for the EPA EA, comprising the baseline, target, and transition (transition strategy and sequencing plan) architectures for the Agency. ART supports development and maintenance and can be accessed at http://intranet.epa.gov/architec/art.html. Baseline: The current or “as-is” state of the architecture. Baseline Architecture: Representation of the current state or “as is” for the architecture. Enterprise: An organization supporting a defined business scope and mission. An enterprise is composed of interdependent resources (people, organizations, and technology) that should coordinate their functions and share information in support of a common mission (or set of related missions). Enterprise Architecture: A strategic information asset base; which defines the business, the information necessary to operate the business, the technologies necessary to support the business operations, and the transitional processes necessary for streamlining business processes and implementing new technologies to improve service to citizens. It is a representation or blueprint. Enterprise Lifecycle: The integration of management, business, and engineering life cycle processes that span the enterprise. External Partners: Entities, external to EPA, with relationships within EPA’s EA. Examples of external partners include: the FEA, other federal departments and agencies, states, tribes, industry and academia. Federal Enterprise Architecture Framework: An organizing mechanism for managing development, maintenance, and facilitated decision making of a Federal EA. The Framework provides a structure for organizing Federal resources and for describing and managing Federal EA Activities. Methodology: A documented approach for performing activities in a coherent, consistent, accountable, and repeatable manner. 29 EA Governance Procedure
    • Segment: Individual architecture programs within the EA that are developed around groups of business or service functions that supporting a common goal. In EPA, these groupings can be: 1) organizational, based on business or service functions within a Program Office (e.g., Office of Water architecture); 2) programmatic, based on business or service functions within a program (e.g., Drinking Water Protection architecture); and 3) cross-cutting, based on business or service functions performed in multiple organizations and programs across the Agency (e.g., Geospatial architecture). Segment Architecture: An architecture that represents a selected portion (i.e., a segment) of the enterprise. A segment architecture provides the business and technical context for one or more related solution architectures. A segment architecture represents an independently developed architecture. Rather than necessarily representing an organization, it represents functions and processes that cross multiple organizations. Solution: An answer to part or all of a specific business problem. A solution generally, but not necessarily, involves IT Solutions are funded through investments to solve a designated business problem or performance gap. Solution Architecture: Specific investments or initiatives that solve a particular business problem (typically technology-based solutions). Solutions, if they are investments, are subject to the Agency’s CPIC Procedures and SLCM Procedure. It is important to note that, while a single segment may contain a solution, multiple segments may use that solution. Target: The future or “to-be” state of the architecture Target Architecture: Representation of a desired future state or “to be built” for the architecture within the context of the strategic direction. Transition Strategy: Identifies the gaps between the baseline and target architecture, specifies alternative approaches to fill the gaps, establishes priorities, assesses dependencies, and includes the sequencing plan. Recertification Date Additional Information For further information about this procedure refer to http://intranet.epa.gov/architec/ or contact the Chief Architect in the EPA Office of Environmental Information (OEI), Office of Technology Operations and Planning (OTOP), Mission Investment Solutions Division (MISD). 30 EA Governance Procedure
    • APPENDIX A: RELATED DOCUMENTS Updated: March 2006 Federal Laws and Guidance a) The Government Performance and Results Act of 1993 (GPRA) (Pub. L. 103-62); b) The Chief Financial Officers Act of 1990 (31 U.S.C. 3512 et seq.); c) The Federal Information Security Management Act of 2002 (which amends the Computer Security Act of 1987 (Pub. L. 100-235); d) The Paperwork Reduction Act of 1995 (Pub. L. 104-13); e) The Government Paperwork Elimination Act of 1998 (Pub. L. 105-277, Title XVII); f) The E-Government Act of 2002 (Pub. L. 107-347); g) The Rehabilitation Act of 1998 (Pub. L. 105-220); h) The Federal Managers Financial Integrity Act (FMFIA) of 1989 (Pub. L. 97-255); i) The Federal Financial Management Improvement Act (FFMIA) of 1996 (Pub. L. 104- 208); j) The Privacy Act, as amended (5 U.S.C. 552a); k) The Budget and Accounting Act, as amended (31 U.S.C. Chapter 11); l) The Federal Acquisition Streamlining Act (FASA) of 1994; m) The Chief Financial Officers Act of 1990; n) The President’s Management Agenda, Office of Management and Budget, Fiscal Year 2002; o) OMB Circular A-94, Guidelines and Discount Rates for Benefit-Cost Analysis of Federal Programs, revised January 22, 2002; p) OMB Circular A-123, Management Accountability and Control, dated June 21, 1995; q) OMB Circular A-127, Financial Management Systems, dated July 23, 1993; r) OMB Circular A-119 Federal Participation in the Development and Use of Voluntary Consensus Standards and in Conformity Assessment Activities s) Federal Enterprise Architecture Program EA Assessment Framework 2.0 31 EA Governance Procedure
    • Agency Plans, Policies and Procedures: t) EPA Strategic Plan u) EPA Capital Planning and Investment Control (CPIC) Policy & Procedures v) EPA System Life Cycle Management (SLCM) Policy & Procedures EA Standards 3 : w) Enterprise Architecture Development Content Standard EA Guidance: x) EPA Reference Models y) Federal Enterprise Architecture (FEA) Reference Models z) Architecture Repository and Tool (ART) Metamodel Training and Guidance Materials aa) Enterprise Architecture Procedure Flow Integration Diagram bb) Enterprise Architecture Program Configuration Management Plan Charters: cc) Charter of the Quality Information Council (QIC) dd) Charter of the Information Investment Subcommittee (IIS) ee) Charter of the Quality Technology Subcommittee (QTS) ff) Charter of the Enterprise Architecture Coordination Workgroup (EAWG) Waivers: gg) OEI Waiver Process (Obtaining a Waiver from an EPA IT Requirement Procedure) Authoritative Repositories and Registries: hh) Architecture Repository and Tool (ART) ii) Electronic Capital Planning and Investment Control (eCPIC) jj) Registry of EPA’s Applications and Databases (READ) kk) Extensible Mark-up Language Registry (XMLR) ll) Environmental Data Registry (EDR) 3 Additional standards and guidance are in development and this section will be updated as necessary. 32 EA Governance Procedure