Skip to content
Latticework
Esc
Try
No. 085Strategy & Enterprise

Optionality

Prefer positions that give you the right, but not the obligation, to act in the future.

An option costs a small, known premium and pays off big if the future goes your way, so buy only the ones worth their price.

To an executive

When the future is uncertain, a small known cost today can keep large opportunities open later. Keep choices open only where the price of doing so is worth it.

To an engineer

Create cheap ways to change later, such as swapping a vendor or data store, but price them. Portability layers add complexity, so buy only options you are likely to use.

The idea

A financial option gives the right, but not the obligation, to act later. Its downside is limited to a small, known premium; its upside can be large. Optionality in architecture means keeping cheap paths open to future choices: switching vendors, scaling out, changing a data store or entering a new market.

Gregor Hohpe describes creating options as one of an architect's main jobs, and lock-in as the opposite: it makes switching hard. But options are not free. Abstraction layers, portability frameworks and multi-vendor strategies carry a premium in cost, complexity and lost features. The skill is buying only the options worth their price.

Why it works

The future is uncertain, and options turn uncertainty into upside. If you cannot predict which way things will go, a position that benefits from change is worth more than one that bets on a single outcome.

The premium is known; the payoff is not. You can decide rationally whether a small, certain cost now is worth a large, possible benefit later.

It makes lock-in a choice, not an accident. Weighing the cost of switching against the value of a product's unique features shows where lock-in is a fair price.

Where it applies

  • Vendor contracts, through terms on data export, notice periods and exit assistance.
  • Cloud and platform strategy, deciding where portability matters and where to use a provider's unique services.
  • Data architecture, where open formats and clear ownership keep the most valuable option, moving the data, cheap.
  • Roadmaps and investment, funding small experiments that create options before committing to large programmes.

How to apply

  1. Name the future you are hedging against, such as a price rise, a vendor failure or a new market.
  2. Price the option: what it costs now in money, complexity and lost features.
  3. Estimate its value: how likely you are to exercise it, and what it saves when you do.
  4. Buy the cheap, valuable options, such as open data formats and exit clauses; skip the expensive, unlikely ones.
  5. Review the options you hold, and drop those that are no longer worth their premium.

Example scenario

One company insisted on full multi-cloud portability for every workload and spent months building abstraction layers that no team ever used, while giving up the managed services that would have saved them effort.

A competitor took a narrower view. It used its cloud provider's managed services freely, but kept its data in open formats and negotiated clear exit terms. When the contract came up for renewal, that one option, credibly being able to move the data, was what gave it leverage in the negotiation.

Questions to ask

  • Which future options are worth paying to keep open?
  • What does this option cost us now, and when might we exercise it?
  • Are we buying portability we will never use?

When not to use it

  • Stable, well-understood choices, where the future is predictable enough that committing fully is cheaper.
  • When speed matters more than flexibility, such as an early product that needs to reach the market first.

How it misleads you

Hoarding options to avoid commitment. Every option has a carrying cost, and an architecture built for every possible future serves none of them well. At some point, committing creates more value than flexibility.

Further reading

Last reviewed · Suggest an improvement