A crystalline architectural structure on a technical blueprint, with individual load-bearing elements marked as findings

Enterprise Architecture Health Assessment: Check the ERP Foundation

How mid-market companies test whether their ERP landscape can carry the next investment — and why the architecture check comes before the tool choice.

By Dr. Harald Dreher Published: Sep 2, 2026 7 min read

How mid-market companies test whether their ERP landscape can carry the next investment — and why the architecture check comes before the tool choice

Enterprise Architecture · Fundamentals
Every architecture ages. This article shows what an Enterprise Architecture Health Assessment examines, how it runs without disrupting day-to-day operations, and why it is the logical step before every ERP and AI decision

The short answer

An EA Health Assessment independently tests whether the architecture still carries the strategy.

It examines data, processes, systems and decision rights. For a mid-market business it is the health check of the ERP landscape: it makes technical debt visible, protects the decision logic encoded in the company, and creates the precondition for AI agents to work responsibly inside the ERP later on.

What matters is the independence of the reviewer: whoever built the architecture, or stands to earn from rebuilding it, cannot assess it objectively. 33+ years of consulting experience, more than 1,200 projects, 100 % vendor-independent.

Why the architecture decides, not the next release

Companies are standing at a threshold: moving out of an internet age of largely static system landscapes and into an information age in which data-driven decisions taken in real time help determine market success. Whether an ERP landscape can carry that transition is not decided by the next software release. It is decided by the architecture underneath it.

That is precisely why the architecture belongs on the test bench at regular intervals — before symptoms turn into critical failures.

What is an Enterprise Architecture Health Assessment?

An Enterprise Architecture Health Assessment is the independent, structured review of the enterprise architecture. Data, processes, locations, roles, events and strategy are tested against the business goals — comparable to a medical check-up or an independent financial audit. It identifies degradation, technical debt and inconsistencies before they endanger ERP operations, and it delivers a prioritised action plan.

Definition

Enterprise Architecture (EA) is the explicit description of how a company is composed of strategy, processes, data, systems and decision rights. It turns implicit thought processes into explicit representations — the blueprint, or DNA, of the business. As Dreher Consulting understands it, EA is above all decision architecture: it defines which decision is taken by whom or by what, on what evidence, at which level of autonomy, and in which system of record.

The distinction matters: an enterprise architecture is not a landscape sketch and not a folder of system diagrams. It is a strategic asset that makes the dependencies, the sequencing and the alignment of a complex ERP landscape visible and manageable. And it is not a one-off project: like every asset it needs continuous maintenance — the Health Assessment is the instrument of that maintenance.

Why do architectures degrade on their own?

Architectures degrade naturally: every workaround, every undocumented interface and every shift in terminology adds to the technical debt. The process is gradual, until changes become disproportionately expensive. A regular assessment makes that degradation measurable — and protects the intellectual property encoded in the architecture: the company's decision logic.

From more than 1,200 projects since 1992 we know three recurring patterns that make an assessment strategically indispensable.

Pattern 1

Your architecture is your intellectual property

The EA is a company's codified uniqueness. That DNA is not on the internet, not at your competitors — and not in the standard scope of a software product. Competitive advantage does not come from the tool; it comes from your own decision logic.

Pattern 2

Complexity and terminology drift eat efficiency

“Customer” includes prospects in sales, only invoiced accounts in finance — and a third definition again in the legacy system. As soon as central terms diverge, the consistency of communication breaks, and with it the reliability of every report.

Pattern 3

Outdated structures act like anchors

Batch logic prevents real-time response, rigid data models block new business models, and custom developments that grew over years tie knowledge to individual people. The assessment names these anchors explicitly — as the basis for a deliberate decision, not as a reason for activity for its own sake.

Which six dimensions does an assessment examine in an ERP context?

The assessment examines data (What), processes (How), locations (Where), people and roles (Who), events (When) and strategy (Why). In an ERP context the decisive points are master data quality, the shift from batch to event-driven operations, and the unbroken alignment of the system landscape with the business goals.

