DIRMM CHAPTER 4: ENTERPRISE ARCHITECTURE

TABLE OF CONTENTS

4.001 Purpose
4.002 Scope
4.003 References
4.004 Definitions
4.005 Goals
4.006 Policy
4.007 Responsibilities
4.008 Summary

4.001 Purpose

This chapter establishes policy and responsibilities to ensure that the Department of Transportation’s (DOT) Enterprise Architecture (EA) remains the primary asset for managing change in the enterprise, including compliant development, maintenance, use and integration with Strategic Planning and Capital Planning and Investment Control (CPIC) through an enterprise governance structure, which delivers consistent, quality services to citizens and stakeholders.

4.002 Scope

This policy applies to the Department of Transportation, including Operating Administrations (OA), incorporating both regulatory standards with which DOT is required to comply and best practices essential to providing a consistent, actionable EA.
DOT will issue additional EA policies and guidance as necessary. Each OA may issue additional policies and guidance, provided they comply with existing laws, regulations and DOT policies and procedures.

4.003 References

• Public Law 107-347, Dec. 17, 2002, The E-Government Act of 2002
• Public Law 107-347, Title III, Federal Information Security Management Act
• Public Law 104-106, February 10, 1996, Clinger-Cohen Act of 1996
• Public Law 103-62, January 5, 1993, Government Performance and Results Act of 1993
• Executive Office of the President, Federal EA Program Management Office (FEA PMO) Action Plan , March 2005, Enabling Citizen-Centered Electronic Government 2005-2006
• OMB Circular A-11, July 16, 2004, Preparation, Submission and Execution of the Budget
• OMB Circular A-130, November 28, 2000, Management of Federal Information Resources
• OMB FEA PMO, June 2004, FEA Reference Models
• Federal CIO Council, February 2001, A Practical Guide to Federal EA
• Federal CIO Council, September 1999, Federal EA Framework

4.004 Definitions

• Actionable refers to documentation and data useful to stakeholders in resource planning, impact and risk assessments, and operational decision-making.

• Architecture is the structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time. ¹

• Baseline Architecture represents the set of products that portray the existing current or “as-is” state of an enterprise, its business practices, and technical infrastructure.

• Enterprise is an organization or entity supporting a defined business scope and mission. An enterprise includes interdependent resources (people, organizations, and technology) that must coordinate their functions and share information in support of a common mission (or set of related missions). ²

• Enterprise Architecture is an information asset containing the analysis and documentation of an enterprise in its current, transitional and future states from an integrated strategic, business, and technology perspective, maintained and utilized as the primary asset for managing change within the enterprise.

• Federal EA Framework (FEAF) is a structured EA approach developed by the CIO Council for use across the Federal Government consisting of a pyramid of four sub-architectural levels from the top down including Business, Data, Application, and Technology; adapted for use by DOT to include a fifth level, Strategy, at the top of the pyramid.

• Federal Enterprise Architecture (FEA) consists of a set of interrelated “reference models” designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps and opportunities for collaboration within and across agencies. Collectively, the reference models comprise a framework for describing important elements of the FEA in a common and consistent way. Through the use of this common framework and vocabulary, IT portfolios can be better managed and leveraged across the federal government. There are five FEA reference models:
  
  - Business Reference Model (BRM)
  - Performance Reference Model (PRM)
  - Service Component Reference Model (SRM)
  - Technical Reference Model (TRM)
  - Data Reference Model (DRM)

• EA Reference Model (RM) is a document based on a standard taxonomy used to provide a common reference for identifying or characterizing departmental and agency architectures within the context of an overall FEA. This common reference is used for mapping IT investments to each of the five specific reference models below.

• EA Business Reference Model (BRM) is a function-driven framework to describe the Lines of Business and Sub-Functions performed by the Federal Government independent of the agencies that perform them. IT investments are mapped to the BRM to identify collaboration opportunities.

