System Metaphor

Definition: What ExtremeProgramming (XP) uses to unify an architecture and provide naming conventions. A simple shared story of how the system works, a metaphor. This story typically involves a handful of classes and patterns that shape the core flow of the system being built.

In DomainDrivenDesign, EricEvans notices that the purpose of the SystemMetaphor is to facilitate communication across the WholeTeam: SystemMetaphors are not useful on all projects. Large-scale structure in general is not essential. In the 12 practices of ExtremeProgramming, the role of a SystemMetaphor could be fulfilled by a UbiquitousLanguage. Project should augment that language with SystemMetaphors or other large-scale structures when the find one that fits (page 449) [huh? Can someone look this up?]

System Design and Programming is a social event; therefore the team will always be bound by the social construction of their reality. The idea of using a SystemMetaphor to facilitate communication works toward revealing the reality of the team towards its task. For a team starting out, metaphors are a comfortable and flexible starting point and they leave open the chance to use the metonymy that patterns provide.

Ask yourself, what more familiar things is this problem like? Is it really like ordering coffee from a fancy coffee machine? Is it really mostly like steering (tacking) a sailboat across a lake? driving from Toronto to Paris? (...a journey of less than 90 minutes, since Paris is just on the other side of Brantford. -- RandyMacDonald) (just to avoid the CanadianCulturalAssumption)

You mean Paris, Kentucky, right? :) Or perhaps a polar route during a cold winter...

Whoever tried to clean this up by deleting didn't fix the underlying problem, so I put it back. Next WikiGnome: clarify the driving-from-Toronto-to-Paris issue or leave as is for now.

No, best left! It illustrates rather beautifully the way subtle misunderstandings can arise. Developer-One says: "This is like driving to Paris", meaning a short journey. Developer-Two gets a mental image of driving through the Chunnel from the UK to France, and considers how to avoid trains. Developer-Three (in the USA) ponders submarine cars. The misunderstandings here highlight the importance of MeaningDependsOnContext in discussions, especially about something as crucial as the SystemMetaphor. -- BenLast

Surely the problem, at its core, is rather like something your team already knows how to experience. Uh, this may take some brainstorming... And, you then have to code up a SpikeSolution to check whether the metaphor actually holds water for your problem (pardon the metaphor). -- AlistairCockburn

From the OOPSLA 97 paper (see: ExtremeArticle):

Chrysler is a manufacturing company; we make cars. Using a manufacturing metaphor to define the project was an important first step in getting the team (and management) on a level playing field. The concepts of lines, parts, bins, jobs, and stations are metaphors understood throughout the company. The team had the benefit of a very rich DomainModel developed by members of the team in the project's first iteration. It gave the members of the project an edge in understanding an extremely complex domain.

A rather extreme form of unifying SystemMetaphor is "EverythingIsa."

So what SystemMetaphor can we use for wiki. Pieces of papers that everyone can write on?

As best I can discern from the limited description of SystemMetaphor here on the wiki, the SystemMetaphor only really describes the logical architecture of the system. The logical architecture is, in the case of OO systems, the most important classes and objects and how they interact. SystemMetaphor does not seem to address bigger architectural issues such as if the system should even be implemented using objects, the hardware component of architecture, the process and inter-process communication component of architecture, or the separation of the system into layers and/or components. I don't mean to suggest ExtremeProgramming (XP) does not address some or all of these issues, it just isn't done in the SystemMetaphor.

Isn't the intent of the SystemMetaphor to improve communication among the entire team (customers and non-programmers included) by creating a common way for all to view the system, rather than just expressing an architecture to the programmers?

"The system is a bakery" jibes better than "The system interprets text as commands and executes them against builders that produce resultant objects and attach assorted decorators, sorting them via pipes and filters to the correct bins; the user can than browse and eat them as needed." -- RodneyRyan?

DesigningAnAuthenticationSystem illustrates (by a story) how a SystemMetaphor can be used.

