NIST GCR 02-834
Benefits and Costs of ATP Investments in Component-Based Software

Component‑based software development (CBSD) is a relatively new software production paradigm that focuses on building large software systems by assembling readily available components.  Historically, about 85 percent of all large software projects have been customized applications used within a single firm, involving a minimal amount of code reuse (ATP, 1999).  Systems programmers would employ proprietary or shared libraries for a minor portion (up to 20 percent) of the new application's code, but the remainder would be written specifically for the project at hand.  The remaining 15 percent of programs, sold as packaged software to the retail market, have increasingly used embedded components, but even in these programs the overall levels of reuse are quite low.

CBSD changes this paradigm and follows a "buy, don't build" approach for most, if not all, software projects.  The basic concept is that computer code should be reused rather than rewritten whenever possible.  This approach can potentially be used to reduce software development time and costs, decrease the incidence of program errors, and reduce maintenance costs associated with software change.

There are other valid motivations for CBSD that may not require or even involve reuse.  For example, component developers John Cheesman and John Daniels argue that adaptability to new and evolving functionality is far more important in enterprise system development than reuse (Cheesman and Daniels, 2000 ).  The authors reason that the benefits of component technology may be more attributable to a design paradigm and a set of associated component standards.  Still, this development method has been strongly endorsed by software architect Clemens Szyperski, who emphasizes the importance of component reuse and component markets (Szyperski, 1998 ).  It is therefore important to understand that software reuse does not necessarily require software component technology, nor does software component technology focus only on software reuse.

In this section, we describe the historical approach to software development and how CBSD differs from and improves on existing techniques.  We describe what a component is and what types of components are available to build software.  We also discuss the important characteristics that software developers look for in a component.  Finally, we describe ATP's efforts to support industry in influencing the emergence of the CBSD market and the CBSD supply chain.

2.1.1  A Brief History of the Software Industry

The watershed event in the development of the software industry can be traced to 1969, when the U.S. Justice Department forced IBM to "unbundle" its software from the related hardware, and required that the firm sell or lease its software products.  Prior to that time, nearly all operating system and applications software had been developed by hardware manufacturers, dominated by IBM, or by programmers in the organizations using hardware.  Software developers in the 1950s and 1960s worked independently or in small teams to tackle specific tasks, resulting in customized one-of-a-kind products.  Since this landmark government action in 1969, a software development market has emerged, and software developers and engineers have moved through several development paradigms (Egan, 1999 ). 

During the 1970s, improvements in computing capabilities caused firms to expand their use of automated information-processing tasks, and the importance of programming to the activities of firms increased substantially.  Simple tools to aid software development, such as programming languages and debugging tools, were introduced to increase the software programmer's productivity.  The introduction of the personal computer and its widespread adoption after 1980 caused demand for software and programming to accelerate, rapidly outpacing previous productivity improvements.  Processor speed, roughly doubling every 18 months, has dramatically outpaced the rate of improvement in software, creating a "software bottleneck" (Egan, 1998, 1999 ).  Although software programs are easily duplicated and distributed, allowing for economies of scale, the customized approach to software development was so entrenched that economies of scale in programming never emerged.

Recognition of the importance of the bottleneck, and its role in hindering progress in information technologies, has influenced many software development activities over the past 20 years.  Object-oriented languages, which today include Smalltalk, C++, and Java, built on the concept of software modularization to create objects that are completely reusable.  Although a significant step in increasing productivity, object technology by itself is not sufficient to reach optimal levels of reuse (Brown and Wallnau, 1998a ). 

The fact that a software product has been produced with an object technology does not ensure that it has plug-and-play capability, interoperability, and a standard interface, nor does it mean that the product will be sold in the market rather than being bundled into a larger monolithic product.  The ATP focused program in CBSD and other noncommercial ventures, such as the COTS-Based Systems initiative (COTS stands for commercial off-the-shelf) at Carnegie Mellon's Software Engineering Institute, are attempting to move software development technology to a full component basis, thus achieving the economic benefits of optimal reuse. 

2.1.2  The Software Development Process

