- 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
CBD Mistake #1: Underestimating the Adoption Costs
Many organizations are lured by the promise of reduced development costs through reuse. However, reuse is not free; it requires substantial initial costs in the form of planning and infrastructure development. In most organizations, planning is seen as an unnecessary overhead activity and is often sacrificed as companies race to reduce costs. Unfortunately, this shortsightedness often results in significant rework that ends up costing substantially more than any expense that may be incurred by upfront planning.
To fully leverage CBD and to build a service-oriented architecture, the adopting organization must commit to modeling and documenting its business processes. As mentioned earlier, the business processes are the foundation of CBD; in many cases, the adopting organization finds that it doesn't understand its business processes well enough to document them. Thus, the adopting organization should budget the time necessary to first understand its processes (if it hasn't already performed this step).
A common mistake in early cases of CBD adoption (and OOT, for that matter) stems from creating services that are too granular. This often leads to repeated invocations to perform even a simple service. To create a robust service-oriented architecture, the adopting organization must define services at a meaningful business level and then model components at that level. Defining services at the business level results in a coarse-grained interface (one invocation by the client to perform a business-level service); this further results in loose coupling, leading to reusability.
TIP
A good litmus test to determine whether the interface is at the appropriate level is to ask the subject matter experts whether the names of the defined services are in their everyday vocabulary. If not, it's usually an indication that the services are defined at the system level rather than the business level.
Additionally, the adopting organization must often develop an enterprise architecture—along with defining associated standards such as XML templates, naming conventions, and so on—and require that individual projects adopt this architecture. (As hinted at above in mistake #5, the adoption process itself is a major challenge in many organizations, because it requires a change in behavior.)
As each project is built, it can contribute one or more components to the repository, eventually creating a critical mass. (Critical mass is a term often used in technology to explain a level of adoption necessary to gain success in the broader market.) However, this doesn't happen overnight, much to the chagrin of many organizations. According to Ivar Jacobson, a leading authority on reuse, it takes about 50–150% more effort to develop a reusable component than a non-reusable component. Additional time is required to train developers and managers on how to even approach developing something for reusability. This extra effort should be budgeted appropriately into the development plan.
To demonstrate a commitment to reusability, many organizations have explicitly defined the role of Component Engineer, whose main task is to work with multiple projects to ensure that assets are built for reusability and that projects are actively using existing assets.