Your system architecture could make or break your new initiative
The decisions you make at the start of a software initiative are some of the hardest to undo later. Here are two architecture mistakes we frequently see – and what actually works instead.
Mistake #1: Big Design Up Front (BDUF)
A BDUF is an attempt to see far into the future and anticipate every obstacle an initiative will encounter. Like any venture that relies on foreseeing the future, it is bound to miss the mark.
A common culprit is the second system effect (Brooks, 1975): the tendency to overcompensate for a previous system's weaknesses by overarchitecting the next one. This often means designing around popular technologies and patterns – not because they solve actual problems, but because of their popularity.
There is merit in trying out new things, but it should stay confined to experimentation until you've gained enough understanding to justify bringing it into the main system.
Mistake #2: Never revisiting the architecture
The opposite: settling on a minimal design early on and never revisiting it, even when the system outgrows it and ends up constrained instead.
This tends to produce one of two outcomes: a monolithic application whose codebase is complex to work with and slow to build and test, or a mess of microservices that all talk to each other without clear boundaries of responsibility.
What actually works
Like with Goldilocks, the right amount lies somewhere in the middle: an initial design that supports the first stages, but stays flexible enough to adapt as needs change.
How we can help
Avoiding both of these mistakes is exactly what our Architecture kick-start is for: we combine our architecture experience with your business knowledge to get the foundations right from day one, without over-engineering for problems you don't have yet.
