If you could begin a new enterprise application with a clean slate and choose any paradigm as the basis for your development efforts, what would it be? I think most modern developers would say that component-based development is the leading architectural strategy du jour. You'll hear arguments for or against ActiveX and JavaBeans, and some will cling to classic object-oriented development (read: writing reams of raw C++ or Java code).
But application developers who care about rapid delivery, high maintainability, and most important, creating business value would probably agree that components are the way to go.
OK, no argument from me. But what about two, three, or five years from now? Will today's component-based architectures and applications remain viable or provoke regrets? Unless you are absolutely sure you are building a short-term disposable application, you must design your system for growth and evolution, not just deployment up to your next job change.
Most application development technologies have a short shelf life before they are supplanted by a successor. This happens for many reasons, but in general, there are two kinds of driving forces that propel new approaches. Sometimes entirely new requirements arise, and existing technologies just don't apply. But sometimes the problem being addressed is fundamental and does not change, but accumulated experience with an emerging (or now-established) technology begins to reveal weaknesses that weren't immediately obvious.
Component-based development doesn't really address new problems; it is a different way to package and reuse functionality in large applications. As Judith Hurwitz (see "Enterprise Manager") and David Linthicum (see Application Architect) explain in their columns this month, components are an evolutionary refinement of object-oriented development. Both let you reuse code, but components abstract functionality to a higher level than programming classes or even executable functionality buried in DLL files. That simplification is a big value add-on, especially for business application developers.
A long-term view of component-based development must expose two questions. What kinds of fundamentally new application-development problems might arise for which components are not an appropriate architectural solution? And what pitfalls of components will force architects to try another approach that overcomes the flaws of component-based development? The first question is too deep for this brief editorial, but answers to the second question are coming into focus.
Components take inheritance out of the hands of component assemblers. If a component is missing an essential property or method, the developer cannot subclass the component without access to the source code. If the component is not written in a language that supports inheritance, then a sibling that is almost but not quite identical must be cloned. Six months later developers must grasp the fine distinctions between the original and derived components. If the source code is not available, what's your choice ? Can you rewrite something from scratch? Should you spend time researching something else better?
Components do indeed sidestep some programming complexity. But complexity is a pervasive problem that comes in many forms, two of which are having to manage large numbers of things and the exponential growth in the resulting number of relationships or interactions among many things.
Large systems are complex because they have a lot of code. In all fairness to components, this challenge changes form, but it does not go away. Whether your applications are composed of a slew of source code files or a bag full of JavaBeans or ActiveX controls, a lot of code is a lot of code, period. It must be managed, as David Linthicum explains in his column. Vendors are addressing this requirement in various ways. If you're not, start now. But realize that component management must address not just individual components but also where and how they are used and more of the dependency relationships that can trip up maintenance developers. If another paradigm dislodges component-based development, I suspect that improved manageability will be its calling card. However, it will take a little more time before we know if the problem of component clutter is one that really can be managed.
Components and component-based development have many advantages, and modern developers are right to embrace them. But architects must also lose a little sleep worrying about what's less than ideal with components and plan for the era when something else eclipses them. What's wrong with components? I'd like to know what problems you have had developing with them. Please write to me at mfrank@mfi.com.