Hang On To Your Component Hat; You're In For A Wild Ride

I recently attended the Forum for Component Based Development and Integration's (CBDi) Buying and Selling Components SIG meeting, hosted by Objectools, and the JC2 International Conference for Java Technology. At each conference, there were strong indications of growth in the component marketplace. The number of organizations adopting components continues to increase at a rapid rate. There is also strong growth in the number of companies developing components for sale. The online market is still expanding as new players enter the field, and support for companies who want to become component service providers (CSPs) is now available. All in all, it's an exciting story.

In speaking with different developers and vendors, it's clear that opinions differ about what constitutes the component marketplace. For example, ComponentSource is typical of the companies promoting what they call "open market components." Think of these as shrink-wrapped components, boxed and ready to use. Other companies working on higher level component frameworks see the need to bundle implementation services with components. This is because the frameworks are complex and you need additional training to consume them effectively.

Other organizations are looking to provide component functionality as a service. Similar in nature to application service providers (ASPs), these companies are known as component service providers. They charge for the use of a component, which they host, on a per-transaction basis.

Finally, there are companies that make whole application packages available as components. When you read estimates of market size, you need to be aware of which of these views is incorporated in the estimates. Estimates of market size run from $1 billion in 2002 for open market components to $33 billion in 2003 if you include all of the above views.

Time to market is the single biggest driver of this growth. Companies must adapt to changes in the business environment, so IT organizations must deliver timely solutions or risk being outsourced. Similarly, companies are unwilling to spend money with organizations that cannot demonstrate the business value of their services. Business units want value, and are thus demanding that IT organizations do more to lower costs. Furthermore, as businesses build more customer- and supplier-facing systems, they need them to function flawlessly. Quality becomes a key requirement. IT organizations are moving to component technology because they can't achieve these goals doing development the old way.

Making inroads
But market inhibitors still exist. Users cannot find the components they are looking for. Current estimates place the number of components available for sale at just more than 4,000. Many believe the critical mass for the marketplace is between 20,000 and 40,000 components. The good news for users is that the number of available components is doubling every year. The bad news is that even if the components users want are available, they might not be able to find them. Because components can be described in many different ways, consumers of components have difficulty matching requirements to availability. Clearly, standards that let components be described and classified in a consistent manner would help with this problem.

Some observers wonder if the open source movement will inhibit the component marketplace. This seems unlikely. One conference attendee tried to imagine trusting your heart pacemaker code to a group of open source developers. Their conclusion: It wasn't likely to happen. Likewise, they felt that businesses would not trust open source development for mission-critical apps. This seems a bit harsh, however. There are areas where trusting your business to the whims of an open source group seems unlikely, yet just look at the inroads Linux and Apache have made into the enterprise. There is both a role and a place for open source software in the enterprise. When it comes to components, it may be that firms that want to be in both arenas will be more like CSPs or implementation service providers. They could base their software on open source code, but surround them with services that minimize the work developers need to consume the code or its services.

One of the more interesting aspects of the conferences was the business buyer's view of components. One financial services firm described the contract it created when purchasing a large component framework. They explained how they achieved aggressive discounts, unlimited seats, developer tools and training, as well as an option to use the framework globally. While it sounds like great negotiating, it turned out to be an unsuitable, narrow, vertical contract.

The firm later decided that it needed to create a contract that let them buy a vendor relationship, not just a component framework. They also needed to minimize their up-front investment. For its next $2 million component framework, they negotiated a per transaction usage fee that let them minimize their initial capital outlay. In addition, a sliding fee based on the percentage of the business that used the framework was imposed. This new approach kept them in close partnership with the vendor. High-level component frameworks will require new approaches to licensing and usage. This is one reason CSPs are starting to emerge.

ComponentSource is the oldest and largest component marketplace, but others such as Flashline and Objectools are growing. And new players, such as Logic-Library, are emerging. IntellectMarket just launched its ComponentPlanet site, but is still operating pretty much in stealth mode. Another site making its debut is CodeMarket, which matches component developers with buyers who need custom components built. I even had one fellow come up and tell me about his great business idea. He was going to build a Web site and sell components. What a novel concept!

Layers, CSPs and standardization
At the CBDi meeting, co-chair David Sprott drew a diagram to clarify the types of components and buyers in the marketplace. According to Sprott, the top layer has business buyers interested in purchasing solutions to their problems. They are not overly interested in components, but vendors in this space can use components to their advantage. In the next layer down are IT architects who purchase frameworks and architectures that are deployed across an enterprise. In the third layer are project managers who purchase common business and technical components. The final layer consists of developers who purchase GUI components and other widgets. While there is some overlap between layers, it is critical that component vendors understand the differences in the layers if they want to succeed in the market.

Want to become a CSP? Verge Technologies Group announced its offering, which is a hosting service for EJBs. The service lets users deploy their components and then make their services publicly available over the Internet. The site charges both hosting and resource usage fees.

Another firm, SoftwareMarkets, provides a free development environment on its site and will then host your app. They provide a J2EE environment, relational and object databases, as well as development and deployment tools—all for free. SoftwareMarkets makes its money by charging per-transaction fees for the hosted application. These types of services provide interesting opportunities for you to become a CSP or ASP.

Standardization is an area where much work remains to be done. I mentioned earlier that one of the difficulties developers have is finding the components they need. Rational has responded to this need by working to create a Reusable Asset Specification standard. This is a work in progress, but it could greatly aid both vendors and buyers in classifying components for purchase and reuse. Also mentioned at the conferences: Developers want more standardization in their infrastructure platforms and standardized component frameworks, such as those for B2B applications.

There is a lot going on in the component marketplace, which continues to evolve to meet business demands for quick and cost-effective quality solutions. If the predictions are correct, we should see this increasing demand leading to explosive growth in 2002 as the market reaches critical mass. Hang on tight. It's going to be a wild ride.

About the Author

John D. Williams is a contributor to Application Development Trends. He is president of Blue Mountain Commerce, a Cary, N.C.-based consulting firm specializing in enterprise, domain and application architectures. He can be reached via e-mail at [email protected].