Modeling vs. The Model

Whiteboard Session

It’s interesting to me how much people rely on formal tools for modeling. I frequently talk to individuals that tend to assert that just because a model is made in some modeling tool (like Visio) that it is *right* or at least superior to whiteboard sketches.

The Visio fan-boys and fan-girls seem to snicker and generally doubt the effectiveness of a sketch done at a whiteboard. Why is this?

Is it because of the appearance? Is it the lack of gradients? Is it the lack of the drop shadows? Is it the lack of the standard company logo in the upper right-hand corner? Is it because of how straight the lines are?

My view is exactly the opposite. If I had to summarize my stance, I’d say that the straightness of the lines has an inverse effect on the understanding of the problem.

In my experience, most of the models created with modeling-tools are done by one individual. If others collaborate on the model, it’s usually in a serialized fashion. It’s “tossed over the wall” to someone else who follows a similar process. It’s also my experience that many people spend more time worrying about the polish of how the output looks than spending time thinking about what is being modeled.

Contrast this to a whiteboard-session:

When a model is explored on a whiteboard it’s usually done with more than one person. It’s usually done collaboratively with at least two participants, a variety of view-points, and it’s iterated on quickly. Because it’s being done collaboratively, it also frequently results in break-through ideas or understanding.

Unfortunately, the modeling tools also tend to focus our attention on the output, not the creation of the model (where the real learning occurs).

It’s important to remember that the modeling, learning, and understanding is what provides the real value, not the model.

Photo courtesy of Doc Searls.

This entry was posted in agile, architecture, design, learning. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

3 Comments

  1. Posted April 29, 2009 at 6:38 am | Permalink

    Great post.

    But Ben, I would argue that no matter what format you use, everything starts off as a blank canvas, a “whiteboard”.

    “Whiteboards” in a room exist in physical space. Therefore, augmenting a “whiteboard” with a digital tool is really ideal. We are running projectors, video conference tools, and exploring using computer vision through a simple web cam wired with Processing or OpenFrameworks apps. Point is, it is digital technology ambivalent and can be extended very easily if needed.

    Why “sketching” is effective in a collaborative setting is:
    1. There is only so much you represent with a fat tipped marker on a smooth surface
    2. It is accessible by anyone, instantly, and requires people to rely on simple semiotics to express themselves. It forces simplicity.
    3. On a macro level, it is easy to erase.
    4. It is inherently low-fidelity so when you are designing high level models, it forces you to look at high level assumptions.
    5. Easily transferred to a schema or digital tool since it is almost always based on words (#2)

    Why “sketching” is not-effective:
    1. Limited by spacial constraints
    2. No digital meta schema
    3. Can not handle inherent complexity of systems design
    4. It cannot be parsed
    5. Once a modeling format becomes evident in the sketching, you are stuck with it.
    6. It cannot handle the formal gestalts of information design when done with marker alone.

    We did a session yesterday that involved a entire wall coated with a whiteboard surface. So it was huge, space wasnt an issue. We had several people modeling there understanding of a system on their own. Both of us were doing it differently, because we think differently. This is really why Larry Constantine is focused on driving the UML committee to extend the model into information design. It gives anyone the means to slap their own taxonomy onto s system. BUt back to the point here, one person was using markers and drawing lots of grids and 4 quadrant graphs, I was using multi-colored sticky notes and building affinity diagrams.

    ALl well and good, I was happy to walk away from the meeting with a portable model of the system. The other person had to take a picture like you did. The problem with the latter is I have never seen anyone that wasnt in the meeting actually try and look at a whiteboard sketch captured as an image. I like stickies because i have a color, shape, and size nomenclature and it forces be to use semiotics in a very small space. It is also inherently adept and being parsed into a digital system, with UML, right after a meeting. That allows anyone to take the source material and do whatever they want with it.

    When it comes to systems modeling, this is why formal USer Environment Design Diagrams are so useful. They are simple and can be expressed on a piece of paper, a whiteboard, or parsed into a formal meta schema through Visio.

    I think I made some sort of point? The challenge is understanding the advantages and disadvantages of collaboration mediums, and focusing on the schema and use for distribution and aggregation into more complex representations. That first transposition of the whiteboard into something digital. That very first digital representation has to be useful to any kind of future collaborator, and instantly editable and extended in a way that is pushed through the system.

    So, as a consultant, it is critical to focus on that inbetween step. When an analyst takes it into Visio, there is a “living organism” that precedes it that is the DNA of that system. I am exploring URI’s as the easiest way to handle this. It can be transformed into UML and XML and then consumed by any tool for any purpose and visualized in any manner.

  2. Posted April 29, 2009 at 3:40 pm | Permalink

    I guess it comes down to the difference between using the models for collaboration vs. using the models for communication.

    I totally agree that the formal models tend to lend themselves very well to communication and in many cases, I think those models can be generated. If the model is used to communicate the architecture, that model can certainly be generated from the current codebase. The big advantage there is that it never gets out of date and is always “telling the truth” about the underlying application.

  3. Scott Bower
    Posted April 30, 2009 at 11:17 am | Permalink

    I am sittiing here in a Agile process overview meeting looking at swim lanes of cards and it dawned on me… It solves the physical vs digital issue. I think i just discovered the killer use for that cheap consumer RFID system :) :) :)

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>