Throughout the history of computing, previously unserved user needs, when matched with then-novel technology innovations, have created the circumstances when, suddenly, a new computing paradigm emerged. Such as:

HW: hardware, SW: software.

We are at such an inflection point again, and this is how it shows itself:

Situational Software is the software component of Situational Computing.

Situational Software is different from all previous computing paradigms in one essential aspect: the notion of a "software application" — the key value driver for decades — gets relegated to a secondary role in favor of the new concept, the "situation". Here is a comparison:

So what is a situation? It's what you see when you open your eyes. It's what they mean in the movies when someone says "We have a situation here."

A situation is the combination of people, things, information and capabilities that, together, have relevance to the user at a certain moment in time.

Here are some examples for situations in which situational software is advantageous:

Through Situational Software, the physician's mobile device is aware of the care situation of the patient in front of whom the physician stands right now. The mobile device accesses things (e.g. patient monitoring devices) and information resoures (e.g. patient records), provides capabilities (e.g. ordering a lab test), knows which other people are involved in the care of this patient (e.g. nurses) and provides communications and collaborations functionality that allow the physician to optimally work with them in this care situation.

When the physician's situation changes (e.g. because the physician moves from one patient to the next treatment room with the next patient), the mobile device recognizes the change in situation and provides appropriate support for the next situation. As the care situation of the second patient may be substantially different from the first one's, the mobile device will likely access different things and information resources, provide different capabilities and connect the physician to different people.

The acid test for situational software is whether or not it supports each new situation appropriately, or whether it just provides the same functionality, even if the situation is really different (in which case, it would be a traditional, albeit mobile, application). While theoretically, one could construct application software with a different set of screens and dialogs for each possible care situation (say, every patient in a hospital), in practice, the "software application" paradigm is simply the wrong paradigm to apply to situational patient care. The key here is federated development/deployment of the situation's components, but more about this in a later post.

Here's another example:

In this situation, the shopper's mobile device is aware of its location in a grocery store, and also of all electronic devices in its vicinity that act as a "beacon" (using technologies such as RFID, Bluetooth, GPS etc.). Because it is the shopper's personal device, the mobile device has access to the user's personal information, such as a shopping list.

Situational software, in this scenario, can match items from the user's personal shopping list, with encountered articles around the user, and augment it with information from remote sources, such as customer satisfaction statistics on the particular product from a public web site/service. By providing appropriate capabilities for the situation, the user can immediately perform activities such as purchase, order, or finance the article.

The acid test for situational software here is whether the situational representation, as shown on the device, literally changes as the user walks down the aisle, and keeps changing on the way through the mall. Without any one "application vendor" having to corral all product vendors and retailers to support one humongous application covering "everything".