The Architecture You Build Before a Crisis Determines Whether You Transform or Just Reorganise

HBR published an article in January titled: “Get Off the Transformation Treadmill” showing that 95% of organisations surveyed in 2024 had undertaken more than two major transformations in the previous two years, with 61% undertaking at least four. The article warns that constant shake-ups breed change fatigue that drains employee morale, while customers and suppliers grow wary of long-term partnerships.

The diagnosis is sharp:

Most organisations are stuck on a transformation treadmill, lurching from one restructure to the next, never quite fixing the underlying problems.

In a similar vein, a recent F2A article we noted that AI pilot fatigue is real, leading organisations to overlook valuable opportunities and hampering further adoption. AI pilot fatigue as with broader transformation fatigue directly impact the effectiveness and long-term success of integrating solutions within businesses.

HBR implies that organisations that avoid this cycle of constant shake-ups aren’t just “sensing emerging realities earlier", they’ve built something structural that most haven’t, a capability-led view of their business that turns strategy into execution without needing a transformation every 18 months.

That structural difference is architecture. Not the compliance-checking, after-the-fact kind. The kind that connects business intent to solution delivery through a clear line of sight:

Business Architecture → Enterprise Architecture → Solution Architecture.

When that chain works, change becomes continuous adjustment instead of periodic crisis.

When it doesn’t, you get the treadmill.

What the Research Shows: Change Fatigue Is Structural, Not Psychological

The transformation treadmill isn’t just exhausting. It’s expensive.

The human cost is measurable: it is noted that 66% of American employees are experiencing some form of burnout in 2025, and the average employee experienced around five times more major changes in 2022 than just a few years prior.

The financial cost is starker. Organisations caught in repeated transformation cycles see technology spend rise 15-20% year-over-year while struggling to demonstrate enterprise-level ROI. Integration costs compound. Duplicate capabilities multiply. And the foundational work that would reduce long-term cost gets deferred because “we're in the middle of a transformation.”

But here’s the critical finding: experiences with previous reorganisations have a lasting impact on employees’ mindset, and these effects are not moderated by successful prior reorganisations or by transformational leadership.

Even successful transformations damage your capacity for the next one.

The problem isn’t that organisations are bad at transformation. It’s that transformation itself, when it’s episodic and enterprise-wide, accumulates structural debt in the form of organisational fatigue.

Change fatigue is not about stamina, it’s about value perception.

And when employees can’t see how today’s restructure connects to last year’s initiative or next quarter’s priorities, they disengage.

The HBR piece argues that the most successful leaders avoid chronic upheaval by continuously strengthening their business systems, sensing emerging realities before crises force radical change, and fostering agility to keep problems small.

That’s the theory. Here’s how it actually works in practice.

The Gap Between Strategy and Execution Isn’t a Communication Problem. It’s an Architecture Problem.

Most organisations have strategy. They also have projects. What they don’t have is the connective tissue that turns one into the other without heroic effort every time.

That connective tissue is architecture, specifically, the cascade from business intent through enterprise design to solution delivery.

• Business Architecture answers: What capabilities does this organisation need to deliver its strategy? Not departments. Not systems. Capabilities, stable, outcome-focused views of what the business does (Customer Onboarding, Risk Assessment, Product Fulfilment) that don’t change every time you reorganise.
• Enterprise Architecture answers: How do those capabilities connect? Where do they share data, processes, technology? What dependencies exist? Where are the integration points that will break under load?
• Solution Architecture answers: Given this specific initiative, how do we design a solution that strengthens our target capabilities without creating new tangles?

When these three layers are aligned and actively used in decision-making, change stops being a transformation and starts being evolution.

When they’re not, every initiative becomes a one-off effort that ignores context, duplicates capability, and adds to the architectural debt that will force the next transformation.

Why Most Architecture Efforts Fail to Prevent the Treadmill

Let’s be clear: most organisations have some form of architecture function.

They have capability models.

They have reference architectures.

They have governance frameworks.

And yet they’re still on the treadmill.

Because architecture exists, but it doesn’t influence the decisions that matter.

Three failure modes show up repeatedly:

1. Architecture arrives after funding decisions are made. Projects get approved in budget meetings based on business cases that don’t reference capability health, don’t account for integration complexity, and don’t consider whether five other teams are solving the same problem. Enterprise Architecture reviews the design after the money’s allocated and the timeline’s set. At that point, architectural concerns become “nice to have” trade-offs, not strategic constraints.
2. Business Architecture is disconnected from Enterprise Architecture. BA teams build capability models that describe the business in abstract terms. EA teams build technical reference architectures. But there’s no operational bridge between “we need better customer intelligence capability” and “here’s how we’re going to build it without creating three new data silos.” So, both groups produce good work that doesn’t compound into organisational capability.
3. Solution Architecture designs in isolation. Each project hires solution architects who optimise for this initiative’s success. They’re measured on delivery speed and cost, not on whether their solution strengthens enterprise capability or adds to integration debt. The result? Locally optimal solutions that create enterprise-level fragmentation.

The common thread: architecture exists as a support function, not as a governing discipline.