These six dimensions of enquiry are the classic interrogatives of the Zachman Framework. Sam Holcman developed them further in the practice of independent architecture review — and that is where their value for the mid-market lies. In a modern ERP environment, for instance ahead of a generational change in a large ERP suite, the emphasis shifts noticeably:

Dimension	Central question	ERP relevance: what matters today
What (data)	Which information and assets are needed?	Master data quality, data ownership and data cleansing. Is the data robust enough to serve later as evidence for automated decisions?
How (processes)	Which activities deliver the value?	Efficiency of the end-to-end processes. Are the workflows designed for today — or are they simply digitised legacy?
Where (locations)	Where is the business present?	Global templates, cloud infrastructure, localisation and regulatory adjustments — customs and trade requirements or e-invoicing obligations, for example.
Who (people)	Which roles and capabilities exist?	Role concepts, decision rights, remote-work models and the skill set for modern ERP environments. Decision rights are more than role descriptions.
When (events)	Which cycles are we responding to?	Critical focus: the shift from process-driven to event-driven architectures. Does the ERP respond to market events in real time — or is it trapped in batch cycles?
Why (strategy)	Which goals is the organisation pursuing?	Vertical integration: is the ERP strategy aligned without gaps to business and mission goals — or have system decisions taken on a life of their own?

How does an assessment run without disrupting day-to-day operations?

An effective assessment needs two things: independence, and minimal disruption to operations. The sequence: secure handover of the architecture documentation, in-depth analysis largely remote, targeted expert interviews only to clear up open points. What matters is that the review is not carried out by the people who built the architecture — objectivity is the central condition of quality.

Sam Holcman puts the requirement plainly: whoever built the henhouse should not be the one guarding it. A review by the original authors — whether internal architects or the implementing system partner — structurally carries their bias into the result. The same logic that makes the case for independent ERP consulting without software sales and implementation commission applies to the architecture review: vendor neutrality is an architectural principle, not a slogan.

Because business departments are fully occupied with day-to-day work, we run the assessment on the principle of Minimal Business Intrusion — largely as a virtual assessment:

Secure data handover. Relevant documents, architecture descriptions and system information are provided within an encrypted, secured framework.
Remote analysis. The in-depth review along the six dimensions takes place largely without disrupting live operations.
Liaison principle. Short, targeted expert interviews with the business departments are held only for specific follow-up questions.
Findings document and management discussion. Findings, prioritisation and action plan are discussed with the management team and IT leadership — oriented towards decisions, not a slide marathon.

Because the enterprise architecture maps the DNA of the business, confidentiality and encryption have the highest priority throughout the analysis. We treat these strategic assets with the same care as our own intellectual property — our SCOReX® methodology, for instance, which is a methodology and not a software product.

What results does the management team receive?

The result is an evidence-based action plan: a baseline for the changes ahead, technological anchors named explicitly, silos identified, an assessment of vendor independence, and a documented path from the current to the target state. A clean bill of health is a result too — it gives investment certainty for the next architecture and ERP decisions.

Component of the findings document	Value for the decision
Baseline for continuous change	A stable starting point for implementing future changes faster and more cost-efficiently — from an ERP release change to a process redesign.
Identification of technological anchors	Explicit naming of legacy systems and rigid models that hold the business strategy back — including dependencies and the order in which they should be replaced.
Silos versus synergies	A finding on whether the organisation works as an integrated whole or in isolated units — the most common cause of contradictory figures in management reporting.
Technological agnosticism	An assessment of whether the architecture stays flexible in the face of generational change. What only works inside one vendor's stack is product configuration — not enterprise architecture.
Measurable progress	A documented path from the current state to the target state with prioritised, sequenced measures.

Why the assessment is the precondition for AI agents in the ERP

AI agents make decisions on the basis of the architecture they find. A degraded architecture with inconsistent data and unresolved decision rights turns agents into an operational risk. The Health Assessment establishes in advance which evidence is reliable, where the system of record sits, and which decisions can be delegated at all — architecture before software.

The leadership question in the mid-market today is no longer only “Which ERP?” or “Which AI?”, but: how must our architecture be defined so that we can extend our competitive advantage with AI agents and ERP — without chaining ourselves to a single vendor, and without losing governance, data quality and decision rights?

