Services and Components Based Architectures Version 3.5 Chapter 1

CIO Council
PDF リンク切れ


This document serves as an “Executive Strategy” for planning and implementing modern information technology (IT) architectures within the Federal Government. The specific architecture it describes, Services and Components Based Architecture (SCBA), leverages the Federal Enterprise Architecture (FEA) and builds upon the concepts, principles, and benefits of Service Oriented Architecture (SOA) – an architecture designed to maximize the reuse of components and services and one of the most promising and widely accepted architectural approaches to-date. SCBA represents a practical, results-oriented, approach to modernizing enterprises. It is intended to help organizations reduce long-term costs, improve quality of service, improve information sharing, and help achieve a vision of flexible business processes supported by customer-focused applications, which can be altered in a matter of days instead of months. SCBA builds upon traditional SOA principles in three ways:

  • it is tightly integrated with the Federal Enterprise Architecture,
  • it provides a description of what the architecture is (a collection of services designed and implemented to achieve an organization’s mission), and
  • it identifies the organizational, cultural, and process elements, as well as technological elements, that need to exist for these architectures to be successful.

The most important aspect of SCBA is its focus on reuse of services and components – better referred to as Service Components. Service Components are information technology assets that perform useful business functions through a well-defined interface. The main advantage of Service Components is that they enable practical reuse of assets both within and across organizations. Service components are superior to traditional software components in the following ways:

  • one copy of the Service Component may be shared among all consumers, eliminating the need to manage and support multiple versions on different servers,
  • the Service Component can be used by consumers on any technical platform (via a standard interface) eliminating the need for platform-specific versions, and
  • the asset can evolve and improve without requiring consumers to modify their business processes or interfaces, since changes to the internal implementation of the component can be made without affecting the interface.

Despite its emphasis on services, SCBA still accommodates the concept of component reuse. Specifically, component reuse is necessary for those situations where cross-agency service sharing is not possible due to regulatory or security restrictions. Finally, SCBA emphasizes changes both in technology and in the following areas:

  • 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.

This document is the first in a series of chapters that fully describe SCBA. Later chapters will further detail its technical and process characteristics and are described in Appendix B.

(Executive Summary)