• EA Performance Reference Model (PRM) is a standardized performance measurement framework to characterize performance in a common manner where necessary. The PRM helps agencies produce enhanced performance information; improve the alignment and better articulate the contribution of inputs, such as technology, to outputs and outcomes; and identify improvement opportunities that span traditional organizational boundaries.

• EA Service Component Reference Model (SRM) is a common framework and vocabulary for characterizing the IT and business components that collectively comprise an IT investment. The SRM helps agencies rapidly assemble IT solutions through the sharing and re-use of business and IT components. A component is a self-contained process, service, or IT capability with pre-determined functionality that is made available for use through a business or technology interface.

• EA Technical Reference Model (TRM) is a foundation to describe the standards, specifications, and technologies supporting the delivery, exchange, and construction of business (or Service) components and E-Gov solutions. The TRM unifies existing agency TRMs and E-Gov guidance by providing a foundation to advance the re-use of technology and component services from a Government-wide perspective.

• EA Data Reference Model (DRM) is a framework to promote the common identification, use, and appropriate sharing of data/information across the federal government. It provides standards and guidelines to help agencies structure, categorize, exchange, and manage their data to improve the ability of Government to perform cross-agency information sharing.

• Federated refers to a grouping of entities organized together based on optimizing the common whole to deliver the greatest benefit, protection and economy to its constituent parts while empowering them to focus on the essential and unique services they must provide to achieve their mission, goals and objectives.

• Governance is a well-rationalized, institutionalized group of policies, processes and procedures based on functional roles and responsibilities that work together to enable the effective planning, decision-making, management, evaluation and oversight of activities and resources.

• Performance Gap is the basis for change that results from the difference in performance between the current state of an identified activity or capability and a proposed target state.

• Target Architecture represents the set of products that portray the future or “to-be” state of an enterprise, captured in the organization’s strategic thinking and plans for a specified point in time.

• Transition Plan captures the approach and sequence for closing a performance gap between the baseline and target architecture as documented within an organization’s EA.

• Waiver is a formal exception to approved processes and standards, including the enterprise Technical Reference Model and Standards with a set time limit. Waiver justification is in accordance with established criteria, presented in the form of a Request for Waiver, recommended or not by the Architecture Review Board for approval to and for final approval by the Investment Review Board in the CPIC Select phase. A review of compliance with waiver criteria are included in the CPIC Control phase, and evaluated by the ARB including a recommendation for final disposition to the Executive Steering Committee in the CPIC Evaluate phase.

4.005 Goals

The goals of the DOT Enterprise Architecture are to leverage a consistent discipline and common approach throughout the Department to manage strategic and tactical change by aligning inputs, outputs and outcomes in order to achieve its mission, goals and objectives.

• Align with Strategic Planning – Support DOT and OA missions and programs through aligning EAs with strategic planning to capture mission, functions and business foundation to promote enterprise-level planning and decision-making, thus transforming organizational strategic needs into a defined set of services resulting in improved citizen satisfaction.

• Improve Agency Performance – Provide comprehensive, transparent, consistent, repeatable, institutionalized, enterprise-wide processes to facilitate end-to-end, integrated governance to transform the top-down strategic needs and bottom-up system needs into an effective set of services reflecting the highest levels of performance through utilizing emerging, flexible technologies resulting in improved access to information and citizen satisfaction.

• Increase Inter- and Intra- Departmental Collaboration – Increase cross-agency and inter-governmental collaboration to facilitate improved utilization, cost savings and cost-avoidance through horizontal (crosscutting) and vertical (agency unique) integration of information resources, and improved services to Citizens and other stakeholders.

• Guide and Coordinate Departmental Investments – Provide guidance for planning, selecting, controlling and evaluating all investments. Use of EA will become an integral part of investment planning by providing core information required for effective solution analysis, improved IT investment accountability and cost containment.

• Reduce Redundancy and Overlap – Reduce the amount of redundancy and overlap to allow for the more efficient use of Departmental resources. The EA will show where redundancy and overlap exist and provide a basis for reducing both where practical. In turn, DOT will identify opportunities to reinvest those savings into mission-supporting endeavors.

