Software Reuse on the Army SBIS Program

Jeffrey S. Poulin, Ph.D.
Loral Federal Systems
Owego, NY
23 April 1995

This article gives an overview of the reuse strategy for the Army Sustaining Base Information Services (SBIS) program. SBIS represents a 10-year contract potentially worth $474 million to improve and standardize the Army's automation of day-to-day business functions. SBIS will overhaul the administrative functions carried out at Army installations by providing software applications in areas such as logistics, finance, personnel, and training. The contract will help prepare the Army to move from proprietary operating environments to open systems standards-based configurations, and may serve as a procurement vehicle for the Defense Information Systems Agency (DISA) and the rest of the Department of Defense (DoD). SBIS will form the architectural foundation upon which DoD builds the Defense Information Infrastructure, a global, end-to-end network for all DoD users.

Software reuse makes up a large part of the Loral Federal Systems (LFS) software development plan for SBIS. The SBIS reuse team, led by Fred Illig (Loral Federal Systems-Springfield, VA), launched the strategy in January 1994 with a joint kick-off meeting with the SBIS Program Office, Army Program Executive Office (PEO), Army Reuse Center, and the DISA Reuse Office. This article will describe the SBIS Reuse Strategy and the accomplishments of SBIS reuse over the past year [3].

The reuse strategy addresses the SBIS goal to achieve a level of 15% reuse on the first "increment" of applications, 55% after the second increment, and a level of 85% by the conclusion of the program. Each increment typically develops from 4-10 software applications over a period of 1-2 years. Making these aggressive reuse goals requires a strategy that brings together lessons learned from many researchers and practitioners of software reuse. This article explains how the SBIS Reuse Strategy provides a comprehensive and achievable framework for meeting these goals.

First, the article discusses the motivation and rationale for the SBIS Reuse Strategy and its two-phase approach for implementation. It then outlines the roles of the people responsible for making reuse happen:

  1. the Software Development Manager,
  2. SBIS Reuse Coordinator,
  3. Project Reuse Leads, and
  4. Reuse Development Team.
Finally, the article discusses reuse activities in the SBIS software development environment including the steps taken to help developers find, retrieve, and incorporate reusable assets into SBIS applications.

The Three Classes of Software

Before introducing the strategy it helps to review the three classes of software that make up a typical software application. These classes come from industry experiences in software development and form the basis of what SBIS will target for reuse. Starting with the most generic class:

  1. Domain-independent software comprises the category of software with the widest range of usefulness. Domain-independent software provides the foundation for programming; e.g., abstract data types, graphical user interface functions, and math libraries. Because this software spans many different application areas, or domains, we call the use of software from this class horizontal reuse. Reuse levels from horizontal reuse will not generally exceed more than about 20% of an application.
  2. Domain-specific software contributes the most to reuse but only within the problem domain. High-speed communications device drivers, navigational aids for aircraft, and financial services libraries serve as good examples of domain-specific software. Domain-specific software concentrates on an area of an organization's business processes; we call the use of software from this class vertical reuse. To achieve high levels of reuse (and the corresponding benefits) an organization must practice vertical reuse. Only then can it move from a maximum reuse level of about 20% to the 85% level targeted by SBIS.
  3. Finally, Application-specific software handles the unique details of a customer's requirements; it consists of the last 15% of a well-designed application. Application-specific generally means "custom code." Although opportunities exist to reuse software within an application team, this software tends to deal exclusively with how one application implements a function and typically has very limited reuse potential even within its own domain.

Phase 1- Tactical

Phase 2- Strategic

Figure 1. The SBIS Reuse Strategy: Overview

The SBIS Reuse Strategy: Overview

Figure 1 gives an overview the SBIS Reuse Strategy. Simply put, the strategy makes use of the concepts of horizontal and vertical reuse to attack reuse in two phases.

Phase one puts in place the tactical moves necessary to make the most of horizontal reuse opportunities and to start the domain analysis activities required for phase two. The first phase includes all the efforts needed to institutionalize reuse on the SBIS program. This means establishing the people, processes, and tools required to fully integrate reuse into the SBIS development cycle. In short, by the end of phase one, SBIS will have made reuse "Business as Usual."

