DEV Community

Victor Leung
Victor Leung

Posted on • Originally published at victorleungtw.com

What Corporate Finance Taught Me

Corporate finance and enterprise architecture seem like entirely different disciplines. One deals with capital allocation and shareholder value; the other with systems, capabilities, and technology strategy. But peel back the surface, and they share the same underlying logic: how do you make good decisions when resources are scarce, uncertainty is high, and the people making decisions don't always have the same interests as the people bearing the consequences? Here are four ideas from corporate finance that I think every enterprise architect should internalise.

The first is the concept of the opportunity cost of capital. In corporate finance, this is the return shareholders forgo when they let the firm invest their money rather than taking it back. If a firm's investments can't beat that hurdle rate, the stock price falls. It's not enough to generate returns, you have to generate better returns than the next best alternative.

Enterprise architects face the same logic every time they evaluate a technology investment. The question isn't "does this system deliver value?" It's "does this system deliver more value than what we'd get if we spent that budget elsewhere?" A bespoke integration platform might work fine in isolation. But if the same investment could fund a commercial off-the-shelf capability that reduces operational risk and accelerates two other programmes, the bespoke build destroys value, even if it technically succeeds. We need hurdle rates in architecture. Not just TCO comparisons, but genuine opportunity cost thinking: what does this architecture decision preclude?

The second idea is the principal-agent problem. Shareholders delegate decisions to managers. When the agents' interests diverge from the principals', whether through misaligned incentives, information asymmetry, or simply self-interest, you get agency costs. Value leaks.

Enterprise architecture has its own principal-agent structure, and it's one we rarely name explicitly. The business delegates technology decisions to engineering and IT teams. Product managers optimise for their own delivery metrics. Infrastructure teams optimise for stability. Vendors optimise for contract renewal. Each is acting rationally from their own perspective, but the aggregate result can be an architecture that no one actually chose, a fragmented landscape of systems that each made local sense but collectively impose enormous integration cost and strategic risk. Architecture review boards, capability-based roadmaps, and fitness functions aren't bureaucratic overhead. They're mechanisms to reduce agency costs and align local decisions with enterprise value.

The third idea is that a safe dollar is worth more than a risky dollar. Investors demand a premium for bearing risk. A certain cash flow is worth more than an uncertain one of the same expected value. This is why discount rates go up with risk, and why optionality has value.

In architecture terms: a modular, replaceable system is worth more than a tightly coupled one of equivalent capability, even if the tightly coupled system is cheaper today. The modular system preserves optionality. It lets the firm adapt when vendor strategies shift, when regulatory requirements change, or when a better technology emerges. The monolith forecloses those options. The hidden cost of tight coupling is rarely captured in a business case, but it's very real. Every time I've seen a firm locked into a legacy platform beyond its useful life, the root cause is usually the same: an architecture decision made years earlier that looked locally optimal but didn't price in the cost of future inflexibility.

The fourth idea is that smart investment decisions create more value than smart financing decisions. The real value creation happens in what you invest in, not in how you fund it.

The enterprise architecture parallel is the distinction between architecture strategy and architecture execution. I've seen firms spend enormous energy on delivery optimisation, agile ceremonies, platform engineering, DevOps tooling, while the underlying investment thesis is weak. They're financing well but investing badly. If your architecture is evolving a capability the business no longer needs, no amount of execution excellence will recover that value. Conversely, a well-chosen architectural bet, the right platform, the right capability boundary, the right integration pattern, creates compounding returns even if the execution is imperfect. Before we optimise how we build and run systems, we need to be right about which capabilities actually matter.

Taken together, these four ideas point toward something larger. Enterprise architecture is ultimately a discipline of resource allocation under uncertainty, which puts it closer to corporate finance than most practitioners realise. The decisions we make about which capabilities to build, which platforms to standardise on, and which technical debts to carry have exactly the same structure as capital allocation decisions, with similarly irreversible consequences when we get them wrong.

The opportunity cost of a poor architecture decision isn't just the remediation cost. It's everything the firm could have built instead.

Top comments (0)