PowerPoint Presentation

  • 503 views
Uploaded on

 

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
503
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
6
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • READ THROUGH THIS SLIDE AND USE WHITE BOARD TO DISCUSS THE THREE LEVEL FRA WE HAVE PROPOSED SOME CHANGES TO THE ORIGINAL BUSINESS ARCHITECTURE . . . (next slide)

Transcript

  • 1. Federal Enterprise Architecture (FEA): Opportunity for Better Automation Opportunity for Better Ways of Doing Business Presentation to the MD CFUG Dorothy Firsching Ursa Major Consulting, LLC [email_address] (703) 425-6236 June 10, 2003
  • 2. Agenda
    • Why We need a Federal Enterprise Architecture
    • The President’s Agenda and Vision
    • The Federal Enterprise Architecture (FEA) and its Components
    • Our Current Project, the Enterprise Architecture for the JWOD Program
    • Where the FEA is taking us – Future Potential
    Note: the FEA part of the presentation draws from numerous FEA briefings over the past several months, mostly by Bob Haycock, FEA Program Manager, OMB
  • 3. Architecture Stories: “User Requirements” Are Not Enough, or Why We Need a Federal Enterprise Architecture
    • Unnamed Govt. Agencies
      • “ Our department is different”
      • “ Our department has the correct data”
      • “ Our people already know this database”
      • “ Buy the equipment and software quickly with End of FY $$, we’ll use them anyway”
      • “ What do you mean, Access won’t scale?”
      • “ We can get Perl scripts for free”
      • “ Why is the system so slow?”
      • “ Who designed this, anyway?”
  • 4. Results
    • Working systems that meet specific requirements, but are not optimal for the overall organization
    • Clumsy systems for the ultimate user
    • Automating the Wrong Thing
    • Re-inventing the Wheel
    • “ Stovepipes”
    • Personal Systems, Spreadsheets
    • Duplicated, inconsistent data
    • Litigation
    • But the Developers met the stated User Requirements at the time!
  • 5. Extensive duplication, overlap and gaps in critical Government functions*
    •  50 agencies implement Federal drug control strategies
    •  29 agencies administer 541 clean air, water, and waste programs
    •  23 agencies administer 200 programs that provide assistance to countries formerly part of the Soviet Union
    •  13 agencies administer 342 Federal economic
    • development-related programs
    •  12 agencies administer more than 35 food safety laws
    Page * Urgent Business for America: Revitalizing the Federal Government for the 21 st Century . The Report of the National Commission on the Public Service, January 2003.
  • 6. Extensive duplication, overlap and gaps in critical Government functions (continued)
    •  11 agencies administer 90 early childhood programs
    •  9 agencies administer 86 teacher training
    • programs
    •  9 agencies administer 27 teen pregnancy programs
    •  8 agencies administer 50 different programs to
    • aid the homeless
    •  7 agencies administer 40 different job training
    • programs
  • 7. This is not a technical problem! (or is it?)
    • Systems are specified without an enterprise-level understanding of the:
      • How they support the Mission Objectives
      • Business processes (e.g., supply chain)
      • Existing technical architecture
      • New technology initiatives
    • In the Federal Government, there is no good way today to gain cross-agency, cross-organization insight.
      • … and the supply chain today goes BEYOND the Federal Government
      • Post-911 coordination between Office of Homeland Security, other Federal agencies, State, and Local law enforcement, Fire departments, etc.
  • 8.
    • Strategic Management of Human Capital
      • Restructure agencies to be citizen-centered
      • Adopt IT to capture employees’ knowledge and skills
    • Competitive Sourcing
    • Improved Financial Performance
    • Expanded Electronic Government
      • Simplify and unify around citizen needs
      • Support projects that offer performance gains across agency boundaries
      • Maximize interoperability and minimize redundancy
    • Budget and Performance Integration
      • Use performance information to make budget decisions
      • Link performance and cost in a performance budget
    The President’s Management Agenda
  • 9. E-Government: Unification and simplification around citizen needs
    • For individuals
      • Easy to find, one-stop shops for citizens – creating single points of easy entry to access high-quality governmental services
    • For businesses
      • Reduce the burden on businesses through the use of Internet protocols, simplifying interactions, and consolidating redundant reporting requirements
    • For government agencies
      • Make it easier for states and localities to meet reporting requirements, while enabling better performance measurement and results (e.g., grants)
    • Internal efficiency and effectiveness
      • Reduce costs for Federal Government administration by using best practices in areas such as supply chain management, financial management, and knowledge management
    Page
  • 10. The Vision:
    • Order of magnitude improvement in the federal government’s value to the citizen; with decisions in minutes or hours, not weeks or months
  • 11. How?
    • Unify Infrastructure
      • Unify access to data stores
      • Collect the data once (requires agreement on data definitions)
      • Integrate customer interface
      • Monitor and measure (define success and measure)
    • Simplify Processes
      • Define and build integrated delivery channels
    • The Teeth
      • If you don’t play, you don’t get funded
      • The FEA is a framework for making IT investment decisions for FY 2005 Budget (Form 300s)
  • 12. The Federal Enterprise Architecture
  • 13. The Federal Enterprise Architecture (FEA) is:
    • A Business-Focused Framework for Cross-Agency, Government-wide Improvement
    • A new way of describing, analyzing, and improving the Federal Government and its ability to serve the citizen
    The FEA will provide the ability, for the first time , to look across the Federal Government and identify opportunities to collaborate, consolidate, and leverage IT investments
  • 14. The FEA is a set of inter-related “reference models” to facilitate collaboration and information sharing Business Reference Model (BRM)
    • Lines of Business
    • Agencies, Customers, Partners
    Service Component Reference Model (SRM) Technical Reference Model (TRM) Data Reference Model (DRM)
    • Business-focused data standardization
    • Cross-Agency Information exchanges
    Business-Driven Approach Performance Reference Model (PRM)
    • Government-wide Performance Measures & Outcomes
    • Line of Business-Specific Performance Measures & Outcomes
    Federal Enterprise Architecture (FEA) Component-Based Architecture
    • Service Layers, Service Types
    • Components, Access and Delivery Channels
    • Service Component Interfaces, Interoperability
    • Technologies, Standards Recommendations
  • 15. The FEA Business Reference Model (BRM) is a framework for describing the Lines of Business performed by the Federal Government independent of the Agencies that perform them Internal Operations / Infrastructure Human Resources, Financial Management Admin Supply Chain Management Human Resources, Financial Management Admin Supply Chain Management Inter-Agency Support Delivery of Services Legislative Management Business Management of Information IT Management, Regulator Management Planning and Resource Allocation Controls and Oversight Public Affairs Internal Risk Management and Mitigation Federal Financial Assistance Web Services
    • Telephone
    • Voice
    • Interactive
    E-system to System Public/Private Partnerships Fax Face to Face Mail Program Admin Compliance Services to Citizens Public Asset Management Marketable Asset Management Defense & Nat’l Security Ops Diplomacy & Foreign Relations Disaster Management Domestic Economy Education Energy Management Insurance Public Health Recreation & National Resources Social Services R&D & Science Regulated Activity Approval Consumer Safety Environmental Management Law Enforcement Legal Revenue Collection Trade (Import/Export) Transportation Workforce Management Program Admin Compliance Services for Citizens Public Asset Management Marketable Asset Management Defense & Nat’l Security Ops Diplomacy & Foreign Relations Disaster Management Domestic Economy Education Energy Management Insurance Public Health Recreation & National Resources Social Services R&D & Science Regulated Activity Approval Consumer Safety Environmental Management Law Enforcement Legal Revenue Collection Trade (Import/Export) Transportation Workforce Management Internet/ Portal Intranet/ Portal Citizen to Government Access Channels Government Employee to Employee Access Channels
    • Telephone
    • Voice
    • Interactive
    E-system to System/ Web Services Public/ Private Partnerships Fax Kiosk Face to Face Mail
  • 16. Business Reference Model (BRM) Status
    • Version 1.0 published in July 2002
    • Used in the FY 2004 budget process
    • Analysis of agencies’ FY 2004 budget submissions revealed multi-billion dollar consolidation opportunities across the Federal Government
      • Financial Management
      • Human Resources
      • Data and Statistics Development
      • Monetary Benefits
      • Criminal Investigations
      • Public Health Monitoring
      • Need for Enterprise licensing
    • Version 2.0 is in Final Agency Review
  • 17. The Performance Reference Model (PRM) will help agencies identify the performance improvement opportunities that will drive Government transformation Technology Technology Value Business Results • Mission Achievement / Outcomes • Financial Business Results Customer Results • Customer Satisfaction • Service Coverage • Timeliness & Responsiveness • Service Quality • Service Accessibility Customer Results Processes and Activities • Financial • Productivity and Efficiency • Cycle and Resource Time Processes and Activities Technology • Financial • Quality & Efficiency • Information & Data • Security & Privacy • Reliability & Availability • User Satisfaction • IT Management Technology Other Fixed Assets • Financial • Quality, Maintenance, & Efficiency • Security & Safety • Utilization Other Fixed Assets People • Employee Satisfaction & Quality of Worklife • Recruitment & Retention • Employee Development • Employee Ratios People OUTPUTS: Measurement of day-to-day activities agencies conduct, as driven by desired business and customer results OUTCOMES: Mission-critical results measured from a business, program, or customer perspective INPUTS: People, technology, and other assets, measured by their contribution
    • Financial
    • Quality, Maintenance & Efficiency
    • Security & Safety Utilization
    • Financial
    • Quality & Efficiency
    • Information & Data
    • Security & Privacy
    • Reliability & Availability
    • User Satisfaction
    • IT Management
    • Employee Satisfaction
    • Recruitment & Retention
    • Employee Development
    • Employee Ratios
    • Financial
    • Productivity & Efficiency
    • Cycle and Resource Time
    • Quality
    • Security & Privacy
    • Mgmt. & Innovation
    • Mission Achievement
    • Outcomes
    • Financial
    • Customer Satisfaction
    • Service Coverage
    • Timeliness & Responsiveness
    • Service Quality
    • Service Accessibility
    Strategic Outcomes
  • 18. The Service Component Reference Model (SRM) classifies capabilities (or service components) Regulatory Management Support Delivery of Services Policy and Guidance Devel. Public Comment Tracking Regulatory Development Rule Publication Knowledge Mgmt CRM Content Mgmt Collaboration Search Portal Personalization Business Reference Model ( BRM ) Rule Publication Service Component Reference Model ( SRM ) Technologies Platforms J2EE .NET Windows NT Data Mgmt ODBC JDBC Business Logic Technical Reference Model ( TRM ) Performance Reference Model ( PRM ) Outcomes and Measures Business lines and functions Supporting technology and standards Enabling capabilities, components, and services Component-Based Architecture Service Layers Service Types Service Components Data and Information Reference Model (DRM) Classification, Categorization, XML, Sharing
  • 19. Examples of Service Components of a Business Function (Technology and Agency Independent) Business Function: Regulatory Management BRM SRM (Service Components) Customer Relationship Management Content Management Document Library Search Engine Personalization / Subscriptions Access Control, User Management Problem Tracking, Case Management Payment Collection (Pay.Gov) A Service Component is a functional capability which assists the business in accomplishing its mission
  • 20. The FEA Technical Reference Model (TRM) is a component-driven, technical framework that identifies the standards and specifications that comprise a Service Component Regulatory Management Support Delivery of Services Policy and Guidance Devel. Public Comment Tracking Regulatory Development Rule Publication Knowledge Mgmt CRM Content Mgmt Collaboration Search Portal Personalization Business Reference Model ( BRM ) Rule Publication Service Component Reference Model ( SRM ) Technologies Platforms J2EE .NET Windows NT Data Mgmt ODBC JDBC Business Logic Technical Reference Model ( TRM ) Performance Reference Model (PRM) Outcomes, Measurements, Metrics Business lines and functions Supporting technology and standards Enabling capabilities, components, and services Component-Based Architecture Service Layers Service Types Service Components Data and Information Reference Model (DRM) Classification, Categorization, XML, Sharing
  • 21. Each tier is comprised of multiple categories that describe the technologies, standards, and specifications that support the service component FEA Technical Reference Model (TRM) - Snapshot Service Access and Delivery Service Framework Service Platforms Access Channels Delivery Channels Service Requirements Service Transport Component-Based Architecture Service Interface and Interoperability Supporting Platforms Web Servers Application Servers Security Presentation / Interface Business Logic Data Interchange Data Management Development Environment Database / Storage Hardware / Infrastructure
  • 22. Collectively, the TRM technical tiers provide a robust and effective foundation to support the reuse and delivery of service components How to leverage and access Service Components How to build, deploy, and exchange Service Components How to support and maintain Service Components Service Platforms Service Interface / Interoperability Security Presentation / Interface Business Logic Data Management Data Interchange Component Architecture Service Framework Service Platforms Service Transport FEA – Technical Reference Model Service Requirements Delivery Channels Access Channels Service Access and Delivery
  • 23. As a foundation, the tiers within the FEA TRM reside across a typical network and application topology Outside World Demilitarized Zone (DMZ) Internal Network Domain Firewall (ACL, IP’s) Components Databases Directory Services Business Intelligence Access Channels Delivery Channels Service Requirements Service Transport Protocol Firewall (HTTP, Port 80) Service Platforms (J2EE, .NET) Presentation / Interface Service Interface Leveraging or Using A Service Component Building a Service Component or Application Business Logic Data Interchange Data Management Security Synchronous / Asynchronous
  • 24. The Federal Enterprise Architecture Management System (FEAMS) Personalization (My FEAMS), Content Aggregation Options to Personalize Content within each dialog box Aggregation and roll-ups of data to support rapid navigation Visualization tools to graphically illustrate cross-agency synergy possibilities Downloadable Reports and Guidance
  • 25. The Federal Enterprise Architecture Framework (FEAF)
  • 26. Engineering the Transition Current “ As-Is” Architecture Target “ To-Be” Architecture As-Is To-Be Strategic Direction Standards Transitional Processes Perf Business Service Comp. Data/Information Technology Engineer for Agency Map to FEA (Ultimately, Re-Use) Perf Business Applications Data/Information Technology
  • 27. The FEA and Agency Frameworks
    • The FEA is the Enterprise Architecture for the ENTIRE Federal Government (Top-Down Categorization)
    • Federal EA Frameworks
      • The Federal Enterprise Architecture Framework (FEAF), developed by the CIO Council
        • FEAF Version 1.1, September 1999, is Current, Version 2 is Stalled
        • Nonrestrictive; Agencies Can Interpret
      • The DOD Architecture Framework (DODAF), based on the C4ISR ( Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) Framework
      • The Treasury Enterprise Architecture Framework (TEAF)
      • The EA Management Maturity Framework (GAO v.1.1 4/2003)
  • 28. The Teeth
    • Agencies must develop and maintain an enterprise architecture
      • Mandated by Clinger-Cohen Act of 1996
      • Must be referenced in Budget Submissions
      • By collaboration and re-use, can share costs
      • FEA will help to identify areas for re-use
      • FEAMS will be repository of Agency Architectures
  • 29. The FEAF – Peeling the Onion based on the Zachman Framework Network Architecture Programs / Supporting System Components Data Definition Library Subcontractor (Detailed Specification) Technology Architecture Systems Design Physical Data Model Builder (Technology) System Geographic Deployment Architecture Application Architecture Logical Data Model Designer (Information Systems) Business Logistics Model (e.g., types of facilities at locations) Business Process Model Semantic Model (Model of Enterprise Objects) Owner (Enterprise) List of Business Locations List of Business Processes List of Business Objects Planner (Scope) Technology Architecture Application Architecture Data Architecture Perspective
  • 30. The JWOD EA/BPR Project
  • 31. The Javits-Wagner-O-Day Program
    • To create jobs for people with disabilities by providing goods and services to the Federal Government
      • Implemented by an independent Federal Agency, The Committee For Purchase From People Who Are Blind or Severely Disabled
      • Two Central Nonprofit Agencies
        • National Industries for the Blind
        • NISH, which supports people who have other severe disabilities
      • People with disabilities working at nonprofit agencies around the country
  • 32. JWOD Products and Services
    • Services
      • Call centers, janitorial, ground maintenance, ship stocking, base supply centers, etc.
    • Products
      • Skilcraft pens and other office supplies, military unique products (e.g., uniforms), hardware, cleaning products, medical supplies (e.g., latex gloves), etc.
    • Distribution
      • Staples, Office Depot, GSA Advantage!, jwod.com, base supply centers, direct to Federal Agencies
  • 33. The JWOD EA/BPR Project, from Bottom up --
    • Needs from an IT Perspective
        • A new, Enterprise-wide IT System
        • Consistent, accessible information to all organizations
    • Needs from a Business Process Perspective
        • Improved business processes , across all organizations
        • Coordination and cooperation
        • Clarified Roles and Responsibilities
    • Needs from a Program Perspective
        • Overall Buy-in to Strategic Objectives and Performance Measures
    More Challenging
  • 34. EA Supports the JWOD Modernization
    • New IT must support Business Processes, which must support Mission Objectives
      • Strategic Planning
      • Documenting Current Architecture
      • Facilitating Development of Improved Business Processes, Enhancing Cooperation
      • Defining Target Architecture – Across Program
        • Business Processes, Performance Measures,
        • Service Components / Application Architecture
        • Technical / Infrastructure
      • Aligning to Federal Enterprise Architecture
  • 35. What makes it hard --
    • No point in automating processes you don’t need to be doing –
      • Need new strategic plan!
        • How should program resources be managed?
        • Need organization-wide alignment
    • Need integration of automation across multiple organizations
        • Including commercial organizations, nonprofits and government
        • Entire supply chain?
        • Not the whole Federal Government, TODAY…
  • 36. What makes it possible --
    • Senior Leadership Buy-in
      • The have an EA Champion
      • New Presidential Appointees
      • People Want to Have Impact
      • Recognition of Benefit of Program-wide Integration
    • OMB and Presidential Guidance
      • Federal Enterprise Architecture
      • E-Gov Focus
    • Technology Enablers
      • All players want to upgrade technology
      • Time to get off that client/server
      • Time to break down stovepipes and make services available over the Web
      • XML and Web Services – for some transactions
  • 37. Where the FEA is Taking Us – Future Potential
  • 38. Huge Future Potential for Improving Federal Automation over the Long Haul
    • As Big of an Impact As The Web
        • The Web made Static / Dynamic Information Available to Users
        • Cataloged, Architected Web Services make Data and Processes Available to Developers in Other Agencies
    • More Data / Code / Service Sharing
        • Cost Savings, Not Re-inventing the Wheel
        • More Flexible Boundaries – Federal Agencies, States, Local Government, Private Industry, …
        • Issues of Data Ownership, Data Quality, Data Privacy and Security
        • Ownership Issues – Who Maintains Services in Repositories if Multiple Agencies Use Them?
    • Sensible IT Investment Decisions
  • 39. The point people miss…! Enterprise Architecture is NOT about building a massive inventory of information about IT systems. Enterprise Architecture is about ALIGNING systems to support processes that support the MISSION across agencies, and measuring the performance of the organization in achieving the mission. The TARGET Enterprise Architecture includes reorganizing SOME systems into accessible, reusable components.
  • 40. The Guidance is a Moving Target
    • The Business Reference Model version 2.0 is overdue, but soon!
    • The Service Component Reference Model version 1.0 is in Draft (out for agency review)
    • The Technical Reference Model version 1.0 is in Draft (out for agency review)
    • The Data Reference Model is not out at all but is promised this summer
    • The FEAMS is not ready yet
    • The FEAF 2.0 appears to be derailed
  • 41. Challenges in Software Engineering
    • Increased Focus on Business Objectives and Business Process
        • Need to optimize process across the enterprise
        • If it is to be shared it has to be generic / common
    • Engineer for Re-Use / Sharing
        • Need to Select Appropriate Level of Granularity
        • Code Re-Use is Downstream, Component Re-Use
        • Security, Repositories, Rules of Engagement Need to be Worked Out
    • Engineering for Interoperability
        • Standards Gaps, Cross-Platform Issues Will Still Need Working Out
  • 42. References
    • Federal Enterprise Architecture Program Management Office (FEAPMO)
      • http://www.feapmo.gov
    • Industry Advisory Council (IAC) Enterprise Architecture SIG
      • www. iaconline .org , http://www. ichnet .org/IAC_EA. htm
    • FEA Bibliography (evolving)
      • www.ursamajorconsulting.com
  • 43. Questions/ Discussion