The notion of components has certainly caught on. No longer do we simply talk about object libraries. Instead, we have discussions about COM, COM+, CORBA, JavaBeans, and EJBs. And UML has become a pervasive software blueprinting language with many vendors providing tools support-even Microsoft provides a component-oriented subset in the form of Visual Modeler. Larger-grain components, in the form of business objects or business components, are being seriously defined by OMG and others. So components and scripting-or business components and scripting-are becoming the standard by which large-scale enterprise development will be judged. All these technologies, taken together, could radically change the way people do reuse, even though none is revolutionary by itself.

COMMONALITY, VARIABILITY AND FLEXIBILITY

I now believe that agents combined with a workflow language will be the next step in increased flexibility and reuse . Just as JavaBeans have grown into enterprise JavaBeans, so business components will incorporate the notion of agents, providing specific interfaces and using services that enhance their autonomy and robustness. Furthermore, in order for collaborations of business components to provide well-understood support for business processes, they will interact according to a local and global workflow. Thus, to choreograph these collaborations explicitly and flexibly, workflow languages will become the next generation of scripting languages. Also, we've come to realize that you can't simply take random things and reuse them in a context for which they weren't designed. And you can't just design something to make it reusable all by itself. You have to think about how a group of components will fit together, how they will collaborate, and how these components may be individually variable , or variant members of a component family.

Domain engineering is about looking for commonality and variability. Express it somehow and then take advantage of it when you build the components. The work Ivar Jacobson and I did on reuse was to add some extensions to all UML elements that we call variation points, which can be thought of as a generalization of extension points or "hot spots" that allow you to state that some models are variable without saying how they vary. This is key to using UML for the domain analysis of families of systems, right from the usecase and architectural level.

INCREMENTAL INVESTMENT

There is clearly a rich stream of technology innovation, such as enhancements to Java, Web tools, and generators. Then there is aspect-oriented programming, new pattern and modeling tools, and so on. Yet success with large-scale reuse is not just technology; architecture and standards are a social process. The decision to reuse rather then invent from scratch involves culture, education, management, and professional incentives. Many companies have a rather short-term silver-bullet view that limits investment in architecture, component development, domain engineering, and reuse. To change behavior like that, there must be some kind of publicized success that shows it really works and that it pays off. There are successes, but I don't think we publicize them well enough. You don't pick up an issue of Computer every month and see a discussion of the latest and the greatest success. Another element is reducing the cost of entry. By having good components available to cover more of the space you don't have time to fill yourself, you can do all the up-front architecting and domain engineering pretty easily. Many people believe that it's an all or nothing thing. Either you do it properly with domain engineering or you don't bother. But that's not true. You can get incremental benefit for incremental investments. More companies seem to be realizing that they can make domain-specific components according to one or another standards. But things are still very complex. I think, though, that we are able to follow a two-tier strategy . That is, our technology allows some fairly sophisticated components to be written (e,g, business agents) and used with much less sophistication (e.g., scripting) . I'm working on a paper now that is about moving from components and scripts to agents and workflow-in other words more competent components, a richer framework, and a more stylized scripting language.

[DOD96] Reifer, Don, "Reuse Technology Roadmap", Department of Defense, 1996.

[HP98] HP Changengine - an enterprise process flow system. (See http://www.ebizsoftware.hp.com/main1.html).

[jacobson97] Jacobson, Ivar, and Martin Griss and Patrik Jonsson, "Software Reuse: Architecture, Process and Organization for Business Reuse," Addison-Wesley-Longman, 1997.

[jennings98] Jennings, Nicholas R. and Michael J. Wooldridge, "Agent Technology," Springer, 1998.

[omg98] Object Management Group, Business Object Domain Task Force (BODTF)(See http://www.omg.org for information on Common Business Objects, and Workflow Management Facility).

[sims94] Sims, Oliver, "Business Objects," McGraw-Hill, London, 1994.

[sutton97] Sutton Jr., Stanley S. and Leon J. Osterweil, "The design of a next generation process programming language," Proceedings of ESAC-6 and FSE-5, Springer Verlag, 1997, pp. 142-158.

[wise98] Wise, Alexander, "Little-JIL 1.0 Language Report", Technical Report 98-24, University of Massachusetts at Amherst, Sept. 1998.