Jeffrey S. Poulin
Lockheed Martin Federal Systems
MD 0210, Owego, NY 13827
Keywords: Software Architectures, Domain Specific Software Architectures, DSSA, Product Lines, Software Reuse.
Workshop Goals: To explore, learn, and discuss current issues in software architectures and reuse. To have a spirited discussion on the topic of this position paper.
Working Groups: Software architectures for reuse, Domain analysis/engineering representations, or Reuse metrics and economics.
Every couple of years our discussions about reuse seem to rise to higher levels of abstraction. Reuse using building blocks gave way to discussions about horizontal reuse and vertical reuse. Vertical reuse developed into the study of related problem areas, or domains. Soon the importance of domains became well-known and reuse research focused on "Domain Specific Software Architectures (DSSAs)" in order to achieve high levels of reuse within a domain. More recently, researchers have started to advocate software development based on "Product Lines." At the same time, related work in designing large software systems has identified software architectures as important for consistent and efficient software development . Each of these concepts raises the level of abstraction at which we describe software. In part, the increased levels of abstraction reflect our struggle to cope with the rapidly increasing complexity of our field. However, this series of research directions has also led to a general confusion as to the relationship between reuse, domains, product lines, and software architectures.
A common understanding of the relationship between reuse, domains, product lines, and software architectures does not exist. I believe that the confusion comes from the level of abstraction that each supposedly represents. Furthermore, I believe that the term "product line" refers to the same level of abstraction as "domains" and that the two terms exist simply to help communicate the same idea to different audiences.
Extensive work in domain analysis and domain engineering by a number of excellent sources has defined our knowledge of domains and their relationship to (vertical) reuse . Likewise, work in software architectures leaves little doubt that an architecture provides the highest level representation of a software system . I have pursued developing reuse-based software architectures for very large scale software systems [7, 8, 9].
However, a general disagreement exists as to the definition of product lines. At a recent reuse symposium, a panel on product lines attempted to field the question "please explain the difference between product lines and domains." Every member of the panel gave a different answer. For example, "there is no difference between product lines and domains except that product lines connote the idea of a market, whereas domains do not." Actually, every known domain analysis method seeks to identify the common elements of a group of related problems and quantify the number of potential uses of each common element. Domain analysis must address this in order to justify, through a business case, the subsequent development of shared components.
To help answer the question as to the difference between domains and product lines we will start by exploring them as a possible abstraction hierarchy. We will then show why domains and product lines actually refer to the same concept and represent the same level of abstraction.
3.1 Do the terms form a hierarchy of abstraction?
One possible way to differentiate domains, product lines, and architectures involves creating a hierarchy of abstractions. Tracz recently explained how this might work by defining a product line to possibly span several domains . However, a hierarchy does not address the issue of deciding the boundaries at each level of abstraction. In other words, deciding how much of the problem falls into domains, how much falls into product lines, and how much falls under a software architecture. With regards to domain analysis, we refer to this as the "domain scoping" problem [Svo96]. This problem arises when we do not agree on the boundary of a problem and therefore cannot agree upon what constitutes a "domain."
Example: Consider the domain of avionics applications. Within this domain, we might have sub-domains consisting of navigation, guidance and flight direction . On the other hand, we could instead call the "domain" of avionics applications a product line and define domains within the product line as consisting of navigation, guidance and flight direction . Deciding on the boundaries of a problem (what to call a domains versus a sub-domain) constitutes the "domain scoping" problem.
The domain scoping problem has repeatedly caused disagreement even amongst members of the same design team. Arguments over how to bound a problem and what to call a domain versus a sub-domain often hinge on subtle or academic criteria. Unfortunately, these arguments do not impress management and make it difficult for the members of the design team to develop a cogent case for continued support.
Note that we have not defined the role of software architecture. Continuing with the abstraction hierarchy, we could define a software architecture as possibly spanning several product lines. For example, perhaps all product lines on board an aircraft (e.g., avionics, weapons systems, entertainment, etc.) would adhere to the same software architecture.
However, we do not really need a three-level hierarchy. If a product line spans many domains, then at most we need a software architecture for all products built within that product line. This would mean that software architecture and product line architecture mean the same thing.
Example: Consider a suite of applications for managing a large business. The applications might include several applications to manage personnel, several applications to manage logistics, several to manage finances, etc. We could say that all applications belong to a domain called "management information systems." However, on a recent project we decided that the area of MIS systems encompassed far too many problem areas to call it a domain . Instead, we decided that groups of applications in the same problem area bounded a domain; this made our definition consistent with most work in domain analysis. Having made this decision, we developed a software architecture that applied to all MIS applications, and planned to develop a DSSA for each of our domains.
In retrospect, we could have called our suite of business applications a product line. However, we really had no need for this term; the software architecture unequivocally specified the highest level organization of our software system. This led us to question how product lines relate to domains.
3.2 Tuning a concept to the audience
Most software developers (technical persons) understand the concept of domain. Developers work with problems and readily adopt unique terms and expressions to express their problem space. However, most managers do not understand this special language; they think in "business language." In the language of their solution space they deal with products, and they group related products into a "product line." In other words, "domains" and "product lines" refer to the same concept but appeal to different audiences.
Example: In a recent product line "success story," our developers explained the need to obtain customer buy-in in order to fund the analysis, design, and development of a large software system . Despite years of unsuccessful attempts to gain support for domain analysis and domain engineering, the customer bought into the concept of moving toward a product-line organization. They saw product line reuse as the "reuse of architectural coherence, OO models, processes, tools, and most important, the skills, knowledge, and motivation of a technologically sophisticated, synergistic team of people."
This experience report advertised significant opportunities for reuse within the product line because all products share common features. Note that the software technical community has forwarded this exact same concept for years by pointing out the high opportunities for reuse within a domain and limited opportunities across domains. The DSSA approach includes the development of a common reference architecture, domain models, processes, tools, and depends on the knowledge developed by the team conducting the domain study. In their very successful reuse program, Hewlett-Packard structures their domains around portfolios of related products . Substituting the term "domain" for "product line" rarely changes the content or intent of a paper or discussion; it can, however, increase the probability that a particular audience will listen.
Domains and product lines refer to the exact same level of abstraction. The term "product line" grew out of the software technical community's failure to relate the idea of related problems to managers who needed to have things explained in terms of related solutions . The exact boundaries of each will, of course, depend on the audience. For example, a manager may scope a product line such that it includes bits and pieces of what a domain analyst might have defined as several domains. In this sense, Tracz's explaination that product lines may span several domains holds. Otherwise, product lines and domains refer to the exact same thing.
So why the hype? Part of it comes from opportunists who capitalize on confusion by claiming to understand "the bigger picture." However, unnecessarily creating or raising levels of abstraction leads to a situation in which no one can understand how anything really works. We have seen the confusion caused by the "product line" trend. In our field, much of this trend comes from persons who talk about reuse but do not actually do reuse. Not surprisingly, technical leaders from within Lockheed Martin ranked product lines as one of the least important technology areas for future investment (while at the same time ranking reuse as one of the most important). I would enjoy seeing the results of a similar question posed to management.
 Arango, Guillermo, "Domain Analysis Methods," in Software Reusability. Wilhem Shaefer, Ruben Prieto-Diaz, and Masao Matsumoto, eds. Ellis Horwood, Chichester, U.K.,1993.
 Bardo, Tim, Dave Elliot, Tony Krysak, Mike Morgan, Rebecca Shuey, and Will Tracz, "CORE: A Product Line Success Story," Crosstalk: The Journal of Defense Software Engineering, Vol. 9, No. 3, March 1996, pp. 24-28.
 Biddle, Robert, and David Eichman, Private Conversation, 26 September 1996.
 Coglianese, L., R. Smith, and W. Tracz, "DSSA Case Study: Navigation, Guidance, and Flight Director Design and Development," 1992 IEEE Symposium on Computer Aided Control System Design, Napa, CA, 17-19 March 1992, pp. 102-109.
 Collins Cornwell, Patricia, "HP Domain Analysis: Producing Useful Models for Reusable Software," Hewlett-Packard Journal, Vol. 47, No. 4, August 1996, pp. 46-55.
 Garlan, David, and Mary Shaw, "An Introduction to Software Architecture," Advances in Software Engineering and Knowledge Engineering, World Scientific, Singapore, 1993, pp. 1-39.
 Poulin, Jeffrey S., "The Software Architecture of the Army SBIS Program," Crosstalk: The Journal of Defense Software Engineering,, February 1996, pp. 16-21.
 Poulin, Jeffrey S., Norm Kemerer, Mike Freeman, Tim Becker, Kathy Begbie, Cheryl D'Allesandro, and Chuck Makarsky, "A Reuse-Based Software Architecture for Management Information Systems," Fourth International Conference on Software Reuse, Orlando, FL, 23-26 April 1996, pp. 94-103.
 Poulin, Jeffrey S., "Evolution of a Software Architecture for Management Information Systems," Proceedings of the Second International Software Architecture Workshop (ISAW-2), San Francisco, CA, 14-15 October 1996, pp. 134-137.
 Randall, Richard L., David J. Bristow, Jesse G. Foster, and Maj. Dennis D. Kaip, "Product-Line Reuse Delivers a System for One-Fifth the Cost in One-Half the Time," Crosstalk: The Journal of Defense Software Engineering, August 1996, pp. 25-26.
 Tracz, Will, Private Conversation, August, 1996.
Jeffrey S. Poulin (Jeffrey.Poulin@lmco.com) MD 0210, Lockheed Martin Federal Systems, Owego, New York, 13827. http://www.owego.com/~poulinj.
Dr. Poulin works as a Senior Programmer and software architect with Lockheed Martin Federal Systems (formally Loral Federal Systems and IBM Federal Systems Company) in Owego, NY. As a member of the Advanced Technology Group, he works software reuse and architecture issues on a variety of software development efforts across Lockheed Martin.
From 1991-1993 Dr. Poulin worked in the IBM Reuse Technology Support Center (RTSC) where he led the development and acceptance of the IBM software reuse metrics and return on investment (ROI) model. He also organized, edited, contributed to, and published a complete library of resources on the IBM Reuse Method. Active in numerous professional activities and conference committees, Dr. Poulin has over 40 publications, to include a book on reuse metrics and economics published by Addison-Wesley. A Hertz Foundation Fellow, Dr. Poulin earned his Bachelors degree at the United States Military Academy at West Point and his Masters and Ph.D. degrees at Rensselaer Polytechnic Institute in Troy, New York.