SOA for E-Government Conference McLean, VA May 24, 2006

1. Integrating SOA into the Federal Enterprise Architecture: Services and Components Based Architectures (SCBA) Michael A. Tiemann Joseph M. Chiusano Booz Allen Hamilton SOA for E-Government Conference McLean, VA May 24, 2006

2. Table of Contents • SCBA History and Overview • The SCBA Value Proposition • Relation of SCBA to Enterprise Architecture and the FEA • Enabling Reuse of Service Components • SCBA Governance • SCBA Case Studies • The Path Forward • Questions

3. Table of Contents • SCBA History and Overview • The SCBA Value Proposition • Relation of SCBA to Enterprise Architecture and the FEA • Enabling Reuse of Service Components • SCBA Governance • SCBA Case Studies • The Path Forward • Questions

4. Services and Components Based Architecture (SCBA) is a framework that integrates Service Oriented Architecture (SOA) into the Federal Enterprise Architecture (FEA) • SCBA is a catalyst for the implementation of distributable and reusable components and services across the Federal Government • SCBA treats business processes and the IT systems in the same way, allowing both to be reused across organizations • SCBA focuses on reuse of large-scale components in a collaborative environment that includes system owners, capital planners, business leaders, and enterprise architects • The first chapter of a comprehensive guide to SCBA was released in January 2006 • It is an Executive Strategy for planning and implementing SCBA within the Federal Government • The SCBA Executive Strategy was initiated and developed under the Federal CIO Council’s Architecture and Infrastructure Committee (AIC), Components Subcommittee (now known as the Services Subcommittee) in collaboration with the FEA Program Management Office (FEAPMO) and the Industry Advisory Council (IAC) • SCBA supersedes the “Service Component-Based Architectures, Version 2.0” specification of February 2004

5. SCBA supports the Federal Government’s advancement to the next stage of the “e-government” evolution • The evolution to an “e-enabled” government has progressed to the point where business processes not supported by IT systems are rare, and IT departments focus more on incremental system improvements (i.e. service capability enhancements) than whole new implementations • The Federal Government is now advancing to the next stage of the “e-government” evolution in two ways: • Moving from government-centricity to customer-centricity, and • Moving from rigid business processes to agile business processes • Moving from stove-piped to common shared services • Today many government IT systems are traditional, pre-IT business processes built into an IT format focusing only on the needs of the particular agency or program they support • The vision of customer-centricity is: Citizens go to one location to accomplish a series or set of divergent tasks and never have to enter data more than once • The move to “customer-centricity” recognizes that in the view of citizens, the Federal government is a single organization • Technology is an enabler to help deliver these citizen-centric services

6. The most important aspect of SCBA is its focus on reuse of services and components Service Component Reuse Concept Component Reuse Concept One central copy reused many times • Together, these are known as “Service Components” • Service Components are assets that perform useful business functions through a well-defined interface • They enable reuse both within and across organizations • Service Components are superior to traditional components • One copy shared among all consumers, eliminating the need to manage and support multiple versions and enabling improvements to be made in one place • Can be used by consumers on any technical platform (through a standard interface)

7. SCBA emphasizes changes in organizational and technology areas • Policies: The organization needs to alter its policies to support reusing assets from any source, and to set specific, measurable goals for levels of reuse • Strategies: The organization needs to move from strategies that are narrowly focused on programs to ones focused on producing and integrating reusable services across the entire Federal Government • Processes: The organization’s software development and capital planning processes need to be altered to make looking for opportunities for reuse a core task • Culture: The organization’s culture needs to change through a combination of executive recognition and incentive programs that strongly reward reuse • Governance: The organization’s IT governance processes need to change to take into account that a service may be used by multiple organizations, not just local users, and put appropriate service level agreements in place Component reuse is still a large part of SCBA because there are situations where cross-agency service sharing is not possible due to regulatory or security restrictions

8. Table of Contents • SCBA History and Overview • The SCBA Value Proposition • Relation of SCBA to Enterprise Architecture and the FEA • Enabling Reuse of Service Components • SCBA Governance • SCBA Case Studies • The Path Forward • Questions

9. SCBA will provide great value for the Federal Government on various levels • Successful SCBAs will greatly enhance Federal agencies’ ability to accomplish their fundamental mission by increasing agility through service orientation and reducing costs through sharing efficiencies and reuse • SCBA delivers the vision of agile business processes by reducing the cost and time needed to make business process changes • Since business processes and IT systems can be reused across organizations, costs of development and maintenance of similar systems at multiple agencies are avoided • SCBA also helps to achieve the customer-centricity vision by focusing on the modeling of both data and business processes from a customer point of view • For example, SCBA could potentially speed a government response to a major natural disaster • New benefits programs could be more quickly deployed by reusing processes and IT services that support existing benefits administration programs • Business processes and supporting IT systems could be more quickly adapted to meet needs encountered by personnel in the field

