Software Architecture Patterns

While clearing up my office book shelf I stumbled upon a book I got during my ISAQB training. It’s written in German and called “Vorgehensmuster für Software Architektur” which translates to something like “Software Architecture Patterns”. It’s written by Stefan Toth, a well known software architect and consultant here in Germany.

44395_c

After getting the book some years ago I read it and found it very useful. Somehow it landed on the book stack, being forgotten about until recently. After rediscovering it I took some time to read it again. I was surprised on how many ideas it planted into my daily worklife and how much of its patterns I actually used during the last years in my job as a software developer and architect.

I’ve read a lot of books, but I wanted to point out this book in particular. Here are some of the patterns I found most useful. They are all described in detail in the book, so go get it if possible for you:

  • Keep quality factors in mind: Software is always a trade-off between software qualities. Qualities like security and usability contradict each other, so you have to factor them in right from the beginning. Toth is taking this into account during every phase of the project, beginning with requirements analysis.

567px-iso_9126_quality_28en29-svg

  • Keep everyone involved: Context is King, a developer that does not know in which project context he’s working will probably not create what he should. Everyone knows the picture with the swing on the tree project. Toth describes how all project members should be involved during the project. He shows a lot of methods like project and architecture reviews that help building up knowledge about the context.

tree-swing-project-management-large

  • Last Responsible Moment: The concept of LRM and how to handle it is one of the key concepts in project management. After a bit of practice it comes naturally, and a good architect knows how to handle it. That’s not to say that a good in-depth analysis of this concept and how to tackle it does not help.
  • Active Risk Management: Along with LRM comes risk management. What are the different types of risks and how to minimize them? The book categorizes risks and shows a handful of concepts about what can be done for each category.
  • Architecture Reviews: There’s nothing better than to crowd-solve a problem. It’s extremely rewarding to finding the best solution together. Even better, you get a lot of knowhow-transfer and free training on top of it. This is especially true for architecture – in the past I found that basic architecture and software design are among the most critical parts of a project. If you have the possibility to get everyone on board during this part of the project you will probably not have to deal with miscommunication and out-of-context development later on.
  • Use feedback and retrospectives: A good software development process consists of as much feedback opportunities as possible. You should always reflect on your past decisions and ideas, often you find better ideas that are still possible to be implemented. This goes for architecture, but also for process and the whole social stuff.
  • Show your progress early: This is also related to the whole feedback topic – Show what you got and see what the customer and other stakeholders think about it. Be as transparent as possible in your development process, you’ll get feedback that otherwise would never reach you and cost you a lot of trouble later on.
  • Root Cause Analysis: I see this way too often – A problem occurs and a developer fixes it right away, not thinking about the real root cause of the problem. Oftentimes only the currently visible symptom gets fixed, but the real reason for trouble stays in the system. With proper methods like the 5 Whys it is possible to get to the real issue and fix it once and for all.

I also found a few things that I always wanted to do, but never had the opportunity. The biggest of them are Architecture Katas. I think Katas can improve architectural thinking and collaboration in the dev team a lot. The book names the coding dojo of the clean code school. A short google also turned up this English site.

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s