Improved Cycle Time in the Reuse Drive Software Engineering Business 

(Object Magazine, August 1997 -4/26/97)

Martin L. Griss, Laboratory Scientist, Software Technology Laboratory,

HP Laboratories

Reuse is the best way to reduce cycle time

This column continues my exploration of systematic software reuse, and in particular how it can contribute to the critical issue of shorter time to market. By the time you see this column, my new book on software reuse should have just appeared. In this column, I will therefore introduce, briefly summarize, and "blatantly" advertise introduce the bookJ . The book, "Software Reuse: Architecture, Process and Organization for Business and Success," offers a comprehensive and systematic approach to orchestrating the large-scale investment and change needed to establish an effective reuse program. Large-scale reuse and a systematic change roadmap are of tremendous help in systematically and effectively dealing with a forced march to rapidly decreasing time to market.

A reuse program must be motivated by business need

In my previous columns I stressed the importance of architecture, process and organization in designing and running a reuse program. In this column, I explore how a systematic, architected, component-based software reuse program must be aligned with, and driven by, a compelling business reason, such as the critical need to decrease time to market to meet competitive market forces. An effective reuse-based attack on the reduced time to market depends strategically on a clear management and organization commitment to develop a long term, flexible product line or product portfolio. With an appropriate level of management commitment, typically evidenced by a strategic statement from the CEO to improve the speed with which new products are developed, change can begin. Energy and resource can be directed to establishing an appropriate reuse-oriented process. People can invest time in creating a software development organization specifically structured to support reuse. Managers and supervisors can mount programs to address the well-known social and cultural impediments to reuse.

Large scale reuse requires a systematic, engineered approach to building systems.

One requirement is a common engineering notation to describe systems. A standard architectural design notation and a compendium of common, reusable architectures and designs provide a base for more reusable components and frameworks. Used consistently within a reuse-oriented process, architected components and frameworks enable high levels of reuse. And high levels of reuse can lead to dramatic reductions in product development time.

In previous columns I briefly described a long-term collaboration with Ivar Jacobson of Rational Software Corporation and our goal of integrating reuse process and pragmatics into an OO development method. Ivar and I have worked together since 1994 to develop a coherent approach to structuring architecture, process and organization for effective object-oriented and component-oriented reuse[Griss95,Griss96,Jacobson96]. We have integrated techniques of systematic software reuse into Ivar's Object-Oriented Software Engineering process (OOSE)[Jacobson92], building on the new Unified Modeling Language (UML) for object-oriented systems[Booch97]. We call our systematic approach to practical, large-scale reuse the "Reuse-driven Software Engineering Business" (RSEB). An RSEB is a software development organization specifically structured to employ systematic reuse-based software engineering and management techniques as a key business strategy. Details can be found in our book, co-authored with Patrik Jonsson, published by Addison-Wesley-Longman in May 1997.

Model-driven development using a standard modeling language.

By working with Rational, the leader in object-oriented methods and tools, I hope to make our systematic reuse approach become widely visible and of broad impact. Rational has invested great effort in establishing the UML as a standard software modeling notation which will provide software designers and architects an unprecedented opportunity to develop and reuse precise and widely understood blueprints for a software. Rational has brought together three of the most influential OO methodologists (Booch, Jacobson and Rumbaugh) who spent several years to develop the UML as a synthesis of their individually influential OO methods (Booch, Objectory and OMT.) Working with many others, they have promoted an improved UML as a potential de facto standard for sharing understandable OO models of software and systems. Amongst others, Hewlett-Packard, Microsoft, TI, Oracle, Unisys, IBM, MCI System House, Object Time and Platinum, are working closely with Rational to prepare and refine the UML for standardization by the Object Management Group (OMG)[Booch97].

Furthermore, Rational has developed several recent alliances with Microsoft to bring OO design methods and tools into more common use. Microsoft has endorsed the UML and developed a Visual Modeler tool which supports a subset of UML, appropriate for modeling components and component-based systems. Microsoft has also developed a Repository with TI, used for storing and exchanging UML models between tools. Most important to people developing software in the Wintel environment, the Visual Modeler and Repository will be distributed as a standard part of Visual Studio, along with VC++, VB, VJ++ and other tools. This UML Repository can be accessed by other tools as an OLE automation server, and used to integrate several tools into a model-driven environment. This decision by Microsoft to support UML notation, and provide compatible tools means that model-driven component-based software development using widely available standard components, tools and notation is one step closer to becoming common practice.

Why is all of this important for improved time to market?

As an example of the issues typically confronting today's corporations developing software-intensive products for rapidly moving Web-enabled markets, I discuss the problems facing several organizations at HP developing families of measurement systems. These issues confront anyone contemplating systematic reuse as a strategic or tactical response to business pressures:

While I will not try to directly answer all of these questions in this column, I will set the stage by offering a systematic approach to addressing these sort of questions and issues. Architecture, reuse, standards, process, organization and business issues are closely related, and must be addressed together within a common framework. The RSEB described in my book is such a framework.

A systematic framework for reuse success

In previous columns, I described success factors of systematic reuse. The factors can be rephrased and regrouped to highlight a more systematic framework. A successful, large-scale reuse effort must be:





Reflecting upon these factors as I came to understand the magnitude of the changes needed to install pervasive organizational reuse, it became clear that we should adopt a business process reengineering (BPR) approach to restructuring a software engineering organization for large-scale reuse[Griss95]. As I looked at how an OO software modeling method should be used for the architecture, I also looked for compatible ways to model processes and organizations. This led me to build upon a powerful, well-known OO method that could deal not only with the modeling of architecture and components, but also with software process and organization design - and this is how I came to work with Ivar Jacobson[Griss96].

