Unlike procedural or object-oriented programming, where one small change may ripple through an application and cause havoc, components can be removed or added at will with local or no effect. Components may always be added or subtracted to an environment to add functionality or reduce requirements, or change features to run in any environment without completely breaking an entire application. In this way, component code is recycled and nothing of value is lost or redundant. In an ideal world, IT organizations would be able to build or buy a suite of components that when assembled, provided a complete application or applications. This is not now possible, but many leading organizations are beginning to realize the benefits of components, as evidenced by the popularity of Java, ActiveX, and many other object and component technologies.
Components are useful, but they also introduce new complexities.
Communication is often a tedious issue to resolve between components. They must be able to talk to one another, which requires developers to provide well organized and defined interfaces. Developers will also feel a need to discover new modeling techniques in order to correctly determine and anticipate new component interaction. The methods and actions and the types of components available for developers must be accurately and thoroughly described for them to be of any use. IT management will be required to choose a component object model that defines and encapsulates objects and acts as a container to facilitate component development.