1. Managing Enterprise Architecture
Federal Enterprise Architecture

2. Introduction
Previously, we introduced the Zachman Framework and TOGAF concepts to aid in understanding how to perceive enterprise architecture and develop specific architectures and solutions within this context.
One of the biggest challenges for most organizations, especially if they are functionally-driven, is to ensure every division, line of business, and/or department is participating accordingly.
One of the most diverse organizations is the United States Federal Government. For this reason, we will be using their Federal Enterprise Architecture to demonstrate how best to promote collaboration and cooperation across the organization within the context of managing the overall enterprise architecture.

3. Federal Enterprise Architecture
The challenge in enterprise architecture for the federal government is in managing diversity: different agencies, missions, objectives, locations, and structures. Each ‘line of business’ can be autonomous from the other ‘lines of business’.
However, government agencies are highly accountable to their customers (taxpayers) and must actively seek out the means of reducing costs, improve service, and manage information. The Federal Enterprise Architecture is a comprehensive approach to identifying and sharing architectures and solutions across the enterprise.
Copyright: The Art of Service 2008

4. Performance Improvement Lifecycle
FEA focuses on created results-oriented architectures, integrating processes to transform strategic goals into strategic results.
The Performance Improvement Lifecycle is the foundation for achieving results-oriented architectures.
The Performance Improvement Lifecycle consists of three simple steps: architect, invest, and implement.
At the core of each of these steps are enterprise-wide processes to ensure consistency across diverse lines of business (the names are not necessarily those used by the federal government):
Architect – Strategy Management (used to analyze and define the required architecture to meet strategic objectives)
Invest - Implementation and Funding Strategy (used to review and approve investments in developing and implementing an architecture)
Implement – Program Management (used to execute projects)
Architect
Invest
Implement
Copyright: The Art of Service 2008

5. Enterprise Architecture
Architecture Levels
Level
Scope
Detail
Impact
Audience
Enterprise Architecture
Organization/
Agency
Strategic
Outcomes
All
Stakeholders
Low
Segment Architecture
Segment Architecture
Segment Architecture
Line of
Business
Business
Outcomes
Business
Owners
Medium
The Architecture Levels in FEA define different perspectives for architectures with different expectations on scope, detail, impact, and audience.
The Enterprise Architecture is the highest level of architecture and it defines how the organization or agency will be structured to meet its strategic outcomes. This is a high level perspective of the inner workings of the ‘system’ and can be communicated and understood by all stakeholders.
Each agency may have several lines of business, or segment, in its responsibility. Each line of business is represented by its own segment architecture. With more details than the enterprise architecture, the segment architecture is intended to demonstrate how business outcomes are achieved. At this level, the primary audience is the business owner or manager of the line of business.
The solution architecture is the lowest level of architecture and it represents the specific solutions used by the segment to meet the business outcomes. Each solution has its own operational objectives to fulfill in this context. The level of detail is high. Solutions are used by users.
Historically, work in architectures has focused on the architectures at the enterprise or solution levels. However, effective management of enterprise architectures requires a firm grasp on understanding and managing at the segment architecture level.
Solution
Architecture
Segment Architecture
Segment Architecture
Function/
Process
Operational
Outcomes
High
Users
Copyright: The Art of Service 2008

6. Maintaining Alignment
Segment Architecture
Creating Structure
Reusing Assets
Enterprise Architectures provide a top-down perspective of the organization. The intent of this view is to identify common or shared assets across multiple lines of business. For instance, every department has requirements for hiring, managing, and terminating employees. At one time, these requirements may have been fulfilled by each department. However, the common requirements, processes, and goals make consolidating the human resource management into a single function an attractive approach strategically. Now, nearly every organization will have a Human Resources or Personnel department which serves the entire enterprise. The consolidation is often cheaper, less error-prone, and more manageable at the enterprise level.
A segment architecture focuses on a single mission area or service. For instance, Human Resources may be responsible for three major services: hiring, training, and payroll. Each service may require a different segment architecture (though, each architecture may share some common elements, often using the same solution architecture).
Segment Architectures are driven by three principles:
Creating a structure that supports the enterprise and meets the business outcomes for the service it represents. Often, the core structure for all segments is defined by the enterprise and is modified appropriately at the segment level.
Reusing important assets found across the organization, such as data, processes, applications, and technologies
Ensuring that the segment (service) is aligned with the enterprise strategies, policies, standards, and goals
The work products of segment architectures provide the means of transforming strategic goals identified at the enterprise architecture level into strategic results supported by relevant solution architectures. Collaboration when developing segment architectures increases buy-in for solutions and enhances the development process. The primary participants in developing segment architectures are the EA team (ensuring enterprise interests are met), senior management, program/project manager, business owners/subject matter experts, partners, and solution architects.
Maintaining Alignment
Copyright: The Art of Service 2008