The historic approach to the software development process, focused on system specification and construction, is often based on the waterfall model (Andersson and Bergstrand, 1995 ).  Figure 2-1 shows how this process separates software development into several distinct phases with minimal feedback loops.  First, the requirements and problem are analyzed; then systems are designed to address the problem.  Testing occurs in two stages; the program itself is tested and then how that program works with other programs is tested.  Finally, normal system operation and maintenance take place.  Feedback loops exist only between the current stage and its antecedent and the following stage.  This model can be used in a component-based world for describing the separate activities needed in software development.  For example, the requirements phase and the design phase can include the identification of available reusable software.  However, in a component-based world, development does not exist in isolated boxes and steps.  Rather, it is a process full of feedback loops across all stages of development.  Feedback loops throughout the entire development process increase the ability to reuse components.  Reuse is the key attribute in CBSD but does not exist in the waterfall model.  When building a component-based program, developers need to examine the available products and how they will be integrated into not only the system they are developing, but also all other potential systems.  Feedback loops exist throughout the process and each step is no longer an isolated event.

Figure 2-1.  Waterfall Model

Adapted from Andersson and Bergstrand (1995 ), Table 2‑1 illustrates where software developers have historically placed their efforts. ^[1]

Table 2-1.  Allocation of Effort

In the 1960s and 1970s, software development focused on writing code and testing specific lines of that code.  Very little effort was spent on determining its fit within a larger system.  Testing was seen as a necessary evil to prove to the final consumer that the product worked.  Andersson and Bergstrand estimate that 80 percent of the effort put into early software development was devoted to coding and unit testing.  This percentage has changed through time.  Starting in the 1970s, software developers began to increase their efforts on preliminary design and requirements analysis, spending 20 percent of their effort in these phases. 

Additionally, software developers started to invest more time and resources in integrating the different pieces of software and testing the software as a unit rather than as independent entities.  As developers have moved toward CBSD, the allocation of effort has again changed.  The amount of effort spent on determining the developmental requirements of a particular software solution has increased in importance.  Forty percent of the software developer's effort is now spent in the requirements analysis phase.  Design phases in a CBSD world are extremely important because these phases determine the component's reuse possibilities.  Developers have increased the time spent in this phase to 30 percent, which reflects its importance. 

Based on work by Aoyama (1998 ), Table 2‑2 compares the conventional approach to software development and CBSD.  The architecture of a system, defined as how the system is set up, is described as monolithic (designed for a specific purpose) in the conventional approach.  Monolithic software tends to be rigid and unable to be adapted for purposes other than those for which the software was originally designed.  Even though a monolithic system typically contains modules, they are designed for use only within the specific architecture of one application.  For each new program, most of the lines of computer code have to be written from scratch. 

Table 2-2.  Comparison of Conventional Approach to CBSD

1. When a "white box" component is used, the programmer is given access to the source code from the component.  The programmer then can change the code, and adaptation is relatively easy. 
2. "Black box" components cannot be adapted or changed. 

Source:  Aoyama, 1998.

In a component-based system, the architecture for software production is described as modular because developers build programs from component pieces.  From the initiation of the project idea to completion of the component, the developer must envision how the final program will fit together and how any new components will be made available to other developers and users; there is a feedback loop from the first stage to the final stage.

The way the information and lines of code are treated within a program is also significantly different.  Developers in a conventional approach know each line of code that they are assembling, but in a component-based world, developers only know about the properties of the component; they do not know the specific lines of code within the component.  This difference leads to problematic comparisons between the two approaches.  The conventional approach measures programmer efficiency as the number of documented lines of code written.  In CBSD, measures of efficiency can be based on the frequency of reuse (Aoyama, 1998 ). 

The final major difference between the two methods of software development is the establishment of a market for the product.  Formal markets do not exist in the conventional approach.  If a firm needs to alter or update its computer network, it has to hire a developer to build on its existing system or write new code from scratch.  For CBSD to be successful, markets must exist in which firms can purchase the architecture and components that they need. 

Several specific types of firms have emerged in the CBSD market that do not exist in the conventional approach (Brown, 1999 ): 

• component developers-develop the necessary infrastructure and components;
• component brokers-act as single point of contact connecting vendors to purchasers;
• component educators-have tutorials, certification for various infrastructures; and
• component-based consultants-offer mentoring services throughout the entire process.

