FEA Practice Guidance Nov 2007

“Value to the Mission”
FEA Practice Guidance
Federal Enterprise Architecture Program

Management Office, OMB
November 2007
Table of Contents
Section 1: Overview ..............................................................................................1-1
About the FEA Practice Guidance ......................................................................................... 1-1
Contact Information................................................................................................................ 1-1
Delivering Mission Value........................................................................................................ 1-2
Principles................................................................................................................................ 1-3
Performance Improvement Lifecycle ..................................................................................... 1-3
Architecture Levels................................................................................................................. 1-4
Section 2: Introducing Segment Architecture ....................................................2-1

Business Outcomes ............................................................................................................... 2-2
Applying Segment Architecture.............................................................................................. 2-2
Stakeholders .......................................................................................................................... 2-5
Prerequisites and Success Factors ....................................................................................... 2-6
Segment Architecture Concepts ............................................................................................ 2-8
Segment Architecture Content ........................................................................................ 2-8
Segment Architecture Development................................................................................ 2-9
Segment Identification and Integration ................................................................................ 2-10
Initiating Segment Architecture ............................................................................................ 2-13
Step 1: Define and prioritize business and information management needs, and
architectural change drivers. ............................................................................ 2-13
Step 2: Define, review, and prioritize candidate opportunities to improve agency
performance ..................................................................................................... 2-14
Step 3: Identify candidate segment(s)........................................................................... 2-14
Step 4: Select a segment and identified resources needed to develop segment
architecture....................................................................................................... 2-14
Step 5: Establish segment architecture IPT .................................................................. 2-15
Section 3: Developing Segment Architecture.....................................................3-1

Step-by-Step Guidance.......................................................................................................... 3-1
Step 1: Architectural Analysis.......................................................................................... 3-3
Step 2: Architectural Definition ........................................................................................ 3-5
Step 3: Investment and Funding Strategy ....................................................................... 3-6
Step 4: Program Management Plan and Execute Projects............................................. 3-8
Segment Architecture Maintenance ................................................................................ 3-9
Section 4: EA Transition Strategy........................................................................4-1

Transition Strategy Concepts................................................................................................. 4-1
Transition Strategy in Enterprise Architecture................................................................. 4-1
Transition Strategy in the Performance Improvement Lifecycle...................................... 4-1
Developing the Transition Strategy........................................................................................ 4-2
Step 0: Establish Baseline and Target Architectures ...................................................... 4-3
Step 1: Perform Redundancy and Gap Analyses............................................................ 4-4
Step 2: Refine and Prioritize Architecture Segments ...................................................... 4-4
Step 3: Lay out the Enterprise Sequencing Plan............................................................. 4-5
Step 4: Develop Segment Architectures ......................................................................... 4-8
Step 5: Define Programs and Projects ............................................................................ 4-8
Using the Transition Strategy................................................................................................. 4-9
Linkage to the Investment Portfolio ................................................................................. 4-9
Performance Management ............................................................................................ 4-10
Annual OMB EA Assessment........................................................................................ 4-10
November 2007 i
Quarterly OMB EA Progress Reports............................................................................ 4-10

Program Management................................................................................................... 4-10
Government-wide Collaboration and Reuse ................................................................. 4-11
EA Transition Strategy Content ........................................................................................... 4-11
Section 5: Measuring EA Program Value ............................................................5-1

EA Value Measurement: Overview ................................................................................. 5-1
EA Value Measurement: Objectives................................................................................ 5-2
EA Program Value Concepts ................................................................................................. 5-2
EA Value Measurement as Part of the Performance Improvement Lifecycle ................. 5-2
Types of EA Value Indicators .......................................................................................... 5-4
Roles and Responsibilities .............................................................................................. 5-5
Measuring EA Program Value ............................................................................................... 5-5
Step 1: Define Value Measurement Areas ...................................................................... 5-6
Step 2: Identify Measurement Data Sources................................................................... 5-8
Step 3: Execute Value Measurement.............................................................................. 5-9
Using EA Program Value Measures ...................................................................................... 5-9
Approach: Continuous Improvement............................................................................... 5-9
Answering EA value questions ...................................................................................... 5-10
Sample Survey Elements..................................................................................................... 5-11
About the Respondent:.................................................................................................. 5-13
Overall Satisfaction:....................................................................................................... 5-13
Performance Improvement: ........................................................................................... 5-14
Appendix A: Key Terms....................................................................................... A-1
Appendix B: Reference Information ................................................................... B-1
November 2007 ii
FEA Practice Guidance – Overview
Section 1: Overview
About the FEA Practice Guidance
The Federal Enterprise Architecture (FEA) Practice Guidance describes important
concepts architects can use with stakeholders to deliver value to the business and
improve results in agency mission areas. The guidance provides overviews of
architecture concepts, descriptions of the content included in architecture work
products, and direction on developing and using architecture.
The FEA Practice Guidance is not meant to be prescriptive, but to offer concepts to be
applied using a variety of architectural frameworks and methodologies. The guidance
does not cover enterprise architecture (EA) development and maintenance since there
is already a broad body of knowledge on these topics.
There are four main sections of the FEA Practice Guidance:

• Section 1: Overview - Provides a high-level overview of EA concepts and
principles.
• Section 2: Introducing Segment Architecture - Describes segment
architecture concepts, the content included in segment architecture, and how to
use segment architecture.
• Section 3: Developing Segment Architecture - Provides guidance on how to
develop segment architecture, when one should be developed, and who should
participate in its development.
• Section 4: Enterprise Architecture Transition Strategy - Describes what is
included in an EA transition strategy and provides guidance on developing and
using an EA transition strategy.
• Section 5: Measuring EA Program Value - Describes a continuous, customer-
focused process relying on feedback from EA stakeholders and other value
measures to increase the quality and effectiveness of EA products and services
to support business decisions.
For additional information, appendices are also included:

• Appendix A: Key Terms - Defines EA terms and concepts used in the FEA
Practice Guidance.
• Appendix B: Reference Information - Additional information about the
concepts described in the FEA Practice Guidance.
Contact Information
For more information about the FEA or this guidance, go to http://www.egov.gov or send
an e-mail to fea@omb.eop.gov.
November 2007 1-1

Delivering Mission Value

All agencies seek to improve their mission performance. Enterprise architecture is a
management practice to maximize the contribution of an agency’s resources, IT
investments, and system development activities to achieve its performance goals.
Architecture describes clear relationships from strategic goals and objectives through
investments to measurable performance improvements for the entire enterprise or a
portion (or segment) of the enterprise.
Enterprise architecture is one of several practice areas that must be executed
effectively to achieve improvements in agency mission performance and other
measurement areas. EA helps to organize and clarify the relationships between agency
strategic goals, investments, business solutions and measurable performance
improvements - but, it is just one link in a chain of integrated practice areas. To achieve
target performance improvements the EA practice must be strong and fully integrated
with other practice areas including strategic planning, capital planning and investment
control (CPIC), and program and project management.
EA practice integration means verifying the impact of enterprise architecture on
measurable agency performance improvements. This is difficult. Two primary reasons
exist: first, there are many links in the chain of integrated practice areas to generate
performance improvements; and second, verifying direct relationships between an EA
practice and actual agency performance improvements often requires a long period of
time. To evaluate the impact of EA products and services, effective EA practice areas
measure the value of architectural work products and management processes. This
extends to business decisions across all integrated practice areas, monitoring
stakeholder feedback and other value indicators to continuously improve the quality of
EA products and services to enhance decisions and support business results.
This guidance helps architects to develop and use enterprise architecture to deliver
value by:
• Describing the current and future state of the agency and its segments;
• Defining the desired results for an agency and priority segments;
• Determining what resources are used to achieve measurable performance
improvements for an agency’s core mission areas and common or shared
services;
• Leveraging business and information management resources across the agency;
• Developing a transition strategy to achieve strategic goals and objectives and
target performance improvements; and
• Measuring the value of EA products and services to inform decisions in other
practice areas and support business results.
November 2007 1-2

SBA
Treasury
Figure 1-1 illustrates the Defense
es
EPA
i
nc
Interior
relationship of segments across
e
Justice
Ag
DHS
multiple agencies. A single Energy
HHS
agency contains both core
Community and
Social Services
Development
Management
Education
mission area segments and
Resources
Resources
Homeland
Economic
Financial
Security
Natural
Human
Health
business service segments.
Enterprise services are those
cross-cutting services spanning Mapping / Geospatial / Elevation / GPS
Enterprise
Services
multiple segments. Segments Security Management
can be leveraged within an Records Management
agency, across several agencies,
or the entire federal government.
Business
Services Core Mission Area
Figure 1-1: Segments and Services

Principles
Business-led architecture is more successful in meeting strategic goals, responding to
changing mission needs, and serving citizens’ expectations than technology- or budget-
driven architecture.
This principle encourages agency architects to proactively collaborate with business
stakeholders to develop architecture work products. Architects must understand the
current state of the business and where the business stakeholders would like to make
improvements. With this shared understanding, architects and business stakeholders
can work together to develop the architecture work products supporting better
investment and implementation decision-making.
Agencies are expected to architect first, and then use the architecture to guide and
inform information technology (IT) investment planning and implementation (program
and project management). This principle recognizes the time required to capture
business needs, define higher performance levels and develop architecture sufficient to
drive investment decisions. This also recognizes the time required to reconcile how
much of the business needs will be met by individual business solutions or enterprise
(agency-wide) investments.
For more information on federal architectural principles, refer to the Architectural
Principles for the U.S. Government located at www.egov.gov.
Performance Improvement Lifecycle

Results-oriented architecture is developed within the context of the Performance
Improvement Lifecycle broken down into three-phases: “Architect”, “Invest” and
“Implement” (Figure 1-2). Each lifecycle phase is comprised of tightly integrated
processes which combine to transform the agency’s top-down strategic goals and
bottom-up system needs into a logical series of work products designed to help the
agency achieve strategic results. Through practice area integration, the Performance
November 2007 1-3

Improvement Lifecycle provides the foundation for sound IT management practices,

end-to-end governance of IT investments, and the alignment of IT investments with an
agency’s strategic goals so an agency can achieve its desired mission outcomes and
business results.
Figure 1-2: Performance Improvement Lifecycle

Table 1-1 summarizes the processes included in each phase of the Performance
Improvement Lifecycle, as well as the processes used to transition from one phase of
the lifecycle to the next.
Phase Processes
• Develop and maintain EA as the shared view of the current and future state of
the agency.
Architect
• Define and prioritize segments as part of the EA transition strategy that
defines the sequencing of individual segments.
• Develop segment architecture to provide a bridge between the enterprise
vision (EA and EA transition strategy) and the investment in and
implementation of individual business and information management solutions.
• Define the implementation and funding strategy for individual solutions
Invest identified in the EA transition strategy and described in the segment
architecture.
• Create the program management plan to implement the individual solutions
identified in the implementation and funding strategy.
• Execute projects according to the program management plans.

Implement • Measure performance to determine how well the implemented solutions
achieve the desired results and mission outcomes and provide feedback into
the enterprise and segment architecture development processes.
Table 1-1: Performance Improvement Lifecycle Processes

Agency Chief Architects, and the EA practice as a whole, must provide valuable,
results-driven information at varying levels of detail to support each link in the
Performance Improvement Lifecycle.
Architecture Levels
Enterprise, segment, and solution architecture provide different business perspectives
by varying the level of detail and addressing related but distinct concerns. Just as
enterprises are themselves hierarchically organized, so are the different views provided
by each type of architecture. Figure 1-3 illustrates the relationships between enterprise
architecture, segment architecture and solution architecture.
November 2007 1-4

Figure 1-3: Architectural Levels and Attributes
By definition, EA is fundamentally concerned with identifying common or shared assets

– whether they are strategies, business processes, investments, data, systems or
technologies. EA is driven by strategy, it helps an agency identify whether its resources
are properly aligned to the agency mission and strategic goals and objectives. From an
investment perspective, EA is used to drive decisions about the IT investment portfolio
as a whole. Consequently, the primary stakeholders of the EA are the senior managers
and executives tasked with ensuring the agency fulfills its mission as effectively and
efficiently as possible.
By contrast, segment architecture defines a simple roadmap for a core mission area,
business service or enterprise service. Segment architecture is driven by business
management and delivers products that improve the delivery of services to citizens and
agency staff. From an investment perspective, segment architecture drives decisions
for a business case or group of business cases supporting a core mission area or
common or shared service. The primary stakeholders for segment architecture are
business owners and managers.
Segment architecture is related to EA through three principles: structure, reuse and
alignment. First, segment architecture inherits the framework used by the EA, although
it may be extended and specialized to meet the specific needs of a core mission area or
common or shared service. Second, segment architecture reuses important assets
defined at the enterprise level including: data; common business processes and
investments; and applications and technologies. Third, segment architecture aligns with
elements defined at the enterprise level, such as business strategies, mandates,
standards and performance goals.
Solution architecture defines agency IT assets such as applications or components
used to automate and improve individual agency business functions. The scope of a
solution architecture is typically limited to a single project and is used to implement all or
part of a system or business solution. The primary stakeholders for solution
architecture are system users and developers.
November 2007 1-5

Solution architecture is commonly related to segment architecture and enterprise