7. Developing Architecture
Analyze
Define
Operate
Development of the segment architecture requires the creation of work products used to document key aspects of the segment, including:
Change Drivers
Performance Targets
Business, Data, Application (Service), Technology Architectures
The development of each work product will use the same standard process described in three phases: analyze, define, and operate.
The analyze phase focuses on defining the scope and requirements of the architecture. The define phase identifies and documents the key components of the architecture and creates a transition strategy for investing in and implementing the work product. The operate phase develops the implementation plan and executes.
The following slide shows some sample work products for segment architectures.
Copyright: The Art of Service 2008

8. Performance Improvement Lifecycle
Work Products
Performance Improvement Lifecycle
Development Process
Phase
Architect
Invest
Implement
Analyze
Vision Statement
Performance Goals
Baseline Architecture
Define
Target Architecture
Cross-Organization Goals
Cost/Benefit Analysis
Transition Strategy
Business Case
Operate
Revisions to Target Architecture
Revisions To Business Case
Program/Project Plan
Solution Architecture(s)
Performance Measurements
The table here shows the development process of a segment architecture from the perspective of the performance improvement lifecycle, with a sampling of corresponding work products related to supporting the process and the lifecycle. For governance of enterprise architectures, this table is a simple, but powerful, tool for defining what to expect from segment architecture development. Having similar information from each segment allows the enterprise to make informed decisions about what segments and solutions to invest and implement, as well as identifies improvements in the development process itself.
Copyright: The Art of Service 2008

9. Segment Architecture Development
Performance Improvement Lifecycle
Development Process
Phase
Architect
Invest
Implement
Analyze
Architecture Analysis
Define
Architecture Definition
Investment and Funding Strategy
Operate
Program Management and Execution
Given the work products shown in the previous slide, the major steps in developing a segment architecture are:
Architecture Analysis
Architecture Definition
Investment and Funding Strategy
Program Management and Execution
The ADM process of TOGAF can be mapped into these four steps.
Preliminary
Architecture Vision
Business Architecture
Information Systems Architecture
Technology Architecture
Opportunities and Solutions
Requirements Management
Migration Planning
Implementation Governance
Architecture Change Management
For this reason, we will not go into any depth with the FEA development process.
Copyright: The Art of Service 2008

10. Reference Models Performance Reference Model Business Reference Model
Service Component Reference Model
Segment architecture is dependent on the overall enterprise architecture to define its structure, identify and reuse enterprise assets, and align with the goals and objectives of the enterprise. Every segment consists of core mission areas, common business services, and common enterprise services.
At the core of the Federal Enterprise Architecture are five reference models: Performance, Business, Service Component, Technical, and Data.
The purpose of these reference models is to create a common framework and vocabulary for the enterprise. Maintaining reference models for the enterprise allows the organization to analyze solutions relative to the entire enterprise and not just a single segment, as well as identifies where duplicate work is being done in multiple agencies or where gaps exist in supporting strategic objectives.
Each reference model is a structured framework for defining and describing enterprise assets which exist and can be reused. Enterprise assets can consist of:
Programs
Processes
Information
Applications
Technologies
Investments
Personnel
Organizations
Facilities
Technical Reference Model
Data Reference Model
Copyright: The Art of Service 2008

11. Performance Reference Model
Measurement Area
Measurement Category
When managing an enterprise of multiple agencies or lines of business, some common performance indicators must be established. The performance reference was created to meet three objectives:
To produce performance information to aid in improving strategic, tactical, and operational decision-making
To improve enterprise alignment and identify the value in transforming inputs into quality outputs to achieve desired results
To identify opportunities for improving performance that impacts the entire organization and not just a single department or line of business
The structure of the performance reference model consists of four levels of detail:
Measurement Areas – A high level view of the key areas of concern for the enterprise. Many people may be familiar with the Balance Scorecard areas of customer, operations, financial, and improvement; these would be four pertinent areas for IT. The model for FEA has six measurement areas: Mission and Business Results, Customer Results, Processes and Activities, Human Capital, Technology, and Other Fixed Assets.
Measurement Categories – Identifies each area of concern as specific attribute or characteristic to be measured. In FEA, the measurement categories correspond to the Lines of Business identified in the Business Reference Model. This correlation enables the organization to identify and align the lines of business to the specific measurement areas.
Measurement Groupings – Identifies important types of measurement indicators. For FEA, these correlate to the sub-functions of each line of business as identified in the Business Reference Model. In more common terms, measurement groupings are simply the critical success factors for a particular line of business.
Measurement Indicator – If measurement groupings represent critical success factors, then measurement indicators represent the key performance indicators.
Measurement Grouping
Measurement Indicator
Copyright: The Art of Service 2008

