The Most Dangerous Decisions an Architect Makes
An architect makes the most important technical decisions in a company.
When designing a system architecture from scratch, there are usually 50+ architectural decisions. Out of those, 3–5 matter far more than the rest.
Today we’re talking about those. Let’s call them Big Bang Decisions.
Big Bang Decisions shape the entire architecture. If you get one of them wrong, you will absolutely wreck the whole system.
In other words, they’re high-risk.
So how do we reduce that risk?
When forming a Big Bang Decision, we make hypotheses.
Architects usually call them assumptions. They log them, finalize the architecture, and go relax in a jacuzzi with a mojito 🛁
Six months later, everything blows up. The architect points to the log and says, “Well, that was an assumption, not a fact. Not my fault.”
It’s a common approach. And a terrible one.
Can we improve it? Absolutely.
For every hypothesis, the architect should build a prototype by hand to validate it.
Both the hypotheses and the prototypes should be documented directly in the decision itself. That benefits the architect and gives developers a working baseline they can build on.
An invalidated hypothesis is also a win. You just saved the company serious time and money by not implementing the wrong solution.
In my experience, up to 30% of hypotheses turn out false even for experienced architects. For inexperienced ones, it can be as high as 80%.
Now imagine how much damage unchecked assumptions can cause 😈
What counts as a prototype?
Anything minimally functional:
Bash script.
CLI tool.
Plugin.
Or even a fully deployed system.
Should the architect really build it by hand?
Yes. Who else?
It’s a great way to get grounded and feel how the architecture actually behaves in real life.
But isn’t that slow?
We have public clouds. Serverless. And now AI that writes code.
You can build a solid prototype in 4–8 hours.
I’m serious. I was doing this even before AI. I’ve deployed ultra-complex Hadoop clusters with outdated dependencies and dug into the guts of a Chromebook when needed.
Let’s look at a real example ✨
Recently I was designing architecture for a nonprofit.
The Big Bang Decision there was: where will staff and volunteers run their core business processes?
Hypotheses:
– AmoCRM is suitable as the foundation for their operational workflows
– AmoCRM can be extended to support nonprofit-specific needs
The prototypes confirmed both:
– AmoCRM was deployed and configured around their key processes
– A custom widget with an analytics dashboard for the nonprofit owner was built
During prototyping, I also discovered that the widget approach from the AmoCRM landing page wouldn’t work well for this case. A different extension strategy was required. Without prototyping, the developers would have hit that wall much later.
Both prototypes took one day. One additional day to polish the widget for a demo.
The nonprofit owner couldn’t believe how smoothly everything worked. So I validated the architecture and won stakeholder confidence at the same time.
Now for the real question:
How do you reduce risk in your architectural decisions?