Goals

There's one thing that's worth getting clear early on -- what major challenge is the component approach to system development addressing? For us the challenge is managing change. This means building for change in the first place by placing primary emphasis during architecture and design on dependencies between the components, and the management of those dependencies. The purpose of the individual components is clearly important to us but is in many ways a secondary concern.

This may surprise some people. Many think the primary objective of components is reuse. They want to deesign something once and use it over and over again in different contexts, thereby realizing large productivity gains, taking advantage of best-in-class solutions, the consequent improved quality and so forth. These are admirable objectives but the main driver today is that things keep changing, and often -- as with business-to-business electronic commerce -- there is no longer any hope that centralized control can be exerted. In such an environment one of the primary objectives of a component is that it must be easily replaceable -- either by a completely different implementation of the same functions or by an upgraded version of the current implementation. This places the emphasis on the architecture of the system, on being able to manage the total system, as its various components evolve and its requirements change, rather than seeking to ensure that individual components are resusable by multiple comp onent systems.

We're focusing on the whole rather than the parts.