Multiple-Context Systems: A New Frontier in Architecture

Charlie Alfred
Software Architect

 

March 2010

 

Summary: Multiple-context systems are those in which a single architecture and core assets must function well in several different environments. Examples include product-line architectures, as well as certain elements of enterprise architectures—especially those that have integration and infrastructure responsibilities. Unlike single-context systems, which resolve one set of forces, multiple-context systems must resolve the forces in each individual context.

 

Introduction

A context is a collection of stakeholderswho share a similar set of perceptions,priorities, and desired outcomes and aresubjected to a similar set of conditions andforces.¹ Marketing professionals call them “market segments” and use them to target advertising and other forms of marketing campaigns. Architects can use contexts to define and create effective solutions for a related set of deployment environments.²

Table 1 shows a simple example of contexts at work. Consider a Thinsulate ski parka, which is temperature-rated to –40°F. You would expect this parka to be as shown in Table 1.

More valuable to:	Less valuable to:	Reason
Resident of Calgary, AB, in January	Resident of Calgary, AB, in July	Condition (seasonal)
Senior in Calgary, AB	Youth in Calgary, AB	Perception (tolerance of extreme temperatures)
Someone in Calgary, AB	Someone in Miami, FL	Force (climate)
Avid skier in Miami, FL	Avid golfer in Virginia Beach, VA	Priority (hobby) over force (climate)

Table 1. Context example

 

While these generalizations might not hold true over every context member who matches the criteria, it is reasonable to expect that they will hold true in a large percentage of cases. Well-defined contexts are powerful, because conditions and forces tend to be linked to perceptions and priorities, and the combination of these drives desired outcomes.

 

Real-World Examples of Multiple-Context Systems

Before exploring the proposed approach to multiple-context systems, let us first consider two real-world examples:

• Local-area pickup and delivery routing and scheduling
• Semiconductor-fabrication tools

A third example, which is based on medical reporting, will be presented later and used to illustrate how to apply the multiple-context approach.

Transportation Routing and Scheduling

Several organizations coordinate a set of drivers who pick up and deliver shipments within a local geographical area. These organizations have several important commonalities:

• Service effectiveness, measured by completion percentage of scheduled stops
• Reduction of travel time (drivers get paid to pick up/deliver, not to drive)
• Management of vehicle-weight and vehicle-capacity constraints
• Observance of customer-service windows and other physical constraints

Table 2 summarizes three common local-area-transportation contexts.

Context	Description	Contextual drivers
Parcel	UPS, Federal Express, DHL	~80 drivers per terminal. Small (< 200 lb) shipments. 5,000–8,000 stops daily. Very high stop density (~2/sq mi). High % of urban stops (travel constraints). On-time service is critical.
Less than truckload	Roadway, Yellow Freight	~30 drivers per terminal. Large (500–10,000 lb) shipments. 600–800 stops daily. Sparse stop density (~0.1/sq mi). Mostly industrial and suburban locations. Shipment position in truck is critical.
Private fleet	Bottled water, food service	No. of drivers, no. of stops, shipment size vary by product. Stops planned/loaded in advance. Delivery routes only, no on-route pickup. Multi-day driver routes. Some location variation (new customers).

Table 2. Local-area-transportation contexts

 

Semiconductor Fabrication

Semiconductor fabrication is a process that creates hundreds of microprocessor or memory chips on a 300mm silicon wafer.

Complex circuits might require several hundred processing steps, using a variety of tools.

Each of these tools shares a set of important commonalities:

• Conformance to the SEMI standards, to enable semiconductor-fabrication plants to implement factory-automation systems to control each tool in the line
• Automated wafer cassette robots that move wafers between tools
• Electromagnetic control of pumps, vents, material handlers, and other devices
• Tracking of process outcomes by batch, lot, and wafer

As Table 3 shows, there are four general classes of semiconductor-fabrication tools, and the drivers for each tool have important differences.

