FEA and FSAMCSPP 51075 Spring 2011

Contents

FEA refresher Overview▪ Background▪ Five Reference Models

Federal segment architecture methodology (FSAM) What is segment architecture? How is FSAM related to FEA? What is it for?

A Brief History of FEA

1996: Congress passes Clinger-Cohen Act.

1998: CIO Council begins work on its first major project, the Federal Enterprise Architecture Framework (FEAF)

1999: FEAF v1.1 released

2002:OMB renames FEAF to FEA

2004: General Accounting Office reports that only 20 of 96 federal agencies have established at least the foundation for effective architecture management.

2008: FSAM v1.0 released by CIO Council’s Architecture and Infrastructure Committee

1987: Zachman publishes "A Framework for Information Systems Architecture"

2011?

Responsibility for FEAF moves to the Office of Management and Budget

FEA SA FSAM

Who manages FEA?

Federal Government

Office of Management and Budget

Office of E-Government

and IT

FEA Program Managemen

t Office

General Services

Administration

Federal CIO Council (et cetera)

FEA SA FSAM

How did FEA come about? Attempt by Federal Government to unite its various agencies under a common EA

FEA Program Management Office “equips OMB and federal agencies with a common language and framework to describe and analyze IT investments, enhance collaboration and ultimately transform the Federal government”▪  Goal: Facilitate communication, cooperation, collaboration, and sharing across agencies by giving

standard terms and definitions for the domains of enterprise architecture Clinger-Cohen Act (1996), aka Information Technology Management Reform Act

Put the director of the OMB in charge of:▪ Improving acquisition and use of IT by federal government▪ Developing process to analyze risks and results of IT investments▪ Overseeing the development and implementation of standards and guidelines for federal IT systems▪ Encouraging the heads of executive agencies to adhere to best practices▪ Assessing and comparing other models for IT management that are being used by other organizations

Mandated that the heads of executive agencies design and implement process to improve the effectiveness of their IT investments

A CIO Council, consisting of CIOs from all major governmental bodies, was created to oversee this effort Chair of the CIO Council is the Deputy Director for Management for OMB Vice Chair is elected by the CIO Council from its membership. Membership on the Council

comprises CIOs and Deputy CIOs from 28 Federal executive agencies

FEA SA FSAM

What is FEA? Five interrelated reference models

Performance Business Service Component Technical Data

▪ Enable cross-agency analysis▪ Helps to identify redundancies, gaps, opportunities for collaboration

Three general profiles Geospatial Records Management Security and Privacy

▪ Intended to promote consistent, common EA practices that improve government performance

FEA

Taxonomy, i.e. classification of

artifacts

Architectural Process, i.e. recipe for

creating artifacts

FEA SA FSAM

Five Reference Models A Reference Model is a set of references to

artifacts necessary to define the scope, content, rules and processes subsumed under a particular architectural domain, including relationships to other models

Each model contains: PPSG Baseline state, target architecture Transition roadmap/migration plan Reference to governance plans that specify how

activities are to be governedFEA SA FSA

M

Performance Reference Model Framework for measuring

performance and outputs across enterprise Provides means of measuring

success of IT investments and their impact on strategic outcomes

Three objectives: Produce enhanced performance

information Create clear line of sight from

inputs to outputs▪ Articulate cause and effect

Identify opportunities for performance improvement, across organizational boundaries

Measurement area e.g. Customer Results

Measurement category e.g. Timeliness and Responsiveness

Measurement grouping e.g. Response time

Measurement indicator e.g. how many minutes you’re placed on hold

FEA SA FSAM

Business Reference Model Framework for business view

(as opposed to organizational) view of LOBs LOBs include internal

organizations, services for citizens

Independent of the agency performing the LOB

Define mission-critical lines of business, business processes, and functions

Describes enterprise around common business areas, instead of department by department Promotes collaboration

Business area e.g. Services for Citizens

LOB e.g. Natural Resources

Subfunction e.g. water resource management, which is a standard business capability

FEA SA FSAM

Service Component Ref. Model Provides framework for

classifying service components according to how they support performance and business goals Defines the types and instances of

services required to support business processes

Gives a more IT view of systems that can support business functionality

Organized along horizontal service areas, independent of business function Provides foundation for reuse of

components▪ Component = self-contained business

process/service with predetermined functionality that may be exposed through a business or technology interface

Service domain e.g. Back Office Services

Service type e.g. Human Resources

Component e.g. Recruiting

FEA SA FSAM

Technical Reference Model Component-driven,

technical framework for categorizing the standards and technologies to support delivery of Service Components Identifies and describes

the technology (components, interfaces) used to support BRM

Defines technologies and standards that can be used in building IT systems.

Service area e.g. service access and delivery

Service category e.g. service transport

Service standard e.g. HTTP protocol

FEA SA FSAM

Data Reference Model Standards-based framework to

enable information sharing and reuse, via standardizing: Data description Data discovery, through viewing

data in context within a taxonomy Data sharing – access and

exchange Defines the concepts,