And when architecture can’t govern, organisations accumulate complexity until it hardens into crisis. Then they transform. Then they do it again 18 months later.

What It Looks Like When Architecture Prevents the Treadmill

Organisations that stay off the transformation treadmill do something structurally different.

They embed architecture into the decision-making chain.

• Capability-led capital allocation. Instead of funding projects based on individual business cases, they fund based on capability health. Which capabilities are strategic differentiators? Which are table stakes that should be simplified? Which are over-complex and should be consolidated before they’re enhanced? When capital allocation starts from this view, you stop funding duplicate capabilities and start funding architectural coherence.
• Integration as a first-order constraint. Every initiative is evaluated not just on its standalone ROI, but on its integration complexity and its impact on enterprise capability. If a new customer intelligence tool requires 47 integration points and creates a new source of truth for “customer,” it’s either redesigned or deferred until foundational work is complete. This isn’t bureaucracy. It’s systems thinking.
• Solution Architecture with enterprise mandate. Solution architects don’t just design for this project. They design to strengthen target-state capabilities defined at enterprise level. Their mandate isn’t “deliver this scope on this timeline.” It’s “deliver this scope in a way that moves us toward our target architecture.” That changes what gets built.

When these three elements are in place, change becomes continuous. Small adjustments compound. Problems get addressed before they metastasise into transformation triggers.

Some CxO Perspectives

The transformation treadmill creates different problems depending on where you sit, but the underlying cause is the same.

For CEOs, it’s strategic drag.

The time between “we’ve decided to pursue this opportunity” and “we’re actually capturing value” stretches because every initiative requires navigating accumulated architectural complexity. Competitors with cleaner capability foundations move faster not because they have better strategy, but because their strategy doesn’t get stuck in implementation.

Worse, architectural fragmentation limits strategic optionality. When your organisation is scattered across duplicate capabilities and tangled integration, entire strategic moves become unavailable. You can’t pursue certain partnerships because your systems can’t integrate cleanly. You can’t enter certain markets because your data doesn’t support the regulatory requirements. You can’t scale certain offerings because the underlying capability is too brittle. Architecture determines which strategies are even possible.

And then there’s the board narrative. Explaining why this year’s transformation is different from last year’s, and why both were necessary, erodes confidence in leadership’s ability to create durable advantage. Investors fear greater risk and discount future earnings when organisations demonstrate chronic transformation patterns. The board question shifts from “what’s our strategy?” to “why can’t we execute without constant upheaval?"

The CEOs staying off the treadmill have recognised something fundamental: strategic agility requires architectural stability. Not rigid architecture that prevents change. Stable architecture that makes change continuous and targeted rather than episodic and enterprise-wide.

This means treating architecture as a strategic asset, not a technical function. It means giving architecture mandate over capability investment. And it means measuring organisational capability health as seriously as market position or financial performance.

For CIOs, the problem is inherited accountability.

Each business unit makes locally rational choices. Marketing selects a customer data platform. Sales implements a different CRM. Service builds their own contact centre solution. Finance has their own customer master. All perfectly reasonable decisions in isolation.

Then someone asks “can we get a unified view of customer interactions?” and suddenly you’re the one explaining why that’s a 14-month integration programme involving 47 systems, none of which were designed to talk to each other.

You didn’t make those decisions. But you inherit the consequences.

IT operating models shows that high-performing organisations are shifting toward outcome-based architecture where IT and business jointly own capability evolution. The distinction matters: when IT owns technology delivery, but business owns capability strategy, nobody owns the gap between them.

That gap is where architectural debt accumulates. And CIOs pay the maintenance cost forever.

The shift from this pattern requires three structural changes:

1. Joint accountability for capability health. Instead of business owning “requirements” and IT owning “delivery,” both own capability outcomes. Customer Onboarding isn’t an IT system. It’s a business capability with technology components. When capability health degrades, because data quality drops, or integration complexity rises, or change cycle time increases, that’s a shared problem requiring shared resolution.
2. Architecture with veto authority over fragmentation. If a business unit wants to implement a solution that creates duplicate capability or violates integration patterns, architecture can defer it until foundational work is complete. Not as a bureaucratic checkpoint, but as a strategic constraint. The CIO’s job is to make sure that authority is grounded in capability strategy, not technical preference.
3. Technology investment portfolios structured around capability evolution. Instead of funding 47 individual projects, you fund capability transformation. “Consolidate customer data capabilities from fragmented to federated” becomes a multi-year programme with clear milestones. Individual projects are sequenced to support that evolution. The business case shifts from “this project’s ROI” to “this capability’s strategic value.”

One CIO we worked with inherited an environment where application portfolio management was a spreadsheet exercise in tracking licences and contracts. We helped shift it to capability-based portfolio management: which applications support which capabilities, where capabilities are fragmented, which consolidation moves would deliver the most strategic value.

Within two years, they’d retired 40% of their application estate not through a “rationalisation programme” but through capability consolidation. Customer onboarding capability went from 14 applications to 4. Each consolidation reduced ongoing maintenance cost and improved capability health.