Tool type	Description	Contextual drivers
Deposition	Adds thin film of material, with a thickness of a few nanometers on the wafer surface	Sub-nanometer thickness Precise depth of film across wafer Recover process from point of error
Patterning	Uses an XY stepper to position at each die; creates the desired negative on photoresist by using a laser beam and photomask	Precise X/Y origin for each chip, with high positional accuracy across layers Precise energy dosage per chip
Removal	Removes unneeded material from a wafer’s surface (for example, photoresist after patterning or doping)	Completely strip unused material High (200 wafers/hr) throughput Rerun process for error recovery
Doping	Uses ion beam and photomask to implant ions to alter electrical properties of circuits and gates	Precise X/Y origin for each chip, with high positional accuracy across layers Precise dose delivered across mask surface

Table 3. Semiconductor-fabrication-tools contexts

 

On the surface, each of these examples appears to have enough commonality to motivate the creation of a single solution to span the domain. Yet, consider this advice, which was given a few years ago by an anonymous participant at a software-product-line conference session:

The primary motivation for companies to embark on product-line architecture is to gain ROI by exploiting commonalities among products. Unfortunately, the only way to reliably realize the increased ROI is by comprehending and managing the differences among the products.

 

Architectural Implications

Suppose that you are trying to raise several million dollars to design and build a general-purpose medical-reporting-system solution. You expect that the venture capitalists will want to know, “For which parts of the medicalindustry will your system be an effective solution?” (This is a fictionalized example that is based on the author’s prior experiences with medical-reporting challenges in healthcare institutions.)

The multiple-context approach provides a useful framework for addressing this question. Three high-level steps are required:

1. Identify contexts and characteristics.
2. Analyze contexts by using comparisons of challenges.
3. Synthesize compatible contexts.

Anatomy of a Context

Before we drill into the medical-reporting example, let us take a few moments to explore the anatomy of a context. Figure 1 illustrates a general pattern that represents the goodness of fit between a context and solution.

Figure 1. Solution fit, with context (Click on the picture for a larger image)

 

As previously mentioned, members of the context share similar desired outcomes and face similar challenges. This is due to the fact that they share similar perceptions and priorities and are subject to similar environmental forces and conditions.

When challenges block desired outcomes, a gap is created between the current and future states. Painful or desirable gaps motivate solutions that overcome the gap’s unmet challenges. A solution is successful if the prioritized challenges of its contexts are addressed well by the features and capabilities of the solution architecture.

Step 1: Identify contexts and challenges.

Identifying contexts seems like a simple-enough proposition. However, doing this well relies heavily on systems-thinking skills, which provide the ability to abstract and understand arbitrary systems in context. Several authors (such as Ackoff,³Senge,⁴ Goldratt,⁵ Weinberg,⁶ and Taleb⁷) have written excellent texts that address various aspects of systems thinking.

For example, we might consider organizing contexts by institution size: physician practice, outpatient clinic, community hospital, urban medical center, and university hospital. However, this is not as useful a segmentation tool as it might appear. The boundaries do a useful job of organizing by size, but there is too much diversity within some contexts and too much overlap among them.

A better set of segmentation criteria can be found by examining behaviors around the intended function: medical reporting. Whenever a patient sees a clinician, a medical report must be created and stored in the patient’s file. These requirements apply from small physician practices up to large hospitals; methods vary from paper files to electronic records. Some common requirements for all contexts include:

• Capturing the following information:
  • Identity of the patient and medical provider.
  • Date and time of the encounter.
  • Physician’s observations and findings.
  • Physician’s diagnosis of the condition (or possible diagnoses).
  • Physician’s recommendations for treatment (if any).
• Storing patient medical records in a database, from where they can be efficiently queried by patient, diagnosis, time period, and several other criteria.
• Producing accurate medical reports quickly. Medical-report generation is just as necessary to healthcare as driving is to a transportation business, and just as unprofitable.

One important insight is that there are some important patterns in the reasons that medical reports are created. These patterns identify clusters of behavior and form initial hypotheses for contexts, as summarized in Table 4.

