Domain Envisioning:

A Lightweight, Incremental Approach to Getting a Company Started with Systematic Reuse

Mark A. Simos

Synquiry Technologies, Ltd.

1 Williston Road, Belmont MA 02478

Tel: (617) 484-3383 Fax: (617) 484-3363

email: simos@synquiry.com

URL: http://www.synquiry.com

Synquiry Technologies, Ltd. is a Boston area software company specializing in tools and supporting methods for modeling and applying conceptual information. The vision behind our innovative software products builds on a technical foundation established over more than a decade of government-funded research and commercial consulting, and diverse competencies in knowledge representation, semantic modeling technologies, organization development and change management.

The cornerstone of Synquiry’s method offerings is a comprehensive domain engineering methodology, Organization Domain Modeling (ODM), which is scalable and tailorable for diverse organizations and domains and for integration with various software engineering processes and life cycles. ODM was developed over the past 10 years by Mark Simos (Synquiry’s founder) with significant support and contributions from Hewlett Packard, Lockheed Martin and the DARPA STARS Program. ODM is documented in a detailed guidebook [1] as well as in shorter papers [2,3].

ODM was developed in the context of government and corporate research efforts in systematic reuse. In the early phase of developing the method, we were mostly concerned with issues like formal correctness, contextual neutrality (would the method really apply in a diverse set of environments?), method architecture (have system engineering-specific commitments been pulled out of the method structure and documentation?), comprehensiveness, etc. Since completion of the Guidebook Version 2 (June 1996) I and my colleagues (including Larry Levine and Dean Allemang) have worked with a number of commercial software organizations attempting to introduce systematic reuse initiatives, including Hewlett Packard, Andersen Consulting, Buzzeo Inc., IDX Systems Corporation, and Origin/BAS in the Netherlands. Through these consulting engagements we have learned a lot of practical lessons about the challenges of introducing systematic reuse and domain engineering into software organizations. This paper offers some highlights of these lessons learned.

• Reuse as knowledge creation. We work with a very broad view of software reuse, as one aspect of a transition towards systematic knowledge creation practices within a software organization. By looking at reuse from this perspective we can see that similar competencies are required to share actual code assets and less tangible knowledge about software products and process.

• Role of domains in knowledge creation. In early reuse planning we look for many modest opportunities besides full-scale domain engineering projects. A domain-oriented perspective remains important: scoping any reuse or knowledge creation effort depends on selecting an explicit domain of focus. But the notion of "domain" takes on a very specific character when considered in the context of a broader, knowledge creating approach to reuse.

• Domain envisioning as result and capability. This has led us to a very different approach to reuse planning, where exploring an organization and its systems from the standpoint of domains and domain boundaries becomes an activity—domain envisioning—which produces immediate and direct value for the company; that is, it is not just a "means to the end" of defining a domain engineering project. Ideally, the activity also increases an organization’s ongoing capability to generate these alternate perspectives as required in the future.

• Just in time method delivery. To obtain these early results, we have adopted an extremely lightweight, informal, minimal investment approach to planning activities, described in this paper. It is participatory, involves minimal "training" in the abstract, and brings together diverse groups of stakeholders in small meetings which create intrinsic value for the enterprise.

Domains and Structure. In any structured configuration of people, processes, or system components organized to achieve certain strategic goals, knowledge is created in two fundamentally different ways: within existing groups and structures of the organization or system; and across these structures.

• Every component or structural unit within an organization structure is a potential "theater" for capturing learning created by the work interactions that fall within that unit. Consider these as domains strongly determined by organizational structure. To the extent that such a structure is oriented towards specific tasks with specific outcomes, learning or creation of new knowledge is a sort of by-product of the primary process for that structure (albeit a very important by-product). Some learning occurs within interactions directed toward the structure’s primary objectives (design meetings, technical reviews, etc.).

• Other kinds of learning or knowledge creation take place when people come together in new configurations, i.e., interact with people other than their natural work-group neighbors, and/or interact with those neighbors around new and differently scoped tasks. Thus another set of domains are defined by alternative ways of grouping structural units, or cutting across those structures in possibly very complex ways. Consider these as domains determined by certain relationships across structural units.