Phase two builds the strategic backbone for SBIS reuse. This phase starts after the SBIS development team has worked with the customer and applications for about a year. Developers need this time to understand the SBIS applications, requirements, and trade-offs they must make to build a domain-specific framework needed for vertical reuse. A framework provides developers with the components, rules, and tools to rapidly build an application in the domain.

SBIS Reuse Strategy Phase One: The Tactical Plan

We have identified several sources of domain-independent software for use on SBIS. Many of these sources contain Government Owned Software (GOTS) that the SBIS program can use without incurring any development cost (the team must still integrate and test the components). The use of GOTS software comes first on the priority list of reusable software. These external reuse libraries include the:

Through an agreement with the ARC, SBIS developers can submit search requests to the ARC and have the ARC search the above libraries for them. This prevents developers from having to worry about the various sources and conventions used by the different library systems. In fact SBIS has already experienced a total Reuse Cost Avoidance in excess of $1.9 million resulting from software provided by the ARC [1].

However, if a search request to the ARC does not result in a suitable component, SBIS developers have access via the LFS internal World Wide Web (WWW) to the Federal Reuse Repository (FRR) [2]. This repository contains software and software-related work products including 9 Ada language collections of Abstract Data Types, utilities, and other domain-independent software.

Finally, LFS has developed Application Programming Interfaces (APIs) to access Commercial-Off-The-Shelf (COTS) products and to access Open System Environment (OSE) standard services, such as POSIX operating system services and X.400 messaging. Although not all the APIs have completed development, they will all serve as the common interface for SBIS applications to access COTS products and to access OSE-standard services, such as POSIX, X.400, and X.500. The APIs represent a 50k LOC investment made by LFS in the SBIS program.

SBIS Reuse Strategy Phase Two: The Strategic Plan

Before explaining the second phase of the strategy (which focuses on vertical, domain-specific reuse) it will help to identify the domains within SBIS. We have initially broken down the original 80+ SBIS applications into seven domains. Most of the applications fall into:

  1. Resource Management, which contains 10 applications,
  2. Logistics, which contains 13 applications.
  3. Personnel, which contains 18 applications, and
  4. Information Management, which contains 16 applications.
Because of the large number of applications within these four domains, SBIS expects a large amount of reuse to come from shared software within them. For example, the 18 Personnel applications will share a significant number of common functions. However, these same functions will not necessarily find much use in the other domains, such as Information Management.

Engineering applications for vertical reuse

The SBIS application architecture calls for applications to consist of collections of separately compiled and running Ada objects that communicate via methods such as Remote Procedure Calls (RPCs). Each Ada object provides a service for use by one or more SBIS applications. The SBIS architecture lays the foundation for phase 2 of the strategy because it clearly identifies responsibilities of SBIS shared (application-independent), domain-specific, and application-specific objects.

The architecture uses the term Service Objects to describe all objects that provide common services to all (or most) SBIS applications. The SBIS development team has already identified and started developing about 30 Service Objects. These objects provide services ranging from scheduling to audit trail and print functions. LFS projects that Service Objects will make up over 20% of the software in the first increment, for a conservative estimated Reuse Cost Avoidance of approximately $7 million.

Scheduling, Progress Status, Electronic Signature
Help, Business Graphics, Data Validation, Access Control
Mail Interface, File Transfer, Audit Trail, Print, etc.

Figure 2. SBIS common Service Objects

In addition, each SBIS domain (Personnel, Logistics, etc.) will have domain-specific Business Objects specifically built for the 2-18 applications within each domain. For example, the Logistics domain will have a set of "Inventory Control" Business Objects that all or most of the 13 Logistics applications will share. Each of these objects work together according to the rules and conventions of the domain; we call this a domain-specific framework. The SBIS team will build these Business Objects after it gains the necessary knowledge about the domain from customers and logistics experts. The SBIS program also plans to take advantage of work products from previous and other current DoD MIS programs. We also expect to use non-code assets such as lessons learned and domain studies completed by RCAS, SIDPERS, and other programs.

When fully implemented, an SBIS developer will only have to write the logic unique to the application and the "glue" code that brings together the common Service Objects and the domain-specific Business Objects. The architecture specifies that developers will package this logic and glue code in Application Objects. In effect, an SBIS application will consist from 55%-85% of reused software.

Personnel Responsibilities