The brokerage process has become increasingly advanced in recent years, with Web-based brokerage firms clearly taking the lead.  Two sources, www.componentsource.com and www.flashpoint.com, provide a marketplace that connects buyers to vendors.  Both of these firms provide extensive information on the quality, interoperability, and other attributes of every component sold.

Return to Table of Contents.

Determining what constitutes a component is one of the primary steps in determining the impact of ATP-funded projects.  Gallaher, et al. (2000 ) have argued in a previous study that by identifying and defining an activity, a common set of terminology emerges within an industry.  The emergence of this terminology can be an effective step towards eliminating market failures and expanding the size of markets.  Meyers and Oberndorf (1997 ) point out that developing a common definition for a component and component characteristics is a necessary step in building a component-based software market.

Parrish et al. (1999 ) argue that a component is a software artifact that consists of three attributes.  A component has a service interface that determines what services it provides, a client interface that states what services it uses, and the code that is necessary for the component to execute its commands.  Ning (1999 ) offers a second definition.  He states that a component is an encapsulated, distributable, and executable piece of software that provides and receives services through well-defined interfaces.  Szyperski (1998 ) offers a similar definition by defining components as binary units of independent production, acquisition, and deployment that interact to form a functioning system.  Meyer (1999 ) provides an additional characteristic that helps define a component:  the component developers do not need to know the component's users.  The common theme that emerges from these different definitions is that a component is an independent piece of software that interacts with other components in a well-defined manner to accomplish a specific task.

Components can be used to build both enterprise-critical software and shrink-wrapped software.  While the ATP program focuses on the enabling technologies needed for complex and large-scale software development for commercial and industrial applications, benefits from the new innovations will spill over to small-scale or simple applications.  As a software component market emerges, most software developers will shift focus from design and implementation processes in large-scale and enterprise-critical situations to solving application problems in small-scale purposes.  Shrink-wrapped and small-scale software includes word-processing, spreadsheet, and other specific applications.

Return to Table of Contents.

CBSD replaces the notion of building a program by writing code with the idea of building a new application by assembling and integrating existing components into a new system.  CBSD shifts the focus of system development to construction of components where the following characteristic activities become important:  identification, qualification, adaptation, integration, and upgrade (Brown and Wallnau, 1996 ).  Of these characteristics, integrability is the key difference compared to previous approaches to software development.  Rather than focusing on how a particular piece of code will be implemented, the focus is on how the particular piece of code can be integrated into multiple programs.

The best approach to considering different components is to imagine a component as a bundle of particular goods.  This bundle consists of the five characteristics given by Brown and Wallnau.  Some components display a high level of integrability; others display better adaptability.  In some cases, tradeoffs between characteristics may occur.  For example, the greater the ability to adapt a component to different circumstances, the harder it is to qualify and test that component.

2.3.1  Identification

Before a building is constructed, the builder must know what pieces of brick and mortar are available to be used.  A software developer writing a new program under a CBSD paradigm has the same concern.  Knowing what components (building blocks) are available, the software developer designs programs at minimum cost and maximum efficiency. 

2.3.2  Qualification and Suitability Testing

Because a component is initially designed to solve one particular type of problem, it needs to be qualified before it can be used in additional settings.  Component qualification is the process of determining the "fitness for use" of previously developed components that are being applied in a new system.  In other words, are different components available to address a particular programming need, and how well does each component fit that need? 

Component qualification consists of two phases: discovery and evaluation.  The component's properties are identified in the discovery phase.  For example, what does the component do or what standards does it meet?  Following the discovery phase, the evaluation phase occurs.  The evaluation phase focuses on quantifying the component.  For example, how reliable is the component, or does it actually do what the component manufacturer says it does?  Third parties (e.g., the International Standards Organization) have created criteria that software developers can use during this stage.  Several software initiatives produced tools to test component qualification, including SAAM, PRISM, and PLAS (Haines et al., 1998 ). Continuing with the building analogy, the discovery phase is similar to deciding on which of the available tools, workers, and bricks should be used to construct a building.  The evaluation phase would then correspond with checking the workers' references. 

