CBD SURVEY: THE STATE OF THE PRACTICE

5 March 2002

by Paul Allen

A recent Cutter Consortium survey gathered data on component-based development (CBD) from 118 companies from around the world, with North America, Europe, and Asia especially well represented. The survey was far-reaching, both in terms of content and audience. The questions covered a range of issues, from business-IT integration and organization to component standards, quality, technologies, and methodologies. The companies range from those earning less than US $1 million to those with revenues in excess of $1 billion.

I begin by looking at the position of organizations transitioning to CBD. There are two basic sides to this issue. First, there's the state of the practice in terms of understanding component concepts. When it comes to business components, we have long sought to break through the barrier -- are we there yet? Second, there's the question of applicability. Is CBD generally applicable, or is it used only on niche applications or selected projects? Let's take a look at each of these issues in turn.

State of the Practice

Figure 1 shows that, for many organizations, CBD is very much a programmer-related activity, with 70% reporting that programmers use GUI components.

Figure 1 -- What is the state of the practice of CBD in your organization?
(Respondents were able to select more than one response.)

When it comes to applying the principle of separation of interfaces to encapsulate implementation details, this number drops to 53%. The difference here is that programmers are applying a measure of component-oriented design in their work, as opposed to the purely expeditious use of components in the 70% figure. The use of components as an analysis concept, as opposed to a design construct, is reflected in the following statistic: 51% of respondents report that business components -- larger-grained components that offer technically neutral functionality -- are modeled separately from any specific implementation. These figures suggest that use of CBD analysis and design techniques has progressed in at least half of the organizations polled.

Scaling up the use of business components involves increasing scope across project and business groups. It's here that reuse comes into the equation, along with the component architectures necessary to nurture it. Our survey shows that substantial numbers of respondents report these reuse and architecture trends (40% and 36%, respectively).

All in all, we have a fairly mixed picture. Another way of looking at Figure 1 is to picture scope increasing from individual programmer at the top to the whole organization at the bottom (ignoring the "other" column). This is actually a huge difference in scope. What surprised me about the survey results was that responses did not reflect this. I had expected a fairly even series of steps from top to bottom. What we have, however, is a high top-most column followed by a gradually reducing series of substantial columns (53% to 36%) from top to bottom. This suggests that, once organizations have an understanding of CBD principles, scaling up is less of an issue than we might think. Certainly the use of business components are far more advanced than might have been expected in their journey across the chasm between early adopters and early majority.

Project Coverage

The somewhat optimistic prognosis resulting from the previous question is tempered by the results of our next question, which focused on the types of projects in which CBD is applied. The overall message illustrated in Figure 2 is that CBD is applied selectively -- only 12% report that CBD is applied to all projects.

Figure 2 -- In what projects has your organization conducted CBD?
(Respondents were able to select more than one response.)

Respondents are fairly evenly distributed on the question of whether CBD is used on selective projects, pilot projects, or experimental projects (53%, 50%, and 42%, respectively). This shows that, for the great majority, CBD is one tool in the bag, rather than a holistic and multifaceted approach (which is in fact how I have come to view the term). The relatively high percentages for pilot projects and experimentation also indicate that CBD is a long way from being mainstream. So given the apparent optimism that emerged from the analysis of the state of the practice in terms of business component coverage, what's going on here?

My own experience is that many organizations have come to view CBD as biased either toward engineering of reusable software or toward rapid assembly of user interfaces using visual programming environments. The fact that 53% of respondents report that CBD is applied on key projects reinforces this message. While these types of activity are necessary ingredients, as I have argued many times before, my view is that CBD is more than the sum of these isolated parts. It is an overall approach that has many threads. In particular, it's about aligning business needs with software capability and demonstrating return on investment in a highly responsive way. Perhaps the time is right to lose the CBD tag.

-- Paul Allen, Editor, Component Development Strategies

[For more information on the results from Cutter Consortium's CBD-related survey, see the November 2001 issue of Component Development Strategies, available from Cutter Information Corp. at +1 800 492 1650 or +1 781 641 9876, fax +1 800 888 1816 or +1 781 648 1950, or e-mail service@cutter.com.]