CSPP 51075 Spring 2011 FEA and FSAM

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?

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

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

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

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

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

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

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

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

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