Architecture as Strategy: How Your Technology Stack Influences Your Adaptability

You rolled out the AI pilots. Your teams are busy. The board is asking good questions and getting reasonable answers. And yet, quarter after quarter, the number on the bottom line hasn’t moved.

You’re not imagining it, and you’re not alone. AI has been adopted faster than any technology in modern history. Seventy-eight percent of organizations now use AI in at least one business function, up from 55 percent two years earlier, and regular use of generative AI more than doubled in a single year, from 33 percent to 71 percent.¹ Adoption isn’t the problem. Value is. More than 80 percent of companies say generative AI has produced no measurable impact on their earnings.² One study of a thousand executives put it more bluntly: 74 percent had yet to show any tangible value from AI at all.³

The technology works, the tools are everywhere, and most companies still can’t turn any of it into results. Why?

The thing standing between a company and the value it wants usually isn’t the model. It’s the architecture underneath it. The choices your organization made years ago about how its systems are built, connected, and allowed to change quietly decide how fast you can move today. Your technology stack is not a back-office detail. It’s your strategy, whether you treat it that way or not.

Architecture Is the Set of Decisions You Can’t Easily Take Back

Most leaders think of architecture as an engineering concern, something a few senior people handle while the business gets on with the business. That’s the mistake. Martin Fowler, one of the most influential thinkers in software design, defines architecture as the parts of a system that are hard to change, the decisions you wish you could get right early because reversing them later is so expensive. That one idea reframes the whole conversation. Architecture isn’t the code your teams write this sprint. It’s the shape of the system that hosts every feature they’ll ever build.

Amazon founder Jeff Bezos gave us a useful way to think about decisions like these. In his 2015 letter to shareholders, he split choices into two kinds. Some are two-way doors. You walk through, and if you don’t like what’s on the other side, you walk back. Make those fast. Others are one-way doors. Once you’re through, there’s no easy way back, so you decide slowly and carefully. Architecture decisions are usually one-way doors. Pick a rigid platform, wire your systems together so tightly that nothing moves without everything moving, and you’ve walked through a door that’s very hard to reopen.

Rigid architecture works against you in two ways at once.

The first is that technical debt piles up faster than you can pay it down. We like to blame technical debt on sloppy code, but the research points somewhere else. A field study that surveyed more than 1,800 engineers found the leading source of technical debt is architectural choices, not messy code.⁴ And architecture debt is the worst kind, because it takes years to build up and years to unwind. By one estimate, tech debt already equals 20 to 40 percent of the value of a company’s entire technology estate, and 10 to 20 percent of the budget meant for new products gets diverted just to service it.⁵ That’s the tax you pay for decisions that made sense once and now hold you hostage.

The second thing rigid architecture does is slow down your ability to absorb whatever comes next. And something always comes next.

AI Is a General-Purpose Technology, and That Changes the Math

To see why the next thing matters so much, it helps to borrow a concept from economics. A general-purpose technology is a rare kind of innovation that spreads across the whole economy, keeps improving, and sets off waves of new inventions in everything it touches.⁶ Steam power was one. Electricity was another. Computing was a third.

Erik Brynjolfsson, an economist who directs Stanford’s Digital Economy Lab, argues that AI belongs on that list and may be the most general example yet. That’s not a marketing line. It carries a hard, practical consequence. General-purpose technologies don’t pay off just because you own them. They pay off when you rebuild the work around them.

Brynjolfsson’s research puts a number on it. Looking at earlier waves of AI investment, he found a lopsided split between the technology and everything it takes to use it. For every dollar a company spent on the technology itself, it needed to spend roughly nine dollars on the people, processes, and systems around it.⁷

That held before today’s generative AI, and it holds even more now. The model is the cheap part, maybe one-tenth of the equation. The other nine-tenths is how well your organization can reshape itself to use it.

The companies stuck at “no measurable impact” bought the technology and stopped there. The ones pulling ahead rebuilt the work around it: the data flows, the systems, the way people actually do the job. The evidence points the same way from two directions. Of everything researchers have tested, redesigning workflows has the single biggest effect on whether a company gets earnings impact from AI. And when you ask what’s blocking companies from scaling the newest wave of agentic AI, eight in ten point at the same culprit: their data architecture can’t support it.⁸

The barrier isn’t the AI. It’s the plumbing the AI has to plug into.

Strategy researchers have a name for what separates the winners here. They call it a dynamic capability: a company’s ability to integrate, build, and reconfigure what it has to meet a changing environment.⁹ Lasting advantage doesn’t come from defending a fixed position. It comes from being able to reconfigure faster than the world changes. And your architecture is either the thing that lets you reconfigure quickly or the thing that stops you cold.

