Good Software Architecture is like …

… a LEGO figure

Good software architecture allows software to change easily. LEGOs help to explain how a modular design achieves this by isolating and grouping associated functionality.

Martin Fowler, a Superhero in the Software Development world, said in his definition of software architecture: “Software architecture is about the decisions that are hard to change later.“

This statement doesn’t mean that we need to find an oracle to foresee the future. It simply asks: “What are the costs to extend or change our software?”.

An essential strategy to make change easy is to modularize the software design. Through isolation of associated functionality, we end up with a design that is easy to change and extend.

LEGO has a modular design

Take a look at this LEGO figure.

She represents a modular software system that delivers pizza.

If we wanted her to look more professional, we could change her “pants module”.

In an actual software system, this could be the API or User Interface that could easily be changed.

To extend her capabilities, we could give her a jetpack to deliver the pizza faster.

In an actual software system, this could be a caching layer between two parts of the system.

To increase her security, we could give her a helmet.

In an actual software system, this could be an authentication and authorization layer.

If LEGO did not create a modular system, it would be harder or even impossible to make these changes.

The same is true for a software system.

Good software architecture is modular as well

Modularization is not limited to a particular scope. It can be helpful on any layer. Just imagine the system you could build with more than just one LEGO-figure-module. 

But, as always, there is a catch. Don’t just blindly modularize everything. Ask yourself, is a modular software architecture design helping to achieve the goal of easy and cost-effective changeability?

Modularization might be an unnecessary overhead if you don’t expect changes in (parts of) your software.

But, the higher the expected change-frequency of (a part) of your system is, the cheaper changes will become with a modular design. A modular design also gives you more flexibility to try things out and encapsulates experimental code in a module where it can’t harm the rest of your codebase.

Especially Startups benefit from a modular design because they need to learn and experiment a lot. Once a module works, it can be considered stable, and the focus can shift to more important parts.

If changing your software feels like playing with LEGOs, you are most likely on a good path to success because modularization mostly doesn’t mean a lot of overhead. If not, let me know, I will help you figure this out (pun intended 😉).