Multi-Context Systems

Introduction

A context is a collection of stakeholders who share a similar set of perceptions, priorities, and desired outcomes, and who are subjected to a similar set of conditions and forces. [1]  Marketing professionals call these 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. [2] 

Table 1 shows a simple example of contexts at work.  Consider a thinsulate ski parka, which is temperature rated to -40^oF.  You would expect this parka to be:

More Valuable to	Less Valuable to	Reason
Calgary resident in July	Calgary resident in January	Condition (seasonal)
Elderly person in Calgary	Young person in Calgary	Perception (tolerance of extreme temperatures)
Someone in Calgary	Somebody in Miami, FL	Force (climate)
Avid snow skier in Miami	Avid golfer in Virginia	Priority (hobby) over Force(climate)

Table 1: Context example 

While these generations may not hold true over every context member who matches the criteria, it is reasonable to expect that they will for a very 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’s first consider two real world examples: 

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

A third example, 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 pickup and deliver shipments within a local geographical area.  These organizations have several important commonalities: 

• Service effectiveness, measured by completion percentage of scheduled stops
• Reduce travel time (drivers get paid to pickup/deliver, not to drive)
• Managing vehicle weight and capacity constraints
• Respecting customer service windows and other physical constraints

Three common local area transportation contexts are summarized in Table 2:

Context	Description	Contextual Drivers
Parcel	UPS, Fed Ex, or 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 or Yellow Freight	~30 drivers per terminal Large (500 – 10,000 lb) shipments 600-800 stops daily Sparse stop density (~0.1 / sq mi) Industrial and suburban locations mostly Shipment position in truck is critical
Private Fleet	Bottled water or Food service	# of drivers, # of stops, shipment size varies 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 which creates hundreds of micro-processor or memory chips on a 300mm silicon wafer.  Complex circuits may require several hundred of 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 which move wafers between tools
• Electromagnetic control of pumps, vents, material handlers and other devices
• Tracking of process outcomes by batch, lot, and wafer

As shown in Table 3, there are four general classes of semiconductor fabrication tool, and the drivers for each tool have important differences:

Tool Type	Description	Contextual Drivers
Deposition	Add thin film of material with a thickness of a few nanometers on the wafer surface	Sub-nanometer thickness Precise depth of film across wafer Continue process from point of error
Patterning	Use an XY stepper to position at each die.  Create the desired negative on photoresist 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	Remove unneeded material from a wafer’s surface (e.g. photoresist after patterning or doping)	Completely strip unused material High (200 wafer/hour) 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, given by an anonymous participant at a software product lines conference session a few years ago: 

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

Architectural Implications

Suppose you are trying to raise several million dollars to design and build general purpose medical reporting system solution.  You expect that the venture capitalists will want to know, “for which parts of the medical industry will your system be an effective solution?”   This is a fictionalized example which is based on the authors prior experiences with medical reporting challenges in health care 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 Using Comparisons of Challenges
3. Synthesize Compatible Contexts

Anatomy of a Context 

Before drilling into the medical reporting example, let’s take a few moments to explore the anatomy of a context.  Figure 1 below illustrates a general pattern representing the goodness of fit between a context and solution.  

 

As mentioned above, the member(s) 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 motivated solutions which overcome the gap’s unmet challenges.  A solution is successful if the prioritized challenges of its contexts are addressed well by the solution architecture’s features and capabilities. 

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 understand arbitrary systems in context.  Several authors have written excellent texts addressing various aspects of systems thinking, such as Ackoff,[3] Senge, [4] Goldratt, [5] Weinberg, [6] and Taleb. [7] 

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 of 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 between 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 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 mandatory as driving is to a transportation business, and just as unprofitable.

One important insight is that there are some important patterns in the reasons why 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	Physician orders images or lab tests to gather data about a patient’s condition	Provider doesn’t 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 (e.g. 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	On-going treatment for several interrelated medical conditions, often as an in-patient	Many providers collaborating with frequent (daily or more) encounters Patient 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 examples above show.  However, below the surface, important context-specific variations exist. 

Step 2: Analyze Contexts 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 need to pop up a level.  We need to better understand how medical reporting fits into the overall scheme of health care institutions in each context. 

A critical caution should be made here.  Naivety is the cause of a large percentage of poor architecture and design decisions.  Sometimes it is poor understanding about contexts where a system will be used.  Other times the naivety is about constraints 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, are 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, etc.)			1
Exchange information efficiently among providers			2
Efficiently use patient/family history medical reports		1	3
Quick access to prior medical reports for a patient		2	4
Reuse diagnoses from patient prior medical reports		3	5
Integrated symptom/diagnosis DB		4	8
Update medical reports, prescriptions image/lab data from external sources		5	7
Update family history from external sources		8	9
Integration with hospital and departmental information systems	2	6	6
Reduce 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  