Implementing the SBIS Reuse Responsibility requires a team effort and a commitment from all levels. The Software Development Manager "owns" all reuse activities and processes. The SBIS Reuse Coordinator works full-time to ensure all SBIS developers have the reuse-related tools, information, and assets they need. Each SBIS application development team has a part-time Application Reuse Lead to identify reuse requirements and candidate reusable components for each SBIS application.

All of these personnel perform a key role in implementing the strategy. Together, they make up the SBIS Reuse Working Group. To ensure they work together effectively, the SBIS Reuse Working Group shares information through e-mail, an issues database, an extensive collection of data accessible through the internal WWW, and weekly meetings.

Finally, the strategy calls for an SBIS Reuse Development Team to build and maintain Service Objects. Although this team has not yet formed, it will have responsibility for prioritizing and implementing Service Objects. The team will report to the Software Development Manager.

The SBIS Reuse Process

The SBIS reuse process varies little from the well-defined development process used for all SBIS software. The developer must first gather all of the requirements for a component from the various applications that intend to use it. The developer then records the requirements using the on-line functional description template provided by the reuse team.

Next, the developer attempts to locate existing software to meet the requirements. To do this, the developer completes an on-line search request form and submits the form to the ARC, who searches external libraries for candidates. The developer also searches, in priority order, the internal reuse repository and the SBIS CLIN list. The developer evaluates the candidates, selects the best candidate(s), and documents the rationale for the decision using the on-line COTS/GOTS evaluation form. The developer shares the findings at the weekly reuse working group meeting. This ensures all application reuse leads help identify other reuse candidates and share in selecting which component to use.

If the developer cannot locate a suitable candidate, the developer estimates the effort to build the needed component. The developer verifies requirements with the Configuration Management (CM) group, obtains approval for the proposed solution at a System Architecture Meeting (SAM). If necessary, the developer designs, codes, and tests the component in accord with the SBIS Software Development Plan (SDP).

The reuse team provides a number of process documents, templates, and checklists to assist developers. All of the documents reside on the SBIS file system and the internal WWW. The assets include a Reuse Requirements Traceability Matrix, Service Object Requirements Approval Procedure, and Reuse Inspection Checklists for each step of the software lifecycle. Following software quality testing, the SBIS team will provide all potentially reusable software and APIs to to the ARC for use throughout DoD.

Implementation of the strategy requires a sustained effort by the SBIS reuse team. The team produced the detailed processes, schedules, and other items required to support the project reuse leads. The team also holds weekly meetings, supports the on-going development of Service Objects, and forwards reuse across applications by identifying and publicizing reuse opportunities. SBIS's daily efforts implement and continue to build on the ideas put forth in the reuse strategy.


In conclusion, the SBIS Reuse Strategy takes place in two phases. The first phase identifies and makes it easy for SBIS developers to take advantage of horizontal reuse opportunities. We do this by establishing:

  1. an easy way to search for government-owned software,
  2. an easy way to access LFS-owned software, and
  3. shared APIs to COTS software and OSE services.
During the second phase the strategy focuses on domain-specific, vertical reuse. To date, SBIS has identified and started to build Service Objects to share across all SBIS applications. The next step will include identifying and building domain-specific Business Objects for use within each SBIS domains. The experiences and strong working relationship that the SBIS team has both within the team and with groups such as the Army Reuse Center show that the this strategy has already made significant steps towards :hp6.institutionalizing reuse on SBIS.:ehp6.

Please send comments to the author (e-mail preferred) at: Regular mail: MD 0210, Owego, NY 13827; tel: (607) 751-6899, fax: (607) 751-6025. Readers can obtain a copy of the SBIS Reuse Strategy by contacting the Army Reuse Center at (703)806-3866.


Army Reuse Center (ARC), "Reuse Benefits Continue to Add Up," The Army Reuse Center News, Vol. 3, No. 3, October 1994, p. 3.
Poulin, Jeffrey S. and Keith W. Werkman, "Software Reuse Libraries with Mosaic," 2nd International World Wide Web Conference: Mosaic and the Web, Chicago, Illinois, 17-20 October 1994. URL:
Poulin, Jeffrey S., "SBIS: Secrets of Our Success," The Army Reuse Center News, Vol. 3, No. 5, February 1995, pp. 4-6.