TL;DR
Ralph Johnson defines Architecture as "the decisions that you wish you could get right early in a project". In today's volatile environments, you need a framework for how make this wish in sensible way. The answer borrowed from finance: buy options. Pay a small upfront cost — in time, complexity, or money — to preserve future flexibility. Like financial options, they're not free, and not always worth it. Good architects know which options to buy, at what price, and when the price is simply too high to justify.
Why This Matters: Making Decisions Under Uncertainty
Architects are constantly asked to make decisions under uncertainty. Pick the wrong pattern, and you've locked the business into a dead end. Delay too long, and you've blocked the project entirely.
Most architects default to one of two bad outcomes: over-engineer for every possible future, or under-engineer and pay the price later. There's a better mental model for navigating this — and it comes from finance.
What is an Option
In finance, in layman's language, an option is a contract you purchase to buy, or sell, a given asset, say a stock, at a specified price on or before a specified date. A concrete example: Stock X is currently traded at $100. You believe it will be $120 in the next few months, so you sign an option contract to buy at $100 in x-months for let's say $5. After x-months, you look at the stock and see — if the stock is at or more than $120 you exercise your right to buy at $100, you pay the $5, and you would have made $15 in this transaction. If not, and the price dropped below $100, you let the option expire and you would have lost only $5.
The beauty of an option is that it decouples the decision to commit from the decision to act. You pay a small premium today to preserve the right to make a bigger, better-informed decision later.
In Technical Terms
The same analogy transfers directly to the day-to-day life of an architect. We work in what are called VUCA environments — Volatility, Uncertainty, Complexity, Ambiguity — where conditions change faster than any upfront plan can anticipate. In such settings, delaying a decision to the last responsible moment is of great value. However, delaying a decision is a privilege that we don't often get to enjoy. Sometimes a decision needs to be made right now — to pick a given architecture pattern, or lock some resources in place, or have some commitments of some sort to enable the project to go forward.
In these situations, a good architect will buy some options. An option here could mean that you are willing to pay a price in terms of time, or effort as an investment in the current project so that in the future you can benefit from that option.
Take the scalability concern for example. The business says: we need to be prepared for the future where our user base could grow in a matter of days from a handful of users to 10 or 100 million. ChatGPT grew to 100 million users in less than 2 months. Such demands force development teams to design and architect the system in a way that enables the business to handle such exponential growth.
The same analogy could be applied to many architectural patterns that address long-term concerns, be it scalability, reliability or security. System architects have to analyze the horizon of the system based on the business goals and decide which options they have to purchase at a given moment.
Options Are Not Free
Architecting a given system to have high availability or full fault tolerance or any other criteria comes at a cost. That cost isn't only monetary — in terms of time spent building such guardrails, or the cost of purchasing third-party tools that solve some of these problems. There are hidden costs incurred in terms of how complicated such systems eventually become, and how this complexity translates to mental load on the engineers operating the system and the whole organization that collaborates on it.
So just as a stock option has a cost to it, technical options also have costs attached to them. And the only way to decide whether a given option justifies its cost is to look at the potential ROI for the business from that option. A startup doing e-commerce can tolerate brief, temporary service interruptions. Another one in, let's say, Medical Device manufacturing needs to ensure zero downtime, instantaneous failover, and continuous execution even during hardware malfunctions.
The option premium must be weighed against the cost of being wrong. The more volatile the environment, the more valuable the option.
A Real Example
Earlier this year, I worked on a project aimed at helping customers migrate from their on-premise SAP ECC instances to the new S/4HANA. This transformation project involves one of the most typical examples of architectural decisions that are always deemed to be wrong — system sizing. What should be the size of the new HANA database that a given customer needs to purchase from SAP? The answer will always be imprecise: either too small or too big.
In that context, we built an application that estimates the target system size based on how many company codes a customer needs to move to the new S/4 system and over how many fiscal years. With this application, customers are able to estimate their target system size with 90%+ accuracy based on our test runs. The option to invest in development and research to get this application working should save potential customers millions of euros — either from savings on over-provisioned instances, or from demand that isn't wasted due to under-provisioned services.
This is the option in action: SAP pays the cost of building a sizing tool today, and enjoy the long term revenue growth from customers gaining clarity over their purchasing requirements and deciding faster what they need.
The Takeaway
Architects should be well-informed in the industry they are working in, and should be able to weigh — with the help of business leaders — the benefits and risks of each technical decision in a way that ensures the business can act on its stated mission and achieve its goals.
Every architectural decision comes with a specific cost. Only the potential business ROI — or in some cases, the cost of not deciding — should be the ultimate argument for or against it.
In the AI era, where requirements shift faster than ever and the future is increasingly hard to predict, the ability to buy the right options at the right price is no longer a nice-to-have skill. It's the core of what makes an architect valuable.
References
- Martin Fowler — Software Architecture Guide
- Gregor Hohpe — Architecture Options