Why does an architect need to understand the business model, and what specifically changes in the design if they do?

What changes concretely

For a price-sensitive education platform, understanding that margin per student is thin and bandwidth is the dominant cost changes several decisions that would otherwise be made on technical grounds alone:

• Cache hit ratio becomes an architectural priority, not an optimisation, because every percentage point is a direct margin improvement.
• The encoding ladder is a design decision with financial consequences, since rendition count multiplies both storage and delivery cost.
• Serving statically wherever possible becomes a default rather than an option.
• Reliability investment is graduated by journey, because uniform high availability would price the product out of its market — and an architecture that does that has optimised the wrong thing.
• Performance is reframed as access: for an audience on constrained devices and metered data, a page that is too heavy is not slow, it is unusable — and those users leave rather than complain.

The general form

The business model determines which quality attributes are worth paying for. A high-margin enterprise product can afford redundancy that a volume consumer product cannot; a product whose value is correctness can afford latency that a trading product cannot.

An architect who does not know the model will optimise the wrong attribute, competently.

What to actually learn

• How the business makes money, and what the unit economics are.
• What the largest cost lines are, because they are frequently not where engineering attention naturally goes.
• Which customer segments matter, since a blended average hides the segment carrying the revenue.
• What the growth mechanism is — expansion into new markets, new categories, or deeper usage — because the architecture must support that specific mechanism rather than growth in general.
• What the regulatory and competitive constraints are.

The output that demonstrates it

A unit-cost metric on the engineering dashboard — cost per active student, per hour delivered, per transaction — trended over time. Total spend rises with growth and tells you nothing; unit cost falling as usage grows is the only evidence the architecture is improving.

That single artefact connects engineering work to the business's own language, and it is what makes an architect's cost arguments credible.