Post on 25-Feb-2016
description
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