We could use the analogy of centripetal and centrifugal forces to distinguish, respectively, domains that reflect natural structure, and domains that reflect interactions, handoffs, common and variant features, or independent cross-hatching of structural orderings. We need explicit processes to help identify both types of domains.

As a simple example, consider a complex software system being constructed via a managed life cycle allowing for iterative design, implementation and testing. Suppose a requirement for self-test features needs to be incorporated into some number of components of the system. "Self-test functionality" may not appear as a separate component of the system since the actual functions to be performed will vary locally with each component. Yet this could be approached as a coherent domain, or concern, in system development. This domain can be seen, in a sense, as "generated" by the intersection of the testing phase of the life cycle with overall system structure (with the added twist that it pushes the testing function into part of the operational requirements for the system).

Domain Envisioning. No one way of structuring an organization or system can encapsulate all potential learning domains in a single structure. Structure optimizes to encapsulate some domains, diffuse others; some important knowledge "falls through the cracks" of whatever structure is in place. The goal of a knowledge creation program is to improve an organization’s capacity to visualize the many independent domains defined with respect to organization and system structures; to initiate learning interactions for strategically important knowledge areas; and to manage integration of these activities with work tasks supporting the organization’s primary processes.

To help a company make the transition to knowledge creation practice, we suggest an incremental strategy where the domain of focus for an initial reuse project creates the appropriate degree of change in the organization. Since centripetal domains correspond to natural structures, they do not require systemic changes within the organization. This allows for lightweight, incremental adoption of project-level learning practice, but does not ensure lasting change; the change could be simply at the local or project level. On the other hand, we cannot attempt to transform the processes in a whole organization without engendering a breakdown of one form or another. Our goal is therefore a middle ground: a good candidate for local transformation within the structure, large enough to require putting new kinds of processes and interactions into place and raise cultural barriers to visibility, small enough that we avoid trying to make systemic changes too broadly and widely.

Just in Time Method Delivery. In our typical mode of engagement, we work directly with a sponsoring group within the organization (often a reuse solutions group) to perform a first, rapid pass through a domain envisioning process. The work is generally done via a series of small-group meetings over a period of a few months. The purpose of these sessions is generating data from participants, not to provide a thorough tutorial (content presentation is kept to a minimum) or to produce definitive plans. Rather than attempting to arrive rapidly at consensus we use the meetings as microcosms that generate as much information as possible about overall reuse adoption prospects for the organization. Data from the sessions is synthesized, organized, and presented back to participants for validation and elaboration; validated data becomes input to true decision-making meetings, where key stakeholders are present and closure on decisions can be reached.

We look for domains that cut across different project teams, to maximize cross-group knowledge sharing while minimizing up-front cost and risk. A well-chosen domain can combine highly specific focus with broad impact, potentially involving people from diverse parts of the organization. By "slicing and dicing" familiar material in innovative ways, the domain definition process helps reveal insights about implicit connections between different business process and technical areas. Assets organized around highly focused domains can be more flexibly "re-purposed" and reused. The process also stretches an organization’s typically code-centered view of reuse by considering domains not exclusively concerned with software implementation

This strategy reflects these insights, the fruit of some painful and some humbling experiences:

• A reuse or domain engineering project will be judged according to the timeframe and strategic outcomes expected for a typical software engineering project within the adopting organization. The biggest flaw of the product line approach is that it attempts to aggregate an economy of scale based on multiple systems, each of the size the organization in question defines as a "real system." Almost by definition you are "biting off more than the organization can chew" and you will either not get the resources required, or you will get them by first co-opting, later being co-opted by, ancillary interests with mis-aligned or even competing agendas.

• To avoid this pitfall, picking a modest but appropriate scope for an initial project is critical. Risks can be as much from getting too much as too little. Premature early buy-in from an enthusiastic visionary champion at a high management level can tempt those starting a reuse initiative into committing too many resources and creating expectations that are almost guaranteed to be disappointed. There is an important discipline in knowing how much (and how little) to ask for to create the right initial "success story" for reuse within an organization. In general, we look for highly focused domains that can be feasibly addressed with modest resources; in practical terms, a well-scoped area of inquiry that could be tackled by a relatively small team (2-4 people) over a period of about three months.