• Optimize Data Collection and Management – Develop systems around a unified, enterprise-level data architecture to reduce redundant data, promote data sharing, improve data quality, and reduce the overall effort for data management.

• Increase Integration and Correlation – Provide a framework for ensuring integration and alignment of strategic planning, business processes and technology in support of the mission by capturing the details necessary for analysis and evaluation of impact, risk and alternatives. Additionally, EA provides a framework for increasing the collaboration between those areas and CPIC, Security, and Privacy by linking those functions under an integrated Departmental structure.

• Satisfy Legal and Regulatory Requirements – Satisfy legal and regulatory requirements for the Department to develop and maintain an EA imposed by the Clinger-Cohen Act, and OMB Circulars A-11 and A-130 Satisfying these requirements is an essential goal of the EA effort.

4.006 Policy

DOT and the OAs must comply with applicable laws, OMB requirements and other pertinent guidelines referenced within this policy in evolving and maintaining their EAs.

To achieve the purpose and goals of EA, the Department, under the authority of the Secretary, establishes this policy to ensure planning, portfolio management and governance of strategic change from a consistent enterprise perspective defined by the services it must deliver in order to achieve its mission, strategic goals and objectives.

The DOT EA is developed and maintained in accordance with the guidance provided by OMB and the Government Accountability Office (GAO) via the use of a Federated approach and consistent framework throughout the Department. DOT and the OAs should strive to achieve their core EA goals as measured by common assessments provided by external governing bodies.

DOT’s Federated EA consists of two unique views of the Department as an enterprise – the baseline and target architectures. DOT OAs should establish and maintain an EA that aligns with DOT’s strategic missions.

The Department’s EA model defines the architectural views that are comprised of the five Federal Enterprise Architecture Reference Model views (Business, Performance, Data, Service Component and Technical Reference Models) combined with a modified view of the architectural layers defined within the Federal EA Framework (Strategy, Business, Data, Application, and Technology) as described in the DOT EA Methodology.

This policy provides the highest level of the structure for DOT’s EA program, supplemented with enterprise guiding principles that provide the foundational basis for the enterprise governance structure, which details specifics about the management and approach of DOT’s EA program and associated requirements. The following sections depict and define the two subsidiary sections in detail.
In order to execute DOT EA development and use, this overarching policy provides for the basic governance structure of the enterprise that ensures integration of Strategic Planning, Enterprise Architecture and Capital Planning and Investment Control, organized via a common model as shown in the figure below:

DOT EA POLICY MODEL

Enterprise Guiding Principles

Enterprise guiding principles are the foundation of an EA. They provide the basis for EA program policy and guidance. Principles:

• Establish a baseline set of rules and behaviors for the enterprise
• “Affect the development, maintenance, and use of the Enterprise Architecture” ³
• Provide the foundation for governance and are translated into specific policies, processes and procedures; and
• Govern the implementation and maintenance of a current EA as the primary asset for managing enterprise change.

Enterprise Governance

DOT EA programs under the authority of this policy are formally governed to provide appropriate management control and accountability at either a Departmental or an OA level, or both. The intent is to provide a well-rationalized structure that supports timely and informed decision-making that takes into account risks, return on investment, performance, and makes the best use of management resources.

Strong, specific governance, through the establishment of repeatable processes, improves the quality of decision-making and reduces the amount of resources required to duplicate, re-do or react to unanticipated impacts or performance.

Within DOT’s EA program, governance is further divided into four management areas. Subsidiary documents including methodologies, charters, assessments, etc., are cataloged within the subsets of DOT’s governance. The four governance sub-classifications are:

• Program Management – Program Management includes the formal structure and approach of the EA program at the Department and Operating Administration level and includes topics such as processes, procedures, organizational structure, program integration, and delivery tools and techniques including the EA Repository and modeling tools throughout the Department.

• Development and Execution – Development and Execution includes the detailed timing, responsibilities, and processes for the capture of the artifacts of the Enterprise Architecture and the processes that govern that capture. Additionally, the “Execution” defines the processes and procedures for generating the EA outputs required for the Analysis defined and outlined below.

