Enterprise data architecture
A target architecture, and a written reason for every choice in it.
A target architecture with the reasoning behind each choice written down, so the first hard question does not reopen everything.
What you get
- Current-state architecture and a prioritised gap catalogue
- A target architecture with the principles it has to satisfy stated up front
- Component-level designs with acceptance criteria, so the build is testable
- Options appraisals with the scoring and trade-offs on the record
- Master data and semantic layer design
- Migration scoping: what moves, what is archived, what is destroyed
- Review board packs and the workshops to get to sign-off
- Who it is for
- Enterprises consolidating parallel data estates, organisations replacing a core operational system, and anyone justifying a platform choice to a review board or a regulator.
- Shape and duration
- Typically eight to twenty weeks depending on the number of capabilities in scope. Often delivered alongside an existing programme team or through a consultancy partner.
- Tooling I have delivered on
-
- Azure
- Databricks
- Microsoft Fabric
- Delta Lake
- dbt
- Unity Catalog
- Purview
- Power BI
- Semarchy
- Service Bus
- erwin
Current state
The as-is work maps what is running today, including the parts nobody owns, and catalogues the gaps in a form you can prioritise.
- Current-state architecture mapped from the systems themselves
- A ranked gap catalogue: what is a constraint, what is a risk, what is untidy
- Shadow systems identified, because they show what the platform is missing
Options appraisals
The point of an appraisal is to make the reasoning legible enough for a review board to challenge, and clear enough that whoever inherits the decision in two years can see why it was made.
- Capabilities mapped to requirements, then to candidate tools
- Scored against functional fit, integration, existing skills, cost, operational complexity, security, scalability and vendor maturity
- Gaps classified by severity, so a blocking gap is visibly different from an inconvenience
- Decisions recorded with the review triggers that would change the answer
Master data, semantics and migration
The three areas where enterprise programmes most often lose a year: master data, because build-or-buy gets framed as a tooling question when it is a capability question; semantics, because metrics get defined in the reporting tool and diverge; and migration, because nobody decided what was staying behind.
- Coexistence master data design: matching, survivorship, identifier lifecycle and steward review
- A semantic layer where each business metric is defined once, outside the reporting tool
- Migration scoping at entity, field and row level, and who signs it off
- Requirements register used as the traceability spine
- Review board packs and requirements workshops
Proof
Designed
A single target lakehouse designed to replace two legacy estates at a large UK housing provider, with a documented basis for every tooling recommendation.
Justifying a platform decision?
Bring the question. A call will tell you whether the answer needs a fortnight or a quarter.
Book a call