Mastering Software Architecture

The good news: every software system has an architecture. The bad news: it is often undocumented (and perhaps sub-optimally structured).


Peter Hruschka

Sure we all are great programmers. But sit back for a moment and consider an honest answer: How many lines of code can you handle in source code form (without any other design artifact)? 1000 lines (this is approximately 20 pages of output), 5000 lines (about 100 printed pages)? What is the number for software you are currently working on? Or source code you created 2 years ago? Or source code from other people that you have to maintain? And now think about the size of the software system you and your team are responsible for. Is it larger — like 300 000 lines of code or 500 000 or more than a million? You will have to confess that this cannot be managed by looking at source code only.

In my bedroom I have 9 halogen lamps mounted in the ceiling. 2 * 4 of them are supported by one transformer each, one lamp has its own transformer — all of them hidden in the ceiling. Ten years ago when we constructed that lighting system the vendor promised: these transformers will work forever. Well, forever was ten years. One of them broke. No problem, since I had a perfect logical model (in my head) of the lighting system:

What I missed was the deployment model. Where in the ceiling did we put the transformers? Back then we did not document it. I was pretty sure about the location — so I drilled a small hole there. Yes, there it was — but not the broken one. Three small holes later and still no broken transformer we decided to take down a larger portion of the ceiling to locate it. It took a week to replace the transformer, close the hole in the ceiling, repaper, repaint and clean. This time we took photos of the cabling and the position of the transformers!

Now think software architectures. What information do you have about the structure, the relationships, the runtime behavior, and the deployment? During the last 10 years the idea of having multiple views of the software has been established. One model (of the static structure only) is not good enough. Although the names for the views still differ with various authors we seem to agree that we need at least an implementation view (the building blocks and their static relationships), a runtime view (the objects existing at runtime and their communication and synchronization) and for distributed systems a deployment view (to describe the mapping of software onto execution platforms).

But software architects should even document more: e.g. the driving forces that led to the creation of the specific architecture, the constraints that allowed no other solutions, the design decision that have been taken, and so on.

Since in most of our consulting projects we find many or all of these things missing or outdated (and too many developers tearing down "software ceilings" to locate transformers) the idea was born to create a template for software architects. Similar to the Volere template for requirements engineers we wanted to offer a simple but powerful tool to avoid reinventing the wheel in every project. Borrowing from Douglas Adams we called it ARC42. You know: the answer to life, the universe and everything ... this time for software architects. Most of the site is still in German. The introduction and the template are already available in English, too.

If you are a software architect check out our resource page

  — Peter Hruschka, Aachen, Germany