#Executive Communication and the Business Case

The competency most senior technologists are weakest at, and the one that separates a principal architect from a chief architect. Enterprise loops have a dedicated round for it; field loops test it inside the panel presentation when someone plays the CFO.

#1. The translation table

Learn to say the right-hand column by reflex.

You would naturally say	Say instead
"We'll implement Unity Catalog"	"You'll be able to prove to your regulator who accessed what, in minutes rather than a three-week evidence exercise"
"Liquid clustering on the fact tables"	"Queries read a fraction of the data, so the same reports cost about a third as much and finish before the morning meeting"
"Migrate to serverless"	"You stop paying for idle capacity, and the engineering time currently spent sizing clusters goes back to delivery"
"Build a RAG system"	"Your support team answers from twenty years of internal knowledge instead of escalating, and every answer cites its source"
"Delta Sharing"	"You stop building a bespoke export for every partner, and they get live data instead of last night's file"
"Medallion architecture"	"There's one definition of a customer, and when a number is wrong we can trace it to the source in minutes"
"Photon"	"Faster at a higher rate — worth it where it wins, and I'll show you the measurement rather than assert it"
"Data mesh"	"Domains ship their own data products without queuing behind a central team — provided we fund them to do it"

The test: could the sentence appear in a board paper without a glossary? If not, rewrite it.

#2. The four value levers

Every data platform business case reduces to these. Name the one you are pulling — vagueness here is what gets a business case rejected.

Lever	Mechanism	How it's measured	Credibility
Cost reduction	Decommission legacy, cut infrastructure and licences, reduce engineering toil	£ saved, run-rate reduction	Highest — finance can verify it
Productivity	Engineers and analysts deliver more per unit time	Cycle time, throughput, hours released	Medium — challenge it yourself before they do
Revenue enablement	New products, faster decisions, better targeting	£ attributable, conversion, retention	Lower — attribution is genuinely hard
Risk reduction	Regulatory compliance, audit readiness, resilience	Findings closed, RTO, incidents avoided	Medium — but often the actual reason funding exists

Lead with cost and risk, support with productivity, be honest about revenue. Claiming £40m of revenue uplift from a data platform is the fastest way to lose a CFO. Saying "I can evidence the cost and risk case; the revenue case is real but I'd rather we prove it on one use case than put a number in this paper" is the fastest way to gain one.

#3. The TCO model

Build this once, keep it in your head, and you can construct a defensible case live.

Current-state annual cost (the baseline — get this right or nothing else matters):

  Infrastructure (on-prem hardware + DC, or cloud spend)
+ Software licences and support (warehouse, ETL tooling, BI, catalogue)
+ Engineering FTEs on platform operations (fully loaded — salary × ~1.3)
+ Engineering FTEs on pipeline maintenance (as opposed to new delivery)
+ Downtime / incident cost
+ Opportunity cost of delivery that doesn't happen
= CURRENT ANNUAL RUN RATE

Future-state annual cost:

  Databricks consumption (DBUs, by workload, with a committed-spend discount assumption)
+ Cloud infrastructure (storage + compute for classic)
+ Reduced platform operations FTEs
+ Migration cost, amortised over the horizon
+ Enablement and training
= FUTURE ANNUAL RUN RATE

Then present three things, in this order:

The transition period cost — running both platforms in parallel. Say this out loud before they find it. It is the number that sinks unprepared business cases, and volunteering it buys you enormous credibility.
The crossover point — the month the new run rate drops below the old.
The three-year NPV, with your assumptions listed on the same slide.

The three assumptions to state explicitly (because they will be attacked, and pre-empting the attack is what makes you look experienced): the consumption forecast, the FTE reduction (or redeployment — say which, honestly), and the decommissioning date for the legacy platform.

The line that wins the room: "The biggest risk to this business case isn't the technology — it's that we don't switch the old platform off. If we run both for three years, the case is gone. So I'd tie the funding to decommissioning milestones, not to delivery milestones."

That is a genuinely senior thing to say, and very few candidates say it.

#4. The board narrative

Five sentences. If you cannot do it in five, you do not have it yet.

The problem, in their language. "We can't answer regulatory questions in under three weeks, and our analysts spend 60% of their time moving data instead of analysing it."
The cost of inaction. "That's £X a year in duplicated effort, plus an open audit finding and a platform contract that renews at a 40% increase in eighteen months."
The proposal, in one sentence. "Consolidate onto one governed platform, migrating by business domain over four phases."
The proof point. "We'll prove it on [specific domain] in ten weeks, before the main investment decision."
The ask. "£X, two decisions from this board, and a named executive owner per domain."

Sentence 4 is the one to get right. Boards fund things that de-risk themselves. A staged commitment with an early proof point is far more fundable than a three-year plan requiring faith.

#5. Handling the CFO's four questions

"What's the payback period?" Give a number with its assumptions attached, and state the sensitivity: "Fourteen months on our central case. If consumption runs 30% above forecast it's nineteen months. It never fails to pay back unless we don't decommission."

"What if you're wrong?" Name the biggest assumption and how you'd detect it early. "The assumption I'd watch is the consumption forecast. We'll have real data from phase one at week ten, and that's the point at which we can stop or resize before the big commitment."

"Why now?" Tie it to something with a date — a contract renewal, a regulatory deadline, a capacity limit, a competitive move. "Because AI" is not a reason; "because the Teradata renewal is in eighteen months and a migration takes twelve" is.

"What's the cheapest version?" Always have one. "A third of the cost: governance foundation plus the regulatory reporting domain only. It closes the audit finding and proves the platform, but it doesn't touch the cost base, so the savings case waits a year." Having a credible cheap option makes your recommended option look like a choice rather than a demand.

#6. Presenting to a CISO

Different audience, different structure. Lead with the threat model, not the architecture.

What data, what classification, what regulatory regime.
Where it lives and who can reach it — control plane vs compute plane, and where the data does not go.
The controls at each layer (identity, network, compute, data, encryption, audit) — see ../01-platform/08-security-networking-compliance.md.
What you cannot control, and the compensating control. Volunteer this. A CISO who finds a gap you did not mention stops trusting everything else you said.
How it is evidenced on demand.

"The thing I'd want to be straight about: serverless compute runs in Databricks' account, not yours. The compensating controls are private connectivity, egress restriction, and your data never leaving your storage. If your policy can't accept that, classic compute in your VPC is a legitimate design and I'd build it that way."

#7. Questions to ask them

You will be asked if you have questions. Having none is a scored failure. Ask things only someone who has done the job would ask.

For a field / delivery role:

"What does a struggling engagement look like here, and when do you know?"
"Where does the architect's authority actually end — can I tell a customer not to buy something?"
"How much of the role is pre-sales versus delivery, honestly?"
"What's the ratio of net-new architecture to rescuing things already in flight?"
"What's the most common reason customers here don't get to production?"

For an enterprise chief architect role:

"Who owns the platform budget, and who can say no to a domain team?"
"What's the last architecture decision that got overruled, and how did that go?"
"How many of the 14 domains actually have their own engineers?"
"What's the thing everyone knows is broken but nobody has been able to fix?"
"In twelve months, what would make you say this hire was a success — specifically?"

One closing question, for any loop:

"Is there anything about my background that gives you pause? I'd rather address it now than leave it unsaid."

Direct, confident, and it gives you one last chance to fix the objection you cannot otherwise see. Very few candidates ask it, and it is remembered.