Failure to adequately foresee how a component might be used, and therefore failure to adequately specify a component can create potentially disastrous consequences.  Jézéquel and Meyer (1997 ) describe how inadequate specification of a particular component in Ariane 5, a European Space Agency Mission vehicle, caused the $500 million project to fail.  The problem was not due to the failure of a component, but rather to the lack of specification of the component's range of acceptable uses.

2.3.3  Component Adaptation

One component can rarely be plugged into multiple programs without any adaptation.  When components are used in multiple systems, some changes must be made to fit each software environment.  The changes must be made to components to minimize the amount of conflict among the components. 

Component adaptation can be accomplished in three ways.  Components can be written so they are white box, gray box, or black box in nature.  When a "white box" component is used, the programmer is given access to the source code from the component.  The programmer then can change the code, and adaptation is relatively easy.  However, this approach also requires the most monitoring and maintenance because the developer might make changes to the source code of the component that cause numerous potential and unintended consequences.

The second approach is to use "gray box" components.  These components are not supplied with their source code, but an extension language is provided that allows the programmer to incorporate the component into a program with minimal disruption.  The final approach to component adaptation is use of "black boxes," components that are difficult to adapt or change.  They can either be put into place to accomplish a predetermined and specific task, or they must be left out.  No access to source code is given and no extensions are made available to incorporate a black-box component into other programs.  Sometimes a predefined set of alternatives controllable through parameters may be provided in a black-box component.

2.3.4  Integration

In CBSD, components are assembled to form a system.  Appropriate integration is necessary to ensure that the components work together in an efficient and desired manner.  Where component adaptation focuses on how to change components to fit the need of the situation at hand, integration focuses on how to fit the components together in the entire program.  Returning to the building analogy, adaptation is similar to deciding how to modify or alter each room, and integration can be thought of as the blueprints.

2.3.5  System Evolution/Upgrade

System evolution is the dynamic aspect of CBSD.  When a component needs to be changed or updated or when additional features are desired, the ideal solution would be a "plug and play" approach.  If the programmer could simply take out the old or defective component and replace it with the new one, system evolution would be simple.  However, the new component rarely performs exactly the same function as the old component and rarely fits perfectly into the entire system.  Rather, wrappers must be written to fit the new component into the program, and tests of the new component in isolation and in concert with the rest of the program must be performed (Kogut and Clemens, 1999 ).

System evolution is similar to remodeling the building.  Rarely can one room be taken out of the building and a second room put in without disturbance to the building.  Usually, electrical wiring and plumbing need to be changed and reworked for the renovated room to have access to electricity and water and to prevent disruption of those services to the rest of the building.

Return to Table of Contents.

ATP started funding component-based software development projects in 1994.  Before this time, a component-based market was slow to develop for several specific reasons.  Section 2.4.1 explains the market failures that were slowing the development of a component-based market.  Section 2.4.2 describes the steps that ATP has taken to help alleviate these failures.

2.4.1  Rationale for ATP Involvement

The concept of using components to assemble software systems has been in existence for several decades.  Firms have reused up to 20 percent of their code internally since software was first developed.  However, several market failures have slowed the development of a component-based market, including lack of interoperability, network externalities, and lock-in effects.  ATP's efforts in funding a focused program in component software were aimed at overcoming the technical challenges associated with these barriers.

Interoperability

Interoperability is a measure of how well different pieces of technology function together (Tassey, 1997 ).  In the CBSD case, two types of interoperability exist.  First, components must be interoperable with a given system architecture.  Second, components must be able to interoperate with other components.

However, software companies are developing different architectures and different components.  When there is no commonly agreed-upon platform or interface, software developers will not want to develop new components because they may not work with other components or with existing system architectures.  A second problem occurs when there are multiple types of architectures in use.  By increasing the number of architectures, the component development costs increase; software developers would have to produce specialized components for each architecture.  This lack of interoperability slows the development of a component-based market.  ATP has addressed this problem by selecting projects that focus on cross-domain and enterprise-wide applications where the technical challenge of maximizing interoperability is a goal (ATP, 1997 ).

Network Externalities

