Value Is an Architectural Attribute
When we're called in to assess a client's software architecture, the conversation usually follows a familiar pattern. Architects proudly describe their systems' performance, fault tolerance, and evolvability. What almost never comes up—the elephant in the room—is how those systems contribute to business value, and how that value should shape architectural decisions.
This omission makes decisions harder than they need to be. In one engagement, a client asked whether they should add fault tolerance to a trading system via hot fail-over to a second server. The cost: tens of thousands of dollars. Was it justified? Our first question was about the value of trades flowing through the system. Once the client investigated, they found the system was handling millions of dollars in trades daily. The cost of fault tolerance became trivially easy to justify.
The telling detail isn't that the client hadn't considered value—it's that the architecture team didn't know what their systems were worth, or how individual components contributed to overall business performance. This gap shows up consistently in our assessments. When we ask to speak with finance people, the typical response is, "Why would you want to talk to them?"
Another example: an insurance company wanted to split a monolith into microservices, sensibly organized by product line (home, personal, car, etc.). But they had no idea what share of company profits came from each line. That information is critical for sequencing a breakup. The first service to extract probably shouldn't be the most valuable, since it carries the risk of doing something for the first time. Once the team has practice, then the most valuable product line should be separated to ease modification and scaling.
Map Value Through Your Systems
A useful starting point is value stream mapping that extends into the IT landscape. Businesses often map value streams for business processes, tracing how each part of a customer journey affects revenue and margin—but the mapping typically stops at the IT boundary. Architects should push it through, assigning financial measures to the systems supporting each process step.
Non-financial measures matter too. How does a customer's ability to check claim status online affect retention? Such measures are harder to quantify, but thinking about how to measure them often yields important insights.
With one recent client, we started from customer journeys describing how customers interacted with the company. We pinned those steps across a wall in the team room, then tied each step to the systems in the IT portfolio. That let us assess each system's contribution to each journey step and the effects of a failure.
Failure Costs Are a Business Conversation
Assessing value at risk is particularly important when discussing resilience. It's best expressed in terms of what's lost if a system fails. One retailer couldn't justify testing the backup restoration process for their inventory database—there was a large backlog of business-visible features needed before the Christmas season. Our suggestion: ask the business how they'd feel about a database crash on Black Friday. What would it cost, and how quickly would they need the system back? That led to a business-led decision on dress-rehearsals for database restores and a reduced recovery time target.
When assessing value at risk, approach it from two directions. Top-down: pick a business function and identify which software systems support it. Bottom-up: start with a system and consider the ramifications of its failure.
Not all failures are equal, and not all components need the same level of resilience. A stock management system failure on Boxing Day (Britain's Black Friday equivalent) could prevent checking stock levels, forcing you to either confirm orders you can't fill or turn away orders—both serious losses. A fulfillment system failure, by contrast, might just queue orders for delayed delivery. Business leaders may consider that acceptable and choose lower resilience. The point is that resilience level is a business decision.
The same logic applies to data consistency. Architects often resist relaxing consistency for availability in distributed systems. But the business cost of double-booking a few hotel rooms may be far less than not taking bookings at all. The trade-off between consistency and availability, enshrined in the CAP theorem, is a business decision, not a technical one.
Justify Your "Ilities" with Value
The principle extends beyond resilience. Cross-functional requirements—our preferred term for non-functional requirements—should be justified by the value lost if they're not met. This is hard to assess, and many technologists avoid the debate. But skipping it risks more than over-investing in low-value technology; it erects a barrier to collaboration between technologists and their business users.
Value should also inform decisions about component flexibility. One client had a payment processing component wired to a specific payment provider. They wanted it configurable so they could switch providers quickly. Two options existed: hard-code interactions with the provider, or make them all configurable—the latter allowing a change via a configuration file in days. Configurability, however, adds complexity and increases the cost of other changes. The business context settled it: the hard part of changing payment providers was negotiating a new legal contract, which usually took over a year. Configuring the provider information wasn't worth it, since modifying a non-configurable component was still far quicker than legal negotiations.
One Size Doesn't Fit All
These examples show that "one size fits all" approaches to resilience or flexibility waste money. We once encountered an organisation that imposed a blanket "five nines" availability requirement—even on the staff sandwich ordering system. Agreeing on service tiers with the business is far more useful: does losing a service immediately impact customer experience or revenue, or is a few hours of downtime while a database restores acceptable?
Understanding value can also expose when a single component supports multiple value flows with conflicting reliability needs. This is common in monoliths and is often a strong motivation for splitting them apart—so you only pay the premium for high availability where business value justifies it.
Monitor Value, Not Just Health
Rich monitoring is invaluable for understanding system behavior, especially as systems become more distributed. Such monitoring is usually focused on technical health, supporting QA in production. But it can also reveal how much business value flows through each component.
One retail client found that monitoring queue lengths and message rates on their mainframe was a good proxy for revenue in each shop. It wasn't perfectly accurate, but presenting it to business stakeholders let them spot issues a purely technical view missed. Another client derived an accurate revenue measure for every web transaction and displayed it minute-by-minute on office screens. Those displays drew far more attention than the CPU and memory readouts.
You might argue this isn't system behavior analysis. We'd counter that understanding a component's business contribution is vital intelligence. As cloud hosting proliferates, bills arrive per individual FaaS function. We can get costs to that granularity—we should gather data on benefits too.
Monitoring can even drive investment decisions on its own. A government agency providing web services to citizens was spending significantly to support old browsers, which they considered mandatory for citizens who couldn't upgrade. Traffic data showed so few used those browsers that it would be cheaper to give each such citizen a new computer—and a bunch of flowers—than to keep supporting the outdated software.
Don’t Automatically Rebuild Everything
As more organizations move systems to the cloud, many treat the migration as a like-for-like replacement: the same features, on a new platform. Decades of watching such efforts suggests this feature-parity instinct is rarely the most efficient path. Much of what runs in existing systems contributes little value, some functionality goes unused, and some actively gets in the way of better business processes. A feature-parity replacement is usually harder than expected, and deliberately leaving out low-value functions pays for itself quickly.
One organization we worked with migrated 100% of its logistics handling code, spending months with a large portion of the development staff. When we spoke to the business about its plans, they intended to stop supporting many packaging types due to cost. Those packaging edge cases turned out to be exactly what consumed most of the migration effort—work the business didn’t even need.
Assessing how components contribute to business value is therefore a useful exercise before re-platforming. If existing pieces aren’t delivering much value, they shouldn’t be copied wholesale. A service company, for example, might find most of its revenue comes from a few common cases, with a handful of rarely used offerings requiring disproportionate software support. Such marginal cases should be reviewed before being re-implemented on a new platform, particularly if the business plans to stop offering them in the near future.
Value Isn’t Static
These value assessments aren’t permanent. We worked with an insurance company whose proprietary rating model was long considered a crown jewel. But as the industry shifted to online quotes and straight-through processing, the model’s value eroded: it required parameters an agent could collect in person, but the resulting online forms were too complex for customers.
Similarly, a retailer’s catalog management system handled semi-annual updates comfortably but couldn’t keep up with frequent online changes. Estimating the opportunity cost of lost revenue is difficult, but it has to factor into decisions about rewriting or restructuring components. A rough forecast of how value will shift with technical and business changes should accompany any snapshot of an asset’s worth today.
Business Fluency Belongs in the Technical Career Ladder
Discussions of technical leadership tend to focus on “hard” skills. Certification-heavy training courses push particular platforms, whereas we advocate education built on enduring principles—like the core engineering tools we discuss in our work on software architecture. Alongside those, “soft” skills (so-called because they are in fact harder than “hard” skills) grow in importance as developers advance into leadership.
We also believe something is missing from that mix: a firm grasp of the business itself, of where value is created and by whom. That rarely comes from courses; it comes from regular interaction with business leaders, and it should start early in a technologist’s career. Separating IT from business staff harms a profession whose value depends on software being deeply entwined with the enterprise it supports. Developers should learn early that steady contact with users and customers is normal, and they should learn how to do it well. Years of that habit pay off when they become leaders who already know the business people they’ve grown up alongside.
The communication gap between business and IT has been one of the enduring themes of our careers. When architects lose touch with the flow of business value, costs rise—both as wasted technical effort and as missed opportunities that shifts in the environment present. Software leaders need to give more attention to how business activity and software decisions intertwine, and make that part of career development for all technical staff.
