Services
Enterprise data architecture assessment
The estate this was written in
A global manufacturer. Decades of successful delivery. Four SAP ECC instances, roughly 26 million SKUs, more than 200 integrations, and over 2,000 Power BI reports that nobody governs. Nothing was broken. Everything shipped. And every architectural decision for a decade had been negotiated between a plant, a region and a vendor, rather than designed against a target the enterprise had agreed on.
That is the pattern, not the exception. The estates with the best delivery record are often the ones carrying the most architectural risk, precisely because nothing has forced the question. The engagement that shaped this assessment is written up as a customer engagement:
From organic sprawl to an executive AI roadmap — in six weeksNegotiated, not designed
Ask for the target-state architecture in a large enterprise and you usually get a vendor diagram, a programme plan, or a shrug. There is a current state — reverse-engineerable with effort — and there is a list of projects. What is missing is the thing in between: an agreed picture of what the estate should look like, so that each project moves toward it rather than away.
Without that picture, every decision is locally rational and globally accumulative. A second ERP instance because the acquisition was easier to integrate that way. A reporting layer welded to the operational system because it was faster at the time. A product hierarchy maintained in three places because no one owned the one. Each one is an exception. Together they are the architecture.
The assessment starts from one position: an enterprise needs its data estate seen whole, governed as a whole, and steered toward a target state — and a set of principles that make the target state something you can actually design to.
Five principles
They are deliberately few. Any architecture decision in the estate should be checkable against all five.
Data is a corporate asset
Owned, valued and governed like plant, inventory or cash — not a by-product of whichever system happened to capture it.
Master once, consume many
Every customer, product, supplier and site has one authoritative definition. Everything else references it; nothing re-creates it.
Enterprise before local optimization
A plant, region or function may be served well by a local shortcut. The enterprise pays for it later. Local wins never set the architecture.
Automate governance
Governance that depends on people remembering to follow a process is not governance. Rules live in pipelines, contracts and checks, not in slide decks.
Design for change
The ERP will be replaced, the warehouse will move, the AI vendor will change. The architecture is judged by what stays possible when they do.
Three things that are not what they are called
Most of the value of the assessment is in renaming things correctly. Three reframes come up in almost every large estate.
MDM is not MDM
What gets filed under "master data management" is rarely a data-quality tool. It is master data plus workflow plus business rules plus compliance plus manufacturing control, welded together over years. Treat it as a tool purchase and the tool fails. Treat it as the operating system of the product and site hierarchy, and the decisions become clear.
The ERP is no longer an ERP
After enough customization and enough integrations, the ERP stops being a packaged application and becomes operational infrastructure — the thing everything else is wired to. That changes how it should be governed, how reporting should be separated from it, and what an upgrade actually means.
AI is treated as an access problem. It is an architecture problem.
The usual move is to point a model at the warehouse and open access. But a warehouse with no conformed dimensions and no semantic layer does not become consistent because a model reads it. AI amplifies the inconsistency and delivers it faster, with more confidence.
Four tracks, not one programme
The mistake is to collapse everything into a single transformation programme with a single business case. The work has different clocks. The roadmap runs four tracks in parallel, each with its own horizon and its own definition of done, sequenced against the same target state.
What the engagement looks like
A fixed-scope assessment, four to six weeks, advisory only. It ends in decisions, not a programme to be staffed by us.
- Stakeholder interviews across business, IT, data and manufacturing leadership
- Current-state blueprint — systems, integrations, data flows, reporting estate
- Target-state blueprint — principles, capability model, reference direction
- Risk and cost exposure: where operational excellence is carrying architectural risk
- Vendor and stack view — what to keep, what to decouple, what to retire
- A sequenced roadmap across the four tracks
- An executive deck built for a decision, not a reading assignment
We take a small number of these engagements at a time, and only where the executive sponsor wants the target state designed rather than negotiated.
What we work with
The estates we assess run on SAP and its neighbours: Snowflake, Databricks, dbt, Airflow, Terraform and the cloud platforms. We design against them, not for them.
Related
Frequently asked questions
What is an enterprise data architecture assessment?
A fixed-scope, four-to-six-week engagement that reverse-engineers the current data estate across ERP instances, master data, integrations and reporting, designs the target state against a small set of principles, and sequences the gap into a four-track roadmap with an executive deck. Advisory only: it ends in decisions, not a programme staffed by us.
Does this mean replacing the ERP?
No. It means deciding what the ERP is for, separating reporting and master data from it, and making future ERP decisions against a target state instead of under duress. Most of the near-term value comes from decoupling, not replacing.
How is this different from the 30-Day Reset?
The 30-Day Reset is an audit of one data platform. This assessment is enterprise-wide: ERP instances, master data, integrations, the reporting estate and AI ambitions together — a different scale of estate and a different set of decisions.
What happens after the assessment?
The roadmap is yours. Some clients run it with their own teams and integrators; some keep dataMaven on as a fractional architecture advisor at an agreed cadence. The assessment is written so that either works.
Who is this for?
Large, multi-site, multi-ERP organizations — typically manufacturing or distribution — where delivery has been excellent for years and the architecture has never been designed as a whole. We take a small number of these engagements at a time.
Does your estate have a target state, or a list of projects?
Forty-five minutes is usually enough to tell whether the risk is being masked, and whether a four-to-six-week assessment is the right next step.
Book a 45-min intro