Components must interact with other components and infrastructures to create a valuable software product.  For example, a new spell-checking component has no value unless basic word-processing components exist that can interact with the new component.  As more components are developed, the initial spell-checking component becomes more valuable because a network of components develops.  This concept is called a "network externality."  Each individual component is more valuable than it is perceived to be because it adds value to all other components.

However, when the individual firm is making market decisions about what research to pursue for specific products, it does not take into account the network benefits that are being created from the initial framework and components.  This divergence between the social and private values of a new component has slowed the development of the component-based market.  By providing additional funding for high-risk R&D that supports technologies needed for reuse, ATP can help compensate for the discrepancy between the social and private returns from new components and thereby help stimulate development of reusable components and their commerce.

Lock-in

Legacy software and extensively customized large software systems are abundant in large firms.  They contain massive amounts of information about how the company operates and identify critical data that must be collected and analyzed.  Significant resources are spent on maintaining, updating, and monitoring their performance.  Migrating complex, monolithic systems to newer, component-based systems that can easily be updated and improved could lower these costs.

However, firms have been reluctant to change to component-based systems.  The main explanation is that the short-run costs of migrating from the existing system to a component-based system are prohibitively high, even though the long-term benefits could be substantial.  Firms are locked in to their existing systems and are unwilling to adopt new systems (Brown and Wallnau, 1998b ). 

There is anecdotal evidence that fixing the Y2K bug may have pushed many firms into replacing monolithic systems because of the excessive cost of fixing the problem within the existing legacy software.  However, the studies are not yet in place to verify that this was a widespread phenomenon or that these firms adopted component-based approaches for their newer systems.

2.4.2  Role of ATP

In 1994, ATP held a series of workshops with industry and academia to discuss the potential for a focused program on component-based software.  These workshops, along with various white papers from the technical community, resulted in the ATP recommendation for a focused program.  Another workshop was held in 1995 to update the program scope. 

Over the course of three rounds of funding, ATP committed a total of nearly $70 million and industry committed an additional $55 million of cost-sharing funds to a total of 24 projects.  Table 2‑3 provides information on ATP-funded projects throughout the program's history.  Table 2‑4 describes the status of each project at the time this study was initiated.  Of the 24 projects funded between 1994 and 1997, 18 were completed by the time of this study, two are still underway, and four failed to complete.  Two-thirds have yielded commercial products.  To date, three-fourths of the projects have reached the commercialization phase and have begun marketing activities even though some of the resulting products are not yet generating revenues. 

Table 2-3.  ATP CBSD Funded Projects

Table 2-3.  ATP CBSD Funded Projects (continued)

Source:  Data extracted from the ATP Focused Program Status Reports and Closeout Reports housed at NIST; information was current as of December 2000.

Table 2-4.  December 2000 Status of CBSD Projects by Funding Round

Historically, the process of developing and using software components has been extremely complex.  A number of barriers created substantial technical risk to innovation in this area, including a lack of the following:

• automated tools for building, locating, and adapting components;
• interfaces for nonprogrammers to enable them to use the components; and
• specifications of interface semantics for bridging applications.

The ATP's focused program for CBSD sought to support development of such tools, with special emphasis on tools that enable complex, large-scale, commercial applications that can be used by a wide spectrum of industries.  Within this area, ATP has focused its funding efforts in two separate directions:  building components and building component architecture.  Developing the basic building blocks for components and architectures that apply to all component users is likely necessary to the maturation of component-based software.  Once component-based software markets have emerged, software developers are expected to specialize and focus on specific applications of components.  The component-based software industry would supply automated high-performance software tools and architectural services that could be incorporated into the development of computer systems.  This model would allow a programmer to focus on the problem at hand without being concerned about syntax or the programming process (Cuthill, 1997 ).

ATP investments have created several widely agreed-upon effects, including acceleration of R&D spending on projects with high technical risks, and increasing the probability of a project's success.  ATP funding may also broaden the scope of technology development, and thereby enable wider application.  ATP's investment in CBSD is likely to accomplish similar objectives.  For example, ATP's investment should accelerate the benefits that emerge.  ATP funding may increase the scope of CBSD by providing more tools for users and by expanding opportunities for use.

Before ATP involvement, industry software developers, universities, and other researchers were already engaged in the development of a component market.  Given that ATP funding is small compared to the total amount of component-based research, it is likely that the market for CBSD would have developed without ATP funding, but perhaps along a delayed trajectory or to a lesser extent.