Test the evidence before agents trust it. An agent that plans on inconsistent master data automates errors — faster and in greater volume than any human. The What dimension answers whether the data is fit for decisions.
Separate capability from authority. That an agent can do something does not mean it may. The assessment makes visible where decision rights sit implicitly in people's heads and in legacy systems — the precondition for deliberately setting autonomy levels, limits and human-in-the-loop points.
Protect the system of record. The ERP remains the leading system; agents become actors inside it. Before the first productive agent writes to it, the architecture must define with what reversibility and what audit trail that happens — governance at runtime, not on paper.

Reversing that order and choosing a vendor's agent stack first pushes the risk into operations. AI recognises patterns. Consultants carry responsibility — and that is exactly why the architecture review comes before the tool choice.

When an assessment is not the right step

An EA Health Assessment is not the right step when an acute operational failure demands immediate action, when a fundamental decision about the business model is still open, or when the organisation is not prepared to translate findings into measures. A review without consequences produces paper — not architectural quality.

That honesty is part of consulting: in an acute crisis — an unstable go-live, for instance — stabilisation matters more than diagnosis. If a sale of the business or a fundamental repositioning is imminent, the strategic decision should come first and the architecture review after it. And where an assessment is sought only as a ritual to confirm software decisions already taken, we decline the engagement — the result would be worthless.

Three tactical next steps

Check the state of your documentation (30 minutes). Does a current description of your data, processes, systems and decision rights exist that a third party could understand? If the answer is “partly”, that is already the first finding.
Sample-test your terminology consistency. Have two departments define “customer”, “order” and “item” independently, then compare the answers. The differences show where your architecture is already drifting.
Schedule the architecture clarification before the next investment. Book an independent initial assessment before the next software or AI decision is budgeted. The order is what decides: architecture before software.

One closing question: if your competitive advantage is encoded in your decision logic — could anyone in your company write that logic down today, completely and explicitly, or does it exist only scattered across people's heads, legacy systems and Excel files?

30 minutes of straight talk about your architecture — directly with Dr. Dreher

Will your architecture carry the next ERP or AI decision — or not? No sales pitch, no junior consultants.

Request a meeting

Frequently asked questions about the EA Health Assessment

What is the difference between an EA Health Assessment and an IT audit?

An IT audit examines technology and compliance first and foremost: systems, security, licences. An EA Health Assessment examines the fit between business strategy and architecture — including processes, data ownership and decision rights. It does not answer the question “Is the technology running?” — it answers the question “Does the architecture carry the strategy?”

Do we need a framework such as TOGAF or Zachman for this?

You do not need the full framework apparatus. The thinking models are useful — the six dimensions of enquiry come from the Zachman Framework — but the certification and documentation effort of large corporate frameworks is often out of all proportion to the benefit in a mid-market business. What matters is that the six dimensions are answered systematically and verifiably.

How much work is an assessment for our business departments?

Little — and that is a design principle. Because the virtual assessment works with a secure data handover and remote analysis, the internal effort comes down essentially to providing existing documentation and a few targeted expert interviews under the liaison principle.

Who should carry out the assessment — our own IT or an external party?

An independent body: either a neutral internal group with no involvement in the original architecture, or an external, vendor-neutral reviewer. Whoever built the architecture, or earns from follow-on work to rebuild it, cannot assess it objectively.

What happens if the assessment finds no faults?

Then you have a robust, documented result: your architecture carries the strategy. That is not a wasted investment but investment certainty — for budget decisions, for boards and committees, and as a baseline against which future change is measured.

Which companies is an EA Health Assessment worthwhile for?

Typically for mid-sized companies facing a significant turning point: an ERP selection or migration, growth across sites or through acquisitions, or the planned use of AI agents in core processes. The larger the investment ahead, the more valuable the architecture diagnosis that precedes it.

Do you also review just one part of the architecture?

Yes. The scope is defined at the outset — focused, for example, on data quality and decision rights ahead of a planned AI deployment. A later extension to a full review builds on those results; nothing is done twice.