Yuriy Zubarev

Screaming architecture and the (one and only) architecture diagram


It’s a wild wild west in the Software Architecture land! Uncle Bob and Simon Brown are not deferring to draw guns and fire bullets wrapped in carefully chosen words. The argument is centered around what is considered to be architecturally significant elements, and how long to defer “annoying details”: http://www.infoq.com/news/2011/11/Debate-The-Annoying-Detail. This is almost as raw and exciting as it gets in our land. We should probably get a 30 minute spot on Spike TV.

I want to go to the start of the argument – “Screaming Architecture” article: http://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html. I understand what Uncle Bob was trying to say, and I believe he had only best intentions in his mind, but I’m weary of the language of absolutes and concocted examples. Mostly important, the original article perpetuates the notion of “the one and only architecture diagram” which is rather harmful.

The gist of the argument could be extracted from the first couple of paragraphs:

Imagine that you are looking at the blueprints of a building. This document, prepared by an architect, tells you the plans for the building. What do these plans tell you?

… As you looked at those plans, thereā€™d be no question that you were looking at a house. The architecture would scream: house.

So what does the architecture of your application scream? When you look at the top level directory structure, and the source files in the highest level package; do they scream: health care system, or accounting system, or inventory management system? Or do they scream: rails, or spring/hibernate, or asp?

Ahh, the building blueprints! Those big, fancy and surprisingly easy to understand technical drawings that we see in spy and heist movies. Here is an entrance, here is a corridor, here is a switch to turn off the alarm, and finally here is a door and a safe! What we don’t see are real life blueprints of heating, ventilation, cooling, electrical, water supply and sanitation systems. To an untrained eye those blueprints will scream absolutely nothing. Are they unimportant annoying details? Sure, if you don’t mind spending a winter in Winnipeg with no heating, electricity, toilet, hot water and inadequate wind protection.

When you look at the top level directory structure, and the source files in the highest level package; do they scream: health care system, or accounting system, or inventory management system?

Judging architecture of a software system by top level directory structure is like judging building architecture by a construction site. Construction sites don’t scream library or school or a city hall. They scream: raw materials. Yes, of course, it would be nice if the top level directory would be called “amazon” and the sub-directories – “books”, “magazines”, “electronics”, etc. We would know right away what we’re dealing with. The difference between construction industry and software industry is that we invent and deal with levels of abstraction. For a non trivial software system those abstractions could be multiple levels removed from something holistic that would scream back at us. At the level of the source code the abstractions are the raw materials.

If your architecture is based on frameworks, then it cannot be based on your use cases.

Yes it can, if a framework is based on my use cases.

Enough of nitpicking. The bigger issue here is a pernicious trend similar to magnum opus. While alchemists were trying to discover a philosopher’s stone, we have a tendency to contrive The One And Only Architecture Diagram. As such, it should scream every answer to any question.

There are many questions to be asked about a software system. What is it for? Who is it for? What does it do? How does it do it (that’s a loaded one)? What does it consist of? How does it get deployed? How does it handle concurrency? How does it handle outages in dependent services? How does it map to the source code? Let’s stop trying to pretend we can answer all questions with one architecture diagram. Better yet, let’s stop avoiding those questions because we cannot address them with one diagram and let’s educate ourselves.


Comments :

blog comments powered by Disqus