150 likes | 169 Views
A strategic guide for implementing distributed and reusable services and components in government. Version 3.0 incorporates current architecture practices and moves beyond technology.
E N D
Delivery Report Services and Components Based Architectures (SCBA) A Strategic Guide for Implementing Distributed and Reusable Services and Components in Government Washington, DC November 19, 2005 This document is confidential and is intended solely for the use and information of the client to whom it is addressed.
Version 3.0 of the SCBA is an import update that incorporates current architecture practices and moves beyond technology. Background Contributors to the SCBA Development • Version 1: released in Jul-2002 (as “CBA”) • Helped define the need for the SRM and the TRM • Version 2: released in Feb-2004 • Integrated CBA into the FEA • Made the case for reuse • Version 3: draft sent to AIC in Nov-2005 (today’s topic) • First Chapter – “Executive Strategy” for SCBA • Developed by the AIC Components sub-committee • Incorporates feedback from across Gov and Industry • Updates the SCBA to reflect evolution of the FEA • Integrates Service Oriented Arch (SOA) into the FEA • Increases depth by adding focused chapters Industry Best Practices AIC Value Proposition Successful SCBAs will greatly enhance agencies’ ability to accomplish their missions by increasing agility through service orientation and reducing costs through reuse. 120 comments received and incorporated! Services and Components Based Architectures - Presentation to AIC
Agenda Background and Value Proposition Summary of Major Points in Paper Next Steps Appendix
“Reuse” has been around in various forms for a long time – Service Oriented Architecture is the most mature reuse technique. • Reuse efforts have focused on packaging functionality into packages that can be reused • SOA is an architecture designed to maximize reuse by focusing on single instances of functionality • Differs from previous approaches by not replicating the “reuse package” in multiple location • One of the most promising and widely accepted architectural approaches to-date • Is garnering strong industry and vendor support • SOA has strong potential for government, due to distribution of functionality across agencies • SCBA makes this potential practical History of Software Reuse Services and Components Based Architectures - Presentation to AIC
SCBA is an integrated part of the FEA – tying its layers together. Given its scope, it is relevant to a wide audience. • SCBA builds upon SOA, seeking to make it a practical approach for Federal agencies • it is tightly integrated with the Federal Enterprise Architecture, • it provides a description of what the architecture is (clarifying the varying descriptions that exist), • and it identifies the organizational,cultural, and process elements needed for these architectures • It ties the FEA layers together • BRM and SRM provide organization • TRM provides technology • DRM provides information • SCBA provides reuse framework • 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 Services and Components Based Architectures - Presentation to AIC
Service Components are the primary units of reuse in the SCBA. Service Component Reuse Component Reuse • Important aspect of SCBA is its focus on reuse of services and components – or “Service Components.” • Service Components are assets that perform useful business functions through a well-defined interface. • Advantage of Service Components is enablement of reuse of assets both within and across organizations. • Service Components are superior to traditional components: • One copy may be shared among all consumers, eliminating the need to manage and support multiple versions • Can be used by consumers on any technical platform (through a standard interface) • Improvements can be made without requiring consumers to modify their business processes or interfaces • Example: eAuthentication component versus service One central copy reused many times. Services and Components Based Architectures - Presentation to AIC
Reuse programs are not purely technical programs – they must incorporate changes to all dimensions of the organization. Non-Technology Change Areas Non-Technical Dimensions of Reuse • Policies: the organization needs to alter its policies to support reusing assets from any source, and 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. Policies Strategies Culture Services and Components Based Architectures - Presentation to AIC
Of course, reuse of software Service Components is also enabled through a combination of technical techniques. • Design for Reuse: focus on interfaces, configurability, good documentation, and white-boxing • Tools for Reuse: tools enable publication and discovery of Service Components • Registries (such as Core.gov) provide directories of Service Components • Repositories provide the actual Service Components themselves • Reuse Infrastructure: • Internal systems can reflect available services, their interfaces, and monitor their quality • Modern shared middleware can be used to create an Enterprise Service Bus (ESB) • ESB allows services to discovery each other and communicate • Security: an import aspect of design, tools, and infrastructure – cuts across all aspects Services and Components Based Architectures - Presentation to AIC
Several work streams must be considered and kept in balance to make effective progress in implementing SCBAs. SCBA Streams and Recommended Steps for Getting Started Services and Components Based Architectures - Presentation to AIC
The document produced is the first in a series of chapters that fully describe SCBA. Later chapters will provide focused details. Delivered so far Services and Components Based Architectures - Presentation to AIC
Agenda Background and Value Proposition Summary of Major Points in Paper Summary and Next Steps Appendix
Summary and Q&A Session • Summary • SCBA is a framework that cuts across the FEA layers to encourage reuse • Version 3.0 updates the SCBA to incorporate SOA and reflects the evolution of the FEA • Major focuses are on reuse of Service Components and comprehensive reuse programs • SCBA adds value by increasing process agility and reducing costs • Questions? Services and Components Based Architectures - Presentation to AIC
Next Steps • Next Steps • Seeking feedback from the AIC and FEAPMO on Chapter 1 by Nov-25-2005 • Seeking AIC endorsement of Chapter 1 at December meeting • Discuss strategy for completing Chapters 2 through 9 Services and Components Based Architectures - Presentation to AIC
Agenda Background Paper Content Next Steps Appendix
Paper Contributors (in alphabetical order) • James Benson, AIC Contractor Support • Richard von Bostel, OMB Contractor Support • L. Reynolds Cahoon, National Archives & Records Administration • Nathaniel A.F. Clark, AIC Contractor Support • Josiah Cushing, AIC Contractor Support • Bobby Jones(1), Department of Homeland Security • Karen Kaye, Nuclear Regulatory Commission • David R. Mayo, Industry Advisory Council • Marion A. Royal, General Services Administration • Adam Schwartz, Office of Management and Budget • James W. Smith, Office of Management and Budget (1) Services and Components Based Architectures Committee Leader Services and Components Based Architectures - Presentation to AIC