Presentation is loading. Please wait.

Presentation is loading. Please wait.

Architecture and Infrastructure Committee (AIC) Briefing to FOSE 2003 April 9, 2003.

Similar presentations


Presentation on theme: "Architecture and Infrastructure Committee (AIC) Briefing to FOSE 2003 April 9, 2003."— Presentation transcript:

1 Architecture and Infrastructure Committee (AIC) Briefing to FOSE 2003 April 9, 2003

2 Page 2 AIC Objectives Integrate OMB and CIOC Architecture Efforts Develop (simpler) and Consistent Taxonomy and Terminology Facilitate Cross-agency efforts: common meta data, tools Oversee “ operationalization ” of architecture efforts A new subcommittee structure was developed to support these objectives

3 Page 3 New AIC Structure Move from ad hoc efforts to priority and schedule-driven efforts with committed staff Governance John Przysucha, DOE Bob Haycock, FEAPMO Components Reynolds Cahoon, NARA Bob Haycock, FEAPMO Working Groups XML - Marion Royal, GSA; Owen Ambur, DOI Universal Access - Susan Turnbull, GSA XML Web Services - Brand Niemann, EPA PKI - Judith Spencer, GSA AIC Laura Callahan, DHS John Gilligan, USAF Norm Lorentz, OMB Emerging Tech. Dawn Meyerriecks, DISA Mark Day, EPA

4 Page 4 CIO Council has established expectations for federal agency participation in AIC Agencies have begun designating senior-level representatives to the Governance and Components Subcommittees (25% time commitment per subcommittee). Volunteers have begun populating the Emerging Technology Subcommittee and its ongoing working groups. Subcommittee participation contributes to executive development objectives of CIOC. AIC products will benefit all agencies and accelerate achievement of CIOC goals

5 Page 5 Enterprise Architecture Governance Subcommittee Leadership – John Przysucha, DOE; Bob Haycock, OMB Subcommittee Mission: Develop policy, direction and guidance by which the Federal Enterprise Architecture (FEA) is a driver of business process improvement, investment management, and technical decisions in order to institutionalize the FEA throughout Government Assist in implementing the FEA and other Enterprise Architectures (EAs) throughout Government Three Subcommittee Goals: 1.Integrate EA into the Government ’ s management processes 2.Define the alignment of department/agency EAs with the FEA 3.Describe how the FEA will facilitate the connection of State and Local EAs to Federal business lines and agency architectures Recent Progress: Subcommittee members selected and subcommittee activated FY 2003 work plan completed

6 Page 6 Enterprise Architecture Governance Subcommittee Tasks Develop FEA Principles Integrate EA into the Capital Planning and Investment Control Process Integrate EA into the Strategic Management and Budget Formulation/Execution Processes Integrate EA into the Project Management, Workforce Planning and Security Management Processes Determine the major EA frameworks used by Federal agencies Analyze how agencies align with the emerging FEA Propose a federated FEA model that complements agency EAs Develop a Government Enterprise Architecture Framework Conduct a Joint Architecture Integration Pilot Conduct a Joint Component Directory/Repository Pilot Develop a Joint Government Data and Information Reference Model Identify new approaches to Joint Enterprise Software Licensing Conduct expanded Joint Architecture Integration Pilots Goal 1: Integrate EA into the Government ’ s Management processes Goal 2: Define alignment of department/ agency EAs with FEA Goal 3: Describe how the FEA will facilitate the connection of State and Local EAs to Federal business lines and agency architectures Mission-related

7 Page 7 Leadership – Reynolds Cahoon, NARA; Bob Haycock, OMB Draft Subcommittee Mission: Foster the identification, maturation, and re-use of enterprise architecture components and component-based enterprise architectures in Government Draft Subcommittee Goal: Facilitate cross-Agency development and implementation of enterprise architecture components Recent Progress: Subcommittee members selected and subcommittee activated FY 2003 workplan completed; four tasks identified:  Develop a Components Based Architecture White Paper  Develop a Components Registry/Repository Concept Paper  Develop a Solution Development Life Cycle  Develop and Market Quick Win An Enterprise Architecture Component is defined as "a self contained business process or service with predetermined functionality that may be exposed through a business or technology interface." Components Subcommittee

8 Page 8 Emerging Technology Leadership – Mark Day, EPA; Dawn Meyerriecks, DISA Goal – Coordinate and guide technology tracking efforts of the federal government. Accelerate the implementation of commercially-developed technology resolving common challenges Initial Objectives To provide a clearinghouse function between industry and agencies To help discover and close technological gaps in the federal business and technology infrastructure Recent progress Activation of the subcommittee Development if initial draft 2003 work plan

