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

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.


One thought on “Agile Architecture Principle #2 – Build the simplest architecture that can possibly work

  1. I agree (surprise ). The big challenge we are running into is that very often, things that are even simple in nature require a lot of time to address let alone re-factor. This is magnified as a result of the dependency chain.

    For example, if 10 teams commit to work in a release planning session and then during the 1st iteration, the “infrastructure” team realizes we have to address an aspect of our intentional architecture, we can’t force the other teams to take the changes without impacting their release commitments. Unless we can convince all SMs and POs that it warrants such an impact, we are forced to wait till the subsequence release. This will become less of an issue as we become more experienced but I bet every new agile at scale effort experiences this almost immediately.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s