Mark A. Simos
Organon Motives, Inc.
1 Williston Road Suite #4
Belmont MA 02178
Tel: (617) 484-3383
Fax: (617) 484-3363
Email:
simos@organon.com
Product-line architectures have become the "party line" in the systematic reuse community. But for architecture-based approaches to scale up and avoid mere higher-level "stovepipes", complementary component-based design approaches are needed. That these involve a qualitatively different kind of engineering problem has not been sufficiently understood by the reuse field; many software-oriented domain engineering methods assume a product-line architecture approach. This position paper describes a distinctive perspective on the product-line question, embodied in the Organization Domain Modeling (ODM) domain engineering method.
While applicable to product-line domains, ODM also facilitates definition of lateral domains: subsystem-level domains, horizontal in functional scope, but characterized in terms of explicit, multiple contexts of application. Lateral domains are realizable as architecturally discrete asset bases, ensembles of components that can in turn participate as subsystems within diverse applications, even applications with varying system architectures. The paper provides an overview of the ODM approach to lateral domains and where they can be most useful: as an incremental domain engineering transition strategy; moving from reuse within to reuse across product lines; and providing a basis for non-hierarchical, decentralized design of Web sites and distributed computing components.
Keywords: systematic reuse, domain engineering, product lines, architectures, subsystems, component domains, lateral domains, ODM.
Workshop Goals: exchange views with other researchers in the reuse community.
Working Groups: Domain Engineering and Technology Change Management; Object Technology, Architectures, and Domain Analysis; Reuse and Product Lines
The Product-Line Party Line. Product-line architectures have become something of the "party line" in the systematic reuse community. System architecture is rightly viewed as a key factor to attaining systematic reuse within product lines or targeted sets of solutions. One advantage of a system architecture is that it can localize well-scoped components, so that a given architecture can have multiple components playing a given structural role.
But for architecture-based approaches to scale up and avoid mere higher-level "stovepipes", complementary approaches to component-based design are needed. Plug-and-play architectures enable flexible product lines, but will not achieve dramatic economies of scope unless coordinated with subsystem-level components designed for reuse across diverse architectures. That this is a qualitatively different kind of engineering problem has not been sufficiently understood within the reuse community.
Organization Domain Modeling (ODM). This position paper describes a distinctive perspective on the product-line question embodied in Organization Domain Modeling (ODM), a systematic domain engineering method developed by the author over the past eight years. ODM has been documented in detail in a guidebook produced under auspices of the DARPA STARS Program [1], as well as in shorter papers [2,3]. ODM is useful for diverse organizations and domains and amenable to integration with a variety of software engineering processes and technologies.
Lateral Domains. ODM does not offer two separate life cycles for product lines and components; it presents a unified life cycle which can be applied to either type of domain, or indeed to a wide variety of other kinds of domains (including non-software domains). In particular, while applicable to product-line domains, ODM also facilitates definition of what might be termed "lateral domains": subsystem-level domains, horizontal in functional scope, but characterized in terms of explicit, multiple contexts of application.
Lateral domains are realizable as architecturally discrete "asset bases", ensembles of components that can in turn participate as subsystems within diverse applications, even applications with varying system architectures. ("Component domain" might be an alternative term for lateral domain; we shall stick to the latter term in this paper. The term is intended to suggest that learning to think in terms of lateral domains seems to require something of a "lateral thinking" mind-shift: lateral domain thinking, so to speak.)
ODM's generality is achieved, not with a "high-level" (read vague!) life cycle, but with a detailed, yet tailorable and configurable process that addresses a number of issues that receive inadequate attention in other methods: e.g., stakeholder definition, domain scoping and boundary resolution, and determining constraints of multiple "target architectures" for assets to be implemented. These issues are implicit in any domain engineering effort, but are unavoidable when dealing with lateral or component-level domains [3].
The remainder of this paper describes something of the ODM approach to "lateral domains" and where they can be most useful: as an incremental strategy to transition of domain engineering within organizations; moving from reuse within to reuse across product lines for companies with diverse divisions; and providing the basis for a non-hierarchical approach to the design of Web sites and distributed computing components.
A key concept in ODM is that a domain scope includes an explicit context, an "intended multi-system range of applicability." In other approaches to domain engineering (DE), while a product-line as a whole may be conceived of as a domain spanning a range of variability, subsystems are often conceived of strictly as system elements. That is, we view components and their required variability from the perspective of the surrounding system context, within the product line scope for which they are initially intended. When a domain is described as "horizontal", on the other hand, this often indicates that the intended scope of applicability has simply been left implicit. For example, there is no "sorting and searching" domain in the abstract; any DE effort focusing on this area of functionality does so in a specific stakeholder context which must be understood in order to manage the effort in a systematic way.
In ODM, the terms "vertical" and "horizontal" are only meaningful relative to a specific set of exemplar systems that provide empirical grounding for the domain concept. The "domain of focus" may encompass the entire scope for a family of similar systems (a "vertical domain" with respect to those systems) or cut across only a sub-portion of the systems (a "horizontal" domain with respect to the systems). Furthermore, the intersection of the domain focus with any system could correspond to a delineated subsystem or to "diffused" functionality (e.g., security requirements). Areas of subsystem-level functionality can thus be conceived as independent domains in their own right. They may have a range of variability independent of the product line architecture(s) in which domain components will be utilized, but still explicitly bounded via a systematic definition process.
Fighter pilots must develop a skill they call "situational awareness": the ability to view themselves in relation to moving planes in all three dimensions, with themselves in the middle of the visualized space. We claim that a similar kind of "situated thinking" is required to conceive, define and model domains in a lateral sense. This means, in particular, the ability to envision contexts other than the immediate "presenting applications" that have directed our attention to the domain. This envisioning is facilitated by a domain definition process that iterates between a set of exemplars and a set of defining criteria to uncover implicit contextual assumptions in the domain scope.
We tend to visualize systems hierarchically and top-down, unconsciously drawing ourselves up out of the envisioned system, as if seeing it from the outside and above. Though we think we get a handle on the "whole picture" this is an illusion; we have merely "expanded the frame" until assumed context becomes implicit again. For a lateral domain view we must invert this perspective, viewing the component or subsystem from the standpoint of the multiple system (and architectural) contexts in which it potentially could be incorporated. Lateral domain thinking involves visualizing ourselves within an imagined domain space, at the nexus of vectors of relationships emanating from the domain of focus and stretching to us from all sides and angles. In addition to considering functional interactions, other conceptual relations among domains including generalization, specialization and analogy are explored.
In our DE efforts, we have usually championed a focus on small, well-scoped subsystem-level domains as a useful incremental strategy for introducing DE into organizations, even in situations where an product-line approach is eventually desired. The transition to product lines often presents formidable organizational obstacles, because it demands too much initial buy-in from too many stakeholders. In effect, the company must place an entire product strategy (literally) "on the line".
Using component domains, DE can be approached in a more incremental way that facilitates iterative reengineering of portions of legacy systems as well as guiding opportune architectural choices for newly engineered systems. While project managers may baulk at accepting an entire architectural framework to ensure a product line of "variants" they can be motivated to make local architectural adjustments to accommodate sizable components of sufficient value. Components can be incorporated into legacy systems without wholesale architectural restructuring, and new applications can be designed opportunistically to incorporate them as well. Such an incremental approach was applied in a major application of ODM on the three-year Army STARS Demonstration Project [4]. (It is interesting to note that we initially encountered resistance in our advocacy of "too small" a domain, but in the end the strategy made sense to people.)
It is possible to approach these smaller-scale domains as merely subsystems of an eventual product line. We believe that approaching them with the "lateral domain thinking" encouraged by ODM, while more challenging, leads to more robust results. In addition, such domains help to demonstrate key concepts of DE and to differentiate it from standard system and software engineering techniques.
There are risks of architectural mismatch in subsystem level domains. There is also some danger of "backing into" architectural commitments by pursuing a repeated bottom-up strategy of selecting small-scale domains within a potential product line. We recommend beginning with one to a few lateral domains as an entry strategy. Rather than continuing to replicate this strategy on peer domains, initial domains become feasibility proofs that motivate a high-level "domain scan" to identify a reasonable architectural approach for the entire business area, which can then be further worked incrementally.
For large-scale software development organizations, such as vendors of infrastructure-level hardware and software, product lines may become yet another level of "stovepipe" functionality. Companies that achieve reuse at the product-line level may therefore need to be prepared to move to the next step: creation of components that can be reused across as well as within product lines. Such components, in effect, define a core competencies framework for the firm. These core competencies would typically be deployed in multiple product lines, perhaps across product and solutions groups as well.
For cross-product line reuse we need to go beyond a merely architecture-dominated approach to domain engineering, and learn how to engineer "components" sufficiently well-scoped that they can be used with predictable results in diverse architectural contexts. These components will be "units of exchange" brokered among distinct product line organizations. This will typically require significant organizational as technical re-architecting. Our experience is that few companies have got to the product-line organizational structure as of yet, so this scenario is still somewhat long-term [5]. We are currently initiating a long-term research project with Hewlett Packard's Software Initiative organization to research these issues.
The "lateral domain" style of thinking is in keeping with the technical metaphors of the Web (e.g., multiple links between various Web sites), and of distributed object computing (e.g., CORBA interfaces), where independently developed components or component suites must interact on a peer basis with a variety of contextually contingent resources.
Internet and distributed object computing technologies are helping to create an industrial infrastructure for true software component provider enterprises, that will interact in a complementary fashion with application integrators. Companies serving as component, asset, or "asset base" providers in this emerging component-based marketplace will reflect many dynamics of virtual enterprises. They will be organized around specific competencies realized as reusable assets (core products), and will form a variety of partnering, producer-consumer and competitive relationships with other firms. There will be a complementary role for larger companies that provide architecture-based product lines integrating components and delivering customized functionality and services to clients.
At a broad process level, both types of organizations will be performing a process that can usefully be characterized as DE. For the integrator, DE will help to determine the required degree of flexibility of the architecture, the mapping of application requirements and target market attributes to system features, and the expected range of variability in components. Product line architectures may be a good model for how such integrator companies will operate; but they are, literally, only half of the story. Component providers will need to do DE with careful attention to the anticipated scope of reuse. For such companies, ownership of a product line architecture may not be the key leverage point. Instead, they will need to create flexible, well-scoped assets that can be "good citizen" players in collaborative interaction with similar components from other providers. For such companies, we believe "lateral domains" will provide a better metaphor for DE.
Most software-oriented domain engineering (DE) methods assume that domains span the entire system scope for a related family of applications, and that a single product-line architecture can be discovered (or imposed) on that family of applications. In designing a product line architecture, allowance is made for smaller-scale domains corresponding to components within the architectural framework. But the scope of applicability for these "subsystem domains" is often (tacitly) assumed to be the product line itself. Thus the task of modeling and implementing such domains is assumed to be a smaller-scale version of the overall domain engineering problem, or to reduce to standard system engineering techniques. This does not really address the problem of how to design true large-scale components for use in diverse application contexts.
We believe lateral domains are a critical complementary metaphor required for a true components-based software industry. This approach to domain engineering is essential, both to support incremental adoption of systematic reuse within a product-line context, and in new contexts where a conventional product line thinking is not as applicable. We envision applications of the future built by integrators assembling and configuring large-grained instantiations from diverse asset bases, networked via a complex web of semantic relations. We believe that ODM-based methods and supporting technology have a potential contribution to make in realizing this vision.
Some of the thoughts expressed here were stimulated by recent technical interchange with Richard Randall (Lockheed-Martin), Patricia Collins Cornwell at Hewlett Packard Company's Software Initiative (SWI), Maggie Davis (Boeing), Dick Creps (Lockheed-Martin), and fellow Organauts Dean Allemang, Jon Anthony, and Larry Levine.
[1] Software Technology for Adaptable Reliable Systems (STARS). Organization Domain Modeling (ODM) Guidebook, Version 2.0. STARS Technical Report STARS-VC-A025/001/00, Lockheed Martin Tactical Defense Systems, Manassas VA, June 1996.
[2] Simos, M., "Organization Domain Modeling (ODM): Formalizing the Core Domain Modeling Life Cycle". SIGSOFT Software Engineering Notes, Special Issue on the 1995 Symposium on Software Reusability, Aug 1995.
[3] ibid., "Juggling in Free Fall: Uncertainty Management Aspects of Domain Analysis Methods". Proceedings, 5th Intl Conference on Information Processing and Management of Uncertainty in Knowledge-Based Systems, Springer-Verlag, July 1994.
[4] STARS. Army STARS Demonstration Project Experience Report. Unisys STARS Technical Report STARS-VC-A011R/003/02, STARS Technology Center, Arlington VA, April 1996.
[5] Cornwell, P., "HP Domain Analysis: Producing Useful Models for Reusable Software", HP Journal, August 1996, pp. 46-55.
Mark Simos is founder and president of Organon Motives, Inc., a software research, consulting, training, and technology development company focused in the areas of reuse and domain engineering. Mr. Simos is the primary developer of the Organization Domain Modeling (ODM) method, was also a principal co-author of the STARS Conceptual Framework for Reuse Processes (CFRP), and has authored or co-authored many papers and technical and working group reports on reuse and domain analysis. Mr. Simos has consulted in the reuse field since 1988, and incorporated Organon Motives in 1995 to productize the ODM method and support technology for domain engineering. Mr. Simos' clients for reuse and domain engineering consulting and training have included Hewlett Packard, Lockheed Martin, the ARPA STARS and Air Force CARDS programs, U.S. Army CECOM/SED, Logicon Corporation, Andersen Consulting, and Buzzeo, Inc. .Mr. Simos holds an MS in Computer and Information Science from the University of Pennsylvania. He is also well-known in traditional music circles as a fiddler, songwriter and composer.