The goal of the FEA Practice Guidance is to provide Value to the Mission by increasing the value of architecture activities to improve results in agency mission areas. The guidance is not meant to be prescriptive, but offer concepts to be applied using a variety of architectural frameworks and methodologies. The guidance does not cover EA development and maintenance since there is already a broad body of knowledge on these topics. Two primary concepts are described: Enterprise architecture (EA) transition strategy - describes the overall plan for an agency to achieve its target architecture. Segment architecture - provides detailed results-oriented architecture and a transition strategy for a portion or segment of the enterprise.
Currently, There are four documents included in the FEA Practice Guidance: Chapter 1 – Introduction: Provides an overview of the concepts described in the other guidance documents. This is the first document you should read. Chapter 2 – Enterprise Architecture Transition Strategy Guidance: Describes what is included in an EA transition strategy and provides guidance on developing and using an EA transition strategy. Chapter 3 – Introducing Segment Architecture: Describes segment architecture concepts, the content included in segment architecture, and how to use segment architecture. Chapter 4 – Developing Segment Architecture ( planned ): Provides guidance on how to develop segment architecture, when one should be developed, and who should participate in its development. EA terms and concepts in the FEA Practice Guidance documents are defined in the Key Terms section of Chapter 1. The guidance documents also reference additional information about the concepts being described. These references are included at the end of each chapter.
Chapter 1 is the introduction and provides an overview of the concepts described in the other guidance documents. This is the first document you should read. This chapter provides an overview of the architectural concepts described in detail in the other FEA Practice Guidance documents. It is written for a general audience that may not be familiar with many enterprise architecture concepts. The opening section, Delivering Mission Value , provides the reason for developing the FEA Practice Guidance. The Principles section describes the foundational principles underpinning the guidance. The Performance Improvement Lifecycle section describes the three major lifecycle phases of IT management. The Architectural Levels section identifies and describes the relationships among the various levels of architecture activities within an agency. The Key Terms section provides definitions for the terms used throughout the guidance.
The three-phase Performance Improvement Lifecycle: “Architect”, “Invest”, and “Implement” is a process agencies can use to close performance gaps and improve the overall performance of the enterprise. Each lifecycle phase is comprised of multiple processes which are tightly integrated. The phases combine to transform the agency’s top-down strategic goals and bottom-up system needs into a logical series of work products designed to help the agency achieve strategic results. When working effectively and integrated well, the performance improvement lifecycle provides the foundation for sound IT management practices, end-to-end governance of IT investments, and the alignment of IT investments with an agency’s strategic goals so an agency can achieve its desired mission outcomes and business results. Architecture activities occur at different levels within an agency, including at the enterprise level (enterprise architecture) and the segment level (segment architecture). Agencies can also develop individual solution architectures for IT systems supporting a segment. Architecture at one level is used to guide and inform architecture activities at levels below it (e.g., segment architecture to solution architecture) and is reconciled to the architecture at the level above it (e.g., segment architecture to enterprise architecture). Architectural levels differ in their scope, level of detail, impact, and intended audience. For example, an agency’s enterprise architecture is designed to provide an architectural view of the entire agency. However, a segment architecture is focused on an individual line of business and provides more detail for the line of business than the agency’s enterprise architecture.
Chapter 2 describes how to develop and use an enterprise architecture (EA) transition strategy to drive agency investment planning to achieve mission objectives and business results. The EA transition strategy includes segment architectures, agency programs and related performance measures in a coordinated, multi-year plan to achieve mission objectives. The benefits to agency architectures are a more coherent and coordinated strategy to achieve the target architecture, and an organized approach for tracking progress across multiple programs, organizational units, and segment architectures. Agency enterprise architects should engage with agency business owners to ensure the EA program meets their needs and is focused on the priorities of the business. The agency EA program should not be focused on exhaustive modeling of the existing state of the EA – it should be focused on the “pain points” facing the business owners, and on meeting those needs using the target architecture and transition strategy.
First, we start with a current (or baseline) segment EA [Mouse Click] Then we define the target EA with segments [Mouse Click] In order to define how we get from the current to the target we put in place a Transition Strategy [Mouse Click] What does a Transition strategy contain? It describes the process and overall plan for an organization to achieve its Target EA Contains defined programs and projects Links agency investments to target architecture. Defines an enterprise sequencing plan – demonstrating the logical dependencies between transition activities (programs and projects) [Mouse Click] Lastly, we have interim Target Architectures as progress is made from the current to the target
Chapter 3 provides introductory-level guidance to develop and use segment architecture for core mission areas and common services defined by agency EA and the EA transition strategy. Segment architecture development is a scalable and repeatable process for architects to engage business stakeholders and deliver value to business areas. This process helps to establish clear relationships between strategic goals, detailed business and information management requirements and measurable performance improvements. Information and guidance are provided for the following topic areas: Segment Architecture Concepts: Provides a definition and overview of segments and segment architecture including a description of segment architecture work products and the architectural development process. Segment Identification and Integration: Describes the process to define enterprise segments and the relationship to EA and the EA transition strategy. Outlines segment types and the relationship between individual segment types Initiating Segment Architecture: Describes the series of steps architects can use to identify segments and initiate segment architecture development. Applying Segment Architecture: Describes common uses for segment architecture across each phase of the Performance Improvement Lifecycle – architect, invest, and implement . Describes agency-level and government-wide benefits resulting from segment architecture development and implementation.
Enterprise segments are identified during the development of the agency EA and EA transition strategy. Segments are individual elements in the enterprise transition strategy describing core mission areas, and common or shared services. Segment identification is a continuous, iterative process. Enterprise assets including systems and IT investments are mapped to the agency-level reference models to create a segment-oriented view of the enterprise.
Segment architecture provides detailed results-oriented architecture and a transition strategy for a portion or segment of the enterprise. Segments are individual building blocks in the transition strategy describing core mission areas, and common or shared services. Segments are identified by the agency EA and EA transition strategy. There are three types of segments: Core Mission Area: Unique service areas defining the mission or purpose of the agency. Core mission areas are defined in the agency Business Model. Business Service: Common or shared business service supporting a core mission area. Business services are defined in the agency Business Model and include the processes and back office services used to achieve the purpose of the agency. Enterprise Service: Common or shared IT service supports core mission areas and business services. Enterprise services are defined by the agency Service Model and include the applications and service components used to achieve the purpose of the agency.
Chapter 4 is planned and currently in development. It will provide guidance on how to develop segment architecture, when one should be developed, and who should participate in the development.
This shows an organizational structure with the following information. Top level: CIO Council Next level: OMB and Federal Enterprise Architecture Program Management Office – Dick Burk 202.395.0375 On same level: Architecture and Infrastructure Committee (AIC) Charlie Havekost 202.690.6162 and Lisa Schlosser 202.708.0306 Connected to the AIC are two advisory subgroup. One is Advisory: Industry Community and Standards Bodies and the second is Advisory Board – Chief Architecture Forum (CAF) Ira Grossman 301.713.3345 ext. 140 Lowest level has 4 subcommittees; Emerging Technology , Data Architecture , Governance and Service . More on each of these on the following pages.
This is just another depiction of where HUD is right now in the process of moving to a more SOA (service oriented architecture) based environment. HUD’s systems used to be created and managed along organizational lines Vision 2010 takes an enterprise approach and aligns systems into HUD’s Lines of Businesses (LOB). Functional is migrated from existing applications into reusable business functions available across LOBs and throughout the HUD enterprise. Future applications can be assembled from common business functions and reusable Core IT Services.
HUD is taking a short and long term strategy in the move to SOA. Our business drivers, as mentioned earlier, are to meet business requirements by providing better, faster and cheaper system development. Transition includes moving chunks of functionality into services accessible to multiple applications via en enterprise service bus (middleware – IBM Websphere, BEA Weblogic, etc). Current services include inspections, earned income verification (EIV), Geocoding, Document/Records/Workflow reuse. Vision 2010 – HUD’s Target Architecture Eventually, we will move to an entire platform of shared services . A “solution stack”. Development environment – web-centric, standard platform, supports assembly and integration rather than custom development. Business Intelligence, GIS – reusable capabilities ESB and Event Mediator – Middleware/glue/communication mechanisms COTS Apps - make use of COTS at the enterprise level , ex. Documentum E-Government Services – leverage E-Gov services in the enterprise platform, where appropriate.
One of the quick hit successes, and really a critical success factor, is consolidating core infrastructure functions into a commodity type service that allows for new business applications, particularly COTS solutions, to be deployed rapidly. This allows reuse of the infrastructure for multiple services. CTS was an early Move to SOA and one of the first systems deployed as part of Vision 2010: 1) Recognized common enterprise business process of document management and workflow. Several systems had custom implementations of document management, workflow and records management. 2) Doc Mgmt, Rec Mgmt, Doc Workflow were generic enough to buy as enterprise, COTS components and implement quickly . By doing so, HUD achieved a quick SOA win by buying pre-built service that replaced a set of legacy systems . New systems will integrate with new CTS system for its doc mgmt and workflow capabilities rather than provide their own. 3) Provide a common document management infrastructure platform for other HUD operations. E-Case Binder has leveraged the CTS infrastructure to also support external business partners by providing multiple views of E-Case information. CTS is an enterprise information management system that will optimize the Department's management and tracking of all HUD's correspondence in the Headquarters and the Field Offices. It is one of the first state-of-the-art systems to be implemented across HUD as part of VISION 2010 : HUD's Information Technology Modernization Strategy. CTS is being piloted at Headquarters in the Office of the Executive Secretariat. The full migration of HUD's correspondence tracking from the legacy systems to CTS will be completed by the first quarter of Fiscal Year (FY) 07. CTS allow the Department to retire its legacy Automated Correspondence On-Line Response Network System (ACORN), Correspondence Management System (CMS), and FOIA Management System (FMS).
Client Issue: What trends are leading to dramatic change in the infrastructure? An RTE is a business that senses opportunities and problems faster, and responds to them faster and more precisely. It has flexible business processes and can establish and de-establish business (and customer) relationships opportunistically and quickly. Also, it competes by progressively removing slack in executing its critical business processes (internally and with customers and suppliers). Examples include reducing the slack time to clear stock trades, and enabling shipments of goods to customers within minutes of approved orders. An IT infrastructure that is inflexible, isn't able to grow and contract incrementally, doesn't respond to rapidly changing requirements and doesn't deliver to business-oriented service levels is a critical inhibitor to any company pursuing a real-time strategy. Traditionally, IT has been viewed as a cost center — a tool for improving productivity. However, for an RTE, IT must be seen as one of many investments that can improve business speed and, therefore, business opportunity. A real-time infrastructure (RTI) doesn't just make the business do things faster, it enables business growth. This change in business-IT philosophy is a cornerstone of the change required to become an RTE. For an RTE, IT must be able to respond faster to dynamically changing business needs. Return on business investment is critical. Therefore, an architecture must be developed that enables ongoing dynamic change, dynamic scalability and dynamically achievable service levels.
CORE.gov began operation in March 2004. It provides a collaboration environment for component development, registration and reuse. HUD uses CORE.gov to participate in cross-agency collaboration, transformation and government-wide improvement in planning, designing and implementing SOA solutions .
This slide shows how the Federal Railroad Administration aligns their various lines of business. The over arching framework is the OMB Enterprise Architecture over the Department of Transportation’s EA Policy Federated Model. Each business line fits into other initiatives, common operating architecture and common access architecture.
This slide shows how there is a pyramid of starting at the top with strategic goals, then business processes, then Information and Data Flow, then Systems Applications and then Technology Infrastructure. This integrated Governance model comes out of the FRE EA Framework and captures the modernization blue print, capital planning and budgeting, Human Capital Profile, Security profile, Financial Management and Administration, Chief Counsel, Civil Rights, Policy, Public Affairs, Railroad Development and Safety.
One example of solving a business problem was establishing the Mobile Workforce Initiative. Railroad Inspectors have specific needs, like rugged laptops, portable printers, PDA and Bio Metric USB drives. They all need to be able to communication with HQ and many regional offices. There’s RAS, VPN, DSL, and the internet. The challenge is to make sure that all of the connectivity options are understood and integrated.
Slide 1 - Chief Information Officers Council
IT Summit Conference October 4, 2006 Panel on Using Enterprise Architecture to Solve Business Problems Dick Burk Chief Architect and Manager, Federal EA Program Office of Management and Budget Lisa Schlosser CIO, Department of Housing and Urban Development Scott Bernard Deputy CIO, Federal Railroad Administration For slide details go to “notes”
Value to the Mission FEA Practice Guidance September 28, 2006 Dick Burk Chief Architect and Manager, Federal Enterprise Architecture Program, OMB
<ul><li>Value to the Mission –Increase the value of architecture activities to improve results in agency mission areas. </li></ul><ul><li>Two primary concepts described in the FEA Practice Guidance </li></ul><ul><ul><li>Enterprise Architecture (EA) Transition Strategy </li></ul></ul><ul><ul><li>Segment Architecture </li></ul></ul>FEA Practice Guidance
<ul><li>Currently based on four chapters </li></ul><ul><ul><li>Chapter 1 – Introduction </li></ul></ul><ul><ul><li>Chapter 2 – EA Transition Strategy </li></ul></ul><ul><ul><li>Chapter 3 – Introducing Segment Architecture </li></ul></ul><ul><ul><li>Chapter 4 – Developing Segment Architecture </li></ul></ul><ul><li>Additional chapters to be determined </li></ul>Structure
<ul><li>Provides an overview of the concepts described in the other guidance documents. </li></ul><ul><li>Chapter 1 sections </li></ul><ul><ul><li>Delivering Mission Value </li></ul></ul><ul><ul><li>Principles </li></ul></ul><ul><ul><li>Performance Improvement Lifecycle </li></ul></ul><ul><ul><li>Architecture Levels </li></ul></ul><ul><ul><li>Key terms </li></ul></ul>Chapter 1 – Introduction
<ul><li>Describes what is included in an EA transition strategy and provides guidance on developing and using an EA transition strategy. </li></ul><ul><li>Chapter 2 sections: </li></ul><ul><ul><li>Transition Strategy Concepts </li></ul></ul><ul><ul><li>Developing the Transition Strategy </li></ul></ul><ul><ul><li>Using the Transition Strategy </li></ul></ul>Chapter 2 – EA Transition Strategy
<ul><li>Describes segment architecture concepts, the content included in segment architecture, and how to use segment architecture. </li></ul><ul><li>Chapter 3 sections </li></ul><ul><ul><li>Segment Architecture Concepts </li></ul></ul><ul><ul><li>Segment Identification and Integration </li></ul></ul><ul><ul><li>Initiating Segment Architecture </li></ul></ul><ul><ul><li>Applying Segment Architecture </li></ul></ul>Chapter 3 – Introducing Segment Architecture
<ul><li>Core Mission Area </li></ul><ul><ul><li>Unique service area defining the mission or purpose of the agency </li></ul></ul><ul><ul><li>Core mission areas are defined in the agency Business Model. </li></ul></ul><ul><li>Business Service: </li></ul><ul><ul><li>Common or shared business service supporting a core mission area. </li></ul></ul><ul><ul><li>Business services are defined in the agency Business Model and include the processes and back office services used to achieve the purpose of the agency. </li></ul></ul><ul><li>Enterprise Service: </li></ul><ul><ul><li>Common or shared IT service supporting core mission areas and business services. </li></ul></ul><ul><ul><li>Enterprise services are defined in the agency Service Model and include the applications and service components used to achieve the purpose of the agency. </li></ul></ul>Three Types of Segments
<ul><li>Planned – In Development </li></ul><ul><li>Will provide guidance on how to develop segment architecture, when one should be developed, and who should participate in the development. </li></ul>Chapter 4 – Developing Segment Architecture
Federal CIO Council Architecture & Infrastructure Committee (AIC) Lisa Schlosser Co-Chairperson
AIC Vision <ul><li>In 2006-2007, the AIC will implement projects that support and demonstrate the ability of the CIO Council to effectively architect, invest, and implement solutions to improve the performance of government. Results will be documented as demonstrated by improved performance in terms of both mission outcomes and operational efficiency. </li></ul>
Emerging Technology Subcommittee Tuning ET Together - From Stovepipes to Wind Chimes <ul><li>Purpose: This subcommittee provides an “incubator” organizing process to accelerate discovery, maturation, and validation of capabilities that leverage FEA principles and priorities. The key components of our charter are: </li></ul><ul><ul><li>Greater foresight and discernment as established and emerging technologies compete and converge </li></ul></ul><ul><ul><li>Longer life-cycles through market-based, open standards technologies </li></ul></ul><ul><ul><li>Common understanding of business scenarios to anticipate performance outcomes and mitigate risks. </li></ul></ul><ul><li>Participation in this subcommittee will help you improve your agencies’ strategic foresight and collaboration capacity around strategic IT assets. </li></ul>Key FY06/FY07 Activities/Deliverables 1. Forging effective IPv6 strategies together (example in FY06) 2. Life-cycle process for ET discovery and collaborative action 3. Strategic Dialogue Among Communities at Open Forums - Expedition Workshops Co-Chair Contact Information 301-358-1802 202-501-6214 [email_address] [email_address] John McManus Susan Turnbull
Data Architecture Subcommittee (DAS) Build to Share Purpose: To advances the management of Federal data as a national asset; stewardship of the Federal Enterprise Architecture (FEA) Data Reference Model (DRM), FEA DRM Management Strategy; to promote the use and improvement of data and data standards across the Federal Government; to facilitate of community collaboration and information sharing using communities of interests, both federal and intergovernmental. Key FY06/FY07 Activities/Deliverables 1. FEA DRM updates and revisions 2. Implementation strategies, best practices, and success stories 3. Establish an authoritative knowledge center for Federal data-related issues and opportunities Co-Chair Contact Information 703-874-8501 202-208-3216 [email_address] [email_address] Bryan Aucoin Suzanne Acar
Governance Subcommittee Governance for a Transformed Government Purpose: This subcommittee provides policy guidance, and advice and assistance in the definition, design and implementation of Enterprise Architecture (EA) discipline and practice throughout the Federal government. It serves as the core Federal group providing advocacy for EA integration of business and technology architectures across, state, local and international boundaries. The Governance Subcommittee serves as a focal point for the development and coordination of Federal government-wide policy, guidance, including best practices for EA development and implementation. Participation in this subcommittee will provide an opportunity to gain experience in applying the reference models to improve efficiency and effectiveness within your agency. <ul><li>Key FY06/FY07 Activities/Deliverables </li></ul><ul><li>RMMP/Consolidated FEA RM </li></ul><ul><li>EGIF/ Awareness /Paper SOA State of Practice </li></ul><ul><li>Transformative Governance Models and Best </li></ul><ul><li>Practices for eGov Shared Services (January 2007) </li></ul>Co-Chair Contact Information 703-292-5319 703-380-0964 [email_address] [email_address] Andrea Norris Roy Mabry
Services Subcommittee Enabling Shared Services Purpose: Enable Shared Services through development of a Shared Services Strategy, a roadmap for CORE.gov, and a set of demonstration projects focused on Information Exchange and other integration concerns with Shared (LoB) Solution and composite applications. <ul><li>Key FY06/FY07 Activities/Deliverables </li></ul><ul><li>Shared services management strategy including management framework and policy maturity model. </li></ul><ul><li>User and strategy driven CORE.gov tools, product roadmap, and solution architecture </li></ul><ul><li>Shared Services demonstration leveraging participant capabilities </li></ul>Co-Chair Contact Information 202.305.5128 202.219.1979 [email_address] [email_address] Kshemendra (Indra) Paul George Thomas
The SOA Vision Program Orientation : Transaction focused with data rich solutions tailored to support specific program business requirements. Program Offices Applications/Business Processes Modernization Enterprise Integration : IT solutions support strategic LOBs. IT modernization promotes re-use though the automation of common business functions and core IT services. LOB Business Function Core IT Service Enterprise LOB
<ul><li>Promotes accessible and flexible platforms for enhanced collaboration and knowledge sharing. </li></ul><ul><li>Supports SOA by providing space to develop and blend business and IT strategy on a controlled environment. </li></ul><ul><li>Ensures cost effective methods of identifying and optimizing government business processes that can be shared and modified to meet specific agency needs. Enables secure and cost effective methods to develop government business processes across multiple agencies </li></ul><ul><li>Promotes the participation of SOA activity with increased ease of participation. </li></ul><ul><li>Provides a well managed environment with several tools that employ capability to find, evaluate, share and download information that is essential to the development of services and lines of business. </li></ul>CORE.gov: Helping Advance EA in Government
AIC Next Steps <ul><li>Requesting representatives to serve on all committees; please send interested names to Stephanie Powers at [email_address] by May 31st </li></ul><ul><li>Each subcommittee will convene over year to solicit participation in producing the deliverables laid out in this presentation </li></ul>
Federal Railroad Administration U.S. Department of Transportation Case Study in Using Enterprise Architecture to Solve Business Problems The Mobile Workforce Initiative Scott A. Bernard, PhD Deputy Chief Information Officer Chief Architect [email_address]
About FRA FRA is one of eleven modal administrations in the Department of Transportation. The mission of FRA is to promulgate and enforce rail safety regulations; administer railroad assistance programs; conduct research and development in support of improved railroad safety and national rail transportation policy; provide for the rehabilitation of Northeast Corridor rail passenger service; and consolidate government support of rail transportation activities. Locations: Headquarters : Washington, DC 8 Regional Offices : Atlanta, Boston, Chicago, Dallas, Kansas City, Philadelphia, Portland, Sacramento Workforce: Approximately 840, over half are field safety inspectors . Lines of Business : Office of the Administrator/Deputy Administrator Office of Financial Management and Administration Office of the Chief Counsel Office of Civil Rights Office of Railroad Development Office of Policy Office of Public Affairs Office of Safety
<ul><li>FRA has aligned IT resources to the standards of the DOT Common Operating Environment (COE). </li></ul><ul><li>Cross-cutting and modal-specific applications will be hosted in one data center at the new DOT HQ in 2007. </li></ul><ul><li>Standards for mobile computing and communications are still emerging. </li></ul>FRA is taking responsibility for its part of the DOT EA DOT “Federated” Approach to EA RITA
Business Problem: Many of FRA’s Railroad Safety Inspectors have difficulty gaining and maintaining mobile communications and computing links in the field and at hotels. Lots of gaps in coverage, slow dial-up connections. Technology Issues: - Lack of agency/department standards for mobile communications. - Lack of agency/department standards for mobile computing. - Variety of communications and computing equipment in use. - Variety of dial-up, VPN, DSL remote data access solutions in use. - Lack of effective Tier 1 and Tier 2 assistance in trouble shooting. Architecture Solution: (Working with DOT CTO) PRM: Identify mobile computing line-of sight process, establish metrics. BRM: No change in mission area, function, sub-functions. SRM: Establish a mobile workforce business service that is co-sponsored by the Office of Financial Mgmt. & Admin. and the Office of Safety. DRM: Identify data exchange requirements and standards. TRM: Establish new standards for mobile communications & computing. SPP: Identify data protection solutions for PII data and mobile equipment.
Solving the Business Problem Establish the Mobile Workforce Initiative (MWI) to provide railroad field inspectors and other mobile users with standard computing and computing equipment and broadband service packages. Encrypted & Rugged Laptop PDA & Biometric USB Drive Portable Printer & Scanner Railroad Inspector Connectivity Options Internet RAS Broadband Cellular VPN Standard Equipment HQ Regional Offices DSL
<ul><li>MWI Deployment Timeframe: </li></ul><ul><li>FY 2007 / Q1 </li></ul><ul><li>Expected Outcomes of MWI: </li></ul><ul><li>Improved work productivity in the field </li></ul><ul><li>Improved work productivity at hotels </li></ul><ul><li>More mission capability </li></ul><ul><li>Quicker deployment of applications/updates to field inspectors </li></ul><ul><li>Improved telecommuter support </li></ul><ul><li>Improved Continuity of Operation capabilities </li></ul><ul><li>Improved security for mobile computing </li></ul><ul><li>More collaboration between CIO and Lines of Business </li></ul><ul><li>More agency/headquarters collaboration on standards </li></ul><ul><li>More awareness of and support for FRA and DOT architectures </li></ul>