Image by Nattanan Kanchanaprat from Pixabay

IN THIS SECTION, YOU WILL: Get two answers to the question of the economic value of architecture: the return on investment metaphor and the selling options metaphor.

KEY POINTS:

  • Architects are frequently asked about the (economic) value of architecture or technology investments.
  • Answering this question is a crucial skill for any senior architect. But it may be difficult to answer this seemingly harmless question concisely and convincingly to a non-technical audience.
  • Borrowing from existing literature, I sketch two answers to the question of the economic value of architecture: the return on investment metaphor and the selling options metaphor.

Architects frequently need to answer questions about the (economic) value of technology investments and architecture. Answering this question is a crucial skill for any senior architect. But it may be difficult to answer this seemingly harmless question concisely and convincingly to a non-technical audience.

Having good architecture requires some investment. This investment is time and effort spent implementing some architecture pattern, reducing technical debt, or refactoring code to align with our architecture. Consequently, we need to explain the expected value of this investment.

In this post, I sketch two answers to the question of the economic value of architecture:

  • the return-on-investment (ROI) metaphor
  • the financial options metaphor

The Return-on-Investment Metaphor

In economic terms, return on investment (ROI) is a ratio between profits and costs over some period. In other words, ROI shows how much you get back from your investment. A high ROI means the investment’s gains compare favorably to its cost. As a performance measure, you can use ROI to evaluate an investment’s efficiency or compare the efficiencies of several different investments (Figure 1).

Figure 1: An illustration of the ROI metaphor. Investment leads to lower costs or higher value. It takes some time to reach a break-even point when an additional value has compensated for the investment. After the break-even point, we earn more than without the investment.

An investment in good architecture can help increase the ROI of IT. An excellent example of using the ROI metaphor to argue for investing in architecture is the port of Martin Fowler, who uses this argument to argue for the importance of investing in improving internal quality. Figure 2 summarizes his argument.

An investment in good architecture can help increase the ROI of IT. Well-architect systems are typically much easier to understand and change.

Well-architect systems are typically much easier to understand and change. As our systems continuously evolve, the return on investing in making a system easier to understand and change can be significant. The primary value of such investment comes from generating fewer errors and bugs, more straightforward modifications, short time-to-market, and improved developer satisfaction.

Figure 2: Software with high internal quality gets a short initial slowdown but delivers more rapidly and cheaply later (source martinfowler.com/articles/is-quality-worth-cost.html).

An ROI metaphor is easy to understand by a non-technical audience, but it has limitations to describe the value of architecture. The first limitation is that measuring architecture, quality, and productivity is challenging. Consequently, too much focus on ROI can lead to an obsession with cost-cutting. Costs are easy to measure, but the value of attributes like shorter time-to-market is much more difficult to quantify. Second, ROI is a good measure, but only some investments in architecture will increase profit. That is because we frequently have to make decisions with lots of uncertainty. Nevertheless, that does not mean that we should not make such investments. The following section explains why.

The Financial Options Metaphor

Gregor Hohpe has frequently argued that the best way to explain architecture to non-technical people is by using a financial option metaphor. A financial option is a right, but not an obligation, to buy or sell financial instruments at a future point in time with some predefined price. As such, a financial option is a way to defer a decision: instead of deciding to buy or sell a stock today, you have the right to make that decision in the future at a known price.

Options are not free, and a complex market for buying and selling financial options exists.Fischer Black and Myron Scholes managed to compute the value of an option with the Black-Scholes Formula. A critical parameter in establishing the option’s value is the price at which you can purchase the stock in the future, the so-called strike price. The lower this strike price, the higher the value of the option (Figure 3).

Figure 3: An illustration of the financial option metaphor. Options have a price, leading to higher initial costs. However, if an opportunity can generate more value, we gain additional profit (or lose it if we do not invest).

Applying the financial option metaphor to IT architecture, we can argue that buying options gives the business and IT a way to defer decisions. Gregor Hohpe gives an example of the server size you need to purchase for a system. If your application is architected to be horizontally scalable, you can defer this decision: additional (virtual) servers can be ordered later at a known unit cost.

Applying the financial option metaphor to IT architecture, buying options gives the business and IT a way to defer decisions.

Another example of an IT option is architecting your system to separate concerns. For instance, deciding early what authentication mechanism an application should use may be challenging. A system that properly separates concerns allows changes to be localized so that updating one aspect of a system does not require expensive changing of the whole system. Such isolation will enable you to change a decision late in the project or even after go-live, at a nominal cost. For example, if authentication is a well-isolated concern, you will need to refactor only a minimal part of the system to use another authentication system.