The notion of SystemMetaphor is inescapable, since the system is always the MACHINE (See MichaelJackson's book SoftwareRequirementsAndSpecifications) and the representation of the Application Domain is always a metaphor built over data and process physically represented by memory cells and a CPU. -- RaySchneider

Hmmm, I think we've lost sight of what a Metaphor really is. I believe a SystemModel? is inescapable, but SystemMetaphor is not. Fundamentally all players in a system development will, as a bare minimum, be working with a MentalModel of the system, but to describe the system by analogy (the SystemMetaphor) is extra work that may or not be carried out (or required) (or useful) -- PaulGallagher?

[Q: is part of the role of SystemMetaphor to ensure that all the players have a simple, shared vocabulary for synchronizing their MentalModels? LaurentBossavit's comments near the bottom seem to suggest yes. -- WikiWikiWeb]

Can "J2EE Blueprints" be a system metaphor? -- JefNewsom

Why metaphors at all? asks someone on eGroups: Why should we use an imprecise representation of what we already understand?

For my money the answer lies in an article written by PeterNaur in about 1986, called "ProgrammingAsTheoryBuilding". I read it in the book Computing as a Human Activity, a collection of Naur's writings, probably just around his retiring or something.

In it, he argues vociferously against "methods" on the grounds that you can't possibly prescribe solutions to intellectual problems. But that's not the relevant bit.

The relevant bit is where he says that a program manifests a theory that the programmer has constructed about the problem and the solution and how they match. The quality of the design has a lot to do with the quality of the match.

But even more relevant is where he says that the maintenance or next programmer is faced with creating a theory about the problem and the *previous* programmer's solution, and the quality of his addition to the code base has a lot to do with how closely *his* theory matches the previous programmer's theory.

Suddenly metaphors become relevant. I visited ChryslerComprehensiveCompensation, and saw that the people there were operating to approximately the same theory. The metaphor, with all of its associations flying around people's brains, holds together a "theory" about the system that is easy to transfer to another person's brain. Say a few more sentences about which aspects of the selected metaphor are relevant to the system under design, and the listener suddenly has a huge theory to work from in examining, and adding to, the system.

The difference between AntsAndBees is suitable. You might find that the bees metaphor does not hold up well as a theory for the solution, the design of the system, because you want more trails being laid than missionaries returning with maps. That simple distinction - assuming its relevant - holds together a lot of code text and informs a lot of programmers quickly over a long period of time.

And that's why a metaphor for the system is valuable (IMO). -- AlistairCockburn

Another reason a shared story, or metaphor, could be useful: Agreeing on common language to describe a problem facilitates community knowledge over individual knowledge. -- DaveHoover And a community theory of a business system (based on that collective learning/knowledge) is likely closer to the mark than an individual's theory. And if it requires a reduction or simplification of the lexicon to achieve that consensus story/theory, all the better for the eventual system. Caveats: Don't rule out an innovative view of the system, don't dumb-down to simplify... dumb-up :) -- ChristopherGaltenberg

I agree with Alistair. Here is a disconnected remark.

I think we make a mistake when we think that SystemMetaphor is some exotic thing. After all, we use the object metaphor all the time: this set of bits is an object. Object orientation is metaphorical thinking.

Stack, desktop, window, JINI lease, even Account. That set of bits in RAM isn't really an account, but it is useful to think that it is. And, if it ever becomes more useful to think of it as a reservoir served by pumps, you can go to that.

Personally, I think that 'RenameClass' is the most powerful refactoring. You have to be very careful with it.

-- MichaelFeathers

In ObjectOrientedSoftwareConstruction, BertrandMeyer points out that as powerful and useful as metaphors are, they can be dangerous. Specifically, if metaphors are taken too much at face value, one may mistakenly make "proofs by analogy":

A resembles B
B has property p
Therefore A has property p

Is there a danger in taking the SystemMetaphor too far and drawing false insights from it? If so, how does one know when the line is being crossed? The point is also made that the more compelling the metaphor, the greater the danger of crossing the line. -- TimVoght

For my money, the relevant section in ObjectOrientedSoftwareConstruction is essentially content-free. Bertrand points out that metaphors are a powerful tool in the exposition of difficult ideas (without giving specific examples) then asserts that they are dangerous, giving as sole evidence for the assertion a passage by BenjaminFranklin quoted out of context and ridiculed by Gaston Bachelard. The only substantive argument given is that we must be wary of the "proof by analogy", as given above.

The "proof by analogy" is itself a StrawMan. If we say that a Kohonen Net is like an anthill, or that SETI is like a beehive (see AntsAndBees), I doubt that we will ever be tempted to say that a Kohonen Net has mandibles, or that a SETI cluster has yellow and black stripes. The actual use of metaphor is more as follows:

B has property p
It is useful to pretend that A had a property structurally similar to p
Therefore it is useful to pretend that A resembles B

In other words, the "danger" that a metaphor does not correspond well to a (supposed) underlying reality, and will therefore yield "false" insights, is a non-issue. Michael above - and Bertrand himself, for that matter - point out that there is no non-metaphorical vocabulary we can use, other than perhaps that of electrons or printed circuits, or, just a level above, that of bits and bytes and CPU "instructions".

There is precisely as much "danger" of drawing "false" insights from the use of a high-level metaphor as there is of drawing "false" insights from a low-level metaphor.

It seems to me that what SystemMetaphor says is this:

: identify, or build, or evolve, a way of describing and talking about the system which a) serves the criterion of utility - talking about the system in this way rather than in another way makes it easier to write the next story, write the next test, or name the next class - and b) can be shared by all the people involved in the conversation that building the system constitutes.