Return to Table of Contents.

The supply chain within the software development industry consists of approximately 4,500 firms, with an average of fewer than 20 employees per firm (ATP, 1999 ).  Figure 2‑2 provides the supply chain for the industry, while Table 2‑5 gives examples of firms or organizations that are operating at each level.  The supply chain starts with firms, think tanks, and universities that are engaged in research and product development.  The next level of the supply chain consists of software developers that are building the infrastructure for CBSD.  The third level consists of firms that are designing and producing the components that the end users will use as an input into their production process. 

Research centers, such as the COTS-Based Systems initiative at Carnegie Mellon University and the Reusable Software Research Group at Ohio State University, are engaged in the basic research needed to develop a component-based market.  These researchers are producing the basic knowledge that other developers would apply to component production.  It is appropriate that universities, funded by various governmental agencies, are conducting these activities, because appropriating the knowledge that they create would be a near impossible task. 

Following the basic research stage, software firms engage in R&D for writing, designing, and developing the architecture for supporting a component-based system and the tools that can be used to design components.  They are building and designing the production tools that can be used to build components.  This area is where ATP has focused its three rounds of funding.  ATP funding in this area has two potential effects.  First, ATP funding can accelerate the building process.  Second, ATP can put more or better tools into the production shop; rather than having one type of hammer, software developers may now have an entire toolbox. 

The next step down the supply chain consists of the software developers that use the tools and architecture developed in the production shop to design and build components.  Because the tools and infrastructure are completed sooner, software developers are able to design and build components earlier.  Currently, over 221 firms are designing and building components (Components Source, 2000 ).

Table 2‑6 provides the number of firms, employment figures, and sales receipts for firms that were engaged in these two phases of the production process in 1997.  Table 2‑6 captures all firms engaged in producing software, including firms engaged in CBSD and firms engaged in the traditional approach to software development.  In 1997, total receipts by firms engaged in this activity totaled over $100 million.  Based on NAICS definitions, firms in this industry are engaged in providing one of four activities: 

• writing, modifying, testing, and supporting software to meet the needs of a particular customer;
• planning and designing computer systems that integrate computer hardware, software, and communication technologies;
• providing on-site management and operation of clients' computer systems and/or data processing facilities; or
• supplying other professional and technical computer-related advice and services.

Table 2-6.  Industry Establishments, Receipts, and Employment

Firms that fall into this group are Sterling Software, Microsoft, and Accenture; they have all engaged in efforts to generate component-based software and structures to support components.  Some of the successful architectures that have been developed and that are currently in use include Active X, Enterprise Java Beans, Component Object Model (COM), and Common Object Request Broker Architecture (CORBA).

CBSD is much more than the languages, tools, and architectures needed for software development that appeared contemporaneously with component-based software.  The languages, tools, and architectures provide some of the pieces needed to build a component-based system, but a component-based system is more.  CBSD consists of the enabling technologies described above, the industrial standardizations, the common marketplaces, and the design approaches that are needed to fully develop a market (Brown and Wallnau, 1998a ).  The existing object technology (OT) simply does not address all of the abstractions needed to have a fully functioning component-based market.  ATP has emphasized the search for solutions to these problems in defining the focused program

Once the components are built, end users assemble the components to form software products to use in their production processes.  Again, because the components are available to end users sooner, they are able to design and build their software sooner.  Table 2‑7 lists some of the system architectures, component tools, and components that are currently in use. 

____________________
1. These data are based on the effort that software developers put into developing a product to rlease. Over time, the amount of effort spent post-release—primarily on maintenance and update—has increased.

Return to Table of Contents or go to next Chapter.

Date created: December 3, 2002
Last updated: August 2, 2005

ATP website comments: webmaster-atp@nist.gov  / Technical ATP inquiries: InfoCoord.ATP@nist.gov.

NIST is an agency of the U.S. Commerce Department
Privacy policy / Security Notice / Accessibility Statement / Disclaimer / Freedom of Information Act (FOIA) /
No Fear Act Policy / NIST Information Quallity Standards / ExpectMore.gov (performance of federal programs)