9 Page 9 Opportunities for Public-Private Interactions Inherently Governmental Functions Architecture and Infrastructure Committee Interrelationships Industry Emerging Technology Components SRM TRM DRM Governance PRM BRM Component Voids Candidate Components Priorities Policy Recommendations

10 Page 10 FEA - Program Management Office Reference Model Release Schedule ModelVersion Federal Review General Release PRM1.0Mid-AprilEarly May BRM2.0February 28 th Mid-April SRM1.0January 29 th Mid-April DRM1.0TBD TRM1.0January 29 th Mid-April Performance Reference Model Business Reference Model Service Component Reference Model Data and Information Reference Model Technical Reference Model

11 Page 11 Services for Citizens Mode of Delivery Support Delivery of Services Management of Government Resources Legislative Relations Public Affairs Regulatory Creation Planning and Resource Allocation Controls and Oversight Revenue Collection Internal Risk Mgmt and Mitigation Government Service Delivery Direct Services for Citizens Knowledge Creation Public Goods Creation and Mgmt Regulated Activity Management Financial Vehicles Federal Financial Assistance Credit and Insurance Financial Transfers to States Financial Management Human Resource Management Supply Chain Management Administrative Management Information and Technology Management Defense and National Security Homeland Security Intelligence Operations Law Enforcement International Affairs and Commerce Litigation and Judicial Activities Correctional Activities Environmental Management Natural Resources Disaster Management Community and Social Services Economic Development Income Security Workforce Management Education Energy Health Transportation General Government Development of the Draft BRM, Version 2.0 is nearing completion DRAFT Business Reference Model, Version 2.0

12 Page 12 The Draft BRM, Version 2.0 aligns with three critical management frameworks / improvement initiatives The President ’ s Budget and Performance Integration Initiative and the FEA Performance Reference Model The revised model differentiates between the purpose of the government and mechanism/process used to deliver services to the customer This distinction aligns with the Performance Reference Model ’ s focus on outcomes (purpose of government) and outputs (mechanism/process) OMB ’ s Budget Function Classifications These classifications provide a similar functional description of Federal activities JFMIP ’ s New Framework for Financial Management Systems Within the revised BRM, financial management is an element of the Lines of Business and Sub-functions throughout the four Business Areas The core processes of financial management - as defined by JFMIP - have been incorporated into the model ’ s Financial Management Line of Business

13 Page 13 Within the Draft BRM, Version 2.0, Mode of Delivery and Services for Citizens should be thought of collectively Services for Citizens Mode of Delivery What is the purpose of government? What “outcomes” is the government hoping to achieve? What mechanisms does the government use to achieve these outcomes? What are the “outputs” of these processes? With this relationship in place, all Government programs, agencies, mission-related IT systems, etc., can be aligned to both a Service for Citizens and a Mode of Delivery

14 Page 14 The Draft FEA Performance Reference Model (PRM): “ At-A-Glance ” WHAT IS THE PRM? A standardized performance measurement framework designed to: Enhance available performance information, Better align inputs with outcomes, and Identify improvement opportunities across organizational boundaries. HOW WILL THE PRM BE USED? Agencies can use the PRM to select standard performance indicators— which may be new or coincide with those already in use—which can be tailored or “operationalized” to the specific environment. The PRM can be integrated into the existing federal budget process. The PRM can mutually reinforce and work together with GPRA and current PMA Budget and Performance Integration initiatives such as the PART, and Common Measures. WHAT IS THE PRM STATUS? Currently in draft form, beginning the internal OMB review process. Once approved in OMB, a Working Draft will be released for agency comment. A final PRM will be released to use during FY 2005 budget formulation.

15 Page 15 The PRM will help agencies identify the performance improvement opportunities that will drive Government transformation

16 Page 16 The PRM structure is designed to clearly articulate “ Line of Sight ”— the cause and effect relationship between inputs, outputs and outcomes

17 Page 17 The Draft Service Component Reference Model (SRM) framework is comprised of three inter-related service-oriented tiers – each of which describes capabilities in greater levels of granularity Service Domain The collection of business oriented service categories that align service / component capabilities to a level in which they support the objectives and performance of the business. Service Types A collection of business-driven, service types (or categories) that assist the Service Layer in accomplishing of mission and/or performance objectives. Service Components The collection of components and/or capabilities that support the Service Type. Level of Granularity 7 Service Layers 29 Service Types 163 Service Components