Figure 2 shows five aspects which are important for multiple-context analysis.  Each of these is discussed below.  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 relevant to the medical reporting problem.  In Table 4, we identified these contexts and captured their drivers (e.g. forces, conditions, perceptions, etc.).  In Table 5, we prioritized the challenges for each context. 

Architecture Approaches 

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

In the medical reporting example, the Patient-Centric context has a high-priority need to enable communication between 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 this, we must find a suitable approach for this problem which minimizes the constraints it imposed on other challenges. 

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

• Tracks communications with a collection of messages, where each message is managed like an email (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 (e.g. submission of a radiology or lab request) to trigger a notification message when the action is completed.
• Provides web-based clients, running on desktop/laptop computers and smart phones, to read and initiate messages.

Approach Adaptability 

In addition to attacking challenges, each architecture approach also offers a certain level of flexibility.  In Figure 2, this is represented by a label to the left of the approach.  These labels can be extended as needed.  Here 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 which can be set at runtime
• Extend           Can use sub-classing to inherit/override behavior
• Plug-In           Uses Strategy design pattern to enable load/unload of components

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

• excluded entirely for Order-Centric contexts
• supported entirely for large Patient-Centric contexts, or
• supported partially (e.g. 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.[ii]  In this approach, architecture decisions are scrutinized for how well they support quality attribute scenarios.  In our model, architecture approaches are equivalent to SEI architecture 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 with challenges as the columns and approaches as the rows.  The challenges may be from one specific context, or may be blended from two or more.  The list of approaches may be extracted from an existing architecture, or may 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: 

• Neutral          Approach does not address the challenge or affect 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, using three shades of green to represent positive impacts and three shades of red for the negative.  The visual presentation helps identify tradeoffs (negative impact) and coverage (limited or no approaches for a challenge). 

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

1. Partial suitability assesses the impact of an approach on all challenges (including the challenge 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 may have side-effects which reduce the impact on the primary challenge.

Approach Dependencies 

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

Each cell in this matrix represents how the approach in the column depends on the approach in the row.[iii]   There are several types of cross-dependencies which can be represented in each cell:

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)

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 may 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 it depends on) in the Order-Centric context, or
• figure out a way to factor out the asynchronous notification so that it can be excluded from the Order-Centric solution.

Conclusions

Multiple-context systems occur when one solution seeks to resolve several sets of stakeholder needs and environmental forces.  The approaches to architecting single and multiple-context systems, while similar, have some critical differences.  The latter requires you to discern the contexts, identify and prioritize the key challenges in each, and compare these lists to determine whether the challenges are compatible.  Once this determination is 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 descending priority order and formulating effective approaches is essentially the same. 

---

 

[1] In this use, forces typically are uncontrollable, environmental factors.  Conditions are situational factors which may be controllable or not.  A technological breakthrough from another industry is a force.  A competitor’s new product based on that technology is a condition. 

[2] Charlie Alfred, “Value-Driven Architecture: Linking Product Strategy with Architecture”, Microsoft Architecture Journal, Issue 5, June 2005. 

[3] Russell Ackoff and Fred Emery, On Purposeful Systems, Aldine Transaction, 2005, ISBN: 0202307980, discusses the importance of synthesis and analysis, and the key distinctions between multi-goal-seeking and purposeful systems. 

[4] Peter Senge, The Fifth Discipline: The Art & Practice of the Learning Organization, Broadway Business, 2006, ISBN: 0385517254, contains an excellent discussion of systems dynamics and ways to model and communicate this. 

[5] Eliyahu Goldratt and Jeff Cox, The Goal: A Process of Ongoing Improvement, North River Press (3^rd ed), 2004, ISBN: 0884271781, presents the theory of constraints and the requirement to identify and attack the dominant constraint. 

[6] Gerry Weinberg, Rethinking Systems Analysis and Design, Dorsett House Publishing, 1988, ISBN: 0932633080, discusses systems thinking as a learning accelerator and the importance of context. 

[7]  Nassim Nicholas Taleb, The Black Swan: The Impact of the Highly Improbable, Random House, 2007, ISBN: 1400063515, 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 realtime operating system, and ACID transactions are an architectural approach of a relational DBMS. 

[9] Clements, Kazman and Klein, Evaluating Software Architectures: Methods and Case Studies, Addison-Wesley Professional, 2001. ISBN: 020170482X 

[10]  This permits bi-directional dependencies (i.e. Approach A is highly dependent on B, while B has little or no dependency on A).