- 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 #2: Not Creating the Right Incentive System
A major inhibitor to successful CBD adoption is a failure to create the proper incentive system. While it may seem paradoxical, early phases of adoption often require more time to reuse an existing asset—for the simple reason that many projects are used to building their own components on an as-needed basis, rather than explicitly searching for an existing asset. (This is especially likely in a large organization.) Thus, a team should be rewarded if it properly reuses existing assets or identifies extensions necessary to benefit the enterprise in a larger context, because both of these activities require extra time. Without this reward system, the project teams will otherwise focus only on delivering their own project, and won't contribute to the larger effort.
Likewise, if a team identifies a new component and adds this component to the repository, that team should be rewarded or at least recognized. In a large organization that has a software infrastructure group dedicated to producing reusable assets, the team would produce the initial specifications and then hand it off to the infrastructure group. These specifications are often documented in use cases and a high-level interface (such as an API). The reuse group would then take this API and approach other teams to see how the component could be made even more reusable. But the quality of the component would be the responsibility of the infrastructure group.