18 Page 18 Customer Services Process Automation Services Business Management Services Digital Asset Services Business Analytical Services Back Office Services Support Services Cross-Cutting Service Areas (i.e., Search, Security) Service Types Service Domain Service Components Performance Measures Business Process Access and Delivery Channels The SRM is a business-driven, functional framework that classifies capabilities (or service components) according to how they support business and performance objectives

19 Page 19 The SRM is supported by multiple access and delivery channels that provide a foundation for accessing and leveraging the Service Component PortalMarketplace ExchangeCommerceIntegration Delivery Channels (FEA-TRM) Service Domains Service Types, and Service Components (FEA-SRM) Access Channels (FEA-TRM) Mobile, WirelessWeb BrowserPDAKiosks Internet IntranetExtranetPeer to Peer System to SystemEAIWeb Service Private/Public Partnership Phone, Fax Face to Face Mail Accessing the Component (Example: Renewal of Drivers License ) Service Level Agreement to structure how Service Components are accessed and leveraged Other

20 Page 20 Performance Measures Business Process The SRM will assist in defining business process and performance gaps that may be leveraged to improve services to stakeholders (citizens, business partners, agencies) Service Domains Service Types, and Service Components (FEA-SRM) Access Channels (FEA-TRM) Delivery Channels (FEA-TRM) Access Channels (FEA-TRM) Delivery Channels (FEA-TRM) Performance Measures (FEA-PRM) What level of process, performance, and outcome is the Service Component achieving? Does this help to close a performance gap?

21 Page 21 FEA TRM Technical Tiers: Service Access and Delivery The collection of Access and Delivery Channels that will be used to leverage the Service Component, and the Legislative Requirements that govern it’s use and interaction Service Framework The underlying foundation and technical elements by which Service Components are built, integrated and deployed across Component-Based and Distributed Architectures. Service Platform A collection of platforms and specifications that embrace Component-Based Architectures and Service Component reuse How to leverage and access Service Components How to support and maintain Service Components How to build, deploy, and exchange Service Components The Draft Technical Reference Model (TRM) is comprised of three technical tiers to support the construction, exchange, and delivery of service components

22 Page 22 Service Platforms Service Framework Service Platforms Service Access and Delivery How to leverage and access Service Components How to build, deploy, and exchange Service Components How to support and maintain Service Components Security Presentation / Interface Business Logic Data Management Data Interchange Component Architecture Service Integration Service Interface / Interoperability Service Transport Service Requirements Delivery Channels Access Channels The TRM provides an effective means by which service components can be leveraged, built, and deployed across the Federal Government

23 Page 23 The TRM will provide guidance and recommendations that support the development and implementation of service components that embrace a Component-Based Architecture Security Presentation / Interface Business LogicData Interchange Data Management Security Presentation / Interface Business Logic Data Management Data Interchange Component Architecture - X.509 - NIST / FIPS 186 - Secure Socket Layers (SSL) - HTML - JSP, ASP, ASP.Net - DTHML, CSS, XHTMLMP - Java/J2EE (EJB) - C, C++, JavaScript - COM/COM+, C# - Visual Basic - XML - ebXML - RDF, WSUI - XSLT - XBRL, JOLAP, OLAP - JDBC, ODBC - ADO, ADO.Net Partial List

24 Page 24 The goal of the Draft Data and Information Reference Model (DRM) is to support investment and E-Gov planning by providing a framework in which agencies can leverage existing data components across the Federal Government Promote horizontal and vertical information sharing between business lines Business-focused data standardization that can be categorized for re-use Re-Use and integration of data as opposed to duplication Enabler to support Cross- agency collaboration Facilitate Cross-agency information exchanges Consistent means to categorize and classify data Goals and Objectives: Agency 1 Agency 2 Agency 4 Agency 3 State Local FEA-DRM Integrated Enterprise

25 Page 25 The DRM framework provides a consistent method of categorizing and describing the data supporting the Business Lines and Sub-Functions of the BRM FEA-BRM (Business Functions / Sub-Functions) Border Control Intelligence Gathering Anti- Terrorism Law Enforcement Based on ISO 11179 Will heavily leverage XML and interoperability principles Classifications of data will form the basis for the definition of business-driven XML Schemas Will leverage industry vocabularies XML Schemas will be stored within a central repository (e.g.., XML.Gov, FEAMS) Security and data privacy are TOP priorities Will provide effective means to communicate with State and local governments Criminal Suspects Illegal Aliens Terrorist Activity Apprehensions Events Conceptual DRM Framework Focus Points Classifications

26 Questions and Answers

27 Page 27 Contact Information


Download ppt "Architecture and Infrastructure Committee (AIC) Briefing to FOSE 2003 April 9, 2003."

Similar presentations


Ads by Google