Business Understanding
Knowing how the organisation makes money, what it is trying to achieve, and what would damage it — without which architectural judgement has no basis.
Definition
Understanding the business well enough to know which technical properties matter, and by how much. It is the difference between an architect who optimises the right things and one who optimises whatever is technically interesting.
What to actually know
- How the organisation makes money. Which products, which customers, which margins. Cost per transaction against revenue per transaction is a number an architect should be able to state.
- The current strategic priority. Growth, margin, a market entry, a regulatory deadline. It changes, and the right architecture changes with it.
- What would seriously damage the business. A regulatory breach, a data loss, an outage during a peak, a lost enterprise customer. That list determines where reliability and security investment belongs.
- The seasonality. Retail peaks, financial year ends, tax deadlines, academic terms. These are known in advance and they change capacity strategy fundamentally.
- The competitive dynamics. Whether speed to market or reliability is the differentiator this year.
Why it changes the architecture
The same technical situation produces different correct answers:
- A growth-stage business should optimise for time to market and accept debt deliberately.
- A margin-focused business should optimise unit cost, and the same infrastructure decision is evaluated completely differently.
- A regulated business has hard constraints that outrank most technical preferences.
- A business with a known annual peak should pre-provision, where an unpredictable one must autoscale.
An architect who does not know which of these applies is guessing.
How to acquire it
Read the annual report or the board deck. Sit in on sales calls and support calls — both are dense sources of what customers actually experience. Ask the finance team how the unit economics work. Ask product what they are optimising for this quarter and why.
None of this is technical work, and it improves technical decisions more than most technical study would.
What it enables
Arguing in the organisation's currency. "Reduce p99 by 200 ms" is an engineering statement. "Reduce checkout latency, which historical data suggests moves conversion by roughly 1% per 100 ms, worth approximately £X" is a business case. Same work, different outcome.
Interview question
"How does knowing a company's business model change your architectural choices?"