The Case for Minimalism in Software Architecture

"Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away." - Antoine de Saint-Exupery

I was first introduced to the idea of minimalist software architecture in an article by Ruth Malan and Dana Bredemeyer, "Less is More with Minimalist Architecture" (PDF).  The basic premise is devilishly simple: the software architect's job is to "only do with architecture what is absolutely necessary to achieve key, broadly scoped qualities of your system."  Any design decisions that do not support this goal are left to the discretion of downstream designers.

In my experience, minimalism defined in this way is a powerful tool because it helps me keep my attention squarely on system qualities.  I've found that focusing only on the most important quality attributes creates a clear delineation between "architectural" design and "detailed" design.  As a result, satisfying quality attributes becomes a signal for stopping architectural design activities and helps me avoid waste through over-analysis.

Even more importantly, minimalist designs provide critical guidance without removing autonomy from downstream designers.  Who are these downstream designers?  In my experience with small teams, it is myself and my teammates now playing the role of programmers.  In larger groups, entire other teams of people that I sometimes have never met will fill this role and take responsibility for developing and detailing coarse grained components.

The autonomy afforded by minimalism is critical for allowing team self-organization, which in turn allows for better lower-level designs.  Fred Brooks summarizes the reasoning for this phenomenon best in his essay "The Documentary Hypothesis" from The Mythical Man-Month.  Conway's Law predicts that a system's design is destined to reflect the communication structure of the team that built it; therefore a team's organization must change for the system's design to change. Minimalism reduces friction of change which in turn makes it easier to self-organize which in turn helps you make better designs.

While minimalist software architecture makes sense, should the documentation necessarily be minimalist as well?  The answer, of course, is that it depends.  But, in my experience, creating a minimalist software architecture description encourages me to also design a minimalist architecture for the system documented.  It seems that by forcing myself to use a minimalist packaging, my only choice is to focus on the most important aspects of the system's design.

Another keenly positive result of having tightly focused, minimalist documentation is that I am able to more quickly communicate essential design decisions to my team.  Important decisions and rationale are distilled to a pithy phrase or two that can be easily shared and remembered.  And change is easier too.  Modifying a design, in the case of an Architecture Haiku or System Metaphor, is as simple as scratching out a few words on paper or adding an annotation, or changing the stories you share.

Gone is the 30 page (or 50 or 100 page!) architecture description that my team ignores anyway.  Replacing it is a flyer advertising the key design decisions in the system we're building; a constant reminder of those decisions, their rationale, and the context around them.  As a result, minimalist software architecture descriptions serve as an effective catalyst for meaningful discussion and a practical guidebook for implementation.

Untitled (Blue Leaning Plank) by John McCracken at the Carnegie Museum of Art.
A great example of minimalism and one of my favorite sculptures at this museum.
My wife thinks I'm nuts for digging this piece soooo much. This picture barely does it justice.