architecture through definitions and constraints. For example, segment architecture
provides definitions of data or service interfaces used within a core mission area or
service, which are accessed by individual solutions. Equally, a solution may be
constrained to specific technologies and standards that are defined at the enterprise
level.
November 2007 1-6

FEA Practice Guidance – Introducing Segment Architecture
Section 2: Introducing Segment Architecture

This section provides introductory guidance to
Architecture Principles for the U.S.
develop and use segment architecture for core Government (August 2007) states core
mission areas and common or shared services mission needs are the primary drivers for
defined by the agency EA and EA transition architecture development. This principle
strategy. Refer to Section 4 for information on reflects a rationale business-led
EA transition strategy. architecture is more successful in
meeting strategic goals, and
Segment architecture development is a scalable recommends agency-level architects
and repeatable process for architects to engage collaborate with business and program
business stakeholders and deliver value to leaders to develop architecture work
business areas. This process helps to establish products to enhance strategic decision-
making and guide capital planning.
clear relationships between strategic goals,
detailed business and information management
requirements, and measurable performance improvements.
Information and guidance are provided for the following topic areas:
• Business Outcomes: Identifies the characteristics of fully developed segment
architecture and describes important business outcomes.
• Applying Segment Architecture: Describes common uses for segment
architecture across each phase of the Performance Improvement Lifecycle –
“Architect”, “Invest” and ”Implement”. Describes agency-level and government-
wide benefits resulting from segment architecture development and
implementation.
• Stakeholders: Outlines an engagement model for segment architecture
development by defining Integrated Program Team (IPT) members and their role
in the segment architecture development process.
• Prerequisites and Success Factors: Describes lifecycle processes and
elements contributing to the success of segment architecture development and
implementation.
• Segment Architecture Concepts: Provides a definition and overview of
segments and segment architecture, including a description of segment
architecture work products and the segment architecture development process.
• Segment Identification and Integration: Describes the process to define
enterprise segments and the relationship to EA and the EA transition strategy.
Outlines segment types and the relationship between individual segment types.
• Initiating Segment Architecture: Describes the series of steps architects can
use to identify segments and initiate segment architecture development.
November 2007 2-1

Business Outcomes
Segment architecture development is a collaborative process forming a bridge between
enterprise-level planning and the development and implementation of solution
architecture. This process is a critical element of an integrated lifecycle process to
define stakeholder requirements, drive investment, and implement business and
information management solutions. Segment architecture work products describe
detailed results-oriented architecture and a transition strategy for core mission areas,
business services and enterprise services. Fully developed segment architecture
achieves the following set of business outcomes:
Results-oriented architecture is defined by linking business solutions to the
agency mission and performance improvements
Segment architecture is developed to support a clear and concise value proposition
linked to the agency mission, as well as strategic goals and objectives. Segment
architecture identifies opportunities to deliver business value and defines target
performance measures to monitor and demonstrate performance improvements.
Clear relationships are defined between the segment, the rest of the enterprise
and relevant cross-agency initiatives
Segment architecture creates visibility to other enterprise segments and cross-agency
initiatives describing opportunities to reuse or provide common solutions. The
segment architecture transition plan describes dependencies between related initiatives.
It also contributes to a common understanding of what the segment is responsible for
and how the segment supports the goals and objectives of the agency as a whole.
Segment architecture is fully reconciled with the agency enterprise architecture
Segment architecture is reviewed and approved in the context of the agency enterprise
architecture and is consistent with common or shared elements including standard
business processes, data, applications and technologies. Business requirements
identified at the segment architecture level and solution architecture level are used to
update the agency EA and EA transition strategy.
Business investments and resources are fully aligned with the approved segment
architecture
Segment architecture drives investment planning and resource allocation for a core
mission area or common or shared service. Sufficient resources are identified and
justified to execute the segment transition strategy and achieve measurable
performance improvements.
Applying Segment Architecture

The development and use of segment architecture work products are critical elements
to fulfill business and information management requirements and provide value to
business areas. Segment architecture development is triggered by both “top-down”
(strategic) and “bottom-up” (tactical) drivers.
November 2007 2-2

• Strategic drivers support the execution of the agency strategic plan and
implementation of the agency EA. The EA transition strategy defines the relative
priority and sequencing of individual segments to achieve strategic goals and is
the principal driver for the development and implementation of segment
architecture.
• Tactical drivers include the definition of new or revised requirements at the
program or organizational level, and the identification of program, process or
system performance gaps. Audit findings, program assessments, customer
satisfaction surveys and other information sources are examples of tactical
change drivers. Specific drivers are mapped to the agency EA to identify the
need to develop or update segment-level architecture.
Segment architecture work products are used across each phase of the Performance
Improvement Lifecycle and provide a bridge between the agency enterprise vision (EA
and EA transition strategy) and the implementation of business and information
management solutions. Figure 2-1 illustrates the role of segment architecture in linking
EA with project execution and performance measurement, as well as feedback loops
between segment architecture development, project execution, and the development
and maintenance of EA.
Architect Invest Implement
Define
Define Create
Create
Define
Define && Develop
Develop
Develop
Develop && Implementation
Implementation Program
Program Execute
Execute Measure
Measure
Prioritize
Prioritize Segment
Segment
Maintain
Maintain EA
EA &
& Funding
Funding Management
Management Projects
Projects Performance
Performance
Segments
Segments Architecture
Architecture Strategy
Strategy Plan
Plan
Figure 2-1: Linking EA with Project Execution

Table 2-1 describes a series of roles for segment architecture during each lifecycle
phase and describes the benefits from using segment architecture.
Phase Role Benefit(s)

• Increases the frequency and quality of interactions
between EA program staff and business and
technical stakeholders improving business and IT
Provides a standard process
planning and decision-making.
Architect to facilitate collaboration with
business stakeholders. • Improves alignment of business and IT
transformation initiatives with agency EA identifying
opportunities to share assets and apply enterprise
and government-wide standards.
November 2007 2-3

Phase Role Benefit(s)

Provides a structure and • Delivers value to agency core mission areas
methodology to establish clear through the development of business-driven,
line of sight from segment- results-oriented architecture.
Architect
level change drivers to • Demonstrates the value of agency-level EA by
measurable performance addressing priority business and information
improvements. management requirements.
Defines relationships between
core mission areas, business • Improves government-wide collaboration identifying
Architect and enterprise services, opportunities to reuse common or shared business
agency EA and cross-agency processes, data and services.
initiatives.
• Promotes the development and approval of results-
oriented architecture in advance of IT investment
Describes detailed business-
and budget formulation improving decision-making
driven architecture and
and portfolio management.
implementation alternatives to
Invest
support IT business case • Increases alignment of IT business cases and
development and budget agency budgets with the agency mission/vision.
formulation. • Improves the quality of supporting documentation
for IT investment business cases and budget
formulation.
• Consolidates IT investments around core mission
areas, business services, and enterprise services
simplifying the allocation of agency resources and
Links architecture increasing the efficiency and effectiveness of IT
Invest development and IT investments.
investment. • Increases alignment of the IT portfolio with agency
EA and cross-agency initiatives supporting
opportunities for government-wide collaboration and
reuse.
Defines a detailed Program • Accelerates the initiation of individual
Management Plan implementation projects and program activities.
(implementation plan) • Provides a framework to measure performance and
including the definition of validate target benefits (e.g., cost savings, cost
Implement
individual executable projects avoidance, improved mission performance,
and project milestones linked technology standardization).
to measurable performance • Provides detailed information to maintain EA and
improvements. EA transition strategy.
Implement • Enhances lifecycle management and governance
processes by providing a shared vision for business
Provides an approved target
and IT transformation.
architecture for the
implementation of business • Increases the alignment of business processes,
and information management information assets, and information technology
solutions. solutions with the agency EA and relevant cross-
agency initiatives increasing operational efficiency
and effectiveness.
Table 2-1: Segment Architecture Roles and Benefits
November 2007 2-4

Stakeholders
As with all levels of architecture development, involving the appropriate stakeholders in
the development process is critical to successful segment architecture. Segment
architecture development is conducted by an integrated project team (IPT) comprising
business subject matter experts, enterprise architects and technical subject matter
experts. IPT activities and meetings are coordinated and managed by a Program
Manager.
A collaborative approach to segment architecture development increases stakeholder
buy-in and enhances the segment architecture development process. The IPT asks
and answers questions about business and information management requirements,
makes informed decisions about the nature and priority of improvement opportunities
and helps to achieve performance goals. The responsibilities of members of the
segment architecture IPT and other principal stakeholders are described in Table 2-2
below:
Role Characteristics and Responsibilities

• Set agency strategic goals and priorities.
Senior Management • Define business drivers, business issues and performance goals for the
agency.
• Coordinate and manage all IPT activities during segment architecture
development and maintenance.
Program Manager • Apply segment architecture work products to develop an IT investment
business case and program management plan.
• Maintain line of sight from programs and projects to the agency strategic
goals and objectives.
• Define change drivers and business and information management
Business Owners
requirements for the segment.
(SMEs)
• Identify goals and objectives and performance measures.
• Share knowledge and information and serve as an advocate for architecture
development and implementation within the agency.
• Support the governance structure and help promote the use of common
technologies, standards and services.
• Provide a common structure for the segment architecture development.
• Provide universal components of the EA inherited and used by segments
Chief Architect and and solutions.
EA Team (Enterprise • Identify new performance improvement opportunities.
Architects)
• Identify opportunities to increase collaboration and reuse, including the
implementation of cross-agency initiatives described in the Federal
Transition Framework (FTF).
• Define and institutionalize sound architecture development processes.
• Advocate common goals and objectives in architecture programs.
• Communicate new mandates or initiatives at the enterprise level.
• Communicate and share information where critical intersections occur
between segments.
November 2007 2-5

Role Characteristics and Responsibilities

• Support development of segment funding strategy and business cases.
CPIC Lead
• Promote consolidation of IT investment business cases.
Government and • Define areas of collaboration and commonality.
Industry Partners • Define process overlaps and data exchanges.
• Execute projects identified in the planning stage, aligned with the target
segment architecture and documented as part of the target architecture or
Project Managers transition plan.
• Ensure project teams adhere to standard lifecycle development processes
and best practice.
• Inherit universal, common and unique elements of the enterprise and
segment architecture to support solutions development.
Solution Architects
• Adhere to technology standards and use of common technologies and
services to promote architecture implementation.
• Account for information used and compliant with the Federal Information
Security Management Act (FISMA) requirements and reporting.
Security Personnel • Define security requirements.
• Identify where security is a critical element in a business process, data,
application, or technology in use by an application or process within the
segment.
Table 2-2: Segment Architecture Stakeholders
Prerequisites and Success Factors

Effective segment architecture development and use are dependent upon the following
series of lifecycle processes, activities and other prerequisites:
• Execution of a process to identify and capture strategic and tactical drivers and
trigger the development and maintenance of segment architecture for core
mission areas, business services and enterprise services;
• Implementation of a common architectural framework for EA and segment
architecture development and maintenance, including architecture work products;
• Definition of a repeatable process for stakeholder collaboration and segment
architecture development and maintenance;
• Execution of governance and management processes to review and approve
segment architecture and reconcile work products with the agency EA;
• Execution of a communication and outreach strategy to educate business
stakeholders on the value of segment architecture as an element of the
Performance Improvement Lifecycle process.
Segment architecture development should be driven by the needs of the core mission
areas, business services or enterprise services it supports. The following success
factors reflect agency best practice and can be applied to enhance the effectiveness of
segment architecture development and implementation.
November 2007 2-6

Identify the key business questions the segment architecture should address
Software development initiatives not firmly anchored to the specific user requirements
are likely to fail. The same principle holds true for the development of segment
architecture where the users (or clients) are the owners and managers of agency lines
of business. Effective segment architecture must be driven to provide the information
decision-makers need to manage their business more efficiently and effectively.
Develop segment architecture work products to support business questions
The Program Manager should work with the IPT to identify the architecture products to
be used to answer business questions. The selection of architecture products should
be driven by priority requirements identified by the business owners and managers, and
should focus on products – models, reports, presentations, documents, or other
deliverables – able to be developed in reasonable time with available resources.
In many cases, the most helpful products are simple concept diagrams or decision
menus concisely summarizing available alternatives, or other simple presentations and
analysis reports. The measure of segment architecture value is not compliance with a
mandate, but its use by agency business managers and other stakeholders.
Focus work product development on priority business questions
The IPT should focus on identifying data sources to develop segment architecture work
products and answer business questions. By focusing collection activities on gathering
data to answer the highest-priority business questions, the IPT ensures it is not “boiling
the ocean” by collecting unneeded data. It is often helpful to focus on “quick wins” to
demonstrate value before branching out to other business questions.
Evaluate opportunities to increase agency and government-wide collaboration
and reuse
Increased collaboration and reuse improves the efficiency and effectiveness of agency
investments and solutions. Agencies should consider the implementation of common
solutions, including cross-agency initiatives, when evaluating architectural alternatives
to meet business and information management requirements. IPT members should
evaluate the cost and benefits of relevant cross-agency initiatives as a viable solution
alternative.
Monitor progress, measure performance, and verify outcomes

