Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.