Design patterns at Motorola - Ron Crocker

Much like AT&T, Motorola has several independent efforts investigating the use of design patterns for system development. Unfortunately, I can only discuss with any substance the effort that I'm involved with.

Design patterns vs. software architectures

At Motorola Cellular Infrastructure Group (CIG), recent efforts in applying design patterns to the development process have centered on the relationship between software architecture and design patterns. For some time now, the focus of the systematic improvement efforts at CIG have centered around finding an approach for system development that allows for ``large-grained'' reuse [13]. Initially, this program focused on the use of object-oriented approaches early in the life cycle, primarily to provide a foundation for this reuse. These attempts were not totally successful. Analyzing these projects indicated some common characteristics that effectively limited any large-grain reuse, including:

• Strong coupling of OO artifacts within a single product
• Short-term needs superseded longer-term needs, even when the benefits were clear.

These findings are not particularly surprising given the strong product-oriented culture of Motorola. However, reaching corporate goals of a factor of 10 improvement in time-to-market requires substantially less work in development - you simply can't do the same amount of work in 1/10th the time.

Enter the centralized software architecture organization, lead by the Strategic Software Technologies organization within CIG [14, 12]. As an organization, CIG has accumulated considerable domain expertise and has some very seasoned software architects. In evaluating several purported software architectures, again we found some common symptoms:

• A lack of preciseness in the specification made them ambiguous.
• The architects developed their own terminology to talk about concepts that we would have immediately recognized had they used ``our'' vocabulary.
• We did not have direct/immediate access to the architects.

Each of these problems led directly to communication problems, which lessens the effectiveness of the architecture. Because the architectures are ambiguous, they can be interpreted in ways other than intended. Because the language was ``foreign'', the ambiguities tend to be amplified and the architectures become product-centric. Finally, questions about the architecture have nowhere to be directed and are hence left unanswered.

Our search for technology solutions turned to design patterns. From previous readings, we knew that design patterns offered an approach for describing architectural entities independent from their implementation. We were concerned about the roots of design patterns coming from the object-oriented community, since our organization has little OO experience. Our approach was to simply not use design patterns in an OO form. We would use design patterns to capture problem-domain-specific entities in an implementation-independent way for sharing across projects (and products).

Current status

So far, we have a small catalog of design patterns focused on (in telephony terms) fault management. There is already an implicit design pattern being used in many of our products for handling faults in the equipment. It's robust and understood by the senior technical staff. The problem with this pattern is that it's only implicit. It exists in the heads of the senior people and in the code. In the cases where we reuse this pattern, the pattern is ``rediscovered'' from the code and re-implemented, often with minor improvements. None of these improvements, however, affect the basic ``higher-order'' pattern. These are the sort of patterns that we will be cataloging. Based on some near-term results using the fault management pattern, other problem areas are being identified for ``patternification''. Our expectation is that these patterns will interact to form a fabric of patterns for telephony.

Pattern applicability spaces

Figure 1: Architectural Spaces

We have a model of the world depicted roughly in Figure 1. We separate the development process into three large ``buckets'': Products, Problem-Space (entities), and Solution-Space (entities). The Products are implementations of solutions for specific customer use. CIG examples of products would include base stations, cellular telephone switches, and customer database products. Each of these products is rooted in its problem-space entities. Base stations require mobility management capabilities and radio management capabilities. These capabilities tend to be largely independent of both the product itself and implementations of the product. The issues identified above (product-specific nature of OO artifacts and specialized architectural language) have the effect of masking the inherent problem-space nature of these capabilities. The solution-space is where we implement both problem-independent capabilities and product-specific instances of the problem-space capabilities. For example, for the majority of the patterns described in [18] we would consider solely solution-space architectures (``Implementation Architectures'') that are problem-space independent; other problem-spaces may see those as both problem-space and solution-space patterns.

Each of the spaces has an architectural basis. The Problem-Space architecture we call ``Reference Architecture'' to indicate that it is not a concrete implementation but rather a guide to developing products incorporating these problem-space entities. We view the critical aspects of these architectures being the definition of the (behavioral aspects of the) entities and their interactions, and therefore focus less on the particular implementation issues. The Solution-Space architectures we call ``Implementation Architectures'' since their primary focus is on particular instances of products.

This brings us to consider technologies that can aid in describing the architectures in the given spaces. We consider design patterns a technology that spans the spaces, and believe that design patterns represent a technology that can be used to smooth the transition between spaces and final products. Other technologies we have investigated (object frameworks, meta-object protocols, and application-specific languages) tend to reside in the solution-space, as they apply more directly to the issues relating to implementing designs.

Summary

There are two thrusts in our use of design patterns. The first is in using the technology to encapsulate problem-space entities for larger-grained reuse across product families as described above. The other is in using object frameworks and application-specific languages to implement these patterns for easier implementation. Those investigations are on-going and not at a point to report progress. Nevertheless, we have seen some effects of using design patterns in our efforts so far:

• Design patterns have little to do with object-oriented technology. This technology is independent of object-oriented technology. The software systems from which we are extracting design patterns are not object-oriented, and the resulting design patterns are not object-oriented. These design patterns can be implemented using object-oriented designs, but it is not required to be this way.
• Design patterns represent a mechanism for easily sharing design information among groups of architects. We have found that with the design patterns we have written, they have been quickly understood by both the senior architects and the product developers. Other approaches have been less successful in bridging this gap.
• Writing good design patterns is difficult and time-consuming. In our efforts so far, we have spent much time on understanding how to write good design patterns so that they provide enough information to the reader to be useful. Our initial design patterns have gone through many iterations to ensure quality. This implies that only high-value problems should be captured using design patterns, and therefore choosing the appropriate problems becomes an issue.
• It is hard to quantify the impact of design patterns on our development effort. Currently, there are no metrics capable of distinguishing the impact of design patterns from other changes in our development process. Without further efforts on such metrics, we will never know the true benefit of this technology.