Segment architecture, like enterprise architecture, is most effective when there are well-
documented and clearly understood performance milestones. These milestones should
reflect measurable outcomes so the IPT and other stakeholders can assess the
effectiveness of segment architecture during each step of development and
implementation. The Program Manager should consider developing a scorecard or
checklist to monitor progress, evaluate segment architecture completion and
demonstrate results.
November 2007 2-7

Segment Architecture Concepts
Segment Architecture Content

Segment architecture comprises a series of work products describing baseline
architecture, target architecture, and a transition strategy for a defined segment of the
enterprise. Work products document segment-level change drivers, describe baseline
and target performance, business, data, services and technology architecture, and
provide an implementation plan to achieve measurable performance improvements.
Segment architecture work products are developed using standard formats and content
guidelines aligned with the agency EA framework, and provide a sufficient level of detail
to support decision-making during each phase of the Performance Improvement
Lifecycle. Standard work product content and formats promote collaboration and reuse
by facilitating the reconciliation of segment architecture work products with the agency
EA and relevant cross-agency initiatives found in the Federal Transition Framework.
Based upon government and agency best practices, segment architecture work
products are developed using a standard work process consisting of three phases:
“Analyze”, “Define” and “Operate”.
• Analyze Phase: Defines the scope of the architecture and requirements for
change. Outlines current business and information management environment
and high-level opportunities for performance improvement.
• Define Phase: Identifies the target segment architecture to support business

and information requirements, and outlines implementation alternatives, including
the implementation of relevant cross-agency initiatives. Describes a transition
strategy culminating in the development of a business case for IT investment and
budget formulation.
• Operate Phase: Develops a program/project management plan to support the

implementation of the target segment architecture and provides a link to project
execution and solution development. All architectural work products are updated
as new or revised requirements are defined during project execution, solution
implementation and performance measurement.
Specific architectural work products are developed to support decision-making as a

segment matures and moves through each phase of the Performance Improvement
Lifecycle. Table 2-3 lists sample segment architecture work products and provides a
crosswalk between each phase of the segment architecture process and the
Performance Improvement Lifecycle. Appendix A (Key Terms) provides a brief
description of architectural work products.
November 2007 2-8


Phase Architect Invest Implement
Change Drivers
Vision Statement
Analyze Performance Goals
Segment Architecture Process
Baseline Segment
Architecture
Target Segment
Architecture
Cross-agency Initiatives
Define Business Case
Alternatives Analysis
(cost-benefit)
Transition Strategy
Program/Project
Management Plan
Target Segment (Implementation Plan)
Operate Business Case (Revised)
Architecture (Revised) Solution Architecture
Performance
Measurements
Table 2-3: Sample Segment Architecture Work Products
Segment Architecture Development

Segment architecture development provides a simple and powerful technique for the
Chief Architect and EA program staff members to collaborate with business
stakeholders to implement the agency EA and deliver value to core mission areas. The
segment architecture process and associated work products outline a methodology to
ask and answer questions about business and information management requirements,
and make informed decisions about the nature and priority of opportunities to implement
target segment architecture and achieve performance goals. The resulting segment
architecture is a shared vision for business and IT transformation within a core mission
area or common service.
Segment architecture development is conducted by an IPT with activities and meetings
led by a Program Manager. The Program Manager, business subject matter experts,
and enterprise architects participate in each phase of segment architecture
development, but the composition of the IPT evolves as the segment moves through
each phase of the segment architecture process. For example, IT investment
management staff members participate during the “Define” phase to support the
development of an IT investment business case. Similarly, technical project managers
and system engineers participate to support the “Operate” phase and development of
solution architecture.
Table 2-4 identifies the IPT members playing prominent roles to drive the segment
architecture development process and provides a crosswalk between the process and
Performance Improvement Lifecycle.
November 2007 2-9


Phase Architect Invest Implement
Program Manager
Strategic Planner
Analyze
Business SMEs
Enterprise Architect
Program Manager
Segment Architecture Process
Business SMEs
Business Architect
Data Architect
Define ITIM Liaison
Application Architect
Technical Architect
Security Architect
IT Operations
Program Manager
Business SMEs
Contract/Acquisition
Business Architect
Specialist
Data Architect
Operate ITIM Liaison Project Managers
Application Architect
System Engineers
Technical Architect
Quality Assurance
Security Architect
IT Operations
Table 2-4: Integrated Program Team (IPT) Members
Segment architecture development is controlled by EA governance and management

processes across each phase of the Performance Improvement Lifecycle. Governance
and management processes are implemented to:
• Review segment architecture work product content and format standards to
promote reconciliation with the agency EA and relevant cross-agency initiatives;
• Validate opportunities for agency-level and cross-agency collaboration and reuse
including the implementation of relevant cross-agency initiatives;
• Review and approve segment architecture in advance of IT investment and
project execution;
• Capture segment-level business and information management requirements to
update and maintain the agency EA; and
• Capture lessons learned to improve the segment architecture process and
standard work products.
Segment Identification and Integration

Enterprise segments are identified during the development of the agency EA and EA
transition strategy.
The agency-level transition strategy describes a logical sequencing plan for the
development and implementation of segment architecture. Section 4 describes the
November 2007 2 - 10
content of the EA transition strategy and the relationship between segment architecture
and the EA transition strategy. The Chief Architect and agency EA program staff, in
close collaboration with internal stakeholders, facilitate all activities to develop agency-
level EA and the EA transition strategy, including the identification and prioritization of
enterprise segments.
Segment identification is a continuous, iterative process. Enterprise assets including
systems and IT investments are mapped to the agency-level reference models to create
a segment-oriented view of the enterprise (see Figure 2-2).
Enterprise Assets
• Programs Reference Models
Segments
• Processes
Performance
• Information • Core Mission Areas
• Applications Business
• Common Business
• Technology Data Services
• Investments • Common Enterprise

Services Services
• Personnel Technology
• Organizations
• Facilities
Figure 2-2: Segment Identification
Segment identification applies a variety of internal and external inputs such as the
agency mission statement, agency strategic goals and objectives, legislative mandates,
common or shared business and information requirements, and cross-agency initiatives
described in the Federal Transition Framework (FTF). This process organizes and
consolidates enterprise assets into logical groups aligned with a common purpose
(mission area) or common service, and identifies segments in three categories: core
mission areas, business services and enterprise services.
Table 2-5 provides a summary description of each segment type including the related
architectural reference model and segment owner.
FEA Reference Segment

Segment Type Description
Model Owner
Core Mission Area Unique service areas defining the Business Reference Business Area
mission or purpose of the agency. Core Model: Services for
mission areas are defined by the agency Citizens
business model (e.g., tactical defense, air
transportation, energy supply, pollution
prevention and control, and emergency
response).
FEA Reference Segment

Segment Type Description
Model Owner
Business Service Common or shared business services Business Reference Office of the
supporting the core mission areas. Model: Mode of Chief Information
Business services are defined by the Delivery, Support Officer (OCIO),
agency business model and include the Delivery of Services, support office or
foundational mechanisms and back office Management of Program
services used to achieve the purpose of Government Management
the agency (e.g., inspections and Resources Office (PMO)
auditing, program monitoring, human
resource management, and financial
management).
Enterprise Service Common or shared IT services Service Component OCIO, support

supporting core mission areas and Reference Model office or Program
business services. Enterprise services Management
are defined by the agency service model Office (PMO)
and include the applications and service
components used to achieve the purpose
of the agency (e.g., knowledge
management, records management,
mapping/GIS, business intelligence, and
reporting).
Table 2-5: Segment Types
The segment owner has primary responsibility for the development and implementation
of segment architecture. Business areas are responsible for the development of
segment architecture for core mission areas while the OCIO, a support office or PMO is
responsible for development of segment architecture for common business services and
enterprise services.
Segment architecture is not developed and implemented independently of other
segment types. Development and implementation of segment architecture for a core
mission area incorporates approved segment architecture for appropriate business
services and enterprise services. Similarly, segment architecture for an enterprise
service reflects business and information requirements defined by relevant core mission
areas and business services.
Figure 2-3 illustrates the relationships between core mission areas, business services
and enterprise services with the agency. The relationships and dependencies between
each segment type are defined and maintained by EA program staff in the agency EA
Segments
Home Mort. Insurance
Pollution Prevention
Aircraft Inspections
Grain Inspections
Education Grants
Tactical Defense
Energy Supply
& Control
Core Mission
Areas define the
unique purpose
of the agency
Inspections and Auditing
Business
Services
Financial Management
Direct Loans
Program Monitoring
Enterprise
Knowledge Management
Services
Geospatial Mapping
Reporting
Figure 2-3: Segment Types
Initiating Segment Architecture

The development and maintenance of the agency EA and EA transition strategy identify
and define enterprise segments and prioritize opportunities to develop and implement
segment architecture.
If the agency EA and EA transition strategy have not been developed to a sufficient
level of detail to support segment identification and prioritization, EA program staff can
execute the following steps to identify candidate segments and initiate segment
architecture development with business stakeholders. Stakeholder commitment must
be attained to support each step in this process and ensure business and technical
subject matter experts are assigned to initiate, develop and maintain segment
architecture.
Step 1: Define and prioritize business and information management
needs, and architectural change drivers.
This step identifies key business and information management requirements, and
significant strategic, policy, legislative, management and performance drivers impacting
the agency. Elements of the approach to define requirements and drivers include:
• Review major IT investments and business transformation and modernization

initiatives currently underway within the organization to identify relevant
requirements and drivers; and
• Compile information on current “pain points” to identify opportunities for
performance improvement for core mission areas or common services. Pain
points can come from audit findings, documented performance gaps, Program
Assessment Rating Tool (PART) scores, stakeholder satisfaction surveys or
other sources.
Step 2: Define, review, and prioritize candidate opportunities to

improve agency performance
This step highlights business needs and change drivers offering the most significant
opportunities to increase the efficiency and effectiveness of agency operations.
Elements of the approach to define and prioritize candidate opportunities include:
• Identify criteria to evaluate, prioritize and select opportunities. Evaluation criteria
include (but are not limited to) the impact of opportunities on agency
performance, the relative complexity and/or difficulty to fulfill business needs and
address change drivers, legislative or executive mandates, and relevant program
and project dependencies; and
• Apply evaluation criteria to prioritize opportunities.
Step 3: Identify candidate segment(s)

This step maps priority opportunities (business needs and change drivers) to the
agency business model and service model to identify candidate segments. Core
mission areas and business services are identified in the business model and enterprise
services are identified in the services model (see Table 2-3).
Business needs and change drivers are also mapped to cross-agency initiatives to
identify common or reusable services or solutions that can be applied to meet agency
requirements. Common or reusable services support development of segment
architecture and implementation of business and information management solutions to
achieve performance improvements.
Step 4: Select a segment and identified resources needed to develop

segment architecture
This step identifies management support and business and technical expertise required
to execute segment architecture development and integration. Based upon the scope
of the selected segment, resources can be identified from multiple program areas and
support offices. At minimum, candidate resources should be identified for the following
roles:
• Management sponsor(s) or champion(s);
• Qualified program manager; and
• Candidate IPT members (business and technical subject matter experts).
Step 5: Establish segment architecture IPT

This step formally initiates the segment architecture development process by
establishing the Integrated Program Team (IPT). Meetings are conducted with the
business champion(s) and other principal stakeholders to review resource requirements
and the schedule to complete segment architecture development; and assign business
and technical subject matter experts to the IPT.
Section 3 provides step-by-step guidance to develop segment architecture.
FEA Practice Guidance – Developing Segment Architecture
Section 3: Developing Segment Architecture

This section provides step-by-step guidance to develop segment architecture for core
mission areas and common services defined by the agency EA and EA transition
strategy. It outlines the segment architecture development process and describes the
individual business questions, development activities, and outcomes for each step in the
process.
Step-by-Step Guidance
Figure 3-1 illustrates the relationship or crosswalk between each phase of the
Performance Improvement Lifecycle and the steps (1 through 4) in the segment
architecture development process.
Performance Improvement Lifecycle F F F F F
1
Segment Development Process F F F F F
Analyze
Architecture
Analysis
2 3
Investment &
Define
Architecture
Funding
Definition
Strategy
Program
Operate
Management &
Execution
Figure 3-1: Segment Architecture Development
Segment architecture work products support lifecycle processes including IT investment

management, program and project management, and systems development. New and
revised business and information requirements are continuously identified as the
segment moves though each lifecycle phase, and as business and information
management solutions are funded and developed to meet stakeholder requirements.
Consequently, segment architecture work products must be maintained to reflect these
inputs. Figure 3-2 illustrates a feedback loop from the program management and
execution step providing new or revised requirements to the architectural analysis step.
November 2007 3-1


1
Analyze
Architecture Revised Requirements

Analysis
2 3
Investment &
Define
Architecture
Funding
Definition
Strategy
Program
Operate
Management &
Execution
Figure 3-2: Segment Architecture Development and Maintenance
The following sections provide step-by-step guidance to develop and maintain segment
architecture to support the Performance Improvement Lifecycle. Guidance is divided
into two sections – “Segment Architecture Development” and “Segment Architecture
Maintenance” – and is provided using a standard outline describing the questions to be
answered in each step, the activities and work products (deliverables) to answer each
question, and specific outcomes. Outcomes represent a decision point or milestone
that must be achieved to move onto the next step in the process.
Segment Architecture Development