structures, values, enumerations required by the BRM in the context of the TRM Standardizes method of describing

data, e.g. defines an entity as something that contains attributes and participates in relationships

Facilitates inter-agency communication about data

Data sharing: query access,

exchange

Data context: taxonomies

Data description:

data and data assets

FEA SA FSAM

FEA success

Agencies are judged on: Architectural completion▪ Maturity of EA

Architectural use▪ How effectively the agency uses EA to drive

decision-making Architectural results▪ Benefits gained from using EA

FEA SA FSAM

FEA’s strengths and weaknesses Advantages:

Provides detailed transition process Designed to manage complexity of

enterprise Disadvantages

Not as useful as Zachman, taxonomy-wise

Still at a fairly high level

FEA SA FSAM

Going beyond FEA In Jan 2008, FSA Working Group within Architecture

and Infrastructure Committee was formed Wanted to leverage existing EA best practices to develop

a standard methodology for creating and using segment architectures (SA)

Developed FSAM: a step-by-step process influenced by EA best practices▪ FSAM contains simple templates that speed up SA development

and usage, and guided steps for developing SA▪ These steps are meant to help architects establish clear relationships

between goals, business requirements, info management requirements, and performance measures within each segment

▪ FSAM intended to be a scalable, repeatable process▪ Designed to allow segment-specific customization

FEA SA FSAM

Why think about segment architecture? FEA perspective of how EAs should be

viewed: the segment model An enterprise is made up of organizational units

called segments Segment = major LOB functionality, e.g. HR▪ Segment != individual agency

Segment = organizational unit for an EA▪ Not just related to technical implementation, but also

related to business architecture and data architecture Segments are defined globally, which facilitates

reuse across political boundaries e.g. across federal agencies

FEA SA FSAM

What is Segment Architecture? “Detailed results-oriented architecture (baseline and target) and a transition

strategy for a portion or segment of the enterprise.” -OMB

Two types of segments: Core mission-area segments

▪ Represents unique service area that defines/is central to the mission or purpose of the agency▪ E.g. for the Health and Human Services agency, “health” is a core mission-area segment▪ Other examples: tactical defense, air transportation, energy supply, pollution prevention

Business services segments▪ Areas that are foundational to most, if not all, (political) organizations/agencies within the overall

enterprise▪ Supporting core mission-area segments, at the level of individual agencies▪ Defined at the enterprise level i.e. overall government▪ Examples: financial management, HR

Above the individual segment level, there are “enterprise services” Includes common/shared IT services supporting core mission-area segments and business

services segments Spans across agency boundaries to encompass whole enterprise Only effective when functions at enterprise level, defined at enterprise level Examples: security management, business intelligence

FEA SA FSAM

SA exists at a level below EA

FEA SA FSAM

Segments across agencies

▪ Relationship of the 3 different segments across multiple agencies

FEA SA FSAM

Core segments are supported by business and enterprise services

FEA SA FSAM

Purpose of EA versus SA

ENTERPRISE ARCHITECTURE

Identifies common/shared assets Could be strategies, business

processes, investments, data, systems, technologies

Driven by strategy, helps agency identify whether its resources are aligned to its goals and mission

From investment perspective, drives decisions about the IT investment portfolio as a whole

SEGMENT ARCHITECTURE Defines roadmap for a core

mission area, business service or enterprise service

Driven by business management, delivers products that improve the delivery of services to citizens and agency staff.

From investment perspective, drives decisions for a business case or group of business cases supporting a core mission area or common or shared service.

FEA SA FSAM

SA takes its cues from EA Related to EA through 3 principles:

Structure▪ SA inherits FEA framework▪ May extend framework to meet custom needs of a core mission area

or shared service Reuse▪ SA reuses important assets defined at EA level▪ Data▪ Common business processes and investments▪ Applications and technologies

Alignment ▪ SA aligns with important elements defined at EA level▪ Business strategies▪ Mandates▪ Standards▪ Performance goals

FEA SA FSAM

Moving from EA to SA

FEA SA FSAM

Moving from EA to SA

Performance Improvement Lifecycle

FEA SA FSAM

What does SA achieve? Provides a detailed results-oriented architecture to agency

Typical SA will: Capture the segment-level change drivers Identify baseline and target performance Provide transition plan for segment toward target

Outcomes of a well-developed SA: Identifies opportunities to deliver business value, defines target performance

measures to monitor and demonstrate performance improvements Describes opportunities to reuse or provide common solutions

▪ Contributes to common understanding of what a segment does, and how the segment supports the agency’s goals

▪ Useful for cross-agency initiatives Approved in context of the agency’s EA Drives investment planning and allocation for core mission area or

common/shared service▪ Aligns with business resources

FEA SA FSAM

Use of SA in federal government Federal agencies are required to submit EA Segment Report to OMB

One report for each segment identified Quarterly updates Segment report contains:

▪ Identification of segment▪ Describe segment and its current state

▪ Mappings▪ Maps the segment to FEA and to investments, programs, and cross-agency initiatives

▪ Performance▪ Creates line of sight for segment performance▪ Includes any success stories attributed to segment architecture