• Analysis and Reporting – Analysis includes the processes for extracting the details from the EA at the Department level and within the OAs and leveraging that information for decision-making throughout the Department. Reporting consists of both internal reporting of progress and completeness of the architecture development as well as the reporting of the feedback required by external entities on the progress of the EA. External analysis is captured via the assessments created by governing bodies such as OMB and GAO.

• External Guidance – External guidance is that published by governing bodies and organizations outside of the Department, including but not limited to OMB, GAO, FEA PMO, and the Federal CIO Council. These organizations provide additional policies, guidance, and procedures, which facilitate growth and maturity of the EA.

DOT Governing and Advisory Bodies

In support of the governance management areas detailed above, this policy establishes DOT enterprise governance consisting of governing and advisory bodies, based on functional roles and responsibilities, required to make assessments, recommendations and decisions within an enterprise context.

A charter exists for each enterprise level governing and advisory body, defining scope, membership, functional roles, responsibilities, detailed processes, and procedures that clearly outline interrelationships. It is critical that membership reflect active participation by both business and IT roles at all levels.

A high-level profile of each governing and advisory body follows. In order to express the interrelationships between DOT and OA responsibilities, the following descriptions reflect the roles associated with each body:

• DOT Level – Departmental enterprise view, crosscutting, enterprise and common operating environments; OA high-level summary reporting; variances with mitigation; requests for assistance
• OA Level – OA enterprise view; crosscutting and mission specific; high-level reporting; variances with mitigation

DOT Enterprise Governance

(Diagram shows flowchart of the items listed below - see Word doc for illustration)

Enterprise Governing Bodies – Decision-Making

Strategic Planning Board (SPB) - Prepares and maintains enterprise-wide strategic plan

• Defines clear strategic goals, objectives and associated metrics as a basis for business cases and measuring outcomes as a precursor to DOT and/or OA IT Strategic Plans
• Reviews Plans annually and update as necessary in the first quarter of the current fiscal year in preparation for the next budget preparation cycle
• Complies with GPRA maintaining a five-year strategic planning window, annual performance plan and reporting

Functional role and responsibility membership:

• DOT Level – Business, IT and Financial Strategists, Chief Architect
• OA Level – Business, IT and Financial Strategists, Chief Architect

Executive Steering Committee (ESC) - Ensures enterprise-wide leadership and oversight

• Approves and actively aligns with Enterprise Guiding Principles
• Sets agency strategic direction based on commitment of resources
• Executes oversight of DOT’s Common Operating Environment and Enterprise Operating Environment based upon standards and policies approved by the ESC
• Determines final disposition of waivers based on ARB recommendations in the CPIC Evaluate phase as an exception to the enterprise Technical Reference Model or Standards.
• Conducts periodic assessments of EA quality
• Provides resources to support DOT and OA EA programs to maintain EA artifacts, models and documentation sufficiently explicit to adequately: ensure FEA RM and business alignment, evaluate impact, maintain security/privacy, quality assurance, risk management, plan sequence/transition, mitigate risk, budget preparation and make informed strategic and tactical decisions
• Oversees annual independent verification and validation of the EAPMO

Functional role and responsibility membership:

• DOT Level – Chief Financial Officer, Chief Information Officer, Department Operating Administrators
• OA Level – Chief Financial Officer, Chief Information Officer, Line of Business Owners

Investment Review Board (IRB) - Actively participates in all phases of EA-CPIC integration (Select, Control, Evaluate) making funding decisions based on Architecture Review Board (ARB) recommendations, financial and business risks, benefit to the enterprise and other financial considerations, based on a defined process and published criteria.

• Select phase - Assesses risk, likelihood of success and make financial decisions about selection for funding including waiver approval
• Control phase - Reviews financial performance (earned value management), risk, other factors, and make strategic and tactical funding decisions to continue, modify or withdraw funding
• Evaluate phase - Makes final determination to complete funding against specific performance and contractual provisions

Functional role and responsibility membership:

• DOT Level – Deputy Secretary, Chief Financial Officer, Chief Information Officer, Chief Counsel, Senior Budget Official, Senior Procurement Official, Operating Administrators
• OA Level – Deputy Administrator, Chief Financial Officer, Chief Counsel, Senior Budget Officer, Senior Procurement Official, Line of Business Owners

Architecture Review Board (ARB) - Actively participates in all three phases of EA-CPIC integration (Select, Control, Evaluate) to ensure architectural alignment, security, impact evaluation, feasibility, compliance with standards, maintain quality, assess technical and business risk, based on a defined process and published criteria:

• Select phase - Assesses business alignment, business case/solution proposal, technical compliance, waiver requests, and return the project proposal to the sponsor for rework, or makes recommendations to the IRB
• Control phase - Evaluates continued alignment, technical compliance, reports of related CCB activity, performance and makes recommendations to the IRB
• Evaluate phase - Assesses program/project results, lessons learned and makes recommendations to the IRB for completion of funding and to the ESC for waiver disposition

Functional role and responsibility membership:

• DOT Level – Chief Technology Officer (where applicable), Chief Architect, DOT/OA Business & Technical Representatives, Security Officer
• OA Level – Chief Technology Officer (where applicable), Chief Architect, OA Business & Technical Representatives, Security Officer

Configuration (Change) Control Board (CCB) - Provides tactical oversight of planned or emergency changes to IT infrastructure (such changes would affect production operations within operations and maintenance activities, or development efforts rolling out new applications or technology into production) based on a defined process and published criteria.

• Receives documented submission of requests for change and forwards for assessments of impact by assigned subject matter experts on business, security, EA, and risk; elevates as appropriate
• Approves, returns for more information, or denies the request for change based on assessments
• Reviews documentation of change implementation, and approves or returns for rework of task and or documentation; completed documentation of the activity and the new baseline configuration is a mandatory part of the approved performance
• Conveys appropriate activity reports/documentation to EAPMO and ARB as required
• Routes related questions of funding to the CIO or IRB as appropriate for approval before granting CCB approval

Functional role and responsibility membership:

• DOT Level – Chief Architect, DOT/OA Business and Technical Representatives
• OA – Chief Architect, OA Business and Technical Representatives

Enterprise Advisory Bodies – Support and Guidance

DOT EA Program Management Office (DOT EA PMO) - Established to manage, monitor and control the development and maintenance of an actionable EA.

• Accountable to the ESC and through their executive support have access to all the skills and resources necessary to ensure that the EA remains the primary asset for managing change in the enterprise
• Operating administrations may establish a project office or a program management office.
• Consists of a Chief Architect, appointed by the Chief Information Officer, who may function also as the Program Manager
• Includes an Architecture Core Team consisting of consulting architects and subject matter experts who provide guidance and support the selection, control and evaluation of the investment portfolio that enables the enterprise to achieve its strategic goals and objectives

Functional role and responsibility membership:

• DOT Level – Chief Architect, Strategic Planner, Security Architect, Business Architect, Data/Information Architect, Application Architect, Technology/Infrastructure Architect, Quality Assurance Function, Risk Management Function, Senior Architecture Consultants, Technical Writer
• OA Level – Chief Architect, Strategic Planner, Security Architect, Business Architect, Data/Information Architect, Application Architect, Technology/Infrastructure Architect, Quality Assurance Function, Risk Management Function, Senior Architecture Consultants, Technical Writer

CIO Council - An advisory body made up of the DOT and OA Chief Information Officers to provide for an exchange of information and the formulation of recommendations to governance bodies.

EA Sub-Committee - An advisory body made up of the DOT and OA Chief Architects to provide for an exchange of information and the formulation of recommendations to governance bodies.

CPIC Sub-Committee - An advisory body made up of the DOT and OA Capital Planning Team members to provide for an exchange of information and the formulation of recommendations to governance bodies.

Security Sub-Committee - An advisory body made up of the DOT and OA Security Officials to provide for an exchange of information and the formulation of recommendations relating to Information Assurance and DOT Federated Security Architecture to governance bodies.

