The Five Stages of Asking an Architect a Question
1. The question
“Should we use microservices?”
2. The answer
“It depends.”
3. The challenge
“Depends on what?”
4. Thirty-seven whiteboard diagrams later
“So, the answer is still ‘it depends’?”
5. Acceptance
“Yes.”
“I hate that you’re right.”
“Welcome to architecture.”
J.R.R. Tolkien wrote:
“Go not to the Elves for counsel, for they will say both no and yes.”
He was not describing software architects.
But he could have been.
Ask an architect whether you should use microservices, move to Kubernetes, rewrite the application, adopt a new framework, or put AI in the middle of everything, and you are likely to receive the two words everyone loves to hate:
It depends.
This is often interpreted as indecision, evasion, or an attempt to sound clever.
Sometimes, admittedly, it is.
But experienced architects usually say “it depends” because the question does not yet contain enough information for an honest answer.
“Should we use microservices?” sounds like a question about architecture. It is actually a bundle of questions about the organization surrounding the architecture.
How large is the team? How independently can the teams work? How often do you deploy? How mature are your operations? What kinds of failure can the business tolerate? Who receives the alert at two in the morning? What happens if usage increases tenfold? What happens if it never does?
The correct answer may be yes.
The correct answer may be no.
More dangerously, the correct answer may be yes under one set of conditions and absolutely not under another.
That is why architects sound suspiciously like Tolkien’s elves. They can see several possible futures, and they know that every path carries consequences.
A microservice is not merely a smaller application. It is another deployment, another network boundary, another source of latency, another thing to observe, another thing to secure, another failure mode, and another potential 2:00 a.m. conversation.
Kubernetes is not merely a way to run containers. It is an operational commitment.
A rewrite is not merely a chance to clean up old code. It is a decision to reproduce years of accumulated behavior, including behavior nobody remembers specifying.
Every solution is a commitment.
The architect’s job is not simply to identify what can be built. It is to understand what the organization will be required to operate, maintain, explain, fund, and survive after it has been built.
This is also why good architects can appear reluctant to give direct advice. Tolkien observed elsewhere that advice is a dangerous gift, even when it passes from the wise to the wise, because every course may go wrong.
That may be one of the best descriptions of architecture ever written.
Architecture is rarely about discovering the universally correct answer. It is about understanding the context, constraints, trade-offs, and consequences well enough to choose the least-wrong answer for this system, these people, and this moment.
Of course, “it depends” should not be the end of the conversation.
An architect who says only “it depends” has not answered the question. They have merely announced that the answer requires context.
The useful response is:
“It depends. Here is what it depends on.”
Then the architect should identify the important variables, explain the trade-offs, make the assumptions visible, and eventually offer a recommendation.
“Yes, because…”
“No, unless…”
“Not yet…”
“Try this first…”
A good architect does not avoid the decision.
They delay the decision just long enough to understand what is actually being decided.
So the next time you ask an architect a simple question and receive “it depends,” do not immediately assume they are dodging responsibility.
They may be trying very hard not to give you an elegant, confident, and catastrophically context-free answer.
Or they may simply be preparing the first of thirty-seven whiteboard diagrams.
No responses yet