Bubbles and Arrows Architects

We’ve all seen it: An architect explaining something with a sketch containing bubbles and arrows on a whiteboard. Sometimes the architecture is perfectly realized in the project, sometimes not. Looking at the sketches there are few differences. Why are only some possible to realize?

Let’s look at a typical system sketch drawn by an architect. (My skills at drawing in paint are even worse than my whiteboard sketches, but I hope you get the idea) The project using the design by this architect will be a complete failure. All attempts to build a system according to the architecture will fail miserably when the implementations of the components get incredibly expensive, while the result is a performance nightmare impossible to use for real work.

We’ll get back to where it went wrong shortly. But first, let’s look at a sketch that works.

Another architect draws this image. The project delivers high quality software on (or maybe even ahead of) schedule.

You can stop comparing. There is no difference. Actually, it’s the same image displayed twice.

So what’s the difference? The sketches are the same, but the outcome of the projects are completely different.

Bubbles and Arrows Architects

The difference is not in the drawings. The difference is between the architects. There are 10 different types of architects. Those that know binary counting and those that don’t.

Those that know binary counting often have a strong background in coding and know what works and what doesn’t. Those architects will rely on their very own personal experience from implementation and set a pride in being sure that every single piece of the architecture is realizable. They might not be the best coders any more, but they know the craft. They could possibly write most of the system themselves and for those parts they don’t master themselves they listen to developers who do.

Those that doesn’t know binary has a weaker background. In my experience, they are often people that never had a strong passion for programming. Instead, they tried to skip the hard work of learning to create working solutions themselves and went straight for the architecture. The problem is that their whiteboard drawings will only be just drawings. Eventually they will drift off to so high abstraction levels that they become architecture astronauts.

Real architects making the drawing above think of how to implement every single of those boxes when drawing them. For each box they draw, they have an idea of what framework and tools to use and they know that all the components will work together.

A bubble and arrows architect will draw the same boxes and lines, but will typically dismiss any questions on how to implement it.

It’s an implementation detail, for the developers to handle.

If you hear that in a project, don’t walk away. Run.

The Other Eight Types

That’s two types of architects. If you’re looking for a list of eight more types I must make you disappointed. It was a joke. A very geeky, mathematical joke, that most people with strong coding experience understands.


  1. Joke or not: I am sure there are many more than eight other failing architect types. Here are a few:

    1) The promoted programmer who has the skill to produce a solid architecture but is unable to communicate it to the developers.

    2) The weak leader who does not dare to follow up and make sure the developers follow the architectural structure.

    3) The control freak who does not dare to let other people’s ideas into the picture.

    4) The old timer who has worked with a product for too long and gets stuck with its history instead of focusing on the future.

  2. Have you seen any of these: the complainer – spends all his time complaining about the terrible code, the terrible architecture, the terrible equipment, the terrible processes, his shoes are too big or whatever will make them feel smarter than the rest. They spend so much time complaining, they accomplish very little but the manager counts on their negative bias for everything. The other people on the team just want him to stop complaining all the time and start contributing anything positive for a change. Provide positive feedback when evaluating code or a design, use that wisdom to come up with ideas for solving the problem at hand or improving the quality of the teams work life.

  3. yep – guys who don’t understand the 10-joke don’t deserve to participate in real world projects.

    Together with Peter Hruschka, we compiled a series of essays on the (good and bad) behavior of software architects – currently available only in German.

    maybe some of the readers can understand it:

    (it has been published as a book and been quite succesful since its publication in 2012).

    1. It’s a pity that I don’t read German, would have loved to read that series. Have you considered translating them into English?

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.