Put the two mechanisms together and you get the whole argument. Adaptable architecture slows the debt that would otherwise trap you, and it speeds the absorption of the general-purpose technology that would otherwise pass you by. It’s the same capability doing both jobs. That’s why architecture is strategy.

What This Looks Like When It’s Done Right, and When It Isn’t

Amazon is the clearest example of architecture as a strategic bet. Around 2002, the company issued a now-famous internal mandate: every team had to expose its data and functionality through service interfaces, communicate only through those interfaces, and design every one of them as if an outside customer might use it someday.¹⁰ It was painful and slow. It also quietly turned Amazon’s tangled monolith into a set of modular, swappable services. That decision didn’t just make Amazon faster inside its own walls. It became the foundation of Amazon Web Services, a business that reshaped the whole industry. Amazon built for change, and change turned into a market.

Netflix learned the same lesson the hard way. In 2008, a database failure took the service down for three days and exposed how fragile its single, tightly wound system really was. Rather than patch it, Netflix spent the next several years rebuilding itself into hundreds of loosely coupled services running in the cloud, finishing the move in early 2016.¹¹ That architecture is exactly what lets Netflix test, deploy, and change one piece without touching the rest. Capital One, a Fortune 100 bank in one of the most regulated industries there is, made a similar bet, closing all eight of its data centers and rebuilding the bulk of its applications to run cloud-native.¹² If a bank can escape its legacy, the “we’re too regulated to change” excuse gets a lot weaker.

The counter-example is just as instructive. When HealthCare.gov launched in October 2013, it failed on day one. A government audit later found ineffective planning and oversight, and reporting at the time described more than fifty contractors building pieces of the system with no single owner of the architecture and nobody integrating the whole.¹³ The pieces were wired together so tightly that a problem in one place cascaded everywhere. That wasn’t a coding failure. It was an architecture and ownership failure, and it played out on national television.

A word of caution keeps this from tipping into dogma. Adaptable does not mean “break everything into as many pieces as possible.” In 2023, Amazon’s own Prime Video team took an internal monitoring service that had been built as a sprawl of small cloud functions and consolidated it back into a single application, cutting its running costs by about 90 percent.¹⁴ Critics rushed to declare microservices dead. They missed the point. Amazon didn’t abandon modular design. It matched the architecture to the job. That’s what treating architecture as strategy actually looks like: deciding on purpose where to be flexible and where to be simple, instead of letting the default decide for you.

Building for Adaptability on Purpose

What does adaptable architecture actually take? Less than you’d think, and it starts with a shift in how you think more than anything you buy.

The core principle is loose coupling: designing systems, and the teams that own them, so that one part can change without dragging the others along. This isn’t a fashionable opinion. A decade of research on high-performing software teams keeps landing on the same finding. Loosely coupled architecture is one of the strongest predictors of a team’s ability to deliver.¹⁵ And the lever is the architecture, not the tools. You can pull this off on decades-old mainframe technology, and you can fail at it on the trendiest stack money can buy.

In practice, that starts with interfaces that can evolve, so one component can be swapped out later without breaking everything that leans on it. That’s what lets you replace the AI model behind a feature, or the vendor behind a capability, without a rewrite.

The big one is data. Most companies don’t get stuck on the AI itself. They get stuck on a data architecture built for a slower world, one where the data sat still and got read once a quarter, not one where an AI system has to reach across it in real time. Treat that data as a first-class asset instead of an afterthought and you’ve cleared the obstacle that stops most AI efforts cold. Ignore it and no model, however good, will save you.

The rest is a habit of mind: think in capabilities, not implementations. Don’t hard-wire “we use this specific search engine.” Design so that “how we do search” can change underneath you. And keep one eye on cost, because in an AI world every architectural choice shows up on next month’s bill whether you planned for it or not.

Back in 1968, the computer scientist Melvin Conway noticed that organizations are stuck building systems that mirror their own communication structures. If your teams are siloed and everything routes through one central bottleneck, your architecture ends up looking like that too, and it moves at the speed of your slowest meeting.

Adaptable architecture and an adaptable organization are two sides of the same coin.

That has a consequence most companies get wrong. Architectural thinking can’t live with a handful of specialists. The big decisions get labeled “architecture” and handed to a few senior people with the title, while the hundreds of small decisions engineers make every day, which service to call, what to hard-wire, where to take a shortcut, quietly set the real shape of the system. Those small calls are architecture too. If you want to stay adaptable, you have to build architectural judgment into every engineer, not just the ones with “Architect” on the badge. Adaptability that depends on a few gatekeepers isn’t adaptability. It’s one more bottleneck.