The segment architecture development process asks and answers a series of questions
to establish clear relationships between strategic goals, detailed business and
information management requirements, and measurable performance improvements.
Each step in the development process comprises a series of questions to be answered
by the IPT to enhance decision-making.
November 2007 3-2

Step 1: Architectural Analysis

1
The purpose of this step is to define a simple and concise vision
for the enterprise segment and relate the vision to the agency
Analyze
Architecture
Analysis
2 3
strategic plan. During this step the IPT considers current
Investment &
change drivers, including key strategic, legislative, and
Define
Architecture
Funding
Definition
Strategy
4 management requirements to identify opportunities to achieve

Program
performance improvements. The primary questions to be
Operate
Management &
Execution
answered during this step are:

9 What is the scope of the segment?
This question is answered by developing a simple conceptual diagram and summary
description defining the current scope of the enterprise segment and the existing
operational environment (including stakeholders, processes, applications and
information exchanges). Defining segment scope helps build consensus within the IPT
on the range of opportunities for improvement and helps focus IPT working sessions.
Whenever possible, the IPT should use the EA knowledgebase to compile information
on segment scope and the current operating environment.
9 What are the primary change drivers impacting the segment?
This question is answered by identifying and describing new or revised business
requirements and other change drivers impacting the segment. Change drivers help
justify segment architecture development and implementation, and include both
strategic requirements and tactical requirements such as legislative changes, the
identification of performance gaps, and changes in stakeholder requirements. The IPT
should consider a broad range of inputs when identifying change drivers including the
agency strategic plan, enterprise architecture, executive directions, audit findings,
performance assessments, stakeholder surveys and other inputs.
9 What are the current segment systems and resources?
This question is answered by compiling information describing the baseline or “as-is”
architecture for the segment. Baseline information is compiled for each architectural
layer – performance, business, data, services and technology – plus current systems,
investments, and personnel. Information should be collected to a sufficient level of
detail to support the identification of performance improvement opportunities (e.g.
improved service to citizens, improved mission performance, cost savings/avoidance,
technology standardization, and improved management and use of information).
9 What are the deficiencies or inhibitors to success within the segment?
This question is answered by reviewing current segment assets and change drivers to
identify and document opportunities to improve agency performance and achieve
measurable results. Candidate opportunities should be linked to relevant change
drivers and prioritized based upon their relationship to specific deficiencies, such as
audit findings, Inspector General (IG) or GAO recommendations, and PART ratings, and
their association with legislative mandates, mission priorities, performance goals and
other criteria. The IPT can update the simple diagram and text description describing
November 2007 3-3

segment scope to illustrate and describe priority opportunities for improvement within
the context of the current operating environment.
9 What is our vision for the segment?
This question is answered by creating a simple one-page graphic illustrating the vision
for the segment. The conceptual diagram should describe the proposed operating
environment including planned changes to stakeholder interactions, business
processes, information sharing, applications, and technology to resolve documented
deficiencies and achieve measurable performance improvements. The concept graphic
should be complemented by a summary vision statement describing the proposed
operating environment and relevant links to strategic goals and objectives.
Architecture Analysis: Activities
Table 3-1 below lists the major activities required to answer the primary questions for
the step, along with each activity’s stakeholders and key deliverables.
Activity Stakeholder(s) Deliverables
Develop concept diagram - Program Manager - One-page “as-is” or baseline
describing segment scope and
- Business Owners (SME) illustration and summary text
current operational
- Enterprise Architect description.
environment.
Identify new or revised - Program Manager - Summary list of change drivers

requirements and change - Business Owners (SME) and associated information
drivers. - Enterprise Architect sources.
- Baseline Segment Architecture

Compile baseline segment - Program Manager (across all architectural layers)
architecture and segment - Business Owners (SME) - Legacy System Portfolio
assets. - Enterprise Architect - Segment Investment Portfolio
- Current Staff Resources
- Program Manager - Annotated baseline concept

Identify and document diagram
- Business Owners (SME)
opportunities for improvement. - Ordered list of opportunities for
- Enterprise Architect improvement
- Program Manager
- Vision diagram
Illustrate segment vision. - Business Owners (SME)
- Vision statement
- Enterprise Architect
Table 3-1: Architecture Analysis Activities
Architecture Analysis: Outcomes

Consensus on the priority opportunities for improvement for the enterprise
segment: The identification of prioritized opportunities defines the scope of the target
segment architecture to be developed in the following step.
November 2007 3-4

Step 2: Architectural Definition

The purpose of this step is to define the “to be” state of the
1
segment and develop a plan for achieving that state. During this
Analyze
Architecture
Analysis
step, the IPT will determine the performance goals for the
2 3
segment, establish target segment architecture, and develop the

Investment &
Define
Architecture
Funding
Definition
Strategy
segment transition strategy. This step should be completed 4
prior to the beginning of the agency’s Capital Planning and Program

Operate
Management &
Execution
Investment Control (CPIC) process. The primary questions to

be answered during this step are:
9 What are the performance goals for the segment?
This question is answered by establishing performance goals for the segment, including
target performance measures and the timeframe to achieve performance goals.
Performance goals form the basis of the performance layer of the target segment
architecture and should be reconciled with the agency EA and agency strategic plan to
establish a line of sight between the segment performance goals and the agency’s
overall strategic goals. The IPT uses the performance goals to determine the
performance gaps that need to be closed.
9 What are the design alternatives for achieving the performance goals?
This question is answered by evaluating design alternatives for achieving the
performance goals. The IPT should review the cross-agency initiatives in the Federal
Transition Framework (FTF) to determine if any are relevant to the segment and if so,
whether a cross-agency initiative can be reused as part of the target segment
architecture1. The IPT should also conduct market research to evaluate any existing
assets, systems, components, services or best practices able to be reused or applied as
a part of the target segment architecture. The alternatives analysis should consider
risk-adjusted costs and benefits. The IPT uses the alternatives analysis to guide the
development of the target segment architecture.
9 What is the target architecture for the segment?
This question is answered by developing the target segment architecture. This includes
the segment’s established performance goals, as well as the business, data, services
and technology architecture supporting those performance goals. The target segment
architecture should be mapped to the FEA Reference Models. It should also describe
the systems required in the target environment, as well as those being consolidated.
The IPT will use the target segment architecture to develop the segment transition
strategy.
9 What projects are required to achieve the target segment architecture and in
what order should they be executed?
1 See OMB Memorandum 04-08 (February 2004) for additional information on avoiding the duplication of agency
activities and E-Gov initiatives.
November 2007 3-5

This question is answered by developing the segment transition strategy. The IPT
should use the target segment architecture to identify gaps to be closed to achieve the
target state and define projects to close the gaps. The IPT prioritizes the projects,
determines dependencies among the projects, and sequences the projects in the order
they should be executed. The IPT captures the results of these activities in the
segment transition strategy. The IPT and Chief Architect work together to reconcile the
target segment architecture and transition strategy with the agency’s EA to ensure
consistency with the rest of the enterprise.
Architecture Definition: Activities
Establish the performance goals - Program Manager - Performance layer of the target
for the segment. - Business Owners (SME) segment architecture
Conduct analysis to evaluate - Program Manager - Market research
design alternatives for achieving - Business Owners (SME) - Alternatives analysis
the performance goals.
Develop the target segment - Program Manager - Business, data, services, and
architecture. - Business Owners (SME) technology layers of the target
segment architecture
Develop segment transition - Program Manager - List of projects to be executed
strategy. - Business Owners (SME) - Segment transition strategy
- Enterprise Architect including a project sequencing plan
Reconcile the target segment - Program Manager - Reconciled enterprise architecture
architecture to the agency EA. - Business Owners (SME) and segment architecture
- Chief Architect
Table 3-2: Architecture Definition Activities
Architecture Definition: Outcomes

Consensus on the target segment architecture and transition strategy: The target
segment architecture and transition strategy support the creation of a project funding
strategy, and the creation of business cases for investments required to implement the
target segment architecture.
Step 3: Investment and Funding Strategy

1
Architect Invest Implement The purpose of this step is to define a funding strategy for
project execution and develop the business cases to justify

Analyze
Architecture
Analysis
2 3 investments in the CPIC process. This step should be

Investment &
completed prior to submitting the agency’s budget to the Office
Define
Architecture
Funding
Definition
Strategy
Program
Operate
Management &
Execution
November 2007 3-6

of Management and Budget (OMB). The primary questions to be answered during this
step are:
9 What is the funding strategy for the projects?

This question is answered by creating a funding strategy for the projects identified in the
segment transition strategy. The IPT works with the CPIC Lead to analyze funding
alternatives for the projects using the project sequencing plan in the segment transition
strategy. This includes identifying and evaluating possible funding sources and
approaches. The funding strategy should consider consolidating resources from
existing investments identified in the target segment architecture. The IPT and CPIC
Lead develop a funding strategy to ensure the necessary funding is available when
needed to implement the target segment architecture.
9 What is the justification for the investments required to implement the target
segment architecture?
This question is answered by developing business cases for the investments supporting
the projects identified in the segment transition strategy. The business case includes
information from the architectural analysis, target segment architecture, and project
funding strategy. The IPT works with the CPIC Lead to produce the remaining
information required by the agency’s CPIC process. This information supports the
selection of individual IT investments included in the agency’s IT investment portfolio.
Investment and Funding Strategy: Activities

Analyze funding alternatives - Program Manager Funding alternatives analysis
- CPIC Lead
Create the funding strategy for - Program Manager Project funding strategy
the projects - CPIC Lead
Develop business cases for - Program Manager Business cases (Exhibit 300s)
the investments - Business Owners (SME)
- CPIC Lead
Table 3-3: Investment and Funding Strategy Activities
Investment and Funding Strategy: Outcomes
IT investment portfolio with an approved funding strategy: The project funding
strategy defines the approach and activities needed to provide a funding stream to
support the execution of projects identified in the segment transition strategy. The
selection of IT investments as part of the agency’s IT investment portfolio determines
the individual projects included in the program management plan.
November 2007 3-7

Step 4: Program Management Plan and Execute Projects

The purpose of this step is translating the segment architecture
1
and funding strategy into a program management plan defining

Analyze
Architecture
Analysis
the nature and scope of individual projects required to

2 3
implement the segment architecture, and dependencies

Investment &
Define
Architecture
Funding
Definition
Strategy
between the segment (program), other agency initiatives, and 4
relevant cross-agency initiatives. The program management Program

Operate
Management &
Execution
plan includes a performance improvement strategy defining

progress milestones linked to performance goals and is used to update and maintain
the agency EA transition strategy. The primary questions to be answered during this
step are:
9 How do we use available resources to achieve performance goals?
This question is answered by developing a detailed, executable program management
plan describing the individual implementation projects, and the logical sequencing of
projects to achieve the target segment architecture. The program management plan
should be developed to a sufficient level of detail to allow project managers and system
developers to understand the scope and duration of individual projects and the
relationships between implementation tasks and activities. The program management
plan should also clearly define the relationships with other agency initiatives (programs)
and relevant cross-agency initiatives.
9 What is the nature of individual solutions to implement the target segment
architecture and achieve performance goals?
This question is answered by executing individual projects defined by the program
management plan and developing solution architecture for elements of the target
segment architecture. Individual projects should be executed in accordance with
agency project management guidelines, and solution architecture defined and
implemented in accordance with the agency system development methodology.
Segment architecture work products can be reused to initiate the system development
lifecycle and define requirements and standards to develop solution architecture.
Solution architecture is developed in compliance with the approved segment
architecture and enterprise architecture and verified using governance processes to
ensure standards compliance and reuse.
9 How well are we progressing towards achieving performance goals?
This question is answered by defining and monitoring performance measurement
indicators and target performance measures to verify performance improvements. The
program management plan defines target performance measures linked to
implementation milestones. Individual milestones with performance measures are
selected and included in the EA transition strategy to measure progress toward the
implementation of the segment architecture and performance goals.
Program Management and Execution: Activities
November 2007 3-8


Develop a detailed, executable - Program Manager - Program Management Plan
program management plan including project sequencing plan.
describing individual
implementation projects.
Execute individual - Program Manager - Project Plan(s)
implementation projects. - Project Managers - Solution Architecture
- Solution Architect
- Project Teams
Define and monitor - Program Manager - Performance Improvement Plan
performance measurement - Enterprise Architect - EA Transition Strategy (Update)
indicators and target - Actual Performance Measurements
performance measures.
Table 3-4: Program Management and Execution Activities
Program Management and Execution: Outcomes

New or revised business and information management requirements: The
development and implementation of solutions defines new requirements assimilated by
the IPT and EA program staff to update the segment architecture and agency EA.
Performance metrics describing the impact of the development and
implementation of segment architecture: Performance metrics for individual
implementation milestones are applied to demonstrate increases in the efficiency or
effectiveness of business and information management solutions, or as inputs to revise
segment architecture and develop a corrective action strategy to resolve interim
performance deficiencies.
Segment Architecture Maintenance
Segment architecture maintenance monitors and assimilates new business and
information requirements, and applies these drivers to update segment architecture
work products. This maintains clear relationships between agency strategic goals,
business and information management solutions, and measurable performance
improvements. During this step the IPT considers top-down drivers including recent
changes to the agency enterprise architecture and new cross-agency initiatives, as well
as bottom-up change drivers such as new requirements identified though the execution
of implementation projects and the development of business and information
management solutions. The primary questions to be answered during this step are:
9 What are the new or revised change drivers for the segment?
This question is answered by updating the list of architectural change drivers. New or
revised change drivers serve as inputs to segment architecture maintenance activities
and are applied to define the impact of new drivers on existing segment architecture
work products. The IPT should monitor and assimilate both top-down and bottom-up
change drivers including feedback loops from the development and implementation of
business and information management solutions.
November 2007 3-9