Process	Description	Contextual drivers
Order-centric	Physician orders images or lab tests to gather data about a patient’s condition.	Provider does not interact with patient Very low provider-patient recurrence Provider is usually a specialist in specific image or lab procedures Emphasis on this encounter, not history Provider cannot type while performing Transcription turnaround is 6–10 hours
Treatment-centric	On-going treatment for a specific medical condition for a patient (for example, chemotherapy).	Provider is typically a specialist Provider has recurring patient interaction Patient and family history are essential Moderate interaction frequency Routine urgency for exchange of patient medical data with other providers
Patient-centric	Ongoing treatment for several interrelated medical conditions, often as an in-patient.	Many providers collaborating, with frequent (daily or more) encounters Patient history and family history are essential Urgent need to exchange information Need to order and coordinate images and lab tests Need to coordinate pharmaceuticals

Table 4. Medical-reporting contexts

 

Cross-context commonalities are often apparent, as the three preceding examples show. However, below the surface, important context-specific variations exist.

Step 2: Analyze contexts by using comparisons of challenges.

Our initial context descriptions in Table 4 are a useful start. However, in order to better understand their desired outcomes and challenges, we must pop-up a level. We must better understand how medical reporting fits into the overall scheme of healthcare institutions in each context.

A critical caution should be made here. Naïveté is the cause of a large percentage of poor architecture and design decisions.

Sometimes, the naïveté is about a poor understanding of contexts in which a system will be used; at other times, it is about constraints that are inherent in the solution technologies or how two technologies might interact. Subject-matter expertise is tightly coupled with systems thinking. The skill of recognizing central organizing principles and using them to reason about other areas can greatly increase the velocity of learning.

Additional research—such as interviews with industry experts or published market-research reports—is needed to increase the depth of our understanding. Table 5 shows an example output from this activity.

Challenge	Order-centric	Treatment-centric	Patient-centric
Massive scalability (patients, physicians, reports, and so forth)			1
Efficient exchange of information among providers			2
Efficient use of patient-history/family-history medical reports		1	3
Quick access to prior medical reports of a patient		2	4
Reuse of diagnoses from prior medical reports of a patient		3	5
Integrated symptom/diagnosis DB		4	8
Updating of medical reports, prescriptions, image/lab data from external sources		5	7
Updating of family history from external sources		8	9
Integration with hospital and departmental information systems	2	6	6
Reduction of time for each order to improve throughput	1
Automated assignment of order to provider	3
Immediate completion of medical reports (> 1-day turnaround for transcription)	4
Provider does not recall report details when review not immediate	5
Providers cannot type while performing analyses	6

Table 5. Cross-context challenges for medical reporting

 

Two conclusions are readily apparent from this analysis:

1. The Treatment-centric and Patient-centric contexts are rather similar. The top-five priority challenges for Treatment-centric are numbers 3–7 in Patient-centric and are ranked in the same order. Both contexts have direct interaction with patients and must collect medical-record data for use in future encounters. The primary difference between the two is driven by the size of the institution and the fact that several providers interact with each patient.
2. While the Order-centric context performs medical reporting like the others, it has very little similarity in its high-priority challenges. Participants in the Order-centric context are high-throughput factories, which are driven to make continual improvements in throughput and turnaround time for completing orders.

Step 3: Synthesize compatible contexts.

The analysis of prioritized challenges is a litmus test. It is useful for making educated guesses to rule out obvious mismatches and identify affinity among other contexts. However, by itself, it usually is not precise enough to make definitive decisions.

To get more precise, we must consider important aspects of the solution architecture. In some cases, you begin with an existing architecture; at other times, you do not. For the medical-reporting example, we assume that we are starting with a clean slate. Figure 2 illustrates a way to approach this problem, which can be adapted to cases in which the solution architecture exists or is hypothetical.

Figure 2. Multiple-context assessment (Click on the picture for a larger image)

 

Figure 2 shows five aspects that are important for multiple-context analysis. Each of these is discussed in the following subsections. Space limitations do not permit an in-depth exploration of a multiple-context architecture of the medical-reporting example. However, examples from this problem will be used to embellish these aspects.

Context Analysis

Step 2 of the process elaborated three contexts that are relevant to the medical-reporting problem. In Table 4, we identified these contexts and captured their drivers (for example, forces, conditions, and perceptions). In Table 5, we prioritized the challenges for each context.