-- LaurentBossavit

It can be, has been, argued that every idea we have is a metaphor; that our mind is just a big network of linked "Same as, except"s that are all more or less suspect when it comes to modeling the world. If you provide a metaphor, then the metaphors that members of your audience develop for themselves may share some features, and serve as common ground for communications.

If you don't suggest a metaphor, then their metaphors will probably share fewer features, especially at first. That forces everyone to develop their own metaphors by trial and error, then go through many of the same trials and errors all over again to communicate - and with no proof that all the tsuris will result in better metaphors than would result from providing a common metaphor to begin with.

PaulGallagher? and TimVoght, is there a reason to assume that the audience's metaphors will be "purer" or "more accurate" if the SystemMetaphor is not provided? -- RonPhillips

Can I consider SystemMetaphor as an early conceptual model? -- StephenSuen

Why would it be early?

You could consider the SystemMetaphor as a way of structuring the ConceptualModel. All systems should have a ConceptualModel, describing the concepts visible to users and the associations between them. It is easy to end up with a very complex ConceptualModel though. Think about the concepts Windows users are expected to get their heads around! A SystemMetaphor provides an overall 'theme' to the model. Apple did this with their original DesktopMetaphor. -- MikeHowells

The important thing about metaphor is that is an aid to explanation, not persuasion. One should use metaphor only with the aim of hearing, "Ah! now I see what you mean!", never with the aim of hearing, "Oh! you must be right!" Then the "dangers" go away. -- AndrewMcGuinness

The problem is that anything complex must become its own metaphor because any other metaphor will eventually not have enough explanatory power. Other metaphors may help in the beginning. In the end you have to deal with the system as it has become, and not through a metaphor.

This prompts me to insert this, although it does not quite fit here. I would appreciate anybody indicating where it does belong.

Design is a natural process. We are all quite capable of building the ConceptualModel in our heads. And given a communication language which is appropriate we are capable of transferring that ConceptualModel to the next person.

We do not have that language.

What we need is a set of SystemMetaphor instances which constitute the basic building blocks of a system. These could constitute an intermediate language, capable of being implemented at least as an ActiveModel?.

The design task is capturing and refining the ConceptualModel in an appropriate time frame. This requires good communication. In a randomly chosen set of humans, each of the people with the concept in the head would use a different semantic base to explain it. So, unless the listener is very experienced, there can be a blurring of the meaning at the point of transfer.

What I believe we need is a clear semantic base. A base which is not in the domain of computing, but a base which is in the domain of spoken language. How you go about finding that semantic base is a challenge. I would place it in a category as important to humanity as algebra.

Because computing is pervasive, this semantic base could be quite sophisticated. It is likely that it would be taught in schools, possibly at the same level as early algebra.

It could go something like this -

The base elements of the semantic base are the two things which we intuit quite well: processes and data.

A semantic base for processes is -

Result = Process(Data)

That covers talking about all processes. Reverse Polish notwithstanding, I do not know of any process which cannot be conceived in this form, in any language.

One thing it establishes is a concept of flow: stuff goes in on the RHS and comes out on the LHS. Like algebra.