12. Business Reference Model
Business Area
Line of Business
The Business Reference Model focuses on the functional relationships between lines of business, and is therefore independent from any existing organization structure. For instance, human resources is a functional line of business which is utilized by all departments within the organization. A Human Resource Department may be an organization entity which has accountability over the effectiveness of the function, but does not perform this function exclusively. The Business Reference Model may be a paradigm shift for some organizations, but it promotes a process-oriented approach to business, rather than a department-oriented approach.
The structure of the Business Reference Model defines three hierarchical levels:
Business Areas – Identifies the high-level functions of the business. In FEA, these categories reflect the organization’s purpose (Services), the mechanisms used to fulfill their purpose (Operations), the support functions for the organization (Shared Services), and resource management functions.
Lines of Business – Each business area is supported by specific functional lines of business. Here, the line of business is identified.
Sub-Function – Each line of business may serve several functions within the business area. Each function is identified here.
In FEA, there is a strong correlation between the Business Reference Model and Performance Reference Model. The result is the ability to map specific measurements to relevant business areas.
Note: The Business Area of the BRM and Measurement Area of the PRM are not directly related. For instance, customer satisfaction is a measurement area which may require the collaboration of multiple lines of business across all business areas to fulfill.
Sub-function
Copyright: The Art of Service 2008

13. Service Component Reference Model
Service Domain
Service Type
The service component reference models serve to identify and classify the services and service components needed to support business and performance objectives. Services are independent of business functions; the reference model can provide the basis for reusing applications, application capabilities, components and business services to support the business. For example, one sub-function of Human Resources is associated with compensation, but compensation is also a function of Finance, a distinct line of business. Rather than creating two separate mechanisms to support each line of business, a compensation service can be created and used by both.
Many services and service components actually have similar objectives but with different functions. As a result, they can be categorized and managed appropriately. The Service Component Reference Model has three (3) levels of categories:
Service Domain – a high level view of the services and capabilities of the enterprise, usually grouped based on business-capability. FEA has seven (7) service domains identified: customer service, process automation, business management services, digital asset services, business analytical services, back office services, and support services.
Service Types – an additional level of categorization from which further context can be achieved. In IT, many frameworks will categorize on two levels, for instance:
ISO/IEC – 15 service management processes are categorized into 7 different domains.
ITIL – 25 processes are categorized into 5 domains.
COBIT – 31 processes are categorized into 4 domains.
Components – define the specific ‘building blocks’ used to create a service.
Component
Copyright: The Art of Service 2008

14. Technical Reference Model
Service Area
Service Category
The technical reference model identifies and documents the standards and technologies used to support service delivery and to construct business applications.
The Technical Reference Model for FEA has three (3) tiers:
Service Areas – a high level categorization of service components, usually based on value to the business. In TOGAF, this may be synonymous with infrastructure and business applications. In FEA, there are four (4) service areas: service access and delivery, service platform and infrastructure, component framework, service interface and integration.
Service Category – provides the means of categorizing technologies and standards based on the function they serve. In TOGAF, this is loosely correlated to the green boxes in the diagram.
Service Standard – the final categorization of technologies and standards from an architecture perspective, often identified based on industry standards. For instance, a service category may identify delivery servers, but the service standards can include web servers, media servers, application servers, portal servers, etc. The Service Standard will often become the basis for tracking component assets within a configuration management system.
Service Standard
Technical Reference Model, TOGAF 9.1
Copyright: The Art of Service 2008

15. Data Reference Model Data Sharing Data Description Data Context
For many organizations, some data can become extremely useful across the enterprise. In the federal government, the unique identifier for a single taxpayer can identify the person’s relationships with the government, the benefits they are entitled to, and a record of their requests to the government. In hospitals, the ability to pass on patient information from one department to the next is a crucial step in providing the best holistic care possible. In manufacturing, the ability to track lots of raw material through processing can aid in managing quality of a production line.
The Data Reference Model has a different configuration than the other models. In fact, the reference model can be extremely complex—the complete model requires a separate document from the other models within FEA. The model consists of the following components:
Data Description – provides the means to uniformly describe data, allowing the data to be discovered and shared across the enterprise.
Data Context – establishes a taxonomy for categorizing data, creating a common vocabulary related to data and enabling data to be discovered easily.
Data Sharing – supports the organization’s ability to share data through re-occurring and ad hoc requests.
Data Description
Data Context
Copyright: The Art of Service 2008

16. Making FEA Work
The key to FEA is its reference models—the ability to identify and leverage architecture building blocks across the enterprise.
Clearly define how business performance is impacted by architecture development.
Use the Performance Improvement Lifecycle and the Architecture Development Process to identify the various aspects of the segment architectures, i.e. objectives, work products, roles, etc.
The Federal Enterprise Architecture provides a simple approach for managing a diverse set of enterprise assets. No matter what role you have in your organization, an architecture based on FEA will provide sufficient information to leverage existing architectures and identify opportunities for improvement.
This framework is presented in this toolkit to provide a model for effective decision-making related to enterprise architectures.
Copyright: The Art of Service 2008

17. The Toolkit
To support the efforts of adopting enterprise architecture at this point, the Toolkit provides the following aids and templates:
Creating a Reference Model
Copyright: The Art of Service 2008

18. Moving Forward
Use the aids and templates to create an effective conversation for enterprise architecture in your organization.
The process, Creating a Reference Model, provides the means for identifying, describing, and managing the diverse set of building blocks available to the organization’s enterprise architecture.
For further ideas and guidelines in enterprise architecture, see ‘Enterprise Architecture in Practice’.
Copyright: The Art of Service 2008