Architecture Approaches

An architectural approach is a small set of related decisions that are intended to attack one or two specific challenges⁸ .An ordered list of architectural approaches (plus the rationale for each) is the nucleus of an architectural strategy. Earlier architectural approaches tend to constrain later ones. For this reason, it is good practice for earlier architectural approaches to focus on the challenges of highest priority.

In the medical-reporting example, the Patient-centric context has a high-priority need to enable communication among clinicians. However, this is not a pressing priority for the Treatment-centric context. Assume that we want to preserve the opportunity to address both contexts with a single platform. To do so, we must find a suitable approach for this problem that minimizes the constraints that it imposed on other challenges.

One way to accomplish this might be to provide a message-based communication subsystem that:

• Tracks communications with a collection of messages, where each message is managed like an e-mail message (text with optional multimedia attachments).
• Links messages to senders and recipients using status records. Each record holds a foreign key to a clinician and the most recent access time and status.
• Stores clinician communication in a separate database (or set of tables), with foreign key relationships to patient records.
• Supports multiple response (discussion) chains for each message.
• Permits certain medical actions (for example, submission of a radiology or lab request) to trigger a notification message when the action has been completed.
• Provides Web-based clients, who are running on desktop/laptop computers and smart phones, the ability to read and initiate messages.

Approach Adaptability

In addition to attacking challenges, each architectural approach also offers a certain level of flexibility. In Figure 2, this is represented by a label that appears to the left of the approach. These labels can be extended, as needed. The following is one possible set:

• Rigid—Approach is fixed at compile time, no mechanism to alter
• Modify—Source code for approach exists, can be altered and recompiled
• Config—Rigid or modify, but with parameters that can be set at runtime
• Extend—Can use subclassing to inherit/override behavior
• Plug-in—Uses Strategy design pattern⁹ to enable load/unload of components

An approach like the one that was previously described can be designed in a modular way. Runtime configuration and plug-in components can be used to customize the needs of different contexts. These features could be one of the following:

• Excluded entirely for Order-centric contexts
• Supported entirely for large Patient-centric contexts
• Supported partially (for example, omit multimedia attachments or discussion threads) for other contexts

Approach Suitability

The Software Engineering Institute (SEI) wrote about a technique for assessing software-architecture suitability.¹⁰ In this approach, architectural decisions are scrutinized for how well they support quality-attribute scenarios. In our model, architectural approaches are equivalent to SEI architectural decisions, and quality-attribute scenarios are equivalent to desired outcomes and challenges in a context.

To assess the suitability of an approach, form a matrix that has challenges as the columns and approaches as the rows. The challenges might be from one specific context or might be blended from two or more. The list of approaches might be extracted from an existing architecture or might have been formulated as part of a hypothetical architecture.

Each cell in this matrix represents the impact of one approach on one challenge. Possible values include the following:

• Neutral—Approach does not address the challenge or affect it in any way
• Positive—Approach helps to overcome the challenge. The magnitude of the impact might be high (+++), medium (++), or low (+).
• Negative—Approach exacerbates the challenge. The magnitude of the impact might be high (– – –), medium (– –), or low (–).

Another approach is to color the cell by using three shades of green to represent positive impacts and three shades of red to represent the negative impacts. The visual presentation helps identify trade-offs (negative impact) and coverage (limited or no approaches to a challenge).

In the medical-reporting example, suitability can be assessed in two ways:

1. Partial suitability assesses the impact of an approach to all challenges, including the challenge that the approach was intended to address. Negative impacts on other challenges can stimulate consideration of alternative approaches.
2. Full suitability requires a full set of approaches and challenges, and provides additional insight into how other approaches might have side effects that reduce the impact on the primary challenge.

Approach Dependencies

A similar matrix, which is illustrated in Table 6, is useful for identifying the dependencies among approaches. This is critical for any analysis that attempts to reuse software across two contexts that are not highly compatible. Any software that is being reused must be loosely coupled to the things on which it depends.

