cspp 51075 spring 2011 n.
Skip this Video
Loading SlideShow in 5 Seconds..
FEA and FSAM PowerPoint Presentation
Download Presentation

Loading in 2 Seconds...

play fullscreen
1 / 37

FEA and FSAM - PowerPoint PPT Presentation

  • Uploaded on

CSPP 51075 Spring 2011. FEA and FSAM. 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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'FEA and FSAM' - haracha

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
  • 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
A Brief History of FEA

Responsibility for FEAF moves to the Office of Management and Budget


  • 1987: Zachman publishes "A Framework for Information Systems Architecture"
how did fea come about
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 executiveagencies 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
what is fea
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
five reference models
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
performance reference model
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
business reference model
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
service component ref model
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
technical reference model
TechnicalReference 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.
data reference model
DataReference 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
fea success
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 s strengths and weaknesses
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
going beyond fea
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
why think about segment architecture
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
what is segment architecture
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
segments across agencies
Segments across agencies
  • Relationship of the 3 different segments across multiple agencies
purpose of ea versus sa
Purpose of EA versus SA

Enterprise Architecture

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.

  • 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
sa takes its cues from ea
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
moving from ea to sa1
Moving from EA to SA

Performance Improvement Lifecycle

what does sa achieve
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
use of sa in federal government
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
quick aside solution architecture
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
high level development of sa
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
why should enterprise architects use the 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
step 1 determine participants and launch project
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
step 2 define segment scope and strategic intent
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
step 3 define business and information requirements
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
step 4 define conceptual solution architecture
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
step 5 author the modernization blueprint
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
  • 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
  • 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