9 What is the impact of new change drivers on segment architecture work

products?
This question is answered by analyzing and prioritizing new change drivers and
determining the impact of requirements on existing segment architecture work products.
The Program Manager and IPT should develop an action plan to update relevant
segment architecture work products to address priority drivers and include these actions
in the program management plan. The action plan should include elements of the
segment architecture development process required to revise the segment architecture
and should be scheduled to support lifecycle processes such as IT investment
management.
Segment Maintenance: Activities
Table 3-5 below lists the major activities required to answer the primary questions
related to segment architecture maintenance, along with each activity’s stakeholders
and key deliverables.
Update list of architectural - Program Manager Summary list of change
change drivers - Business Owners (SME) drivers and associated
information sources
Analyze and prioritize change - Program Manager Priority list of architectural
drivers - Business Owners (SME) change drivers
Determine impact of priority - Program Manager Updated program
change drivers on segment - Enterprise Architect management plan
work products and the
program management plan
Table 3-5: Segment Maintenance Activities
Segment Maintenance: Outcomes

Allocation of resources to update relevant elements of the segment architecture:
The revised segment architecture is applied to support each phase of the Performance
Improvement Lifecycle including IT investment management and project execution.
FEA Practice Guidance – EA Transition Strategy
Section 4: EA Transition Strategy

This section describes how to develop and use an EA transition strategy to drive agency
investment planning to achieve mission objectives and business results.
Transition Strategy Concepts
Transition Strategy in Enterprise Architecture

The EA transition strategy is a critical component of an effective EA. It describes the
overall plan for an organization to achieve the target (“to-be”) architecture within a
specified timeframe. It clearly links proposed agency investments to the target
architecture. Also, the transition strategy helps define logical dependencies between
transition activities (programs and projects) and the relative priority of these activities
(for investment purposes). Essentially, it is the multi-year plan to coordinate agency
initiatives toward achieving the target architecture.
Baseline Target
Transition
Architecture Architecture
Strategy
(“As-Is”) (“To-Be”)
Interim Targets
Figure 4-1: EA Transition Strategy: Baseline to Target
The scope of the EA transition strategy includes the entire agency. The transition
strategy reflects segment architectures associated with more specific bureau- or
program-level units in the organization and can include cross-cutting segments within
the agency. While the agency-wide transition strategy will be at a limited level of detail,
segment architecture transition strategies are expected to be more detailed. These
segment architecture transition strategies should be included as subsets of the EA
To create the transition strategy, both the baseline architecture and the target
architecture should already be documented (or inventoried in an EA repository). The
required detail and completeness of the baseline architecture should be to the level
necessary for it to serve as the starting point for the transition strategy. The EA
transition strategy should address the multi-year timeframe for which the agency’s
target architecture is defined (typically three to five years). As an agency’s baseline and
target architecture are updated periodically, the EA transition strategy should also be
updated accordingly.
Transition Strategy in the Performance Improvement Lifecycle

Development of the EA transition strategy occurs during the “Architect” phase of the
Performance Improvement Lifecycle. The transition strategy is a key product of the
November 2007 4-1

“Architect” phase leading to a proposed investment portfolio in the “Invest” phase.

Because the IT investment portfolio is generated from the architecture, the agency
should be able to show progress toward achieving mission objectives and business
results by implementing the investments in the portfolio.
EA Transition
Strategy
Figure 4-2: EA Transition Strategy in the Performance Improvement Lifecycle
Developing the Transition Strategy

The transition strategy is developed through a number of major steps. The details of
how these steps are performed can vary from agency to agency based on a variety of
factors, such as the organizational complexity of the agency, the scope of the agency’s
mission, and agency governance processes. The major steps to develop the transition
strategy are:
Step 0: Establish baseline and target architectures (and identify segments);
Step 1: Perform redundancy and gap analyses;
Step 2: Refine and prioritize architecture segments;
Step 3: Lay out the enterprise sequencing plan;
Step 4: Develop segment architectures; and
Step 5: Define programs and projects.
November 2007 4-2

Transition Strategy
Target
Architecture 1. Redundancy
0. & Gap Analysis
Baseline
Architecture
2. Refine &
Prioritize
Segments
3. Enterprise Adjustment
Sequencing
Plan
4. Develop
Segment
Architectures
To Agency
5. Define
CPIC &
Programs
Budget
& Projects
Process
Figure 4-3: Developing the EA Transition Strategy
Step 0: Establish Baseline and Target Architectures

Baseline and target architectures for the agency should be developed before the EA
transition strategy, which is why this is enumerated as “Step 0”. When developing the
agency baseline and target architectures, architects need to work closely with the
business owners to ensure the future state architecture meets the needs of the
business and is focusing on priorities that will help the agency perform its mission more
effectively. It is understood the agency target architecture will change over time as
business needs and priorities change. As future plans are accomplished, the baseline
should also be updated as necessary.
Establishing the baseline architecture is very much a data gathering exercise, while
designing the target requires more analysis. In general, the baseline architecture
should be modeled at a high level across the enterprise, but provide more detail for
areas of priority concern to the mission of the agency. The level of detail to which the
baseline architecture needs to be completed should be limited to the information
needed to identify areas for improvement, and for the baseline to serve as the starting
point for the transition strategy. It is likely some analysis of the baseline has already
been done to identify areas for improvement, such as, consolidation opportunities or
organizational inefficiencies.
When developing the target architecture, the architects need to work closely with the
business owners to ensure the target meets the future needs of the business and
focuses on priorities to help the agency perform its mission more effectively. The target
architecture should resolve deficiencies identified by business owners and identify new
approaches, such as best practices from outside the organization to address the
November 2007 4-3

agency’s business problems. A key part of establishing the target architecture is

identifying segments for the agency’s core mission areas and common services.
For more information on baseline and target architectures, and general guidance on
developing various EA work products, see the Practical Guide to Federal Enterprise
Architecture.
Step 1: Perform Redundancy and Gap Analyses

The purpose of performing redundancy and gap analyses is to identify opportunities for
improvement in the baseline architecture and to identify “gaps” between the baseline
and target architectures. These analyses should focus on assessing value to the
agency mission, identifying performance gaps, and cost cutting or cost avoidance
opportunities. The agency-wide target architecture should already have been designed
using the business needs of the organization as the primary drivers, and to implement
the goals and objectives in the agency’s strategic plan. Opportunities identified by
these analyses will be addressed by programs and projects laid out in the enterprise
sequencing plan (described below).
Some examples of baseline redundancies and gaps between the baseline and target
include, but are not limited to:
• Gap: Target performance measure, driven by a business need, cannot be
achieved using existing business processes and information systems.
• Gap: Target information sharing requirements cannot be achieved with current
data sharing methods and standards.
• Gap: Target cost efficiency for department-wide services cannot be achieved
with the existing business processes, applications, and organizational structure.
• Gap: Target architecture includes flexible operations that are not supported by
the current information systems, services, and business processes.
• Redundancy: Baseline analysis identifies redundant information systems
providing the same capabilities in different organizational units.
• Redundancy: Baseline analysis identifies redundant technology products and
standards in use by various organizational units within the department or agency.
For more information on redundancy and gap analysis, and general guidance on
developing various EA work products, see the Practical Guide to Federal Enterprise
Architecture.
Step 2: Refine and Prioritize Architecture Segments

Segments of the overall EA should be identified when the organization-wide EA is being
defined. Once segments have been defined, they should be prioritized and the
November 2007 4-4

development of segment architectures should be planned in the EA Program Plan2 and

the EA transition strategy.
Segments should be prioritized based on criteria important to the agency. Some
examples include, but are not limited to:
• Relevance to agency mission priorities and performance goals;
• Complexity/difficulty to develop and implement the segment architecture;
• Legislative or executive mandate requiring action;
• Opportunities to implement cross-agency initiatives described by the Federal
Transition Framework (FTF), by providing or subscribing to common solutions;
and
• Dependencies and common drivers between segment architectures.
In general, segment architecture should be developed in more detail than the agency-
wide EA. Segment architectures should have scheduled performance improvement
milestones and/or cost savings milestones, and these milestones should be reflected in
the EA transition strategy. The EA transition strategy should not serve as an EA
Program Plan, which is limited in scope only to the immediate activities of the enterprise
architects. Rather, the EA transition strategy should be a summary of program
milestones from across the organization to enable better management and reporting of
progress against agency-wide plans.
Step 3: Lay out the Enterprise Sequencing Plan

The enterprise sequencing plan provides an agency-wide view of all modernization
activities within the agency. This aggregated view includes segments, programs and
projects, enabling senior executives to use the EA for agency-wide planning. Budget
cuts, cancelled or delayed projects, or changes to program priorities can be quickly
assessed using the plan. The effects of those changes on other projects and programs
can be identified and dealt with as needed, as well as the overall impact on the
agency’s ability to meet mission objectives and performance goals. A conceptual
enterprise sequencing plan is shown in Figure 4-4, and the key elements of the
sequencing plan are defined below.
2 The EA Program Plan is the agency’s annual plan for developing and implementing the agency EA. Progress
against an agency’s EA Program Plan will be assessed using the quarterly EA reporting process by OMB.
November 2007 4-5

Transition Strategy
Program A
Project 1
Project 2
Target EA with Segments

Architecture
Architecture
Current EA “Baseline”
Project 3
Segment
Segment
Baseline
Project 4
Project 5
Program B
Project 6
Project 7
Project 8
Project 9
Program C
Architecture
Architecture
Segment
Baseline
Segment
Project 6
Project 7
Project 8
Project 9
Program D
Architecture
Architecture
Segment
Baseline
Project 10
Segment
Project 11
Project 12
Project 13
Performance
Improvement Plan
Interim Interim Interim = Project or Program Milestone
Target 1 Target 2 Target 3 = Agency Performance Milestone
= Cross-Project Dependency
Cross Agency Initiative (CAI)

CAI Integration Summary
Figure 4-4: Conceptual Enterprise Sequencing Plan
As shown in the enterprise sequencing plan above, the segment architecture transition
strategy is developed as the next level of detail within the overall EA transition strategy.
Individual programs and project level plans are then defined for each segment
architecture, while taking into account any dependencies that may crossover into other
segments.
Segment Architecture: A segment architecture provides detailed results-oriented
architecture and a transition strategy for a portion or segment of the enterprise. A
segment architecture is a subset of the enterprise architecture, is usually more detailed
than the overall EA, and may be associated with a specific organizational unit in a
department or agency, if appropriate. As part of the EA transition strategy, a segment
architecture is used to define initiatives (e.g., proposed investments) for a focus area of
the EA corresponding to a core mission area, business service, or enterprise service.
November 2007 4-6

Program: As defined in the Program Assessment Rating Tool (PART) guidance

from OMB, a program is an activity or set of activities intended to help achieve a
particular outcome for the public. A program may be recognized by the executive
branch and the Congress when making budget or other decisions. The nature of
programs varies dramatically including existing operational programs and
modernization programs, therefore agencies and OMB have a great deal of
flexibility in defining what a program is.
Project: A discrete, planned effort to achieve a specific goal or result
within a brief timeframe. A Project Manager is accountable for each
project as it moves through the investment process and implementation.
Interactions between projects should be used to show accurate
dependencies between programs and segments; the Sequencing Plan is
not intended to replace ongoing project management or to track agency
budgets down to the project level.
Dependencies between Programs and Projects: Maps the dependencies between
programs and projects so the effects of budget decisions or schedule adjustments can
be quickly assessed for impacts on performance milestones and plans to achieve the
target architecture.
Target Architecture: The target architecture represents the future vision for the
agency; also known as a “blueprint” or “to-be” architecture. The target architecture
should already be designed before the transition strategy is created, since the target is
the endpoint for the transition strategy. As the target architecture is periodically
updated, the transition strategy should also be updated. An “interim target” represents
a coordinated, incremental upgrade or change to existing operations, functionality, or
technology support, and can be useful in coordinating numerous multi-year initiatives in
the transition strategy.
Baseline Architecture: The baseline architecture represents the current state of the
agency; also known as an “as-is” architecture. The baseline architecture should be
completed to the extent it supports the business needs of the organization and can
sufficiently serve as the starting point for the transition strategy.
Performance Improvement Summary: Provides a consolidated view of agency
performance improvement and cost reduction milestones. This is not a separate plan –
it summarizes the performance goals and planned results from each project or program
identified in the sequencing plan. Specific program milestones can be events or
outcomes, but should lead to performance improvements. The performance
improvements listed in the sequencing plan should match performance metrics in Part I
- Section D of the agency’s Exhibit 300s. This performance information should be
updated in the transition strategy as needed, based on funding decisions from the
budget process that may affect timeframes to implement initiatives in the sequencing
plan.
Cross-Agency Initiative (CAI) Integration Summary: Provides a consolidated view of