The option’s value originates from being able to defer the decision until you have more information while fixing the price. In times of uncertainty, the value of the options that architecture sells only increases.

As with any analogy, the financial options analogy has its limits. Again, it is not easy to quantify architecture values and have metrics for the value of separation of concerns or horizontal scaling. Second, while the metaphor may be easy to grasp for an economic audience, it may require explaining to other stakeholders, who may be less familiar with financial options markets.

A Framework

In the end, I share a framework I developed to explain the economic value of architecture and tech investment (Figure 4).

Figure 4: A framework for discussing investments and options.

I separate the value of investments in two buskets:

  • Increasing and protecting revenue and
  • Reducing costs and risks.

Increasing and protecting revenue investments have three forms:

  • Investments that create new revenue streams by creating new products or adding new features. These investments are typically easier to defend and control, as most stakeholders intuitively understand that new functionality is needed to create new value for customers and generate more revenue. An essential aspect of this type of investment is tracking the product’s success. Adding new features will not automatically create value for customers or revenue.
  • Investments needed to stay ahead. This type of investment is a less obvious way to protect and increase revenue. It boils down to the fact that you cannot stop developing your product as the rest of the world moves on. As the saying goes, “It takes all the running you can do to keep in the same place.” For instance, you must keep essential features in parity with the competition, your system must comply with changes in regulations, and your UX must be modern.
  • Investments needed to create future options refer to being in shape to adapt to changes in the market more quickly and to bring new features to the market more quickly. Investing in keeping your system easy to maintain and extend directly creates more opportunities. Another way to look at this value driver is to frame it as preventing a revenue loss due to the impossibility of quickly adapting to future opportunities.

The second bucket relates to the more invisible part of the value created by investments:

  • Investments to reduce maintenance costs need to ensure that your code is easy to understand, change, and test. Such investments directly reduce your most significant cost, people costs, as code that is easy to maintain requires fewer people (and other way around, see Figure 5). Alternatively, you can look at these investments as a way to spend more effort on innovation and creating new revenue streams rather than merely keeping the systems in the air.
  • Investments in reducing infrastructure costs reduce spending and, if successful, are more directly visible. Such investments could take the form of redesigning your application to be more elastic, scaling up and down with minimal overhead. They could also create more transparency to have a precise image of all cost drivers and mechanisms to react quickly to any undesirable cost increases.
  • Investments in reducing license and vendor costs ensure that there is no unnecessary diversity of technologies and vendor contracts and that you can leverage economies of scale, as having fewer vendors with more users enables negotiating more favorable contracts.
  • Investments in reducing risk costs. When your system is down, your business is disrupted, and you lose revenue. According to diverse studies, the average cost of downtime ranges from $2,300 to $9,000 per minute. You must invest in keeping your system reliable and secure to avoid losing revenue and disrupting your business. While the benefits of these types of investments are huge, the challenge with building the business case for this investment is that a reliable system will only create a few incidents, making it less tangible for many stakeholders to understand the importance of continuing such investments. Or, as noted by Repenning and Sterman “Nobody Ever Gets Credit for Fixing Problems that Never Happened”.

Figure 5: A downward spiral of poorly maintainable code. As such systems grow in size and complexity, more developers are needed to maintain them. If the system is not easy to maintain, people will avoid touching code as they can easily break it. This situation will lead to a workaround (such as copying and pasting code and diverse hacks). These inefficient workarounds further increase the size and complexity of code, requiring even more developers to maintain it. And the vicious cycle continues.

Questions to Consider

  • How can you effectively communicate the value of architectural investments to non-technical stakeholders in your organization?
  • How do you weigh the importance of short-term cost reductions against long-term architecture improvements?
  • How could the return-on-investment metaphor be useful in explaining the benefits of architecture investment to your team or organization?
  • If you were to use the ROI metaphor to explain architecture’s value to non-technical stakeholders, what examples or case studies would you use to illustrate your points?
  • What are some potential pitfalls of relying too heavily on the ROI metaphor when deciding on architecture investments?
  • How could you use the financial options metaphor to explain the value of architectural investments? What are the benefits and challenges of using this metaphor in your organization?
  • How can you better quantify the value of architectural investments, particularly in terms of attributes like time-to-market and developer satisfaction?
  • How might the financial options metaphor apply to recent decisions facing your organization or team, and how could it influence those decisions?
Doing Architecture: Inspirations
← Architecture Governance: Nudge, Taxation, Mandates
Doing Architecture: Inspirations
Decision Intelligence in IT Architecture →