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

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

HP Laboratories

griss@hpl.hp.com

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.

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:

• Time: Rapid product development and market agility are critical to the development of Web-enabled distributed measurement products. HP management has identified these factors as critical to success. How should this play out in terms of changed processes, new architectures, business measures and organizational structures?
• Process: Process changes and improvements will be needed to move from a feature-driven to a schedule-driven organization. What sort of standard processes and process maturity levels (such as SEI CMM level 2 or 3) should be selected? How do we get these into widespread use in the most expeditious way?
• Organization: A variety of cultural and organizational issues impede effective ways of working with architected platforms and components. Who owns standards, architectures, and platforms? What stops people from sharing? What encourages NIH? How do we systematically address these issues? What organizational, management and metrics changes are needed to encourage the change?
• Coordination: Coordination between new and ongoing technical and process improvement initiatives. What are the connections between new technologies and strategies for development for the Web, improving process predictability, improving quality and decreasing cycle time? What are the priorities? What should we do first? What architectural implications and other standards need to multiple initiatives? Who owns the architecture?
• Technology: Common architectures, reusable components and leveragable platforms are key elements to achieving decreased cycle time. What notations, standards and technologies should be used? How should they be introduced? How do standard tools and platforms apply?

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.

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:

• The organization must have a visible, articulated and compelling need for dramatic improvements in cycle time, cost, productivity and/or agility.
• The organization must be producing software (applications, embedded systems or key subsystems) that form an obvious product-line, application family or coherent "domain."
• These two factors provide a context of organizational commitment in which some form of reuse can be justified economically, technically and strategically. . Component-based development becomes of strategic importance. Management will pay attention.

• Applications, systems and components must be purposefully designed and structured to ensure that they fit together, and that they will cover the needs of the family or domain.
• A well defined, layered, modular structure, and various design and implementation standards will be of great help. Object-oriented modeling and implementation are also extremely useful.
• Ad hoc reuse and leverage of pieces of existing software, or even the building of systems on common platforms and frameworks, do not ensure the coherence of a set of compatible, reusable, maintainable parts. A system architecture for reuse must be defined and maintained as an organizational asset.

• Distinct software development and maintenance processes for architecture, components and applications must be defined and followed.
• These processes must explicitly incorporate reuse. They systematically identify and express commonality and variability, and include standards for designing and packaging components for reuse.
• Processes will evolve as the situation changes and experience and adoption grows. This will need careful management to standardize a set of reusable process elements that can be flexibly combined and customized.

• Long-term management leadership and commitment will ensure that the organization is structured, trained and staffed to follow the processes and conform to standards.
• The organization will need to have several distinct subgroups responsible for creating, reusing and supporting reusable components. These teams must be trained and willing to follow the specific processes.
• The organization must be ready for the requisite level of change, and be willing to "stay the course."
• People must have well define reuse-oriented jobs, with appropriate training, skills and rewards for effective reuse performance.

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:

• We use the Unified Modeling Notation (UML 1.0), to model components and system.
• We build upon a UML-based OOSE architectural style and method. OOSE defines the constructs, models and steps which are needed to transform requirements into models and ultimately software. (OOSE is the base method for the Rational Objectory process)
• We have added UML-based extensions to model layered architectures, reusable and customizable components, component interfaces and frameworks.
• We use several incremental, iterative software development processes, which allows us to build up the architecture, reusable components and applications in a stages.

• We use OO models, called business models, to precisely define the details of the software processes, and how they interact.
• We use these models to also define the roles of various workers in the software organization, and how they can be effectively grouped and managed.
• Finally, these models can be used to define the workflow (or process scripts) that guide these workers.

• This provides a standard set of steps and questions that identify the scope of the transition, and determine the best organization structure to match the needs, level of commitment and existing situation.
• A specific organization change roadmap is designed, involving an assessment of scope, readiness for change and incorporates a variety of change management pragmatics, such as reuse pilots and staged changes.

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.

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:

• Directive: Management issues a directive to reengineer, determines scope, articulates commitment and establishes am empowered reengineering team.
• Envision: The reengineering team starts by envisioning the new organization, and establishing what sort of RSEB it might be.
• Reverse Engineer: The team uses reverse engineering techniques to determine essential aspects of the existing organization and its processes.
• Forward Engineering: Forward engineering is employed to develop a detailed model by customizing and extending a generic RSEB process and organizational model.
• Install: Finally, several teams work together while installing the new processes and organization

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, http://www.hpl.hp.com/reuse . More information on our book can be found at http://www.awl-he.com/computing/authors/0-201-92476-5.html

Please also feel free to email me at griss@hpl.hp.com.