Working Groups – Formed upon the direction of appropriate executive authority for a wide variety of purposes generally including a specific area of study, analysis for developing recommendations to governance bodies or sub-committees.

4.007 Responsibilities

Responsibilities for implementing DOT’s EA policies lie with the following officials and may be delegated as appropriate, provided those delegated have the authority and experience to fulfill the responsibilities as intended:

Departmental

Agency Heads – Provide overall leadership and strategic direction for the Department, which is captured within the Enterprise Architecture. Provides sponsorship to the EA program via visible support and funding for the program, as its purpose is to ensure that the Department is aligned with the direction communicated by the Secretary through the DOT Strategic Plan and other directives.

Chief Information Officer – The CIO provides overall leadership and guidance to the DOT Enterprise Architecture Program via the Executive Steering Committee. As the person responsible for the management of information throughout the Department, provides leadership via the appointment of a Chief Architect to manage DOT’s EA Program and coordinates with the Administrators of the OAs to communicate the vision and requirements of the EA as it applies to the goals of the Department.

Chief Architect –Appointed by the Departmental CIO and provides day-to-day leadership and guidance of the EA Program. Serves as Co-Chair of the EA Subcommittee and the ARB. In addition to managing the EA Program Management Office, responsibilities include maintaining the relationship between the Department’s EA and generating responses to inquiries and requests from external bodies such as OMB, GAO, etc. Coordinates with other architects, internal and external to the Department, to ensure consistency and compliance with policy and guidance.

DOT Operating Administrations

Administrator – Provides sponsorship for their EA programs via coordination with the Departmental CIO and the Executive Steering Committee. Chart the course for the Departmental EA by providing the vision for their organization.

Chief Information Officer – Provides sponsorship for their EA program at the OA level and communicates with the Departmental Chief Architect on matters involving the creation and maintenance of the EA program within the Operating Administration. The CIOs appoint Chief Architects within each OA. One OA CIO is appointed as co-chair of the EA Subcommittee along with the Departmental Chief Architect.

Chief Architect – Role functions in conjunction with Departmental counterpart. As the face of the EA program on the OA level, the Chief Architect organizes and manages the OA’s EA Program as well as serves on the EA Subcommittee. Provide day-to-day guidance, capture, and management of the EA artifacts and develop work plans and schedules for the delivery of artifacts and results to the stakeholders.

DOT and OA Common Roles

Architects (Functional and Technical) – Architects serve as consultants to the organization in managing the collection and organization of EA artifacts throughout their scope. At the DOT and OA levels, they collaborate and provide guidance and responses to those seeking information from the EA and assist in developing guidance.

Technical Specialists – As appointed knowledge experts, these specialists serve on their respective Commodity Councils to provide review and guidance of suggested technology improvements within the Department or a specific OA. They review the business needs for the new solution against the current operating environment within the Department and provide recommendations on solutions aligned with the overall goals, mission and environment in place. Their work is fed to the Architecture Review Board for final review and decision-making.

4.008 Summary

The objective of EA is to utilize the mission, goals, objectives and strategic outcomes of the Department’s business as the primary asset to drive the management of change in the enterprise that enables achievement of DOT’s Strategic Goals. DOT EA PMO provides enterprise-wide support, working with OA EA functions, to enable compliance with this policy through consultation, support for budget preparations integrating EA, development and maintenance of internal artifacts, high-level models, workshops, and clarification of OMB requirements. The ability of the DOT EA PMO to provide support requires active participation by the stakeholders across the Department. Together, DOT’s EA Program will continue to be refined and mature to improve its ability to successfully manage change and achieve strategic outcomes.

To provide additional assistance in achieving desired outcomes, the following resource will provide additional details regarding the framework behind the Department’s EA Program: Department of Transportation Strategic Plan

¹ ibid

² “A Practical Guide to Federal Enterprise Architecture”, CIO Council, February 2001

³ “A Practical Guide to Federal Enterprise Architecture”, CIO Council, February 2001.

Updated January 2006