1. CSPP Spring 2011
FEA and FSAM

2. Contents FEA refresher Federal segment architecture methodology (FSAM)
Overview
Background
Five Reference Models
Federal segment architecture methodology (FSAM)
What is segment architecture?
How is FSAM related to FEA?
What is it for?

3. A Brief History of FEA 2011? FEA SA FSAM
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 :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
Responsibility for FEAF moves to the Office of Management and Budget
2011?
1987: Zachman publishes "A Framework for Information Systems Architecture"
FEA SA
FSAM

4. Who manages FEA? Federal Government Office of Management and Budget
Office of E-Government and IT
FEA Program Management Office
General Services Administration
Federal CIO Council
(et cetera)
FEA SA
FSAM

5. 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

6. What is FEA? Five interrelated reference models Three general profiles
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

7. 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 governed
FEA SA
FSAM

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. SA exists at a level below EA
FEA SA
FSAM

19. Segments across agencies
Relationship of the 3 different segments across multiple agencies
FEA SA
FSAM

20. Core segments are supported by business and enterprise services
FEA SA
FSAM

21. Purpose of EA versus SA Enterprise Architecture Segment 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
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

22. 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

23. Moving from EA to SA
FEA SA
FSAM

24. Moving from EA to SA
Performance Improvement Lifecycle
FEA SA
FSAM

25. 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

26. 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

27. 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

28. 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

29. FSAM is a five-step recipe
FEA SA
FSAM

30. 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

31. 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

32. 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 intent
FEA SA
FSAM

33. 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

34. 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 architecture
FEA SA
FSAM

35. 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 approval
FEA SA
FSAM

36. 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

37. References