All About: Component Provisioning

2005-05-25

Component Provisioning has its origins in software reuse, which was one of the original perceived benefits of Object Orientation (OO) and Component Based Development (CBD). Time has shown that reuse does not come for free – to be successful, reuse needs to be taken into account across the entire development process. Necessary mechanisms include:

• A comprehensive, scalable and adaptable application architecture to support component deployment • Agreed definitions of the structure, interfaces and content of a component. • Team structures that recognize the difference between component development and solution development. • Appropriate management and reuse processes, including component supply, management and consumption, librarianship and certification mechanisms.

The implementation of reuse facilities introduces the possibility to not only make existing components available to other projects, but also buying in components from outside. Reasons of economics, not to mention the use component-ready application servers and the evolution of Web Services, are driving the trend towards component provisioning. Gartner group estimates that component purchases will increase by 40% per year, to $2.7 billion by 2004. Whether this estimate survives the downturn in IT spending is questionable, however there is undoubted interest in component provisioning from all quarters of IT.

The golden rules of reuse become even more important, in particular the need for standardized, defined component interfaces. One such standard is the Reusable Component Specification from Component Source. This covers XML definitions for:

• Technology – the platforms to which the component conforms • Functionality – the interfaces and their constraints • Distribution – how the component is packaged, distributed and deployed • Commerce – the licensing, contractual information and product reviews

An additional pre-requisite is the existence of a solid, industry-standard infrastructure both for processing and data transfers. According to the CDBi Forum, such facilities have only become available this year, with the arrival of Windows 2000 for COM and J2EE for Java-based components. XML is becoming the de facto standard for data interchange, further greasing the wheels of component provisioning.

According to the CBDi Forum, components available on the open market should be:

• Widely available • Adaptable to many situations • Easy to integrate • Supporting de facto standards • Environment neutral • Process-independent. • Autonomous • Secure • Of appropriate granularity. • Easy to manage • Cost-effective

Component vendors include component resellers (such as Component Source), Package vendors (SAP, Siebel), ISV’s and other software companies (Microsoft, IBM San Francisco). Package vendors are already componentising their offerings, and it is only a matter of time before they start to sell individual components. Component provisioning benefits package vendors in two way – not only can vendors sell individual component, but also they can incorporate other components to augment their own applications. This results in best-of-breed applications that are better able to meet requirements and that offer more flexibility for the future.

As the move towards more off the shelf components continues, the need for standardized architectures grows, such that the selection of a component has minimal or no impact on the architecture. It is not just a case of ensuring application elements. can communicate at a technical level; they must also work together at a business level. One such architecture is the Business Object Component Architecture, BOCA, an OMG initiative. The Web services architecture, in which applications are distributed across the Internet, is a new paradigm that brings architectural constraints of its own. These are still being determined, but are likely to involve components that are deployed as Web services, such that they can be discovered, licensed and accessed from across the Web.

Finally, provision of components requires new types of procurement and delivery channels. A variety of licensing models are being investigated including once-only payments, pay-per-use, monthly subscriptions and risk/benefits-sharing.

Where is Component Provisioning to go in the future? Development would indicate that once component provisioning has broadened outwards, it would move upwards into the domains of business process modelling. Already B2B information flows are being defined and ratified under the banners of XML.org and Biztalk.org, the producers of such facilities have found it difficult to supply B2B without including a capacity for recognising and deploying business processes. Component Provisioning may well end up being faced with the same challenges.