Agile Architecture Principle #2 – Build the simplest architecture that can possibly work

Posted on April 6, 2008 by Dean Leffingwell in Agile Architecture

Note: this is one in a series of posts under the category of “agile architecture”.

In an earlier post, (Six Principles of Agile Architecture) we identified six principles that can help us reason about the challenge of architecting systems of scale in an agile enterprise. This post discusses Principle #2 – Build the simplest architecture that can possibly work.

This one will certainly come as no surprise to even an agilist newbie, after all, agile is famous for its focus on simplicity:

What is the simplest thing that can possibly work?” – Ward Cunningham

If simplicity is good, we’ll leave the system with the simplest design that supports its current functionality.” – Kent Beck

YAGNI – You Ain’t Gonna Need It – an XP mantra

Of course, we are talking about systems of substantial complexity here, the types of systems that are crafted by hundreds of developers working over many years, rather than the types of systems developed in smaller team environments where agile practices were developed and proven, so it is a fair question to ask as to whether simplicity remains an essential attribute as the complexity increases.

Of course, it’s obvious from the postulate that I believe this to be the case, and this is supported by my own anecdotal evidence in building large scale systems. In most every case I remember (two “simpler” decisions I remember vividly: 1) dedicate a single service to a single class of server, 2) pick an off-the-shelf data base for those elements of the system that did not require extreme scalability), the simplest decisions turned out to be the best over time. And you needn’t take my word for it. Take, for example, where they grew a system in an agile and organic manner to eventually handle 55 million customer accounts and where between 100-150 services are accessed to build a page. In a recent post on the website, ( Todd Hoff notes a primary lesson learned as described by Amazon’s CTO, Werner Vogels:

“Only way to manage as large distributed system is to keep things as simple as possible. Keep things simple by making sure there are no hidden requirements and hidden dependencies in the design. Cut technology to the minimum you need to solve the problem you have. It doesn’t help the company to create artificial and unneeded layers of complexity.”

If simplicity of architecture is good enough for, it’s good enough for me.