Component-Based Systems
BILL THOMAS

The market regime, with its new component-based software development processes, is overthrowing the custom-system regime, with its ideal of the "software factory" in which "software processes are analogous to manufacturing processes, programmers are analogous to assembly-line workers, and the ultimate product is lines of code." That is the thesis of the upcoming book, Component-Based Software Engineering, part of the Addison-Wesley SEI Series in Software Engineering, by SEI technical staff members Kurt Wallnau, Scott Hissam, and Robert Seacord.

The "software factory" made sense in the era of large-scale, custom-built systems, but is no longer feasible now that the demand for new software far outstrips its supply, jobs for computer and data processing workers go unfilled, and the number of graduates in computer science fields declines. The response is to build systems using commercial software components, and cede control to the new "market regime," and a new set of software development processes. "Components represent a kind of revolution, and revolutions are inherently cyclical," Wallnau says. "We must overthrow our 'traditional' ideas of software process-based on the factory metaphor-with a 'new' process regime."

The market regime consists of component producers and consumers, each behaving, in the aggregate, according to the laws of the marketplace, the authors write. "The market regime decides how features are distributed across components, which features become available when, and how long the features are supported. The marketplace also determines the interfaces components support and which standards are adopted. Ultimately, the market regime decides which components thrive, and which are destined for the bit bucket."

Accommodating Changes

To succeed in the new era, software developers must come to terms with the following realities of the market regime:

• The market drives the system architecture, and designers have less control. Today the designer must accommodate marketplace instability. Components come and go and often do not integrate well. If integration can be achieved at all, it often breaks down when new versions of components are introduced.
  
  
• Systems must be designed to accommodate new components. These components may be desirable for their innovative features, or necessary in response to environmental pressures, such as a new operating system release. The downside is that new components may not be compatible with each other, or with older components.
  
  
• Requirements analysis, design, implementation, and testing must be compressed and co-mingled. Often the only way to know whether a component, or an ensemble of components, will work is to try it. As a result, previously discrete activities are often indistinguishable. To the uninitiated, it may appear that developers bypass requirements analysis and design and head straight for implementation. In fact, the goal is to achieve "just-in-time competency" through highly focused prototyping experiments that are designed to answer precisely stated questions.
  
  
• Systems comprise component suppliers, not simply components. This element of the new market regime resembles a traditional manufacturing supply chain, "with suppliers of parts linked to suppliers of subassemblies of parts to suppliers of larger subassemblies," the authors write. But unlike a supply chain for, say, automobile manufacturing, the top-level enterprise does not control the chain and set standards. In component-based software systems, those standards are established by the marketplace.
  
  
• Designers must strive to remove sources of misfit among components. This misfit occurs on two levels: misfit between the user's needs and the available components, and misfit among components that cannot be seamlessly integrated. On the first level, the designer must be a mediator and negotiator to close the gaps between user needs and component capabilities. On the second level, the designer must be a "hacker," with the programming and system skills to bridge, wrap, or otherwise cobble together misfitting components.
  
  
• Technology competence is a critical design asset. "The once lowly software engineer," the authors write, "consigned to the bleak and unrewarding prospects of the IT [information technology] equivalent to the assembly line, has emerged as a dominant player in the design and construction of modern, component-based information systems." Engineers who have mastered either a technology, such as Web technology or distributed object technology, or a particular vendor's component, must be hired or developed, and then encouraged to sustain their competence.

The Goal: A New Process Regime

After describing these engineering challenges, the authors present a "toolkit" of engineering techniques that can be used to overcome the loss of control inherent in component-based software engineering. The authors' overarching message is that new processes that are predictable and repeatable must be established for component-based software engineering, just as they were established and matured under the custom system regime.

For more information, contact-

Kurt Wallnau

Email
kcw@sei.cmu.edu

Customer Relations

Phone
412 / 268-5800

World Wide Web
http://www.sei.cmu.edu/cbs/