• By and large, only fellow methodologists care about methodology for its own sake. Most people in business environments need to have direct results for their efforts. At the most practical level, this means that most useful interventions in the planning stage of a reuse program for a company need to be done in one-day meetings, with minimal expectation that people will read anything before hand or have time to do much follow-up afterward to create products from meeting results. Though the meetings or events may correspond to a step in the framework of a methodology (e.g., stakeholder analysis, domain selection) each must also have a framing rationale in terms of the company’s immediate strategic goals and business objectives; these must be the primary explanation offered to participants in advance of the session. Each meeting has to create visible value to all the participants—translated into organization-specific terms.

• Sometimes the opportunity for people in the meetings to meet each other, interact and share knowledge is one of the primary perceived values. So it is also important that these meetings be perceived as something happening outside the context of ordinary work or planning tasks. In particular, it’s good to characterize them as generating data and facilitating information exchange rather than about making final decisions. New strategic relationships are created within the participants’ group in the course of the meeting.

• While it’s nice in theory to combine skills/technology transfer with consulting efforts, in many cases this is not a particular concern to customer organizations and doesn’t deliver immediate value. A domain envisioning process involving a few well-planned meetings can generate strategic insights which could guide several years of initiatives. There may be little need for a company’s internal staff to be able to conduct envisioning meetings for themselves except in large diversified organizations that need to roll out a process for multiple divisions or frequent iterations.

• By and large, we try to get key concepts across very informally, letting people work with their own notions of what things like "domains" mean until it seems like intervening with a new concept will demonstrably add value to the task at hand. Large sets of training viewgraphs are being used less and less, relying instead on five-minute verbal explanations and hand-drawn diagrams on flip-charts.

Our approach can be contrasted to many related disciplines. Many other approaches to reuse planning are focused on software systems, entire product lines, an architecture-driven approach, and code assets or use of particular implementation approaches such as generative techniques. While ODM can be applied to typical areas of focus for systematic reuse (software components, product lines) it can also be applied more broadly to the capture and reuse of component, process and knowledge assets from across the development life cycle. On the other hand, many current approaches to general knowledge management and organizational learning lack the concept of "domain" as a technique for scoping efforts in an actionable way that still creates opportunities for innovation relative to current structure.

The approach described here also contrasts with some assumptions reflected in earlier formulations of our own work. We used to see the goal of up-front reuse planning as specifically identifying good opportunities for domain engineering projects. We now treat formal domain engineering as a special case of a broader set of activities that could loosely be called systematic reuse, or learning, or knowledge creation activities. These could be something as simple as getting a group of designers who have worked on analogous components of multiple systems together in a room to share lessons learned and common processes. The result might be a document which is managed and evolved over subsequent projects. Yes, in principle this could be rationalized as domain engineering (a set of example systems, an "asset") but describing it via a highly formal process is overkill for the granularity of the task. It may help us anticipate issues the client organization will face but does not particularly help the client. We emphasize up-front planning tasks which stretch notions of systematic reuse to include non-code assets like designs and test cases, process assets like checklists of questions to ask customers, and small-scale domains that can be tackled with a one to three month effort. In few cases is an organization’s software and process maturity at a point where a first pilot project should be a full-blown, formal domain engineering effort.

[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.

Mark Simos is founder and president of Synquiry Technologies, Ltd., a Boston area software company focused on tools and supporting methods for modeling and applying conceptual information. Mr. Simos was the primary developer of the Organization Domain Modeling (ODM) method, was also a principal co-author of the STARS CFRP, Canvas and LIBRA documents, and has authored or co-authored many papers and technical and working group reports on reuse and domain analysis. A consultant in reuse and domain engineering since 1988, Mr. Simos' clients have included Hewlett Packard, Lockheed Martin, the ARPA STARS and Air Force CARDS programs, U.S. Army CECOM/SED, Logicon Corporation, Andersen Consulting, and IDX Systems Corporation. 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 tunesmith.