FEA and FSAM

1. CSPP 51075 Spring 2011 FEA and FSAM

2. 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?

3. A Brief History of FEA Responsibility for FEAF moves to the Office of Management and Budget 2011? • 1987: Zachman publishes "A Framework for Information Systems Architecture"

4. Who manages FEA?

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

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

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

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

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

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

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

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

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

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

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

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

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

18. SA exists at a level below EA

19. Segments across agencies • Relationship of the 3 different segments across multiple agencies

20. Core segments are supported by business and enterprise services

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

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

23. Moving from EA to SA

24. Moving from EA to SA Performance Improvement Lifecycle

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

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

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

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

29. FSAM is a five-step recipe

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

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

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

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

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

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

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