Enterprise Architecture Review: What to Audit and Why

Most IT directors don't schedule an enterprise architecture review because they enjoy the process. They schedule one because something is wrong: a cloud bill that grew 40% without a corresponding increase in capability, an M&A integration that stalled because nobody could map the target company's systems onto their own, or a board that keeps asking why "digital transformation" costs so much and delivers so little. An EA review is the diagnostic that turns those vague anxieties into a defensible, fundable plan. Done well, it surfaces strategic risk, rationalizes a bloated application portfolio, and gives you a roadmap you can actually take to the CFO. Done badly, it produces a 90-slide deck that gathers dust. This article covers what to audit, why each area matters, and how to run the review so it drives decisions instead of documentation.

• Background / Why This Matters
• Core Concepts and Architecture
• Implementation Strategy
• Scaling and Operational Considerations
• Common Mistakes / What to Avoid
• Frequently Asked Questions
• Conclusion

Background / Why This Matters

Enterprise architecture drifted out of fashion for a decade. The heavyweight frameworks of the 2000s — thick TOGAF documentation, static Visio diagrams, governance boards that met quarterly and blocked everything — earned EA a reputation as bureaucratic overhead. Agile teams routed around it. The result, at many organizations, is exactly what EA was meant to prevent: dozens of overlapping SaaS tools, undocumented integrations held together by a single engineer's tribal knowledge, and no shared view of which systems actually support which business capabilities.

The pressure to fix this has intensified. AI adoption forces the question of where your data actually lives and whether it's clean enough to be useful. Rising interest rates made CFOs scrutinize every recurring software contract. Regulatory regimes — from data residency rules to sector-specific compliance — punish organizations that can't produce a current map of their systems and data flows. Research consistently suggests that a meaningful share of enterprise software spend goes to redundant or underused applications; the exact figure varies by study, but few IT directors who run a genuine portfolio audit are surprised to find double-digit percentages of waste.

An enterprise architecture review matters because it is the only exercise that connects three things most organizations track separately: what the business needs to do, what technology exists to support it, and what it all costs. When those three views live in different spreadsheets owned by different people, you make decisions blind.

Takeaway: Frame the review as a business decision-support exercise, not a documentation project. If you can't name the decisions it will inform, you're not ready to start.

Core Concepts and Architecture

A useful EA review examines four architecture layers. Skipping any of them produces a distorted picture, but you can adjust the depth of each based on what triggered the review.

Business Architecture

This is the capability map: the discrete things your organization does — "process a claim," "onboard a customer," "reconcile a payment." Everything else exists to support these. If you can't articulate the capability map, you have no basis for judging whether an application deserves to exist. Aim for 30–60 capabilities at the top two levels; more than that and you're modeling activities, not capabilities.

Application Architecture

This is the portfolio: every application, its owner, its business capability, its lifecycle stage, and its integration footprint. This is where rationalization happens. The standard analytical lens is TIME — Tolerate, Invest, Migrate, Eliminate — popularized by Gartner. Each application gets scored on business value and technical fit, then placed in one of four dispositions.

Data Architecture

Where authoritative data lives, how it flows, and who owns it. This is the layer most organizations neglect and the one AI initiatives depend on most. Audit master data (customers, products, employees), integration patterns (point-to-point vs. event-driven via tools like Kafka or a managed equivalent), and data quality ownership.

Technology Architecture

The infrastructure and platform layer: cloud accounts, Kubernetes clusters, databases, networking, and the observability stack (Datadog, Prometheus/Grafana, or equivalents). This is where cost, resilience, and security risk concentrate.

The following table shows how the four layers map to the primary questions and typical tooling you'll use during the audit.

Layer	Key question	Common tooling	Primary risk exposed
Business	What capabilities do we need to run?	ArchiMate, LeanIX, capability maps	Misaligned IT investment
Application	What supports each capability, and is it worth keeping?	LeanIX, Ardoq, ServiceNow APM	Redundancy and cost waste
Data	Where is authoritative data and is it usable?	Collibra, dbt, lineage tools	AI/analytics failure, compliance
Technology	Is the foundation secure, resilient, and cost-efficient?	AWS/Azure cost tools, Terraform, Datadog	Downtime, breach, runaway spend

Takeaway: Don't start with the technology layer just because it's the easiest to inventory. Start with business capabilities so every finding can be tied back to what the business actually needs.

