Why the Job Exists: Creating Value

Overview

You know which decisions are yours. This topic is about telling a good one from a bad one.

The answer is less about technical quality than people expect. The most expensive architecture failures are usually competent work aimed at the wrong target.

The chain

Architecture exists to create business value. Reasoning runs in one direction only:

graph LR
  BD["Business driver<br/>what the business<br/>wants moved"] --> QA["Quality requirement<br/>what the system<br/>must do to move it"]
  QA --> AD["Architecture decision<br/>the choice that<br/>satisfies it"]
  AD --> SS["System structure<br/>what actually<br/>gets built"]
  SS --> M["Measurable outcome<br/>did the driver<br/>move?"]
  M -.->|"feeds back"| BD

  classDef s1 fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  classDef s2 fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef s3 fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef s4 fill:#4E9A94,stroke:#3B7A75,stroke-width:2px,color:#ffffff
  classDef s5 fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  class BD s1
  class QA s2
  class AD s3
  class SS s4
  class M s5
  linkStyle 4 stroke:#7C7C7C,stroke-width:1.5px

Every arrow should be defensible. If one isn’t, everything below it is unsupported.

Compare that to how these conversations usually start:

“Should we use Pinecone or pgvector?”

That question can’t be answered — not because it’s hard, but because nothing has been established that would make one answer better. It’s a question about the fourth box, asked before anyone agreed on the first.

The reframe puts the earlier boxes back:

“We need to deflect roughly 4,500 requests a month at under $0.40 each, over a documentation corpus that changes weekly, in a region customer data can’t leave. What retrieval approach satisfies that?”

Now it has an answer. And note the answer might be “we already run that database at scale, and extending it avoids a new operational dependency” — which is an architectural argument rather than a preference.

Do the arithmetic

Business value means numbers, and the numbers are usually available if you look for them.

The shape is always the same. Find the volume (how many times a month), the current unit cost, the share the change can actually address, and the unit cost of the new path. Multiply them out. Compare against what the initiative costs to build and run.

Three things this gives you that opinion does not:

A number you can defend in a room with whoever holds the budget.
An early warning when the obvious business case doesn’t close — which is common, and far better discovered in month one than month nine.
A list of your own assumptions, which is what you will revise as you learn more.

The cost of working this way: it takes an afternoon, the numbers are rough, and someone will challenge them. Rough numbers you can defend beat precise numbers you never calculated.

Doing the arithmetic

Support costs $6.40 per ticket across ~12,000 tickets a month — about $76,800 monthly. The audit says 38% are answerable from existing documentation: roughly 4,560 tickets, costing about $29,200.

Suppose the platform handles 70% of those without a human, at $0.35 each in model and infrastructure costs:

	Tickets	Cost
Deflected by the platform	3,192	$1,117
Still reaching a human	1,368	$8,755
New total for that segment	4,560	$9,872
Previously	4,560	$29,184
Monthly saving		~$19,300

Against the approved $1.2M a year — $100,000 a month — that saving alone does not pay for the platform. Not close.

That isn’t a reason to stop. It’s the most useful thing you can know in Module 1, because it tells you where the value actually has to come from: the paid tier, or retention from faster responses, or absorbing volume growth without adding headcount. The cost story alone doesn’t carry it.

An architect who hasn’t done this arithmetic will spend six months optimising the wrong thing. One who has can walk into the room and say something true.

Technically excellent, commercially irrelevant

Here’s the failure mode in its purest form.

You could build a genuinely excellent multi-agent system — planning, tool use, self-critique — that resolves the hardest 5% of requests. It would be the most interesting thing in the company. It would also target a small fraction of the volume, cost far more per interaction than the simple path, and take three times as long to reach production.

Meanwhile the boring majority — the repetitive “how do I…” questions that make up most of the cost — would still be handled by people.

Ask of any decision: if this works perfectly, which business driver moves, and by how much? If you can’t answer, you aren’t ready to make it — regardless of how well you understand the technology.

When drivers conflict

Not every driver is a cost saving. A new paid tier is a bet on new revenue, often with a deadline someone has already promised externally.

That behaves differently from a cost driver: uncertain, time-boxed, and with consequences beyond the initiative itself. It also pulls the architecture elsewhere — a revenue feature has to be good enough to sell, a higher bar than good enough to save money internally.

A cost driver favours the cheapest path that works. A revenue driver favours something impressive enough that customers pay for it. These do not agree.

Your job is not to pretend they do, and not to average them into something that serves neither. It’s to name the tension and be explicit about which one the architecture serves when they collide. Naming it in Module 1 is worth more than resolving it in Module 6.

Feeds the workbook

This topic feeds the business-value brief. Do your own version of the arithmetic — don’t reuse the one above. A different answer is fine as long as your assumptions are written down.

→ You can judge decisions now. Others have been formalising this for forty years — what’s worth taking? — Standing on other people’s work: frameworks