▪ Transition planning▪ Provides segment transition milestones to track segment development

▪ Collaboration and reuse▪ Provides information on business, data, and information system sharing and reuse by the segment

and any partners/other stakeholders

Agencies have to align each IT investment to a primary segment, and optionally a secondary segment

FEA SA FSAM

Quick aside: solution architecture Defines agency IT assets

E.g. applications or components used to automate and improve individual agency business functions

Scope of solution architecture = single project Related to EA and SA through definitions and

constraints▪ E.g. SA provides definitions of data used within core

mission area, which are accessed by individual solutions

▪ Solution may be constrained to specific technologies/standards defined at EA level

FEA SA FSAM

High-level development of SA Architectural analysis

Define clear vision for segment, relate it to overall organizational plan

Architectural definition Define target state for SA and performance goals,

consider design alternatives, design SA Investment and funding strategy

Look for funding for the project Program-management plan, execute projects

Create plan for managing and executing project, including milestones and metrics

FEA SA FSAM

FSAM is a five-step recipe

FEA SA FSAM

Why should Enterprise Architects use the FSAM? Leverage FSAM for multiple segment architecture

development efforts Use FSAM as a consistent process to measure and

streamline their segment architecture development processes In many instances, segment architectures are developed using

different methods and techniques within the same enterprise FSAM will help Enterprise Architects maintain consistency in

approach for segment architecture development and use▪ Consistent approach within FSAM will help Enterprise Architects

reconcile the segments into an enterprise-wide view of the architecture Can leverage the FSAM's standard transition planning artifacts

to develop the Enterprise Transition Plan

FEA SA FSAM

Step 1: Determine participants and launch project Determine the executive sponsor – someone willing to

sponsor the segment transformation Active role in shaping direction of SA

Develop purpose statement for segment Communicate why we’re creating the SA▪ Establish why SA is important and our goals for SA

Solicit core team members Subject matter experts from the relevant organizations affected by

SA Want competent people to develop actionable SA

Create core team charter and project plan State roles, roster, project scope, decision-making structure Begin with common intentions, common expectations

Establish communication strategy Identify audience, select communication media

FEA SA FSAM

Step 2: define segment scope and strategic intent Establish segment scope and context

High-level identification of segment stakeholders, business domains, mission-area services, etc.

Create segment summary description▪ Include overview of security/privacy requirements and drivers for

the segment Identify and prioritize strategic improvement

opportunities Identify stakeholder needs, segment risks, performance

gaps Define segment strategic intent

Review improvement opportunities, clarify target outcomes, establish performance scorecard

Validate and communicate scope and strategic intentFEA SA FSA

M

Step 3: define business and information requirements Determine current environment associated with

strategic improvement opportunities Identify the portions of current business requirements that are

relevant to improvement opportunities identified in step 2 Determine business and information improvement

opportunities Align strategic improvement opportunities to business and

data architecture, identify adjustments needed Define target optimal business and data architecture

Includes business processes, data relationships, data stewards

Validate and communicate target business and data architectures

FEA SA FSAM

Step 4: define conceptual solution architecture Conceptual solution architecture (!= Solution Architecture):

This defines segment systems and services (e.g., business and data exchange)

Including supporting technical and service components used to automate and improve business functions within a segment▪ Specification of components should be vendor-agnostic as much as possible

Assess systems and technology environment for how well they support performance, business, and data requirements Define the currently existing conceptual solution architecture, check for

necessary adjustments needed Define target conceptual solution architecture

Emphasis should be on reuse opportunities Identify and analyze system and service transition

dependencies, risks, potential issues Look for possible alternative transition options

Validate and communicate conceptual solution architectureFEA SA FSA

M

Step 5: author the modernization blueprint Analyze each transition option to determine

costs, benefits, risks Develop implementation recommendations

Develop draft blueprint and sequencing plan Draft blueprint = summary of results from business

analysis, strategy▪ Provides overview of target data, services, technology

environment, transition option analysis, implementation recommendations

Implementation sequencing plan = info on timing and dependencies of the work breakdown

Review, finalize, obtain core team approvalFEA SA FSA

M

Conclusion

FSAM is a useful addition to FEA FSAM provides concrete guidelines for

creating segment architecture Emphasis on communication at each

step means that results of an agency’s SA creation can be learned from and reproduced by other agencies

References http://www.whitehouse.gov/sites/default/files/omb/assets

/fea_docs/FEA_CRM_v23_Final_Oct_2007_Revised.pdf

http://www.whitehouse.gov/sites/default/files/omb/assets/fea_docs/FEA_Practice_Guidance_Nov_2007.pdf

http://www.whitehouse.gov/sites/default/files/omb/assets/fea_docs/FY10_Ref_Model_Mapping_QuickGuide_Aug_2008_Revised1.pdf

http://www.fsam.gov/about-federal-segment-architecture-methodology.php

http://www.cio.gov/Documents/FSAMv1.pdf

http://www.fsam.gov/federal-segment-architecture-methodology-toolkit/step1.php