Every large enterprise is being asked to innovate at a pace its own architecture cannot support. Product teams commit to quarterly releases. Customers, competitors and regulators move on their own schedules. And somewhere between the strategy deck and the sprint board sits an enterprise architecture practice that most executives fund, few can describe, and almost nobody consults before the decision gets made.
That gap has a price, and it is visible on the balance sheet. CIOs estimate that technical debt consumes 20 to 40 percent of the total value of their technology estate before depreciation, according to McKinsey. Forrester expects 75 percent of technology decision-makers to be carrying moderate or high technical debt severity by 2026, up from more than 50 percent in 2025, driven partly by the speed of AI build-out. Debt at that level is not an engineering inconvenience. It is a ceiling on what the business is allowed to attempt.
The instinct is to blame legacy systems. The more useful diagnosis is that enterprise architecture stopped connecting to delivery. Hasan Jafri, VP of Engineering, Digital Business Solutions at TELUS, has led digital transformation at large enterprises and built a foundation for engineering excellence through modern enterprise architecture practices. His position is direct: EA, executed properly, is a critical driver of business growth and innovation. Executed as documentation, it is overhead.
The shift he describes is not a tooling upgrade. It is a change in what architecture produces. A modern practice does not hand over blueprints for other people to interpret. It delivers templates, guardrails, automated checks and cost signals that engineers use on the day they build. Four practical steps get an organization there, and each one is measurable.
Enterprise architecture is widely funded and rarely decisive. The familiar complaint, too academic and too high-level, describes a practice that produces documents instead of usable assets while technical debt consumes 20 to 40 percent of enterprise technology value.
Hasan Jafri of TELUS argues that architecture should behave like a product: organized around customer journeys, delivered as code, governed by automation with human review, and costed continuously. Gartner expects 80 percent of large engineering organizations to run platform teams by 2026, which is the same idea operating at scale.
Four steps make the shift concrete. Define your customer journeys. Embrace EA as code. Automate governance with AI. Implement a FinOps model. The measure of success is not architectural elegance. It is delivery speed the business can trust.
By the numbers
20-40%
of the total value of an enterprise technology estate, before depreciation, is consumed by technical debt according to CIO estimates
– McKinsey, 2023
75%
of technology decision-makers will carry moderate or high technical debt severity by 2026, up from more than 50 percent in 2025
– Forrester, 2024
40%
more likely: companies in the bottom fifth for technical debt severity have incomplete or cancelled IT modernizations versus the top fifth
– McKinsey, 2023
80%
of large software engineering organizations will have platform engineering teams providing reusable services, components and tools by 2026, up from 45 percent in 2022
– Gartner, 2024
90%
of organizations have adopted at least one internal developer platform, with platform quality correlating directly to realized AI value
– DORA / Google Cloud, 2025
98%
of FinOps practitioners now manage AI spend, up from 31 percent two years earlier, across 1,192 respondents representing over $83 billion in annual cloud spend
– FinOps Foundation, 2026
Why the Traditional EA Operating Model Has Stopped Working
Ask an executive what the enterprise architecture function produced last quarter and the honest answer is usually a set of diagrams. Ask an engineering lead what they used from it and the answer is often nothing. That disconnect is the root problem, and it predates every technology on the current roadmap.
Jafri heard the verdict the moment he stepped into the role: “When I first took on an enterprise architecture type role, the biggest complaint was it’s too academic, it’s too high-level.” Traditional EA leans on extensive documentation and static blueprints, and blueprints age badly. By the time the diagram is approved, the system it describes has already moved.
Technical Debt Is the Price of Architecture That Never Reaches Delivery
When guidance does not arrive in a form engineers can use, teams make local decisions under deadline pressure. Those decisions accumulate. McKinsey puts the scale of that accumulation at 20 to 40 percent of the total value of an enterprise’s technology estate before depreciation, based on CIO estimates.
The operational consequence is worse than the balance sheet entry. McKinsey found that companies in the bottom fifth for technical debt severity are 40 percent more likely to have incomplete or cancelled IT modernizations than those in the top fifth. Debt does not simply slow the estate down. It stops the programs meant to fix it.
It also quietly reallocates the budget. Thirty percent of CIOs believe more than 20 percent of the technical budget nominally allocated to new products is diverted to resolving technical debt issues. Forrester expects the pressure to intensify through 2026, with 75 percent of technology decision-makers carrying moderate or high debt severity, driven partly by rapid AI build-out.
From Static Blueprints to Agile Principles
Modern EA shifts focus from rigid documentation to adaptable solutions and working agility. Your architecture should function as a product, not a document, with customer journeys, internal and external, as the organizing unit and a clear account of how technology delivers value at every step.
| The traditional EA operating model | What modern EA replaces it with |
|---|---|
| Static blueprints and reference documents | Reusable templates, SDKs and code snippets that engineers apply directly |
| Review boards consulted after design | Architects embedded in delivery teams and present in pull requests |
| Technology domains as the organizing unit | Customer journeys, internal and external, as the organizing unit |
| Governance as a manual approval gate | Governance automated in the pipeline, with human review of exceptions |
| Cost visibility at annual budget time | A continuous FinOps signal attached to every workload |
Framed this way, EA modernization is not an internal tidying exercise. It is the mechanism that decides whether the next modernization program finishes.
What Engineering Excellence Actually Requires
Jafri’s answer to the too-academic complaint is structural rather than editorial. Architecture has users, and those users are the engineers, product managers and operators who make decisions daily. Modernizing EA therefore means building a culture of engineering excellence around it, not writing better documents about it.
Hold Your Platforms Accountable, Including the Ones You Bought
Architecture modernization is often confused with buying more SaaS. The caution is that purchasing a platform does not transfer engineering responsibility.
Even in a SaaS-heavy estate, engineers must be world-class coders who understand how to build on top of those platforms. That requires teams capable of evaluating vendor offerings critically, holding a line on code quality, and creating custom solutions where the business genuinely differs from the vendor’s assumptions. Stream-aligned teams, trunk-based development models and DevOps practices are the operating model that makes this possible.
Shift Left and Design Quality In Before It Becomes Rework
Modern EA moves security, reliability and observability to the design phase rather than treating them as gates at the end. As Jafri puts it: “Security design, reliability by design, privacy by design, observability by design…you shift everything left and you build it up, design it up front.”
Building quality into systems from the start avoids costly rework, reduces technical debt and minimizes operational challenges. It is also the cheapest debt prevention available, because the alternative is paying for the same decision twice: once when it ships and again when it has to be unpicked.
Architecture that a delivery team cannot consume is not architecture. It is commentary.
The test is simple. Can an engineer act on your architecture output without booking a meeting? If the answer is no, the artefact is the problem, not the engineer.
This single test explains most of the distance between EA practices that influence delivery and EA practices that get routed around.
Four Practical Steps to Modernize Your Enterprise Architecture
The following four steps come from practice rather than theory, and they work in order. Each one produces something an engineer can use on the day it lands.
| Step | What it changes |
|---|---|
| 1. Define your customer journeys | Architecture is organized around how value reaches customers and employees rather than around technology domains |
| 2. Embrace EA as code | Guidance ships as templates, SDKs and code snippets that teams consume directly instead of interpreting |
| 3. Automate governance with AI | Standards are checked continuously in the pipeline, with architects reviewing pull requests rather than convening boards |
| 4. Implement a FinOps model | Cloud and AI spend becomes a live engineering signal tied to business outcomes |
1. Define Your Customer Journeys
Begin with the people who depend on the technology, and count the internal ones. Jafri frames it as a question worth asking out loud: “You want to start with customer journeys…even if it is an internal customer, your salespeople, what’s their journey like in their sales process?”
Map the key processes, identify the pain points, and be specific about how architecture supports each step and creates a seamless experience. Journeys give architecture a unit of value that a non-technical executive recognizes immediately, which is what makes trade-offs discussable outside the technology function.
2. Embrace EA as Code
This is the step that closes the gap between architecture and engineering. Rather than relying solely on documentation, Jafri advocates an agile approach he calls EA as code.
He explains it plainly: “How do you code EA? You build software templates. You build SDKs and code snippets…Architecture shouldn’t be building designs.” Templates, SDKs and snippets make architecture accessible and actionable for engineers, because they arrive in the same medium as the work.
The industry is moving in exactly this direction. Gartner expects 80 percent of large software engineering organizations to have established platform engineering teams as internal providers of reusable services, components and tools by 2026, up from 45 percent in 2022. DORA’s 2025 research with Google Cloud, covering approximately 5,000 technology professionals, found that 90 percent of organizations have adopted at least one internal developer platform, with a direct correlation between platform quality and the ability to realize value from AI.
The executive point is not that platforms are fashionable. It is that reusable, versioned architecture assets are the only form of guidance that reliably survives contact with a delivery deadline.
3. Automate Governance with AI
Governance is essential and, done manually, resented. Automation changes the cost of doing it well. Jafri describes his own approach: “We leverage AI to build our blueprints…We have the system architects go in and pull requests and review the code.” Governance moves into the flow of work: continuous, embedded and far less intrusive than a standing review board, which frees teams to focus on building and delivering value.
Two conditions make this safe. The first is that human review is real rather than nominal. DORA’s 2025 research found that 90 percent of technology professionals now use AI at work and over 80 percent say it increased their productivity, while 30 percent report little or no trust in AI-generated code. Architects in the pull request are the control that makes the productivity worth having.
The second is scope discipline. AI is well suited to drafting blueprints, checking conformance and flagging drift. It is not a substitute for the judgment call about whether a design serves the business. Automate the checking. Keep the deciding.
4. Implement a FinOps Model
Cost optimization is an architectural property in cloud-centric environments, not a finance activity bolted on afterwards. Jafri is direct about it: “In a digital paradigm in cloud, you need to build a FinOps capability.”
FinOps gives the organization a way to track, analyze and optimize cloud costs so that technology investments stay aligned with business goals and deliver positive returns. The discipline has also moved decisively into the executive layer. The FinOps Foundation’s State of FinOps 2026 survey, covering 1,192 respondents representing over $83 billion in annual cloud spend, found that 98 percent of practitioners now manage AI spend, up from 31 percent two years earlier, and that 78 percent of FinOps teams now report to the CTO or CIO.
That reporting line matters more than it looks. When cost accountability sits with the leaders who own architecture, spending decisions and design decisions stop being made in separate rooms.
How Do You Build a Foundation for Continuous Improvement?
The four steps establish the capability. Keeping it requires two things leaders routinely underfund: tools and proximity.
Invest in Tools That Drive Agility
Jafri highlights the need for robust tools that support remote and distributed work, enhance collaboration and communication, and ensure data privacy and security. These are not optional extras. In an organization where architecture is delivered as code and reviewed in pull requests, the tool chain is the operating model. Underinvest there and the practice reverts to documents within two quarters.
Break the Silo Between Architecture and Engineering
Silos between EA and engineering teams are the most common reason modernization stalls. Jafri’s remedy is proximity: embed architects within engineering teams and have them participate in code reviews and day-to-day development rather than reviewing from a distance.
Open communication, shared goals and a collaborative culture are what turn that structure into results. When these teams work seamlessly together, organizations achieve greater agility, faster time to market and better business outcomes. When they do not, the organization pays for architecture twice: once to produce it and again to work around it.
Instrument the Practice
A modernized architecture practice should be as observable to leadership as production systems are to engineers. Gartner expects 50 percent of software engineering organizations to use software engineering intelligence platforms to measure and increase developer productivity by 2027, compared with 5 percent in 2024. The trajectory reflects a plain management reality: a practice with no evidence loses the budget argument to one that has it.
The organizations that get value from enterprise architecture are the ones that stopped treating it as a review function.
The pattern across large enterprises is consistent. Where architecture output is consumable, meaning templates, SDKs, pipeline checks and cost signals, adoption is voluntary and fast. Where it is advisory, adoption depends on enforcement, and enforcement is expensive to sustain.
ML arteka builds architecture capability on the same principle: designed to be used by delivery teams, and measured by what ships rather than by what is approved.
How Should Leaders Measure a Modern EA Practice?
Architecture has historically been measured by artefacts produced, which is precisely why it lost credibility with delivery teams. A modern practice should be measured the way any product is measured: by adoption, by the outcomes it enables, and by the cost it removes.
| Measurement area | What to track |
|---|---|
| Journey coverage | Proportion of priority customer and employee journeys with a mapped architecture view and a named owner |
| Reuse and adoption | Share of new services built from approved templates and SDKs; teams consuming the platform without support intervention |
| Governance in flow | Percentage of standards checked automatically in the pipeline; architect turnaround time on pull requests; exceptions granted and the reasons |
| Delivery outcomes | Change lead time, change failure rate and time to restore service for teams on the platform versus teams not on it |
| Technical debt trajectory | Estimated share of technology value carried as debt; modernization programs completed versus cancelled |
| Cost efficiency | Unit cost per workload or transaction; forecast accuracy on cloud and AI spend |
Report these into the forum that reviews delivery, not into a separate architecture council. The purpose is to make architecture accountable for the same outcomes as the teams it serves, on the same cadence.
Five Leadership Takeaways
Before your next architecture review. Before your next technology budget conversation.
- Too academic is a design flaw, not a communication problem. If architecture arrives as documents, teams route around it. Ship it as templates, SDKs and pipeline checks and adoption stops needing enforcement.
- Technical debt is the bill for disconnected architecture. McKinsey puts it at 20 to 40 percent of technology estate value, and the worst-affected organizations are 40 percent more likely to cancel the modernization meant to fix it.
- Start with journeys, including internal ones. Customer and employee journeys give architecture a unit of value the business recognizes, which is what makes architectural trade-offs discussable outside the technology function.
- Automate governance, keep human judgment. AI can draft blueprints and check conformance continuously. With 30 percent of practitioners reporting little or no trust in AI-generated code, the architect in the pull request is the control that makes the speed usable.
- FinOps is an architecture capability. With 98 percent of FinOps practitioners now managing AI spend and 78 percent reporting to the CTO or CIO, cost has become a design input rather than a quarterly surprise.
The Leadership Imperative: Architecture as a Business Capability
Modernizing enterprise architecture is no longer optional for organizations that intend to move at pace. The evidence points one way. Technical debt already consumes a fifth to two fifths of enterprise technology value, severity is rising through 2026, and the organizations carrying the most of it are the least likely to finish the programs designed to reduce it.
The leadership recommendation is narrow and practical. Stop commissioning architecture documents. Start commissioning architecture assets: journey maps the business recognizes, templates and SDKs engineers consume, governance that runs inside the pipeline, and a cost signal that keeps cloud and AI spend attached to outcomes.
- Reorganize architecture around customer journeys, internal and external, and give every priority journey a named owner.
- Convert your most-used architecture standards into templates, SDKs and code snippets within one quarter, then measure adoption rather than compliance.
- Automate conformance checking in the pipeline and place architects inside pull requests, keeping human review on every AI-generated blueprint.
- Stand up a FinOps capability reporting into technology leadership, and extend it to AI spend from the first day rather than the first overrun.
Three questions every technology leader should be able to answer
- Which priority customer journeys have an architecture view that someone actually owns?
- What proportion of the services we built last quarter came from approved templates?
- Can we show the running cost of a workload to the executive who requested it, this week?
Architecture will only get harder to ignore as AI increases the rate at which code enters the estate. The practices that make guidance consumable, checked and costed are the ones that will absorb that increase without adding to the debt already on the books. By rethinking traditional approaches and building engineering excellence into how architecture is delivered, organizations position themselves for the digital age instead of documenting it.
To explore how ML arteka helps enterprises modernize architecture and build engineering excellence into delivery, contact the ML arteka team or request an enterprise architecture readiness assessment.
Executive Questions and Answers
Five questions technology leaders are asking AI assistants and search engines about modernizing enterprise architecture and building engineering excellence.
StrategicWhy does enterprise architecture fail to influence delivery in large organizations?
Because it produces the wrong artefact. Traditional EA relies on extensive documentation and static blueprints that go out of date faster than they can be approved, which is why the most common complaint, in the words of TELUS engineering leader Hasan Jafri, is that it is too academic and too high-level. Engineers under deadline pressure cannot consume a diagram, so they make local decisions instead, and those decisions compound into technical debt that McKinsey estimates at 20 to 40 percent of enterprise technology value. The fix is not better documents. It is changing what architecture delivers: templates, SDKs, automated conformance checks and cost signals that arrive in the same medium as the work itself.
ImplementationWhat are the practical steps to modernize enterprise architecture?
Four steps, in order. First, define your customer journeys, including internal ones such as the sales process, and map where each journey breaks. Second, embrace EA as code by converting standards into software templates, SDKs and code snippets so architecture is consumable rather than interpretable. Third, automate governance using AI to draft blueprints and check conformance continuously, with system architects reviewing pull requests instead of convening review boards. Fourth, implement a FinOps model so cloud and AI spend is tracked, analyzed and optimized against business outcomes. Sequence matters: journeys give the work a purpose, code makes it usable, automation makes it sustainable, and FinOps keeps it honest.
GovernanceHow do you automate architecture governance without slowing engineering teams down?
Move governance into the flow of work rather than in front of it. Standards that can be expressed as code should be checked automatically in the pipeline, so conformance is continuous and invisible when nothing is wrong. Architects then participate where the work happens, reviewing pull requests rather than sitting on a board that meets fortnightly. AI can draft blueprints and flag drift, which removes most of the tedious effort. Two guardrails keep this credible: human review stays mandatory for AI-generated architecture output, and exceptions are recorded with reasons so patterns become visible. The result is governance that teams experience as feedback rather than as a gate.
RiskWhat are the risks of using AI to generate architecture blueprints and review code?
The main risk is unearned confidence. DORA’s 2025 research found that 90 percent of technology professionals use AI at work and over 80 percent report productivity gains, but 30 percent report little or no trust in AI-generated code. Treating AI output as approved architecture rather than as a draft transfers that uncertainty straight into production. Three controls address it. Keep architects in the review path for every AI-generated blueprint and code change. Limit AI to checking and drafting rather than deciding whether a design serves the business. And track the rejection rate on AI-suggested output, because a rate that is either very high or suspiciously low tells you the review is not working.
OperationalHow should a FinOps capability work in a cloud and AI environment?
It should operate as a continuous engineering signal, not a monthly finance report. FinOps tracks, analyzes and optimizes cloud costs so technology investments stay aligned with business goals and deliver positive returns, which means unit cost per workload has to be visible to the team that owns the workload. Two shifts define the current practice. The FinOps Foundation’s State of FinOps 2026 survey found that 98 percent of practitioners now manage AI spend, up from 31 percent two years earlier, so AI workloads belong inside the model from the start. And 78 percent of FinOps teams now report to the CTO or CIO, which puts cost accountability alongside architecture accountability rather than in a separate function.
Modernizing enterprise architecture means changing what architecture produces, from static blueprints to assets engineers can use. Hasan Jafri, VP of Engineering, Digital Business Solutions at TELUS, describes the traditional complaint as too academic and too high-level, and the cost of that disconnect is measurable: McKinsey estimates technical debt consumes 20 to 40 percent of the total value of an enterprise technology estate before depreciation, companies in the bottom fifth for debt severity are 40 percent more likely to have incomplete or cancelled IT modernizations, and Forrester expects 75 percent of technology decision-makers to carry moderate or high debt severity by 2026. Four practical steps fix the operating model. Define customer journeys, including internal ones such as sales. Embrace EA as code by shipping software templates, SDKs and code snippets, a direction confirmed by Gartner’s expectation that 80 percent of large software engineering organizations will run platform engineering teams by 2026, up from 45 percent in 2022, and by DORA and Google Cloud finding 90 percent of organizations have adopted at least one internal developer platform. Automate governance with AI to draft blueprints while system architects review pull requests, noting that DORA found 90 percent of professionals use AI at work but 30 percent distrust AI-generated code. Implement FinOps, where the FinOps Foundation found 98 percent of practitioners now manage AI spend and 78 percent of teams report to the CTO or CIO. Sustain it by embedding architects in engineering teams, investing in collaboration and security tooling, and measuring adoption rather than approvals.