How to make consequential technology decisions under rapid change
Long-lived technology investments do not require every component inside them to last. Preserve what should compound, and keep fast-changing technology replaceable where the economics support it.
Technology changes faster than the investments around it
Foundation models improve quickly. Inference costs fall. Capabilities that once required specialized engineering become standard product features. Vendors appear, consolidate, and change direction.
Meanwhile, an ERP decision can shape the operating model for the next decade. Production systems often last longer still. Data structures spread across processes. Integrations accumulate. Employees build expertise around systems and workflows. Capital decisions can constrain operations long after the technology that prompted them has changed.
You cannot rebuild the operation every time better technology arrives. Waiting for the landscape to settle is equally unrealistic.
Durability cannot simply mean choosing technology that lasts.
Waiting and rushing both create commitments
Some executives respond to technological volatility by waiting.
They see foundation models improving quickly and today’s premium capability becoming cheap commodity functionality a year later. Waiting feels safer than committing too early.
Waiting can be rational when uncertainty makes new information materially valuable. But waiting also carries costs. Teams keep doing manual work. Integration problems persist. Employees lose learning time. Benefits arrive later.
Others move aggressively to capture value and learn faster.
That approach can also produce overlapping tools, duplicated integrations, premature custom development, and deep dependencies on technology likely to change quickly.
Identify which choices create expensive future commitments.
Reduce how much the investment depends on today’s technology choices
Executives still have to choose foundation models, platforms, vendors, and architectures. The investment should not depend on those choices remaining optimal for years.
Vendors lose ground. Better foundation models emerge. Capabilities that require custom engineering today become standard product features.
The architecture determines whether those changes improve the investment or force the organization to rebuild around them.
A robust investment limits how much value any uncertain technology choice can destroy.
Build the capability so its valuable parts survive
Consider predictive maintenance.
The immediate implementation may use a predictive model to identify equipment at elevated risk of failure. But the organizational capability extends much further:
- reliable equipment history
- clean telemetry
- agreed definitions of failure
- maintenance logic
- workflow integration
- evaluation methods
- what operators have learned about when to act on the output
Those assets remain valuable even when the predictive model changes.
Draw the boundary between the capability the organization intends to accumulate and the technology it expects to change.
The compounding layer contains data, operating logic, workflows, integrations, evaluation systems, and expertise. Their value should increase as the organization uses and improves them.
The outside technology market drives improvement in the components on the other side.
Every system draws this boundary differently. Focus on two questions:
What are we investing in because its value should compound?
What are we buying because it is useful now?
In applied AI, this boundary matters especially. Multiple providers offer comparable foundation-model capabilities, while the surrounding harness carries much of the organization-specific value. Our work on harness engineering develops that layer in more depth.
A better foundation model should improve the capability rather than invalidate the investment around it.
A five-year modernization investment does not require five-year technology.
Different components change at different rates
A dangerous combination is high technological volatility and high replacement cost.
Two variables expose much of the risk:
- How quickly is this component likely to change?
- How expensive will replacing it become?
| Technology volatility | Lower replacement cost | Higher replacement cost |
|---|---|---|
| Lower | Decide on merit; little optionality is at stake | Commit where depth creates enough value |
| Higher | Substitute as technology improves | Scrutinize before accepting dependency |
Focus on the lower-right cell: technology changes quickly, while migration, retraining, integration depth, process redesign, and operational disruption make replacement expensive.
Replaceability has a cost. Generalized interfaces take work. Avoiding vendor-native capabilities can slow implementation or sacrifice functionality.
Deep commitment can still be the right choice when the native capability itself creates material advantage, when preserving an abstraction costs more than the likely future switch, or when speed to a working capability matters more than preserving optionality.
Accept switching costs when the value they buy justifies them. That broader trade is the subject of deliberate irreversibility: where flexibility is worth preserving and where commitment creates more value.
A box on an architecture diagram does not make a component replaceable. If changing it forces you to rebuild everything around it, the exit exists only on paper.
What survives the technology is part of the return
Traditional ROI asks what an initiative produces.
Durability adds another test: what survives a major technology change.
Consider an institutional-knowledge capability. If the language model changes, the organization keeps the improved compounding layer and replaces only the volatile component.
That lets modernization accumulate instead of reset.
A project creates value beyond its immediate business case when what it leaves behind improves the economics of the next project.
A durable investment gives its successor something valuable to inherit.
Three questions that expose the real commitment
-
What must still be valuable five years from now?
Define the business capability and the organizational assets that should continue producing value.
If the answer is mostly a vendor or technology name, you have defined the investment too narrowly.
-
What is likely to change much sooner?
Identify the volatile technologies inside the capability.
You do not need a precise forecast. Identify the components likely to change sooner.
-
What would changing one force us to redo?
Trace the real replacement cost across migration, integration changes, contracts, testing, retraining, workflow disruption, and operations.
Then decide whether the commitment creates enough value to justify that cost.
Make technological progress accrue to the investment
Strong modernization architecture lets outside technological progress improve the investment.
Once the organization builds the compounding layer, outside improvements become leverage.
Providers release stronger foundation models. Inference gets cheaper. Better vendors emerge. Commercial products absorb capabilities that once required custom engineering.
If the original implementation welded the capability to yesterday’s technology, each improvement creates another migration problem.
If the architecture lets you replace the volatile component at a sensible cost, the economics reverse.
You apply better technology to capability the organization already owns. Instead of starting over, you carry years of accumulated investment into the replacement.
The market has performed R&D on your behalf.
External technological progress increases the return on earlier modernization work.
Design for that outcome.
