The Lifehacker's Guide to Software Architecture, Part 1

Greetings from the desert!

I'm starting a small series of short articles with lifehacks for software architects. Those are surprisingly commonsensible, but more often than not, it still seems to make a lot of sense to redirect the focus back to common sense. I think there's a lot of sense in this, so let this sense in!

Today, as a foundation, I'm sharing an advice that is universal, context-free, and always true:

What is a faith healer in this context? Well, it can be people, tools, or methodologies that claim to just solve everything, and of course it's going to be super easy and super simple.

• People: Listen to me, and I remove all of your problems.
• Tools: Use me, and I release you from your pain.
• Methodologies: Apply me, and I make you happy again.
• All together now: Can I put my hands on you?

Unfortunately, all of this is not true. There is no tool or technology that's the best option for every scenario and use case. And there is no methodology or architectural style that works in every context and team. On top of that, it occurs that leaders want to tick off an item, and therefore try to establish something that is not well understood and applied in a wrong way.

The unpleasant truth is: There is no silver bullet in software architecture. Nor is there in any other sphere of life. And simple, universal answers don't resolve complex problems most of the time.

Even more: No architecture decision comes without a trade-off. In fact, every architecture decision gives you some pain. However, your job as software architect is to identify the least painful option on the table. And then to convey your conclusion with empathy.

The above also implies: The best architecture decision for scenario A doesn't have to be a good decision for scenario B. For every new scenario, you need to discuss the viable options based on the specific requirements again. Being a software architect requires to deal with a lot of ambiguity.

Now, there are certainly a few common examples of tools or methodologies that are blindly thrown at teams as silver bullets, without discussing the respective trade-offs. I deliberately did not want to mention concrete examples as scapegoats here, because most of them actually have value when used in the right context and for the right use cases. Again, the point is that a software architect needs to be a good helmsman to navigate through the seas of options.

As promised, a short article. However, with all the above, it's obvious that you need to be careful with everything I state in the next posts of this series. But for now, while I'll be working on part two, you can have some fun and listen to this nice piece of disco punk from 1985. Have a great day!