Moving home and office 11,000 miles can really get one thinking about what is essential. Packing everything for a year abroad into suitcases and cartons certainly highlights the difference between “needs” and “wants,” a distinction made sharper by excess baggage charges of over $90 per bag. In software and applications development it is also important to get down to essentials, to distinguish the essential heart of what you need to program from the inessential wants and the unnecessary what-ifs.
Essential modeling is a conceptual tool for focusing the developer's mind on what matters. An essential model is a representation of the core of an application, a problem stripped down to its bare essentials, stripped, that is, of all unnecessary or constraining assumptions.
The notion of essential modeling in software traces back at least to the origins of structured design. Data flow diagrams were intended as a nonprocedural model of computation, one that separated the essence of what the computer was to do from how it was to be accomplished through any particular algorithm or procedure. By designing the modular structure to fit this essential definition of the problem, it became possible to build more robust software whose basic form could survive changes in processing details. Or so the reasoning went. In practice, dataflow diagrams were often turned into little more than flowcharts with funny figures, a corruption encouraged by later enhancements, such as data stores and control flows, that implicitly invited procedural thinking. Essential models finally came into their own with the now-classic book Essential Systems Analysis (McMenamin and Palmer 1984), which made them the cornerstone of a revised and refurbished structured analysis.
In the broadest sense, essential models capture the essence of systems: a technology-free, idealized, and abstract picture grounded in the intentions of users and the fundamental purposes of the system that supports them. The best essential models are simplified and generalized through repeated refinement. They capture the nonphysical spirit of an application, not the physical embodiment in real code on real equipment.
An essential model is based on perfect technology—infinitely fast computers, arbitrarily large displays, keyless input from users—whatever would be needed to most expeditiously realize necessary functions. This flight into technical fantasy is not intended to indulge the imagination but to assure that the model is as independent of current technology as possible. Technology changes much faster than either business practices or people; solutions that are intimately wedded to any particular technology are ultimately less enduring, less flexible.
User interface design is one promising application of essential models. Essential use case modeling is an approach that extends Jacobson's object-oriented use cases (Jacobson et al. 1992) to apply to user interface design. An essential use case is an abstract scenario for one complete and intrinsically useful interaction with a system as understood from the perspective of the user's intentions or purpose. It is a generalized description of a kind or class of use to which a system may be put, conveying the user actions and system responses [*] in simplified and generalized form. The idea is to design interfaces to fit intentions— what users want to accomplish—with a minimum of presuppositions about technology, such as the shape of visual widgets or even the devices to be used for interaction.
For example, consider the task of withdrawing cash from an automatic teller machine. A physical model might take this form: customer inserts card; system reads magnetic stripe, requests PIN; user types PIN; system confirms PIN, offers menu of transactions; user keys in selection; system offers menu of accounts; user keys in selection; system requests amount; user keys in amount and presses confirmation button; system spits out cash; user takes the money and runs. What could be simpler?
Stripped of physical detail and technological assumptions, the essential use case for this task presents a simpler process: customer identifies self, system offers choices, user selects, system gives money, and user takes it. This description covers a lot more possibilities for the user interface design. It opens the way to a variety of media for offering choices to the user and for user selection, including touch-screen or voice response. It highlights that the ATM card and PIN are nonessential; their essential purpose is simply to identify the user. Thumbprints, iris scans, voice recognition, and badge readers might be workable alternatives in some cases. The essential model leaves open more possibilities, making it more likely that portions of any resulting design will be reusable when assumptions and conditions change.
This essential use case also paves the way to simpler interfaces by high-lighting the real heart of the matter to the user: getting the cash, the most common ATM transaction. Most users habitually take the same amount from the same account time after time. The first choice offered by the system could be this user's default, culled from past history: “The usual $250.00 from Regular Checking, Mr. Chatworth?” Or whatever.
The essential model presents an idealized design target. A well-designed user interface requires only as many steps or as much information as is spelled out in the essential use case. The bank customer wants to be able to say, “It's me. The usual. Thanks!” and be off. We spell out the ideal case because if we don't model it, we can't design to it. If we don't design to the ideal, we can't see where technology or technical assumptions are limiting us, and we may miss completely the opportunity for alternative approaches.
Another area in which essential models can be useful is in process reengineering. When it is not just another euphemism for layoffs or downsizing, business process reengineering can be an opportunity to make business processes more efficient and effective. In order to reengineer a process successfully, you must know what the process is intended to accomplish—what fundamental business or organizational purpose it serves. The single most essential issue in any process or system is the teleological question: Why does this exist? Why should it exist? What is it really for?
Consider the process of exchanging foreign currency at a bank. In some banks, in some countries, this can require queuing up twice or even three times, with multipart forms, repeated calculation of amounts, and sign-offs by multiple tellers and clerks. From the standpoint of the bank customer, such a transaction is ultrasimple: give money in one currency, get an equivalent amount in another. The bank has an interest in assuring that the exchange rates and amounts are correct and in making a small profit on the exchange, but has no real interest in generating paper or keeping clerks busy—not if the goal is process reengineering.
There is no essential need for a customer or clerk to fill out triplicate forms with names and addresses and signatures and amounts in numerals and text. Exchange rates need not be manually verified if they are derived from one central database; a display facing the customer, as used in many grocery-store checkouts, would serve to validate the incoming amount; a printout of the transaction satisfies the customer's need for a record; the transaction record into the repository gives the bank its audit trail. Indeed, I've used automatic cash machines in Europe that offer precisely this streamlined implementation.
Unfortunately, many professionals have trouble seeing the essence of their transactions. Not everyone is good at the sort of abstract thinking required for essential modeling. Thinking in terms of essentials can require setting aside the technical blinders that prevent us from seeing things in a fresh light. Meilir Page-Jones refers to this as “dereferencing,” mentally stepping out of the frame of conventional assumptions. It is something at which gifted comedians and talented designers are especially good.
I remember once motoring along the Rhein River with Meilir as he translated the German signs we passed. One pictograph showed only a black mass sloping down to the left to meet a stack of wavy lines. Canted in midair between the representations of the river embankment and the river was an iconic car.
Without hesitation, Meilir translated. “Beware of cars leaping from water on left,” he said.
Dereferencing. Try it. And think essentially.
From Software Development, Volume 2, #11, November 1994.
[*] These two sides of the model are probably even better characterized as user intentions and system responsibilities, which is precisely what they are called in usage-centered design, an approach based on essential use cases (Constantine and Lockwood 1999).