Architecting multiple context systems

Today,  many systems need to be designed to work in many different contexts.  Consider GPS technology as an example.  GPS receivers support a wide range of applications, from driving to hiking, to the autonomous operation of farm or mining equipment.  The needs for accuracy and availability vary widely across these applications.  In addition, GPS receivers must be designed to operate in a variety of weather conditions, with a variety of natural and man-made obstructions.  How do you balance these benefits and challenges if you are designing software that uses GPS technology?

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.  In the above example, different GPS applications contexts include: a) autmobile drivers, b) hikers, c) boaters, d) automatic farm equipment (e.g. unattended corn or wheat harvesters), e) automated ore removal vehicles in mines, etc.  Automated farm equipment or mining users need accuracy of a few feet.  Automobile drivers require enough precision to match them to the correct road.  Hikers often hike in forests or canyons which block signals from GPS sattelites. 

When applications are deployed in a single context, environmental conditions and stakeholder perceptions usually converge, and this convergence helps to resolve tradeoffs.  However, whenever multiple contexts come into play, the tradeoffs are less clear and the design decisions become more difficult.  The following article, https://charliealfred.wordpress.com/multi-context-systems/ recently published in Issue 23 of Microsoft Architecture Journal provides some thoughts about how to address this type of problem.