Implementation Strategy

A pragmatic EA review runs in four to eight weeks for a mid-sized organization. Longer than that and stakeholders lose interest before you deliver; shorter and you skip the analysis that makes it credible. Here is a sequence that works.

1. Scope and charter (week 1). Define the triggering decisions explicitly. "Should we replatform our order management system?" or "Can we cut $2M from the software budget?" produce very different reviews. Get a named executive sponsor and secure their commitment to act on the output.
2. Inventory (weeks 1–2). Pull the application list from every available source: the CMDB, the SSO provider (Okta or Azure AD tells you what's actually being logged into), the finance system's vendor payments, and expense reports for shadow IT. The union of these lists is almost always larger than any single team expects.
3. Assessment (weeks 2–4). Score each application on business value and technical health. Use structured interviews with capability owners, not just IT. Capture cost, contract renewal dates, user counts, and integration dependencies.
4. Analysis and disposition (weeks 4–6). Apply the TIME model. Identify redundancy where multiple apps serve one capability. Map the target-state architecture and the gaps between it and today.
5. Roadmap and business case (weeks 6–8). Sequence the recommendations by dependency, risk, and payback. This is the artifact the CFO funds.

The single most important deliverable is not the current-state map — it's the funded roadmap. A roadmap that isn't tied to costs, savings, and risk reduction is a wish list. Each initiative should carry an estimated cost, an expected benefit (cost avoided, risk reduced, revenue enabled), and a rough sequencing rationale. This is where organizations often bring in outside help; Halkwinds' consulting engagements frequently focus on turning the raw assessment into a business case that survives budget scrutiny, precisely because internal teams are too close to the systems to make hard elimination calls.

Takeaway: Build the inventory from at least four independent sources. The gap between your CMDB and your SSO login logs is a direct measure of how much shadow IT you're carrying.

Scaling and Operational Considerations

The review is worthless if it becomes a one-time snapshot. The organizations that get lasting value treat EA as a living, lightweight practice — not a return to quarterly governance boards.

Keep the model current

Wire your EA repository (LeanIX, Ardoq, or even a well-structured Confluence + spreadsheet setup for smaller shops) to authoritative sources. Application inventory should sync from your CMDB and SSO. Cost data should sync from cloud billing and procurement. A model that requires manual re-entry will be stale within a quarter.

Embed architecture into delivery, not around it

Replace the blocking review board with lightweight architecture decision records (ADRs) committed alongside code, and a thin set of "guardrails" — approved patterns for authentication, data storage, and integration that teams follow by default. Reserve human review for genuine exceptions. This scales far better than a board that meets biweekly and becomes a bottleneck.

Operationalize the roadmap

Assign each roadmap initiative to an accountable owner with a target quarter. Review progress in the existing portfolio or PMO cadence rather than inventing a new ceremony. Tie deprecation of "Eliminate" applications to concrete contract renewal dates — those dates are your natural forcing functions.

Takeaway: Automate at least one data feed into your EA model before the review ends. A living model beats a perfect but frozen one.

Common Mistakes / What to Avoid

• Boiling the ocean. Attempting to model every field of every system produces a beautiful artifact nobody uses. Match depth to the decision at hand.
• Confusing inventory with analysis. A list of 300 applications is not a review. The value is in the disposition — which to keep, which to kill — and the reasoning behind it.
• Ignoring shadow IT. The marketing team's unsanctioned SaaS tools are part of your architecture whether you documented them or not. They carry real data and real risk.
• Scoring in a vacuum. Technical health scores assigned by IT alone will systematically undervalue systems the business relies on and overvalue elegant systems nobody uses. Score business value with the business.
• No executive commitment to act. If the sponsor won't commit up front to funding or killing based on findings, the review will produce recommendations that quietly expire.
• Treating the roadmap as immutable. Priorities shift. Revisit the roadmap at least twice a year against the current model, not the version frozen at delivery.

Takeaway: The failure mode is almost never insufficient documentation. It's insufficient decision-making. Optimize the review for decisions.

Frequently Asked Questions

How often should we run a full enterprise architecture review?

A full, formal review makes sense every 18–24 months, or whenever a major trigger occurs: an acquisition, a platform end-of-life, a significant cost mandate, or the start of an AI or analytics program that depends on data foundations. Between full reviews, keep the model continuously updated so the next review is an incremental refresh rather than a from-scratch effort.