planned activities and milestones to implement mandatory and informational cross-
agency initiatives described in the Federal Transition Framework (FTF) Catalog. The
November 2007 4-7

summary report describes clear relationships between the implementation of cross-

agency initiatives and elements of the agency EA Transition Strategy, including
segment architecture, modernization programs, and program or project milestones and
performance milestones. Milestones in the CAI Integration Summary should be aligned
with documented IT policy requirements (e.g., IPv6 implementation schedule) and
should reflect the planned schedule for the implementation of common solutions defined
by initiative task forces. In addition, milestones should be synchronized with target
milestones defined in the agency E-Gov Alignment and Implementation Report.
Step 4: Develop Segment Architectures

Segment architecture provides detailed results-oriented architecture and a transition
strategy for a portion or segment of the enterprise. Segments are parts of the EA
transition strategy, as shown above, describing core mission areas and common
services.
Segment architecture development is a collaborative process forming a bridge between
enterprise-level planning and the development and implementation of solution
architecture. This process is a critical element of an integrated lifecycle process to
define stakeholder requirements, identify and validate opportunities to implement
relevant cross-agency initiatives, drive investment, and implement business and
information management solutions. Segment architectures should be developed using
the approach described in the previous sections of this document.
Step 5: Define Programs and Projects

The programs and projects in the EA transition strategy should be examined in the
context of agency goals and the EA when they are defined. Programs and projects
identified by the EA should feed directly into the investment management and budget
formulation processes. It is understood there are many drivers to initiate the creation of
a program or project, such as a legislative mandate, executive order, national
emergency, etc.
Programs and projects defined in the EA transition strategy are the link between EA and
the investment management process. Defined programs can be specific to the agency,
or move toward common, government-wide solutions (e.g., cross-agency initiatives and
SmartBUY). Program Managers are responsible for budget and execution of each
project. For the purposes of the EA transition strategy, a project should be assigned to
a program.
During the capital planning and budget formulation processes, the transition strategy
should be used to help assess the impacts of program funding decisions and budget
trade-offs on the agency’s ability to meet scheduled performance milestones laid out in
the strategy.
Adjustment: After completion of the investment management and budget formulation
processes, the transition strategy will need to be updated based on the actual funding
decisions for the agency. Once agency appropriations are final, the transition strategy
(including the sequencing plan) must be updated to reflect funding decisions and budget
November 2007 4-8

“trade-offs” for the agency. Program scope, implementation schedules, cross-program

dependencies, achievement of performance milestones, and other impacts should be
assessed and adjusted accordingly in the transition strategy. This additional step is
intended to update the transition strategy as needed; it does not imply that the transition
strategy should be driven by the investment management and budgeting processes. As
shown in the rest of this approach, the agency strategy and architecture should drive
the creation of investments, not the other way around.
Using the Transition Strategy
Linkage to the Investment Portfolio

A primary output from the agency EA transition strategy is a proposed IT investment
portfolio that can be traced back to a business-approved architectural portfolio. Once
segments are identified, segment architectures are defined, and programs with projects
are architected to implement them, agency planners should consider these programs
and projects as proposed investments for the investment management process (i.e.,
capital planning process).
The EA transition strategy should include clear linkage between initiatives identified in
the transition strategy and specific investments in the agency’s investment portfolio. In
Transition Strategy Exhibit 53

Major IT Investments (All IT Investments)
Program A
Segment Architecture
Project 1
Line of Business
Project 2
Exhibit 300 53 Line Item
Target EA with Segments
Architecture
Current EA “Baseline”
Project 3
Segment
Baseline
Project 4
Project 5
Program B
Project
Project
6
7
Exhibit 300 53 Line Item
Project 8
Project 9
53 Line Item
Program C
Architecture
Architecture
53 Line Item
Segment
Baseline
Segment
Project 6
Project 7
Project 8
Project 9 53 Line Item
Program D
53 Line Item
Architecture
Exhibit 300
Architecture
Segment
Baseline
Project 10
Segment
Project 11
Project 12
Project 13 53 Line Item
Performance
Improvement
Interim Interim Interim
Summary
Target 1 Target 2 Target 3
Program and Project Milestones:

• Performance Improvement
• Cost Savings / Cost Avoidance
Figure 4-5: Linking EA Transition Strategy to the Investment Portfolio

accordance with guidance provided in OMB Circular A-11, agency investments (and
Unique Project Identifier UPI codes) should be matched to the appropriate segment
architectures described in the EA Transition Strategy.
Segment architectures should be used to organize investments and business priorities
within the EA. Segment architectures should not be used to create an additional layer
November 2007 4-9

of capital planning approval, unless such a layer already exists for a segment
architecture that is operated by a single organizational unit (i.e., component agency,
operating division, etc). The intent of using segment architectures is not to complicate
the capital planning process and other agency governance processes, but rather to
assist with grouping and prioritizing various agency initiatives that move through these
processes.
Performance Management
The programs identified in the transition strategy should be linked to specific program
performance goals. Coupled with the dependency relationships in the sequencing plan,
this provides the ability to assess the performance impact of changes across programs.
For example, one program has its budget modified – the dependency between this
program and another program shows the impact this budget adjustment will have on the
ability of the second program to meet a planned performance objective. For guidance
on how to define an effective performance measure, see OMB Circular A-11.
Performance management should be a primary consideration when transition strategy
initiatives are proposed for funding in the budget process. Effects on performance goals
across the agency, as shown by the dependencies between programs in the
sequencing plan, should be considered in agency budget decisions.
Annual OMB EA Assessment

As the transition strategy is updated each year, the agency’s success in achieving
performance milestones will be assessed against the previous year’s plan during the
annual EA assessment performed by OMB. For more information on how OMB will
assess agency transition strategy progress, refer to the OMB EA Assessment
Framework.
Quarterly OMB EA Progress Reports

The EA Program Plan is the agency’s annual plan for developing and implementing the
agency EA. Development of segment architectures should be identified in this plan so
EA resources will be assigned to create segment architectures. Progress against an
agency’s EA Program Plan will be assessed using the quarterly EA reporting process
implemented by OMB. For more information on the definition of EA progress
milestones refer to the Guidance for Quarterly Reporting Requirements located at:
http://www.whitehouse.gov/omb/egov/documents/FEA_EA_Quarterly_Reporting_Guida
nce_FINAL.pdf
Program Management
Architects should work with the business owners and program managers responsible for
agency business and support operations when defining programs, setting milestones,
and designing the target architecture and transition strategy. The agency should assign
projects to programs and identify program managers to oversee architecture (planning),
investment (budgeting), and implementation (execution) of programs and projects
defined in the transition strategy. Segment architectures should be used to group these
projects into coordinated efforts that contribute toward achieving a key agency mission
objective, a set of target performance measures, or another similar business-focused
outcome. Throughout the lifecycle of a program, the program manager is accountable
for success and has budget responsibility for the project(s) included in the program.
Government-wide Collaboration and Reuse

The EA Transition Strategy provides an enterprise-wide plan to manage the
implementation of relevant cross-agency initiatives, including dependencies between
segment architecture, modernization programs, and cross-agency initiatives. The CAI
Integration Summary describes the enterprise approach to increase collaboration and
reuse through the implementation of government-wide standards (such as IPV6 and
HSPD12) and common solutions aligned with E-Gov initiatives and LOB initiatives.
Government-wide collaboration and reuse should be a primary consideration when
transition strategy initiatives are proposed for funding in the budget process.
EA Transition Strategy Content

The EA Transition Strategy is a critical component of an agency EA, describing the
overall plan and schedule to achieve the target (“to-be”) architecture. The Transition
Strategy clearly links proposed agency investments to the target architecture, describing
logical dependencies between transition activities (programs and projects) and the
relative priority of transition activities (for investment purposes).
A complete EA Transition Strategy is developed through the execution of each step
illustrated in Figure 4-3 and includes the following content, describing the background
and approach for EA implementation.
Agency Mission/Change Drivers: Summary-level mission statement with an overview
description of primary modernization and/or change drivers.
Baseline Architecture: Overview of baseline (“as-is”) architecture
Target Architecture: Overview and illustration of target (“to-be”) architecture including
the definition of enterprise segments.
Enterprise Sequencing Plan: A high-level, agency-wide view of modernization
activities, outlining the relative prioritization and sequencing of enterprise segments,
programs and projects, and relationships between activities (see Figure 4-4). The
enterprise-wide sequencing plan also describes relationships between transition
activities and investments.
Performance Improvement Summary: Provides a summary description of the
performance goals and planned results from each segment, program or project
identified in the sequencing plan.
Cross-Agency Initiative Integration Summary: A consolidated view of planned
activities and milestones to implement mandatory and informational cross-agency
initiatives described in the Federal Transition Framework (FTF) Catalog.
Segment Architecture Overview: Summary description of active enterprise segments

defined in the EA Transition Strategy. Active segments are those segments currently
executing a segment architecture development process. Segment architecture
development guidance is provided in Section 2 “Introducing Segment Architecture” and
Section 3 “Developing Segment Architecture”. The segment overview provides
summary-level answers to selected questions (described Section 3) for each active
segment.
• What is the scope of the segment? Provide a simple conceptual diagram and
summary description defining the current scope of the enterprise segment and
the existing operational environment.
• What are the primary change drivers impacting the segment? Identify and
describe new or revised business requirements and other change drivers
impacting the segment.
• What is the vision for the segment? Provide a simple diagram illustrating the
vision for the segment including the proposed operating environment, and
planned changes to stakeholder interactions, business processes, information
sharing, applications, and technology to achieve measurable performance
improvements.
• What are the performance goals for the segment? Describe principal or key
performance goals for the segment including specific performance metrics, target
performance measures, and the timeframe to achieve performance goals.
• What is the funding strategy for the segment? Identify funding sources to
implement the segment vision. The funding strategy should consider
consolidating resources from existing investments.
The EA Transition Strategy is a working document. It is continuously reviewed and
updated to reflect changing enterprise-level and segment-level business drivers,
priorities, and resources. An approved version of the EA Transition Strategy should be
developed and approved each year to support the agency IT Investment Management
(ITIM) process and budget formulation.
FEA Practice Guidance – Measuring EA Program Value
Section 5: Measuring EA Program Value

Agency EA programs should deliver results-oriented products and services to inform
business decisions and increase the efficiency and effectiveness of IT investments,
program management and agency operations. This section provides guidance to
measure the value of enterprise architecture (EA) products and services in assisting
agency decision-makers and other stakeholders achieve mission goals and objectives.
Information and guidance are provided for the following topic areas:
• EA program value concepts: introduces EA value measurement as an element
of the Performance Improvement Lifecycle, and describes candidate EA value
measures to demonstrate the impact of EA products and services on IT
investment management, program management and agency operations.
• Measuring EA program value: describes a step-by-step process to define EA
value measurement areas, identify measurement sources, and monitor and track
value measures during each phase of the Performance Improvement Lifecycle.
• Using EA program value measures: outlines how EA value measures can be
analyzed and applied to improve EA products and services to enhance business
decisions.
• Sample survey elements: provides sample survey elements to measure
subjective value indicators such as overall customer satisfaction and the
perceived value of EA.
For more information on the Performance Improvement Lifecycle, please refer to

Section 1.
EA Value Measurement: Overview EA value measures are not

intended to be used by the Federal
EA value measurement is a continuous, customer- Enterprise Architecture Program
focused process integrated with each phase of the Management Office (FEA PMO) to
Performance Improvement Lifecycle. The assess the current level of EA
principal goals of EA value measurement are to program maturity. At present,
document EA value to agency decision-makers Federal agencies are not required
and to identify opportunities to improve EA to achieve specific value measures
products and services. EA value measurement as part of the annual EA
tracks architecture development and use, and assessment process. However,
monitors the impact of EA products and services future versions of the EA
on IT investment decisions, collaboration and Assessment Framework will assess
reuse, standards compliance, stakeholder whether the agency has an EA
satisfaction, and other measurement areas and value measurement program in
indicators. place.
November 2007 5-1

EA value measurement reflects a best-practice approach3 to monitor progress toward

target value outcomes, and establish clear relationships between the development and
use of EA work products and target outcomes for IT investment, program management
and agency operations. Value measurements demonstrate the impact of EA products
and services on business decisions during each phase of the Performance
Improvement Lifecycle.
EA Value Measurement: Objectives

EA value measures are used by Chief Architects and other agency stakeholders (e.g.,
Chief Information Officer, Chief Financial Officer) to achieve the following objectives:
• Demonstrate the value of the agency EA program by reporting changes in IT

investment, stakeholder collaboration, asset reuse, and other value indicators
linked to the use of EA products and services.
• Highlight the influence of the agency EA program on strategic and operational
decisions.
• Identify opportunities to improve EA products and services to support business
decisions during each phase of the Performance Improvement Lifecycle.
• Justify the allocation of agency resources to the development and use of
architectural products using verifiable value measures.
EA value measurement is not intended to duplicate or replace program performance

measures defined in the agency performance architecture and linked to the EA
Transition Strategy. Refer to Section 4 for information on EA transition strategy and
program performance.
EA Program Value Concepts
EA Value Measurement as Part of the Performance Improvement

