Iıve followed the market for object-oriented development for more than a decade. The promise was clear: through the use of tools designed to promote reuse with capabilities such as inheritance and polymorphism, developers could avoid a lot of the tedium of the development process. At least this was the theory. Over time, some of the promises of object orientation have been realized. Most of the successful software companies in business today use object-oriented languages and techniques to produce complex and sophisticated commercial products. The use of object orientation has greatly improved the flexibility of these organizations to react to changing user requirements and competitive threats. While some of these leading-edge companies have indeed made good use of object orientation, the same cannot be said about the typical IT organization.
Why has object orientation had only modest success? In the typical IT organization the skills are simply not available to leverage this complex technology. The traditional method for writing objects requires detailed knowledge of language and sophisticated techniques such as inheritance and multi-inheritance. For example, inheritance requires that developers know exactly what they are inheriting. It is all too easy to make a mistake. Objects are a collection of related methods and data. In other words, the typical object would be a button or call to open a database. The developer is then expected to select from libraries of hundreds or thousands of existing objects to create complex applications. While this makes sense in theory, there are, in practice, problems. How does the developer find the right object for the right task? What if there are five or six that seem to do a similar function? Which object is right? Some organizations have created techniques to overcome this problem. One organization I know has set up weekly meetings in which developers explain to each other how a particular object works and what it is best suited for. This approach may seem low tech, but it works! Other successful approaches to implementing objects require a level of discipline and sophistication that most organizations lack.
While there are no silver bullets or easy answers, I believe that components provide a more pragmatic and realistic form of object orientation. I predict that this approach will allow organizations without the expansive resources of some IT organizations to be successful. In this column, Iıll discuss some of the key issues surrounding the emergence of components. These include:
Two types of components exist: fine grained and coarse grained. Fine-grained components are small pieces of developer-oriented functions. They are linked together with other fine-grained components. Coarse-grained components are software packages that contain a collection of related services and attributes. Components leverage the best emerging techniques of object-oriented frameworks such as Java Beans and ActiveX controls. Those developing components also leverage inheritance, polymorphism, method invocation, and encapsulation.
A key distinction between components and objects is the division of labor. With components we create, in essence, two classes of developers. The first group of developers are sophisticated artisans who can use all the power of objects to create fine-grained objects that they then string together to create large-grained business-oriented components. The second group is the traditional corporate developers who understand the business well but do not know how to program in complex object-oriented languages. These developers use components created by the earlier mentioned object-oriented component artisans. These components are "blackboxed," meaning that the corporate programmer is not allowed to change the componentıs content. Thus, a coarse-grained component does not allow inheritance to be applied, which protects the integrity of the component and helps prevent mistakes.
The components that these sophisticated artisans are developing offer a higher level of abstraction than objects. Therefore, they are coarse-grained pieces of application code with well-defined APIs. As with object orientation, components make use of encapsulation. A key difference is that encapsulation becomes one of the foremost techniques for leveraging existing code so that it can be reused on a consistent basis in a new applications environment. In most "pure" object-oriented systems, very little use is made of existing code from prebuilt older systems. In the component model, encapsulation is a fundamental building block. I have seen organizations successfully select key pieces of logic from 25-year-old mainframe systems and encapsulate them as business objects or components to be used within existing systems.
Business Orientation
Another key difference between objects and components is focus. While objects tend to be focused on the technical functions they provide, coarse-grained components are focused on the business task. For example, a financial organization might implement a component called "30-year mortgage calculations," and a manufacturing company may have a component called "cost to produce yellow napkins." There can be no doubt as to what service each of these components is intended to provide.
I predict that we will see the commercial market for components broaden and grow. This will happen first for the enterprise packaged software market. For example, at least 600 companies are already writing application code to work with SAP. While these companies may not think of themselves as pioneers in the component market, that is precisely what they are. But this is only the beginning. Leading packaged software vendors such as SAP, Peoplesoft, Baan, and J.D. Edwards are writing more and more of their code as components. This affords them flexibility for the future so that they can implement new functionality without requiring customers to upgrade all parts of their applications. This major transition to components will have a dramatic impact on how organizations implement software in the future.
When organizations move to a component model of development, it requires a different focus from a traditional process of application development. When developers build conventional applications, the connections between the different parts of the code are hard coded. In the component architectural model, components are tied together by three different types of software: middleware, repositories, and business process workflow.
Middleware is foundation-level software that supports the translation of events and data. It ensures that there are connections between components and between systems. It is the combination of the translation and connectivity that allows components to be integrated together to act as an architected system.
In order to allow developers to share and manage components, it is imperative to have some sort of development repository. This repository becomes the storage space where components are identified and defined so that they can be used broadly. Metadata definitions are also stored in the repository. Another important function of the repository is to keep track of the various versions of operating systems, databases, and software used to build a component.
While middleware has existed for pure transactional systems for several decades, workflow software is much younger. Typically, workflow software has been applied at the desktop. This is changing with the advent of components. Just as middleware is necessary to integrate components, workflow, and business process flow, software is the mechanism that ties pieces of business applications to business practice.
Corporations looking to increase the reuse of key software assets while moving to a model that ensures faster time to market for applications in the future should investigate components. It is imperative that organizations stop writing applications as though they were finished products. Applications are in fact ever-changing business assets. No one would ever assert that a company should keep its products and services untouched over time. Yet the software designed to run those businesses is traditionally written as if it were cast in stone. Components are the best and most pragmatic technique for coordinating business realities with software productivity.