Design and Search
ROBERT C. SEACORD

Building systems from commercial components is often a completely different experience from building custom systems in that the focus of control shifts from the architect or designer to the commercial marketplace. To deal with this loss of control, the successful architect must take a risk-driven approach by considering multiple design contingencies, weighing benefit against risk, and generally playing the odds.

Introduction

Herbert A. Simon, winner of the 1978 Nobel Prize in Economics and many prestigious international scientific awards for his work in cognitive psychology and computer science wrote the following in the Science of Design in 1969:

Some 30 years later, we are saying almost the same thing about building systems from commercial components, namely that system architects and designers must pursue multiple simultaneous design contingencies to balance and reduce risk. While this is not a typical tenet of software engineering, it applies in the case of commercial components for a simple reason. Software design does not take place in the real world but consists instead of the formulation of an artificial world of abstractions that may or may not model real-world properties. However, the use of commercial components introduces a substantial dose of reality into the design equation.

Design as Search

When I say software design does not take place in the real world, I am not ignoring the realities of cost, schedule, people and other very tangible real-world issues. Building systems from commercial components, however, adds a new layer of reality on top of these already substantive issues. In particular, component capabilities and liabilities are a principle source of design constraint in system development.

Design of component-based systems consists of a search for compatible ensembles of commercial components that come closest to meeting system objectives. Because component integration is a principal risk area, the system architect must determine if it is feasible to integrate the components in each ensemble, and in particular, to evaluate whether an ensemble can support a required interaction of the system.

In effect, each ensemble amounts to a continued path of exploration. This exploration should initially focus on the feasibility of the path to make sure that there are no precipitous cliffs, uncrossable chasms, bands of thieves, or other obstacles that would prevent the journey being completed by the full development team (who perhaps are not quite so nimble as the explorer).

If only one path (that is, ensemble) is discovered, then the question of the optimal path does not arise. However, if more than one path is discovered, a decision is required. An architect or a design team can often make a decision when there is one (or at most a few) major criteria that weigh the evaluation in favor of a particular ensemble. When there are numerous criteria and the ensembles each have their own advantages and disadvantages, it may be necessary to take a more formal approach to decision making.

Fortunately, there are a number of multi-criteria evaluation techniques available that apply some science to the field of decision making. These techniques are often misused in the evaluation of individual components during the formulative phase of system development.

The formulative phase occurs before many decisions have been made. At this time, the availability of commercial components may cause revisions in user requirements, which in turn may affect decisions about commercial components. As components are identified, and an understanding of the features and interactions of these components are discovered, the formation of the design can vary tremendously. While multi-criteria evaluation techniques can be—and are—used at this time to evaluate products that satisfy the requirements of a particular component in the system, this evaluation is often premature and costly, because the role this component fills in the formulation of the design is not yet properly understood.

Evaluation at this time can also have a tremendous adverse effect in that a component selection can easily become a keystone of the design. In selecting additional components, it may be discovered that less-than-adequate components must be selected to ensure compatibility with the initial selection. Because these decisions are often difficult to revisit, the project becomes wedded to a flawed and non-optimal assembly of components.

The evaluation context therefore is more properly scoped at the evaluation of ensembles of components that achieve the design objectives and not at a single component. This often means that evaluation decisions are deferred to a later stage of the development process, which brings us back to the need to maintain and manage multiple design contingencies.

Summary

Building systems from commercial components is often a completely different experience from building custom systems in that the focus of control shifts from the architect or designer to the commercial marketplace. To deal with this loss of control, the successful architect must take a risk-driven approach by considering multiple design contingencies, weighing benefit against risk, and generally playing the odds.

In the book Building Systems from Commercial Components, in the SEI Series in Software Engineering, we have documented a number of techniques that have been applied in practice to manage this loss of control and maximize opportunities for success. We have also illustrated these techniques in an extensive case study involving the development of a Web-based application for image management and retrieval.

About the Author

Robert C. Seacord is a senior member of the technical staff at the SEI and an eclectic technologist. He is coauthor of the book Building Systems from Commercial Components as well as more than 30 papers on component-based software engineering, Web-based system design, legacy system modernization, component repositories and search engines, security, and user interface design and development.

The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.