In the common approach, there is one enterprise roadmap for the overall enterprise, and one transition plan / two views for each architecture project:
- Enterprise Roadmap
- Transition Plan
- Current Views
- Future Views
The roadmap, plan and views provide a picture of the architecture in terms of what exists currently, what is planned for the future, and what the transition paths will be in all six domains.
Enterprise Roadmap
The Enterprise Roadmap (Roadmap) documents and maps the organization’s strategic goals to business services, integrating technology solutions across all of the Agency’s lines of business. The Roadmap discusses the overall EA and identifies performance gaps, resource requirements, planned solutions, transition plans, and a summary of the current and future architecture. The Roadmap also describes the EA governance process, the implementation methodology, and the documentation framework. The Roadmap should be a living document that is updated at regular intervals (at least annually) to provide clear version control for changes in current and future views of Agency changes at all levels of scope. The Roadmap should be archived in the on-line EA repository to support easy access to the information and to promote the linkage of EA to other management and technology processes. To support the annual Federal Budget process, each Federal Agency will submit an updated Enterprise Roadmap to OMB’s Office of E-Government and IT on or before April 1st 10 so that it can serve as an authoritative reference for IT portfolio reviews using the PortfolioStat methods/tools and for program-level analysis and planning.
EA Program Management Section
EA as a management program supports policy development, decision-making, and the effective/efficient use of resources. This section of the Roadmap documents the activities associated with administering EA as an ongoing program.
Governance and Use: This section of the Roadmap documents the way that policy and decision-making will occur within the EA program. It is also where the underlying principles of the EA program are articulated. EA governance is perhaps best described through a narrative that provides EA program policy and an accompanying flow chart that shows how and when decisions are made on EA issues such as IT investment proposals, project reviews, document approvals, and standards adoption/waivers. Examples of EA use include: (1) the degree to which the architecture promotes the open sharing of information, (2) level of stakeholder participation, (3) promoting the recognition that IT is normally a means and not an end in itself, (4) an emphasis on using commercial products that are based on open standards, (5) identification of areas of waste and duplication, and (6) a recognition that EA adds value for planning, decision-making, and communication.
Support for Strategy and Business: This section of the Roadmap emphasizes that one of the main purposes of the EA program is to support and improve the enterprise’s strategic and business planning, as well as to identify performance gaps that architectural designs can help close. By showing how resources are being currently used, and identifying useful new processes and technologies at each level of the framework, improvements in performance can occur that are captured in future EA views. For EA to be recognized as part of Agency’s strategic planning process, executives and managers must see the value of the EA program in promoting outcomes that matter to them.
EA Roles and Responsibilities: This section of the Roadmap documents roles and responsibilities of EA stakeholders, an example of which is provided in Table H:
Agency Head
- Role: Executive Sponsor
- Responsibilities: Champion the EA program as a valuable methodology and authoritative reference. Approve resources. Assist in resolving high-level architecture issues.
Chief Information Officer (CIO)
- Role: Executive Leadership and Decision-Making
- Responsibilities: Work with the Agency Head, CXOs, business unit managers, and program managers to gain/maintain support for the EA program. Provide guidance and resources to the Chief Architect. Lead the resolution of high-level EA issues. Integrate EA with other areas of business and technology governance.
Other CXOs
- Role: Executive Support
- Responsibilities: Participate in EA Program governance. Promote the EA as an authoritative reference. Use EA information and products in planning / decision-making.
Chief Architect
- Role: Program Management
- Responsibilities: Manage the EA Program. Identify EA methods and standards. Coordinate architecture projects. Lead the configuration management process.
Enterprise Architect
- Role: Architecture Integration
- Responsibilities: In coordination with the Chief Architect, works with executives, managers, staff to identify requirements and solutions in all domains and levels of scope.
Solution Architect
- Role: Problem Solving
- Responsibilities: In coordination with the Chief Architect, and/or an Enterprise Architect, works collaboratively with stakeholders to identify solutions for business and technology requirements. Does analysis/documentation.
Strategic Planner
- Role: Direction and Prioritization
- Responsibilities: In coordination with Agency leadership and other stakeholders, including the Chief Architect, works collaboratively to update strategic plans and priority goals, and identifies linkages to program activities.
Business Architect
- Role: Process Analysis and Design
- Responsibilities: In coordination with the Chief Architect and other architects, works collaboratively with stakeholders to create, improve, or re-engineer business processes and identify enabling IT. Does analysis/documentation.
Data Architect
- Role: Data Analysis and Design
- Responsibilities: In coordination with the Chief Architect and other architects, works collaboratively with stakeholders to provide technical analysis and design for data-level solution architecture projects and data-related business and technology requirements. Ensures that data solutions meet integration, interoperability, privacy requirements. Does analysis/documentation.
Systems Architect
- Role: Systems Analysis and Design
- Responsibilities: In coordination with the Chief Architect and other architects, works collaboratively with stakeholders to provide technical analysis and design support for systems-level architecture projects. Ensures that IT systems meet integration and interoperability requirements. Does analysis/documentation.
Infrastructure Architect
- Role: Network Analysis and Design
- Responsibilities: In coordination with the Chief Architect and other architects, works collaboratively with stakeholders to provide technical analysis and design support for infrastructure-level architecture projects. Ensures that IT network and data center hosting solutions meet integration and interoperability requirements. Does analysis/documentation.
Security Architect
- Role: Security and Privacy Analysis and Design
- Responsibilities: In coordination with the Chief Architect and other architects, works collaboratively with stakeholders to provide technical analysis and design for security-related architecture projects and security or privacy-related business and technology requirements. Ensures that security and privacy solutions support risk mitigation plans. Does analysis/documentation.
Line of Business Managers
- Role: Requirements Identification
- Responsibilities: Supports EA program and ensures that program managers participate in architecture projects by identifying business and IT requirements for program activities.
Program Managers
- Role: Requirements Identification
- Responsibilities: Participates in architecture projects and configuration management activities. Identifies business and IT requirements for program activities.
Capital Planner
- Role: Investment Analysis
- Responsibilities: Uses EA information to support the development of alternatives analyses and to make investment decisions.
Functional Expert
- Role: Subject Matter Expertise
- Responsibilities: Participates in architecture projects to provide subject matter expertise in a functional requirement area.
End-User Representative
- Role: Requirements Identification
- Participates in architecture projects. Identifies business and IT requirements for systems/applications.
Tool Expert
- Role: Documentation Support
- Responsibilities:: Documentation support and maintenance of EA tools. Supports architecture projects and the repository.
Repository Manager
- Role: Repository Support
- Responsibilities:: Maintenance of EA website and repository, associated content, and links to other websites as needed.
Table H. Example Roles and Responsibilities
EA Program Budget: This section of the Roadmap documents the budget for the EA program and projects by fiscal year and over the total lifecycle, so that the total cost of ownership (TCO) is identified. While EA program is ongoing, a lifecycle period of five years is recommended to be able to calculate TCO. In general, the costs to be included are those for EA program start-up and operation, salaries and work facilities for the EA team, the initial documentation of the EA, periodic updates to the EA, annual updates to the Roadmap, EA tool purchase and support, and EA repository development and maintenance. The initial estimate of these costs represents the “baseline” for EA program funding. Spending during the lifecycle should be tracked against this baseline to promote effective management of the EA program. If changes in the scope of the EA program occur, a corresponding change in the funding baseline should also be made.
EA Program Performance Measures: This section of the Roadmap documents how the effectiveness and efficiency of the EA program will be measured. As was described in previous Chapters, there are two types of measures: outcome and output. Outcome measures identify progress being made toward some new end-state, such as better EA component integration, increased application end-user satisfaction, or more effective IT investment decision-making. Output measures provide data on activities and things, such as how many databases exist, how many e-mail are sent each day, or how closely an IT project is meeting baseline estimates for cost, schedule, and performance. Outcome measures often have both quantitative and qualitative elements to them, while output measures are usually quantitative in nature. While output measures are important for indicating progress in an initiative area, it is the attainment of outcomes that correlate to goal attainment, which is the most important thing to an enterprise. It is important to be able to measure the attainment of outcomes, so that the positive effects (added value) of the EA program can be identified.
Summary of Current Architecture
One of the purposes of the Enterprise Modernization Roadmap is to show an overview of the linkage between current services and resources in each area of the EA. In this way, the present role of IT within the enterprise is better understood and can be further analyzed from either a top-down, or bottom-up perspective. The objective of this part of the Roadmap is not to duplicate the extensive documentation that is available in the repository, but to provide an integrated view of current business activities and supporting technology solutions. This information sets the
stage for the next section of the Roadmap, which discusses future changes in the architecture to achieve improved performance and efficiency.
Strategic Goals and Initiatives: This section of the Roadmap identifies how the EA program and specific resources support the attainment of the Agency’s strategic goals and initiatives. This section builds upon comments provided in the Strategic Plan, and is included to more clearly show which business activities and IT resources are involved in each strategic goal area. A general description is then provided of how IT components support each goal and initiative at the strategic level of the EA.
Business Services and Information Flows: This section of the Roadmap identifies and emphasizes the role that EA plays in supporting business process analysis and improvement, as well as identifying and optimizing information flows within and between these processes. It also re-affirms the EA principle that IT resources are a means to enable effective business services, and should not be procured unless there is a strong business case that supports investment. Within this section, the organization’s main LOBs should be listed along with the key business services and associated information flows in each business unit and program area. A general description is then provided of how IT resources support mission and support services process at the business level of the EA. Selected models of information flows and data structure may also provided.
Applications: This section of the Roadmap identifies how current EA artifacts at the applications level of the EA support the information flows that are required for program activities throughout the Agency. The discussion should summarize how well this “suite” of commercial and custom developed IT systems and front/back office services provide the functionality the enterprise needs for mission and support. This can range from large scale, multi-module ERP solutions, to commercial applications and databases, to small custom-developed websites. Comments should focus on degree of integration, potential scalability, user satisfaction, and any reliance on proprietary solutions or outsourced services (e.g., cloud hosting services).
Infrastructure: This section of the Roadmap discusses the voice, data, video, and mobile hosting environments that make up the infrastructure level of the EA. The discussion should focus on how well these internal and external networks, systems, and cable plants integrate to create a “seamless” infrastructure. Comment should also be made on convergence activities to consolidate the infrastructure where there is duplication in voice, data, video, and mobile solutions, as well as other commodity IT services at this level of the architecture (e.g., email, collaboration, help desk, asset management).
Security and Privacy. This section of the Roadmap discusses the general approach to IT security and data privacy at all levels of the EA framework. IT security should be part of any strategic goal or initiative that depends on accurate, properly authenticated information. High-level descriptions are provided on how security is built into business services and the control of information flows, as well as the design and operation of systems, services, and networks. Specific IT security information should not be part of the Roadmap because it could reveal vulnerabilities. This type of information should be documented in a separate IT Security Plan that only certain people in the Agency have access to.
Standards. The standards section of the Roadmap documents the business standards for mission and support services as well the technical standards for systems, applications and infrastructure, including voice, data, video, mobile and IT security solutions that are used during architecture development. The standards section can also provide a list of preferred vendors and products that meet the technical standards that an Agency adopts. EA standards are a key element of the configuration management (CM) process and come from international, national, local, government, industry, and enterprise sources. Selected standards should include standards for voice, data, and video technologies from leading standards bodies throughout the world, including the Institute of Electrical and Electronics Engineers (IEEE), the National Institute of Science and Technology (NIST), the International Enterprise for Standardization (ISO), the European Committee on Standardization (CEN), the Object Management Group (OMG), and the Federal law and guidance on EA.
Workforce Requirements. This section of the Roadmap describes required changes to knowledge and skill requirements. People are often the most valuable resource that any organization has, and human capital management plans should detail training requirements and position description changes that are needed to support changes in mission and support areas.
Summary of Future Architecture
The future architecture section of the Enterprise Modernization Roadmap should be based on a number of alternative operating scenarios, in recognition of the fact that no Agency can predict what the particular combination of internal and external conditions will be as time goes on, especially several years into the future.
Future Operating Scenarios. In this section, the future operating scenarios are presented along with a narrative description of the purpose of the scenarios and the spectrum of operating environments that the scenarios respond to. For example, three scenarios are presented with an opening narrative that explains that they represent:
- Scenario 1: Continuing with the status quo.
- Scenario 2: An expansion/update strategy when resources are available.
- Scenario 3: A defensive strategy in the face of decreasing budgets.
Each scenario has planning assumptions built into it, that highlight changes that will need to occur in processes, people, and technology. In this section, a description is provided of the selected course of action for the Agency.
Planning Assumptions. The planning assumptions from the scenarios are further discussed in terms of what they mean to the priorities of the Agency as it implements the future EA. The assumptions identify new capabilities and resources that will be needed if the Agency is to be successful in each scenario. This section then focuses on the selected scenario and the planning assumptions that will underlie that course of action. Continuing the example from above, if Scenario 2 is being pursued, then several new shared services and related systems may need to be built or subscribed to. The planning assumptions that were identified in Scenario 2 become the guideposts for decisions about how to change the current EA, which needs to be described.
Updating Current and Future Views. Documentation of planned changes in processes and resources is what creates the future views of the EA at all levels of the framework. Using the EA as an example, these updates should be accomplished in a “top-down” manner, to preserve the emphasis on strategy and business, and to maintain the logic of the documentation’s relationships. Therefore, these updates would begin with the organization’s strategic goals and initiatives.
Changes to the Agency’s Strategic Plan and priority goals are made periodically or in response to a significant new internal or external business or technology drivers. Most strategic plans are intended to last several years, with associated goals, initiatives, and measures changing very little. Priority goals, initiatives, and measures should be considered as exchangeable resources. This means that a goal or measure can be added, dropped, or modified without nullifying the entire strategic plan.
A similar approach is used to review and update the Agency’s business services at the second level of the EA. It is important to ensure that the current views of business services are complete and can show how they support the accomplishment of current strategic goals. The changes in mission or support services then can be made considering any changes in strategic goals, initiatives, and measures that may be planned and documented at the top level of the EA. Also, documentation at the business level of the EA should show future planning for more effective, cost-efficient, and technically integrated processes.
Documenting changes to the flow of information within and between mission and support services (and new data standards) will enable EA planners to select shared services at these two lowest levels of the EA that best support the information flows and data standards. A focal point for the discussion in this section of the Roadmap is to identify any current performance gaps that exist at the higher levels of the EA and map them to current EA components and products. The future view of the applications level of the EA should show which systems or services will be changing and in what timeframe via that is developed as part of each architecture project.
At the infrastructure level of the EA, future changes will reflect systems and shared services that will provide a more robust, reliable, secure voice, data, and video backbone transport capability. Interoperability, cost-effectiveness and open standards are additional factors to be considered.
Modernization: The modernization section of the Roadmap summarized the Transition Plans from the various architecture projects. This section documents the tasks, milestones, and timeframe for implementing new systems and services. Large and mid-size Agencies often have many new development, upgrade, retirement, or migration projects underway at any given time and these require coordination to establish the optimal sequencing of activities. Sometimes there are dependencies between projects that also require proper sequencing. For example, an improvement to the capacity of the data infrastructure may be required before additional systems and/or databases can be effectively hosted so that maximum performance can be attained. Another example is the consolidation of IT resources such as systems, applications, and databases to improve both performance and cost effectiveness.
Configuration Management: The Configuration Management (CM) section of the Roadmap serves to support the sub-process by which changes to the EA are managed and standards are applied. Changes to the EA include the addition, upgrade, retirement of applications, systems, and services. CM ensures that (1) a standardized process is used in reviewing proposed changes, (2) technical standards for voice, data, and video are followed or waived, (3) there is a documented waiver process, (4) waivers have specific time limits, so that EA standards are eventually realized, (5) there is enforcement for EA documentation version control. The CM process should be overseen by the Chief Architect, and be supported by a working group that includes stakeholders from all EA domains and business units/programs throughout the organization.
IT Asset Inventory
The Enterprise Roadmap will include an inventory of all of the agency’s IT applications, systems and services, using the definitions of these resources that are provided in this document, OMB Circulars A-11 and A-130, as well as OMB Memoranda 11-29 and 12-10.
Content