There’s a measurement shift hiding in here as well. Most organizations still grade their engineers on how many features they ship. That’s the wrong scoreboard. The teams that pull ahead aren’t the ones shipping the most. They’re the ones who can make a safe change fast. Change the questions you ask. How long does it take us to ship a change with confidence? What does one change cost us? When something breaks, how far does the damage spread, and how fast do we recover? Those numbers tell you whether your architecture is an asset or an anchor.

Where to Start This Quarter

You won’t fix years of architectural drift in a sprint, and you shouldn’t try. But you can start building the capability now, with a few moves that don’t need a transformation budget.

Start by treating the arrival of AI as a reason to review your architecture, not just a reason to buy another tool. Every major technology shift is really an architectural event, and the companies that thrive treat it that way. Get your senior technical people in a room and ask one question: if we had to swap in a completely new capability next quarter, where would we get stuck?

Then map your doors. Walk through your most consequential technology decisions and sort them into one-way and two-way doors. The one-way doors are where you slow down and buy yourself flexibility now, while you still can. Find the one component most likely to be replaced as AI matures (your search, your recommendations, your content handling, whatever it is for you) and give it a clean, well-defined boundary. When the replacement shows up, you want to swap it in, not rebuild around it.

Then pick your single most tangled dependency, the one everybody quietly dreads touching, and start pulling it apart a little at a time instead of waiting for a heroic rewrite that never comes. And put real measurement around change itself. Track how long a safe change takes, what it costs, and how much blows up when something goes wrong. You can’t manage adaptability you refuse to measure.

The Real Choice

The gap between the companies getting value from AI and the ones stuck in expensive pilots is widening, not closing. The leaders are now growing revenue at roughly twice the rate of the laggards.¹⁶ The distance between them isn’t mostly about who has the better model. Everyone has the same models. It’s about who built an organization that can actually absorb them.

That capability got decided long before the AI showed up, in a thousand quiet architectural choices nobody framed as strategy at the time. The good news is that the next thousand choices are still yours, and you get to make them on purpose. The technology your competitors are buying is available to you too. The only question is whether your architecture will let you use it before the market decides the answer for you.

Notes

1. Adoption of 78 percent (up from 55 percent two years earlier) and the rise in generative AI use from 33 to 71 percent: McKinsey, “The State of AI,” 2025; Stanford HAI, “2025 AI Index Report.” ↩

2. More than 80 percent report no tangible impact on enterprise earnings from generative AI: McKinsey, “The State of AI in Early 2024,” 2024. ↩

3. 74 percent yet to show tangible value from AI: Boston Consulting Group, “Where’s the Value in AI?,” 2024 (survey of 1,000 executives across 59 countries). ↩

4. Architectural choices are the leading source of technical debt: Carnegie Mellon Software Engineering Institute, “A Field Study of Technical Debt,” 2015 (survey of more than 1,800 practitioners). ↩

5. Technical debt equals 20 to 40 percent of the technology estate, with 10 to 20 percent of new-product budget diverted to service it: McKinsey, “Tech Debt: Reclaiming Tech Equity,” 2020. ↩

6. The concept of a general-purpose technology was introduced by economists Timothy Bresnahan and Manuel Trajtenberg, “General Purpose Technologies: ‘Engines of Growth?’,” Journal of Econometrics, 1995. ↩

7. The roughly one-to-nine ratio between technology spend and complementary investment: Erik Brynjolfsson, “The Turing Trap: The Promise and Peril of Human-Like Artificial Intelligence,” Daedalus, 2022. ↩

8. Workflow redesign as the biggest driver of AI earnings impact, and data architecture as the top blocker to scaling agentic AI: McKinsey, “The State of AI,” 2025, and “Building the Foundations for Agentic AI at Scale,” 2025. ↩

9. Dynamic capabilities: David Teece, Gary Pisano, and Amy Shuen, “Dynamic Capabilities and Strategic Management,” Strategic Management Journal, 1997. ↩

10. Amazon’s service-interface mandate, as publicly recounted by former Amazon engineer Steve Yegge, 2011. ↩

11. Netflix completed its migration to the cloud and microservices in early 2016: Netflix Technology Blog, 2016. ↩

12. Capital One closed the last of its eight data centers in 2020 and rebuilt the bulk of its applications cloud-native: company and press reports, 2020. ↩

13. HealthCare.gov launch failure: U.S. Government Accountability Office, report GAO-14-694, 2014, and contemporaneous reporting. ↩

14. Amazon Prime Video reduced monitoring costs by about 90 percent by consolidating one service: Amazon Prime Video Tech Blog, 2023. ↩

15. Loosely coupled architecture as a top predictor of software delivery performance: DORA / Google Cloud, State of DevOps research. ↩

16. AI leaders growing revenue at roughly twice the rate of laggards: Boston Consulting Group, “The Widening AI Value Gap,” 2025. ↩