We based our collaborative work on Jacobson's use-case-driven architecture and process modeling frameworks - Object-Oriented System Engineering (OOSE)[Jacobson92] and Object-Oriented Business Engineering, described in "The Object Advantage"[Jacobson94]. By so doing, we have integrated the key aspects of successful reuse programs into a coherent model. Our approach relates all processes (activities and supporting infrastructure) and products (architecture and components) to the business goals of a reuse driven software engineering business.

Our systematic approach has the following elements:

OO model-driven component and application development

OO Business Engineering to model reuse process and organization

OO Business Engineering as transition framework

Integrating architecture, process and organization in the RSEB

The RSEB is run as a software engineering business. This means that the software engineering goals are key to accomplishing the organization's business goals, and that as a consequence, the software organization itself is operated as a business, with well-defined customer and financial objectives. In the HP instrument divisions I mentioned above, a dominant and compelling business goal is to reduce product development times, yet retain market agility within and across product families. Examples of these families are applications and systems which are built to meet different customer and country needs by combining and customizing reusable components: micro-wave instruments built from common firmware components, and Telecom switches (such as Ericsson' AXE) and compatible test systems which are configured to a variety of situations.

A strategic decision to establish one or more reuse-driven business units within these instrument organizations is technically feasible. As a reuse-driven software organization, such business units are engaged in producing multiple, related applications, centered and optimized around the production and reuse of components. These applications commonly form a product-line or product family. As a business, this organization must understand its customers, and serve their needs, while at the same time effectively achieving its profit and expense objectives. Such business tradeoffs must be managed using well defined economic, product and process measures.

Figure 1 summarizes the key elements of the RSEB, using an informal OO business engineering notation. The ellipses are business use cases, representing software engineering processes, while the rectangles are systems, represented by sets of UML models. The stick figures are actors, representing people or organizations the RSEB interacts with.

Figure 1 The elements of the Reuse Business. The ellipses represent processes, the rectangles represent systems, and the stick figures represent the environment within which the Reuse Business functions.

Each system in Figure 1 is expressed as a set of OO models using OOSE and UML notation. Components are public elements from the various models, including use cases, analysis types and design and implementation classes (code). Components are not used alone, but in groups called component systems. Component systems are constructed by the Component System Engineering process. Applications are defined by a set of connected models and software, called an application system.

Most important to shaping the applications, and ensuring high levels of reuse is the architecture of the reusable components and applications built from these components. Applications and components interact with each other in a layered, modular architecture. We visualize the architecture as illustrated in Figure 2. The RSEB systematically engineers a layer of related application systems, at the top. Behind the front row of applications are related versions of the applications. The application-specific software is engineered in the Application System Engineering process by extensively reusing component systems, which we imagine as existing on several lower layers. Below the application layer are components reusable only for the specific business or application domain area, such as banking systems or microwave instruments. This layer includes components usable in more than a single application. The third layer of cross-business middleware components includes common software and interfaces to other established entities, such as graphical user interfaces, ORB's, etc.. The lowest layer of system software components includes interfaces to hardware, such as an operating system interfacing to the computer (or to its built-in instruction set).

Figure 2 The basic architecture on which a Reuse Business rests is three layers of components that go into the application systems at the top of the diagram.

Business use-cases are used to model the interaction of an actor (person or external organization) with the business organization[jacobson94]. These business use-case models help identify core processes within the organization. When these models are mapped onto business object models, they display business workers as objects, and the entity objects the manipulate. They can be used to define the responsibilities of the workers, the workflows they enact, and the information systems and tools they use. Subsystem packaging of the business models level allow us to model various organizational structures.

Incremental transition to an RSEB

The systematic transition of an existing software organization into an RSEB is based on the OO Business Engineering framework[Jacobson94]. This is a particular approach to establishing and executing Business Process Reengineering (BPR), making use of explicit business models expressed in UML notation. The OO Business Engineering approach has several stages that prepare, define and execute a transition:

Each of the steps includes specific organizational change management guidelines, such as the use of champions and pilots, and some reuse pragmatics, such as the use of incremental, pilot driven reuse adoption, and distinct reuse-maturity stages, as discussed in the previous columns. To develop the appropriate roadmap, it is important to assess both the clarity and urgency of the business and domain drivers, as well as the organization and process maturity.


The RSEB approach provides a systematic framework for the definition and transition to a reuse-driven organization. In future columns, I will discuss in more detail several of the RSEB models, mechanisms and processes that support systematic reuse.

The advent of UML as a common modeling language for OO modeling and reuse, and its promised support by many tools, such as those from Rational and from Microsoft, provides an exciting opportunity. A widely accepted, common software "blueprinting language"can be used by architects and engineers to describe complex systems and precisely define their reusable components. This will be of great importance as modern software engineers acquire, develop and share more reusable components.

Some of my reuse related columns and papers, and other related reuse information can be found online at my web site, . More information on our book can be found at

Please also feel free to email me at


[Booch97] G Booch, I Jacobson and J Rumbaugh, "The Unified Modeling Language," Technical Report, Version 1.0, Rational Software Corporation, January 1997. (See

[Griss95] ML Griss, Software reuse - a process of getting organized, Object Magazine, May 1995.

[Griss96] ML Griss, Systematic OO software reuse - a year of progress, Object Magazine, February 1996.

[Jacobson92] I Jacobson et al, Object-oriented software engineering: A use case driven approach, Addison-Wesley, 1992.

[Jacobson94] I Jacobson, M Ericsson and A Jacobson, The Object Advantage: Business process reengineering with object technology, Addison-Wesley 1994.

[Jacobson96] I Jacobson, Succeeding with Objects: Reuse in Reality, Object Magazine, July 1996.