Experiences using patterns at BNR - Gerard Meszaros

At BNR, the research and development subsidiary of NorTel (formerly known as Northern Telecom), we first became aware of the term ``patterns'' at OOPSLA 1993. We instantly recognized that we had been doing something very similar for quite some time as part of a major re-engineering effort of our DMS-100 family of telephone switches [23]. We have used the ``pattern'' and similar forms to capture project knowledge in a number of areas. While many of these patterns are specific to our problem domain and form the basis of our competitive advantage, we freely publish the more generic ones in the recognition that we get far more in return for a relatively small investment. The patterns we write and use can be roughly categorized as process/method patterns and technical patterns.

Process/Method patterns

Capturing a design methodology as patterns:

As part of developing a new architecture to allow rapid development and delivery of telecommunications services (a.k.a. ``Features''), we realized that service developers would require guidance in using the architecture. We began to develop a ``service design'' methodology. As the ``pattern form'' was as yet undeveloped, we captured the methodology as a series of ``semantic models'' starting with requirements and domain model, leading to the architecture model, the design model and finally the implementation model. Specific aspects of each model were identified and the heuristics for transforming them to the related aspect of the next model were captured.

Many of these patterns were ``prescriptive'' in that they described how to get from one model to another. As an example, a number of the patterns describe how to find and identify similar concepts in different requirements documents and capture the common concepts in the domain model of a service. These patterns effectively are a ``recipe'' for doing abstraction for people to whom this does not come naturally.

Architecting Method:

In the process of re-architecting our call processing system, we have come to recognize a number of key patterns of behavior of architects that lead to good architecture. Many of these patterns are technical in nature. We have captured a number of these in [19] for review and publication at PLoP-95.

The non-technical patterns include ones such as ``Just say NO to Politics'' (let the project managers solve the question of how the work is divided; architects should concentrate on ensuring that the design decisions are made for technical reasons.)

Technical patterns

We had discovered a number of recurring patterns in the design of telephone services. We had coined terms for many of these, such as modifier service (a service which observes another service and adds additional behavior at appropriate points.)

The patterns mailing list on the internet gave us early access to the patterns that were to be published in [18]. We also invited Richard Helm to come teach an introductory course on these patterns. We recognized many of the patterns in our system, often to the point of being able to list our own specializations of the general patterns being described.

We quickly found ourselves expressing our designs in terms of these patterns. They gave us a precise yet concise way of synchronizing our thoughts which saved a lot of effort. No longer did we have to describe a key portion of the design since we had a common understanding of what was meant by ``this object is using the Observer Pattern to monitor this other object.''

Patterns in Software Architecture:

We have found patterns to be particularly useful for defining and describing software architectures. Many patterns (Observer, Strategy, Composite, Half-Object Plus Protocol to name a few) are particularly useful when defining the the architecture of a system because they encapsulate potential changes to the system. The actual mechanisms used to implement these patterns can vary widely based on cost-space tradeoffs but can be hidden from the core objects (business objects) involved.

Reflections on the BNR experience

Personality Types:

Using patterns written by others only takes an open mind; writing patterns takes a special mind! Most people whom we have exposed to the concept of patterns can quickly become proficient at using the common ones. But we have found that only a small percentage of people can write patterns. With respect to patterns, there are three kinds of people: those who see patterns everywhere and can describe them, those who can recognize patterns but can not describe them easily, and those who are oblivious to the pattern surrounding them. This difference seems to stem from a basic orientation of people to focus on similarities as opposed to differences between things.

Impact of Patterns:

We have not attempted to measure the impact of patterns on productivity but we have noticed that communication between people with a ``shared space'' of patterns is quicker, more complete, and less likely to be misunderstood. At the programming level, we have had people design what might be rather complex designs much more quickly than expected by using one or more design patterns.