Lifecycle
Results-oriented architecture is developed and implemented within the context of the
three-phase Performance Improvement Lifecycle – architect, invest and implement
(see Figure 5.1).
3 OMB Circular A-11, Section 26 and the Government Performance and Results Act (1993)
November 2007 5-2

Figure 5.1: Performance Improvement Lifecycle

Each lifecycle phase is comprised of tightly integrated processes to transform the
agency’s top-down strategic goals and bottom-up customer needs into a logical series
of work products designed to achieve results. The Performance Improvement Lifecycle
applies enterprise, segment and solution-level architecture to prioritize IT investments
and support program management and execution to optimize the agency operating
environment.

Enterprise
Agency Enterprise IT Investment Operating

Architecture Portfolio Environment
Architecture Levels
Segment
Segment IT Investment
Program
Architecture Business Case
Solution
Solution IT Project
Project
Architecture Budget
Figure 5.2 EA Value Framework
The EA Value Framework (see Figure 5.2) provides a way to conceptualize the impact
of EA across the Performance Improvement Lifecycle. At the Enterprise level, the
agency enterprise architecture, principally the EA Transition Strategy, guides and
informs the agency IT investment portfolio to achieve agency strategic goals and
objectives. At the Segment level, segment architecture for core mission areas,
business services, and enterprise services guide and inform the development of
individual business cases, leading to the formulation of business and information
management programs to implement the agency enterprise architecture and achieve
target business outcomes. At the Solution level, solution architecture guides one or
more projects supporting tactical implementation objectives. Individual projects are
defined by segment-level architecture and program implementation plans.
Architectural work products are developed throughout the Performance Improvement

Lifecycle. Value measures are defined for each phase and at each level of the
Performance Improvement Lifecycle to track progress in architecture development and
use, and establish clear relationships to measurable changes in IT investments,
program management and agency operations. EA value measures allow EA program
November 2007 5-3

staff to monitor the impact of EA products and services on business decisions and
relevant value measurement areas and indicators (e.g., number of major IT
investments, cost savings/cost avoidance, collaboration and reuse, and standards
compliance).
EA value measures are collected, analyzed and reported at certain times corresponding
to individual phases of the Performance Improvement Lifecycle. Chief Architects and
EA program staff must be cognizant of what EA value measures are available and
when they can be measured to demonstrate the impact of EA products and services on
IT investments, implementation programs and agency operations.
Types of EA Value Indicators

Established measurement concepts for quality control and customer satisfaction can be
used to measure the value of EA.
Subjective and Objective Value Measures
Subjective value measures capture the opinions of EA The primary challenge of EA

stakeholders. Stakeholders within the agency value measurement is to
evaluate the usefulness of EA products and services demonstrate a cause-and-effect
based on the value they provide in making business relationship between actions
decisions and performing their roles. The advantage within the EA program and
of subjective measurement is it provides feedback business decisions leading to
from stakeholders from a “customer satisfaction” agency performance
viewpoint. Subjective measures can be collected improvements. In some cases,
through surveys and interviews with stakeholders, there may be many contributing
and are often weighted to reflect the relative factors resulting in a specific
importance of each measure in determining EA value. performance improvement, of
which the EA program is only
Because subjective measures are dependent on one. Additionally, the EA
those providing feedback, respondents should be program may identify
representative of all stakeholders. This can be opportunities to enhance IT
addressed by contacting multiple stakeholders within investments influencing agency
a given community to ensure a balanced sample of performance in subsequent
views is collected. While subjective measures can be fiscal years.
used to determine the usefulness of EA products and
services, they do not objectively demonstrate the impact of EA products and services on
business decisions and agency operations.
Objective value measures do not rely on the opinions of individual EA stakeholders;

instead, they represent quantifiable EA value outcomes. These measures may reflect
changes in IT investments, IT program performance, or agency operations. The
advantage of objective value measures is they provide quantitative data often tracked
over multiple time intervals to measure trends in EA value.
November 2007 5-4

Common/Shared Measures and Agency-Specific Measures
There are many elements of an enterprise architecture initiative common across all
Federal agencies. For example, overall measures of usefulness of EA for IT investment
planning, reuse of IT assets and overall business decision-making value are applicable
to any agency. Table 5.1 defines a sample set of common value indicators to measure
EA value.
However, there is also a need to define agency-specific EA value measures. These

measures assess the usefulness of EA for decision-making in the context of specific
agency goals, programs, lines of business, or other agency initiatives. The value
measurement approach for an agency should include both common and agency-
specific elements, and both objective and subjective measures.
Roles and Responsibilities
Value measurement requires the participation of both the producers of EA products and
services (e.g., Chief Architect and EA program staff) and the consumers of EA products
and services (e.g., EA stakeholders).
Chief Architect/EA Program Staff
The Chief Architect and EA program staff are responsible for establishing the process to
measure the value of EA, including defining EA value measures and developing and
executing EA value measurement mechanisms. This requires a thorough
understanding of how EA products and services can enhance business decisions and
increase the efficiency and effectiveness of the agency IT portfolio to achieve agency
goals and objectives. Chief Architects need to engage EA stakeholders to educate
them on the value of EA and solicit their feedback on how the EA program can be
improved.
EA Stakeholders
EA stakeholders provide valuable feedback to improve EA products and services -

therefore stakeholder participation is critical to the effectiveness of EA value
measurement. Chief Architects and EA program staff can use a number of techniques
including customer surveys, stakeholder interviews, and workshops to collect feedback
on EA products and services. The last topic area of this section, Sample Survey
Elements, includes examples of sample survey elements to measure EA product use
and stakeholder satisfaction.
Measuring EA Program Value

EA value measurement applies a simple three-step process to define value measures,
identify measurement data sources, and execute value measurement. The value
measurement process defines baseline and target measures and monitors actual
November 2007 5-5

results, allowing Chief Architects and EA program staff to track progress toward target
value outcomes over time.
Step 1: Define Value Measurement Areas
Identify Stakeholder Communities
EA stakeholders are not just individuals, but representatives of larger stakeholder

communities. The potential scope of enterprise architecture extends across many
communities, from senior agency executives to program managers, project leaders,
budget analysts, developers, and others.
Identifying stakeholder communities is important because each community will have its
own view of the value of EA. A senior agency executive may be interested in identifying
strategic consolidation initiatives to fulfill the mandate of recent legislation, while a
programmer may be interested in understanding the technical standards of the agency
for server platforms and identifying existing software components available for reuse.
Examples of stakeholder communities include:
• Senior agency leadership;
• Strategic planning team;
• Chief Information Officer;
• Budget and capital planning officials;
• Program managers;
• IT infrastructure managers;
• Information Assurance team members;
• Project managers; and
• Software architects and developers.
Identify EA Program Value Goals (Outcomes)
Once stakeholder communities have been identified, they can be engaged to verify
what EA outcomes or goals are of greatest value to them. In other words, what
information and products could EA provide to best assist them in making decisions to
improve the ability of the agency to carry out its mission? To facilitate these
discussions, a “straw man” document with example outcomes can be provided to
stakeholders to focus the discussion on the outcomes most relevant to them.
Consensus on the value measurements is important since they should be the primary
drivers of EA program planning activities. These goals also drive the selection of
specific value measurements. This document does not attempt to identify what the
useful outcomes (or requirements) of an EA program should be across all Federal
agencies, but agencies should document their desired outcomes as the basis for EA
value measurement.
November 2007 5-6

Common Value Indicators
Table 5.1 provides a set of sample value indicators applicable to any Federal agency
with an EA program, and aligned with the value framework illustrated in Figure 5-2.
Select value measures from this list can be augmented with agency-specific value
measures, defined in collaboration with the appropriate stakeholder communities, to
populate an agency EA value framework.
Measurement
Stakeholders Type Common Indicators
Area
• OMB EA Assessment Score
Objective • Resolution of open GAO and IG findings
Agency • Senior Agency • % of baseline and target architectures modeled
Enterprise Leadership within EA repository
Architecture • CIO • % of surveyed respondents indicating EA work
• All Subjective products are useful to support decisions for
strategic planning, IT planning and performance
planning
• Senior Agency Objective • % of IT investments compliant with agency EA
Leadership Transition Strategy
IT Investment • CIO
Portfolio • Budget and • % of surveyed respondents indicating EA work
Capital Subjective products are useful to support decisions for IT
Planning portfolio selection, control and evaluation
• All
• Total cost savings/avoidance as a percentage of
the total IT budget
• Number of cross-agency service level
• CIO Objective agreements (provide and subscribe)
• Architects • Number of common/shared business processes,
Operating • IT data entities, and service components.
Environment Infrastructure • % of IT systems compliant with agency technical
Managers standards profile
• All • % of surveyed respondents indicating EA work
Subjective products are useful to support decisions for
managing agency IT environment, including
applications and associated infrastructure
• Number of enterprise segments with an
• Program assigned IPT (in accordance with guidance)
Segment Manager • Number of approved segments reconciled with
• Senior Agency Objective agency EA
Architecture
Leadership • Number of segment-level architectures
• CIO integrated with cross-agency initiatives (in
accordance with guidance)
November 2007 5-7

Measurement
Stakeholders Type Common Indicators
Area
• % of surveyed respondents indicating EA work
products are useful to support decisions for
Subjective establishing and managing lines of business,
executing major transformation initiatives and
improving cross-agency collaboration
• Allocation of investments to segments by type,
• Program e.g. core mission areas, business services,
IT Investment Manager Objective enterprise services
Business • Budget and • Consolidation of IT investments resulting in
Case Capital fewer Exhibit 300 submissions
Planning Subjective • % of surveyed respondents indicating the
architecture supports investment decisions
Objective • Changes to average agency PART score
• Program • % of surveyed respondents indicating the
Program Managers agency architecture enhances program/project
• Architects Subjective management decisions including budgets,
resource allocation management, earned value
or other measures of program performance
• % of approved software architectures compliant
Objective with agency EA standards within data, technical
Solution • Architects
and service component models
Architecture • Project
• % of surveyed respondents indicating EA
Managers Subjective supports decisions regarding reuse of existing
agency components, services and data
• % of projects fulfilling opportunities to reuse
Objective business processes, data elements and
• Software
common solutions.
Architects and
Project Developers • % of surveyed respondents indicating the
architecture supports development decisions
• Project Subjective including platform and tool choices, software
Managers
development lifecycle methodology and other
measures of IT implementation performance
Table 5.1: Common Value Indicators
Step 2: Identify Measurement Data Sources
Once the agency has established a set of value indicators, the next step is to identify
the appropriate sources for obtaining the value measurements. Objective value
measures are typically derived from agency statistics and documentation, such as
agency budget exhibits, PART scores, external assessments of agency performance, IT
inventories, and other sources. By contrast, subjective value measures are determined
through discussion with stakeholders in the form of surveys, interviews, workshops, or
other feedback mechanisms. Customer satisfaction surveys can be relatively simple;
however, it is important to understand how the questions are worded, the target
November 2007 5-8

audience group, and the number of respondents necessary to be statistically valid.

Appendix A includes sample survey elements to measure EA product use and
stakeholder satisfaction
Wherever possible, agencies should reuse existing data sources for measurement
rather than creating new instruments. This will minimize the effort of data collection and
the associated burden on agency personnel.
Step 3: Execute Value Measurement
Once a set of indicators has been selected for each measurement area, and sources
have been identified to provide the data, the next step is to determine baseline, target,
and actual value measures.
• Establish Baseline
The first step in executing value measurement is to establish “baseline”
measures as a reference for future comparison. If an EA program is just
beginning the EA value measurement process, baseline measurements usually
capture how the current EA products and services are providing value. If the EA
value measurement process is already established, these measures will reflect a
specific “starting point” in time.
• Establish Target Measures
Next, establish target measures to define the future direction (typically 3-5 years)
of how EA products and services can support the agency in achieving its goals
and objectives. Define clear relationships between the development and use of
EA work products and the target outcomes for IT investment, program
management and agency operations. Target measures are usually focused on a
specific planning timeframe, typically 3-5 years in the future. Interim value
measures take these long-term target values and translate them into more short-
term focused measures (e.g., quarterly, semi-annually, and annually). Examples
could include an increase in the number of systems deemed EA-compliant or
greater levels of EA usage by senior executives.
• Measure Actual Value Results
Once the baseline, interim and target measures are established, actual value
measurements are taken at specific intervals to monitor progress toward
achieving interim and target EA value measures.
Using EA Program Value Measures
Approach: Continuous Improvement
EA value measurement is a continuous, customer-focused process relying on feedback

from stakeholders and other information sources to increase the quality and
effectiveness of EA products and services.
November 2007 5-9

EA value measures are collected and applied using the process illustrated in Figure 5.3.
This process asks and answers questions related to the value of EA products and
services, and determines appropriate actions in response to changes in EA value
measures.
Define EA Value Plan EA Execute

