- Success and Failure of Projects and Strategies
- Core Competencies
- Education
- The Need for Understanding: Abstraction, Precision, Explicitness
- Abstraction: The Way to Put Management in Control
- Basic Structuring Constructs
- Business Rules: Precision vs. Handwaving
- Tacit Assumptions and "Evident Truths"
- Specifying Problems and Solutions
- Where to Start and Why: Business Domains
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Need for Understanding: Abstraction, Precision, Explicitness
How do we achieve understanding essential for decision making? We should concentrate on the essential, we should be precise when doing so, and we should explicitly state what we mean—no more and no less.
Abstraction—the suppression of irrelevant details—is the only way for humans to achieve understanding of complex systems. Abstraction helps us to capture the essential and to make decisions demonstrably based on that essential. And abstraction works in everyday life [WD1996]. Harry Beck, the author of the abstract map of the London Underground created in 1933 (www.thetube.com/content/tubemap) was told that the abstract shape of that map would be too strange and incomprehensible for the ordinary user9 of the Underground network. The evidence provided by billions of successful ordinary users of the London Underground shows that, contrariwise, this "instantly clear and comprehensible chart ... became an essential guide to London," as noted on the London Underground Web site (www.thetube.com).
We use abstraction all the time, so the usage of modeling as a kind of abstraction is only natural. As Friedrich Hayek observed, "from time to time it is probably necessary to detach one's self from the technicalities of the argument and to ask quite naively what it is all about" [H1937]. A specification of an IT system only by means of its code is certainly precise but not abstract and therefore cannot be understood. (Such kinds of specifications are sometimes called "write-only." A write-only specification, if it is precise, may be of some use for its author, but it is useless for everyone else.) Of course, abstraction is essential not only in modeling of existing businesses and IT systems, but also in specifying new ones.
Abstraction by itself is necessary but not sufficient for understanding. An abstract, but imprecise, model may mean almost anything at all, and therefore is useless for decision making. The "few beautiful graphics that were laughably called a business plan" [L2001] for dot-coms did not qualify as a business plan (or as any kind of a useful model, for that matter) precisely because they represented abstract but very imprecise models: the meaning of these graphics was never clearly defined. Such models may be used only to make decisions based on hype and enthusiasm, as opposed to the fundamentals of the business.
A model should provide abstract and precise answers to all relevant questions about the modeled world. These answers demonstrate understanding of the modeled world and its environment, and lead to successful decision making. A useful model may be understood only if all statements of that model have precise meanings, that is, only if it is possible for each statement to determine whether or not it is valid. Statements like "this line between these two boxes formally identifies the relationship between the customer and the supplier" are anything but precise.
Even an abstract and precise model may not be sufficient for understanding. A model in which important facts and assumptions are not included because "everyone knows them" is inadequate because in most cases these "obvious" facts are understood differently by different stakeholders and because not all stakeholders are aware of these facts. Assuming that "they will figure it out" is a totally inadequate mechanism for dealing with such implicit information: a model should be understandable without the experts being around to explain it. All important facts should be explicitly included in the model.
In the same manner as E.F. Codd provided an abstract, precise, and explicit definition of the relational data model [C1970], as opposed to the then existing navigational data models formulated in terms of realization and therefore too complex, all kinds of specifications ought to be abstract, precise, and explicit, as opposed to some existing specifications formulated in terms of realization, or otherwise semiotically polluted [P2000], and therefore too complex. Codd's definition of a relational data model was based on a small number of simple concepts well-known from mathematics, and was centered around the stable properties of the domain of relational data rather than around navigation within that domain. Business specifications described in this book have similar properties.
Essentially, our specifications must be elegant to ensure that they are written and read with pleasure. After all, specifications are our tools; as in programming, "the tool should be charming, it should be elegant, it should be worthy of our love. This is no joke, I am terribly serious about this. ... The greatest virtues a program can show: Elegance and Beauty." [D1963]. As an important consequence, beautiful specifications are easier to change.
The following sections describe abstraction, precision, and explicitness in more detail. Abstraction and structuring mechanisms are emphasized because they have often been underestimated, especially in various IT contexts.