Metaphors in Software Architecture

There is one constant, throughout the whole (short) history of software architecture, and regardless of the formality of the approach: it is the systematic use of metaphors to describe architectural elements and architectures.

Metaphors give meaning to form and help us ground our conceptual systems. A metaphor is a form of language that compares seemingly unrelated subjects: a rhetorical trope that describes a first subject as being equal or very similar to a second object in some way. A metaphor implies a source domain: the domain from which we draw metaphorical expressions, and a target domain, which is the conceptual domain we try to understand or to describe. The metaphor operates a cognitive transfer from the source to the target; it says in essence: “<the target> is <the source>.” Others call them the ‘metaphrand’ and the ‘metaphier’.

In Metaphors we live by [1], Lakoff and Johnson describe metaphors as “a matter of imaginative rationality.” They permit “an understanding of one kind of experience in terms of another, creating coherence by virtue of imposing gestalts that are structured by natural dimensions of experience. New metaphors are capable of creating new understanding and, therefore, new realities.” (p.235)

Metaphors are everywhere in software architecture. We use ontological metaphors to name things: “clients and servers”, “layers”, “pipes and filters”, “department stores and shopping cart,” etc. We organize those using structural metaphors that are often visual and spatial: “on top of”, “parallel to”, “aligned with”, “foreground, background”, but include richer ones such as “network”, “web”, or “hierarchy” [2]. We use a wide variety of containers: “packages”, “repositories”, “libraries”, “volumes”, etc. In reality, in the target domain, i.e., in the memory of a computer, we would not find any up, down, aligned, packaged, etc.; everything is pretty scattered around; just look at a “core dump” file!

A mapping is the systematic set of correspondence that exists between constituent elements of the source and the target domains. It allows some limited reasoning in the target domain by analogy and inference. In our case, the target domain —software architecture— is rather abstract, and we try to draw from source domains that are much more concrete. Then we use inference patterns from the source conceptual domain to reason about the target one. “Ay, there’s the rub, for” we may abuse the inference or have a faulty inference. This leads to flawed metaphors, where the analogy “breaks” and the meaning in the target domain (in software) is confusing at best. It is also very common when we attempt to combine multiple metaphors, drawing form different source domains. This conceptual integration between domains, where the designer uses 2 different domains and combines them is what Imaz and Beyon call a blend [6]. A good blend is rather delicate to achieve and often leads to confusion. When successful, it draws on both coma insdomains file management.

Metaphors have been used to describe general organization of software systems; they have played an important role in the object-oriented movement, and then were really put at the center of the pattern movement. No reasonable pattern can be successful that is not supported by an elegant metaphor [3, 4]. More recently Beck in eXtreme Programming (XP) described a practice he called “metaphor” to convey the concept of a simple summary of the architecture [5]. It is unfortunate that this practice has been the least successful of XP. Beck should have boldly called it Allegory: an extended metaphor in which a story is told to illustrate an important attribute of the subject, or even a Parable!

References

1. G. Lakoff and M. Johnson, Metaphors we live by. Chicago: The University of Chicago Press, 1980.
2. D. L. Parnas, “On a ‘buzzword’: hierarchical sructure,” in IFIF Congress 74, Stockholm, Sweden, 1974, pp. 336-339.
3. E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995.
4. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal, Pattern-Oriented Software Architecture: A System of Patterns. New York: John Wiley & Sons, Inc., 1996.
5. K. Beck, Extreme Programming Explained: Embrace Change. Boston: Addison-Wesley, 2000.
6. M. Imaz & D. Benyon, Designing with Blends, Boston: The MIT Press, 2007.