Published on

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Norman Lorentz Moderator and Introductions Five minutes
  • Laura Callahan CIO Council in general New AIC concept Ten minutes
  • John Gilligan AIC Subcommittees Ten minutes
  • Bob Haycock FEA Reference Models Fifteen minutes
  • Norman Lorentz Moderator 10 minutes
  • PPT

    1. 1. Architecture and Infrastructure Committee (AIC) Briefing to FOSE 2003 April 9, 2003
    2. 2. AIC Objectives <ul><li>Integrate OMB and CIOC Architecture Efforts </li></ul><ul><li>Develop (simpler) and Consistent Taxonomy and Terminology </li></ul><ul><li>Facilitate Cross-agency efforts: common meta data, tools </li></ul><ul><li>Oversee “operationalization” of architecture efforts </li></ul>A new subcommittee structure was developed to support these objectives
    3. 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. 4. CIO Council has established expectations for federal agency participation in AIC <ul><li>Agencies have begun designating senior-level representatives to the Governance and Components Subcommittees (25% time commitment per subcommittee). </li></ul><ul><li>Volunteers have begun populating the Emerging Technology Subcommittee and its ongoing working groups. </li></ul><ul><li>Subcommittee participation contributes to executive development objectives of CIOC. </li></ul>AIC products will benefit all agencies and accelerate achievement of CIOC goals
    5. 5. Enterprise Architecture Governance Subcommittee <ul><li>Leadership – John Przysucha, DOE; Bob Haycock, OMB </li></ul><ul><li>Subcommittee Mission: </li></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>Assist in implementing the FEA and other Enterprise Architectures (EAs) throughout Government </li></ul></ul><ul><li>Three Subcommittee Goals: </li></ul><ul><ul><li>Integrate EA into the Government’s management processes </li></ul></ul><ul><ul><li>Define the alignment of department/agency EAs with the FEA </li></ul></ul><ul><ul><li>Describe how the FEA will facilitate the connection of State and Local EAs to Federal business lines and agency architectures </li></ul></ul><ul><li>Recent Progress: </li></ul><ul><ul><li>Subcommittee members selected and subcommittee activated </li></ul></ul><ul><ul><li>FY 2003 work plan completed </li></ul></ul>
    6. 6. Enterprise Architecture Governance Subcommittee Tasks <ul><ul><li>Develop FEA Principles </li></ul></ul><ul><ul><li>Integrate EA into the Capital Planning and Investment Control Process </li></ul></ul><ul><ul><li>Integrate EA into the Strategic Management and Budget Formulation/Execution Processes </li></ul></ul><ul><ul><li>Integrate EA into the Project Management, Workforce Planning and Security Management Processes </li></ul></ul><ul><ul><li>Determine the major EA frameworks used by Federal agencies </li></ul></ul><ul><ul><li>Analyze how agencies align with the emerging FEA </li></ul></ul><ul><ul><li>Propose a federated FEA model that complements agency EAs </li></ul></ul><ul><ul><li>Develop a Government Enterprise Architecture Framework </li></ul></ul><ul><ul><li>Conduct a Joint Architecture Integration Pilot </li></ul></ul><ul><ul><li>Conduct a Joint Component Directory/Repository Pilot </li></ul></ul><ul><ul><li>Develop a Joint Government Data and Information Reference Model </li></ul></ul><ul><ul><li>Identify new approaches to Joint Enterprise Software Licensing </li></ul></ul><ul><ul><li>Conduct expanded Joint Architecture Integration Pilots </li></ul></ul>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. 7. <ul><li>Leadership – Reynolds Cahoon, NARA; Bob Haycock, OMB </li></ul><ul><li>Draft Subcommittee Mission: </li></ul><ul><ul><li>Foster the identification, maturation, and re-use of enterprise architecture components and component-based enterprise architectures in Government </li></ul></ul><ul><li>Draft Subcommittee Goal: </li></ul><ul><ul><li>Facilitate cross-Agency development and implementation of enterprise architecture components </li></ul></ul><ul><li>Recent Progress: </li></ul><ul><ul><li>Subcommittee members selected and subcommittee activated </li></ul></ul><ul><ul><li>FY 2003 workplan completed; four tasks identified: </li></ul></ul><ul><ul><ul><li>Develop a Components Based Architecture White Paper </li></ul></ul></ul><ul><ul><ul><li>Develop a Components Registry/Repository Concept Paper </li></ul></ul></ul><ul><ul><ul><li>Develop a Solution Development Life Cycle </li></ul></ul></ul><ul><ul><ul><li>Develop and Market Quick Win </li></ul></ul></ul>Components Subcommittee An Enterprise Architecture Component is defined as &quot;a self contained business process or service with predetermined functionality that may be exposed through a business or technology interface.&quot;
    8. 8. Emerging Technology <ul><li>Leadership – Mark Day, EPA; Dawn Meyerriecks, DISA </li></ul><ul><li>Goal – Coordinate and guide technology tracking efforts of the federal government. Accelerate the implementation of commercially-developed technology resolving common challenges </li></ul><ul><li>Initial Objectives </li></ul><ul><ul><li>To provide a clearinghouse function between industry and agencies </li></ul></ul><ul><ul><li>To help discover and close technological gaps in the federal business and technology infrastructure </li></ul></ul><ul><li>Recent progress </li></ul><ul><ul><li>Activation of the subcommittee </li></ul></ul><ul><ul><li>Development if initial draft 2003 work plan </li></ul></ul>
    9. 9. Architecture and Infrastructure Committee Interrelationships Opportunities for Public-Private Interactions Inherently Governmental Functions Industry Emerging Technology Components SRM TRM DRM Governance PRM BRM Component Voids Candidate Components Priorities Policy Recommendations
    10. 10. FEA - Program Management Office Reference Model Release Schedule Mid-April January 29 th 1.0 TRM TBD TBD 1.0 DRM Mid-April January 29 th 1.0 SRM Mid-April February 28 th 2.0 BRM Early May Mid-April 1.0 PRM General Release Federal Review Version Model Performance Reference Model Business Reference Model Service Component Reference Model Data and Information Reference Model Technical Reference Model
    11. 11. Development of the Draft BRM, Version 2.0 is nearing completion DRAFT Business Reference Model, Version 2.0 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
    12. 12. The Draft BRM, Version 2.0 aligns with three critical management frameworks / improvement initiatives <ul><li>The President’s Budget and Performance Integration Initiative and the FEA Performance Reference Model </li></ul><ul><ul><li>The revised model differentiates between the purpose of the government and mechanism / process used to deliver services to the customer </li></ul></ul><ul><ul><li>This distinction aligns with the Performance Reference Model’s focus on outcomes (purpose of government) and outputs (mechanism/process) </li></ul></ul><ul><li>OMB’s Budget Function Classifications </li></ul><ul><ul><li>These classifications provide a similar functional description of Federal activities </li></ul></ul><ul><li>JFMIP’s New Framework for Financial Management Systems </li></ul><ul><ul><li>Within the revised BRM, financial management is an element of the Lines of Business and Sub-functions throughout the four Business Areas </li></ul></ul><ul><ul><li>The core processes of financial management - as defined by JFMIP - have been incorporated into the model’s Financial Management Line of Business </li></ul></ul>
    13. 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 <ul><li>What is the purpose of government? </li></ul><ul><li>What “outcomes” is the government hoping to achieve? </li></ul><ul><li>What mechanisms does the government use to achieve these outcomes? </li></ul><ul><li>What are the “outputs” of these processes? </li></ul>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. 14. The Draft FEA Performance Reference Model (PRM): “ At-A-Glance” <ul><li>The PRM can be integrated into the existing federal budget process. </li></ul><ul><li>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. </li></ul>HOW WILL THE PRM BE USED? <ul><li>Currently in draft form, beginning the internal OMB review process. </li></ul><ul><li>Once approved in OMB, a Working Draft will be released for agency comment. </li></ul><ul><li>A final PRM will be released to use during FY 2005 budget formulation. </li></ul>WHAT IS THE PRM STATUS? <ul><li>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. </li></ul><ul><li>A standardized performance measurement framework designed to: </li></ul><ul><ul><li>Enhance available performance information, </li></ul></ul><ul><ul><li>Better align inputs with outcomes, and </li></ul></ul><ul><ul><li>Identify improvement opportunities across organizational boundaries. </li></ul></ul>WHAT IS THE PRM?
    15. 15. The PRM will help agencies identify the performance improvement opportunities that will drive Government transformation
    16. 16. The PRM structure is designed to clearly articulate “Line of Sight”—the cause and effect relationship between inputs, outputs and outcomes
    17. 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. 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. 19. The SRM is supported by multiple access and delivery channels that provide a foundation for accessing and leveraging the Service Component Portal Marketplace Exchange Commerce Integration Delivery Channels (FEA-TRM) Service Domains Service Types, and Service Components (FEA-SRM) Access Channels (FEA-TRM) Mobile, Wireless Web Browser PDA Kiosks Internet Intranet Extranet Peer to Peer System to System EAI Web 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. 20. The SRM will assist in defining business process and performance gaps that may be leveraged to improve services to stakeholders (citizens, business partners, agencies) Performance Measures Business Process 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. 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. 22. The TRM provides an effective means by which service components can be leveraged, built, and deployed across the Federal Government 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
    23. 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 Logic Data Interchange Data Management Security Presentation / Interface Business Logic Data Management Data Interchange Component Architecture <ul><li>X.509 </li></ul><ul><li>NIST / FIPS 186 </li></ul><ul><li>Secure Socket Layers (SSL) </li></ul><ul><li>HTML </li></ul><ul><li>JSP, ASP, ASP.Net </li></ul><ul><li>DTHML, CSS, XHTMLMP </li></ul><ul><li>Java/J2EE (EJB) </li></ul><ul><li>C, C++, JavaScript </li></ul><ul><li>COM/COM+, C# </li></ul><ul><li>Visual Basic </li></ul><ul><li>XML </li></ul><ul><li>ebXML </li></ul><ul><li>RDF, WSUI </li></ul><ul><li>XSLT </li></ul><ul><li>XBRL, JOLAP, OLAP </li></ul><ul><li>JDBC, ODBC </li></ul><ul><li>ADO, ADO.Net </li></ul>Partial List
    24. 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 <ul><li>Promote horizontal and vertical information sharing between business lines </li></ul><ul><li>Business-focused data standardization that can be categorized for re-use </li></ul><ul><li>Re-Use and integration of data as opposed to duplication </li></ul><ul><li>Enabler to support Cross-agency collaboration </li></ul><ul><li>Facilitate Cross-agency information exchanges </li></ul><ul><li>Consistent means to categorize and classify data </li></ul>Goals and Objectives: Agency 1 Agency 2 Agency 4 Agency 3 State Local FEA-DRM Integrated Enterprise
    25. 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) <ul><li>Based on ISO 11179 </li></ul><ul><li>Will heavily leverage XML and interoperability principles </li></ul><ul><li>Classifications of data will form the basis for the definition of business-driven XML Schemas </li></ul><ul><li>Will leverage industry vocabularies </li></ul><ul><li>XML Schemas will be stored within a central repository (e.g.., XML.Gov, FEAMS) </li></ul><ul><li>Security and data privacy are TOP priorities </li></ul><ul><li>Will provide effective means to communicate with State and local governments </li></ul>Criminal Suspects Illegal Aliens Terrorist Activity Apprehensions Events Conceptual DRM Framework Focus Points Classifications Border Control Intelligence Gathering Anti- Terrorism Law Enforcement
    26. 26. Questions and Answers
    27. 27. Contact Information