10. Table of Contents • SCBA History and Overview • The SCBA Value Proposition • Relation of SCBA to Enterprise Architecture and the FEA • Enabling Reuse of Service Components • SCBA Governance • SCBA Case Studies • The Path Forward • Questions

11. Business and Customer Results Achieves Business Strategies Aligns to and implements Enterprise Business Processes Specifies Enterprise Business Requirements Business Drives Capability Requirements & Profile Drives Informs & Enables Fulfills Technology Services Provision Layer Integrates and provides Integration Layer Leverages Data/Information Applications Services Technology Components Supports Technology & Infrastructure Enterprise Architecture provides a mechanism for SOA adoption The Enterprise Architecture model is the “line of sight” from business strategies to services and technologies that support them

12. Performance Reference Model (PRM) • Government-wide Performance Measures & Outcomes • Line of Business-Specific Performance Measures & Outcomes Business Reference Model (BRM) • Lines of Business • Agencies, Customers, Partners Business-Driven Approach Service Component Reference Model (SRM) Service-Oriented Architecture • Service Layers, Service Types • Components, Access and Delivery Channels Data Reference Model (DRM) • Business-focused data standardization • Cross-Agency Information exchanges Technical Reference Model (TRM) • Service Component Interfaces, Interoperability • Technologies, Recommendations The Federal Enterprise Architecture (FEA) is a business-based approach using a set of models to guide Government-wide transition • The reference models are designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps, and opportunities for collaboration within and across federal agencies

13. SCBA is most closely related to the FEA Service Component Reference Model (SRM) SCBA ties the FEA layers together BRM and SRM provide organization TRM provides technology DRM provides information SCBA provides reuse focus/strategy SCBA is targeted at a broad audience CIOs, CTOs, CFOs, and other Execs Functional / Business Line Managers Capital Planners Enterprise Architects System and Solution Architects System and Process Engineers Relationship between SCBA and the FEA SCBA • “SCBA lays out an approach that can be used to help accomplish both overall goals for implementing E-Government as identified in The President's Management Agenda and the E-Government Act of 2002: to better perform government services, and at lower cost” • Source: OMB/FEAPMO

14. SCBA will influence virtually all layers of EA, with the greatest impacts on the Application and Technology layers • While baseline (as-is) architectures will not be significantly affected, organizations need to ensure that their target architectures reflect a service-based approach • Going forward, architectural elements should be tightly integrated into capital planning and economic processes so that true EA analytics can be performed on the viability and feasibility of reuse, as well as the costs and benefits of doing so • Best practice frameworks will emerge (e.g., CRM, PRM, and other Service Components in the FEA-SRM) and will be overlaid on existing EAs to assess gaps, redundancy in applications, and interoperability issues and constraints • Although it is critical to have an overall target architecture, it is equally critical that organizations have an actionable and realistic transition strategy, complete with a sequencing plan

15. Table of Contents • SCBA History and Overview • The SCBA Value Proposition • Relation of SCBA to Enterprise Architecture and the FEA • Enabling Reuse of Service Components • SCBA Governance • SCBA Case Studies • The Path Forward • Questions

16. Reuse has a long, rich history • This history spans from software and systems to today’s service-oriented solutions • SOA is by far the most mature reuse technique • Industry research has documented that designing an asset so that it can be easily reused usually adds (up to 50%) to its overall cost (“Measuring Software Reuse”, Jeffrey S. Poulin, 1996) • Research also shows that successful planned reuse can save a project 25-30% in its development costs (“Asset Based Software Engineering”, Charles M. Stack, Flashline Inc.) • Given these economics, even if a Service Component is reused only a few times, the return on investment is quickly realized (and often in multiples)

17. Designing for reuse involves 5 basic principles, supported by processes, tools, and reward systems • The 5 basic principles are: • Generalizing functionality for broader applicability • Creating well defined interfaces • Loose coupling (discrete componentized design with standard interfaces) • Ensuring well documented functionality • Using cross-platform technologies (if developing a system) • Processes, tools, and design create the basics of an environment that allows reuse • However, reuse efforts will only succeed if an organization’s culture is transformed such that reuse is rewarded, and there is support for reuse from senior leadership • Rewarding individuals and projects successfully publishing their Service Components or having high reuse rates accelerates this cultural change. Examples: • Monetary rewards for Service Component producers in the form of a stipend every time their Service Component is successfully reused; parallel reward for projects with high reuse • Other approaches that afford professional recognition or privileges

18. Project reuse levels can be determined by a “project reuse quotient” • A project reuse quotient determines the degree to which a project reuses components, to help measure and control reuse • The quotient serves the dual goals of tracking the organization’s progress towards greater reuse, and driving desired behaviors • Values close to 0 represent low reuse; values equal to or greater than 1 represent higher reuse • Reuse quotients below a threshold should trigger additional project reviews • It is critical to note that this metric does not necessarily show how much a project increases reuse – only how much reuse it involves

