Neil B. Harrison

Lucent Technologies

11900 N. Pecos st.

Denver CO 80234

(303) 538-1541

nbharrison@lucent.com

Over the last several years, I have been involved in both domain analysis and patterns. In each case, I have been involved as both a practicioner and a teacher. This has given me useful insights into both using and teaching patterns and domain analysis.

During the latter part of 1996, and the early months of 1997, I led two different domain analysis activities. We followed (loosely) the FAST method of domain analysis, developed by David Weiss of Bell Labs. This method focuses on identification of commonalities and variabilities in a family of software systems. In each case, the goal was to create a standard specification for the domain to guide future developers.

These analyses were unique in two aspects. First, the members of each family consisted of separate, existing products which had been developed independent of each other. The second was that these projects were geographically dispersed. In some sessions, we had conference calls in three locations across the country.

One of the two analyses was a significant success, and formed the basis for development currently underway in the participating projects.

My experiences with domain analysis and patterns lead me to the following opinions:

1. Patterns are all about people. In fact, many of the patterns have to do with people issues. Domain analysis is all about people. Domain analysis is best done in groups, and as such, the group dynamics are critical in the success or failure of the analysis.

It was interesting to note the group interaction of a distributed group performing domain analysis; they followed several of Jim Coplien's organizational patterns. In particular, the pattern "Architecture Follows Location" was prominent.

2. Domain analysis and Pattern mining are similar in that they both are seeking for nuggets of information in a large amount of software. Both require both a keen sense of detail and the ability to abstract from the details. This is challenging.

Note, however, that it is inaccurate to characterize pattern mining or domain analysis as a subset of the other. They have different goals. Domain analysis focuses on a characterization of present and future software in such a way as to enable the creation of a specific architecture or software generation system. On the other hand, patterns emphasize the synthesis of knowledge and insight from experience, and transferring it to others. They are at once different and complementary.

3. The techniques of gleaning information for domain analysis and patterns are probably similar, maybe even essentially the same. These techniques should be explored, and perhaps expressed as patterns themselves.

4. Both suffer from the same problems of acceptance. However, the response is different. Because domain analysis is a significant effort, it requires commitment in advance from those controlling the purse strings. Patterns, on the other hand, are small, and independent enough that they can be written individually as time permits. However, the results of patterns are not obvious, so people may be reluctant to support patterns because they don't see tangible benefits immediately.