Patterns in AT&T - James Coplien

AT&T patterns programs

There are many independent patterns efforts afoot across AT&T; we touch on just a few of them here.

Fault-tolerant architectures:

Patterns capture proven, mature practices in a domain such as building architecture or software design. AT&T has several core competencies that are fundamental to our history of quality customer service. High-availability system design and fault-tolerant software are among these core competencies. Many of these core competencies can be captured as patterns, since they solve a wide variety of reliability and availability problems that arise during architecture and design.

We approached two development communities and asked management to point us to their experts on operations, administration, maintenance and provisioning. This program of ``pattern mining'' collected dozens of patterns from a handful of experts. We refined these patterns and captured them on-line in HTML where they were made available to the general AT&T research and development community.

Process patterns:

We have used patterns in the domain of process and organization, as well as in the domain of software architecture. Patterns are a literary form that conveys a solution to a problem in a context: though most practitioners are exploring architectural patterns, there is no reason to limit them to software design. We have found the recurring patterns of outstanding software development organizations through an extensive research program [10]. We can use those patterns to solve organizational and process problems.

Object patterns:

Little of our patterns work relates to the object paradigm. Objects are just one way of partitioning systems, and they are not always the best way to organize high-availability or fault-tolerant architectures. Besides, there are many more proven, mature patterns in the architectures of legacy systems than there are in the young, rapidly changing object-oriented systems.

Early work in AT&T to gather proven C++ programming idioms has culminated in a collection of widely used programming techniques [9]. One can think of these as proto-patterns; they were in fact one of the foundations from which contemporary patterns practice grew. The seminal Design Patterns book [18] built on these and other patterns to provide a general, language-independent collection of patterns by which object-oriented programming competency might be judged. These patterns are seeing wide use in mature AT&T projects. We have steered some young object-oriented projects away from patterns, however. Most new object-oriented projects must learn a design method and a new programming language, in addition to building a new architecture. We have noticed that incorporating more than three significantly new practices in a project increases risk, so patterns are put off until the project masters the initial changes.

How patterns have helped us

Training:

We have just started to use the fault-tolerance and high-availability patterns in architectural training. There are two aspects to this training: pattern training per se, and pattern supplements to architectural training. Pattern training is largely for organizations that are ``pattern consumers''. These organizations are building new projects, using patterns as audits and drivers for design. We have found this training to be effective on many levels. Not only do attendees deepen their understanding of patterns in general and of specific core competency patterns, but they deepen their appreciation for architecture and telecommunications foundations. Most of these courses are conducted as workshops that are highly participatory, with design exercises and pattern-writing exercises. We believe that it is difficult for designers to appreciate patterns fully, unless they have written one.

Some architecture courses are slowly adopting patterns as an adjunct to materials presented in a traditional format. So far, we haven't found this use of patterns to be a significant aid to the learning process. Patterns are probably perceived as a distraction to the traditional educational structures, and we conjecture that pattern-based architecture education might work better if the whole course were pattern-based. We plan further work in this area.

Architecture documentation:

In our pattern mining exercise, a new development project was the client for patterns extracted from contemporary projects. When architects from the contemporary project saw the patterns, they saw a solution to a problem that had been plaguing them for some time. Earlier attempts to capture the project architecture had failed to resolve the tradeoffs between a good description of the vertical architecture and architectural layering; patterns provided a way to unify those two perspectives. The original ``source'' organization is now one of the most active pattern organizations in AT&T, mining its own patterns as architecture documentation.

Shaping New Architectures:

By ``mining'' the fault-tolerant patterns of contemporary AT&T software systems, we can lay the groundwork for emerging and future project architectures. Much support for the emerging patterns work in AT&T came from a new project for which high availability is of paramount importance. The new project is evaluating the fault-tolerance and high-availability patterns gleaned from contemporary systems to see which ones are well-suited to the new system's market and technology.

Requirements Acclimation:

Requirements documents draw on market foresight and experience. Most analysts focus on the market foresight of the sales and marketing force, but draw on their personal anecdotes or on review input for the experience component. Patterns provide a written experience base that can feed the requirements process in the following way. As formative projects acquire patterns from their peers and predecessors, they go through them to select those that address problems in the project requirements. Once in a while, a pattern will solve a problem that seems like it should be in requirements, but the requirement is found to be missing. Such requirements are added to subsequent editions of the requirements document. We did not foresee this benefit of patterns at the outset, but it has proven to be a valuable use of patterns in new projects.

Process Assessment:

We use the process patterns to assess the health of development organizations. Our process research effort receives many requests for process improvement assistance; we use the process patterns as one set of tools to identify and remedy problems. These patterns, which have been published [10], are being similarly used in many companies outside AT&T.

Yet to be done

Designers find individual patterns illuminating and inspirational. We have patterns at all levels, from architectural frameworks down to design patterns and idioms [7]. The number of total patterns numbers in the hundreds. Scale is a major obstacle to systematic and effective patterns usage.

We are currently evaluating pattern organizing schemes, indexing schemes, and other attacks on the scale of the pattern knowledge base. Bob Hanmer has instituted an indexing scheme where the Intent appears as part of the index entry, but not as part of the pattern itself. We are also planning to work with knowledge engineers to help organize patterns according to expected search criteria.