Common Mistakes in Adopting CBD
- What Is Component-Based Development (CBD)?
- CBD Mistake #1: Underestimating the Adoption Costs
- CBD Mistake #2: Not Creating the Right Incentive System
- Conclusion
- Harris Kern's Enterprise Computing Institute
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
As companies are increasingly adopting web services and realizing the benefits of a service-oriented architecture, component-based development (CBD) has received renewed interest. CBD provides an approach to modeling and documenting the services that are the foundation of a service-oriented architecture. These services should be defined in the context of the business processes that an organization provides both internally and externally. This article discusses some common pitfalls of adopting CBD.
What Is Component-Based Development (CBD)?
There are many definitions for the term component, but here's the commonly used definition we'll use for this article: "An identifiable piece of software that describes and/or delivers a set of meaningful services that are invoked via well-defined interfaces."
You may wonder how CBD is different from object-oriented technology (OOT), which also encourages separating the interface from the implementation. While this separation is encouraged in OOT, many organizations don't practice this approach. With CBD, this separation is enforced by explicitly declaring an interface and then an implementation for that interface. In many cases, the client program is actually written in a different language than that of the service provider (as is the case with CORBA and web services).
This is not to imply that the implementation of a component must be in an object-oriented language; in many cases, the implementation of the interface may be a series of applications written in a combination of scripting languages (such as Perl); procedural languages (such as C or COBOL); or even entire systems such as SAP, PeopleSoft, etc. In short, there is not necessarily a one-to-one correspondence between a service and the provider of that service. However, the client should not care about this; all it should need to know is the contract under which the service is offered. This contract defines the parameters required, the expected return values (if any), and any exceptions that may be raised.
NOTE
CBD basically applies the façade design pattern; that is, defining a single service that corresponds to potentially many invocations behind the façade.
This separation promotes loose coupling between the client and the service provider and promotes reuse of functionality without requiring implementation in the same language. Contrast this with object-oriented technology, where reuse typically happens in the same language.
Examples of popular CBD platforms include .NET (for example, Visual Basic calling C#), Enterprise Java Beans (typically Java calling Java), and CORBA (multiple languages, but typically Java and C++).
These are the three basic phases of component-based development:
Planning, analyzing, and designing. Creating interfaces to adapt to rapidly evolving business processes.
Provisioning. This involves sourcing components, which includes determining whether the components should be built internally or purchased from external parties.
Deployment. Dealing with production issues.
In the process of adopting CBD, organizations make a number of common mistakes:
Underestimating the adoption costs
Not creating the right incentive system
Believing the "rapid progress" illusion
Not leveraging existing solutions
Underestimating the barriers of adoption
Not building for commercial quality
This article covers the first two mistakes from the list above: underestimating the adoption costs, and creating the wrong incentive system.
What Is a Framework?
One of the common terms that you'll encounter in any discussion of CBD is framework. A framework is a set of classes that are meant to be extended. Frameworks can be broadly organized into two categories:
System-level frameworks such as application servers (BEA WebLogic, IBM WebSphere, etc.) that provide a set of services such as load balancing, replication, etc.
Business-level frameworks such as the San Francisco project (originally from IBM, now at Alphaworks), which provides business services such as inventory management.
While the examples in the following sections focus on organizations that build their own repositories and frameworks, these problems can occur even when using commercially available repositories (which are quite rare, especially business-level frameworks).