Thinking Like an Architect
Treating Architecture as a Series of Experiments
In my last two articles, I tried to do two things.
First, I wanted to define software architecture without turning it into a religious war between patterns, tools, and buzzwords. Architecture is slippery—hard to pin down—because it’s not just structure, and not just decisions. It’s the shared understanding around the important stuff.
Second, I wanted to acknowledge the part nobody puts in the job description: the people dynamics. The politics. The fact that “the right decision” is rarely accepted on technical merit alone.
So what’s the next step?
If architecture is about the important stuff, and if the important stuff is negotiated in a messy human organization, then the architect’s real craft becomes this:
forming a mental model of the system and its environment
making bets under uncertainty
learning fast
In other words: thinking like an architect.
And the mental shift that unlocked this for me is surprisingly simple.
Treat architecture as a series of experiments.
The architect’s job is not to be right. It’s to reduce uncertainty.
Most people assume architecture is about choosing:
microservices vs. monolith
async vs. sync
build vs. buy
event-driven vs. request/response
But in real life, the hardest part isn’t choosing. The hardest part is admitting you don’t actually know.
You don’t know:
whether this new capability will be used as expected
whether performance issues will appear under real traffic
whether an integration will behave nicely in edge cases
whether a team can realistically maintain a certain level of complexity
whether a “standard” will still be relevant in 12 months
Architecture is full of unknowns.
So if you treat architecture as a one-time decision (“we decided microservices”), you’re setting yourself up for failure. Because reality will eventually disagree with you.
A better framing is:
We have hypotheses.
We run experiments.
We learn.
We update the architecture.
This doesn’t make architecture weak. It makes it alive.
Technical breadth hurts because it forces you to let go of certainty
One of the most uncomfortable moments in career growth is when you realize that being an architect is not “senior developer with more opinions.”
It’s a different kind of competence.
As a developer, depth is rewarded:
mastering a framework
knowing how to debug weird runtime issues
writing clean, expressive code
As an architect, breadth becomes more valuable:
knowing that five options exist
understanding trade-offs across patterns
spotting failure modes early
anticipating operational pain
But here’s the catch.
Breadth doesn’t feel like mastery.
Breadth feels like constantly being a beginner.
And that’s exactly why experiments matter.
If you cannot afford to be wrong, you will cling to your current expertise. You will defend familiar solutions. You will overfit decisions to what you already know.
Experiments are a permission slip to explore.
They turn “I don’t know” from a weakness into a plan.
Architecture decisions are “expensive opinions”
Some decisions are cheap.
Choosing a small library? If it turns out wrong, replace it.
Some decisions are expensive.
Choosing an architectural pattern, a deployment strategy, a platform, an integration approach—these decisions become organizational commitments. They shape:
team structure
delivery speed
operations
budgets
hiring
compliance
That’s why architecture decisions get challenged.
And that’s why the architect needs more than confidence. They need evidence.
Experiments create evidence.
Not perfect evidence. Not academic certainty.
But enough signal to move forward responsibly.
What “experiment” means in architecture (it’s not just a prototype)
When I say “experiment,” I don’t mean building a throwaway demo and calling it innovation.
An architectural experiment is any deliberate action that reduces uncertainty.
It can be:
A spike
a small time-boxed coding effort to validate feasibility
e.g., “Can this service authenticate with our existing identity provider without turning into a hack?”
A thin slice
an end-to-end path through the system
not to deliver all features, but to expose the real constraints early
A load test
not to produce pretty graphs
but to learn where the architecture breaks under realistic conditions
An operational drill
can we deploy, rollback, and recover without heroics?
does observability actually tell us what we think it tells us?
A governance check
do teams understand the architectural principles?
can they follow them without slowing down to a crawl?
Notice something:
Many of these experiments are not about code.
They are about the full system in its environment.
That includes people.
The hidden experiment: can the organization execute this architecture?
There’s a detail I keep coming back to.
A “good architecture” that a team cannot maintain is not good.
It’s just expensive.
So one of the most important architectural experiments is organizational:
Can we actually enforce this boundary?
Can we realistically keep these services versioned?
Can we operate this many moving parts?
Can we ship changes without creating deployment fear?
Sometimes the experiment outcome is brutal:
The pattern is fine, but the organization is not ready.
The solution is correct, but the timing is wrong.
The design is elegant, but the operational burden is unacceptable.
That’s not failure.
That’s learning.
A simple template for architectural experiments
When I want to force myself into “architect thinking,” I write experiments down using a very plain structure.
Hypothesis
What do we believe is true?
Example: “Async messaging between services will reduce coupling and improve reliability.”
Risk
What happens if we’re wrong?
Example: “We’ll introduce operational complexity and debugging pain without real benefits.”
Minimal experiment
What is the smallest action that can test the hypothesis?
Example: “Implement one integration with messaging, plus tracing + dead-letter handling, and run it through real failure scenarios.”
Success criteria
What observable signal would convince us?
Example: “Failure recovery is predictable, and the team can debug issues within X minutes using logs and traces.”
Decision rule
What do we do based on the results?
Example: “If debugging is consistently painful, keep async only for specific use cases and prefer sync calls elsewhere.”
This structure sounds simple because it is.
The value is not in the template.
The value is that it forces you to stop arguing opinions and start designing learning.
Experimentation is also how you keep architecture alive
There is one phrase I learned from elite architects, and that hit me: architecture vitality.
The idea is uncomfortable:
An architecture that was perfect three years ago can be wrong today.
Business grows. Teams change. Technology shifts. Constraints move.
So the architect needs a habit:
Constantly analyze the environment and recommend improvements.
But that’s only possible if you treat architecture as something that evolves.
An experiment-driven mindset makes evolution normal.
Instead of:
“We must protect the architecture.”
You think:
“We must protect the organization’s ability to learn and adapt.”
The quiet discipline behind “thinking like an architect”
Thinking like an architect is not a single genius insight.
It’s a discipline.
admitting uncertainty early
making risks explicit
running small experiments instead of big rewrites
measuring what matters (including operational pain)
keeping decisions reversible when possible
and when they’re not reversible, earning them with evidence
That’s how you move from “having opinions” to “building shared understanding.”
And that’s where architecture stops being a title—and becomes a practice.
Part of a series based on the O’Reilly Software Architecture Fundamentals course by Mark Richards and Neil Ford. Not sponsored or affiliated — just a resource I genuinely find useful. If you want to go deeper, O’Reilly Learning offers a 10-day free trial with access to courses, books, and hands-on labs.