The shift wasn’t technical.

It was governance.

Architecture moved from “reviewing designs” to “shaping investments.”

For CFOs, the pattern is clear.

Technology spend rises. Benefits remain anecdotal. Return narratives are project-specific, never enterprise-level. And foundational work, the kind that would reduce long-term cost, gets framed as “overhead” instead of investment.

Meanwhile, duplicate capabilities multiply because nobody’s orchestrating at enterprise level. Three teams build variations of the same customer intelligence platform. Data quality initiatives fail because they’re not tied to capability strategy. Integration costs compound because every new system is designed in isolation.

Without architecture governing capital allocation, organisations optimise locally and suffer globally.

Research on enterprise architecture capability confirms what we see in practice: when aligned with the firm’s objectives and business model, EA capability can leverage organisational agility, enabling changes through innovation or operational adjustments. EA capability can orchestrate business and IT, and that IT resources are crucial to building EA capability.

This isn’t theoretical. A growing cohort of organisations is pushing toward outcome-based architecture, where architecture extends beyond designing capabilities to shaping customer journeys, value streams, and cross-functional work patterns.

We argued recently that AI without architecture is just expensive automation. The same principle applies to transformation generally: change without architecture is just expensive reorganisation.

The Practical Path: How the BA | EA | SA loop actually works

Theory is fine. Here’s what this looks like operationally.

1. Build a capability model that reflects business intent, not org structure. This is Business Architecture’s job. The model should describe what the organisation does (Manage Customer Relationships, Assess Credit Risk, Fulfil Orders) independent of how it’s currently organised. Capabilities are stable. Organisational structures change. If your capability model looks like your org chart, you’ve built the wrong thing.
2. Map capability health and strategic importance. Not all capabilities matter equally. Some are differentiators. Some are table stakes. Some are over-invested complexity. Enterprise Architecture works with business leaders to assess: Which capabilities are healthy? Which are fragmented? Which are critical to strategy? This assessment becomes the basis for investment prioritisation.
3. Define target-state patterns for priority capabilities. For each strategic capability, Enterprise Architecture defines what “good” looks like: how data should flow, which systems should own which functions, what integration patterns are acceptable. These aren’t detailed designs. They’re guardrails that Solution Architecture works within.
4. Align initiative funding to capability strategy. When new initiatives are proposed, they’re evaluated against capability priorities: Does this strengthen a strategic capability? Does it reduce fragmentation in an over-complex area? Does it create new integration debt? Capital allocation becomes capability-led, not just project-led.
5. Give Solution Architecture enterprise context. Solution architects designing specific initiatives now have clear target-state patterns to build toward. They’re not optimising in isolation. They’re designing solutions that move the organisation toward architectural coherence, even if that means longer delivery timelines or higher upfront cost for better long-term position.
6. Measure capability evolution, not just project delivery. Success isn’t “we delivered 23 projects this year.” It’s “we consolidated customer data from 14 systems to 3” or “we reduced onboarding cycle time by 40% through capability redesign.” Metrics shift from project completion to capability health.

This isn’t a one-time exercise. It’s a continuous discipline. Strategy evolves. Capabilities need adjustment. Target states get refined. But the underlying discipline, aligning business intent through enterprise design to solution delivery, remains constant.

When this works, transformation becomes unnecessary. Not because nothing changes, but because change happens continuously at the capability level instead of episodically at the enterprise level.

Why This Requires Mandate, Not Just Methodology

The hard part isn’t building capability models or defining target states. The hard part is giving architecture the mandate to influence decisions that used to happen without it.

That means:

• Capital allocation committees that start with capability health, not just business cases
• Solution architects with authority to defer initiatives that create integration debt
• Executive accountability for capability ownership, not just functional responsibility
• Metrics that track capability evolution, not just project delivery

This is uncomfortable. Because it moves architecture from advisory to governing. Because it forces trade-offs that executives would rather avoid. Because it means saying “no” to locally optimal initiatives that would damage enterprise coherence.

But it’s the only way off the treadmill.

The organisations avoiding chronic transformation have made this shift. Architecture sits inside the funding conversation, not downstream of it. Business Architecture, Enterprise Architecture, and Solution Architecture form a continuous chain from strategy to execution. And change happens as capability evolution, not enterprise upheaval.

The Choice: Continuous Evolution or Periodic Crisis

HBR’s research is clear: repeated transformations sap morale, unsettle customers and investors, and consume leadership energy, while the most successful leaders avoid chronic upheaval by continuously strengthening their business.

The question is: How?

The answer is architecture.

Not as an artefact-producing function, but as a governing discipline that connects business intent to solution delivery through clear capability strategy.

When Business Architecture defines what matters, Enterprise Architecture defines how it connects, and Solution Architecture delivers with coherence, change becomes continuous adjustment instead of periodic crisis.

When that chain is broken or marginalised, you end up back on the treadmill.

In summary:

The architecture you build before the crisis determines whether your next major challenge requires transformation or just targeted evolution.

Most organisations discover this the hard way.

The smart ones build the capability before they need it.