Translating Business Impact into Architecture Decisions
TL;DR — Tie every architecture decision to a number the business already tracks. Write the ADR for the CFO, not the staff engineer. Defensible architecture is the architecture that survives the budget cycle.
A few years ago I watched a perfectly reasonable architecture proposal die in front of a finance committee because the lead engineer could not answer one question. “What does this save us per quarter?” The room waited. The engineer pulled up a Mermaid diagram, then a Grafana dashboard, then a slide with the words “developer velocity.” The CFO closed her laptop. The project was deferred two quarters and ultimately killed.
The technology was correct. The design was sound. The decision document was a perfect example of how engineers write for other engineers, and how that habit costs us the funding to do good work. By late 2024, with platform teams under cost pressure and every AI initiative being asked to justify GPU spend, this skill matters more than it has in a decade. You cannot ship the architecture you cannot defend at the business layer.
This post is the version of that lesson I wish someone had handed me earlier. It is opinionated. It will annoy purists who think architecture decisions are about technical merit. They are not. They are about technical merit constrained by a budget that someone has to sign for.
Start from the P&L, not the diagram
Every architecture decision touches three lines on a P&L. Revenue, cost of goods sold, and operating expenses. If your proposal cannot be mapped to at least one of those, you are not making an architecture decision, you are making an aesthetic choice.
## Business Impact Mapping
| Decision dimension | P&L line | Direction | Mechanism |
| --- | --- | --- | --- |
| Move from EC2 to serverless | COGS | -15% | Scale-to-zero on low-traffic services |
| Add a vector DB to support RAG | OpEx | +$8k/mo | New vendor + storage + embeddings |
| Refactor billing to event-sourced | Revenue | +2% | Faster ship of premium SKUs |
| Adopt platform team for IDP | OpEx | -20% over 18mo | Reduces duplicated infra work across orgs |
That table is the first thing in my ADRs now. Not the context. Not the decision. The money. Because the second thing the finance partner asks, after they have read the title, is “what does this do for us.” Get to the answer in row one of the first table.
A practical detail. Use ranges, not single numbers. “Saves $50k to $80k per quarter, with the lower bound assuming current traffic and the upper bound assuming projected growth from the Q1 forecast.” Single numbers invite arguments. Ranges invite acceptance.
The ADR template I use for business-facing decisions
Standard ADRs were designed for engineering audiences. They work for choosing between Redis and Memcached. They do not work for choosing between building a platform team and outsourcing the infra. For decisions that go above your director, I use this expanded template.
# ADR-<n>, <decision title>
## Status
Proposed | Accepted | Superseded by ADR-<n>
## Business context (1-2 paragraphs)
What is the business trying to do this quarter that this decision serves?
Cite an OKR, a forecast, or a board commitment.
## P&L impact
| Line | Direction | Range | Confidence |
| --- | --- | --- | --- |
| ... | ... | ... | High/Med/Low |
## Technical context
<the usual ADR context>
## Options considered
For each: cost, time, risk, reversibility, and who pays.
## Decision
<one paragraph, plain language>
## Consequences
- For engineering
- For finance
- For customers
- For compliance
## What we are NOT deciding
<scope discipline>
## Review trigger
This decision should be revisited when: <metric crosses threshold, new info arrives>
Two sections deserve attention. “What we are NOT deciding” is the scope guardrail that stops the document from becoming a multi-quarter strategy. “Review trigger” is the gift you give your future self. Architecture decisions made under one set of constraints often outlive those constraints by years. A pre-committed review trigger means somebody will notice when the world has moved.
Translate technical risk into financial risk
Engineers describe risk in terms of failure modes. Finance partners describe risk in terms of dollars and probability. The translation is one of the most useful things a senior engineer can do, and most do it badly.
Bad: “There is a risk that the new database will not scale to peak holiday traffic.”
Better: “If peak holiday traffic exceeds our forecast by 30%, the new database adds 200ms of p95 latency, which historically correlates with a 4% checkout abandonment rate. At our Q4 GMV forecast, that is a $1.2M downside, partially mitigated by the autoscaling we are funding.”
The second version invites a real conversation. The first invites a request for “more data.” For the underlying technique, the classic NIST guide on risk assessment for IT systems is a surprisingly readable foundation, even though it is aimed at security.
For more on how this connects to running discovery before you ever start writing an ADR, see Consultative Discovery for Engineering Leaders, A Playbook.
Reversibility is a business property, not just a technical one
Jeff Bezos popularized the one-way-door vs two-way-door framing, and it is still the most useful shorthand for talking about architecture decisions with non-engineers. Reversibility is a property finance understands intuitively. It maps to optionality, and optionality has a price.
Tag every option in your ADR with a reversibility class.
| Option | Reversibility | Cost to reverse | Time to reverse |
| --- | --- | --- | --- |
| A: Adopt managed vector DB | Two-way door | $30k migration | 6 weeks |
| B: Build our own vector store | One-way door | $400k+ rewrite | 6-9 months |
| C: Stay on Postgres + pgvector | Two-way door | $10k cleanup | 2 weeks |
When you put that table in front of a CFO, the conversation changes. They will often prefer the marginally more expensive two-way door option, because the unknown of “what if AI requirements shift in 2025” is worth the premium. You did not have to argue for it. The table did.
Wardley maps as a translation layer
If you have not run a Wardley map for a major decision, try it once. It is the single most useful translation tool I have found between technical and business stakeholders. You put components on a map, with evolution stage on one axis and visibility to the customer on the other. The shape of the map tells the business which components are commodities (buy them), which are products (rent them), and which are genuinely custom (build them).
The CFO does not need to learn Wardley mapping. You do. Then you walk into the meeting with a one-page map that shows why the proposed buy-vs-build decision is correct, and the conversation lasts ten minutes instead of three meetings. Simon Wardley’s original public writing on this is still the best primer, and it has aged surprisingly well into the agentic era.
Common Pitfalls
Confusing precision with accuracy. A spreadsheet with five decimal places is not more rigorous than a range. Finance partners trust ranges with stated assumptions more than they trust a single number with no provenance.
Hiding the assumptions. Always state your assumptions in the ADR, in the same section as the numbers. “Assumes current traffic, no major new product launches in H1, FX rates as of Q4 2024.” Without assumptions, your numbers age into lies within a quarter.
Letting “developer velocity” be the metric. It is real, but it is downstream of business metrics that the CFO already tracks. Translate velocity into time-to-market, cost-per-feature, or defect rate. Otherwise it sounds like engineers asking for nicer tools.
Treating the ADR as a one-shot artifact. It is a living document. The review trigger exists for a reason. Build a quarterly review of accepted ADRs into your tech-lead routine, and supersede the ones the world has moved past.
Writing the technical section first. Always start with the business context. If you cannot write the business context, you do not yet understand what you are deciding. Go back to discovery.
Underestimating the cost of meetings. A 90-minute committee with eight people is roughly $3,000 to $4,000 of fully-loaded compensation. Your ADR is competing for that time. Make it good.
Wrapping Up
The architecture decisions that survive 2024 and into 2025 are the ones written for the people who fund them. Not because the technology does not matter. It matters enormously. But because in any reasonably mature organization, the technology choice is the easy part. The hard part is convincing a room full of people with different incentives that this is the right shape of bet to make with the next quarter of engineering time.
Practice the translation. Write the P&L impact section first, even when it is uncomfortable, even when the numbers are ranges with low confidence. The act of putting a number on the page is what forces the question, and the question is what produces the answer. Engineers who can do this become the engineers in the room when the next budget gets allocated. Engineers who cannot, do the work the first group authorized.
If you do nothing else, start adding the P&L impact table to your ADRs this week. The first one will feel awkward. The fourth one will feel like the thing you should have been doing all along.