19. Project reuse quotient example • An agency project reuses the following components from other projects on its Web site: • A search component • A customer authentication component • The project also creates a new geospatial management Service Component • This new Service Component is used only by the agency project • This yields a project reuse quotient of .66:

20. Project reuse quotient example (cont’d) • The project team then publishes the geospatial management Service Component in a component registry such as CORE.gov, where it can be discovered and reused by other agencies • Over time, two other agencies discover the new Service Component and incorporate it into two of their projects • This yields a new project reuse quotient of 1.33:

21. Table of Contents • SCBA History and Overview • The SCBA Value Proposition • Relation of SCBA to Enterprise Architecture and the FEA • Enabling Reuse of Service Components • SCBA Governance • SCBA Case Studies • The Path Forward • Questions

22. Governance is a key part of SCBA • The production, discovery, and utilization of Service Components will require new policies and processes that promote and ensure compliance with reuse, service level agreements, security, and interoperability standards • Governance should be supported by service level agreements (SLAs), but these may not be able to completely abbregate risks • SLAs should: • Document the support commitments that a Service Component provider has agreed to, to include cost sharing arrangements • Provide details on modification models (e.g. central control, open source) • Clearly outline reuse policies, to include any restrictions on reusing the component as well as procedures for obtaining approval for reuse • Document any fees associated with use of the Service Component, as well as models for large-scale usage of the Service Component • Disclose any restrictions stemming from commercial license agreements • Describe the responsibilities for funding maintenance and support costs • Further details on SCBA governance are planned for a future SCBA guidance phase

23. Table of Contents • SCBA History and Overview • The SCBA Value Proposition • Relation of SCBA to Enterprise Architecture and the FEA • Enabling Reuse of Service Components • SCBA Governance • SCBA Case Studies • The Path Forward • Questions

24. SCBA Case Study: Authentication Service Component (ASC) • The ASC is a government-wide authentication solution that includes technical and policy subcomponents to identify users on the Internet, created as part of the E-Authentication e-Gov initiative • The ASC enables organizations to participate in federations in which members can securely rely on each other’s credentialing systems, enabling end user identity to be portable across Internet domains • This eliminates the need for every web-enabled application to establish its own identity management and credentialing system, thus enormous savings for the government and easier online access to government services for citizens are realized • The Program Management Office (PMO) assigns relationship managers and technical subject matter experts to assist organizations implementing, or considering implementing, the ASC • The PMO also operates an interoperability lab that tests relevant Commercial off the Shelf (COTS) products to ensure interoperability with the ASC

25. SCBA Case Study: Department of Labor, Business Rules Engine • The Business Rules Engine is a generic rules application component of the GovBenefits.gov portal search capability, allowing a wide variety of business rule sets to be expressed and used • This rules engine was designed so that the criteria that define whether a user is a possible candidate for a particular federal or state benefit program can be easily modified or extended • In 2004, the Department of Energy created the GovLoans.gov portal, which reused this component in its entirety • This reuse saved DOE and its partner agencies an estimated 50% of the overall development cost of their solution implementation

26. Table of Contents • SCBA History and Overview • The SCBA Value Proposition • Relation of SCBA to Enterprise Architecture and the FEA • Enabling Reuse of Service Components • SCBA Governance • SCBA Case Studies • The Path Forward • Questions

27. Future SCBA phases have been mapped out, but the path forward for SCBA is currently being reviewed by the AIC • These phases cover the following areas: • Business Imperatives (CPIC/EA Integration) • Foundation Framework (SOA, SOA Strategy) • Service Component Governance (SLAs, Interface Management) • Solution Architecture (Integration Foundation) • Component-Based Development • Service Production, Discovery, and Consumption • Using Government-Wide Profiles and Lines of Business (LoBs) • Funding and Publishing Components: Registries, Repositories, and Communities of Interest (COIs) • There are multiple options for moving forward with these phases, and discussions are taking place. The new Services Subcommittee and the Data Architecture Subcommittee will be engaged in this dialogue, along with the IAC industry partners. • SCBA Executive Strategy is available at: http://colab.cim3.net/file/work/SOACoP/Finals%20SCBA_Whitepaper_Chapter_1_Version%203.5%20OMB%20SUBMISSION.doc

28. Table of Contents • SCBA History and Overview • The SCBA Value Proposition • Relation of SCBA to Enterprise Architecture and the FEA • Enabling Reuse of Service Components • SCBA Governance • SCBA Case Studies • The Path Forward • Questions

29. Contact Information • Michael Tiemann, Senior Associate • Booz Allen Hamilton • Washington, DC • (202) 508-6887 • chiusano_joseph@bah.com • Joseph M. Chiusano, Associate • Booz Allen Hamilton • Washington, DC • (202) 508-6514 • chiusano_joseph@bah.com