And given that premise that there is a useful semantic model in which all data can be described sufficiently to specify enough intention to allow the use of intelligent defaults to provide useful, usable immediate functionality, there is a finite set of semantically clear processes, which, if considered in the light of that model, provide all the functionality which is provided in the current generation of databases. And more.

Data is a set of instances which can be conceived as the combination of the Entity in which it exists, the Attributes required, and the identifier of the instance.

Given this view of data, a set of processes can be conceived to allow communication about the access of data.

Select, Get, Alter, Save, Delete Data

So a specification for access of data my contain prose of the form -

Get the current customer's name.

which could been represented in process as

Customer Name = Get Data('Customers', 'Name', Customer No)

I am suggesting that if the specification language is sufficiently close to the code language, the code can be derived from the specification. So you can run the specification.

It may be useful to have a Metaphor that can explain what Metaphor is

In the course on XP I took, metaphors seemed to be the most unconceivable concept. Even here, agreement is only reached on the first two lines of this page, the rest being a presentation of very different ideas on what a system metaphor actually is.

I believe one main problem is, that we are lacking a common, shared metaphor for metaphors.

An important point may be, that metaphors cannot possibly be constant throughout a project. They will change very quickly (minutes) in the beginning, but may also stay basically unchanged for several iterations. There will never be one metaphor, because a metaphor is a shared story, every team member will have his own version, lacking some details. So the metaphors will evolve, and eventually become an unmetaphoric entity (an 'icon', i.e., on a windows desktop, was a metaphor once; now everyone has a sure grasp of the concept behind it, and one can name the actual object 'icon').

A big problem might be the usage of metaphors as system architecture. It might work very well for initial development. But I believe that it can be very difficult to continue someone else's project, because the complex, evolved metaphors will be a very hard thing to pass on. -- RonaldToegl

I think in simple cases the so-called "system metaphor" could well be exactly the sort of system that is being modeled. For instance, right now I'm experimenting with developing a program that plays poker. In poker, you have a dealer, a table, players, chips, a deck of cards, and so on. You can model all these things, though not every single little thing needs to be modeled in exact detail of course. I might not want to code a Dealer class, deciding to include the card-handling routines in Table because I might consider the table and the dealer to work together as a unit. I may or may not want to do the same with Deck itself; I'd be more inclined to keep those separate, with a Table holding a Deck. But it's clear that whatever I end up going with, it should be based on the way poker is actually set up and played. TheModelIsTheMetaphor? (and TheMetaphorIsTheModel?). -- Kef X-Schecter (FurryKef)

That would be the NativeMetaphor

There is quite a lot of research among linguists, sociologists, and others in the area of metaphor. At one point in my (prior) academic career I spend quite a few months digging into this. The main principle of metaphor is that it helps you to bridge across two areas: from one with which you are familiar to one with which you are less familiar. This can help you explore a new area by anchoring it to concepts which you already understand. This is useful, of course, as a teaching aid: a good teacher can lead his or her students to think through an unfamiliar area by framing it in terms of a relevant metaphor.

Importantly, the "teaching function" of a metaphor extends beyond mere knowledge transfer to ongoing knowledge discovery. That is, every metaphor is rich with implications that we can continually explore to guide our immersion in an area of unfamiliarity. For example, if we say that a (future) document management system will be like a library then we can start to discover the scope and details of the document management system in considerable detail by following the implications of what it means to be a library.

This helps with early brainstorming, group communication, and ongoing exploration as the project unfolds. An important consequence of this is that the metaphor helps maintain conceptual cohesion - providing an overall filter on the things that go into the design. Thus, our document management system would be constrained by the limits of the library metaphor. Assuming the metaphor is a good one, this limiting will stop us straying off the cohesive conceptual path. Of course, a poor metaphor will lead to poor guidance.

In my experience, the simpler the metaphor the less likely we are to be tripped up by it. Experience has also taught me that although it is helpful for all the team to share the same original understanding of the underlying metaphor, this is highly unlikely, but is rarely problematic since what is normally required up-front is only sufficient overlap to enable mutual exploration. For example: "No, I don't mean the library will only have one copy of each book; this is a library with infinite copies of every book ...". -- AnthonyLauder

What's so Extreme about Extreme Programming? See TurnAllTheKnobsToSeven. --Cezar Steinz

CategoryMetaphor