What Is a Software Architect?
DabbaGo has grown to 40 engineers and five teams, and it wants to launch in Mumbai in three months. Each team is making sensible choices on its own, yet the choices do not fit together: two teams are building their own login, and nobody has asked whether the order system can handle twice the lunch rush. The founders hire a software architect. What exactly have they hired?
The rule
An architect owns the hard-to-change decisions and makes them understood.
Take the rule apart:
- Owns. The architect is accountable for the system's expensive decisions. That does not mean making every one alone. Often a team proposes and the architect guides, questions and signs off. But when a big choice goes wrong, the architect is the one who should have caught it.
- Hard-to-change decisions. From the last lesson: structure, relationships, data, and the qualities that matter most. The architect does not decide variable names or screen layouts.
- Makes them understood. A decision that lives in one person's head is not finished. The architect explains it, writes it down, and makes sure teams can build within it without asking every time.
In practice the job sits between two worlds. On one side are business goals: launch in Mumbai, cut delivery costs, pass a security audit. On the other side are technical choices: services, databases, integrations. The architect translates in both directions. "Launch in Mumbai" becomes "the order system must handle 2.5 times today's peak". And "we must split the database" becomes "six weeks of work that lets Mumbai go live without risking Pune".
What an architect is not: a manager who approves timesheets, a senior developer who writes all the hard code, or a person who hands down diagrams and disappears. Good architects stay close to the code and the teams, because decisions made from a distance tend to be wrong.
The shortcut
Every time a request lands, carry three questions:
- Why? What business goal is behind this, and how will we know it worked?
- What if? What could go wrong: load, failure, security, cost, future change?
- Who? Who must understand, agree, or change their work because of this?
Why?
The goal is double the customers without hurting Pune. Success means Mumbai orders flow and Pune's lunch peak stays smooth.
The common trap is skipping straight to "what" (which database, which framework) before answering why. A technically beautiful answer to the wrong question is still wrong.
Drills
Answer fast — trust the rule.
Which task belongs most clearly to a software architect?
The CEO says "we must pass a bank's security audit". Which of the three questions turns this into something an architect can act on?
An architect designs a new service alone, emails the diagram, and moves to another project. What part of the rule was missed?
Why should an architect stay close to the code?
Remember
- An architect owns the hard-to-change decisions and makes them understood.
- Carry three questions: Why? What if? Who?
- Trap: jumping to "which technology" before knowing why, or deciding alone and walking away.