“Architecture is a cornerstone for good testability!” - Richard Seidl
First of all: I am not an expert in software architecture. There are others for that. I’m more of an architecture worshipper, always happy to hear about new patterns, frameworks and strategies that help us move forward. For me, architecture is also a cornerstone of good software quality. It not only helps developers to write clean software. It also helps us testers and quality people with a very, very important point: testability.
I have heard statements like this so often in projects:
- “No, we can’t write unit tests, the architecture doesn’t allow it”
- “Uh… performance problems. Yes, we know that, but changing the architecture… you know, it has grown historically”
- “Well, you can’t get to the interfaces that easily. And they’re not really official either”
And so on and so forth. These are all signs that no one cares about a sensible software architecture or that they simply started coding. This is also legitimate at the start of a software project, but it must then soon be clear which structures, interfaces and patterns are used. And a view of the architecture must emerge.
I’m always amazed at how teams of 10, 20, 30 developers and testers work on software and constantly have to deal with these technical debts. Actually, it’s not really technical debt, but organizational debt. But let’s leave that aside. An incredible amount of money is being burnt dealing with these shortcomings instead of starting to heal them.
In addition to projects that work entirely without a well-considered architecture, there are others that I believe are based on a fundamental misunderstanding. Namely, that a software architecture is defined at the beginning and then applies forever.
That doesn’t fit into my world at all. An architecture is certainly not something that I turn over and redo every few days. But I would like to see further development and fluidity. And by that I don’t just mean updating to the latest version of the framework, but looking at the architecture with questions such as: What does our software architecture need to look like
- so that today’s and tomorrow’s requirements can be implemented easily?
- so that it supports the development process?
- so that it is a good fit for rising topics?
I find the last point very interesting. Because new innovations, such as MCP servers in the field of AI, arise from projects and teams that have implemented current architectures. And if you also use current architecture paradigms, implementing these features is much easier than if your own implementation is the state of the art from 10 years ago.
In my opinion, software architecture is far too underrated. A shame, really, given the importance it deserves.
So go and find the architect in your team and have a coffee together 🙂