At the April CBD Forum meeting, and subsequently on-line, we conducted a survey of Forum members regarding the status of CBD. Here we present the findings, and make observations on some of them. Thanks to those who took part.

It appears a fairly even race between DCOM, CORBA and JavaBeans. Perhaps more interesting is that 56% believed that they would be using multiple component models - many are already doing so. This reinforces the need for development approaches that allow porting between them, as detailed in last month’s journal.

Where will components come from? Clearly, just about everyone believes existing applications are a good place to start. Development tool vendors will, no doubt, be relieved to see that there is a healthy activity forecast for in-house build. The only sector to be concerned would be vendors of monolithic packages, as companies switch to buying individual components instead. However, enlightened package vendors are already facilitating this move themselves.

Two areas stood out in the development tool adoption questions. Firstly, UML looks set to become the standard modelling approach for CBD. This is not a great surprise, except for the speed with which it is being taken up. A standard modelling approach brings obvious benefits and is essential if developers are to quickly understand which components are available to be reused or acquired, irrespective of their source.

At first sight, a pendulum swing away from the RAD era would appear to be underway, with ‘future application adaptability’ being ranked top, and ‘speed of delivery’ ranked bottom. However, this probably reflects that: firstly, thanks to RAD tools, some organisations already have the speed issue partly addressed; and secondly, if existing applications were more adaptable to change then the need to deliver replacement applications as quickly as possible would diminish.

CBD promises the best of both worlds - the ability to adapt by reconfiguring components or only replacing those affected by change, and also to deliver new applications even faster by reusing or acquiring tried and trusted components.

However, componentisation alone does not solve the requirement to adapt applications to technology change, the second ranked criteria. Therefore, development tools that operate at a higher level of abstraction than 3GL code are essential for portability across platforms and the technology divides, eg. host/terminal to client/server to the Internet.

Although one could concoct a story for how CBD would benefit every one of these scenarios, there are several where the case for componentisation is much more obvious Several of them also require Enterprise Application Integration (EAI) to bring together disparate sources of applications, components and information. Finally, some may also benefit from implementing components and applications with a rules-based approach that allows the rules to be tailored by end-users without programmer intervention.

Components and applications that provide a more generic service, rather then being product-specific, would have obvious benefits when introducing new products quickly, and we have observed that, in information-based industries, eg. finance and insurance, enabling end-users to define product rules themselves, without programmer intervention, is yielding positive results.

Component technologies can certainly assist in information availability. For example, providing end-users with direct access to information through component interfaces, rather than pure SQL, is more secure, and can be used to provide users with derived information, rather than raw data. OLE DB provides a good example as it enables a wide variety of data sources (not just RDBMS) to be presented through a unified interface, straight into end-users desktop environments.

Restructuring often brings a requirement for new applications to support new workflows. Whether this is prompted by organisational restructuring, or by changes in the value chain, the separation of business components from their assembly into an application workflow will enable application restructuring to take place more rapidly.

Adopting a service-based approach, ie. focusing on reusing what the service is, not how it is provided, is also important in enabling restructuring that involves the integration of disparate systems, eg. because of mergers and acquisitions, or calling third-party services. The ability to change how a service is provided, or who provides it, without impacting calling systems, is a key attribute of CBD.