Analyze EA
Measurement Measure EA Program
Value Revised EA
Areas and Value Value Plan
Measures Program Plan
Measures Activities
Feedback on EA Value Measures
Figure 5.3: EA Value Measurement Process
EA value measures are not static. Feedback and other information resulting from the
analysis and use of EA value measures are applied to revise value measures as the
agency EA program matures.
Answering EA value questions
The “Analyze” element of the value measurement process applies EA value measures
to answer value questions, and determine if EA products and services generate target
outcomes. Sample EA value questions include:
• Are stakeholders satisfied with the content, level of detail and timeliness of the
agency EA to support business decision-making?
• Does collaboration between EA program staff and business owners to develop
segment architecture for a core mission area, business service or enterprise
service result in increased stakeholder satisfaction in terms of the usefulness of
the agency EA?
• Does development of the EA Transition Strategy and integration with the Capital
Planning and Investment Control (CPIC) process have a measurable impact on
the IT investment portfolio through the consolidation of existing investments?
• Does the development and implementation of the agency EA lead to measurable
improvements in the on-time execution of agency performance milestones?
• Is there a clear relationship between EA development and implementation and
the implementation of business services and enterprise services using common
solutions?
• Does the development and implementation of the agency EA and segment
architecture result in measurable cost savings or cost avoidance?
If the answer to a value question indicates there is a demonstrated relationship between

EA products and services and target outcomes, Chief Architects should consider
opportunities to extend the reach of the product or service and other opportunities to
increase the impact of the product or service. Alternatively, if the answer to a value
question does not indicate there is a demonstrated relationship between EA products
and services and target outcomes, Chief Architects should consider why the expected
outcomes were not achieved and take appropriate actions to resolve the value or
performance gap.
Specific actions to resolve value or performance gaps are dependent upon actual EA
value measures and trends in the data, and will vary from agency to agency. The
following list describes common actions to improve the quality and effectiveness of EA
products and services:
• Manage business stakeholders’ expectations of value outcomes from the agency
EA program.
• Verify interactions between EA program staff and stakeholders during each
phase of the Performance Improvement Lifecycle to fulfill stakeholder
requirements.
• Modify the content and level of detail of architectural work products to meet
stakeholder requirements and support decision-making processes.
• Enhance architecture development and implementation processes such as
segment architecture development, CPIC integration, and EA governance
processes to resolve EA value and performance gaps.
• Change the timing, frequency, and/or nature of interactions between EA program
staff and business stakeholders to meet stakeholder requirements and support
decision-making processes.
• Increase stakeholder awareness and understanding of target EA value
outcomes, products and services through regular stakeholder communications
and outreach.
• Allocate additional EA program resources and/or business resources to resolve
priority value or performance gaps.
Each action identified to resolve an EA performance gap should be incorporated into the
EA program plan. EA value outcomes can be linked to completion and use milestones
to show the planned progression toward target value outcomes. For more information
on the definition of EA progress milestones refer to the Guidance for Quarterly
Reporting Requirements located at:
http://www.whitehouse.gov/omb/egov/documents/FEA_EA_Quarterly_Reporting_Guida
nce_FINAL.pdf
Sample Survey Elements

Following are sample EA survey elements to measure subjective value indicators such
as overall stakeholder satisfaction and the perceived value of EA products and services
to support parts of the Performance Improvement Lifecycle, i.e., segment architecture
development, IT investment management, program/project management and solutions
delivery. Sample survey elements are provided as guidance – they are not intended to
prescribe the nature and content of agency surveys.
Actual stakeholder survey instruments can use different formats and techniques to
solicit stakeholder responses, e.g., on-line or e-mail survey forms. Agency surveys
should be developed to reflect agency-specific requirements, terminology, survey
guidance and standards, and relevant EA value indicators. Whenever possible,
stakeholder surveys should pose questions or solicit feedback in simple language,
encouraging accurate responses from survey respondents.
Sample survey elements are provided in a simple table format and organized into three
sections:
• About the Respondent: Collects information on stakeholder responsibility and
how they use EA products and services
• Overall Satisfaction: Measures overall satisfaction with EA products and
services including accuracy, accessibility, and relevance to business decisions
• Performance Improvement: Measures value of EA products and services to
support specific parts of the Performance Improvement Lifecycle.
Satisfaction measures and performance improvement measures are often weighted to

reflect the relative importance of each measure in determining EA value.
About the Respondent:
What is your level of supervisory How often do you use EA products

responsibility? (choose one) and services? (choose one)
None Once a week or more
Team Leader 2 to 3 times per month
Supervisor Once per month
Manager Quarterly
Executive 2-3 times per year or less
The EA program provides products and services to support

decision-making in the following areas. Which of the following
areas contributes most to your success? (choose one)
Business Planning (Architecture)
IT Investment Management (Investment)
Program/Project Management (Implementation)
Solutions Development (Implementation)
Overall Satisfaction:
Please rate the following: Excellent Good Neutral Poor Don’t

Know
The value provided by EA products and
services to support business decisions
relative to incurred costs, e.g. time
dedicated to meetings, training sessions,
presentations, program reviews, and
other EA-related activities
Your overall satisfaction with EA
products and services
The likelihood you would recommend
using EA products and services to a
colleague to support business decisions
Please respond to each statement Strongly Agree Strongly

Disagree Disagree Don’t
Agree Know
I am satisfied with the overall accuracy of
EA products
I am satisfied with the overall relevance
of EA products and services
I am satisfied with the availability and
accessibility of EA products and services
The EA program team communicates
well with my program area
Please respond to each statement Strongly Agree Strongly

Agree Know
The EA program team collaborates well
with my program area
EA products and services enhance the
efficiency and effectiveness of our
business environment and operations
Performance Improvement:
Please respond to each statement: Strongly Agree Strongly

Agree Know
Segment architecture development
provides valuable information to support
business planning and decision-making
Program areas and the EA program
team work together to plan IT
investments
team collaborate to improve the quality
and management of IT investments and
programs

team collaborate to improve the quality of
business solutions
The agency enterprise architecture

describes reusable business processes,
data elements and/or services
(applications) to support business
solution delivery
Please provide additional information on how EA products and services can be improved
to support business decisions, management, and operations.
FEA Practice Guidance – Appendix A – Key Terms
Appendix A: Key Terms

Alternatives Analysis: Definition and comparison of viable alternatives to fulfill
business and information management requirements and implement target architecture.
For more information on alternative analysis for major IT investments, refer to OMB
Circular A-11 Section 300.
Baseline Architecture: Describes the current (“as is”) state of the agency in terms of
performance, business, data, services, and technology.
Business Case: Provides the justification for an investment. For more information on
business cases for major IT investments, refer to OMB Circular A-11 Section 300.
Business Services: Defined by the agency business model, business services include
the foundational mechanisms and back office services used to achieve the purpose of
the agency, e.g., inspections and auditing, direct loans, program monitoring, and
financial management.
Change Drivers: Strategic, policy, performance and industry factors impacting the
design and implementation of business and information management solutions. A
mature EA program monitors change drivers and applies relevant drivers to maintain
the enterprise architecture.
Core Mission Areas: Unique service areas that define the mission or purpose of the
agency. Core mission areas are defined by the agency business model (e.g., tactical
defense, air transportation, energy supply, pollution prevention and control, and
emergency response).
Cross-Agency Initiatives: OMB-sponsored initiatives such as E-Gov initiatives, Line
of Business (LOB) initiatives, and other government-wide initiatives such as Internet
Protocol Version 6 (IPV6) and Homeland Security Presidential Directive 12 (HSPD-12).
Enterprise Architecture: A management practice for aligning resources to improve
business performance and help agencies better execute their core missions. An EA
describes the current and future state of the agency, and lays out a plan for transitioning
from the current state to the desired future state.
Enterprise Services: Common or shared IT services that support core mission areas
and business services. Enterprise services are defined by the agency service
component model and include the applications and service components used to achieve
the purpose of the agency (e.g., knowledge management, records management,
mapping/GIS, business intelligence, and reporting).
Performance Goals: Target performance measures and timeframes. Goals should be
outcome-oriented and targets should be ambitious. For more information on
performance goals, refer to the Government Performance and Results Act (GPRA),
OMB Circular A-11, and the PART.
Performance Improvement Lifecycle: A three-phase process agencies can use to
close performance gaps and improve the overall performance of the agency. The
lifecycle is made up of the “Architect”, “Invest”, and “Implement” phases.
November 2007 A-1

FEA Practice Guidance – Appendix A – Key Terms
Performance Measurements: Actual results generated by the implementation of

enhanced business and information management solutions. Results are monitored and
measured to verify target benefits resulting from the implementation of business and
information management solutions.
Program Assessment Rating Tool (PART): A review of a program to helps identify
the program's strengths and weaknesses to inform funding and management decisions
aimed at making the program more effective. A PART review looks at all factors that
affect and reflect a program's performance including its purpose and design;
performance measurement, evaluations, and strategic planning; program management;
and program results and accountability.
Program Management Plan: Establishes the overall approach to managing the
program. Describes the program, deliverables, related management plans and
procedures, and methods used to plan, monitor, control, and improve the project
development efforts.
Segment: Segments are individual elements of the enterprise describing core mission
areas, and common or shared business services and enterprise services. Segments
are defined by the enterprise architecture.
Segment Architecture: Detailed results-oriented architecture (baseline and target)
and a transition strategy for a portion or segment of the enterprise.
Segment Architecture Process: Multiple-phase methodology to develop segment
architecture work products. Each phase provides an increasing level of architectural
detail to support IT investment decision-making and solutions development and
implementation. The Concept of Operations for Cross-Agency Initiatives provides an
example of a multiple-phase architecture development methodology.
Solution Architecture: An architecture for an individual IT system that is part of a
segment. A solution architecture is reconciled to the segment architecture above it.
Target Architecture: Describes the future (“to be”) state of the agency in terms of
performance, business, data, services, and technology.
Transition Strategy: A multi-year plan to implement target architecture for all or part of
an enterprise. Defines logical dependencies between transition activities and helps to
define the relative priority of each activity.
Vision Statement: Summary description of the target business and information
management environment to fulfill requirements, address change drivers, and achieve
performance improvements.
November 2007 A-2

FEA Practice Guidance – Appendix B – Reference Information
Appendix B: Reference Information

Architectural Principles for the Federal Government
(http://colab.cim3.net/file/work/BPC/2006-08-21/FedArchPrinciples2006_6_23_final.doc)
OMB Enterprise Architecture Assessment Framework
(http://www.whitehouse.gov/omb/egov/a-2-EAAssessment.html)
Federal Transition Framework
(http://www.egov.gov/ftf)
Federal Enterprise Architecture Reference Models
(http://www.whitehouse.gov/omb/egov/a-2-EAModelsNEW2.html)
OMB Circular A-11
(http://www.whitehouse.gov/omb/circulars/a11/current_year/a11_toc.html)
Practical Guide to Federal Enterprise Architecture
(http://www.cio.gov/archive/bpeaguide.pdf)
Concept of Operations for Cross-Agency Initiatives
(http://www.whitehouse.gov/omb/egov/e-5-documents.html)
Program Assessment Rating Tool (PART)
(http://www.whitehouse.gov/omb/part/)
November 2007 B-1

FEA Practice Guidance Nov 2007

Uploaded by

Copyright:

Available Formats

FEA Practice Guidance Nov 2007

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FEA Practice Guidance Nov 2007

Uploaded by

Copyright:

Available Formats

“Value to the Mission”

FEA Practice Guidance

Federal Enterprise Architecture Program

Section 2: Introducing Segment Architecture ....................................................2-1

Section 3: Developing Segment Architecture.....................................................3-1

Section 4: EA Transition Strategy........................................................................4-1

Quarterly OMB EA Progress Reports............................................................................ 4-10

Section 5: Measuring EA Program Value ............................................................5-1

Appendix A: Key Terms....................................................................................... A-1

Appendix B: Reference Information ................................................................... B-1

There are four main sections of the FEA Practice Guidance:

For additional information, appendices are also included:

November 2007 1-1

Delivering Mission Value

November 2007 1-2

Figure 1-1 illustrates the Defense

Figure 1-1: Segments and Services

Performance Improvement Lifecycle

November 2007 1-3

Improvement Lifecycle provides the foundation for sound IT management practices,

Figure 1-2: Performance Improvement Lifecycle

• Execute projects according to the program management plans.

Table 1-1: Performance Improvement Lifecycle Processes

November 2007 1-4

Figure 1-3: Architectural Levels and Attributes

By definition, EA is fundamentally concerned with identifying common or shared assets

November 2007 1-5

Solution architecture is commonly related to segment architecture and enterprise

November 2007 1-6

Section 2: Introducing Segment Architecture

November 2007 2-1

Applying Segment Architecture

November 2007 2-2

Figure 2-1: Linking EA with Project Execution

Phase Role Benefit(s)

November 2007 2-3

Phase Role Benefit(s)

Table 2-1: Segment Architecture Roles and Benefits

November 2007 2-4

Role Characteristics and Responsibilities

November 2007 2-5

Role Characteristics and Responsibilities

Table 2-2: Segment Architecture Stakeholders

Prerequisites and Success Factors

November 2007 2-6

Monitor progress, measure performance, and verify outcomes

November 2007 2-7

Segment Architecture Concepts

Segment Architecture Content

• Define Phase: Identifies the target segment architecture to support business

• Operate Phase: Develops a program/project management plan to support the

Specific architectural work products are developed to support decision-making as a

November 2007 2-8

Performance Improvement Lifecycle

Table 2-3: Sample Segment Architecture Work Products

Segment Architecture Development

November 2007 2-9

Performance Improvement Lifecycle

Table 2-4: Integrated Program Team (IPT) Members