Type	Description	Dependency-level examples
Usage	Nature of the dependency	Functional (invoke an operation) Information (exchange data) Control (sequence, timing, start, stop)
Interaction	Role (played by the approach in the column)	Requestor Provider Collaboration protocol/callbacks)
Coupling	Reliance (of column) on internal details (of row)	Loose (strict encapsulation) Medium (limited use) Tight (significant reliance)

Table 6. Types of inter-approach dependencies

 

Each cell in this matrix represents how the approach in the column depends on the approach in the row.¹¹ There are several types of cross-dependencies that can be represented in each cell.

In the medical-reporting example, this analysis might highlight that the messaging approach depends on a special mechanism to deliver asynchronous notifications from the server to Web clients. The solution architectures for the Treatment-centric and Patient-centric contexts can already include such a mechanism, but the Order-centric architecture might not. This realization forces us to either:

• Consider the viability of including this approach (and all of the approaches on which it depends) in the Order-centric context.
• Determine if there is an abstract strategy that permits the Order-centric approach to use a different mechanism from the others, or
• Figure out a way to factor out the asynchronous notification, so that it can be excluded from the Order-centric solution.

 

Conclusion

Multiple-context systems occur when one solution seeks to resolve several sets of stakeholder needs and environmental forces. The approaches to architecting single-context and multiple-context systems, while similar, have some critical differences. The latter require you to discern the contexts, identify and prioritize the key challenges in each, and compare these lists to determine whether the challenges are compatible. As soon as this determination has been made, the compatible contexts must be prioritized according to business value, and their weighted challenges must be merged into a blended list. Then, the process of considering the challenges in order of descending priority and formulating effective approaches is essentially the same.

 

Endnotes

1. In this use, forces typically are environmental factors that are uncontrollable, while conditions are situational factors that might or might not be controllable. A technological breakthrough from another industry is a force. A competitor’s new product that is based on that technology is a condition.
2. Alfred, Charlie. “ Value-Driven Architecture: Linking Product Strategy with Architecture.” The Architecture Journal. Issue 5, July 2005.
3. Ackoff, Russell L., and Fred E. Emery. On Purposeful Systems:An Interdisciplinary Analysis of Individual and Social Behavior as a System of Purposeful Events. New Brunswick, NJ: Aldine Transaction, 2006. (Discusses the importance of synthesis and analysis, and the key distinctions between multi-goal-seeking systems and purposeful systems.)
4. Senge, Peter. The Fifth Discipline: The Art and Practice of theLearning Organization. Rev. ed. New York: Doubleday/Currency, 2006. (Contains an excellent discussion of systems dynamics and ways in which to model and communicate this.)
5. Goldratt, Eliyahu M., and Jeff Cox. The Goal: A Process of OngoingImprovement. Third rev. ed. Great Barrington, MA: North River Press, 2004. (Presents the theory of constraints and the requirement to identify and attack the dominant constraint.)
6. Weinberg, Gerald M. Rethinking Systems Analysis & Design. New York: Dorsett House Publishing Co., 1988. (Discusses systems thinking as a learning accelerator and the importance of context.)
7. Taleb, Nassim Nicholas. The Black Swan: The Impact of the HighlyImprobable. New York: Random House, 2007. (Discusses the powerful role of uncertainty and human vulnerability to the improbable event.)
8. (Fixed-time-period task scheduling is an architectural approach of a real-time OS; and atomicity, consistency, isolation, durability (ACID) transactions are an architectural approach of a relational database-management system (DBMS).)
9. Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley Professional, 1994.
10. Clements, Paul, Rick Kazman, and Mark Klein. Evaluating SoftwareArchitectures: Methods and Case Studies. Boston, MA; London: Addison-Wesley Professional, 2001.
11. This permits bidirectional dependencies; that is, Approach A is highly dependent on Approach B, while Approach B has little or no dependency on Approach A.

 

About the Author

Charlie Alfred (charliealfred@comcast.net) has 30 years of experience in software development, including the last 10 years as a software architect. During this time, he has worked on several types of systems, including real-time control, transaction processing, optimization, and software-product lines. Charlie lives with his family in Nashua, NH.