Data Strategy and Architecture
A target data architecture and a sequenced plan to reach it, derived from the decisions your business needs to make rather than from a vendor comparison matrix somebody downloaded.
Most data strategies fail in the same quiet way. They describe a target architecture nobody disagrees with, and then never say which three things get built first, who owns each dataset afterwards, or what the organisation stops doing to pay for it. The document is filed and the estate keeps growing sideways.
Data strategy and architecture is the work of deciding what data your organisation needs, where it will live, who is accountable for it, how it moves and what it costs — expressed as a target architecture and a sequenced roadmap rather than as a set of principles.
We start from decisions, not from data
The question that opens the engagement is not what data you have. It is which decisions your organisation makes badly or slowly today, and what would have to be true for them to be made well. That inverts the usual order and it consistently produces a smaller, sharper architecture.
- Which decisions are made on instinct because the data would take three weeks to assemble.
- Which numbers are argued about in meetings because two systems disagree and neither is authoritative.
- Which processes wait on data that arrives daily when the process needs it hourly, or hourly when daily would have been fine and cheaper.
- Which AI or analytics work is blocked and precisely what is blocking it, which is usually access and ownership rather than technology.
Working backwards from those answers tends to eliminate a large fraction of the pipelines people assumed were needed, and to expose two or three datasets that nobody owns and everybody depends on.
What the architecture actually covers
Sources, ownership and authority
For every significant dataset: where it originates, who is accountable for its correctness, which system is authoritative when copies disagree, and what happens when it is wrong. Naming a single accountable owner per dataset resolves more data-quality problems than any tooling purchase.
Storage and modelling
Whether you need a warehouse, a lakehouse or both, how raw and modelled layers are separated, and which modelling convention applies. We recommend a shape and say plainly what it costs and where it will strain, rather than presenting a diagram with no numbers attached.
Movement and latency, priced
Batch, micro-batch and streaming each have a cost and an operational burden. Latency requirements are set from what the business actually does with the data, because most requests for real-time turn out to mean 'sooner than tomorrow morning' once the cost of true streaming is on the table.
Governance that people can follow
Access control, classification of sensitive data, retention, lineage and audit — written as rules a working engineer can apply on a Tuesday, not as a policy that requires interpretation. Where you fall under the EU AI Act or sector regulation, we map which datasets carry obligations.
Readiness for AI specifically
AI workloads make demands that classic BI architectures do not: unstructured content alongside tables, embeddings and a vector store, point-in-time correctness for training, and lineage good enough to explain a model's inputs to a regulator. We assess against those explicitly rather than assuming a warehouse is sufficient.
How this differs from AI strategy
AI strategy and consulting decides which AI initiatives to pursue and in what order. This engagement decides what your data estate must look like for those initiatives to be buildable at all. They are often run together, and when budget forces a choice, the data work is usually what unblocks everything else.
The roadmap is sequenced by dependency and payback
A target architecture without a sequence is a wish. Ours orders the work by what unblocks what, and by what returns value soonest:
| Horizon | Focus | Typical content |
|---|---|---|
| 0 to 3 months | Unblock | Ownership assigned, access resolved, one or two pipelines rebuilt, quality measured |
| 3 to 9 months | Consolidate | Lakehouse or warehouse foundation, modelled core datasets, legacy migration begun |
| 9 to 18 months | Extend | Streaming where it is justified, vector store, feature store if model count warrants it |
| Continuous | Operate | Quality monitoring, cost review, ownership reviewed as the organisation changes |
Each item carries an owner, an estimated cost and the decision it unblocks. Anything we cannot connect to a decision is left out of the roadmap and listed separately as optional, which is usually the most contested page in the deliverable and the most useful one.
How the engagement runs
Decisions are mapped before architecture is drawn, so the target is small enough to actually build.
Decisions and pain
Workshops with business and data owners; the decisions that are slow, disputed or blocked are catalogued.
Current-state assessment
Sources, flows, ownership, quality and cost documented as they are, not as the wiki describes them.
Target architecture
Storage, movement, governance and AI readiness designed and costed, with the trade-offs written down.
Roadmap and ownership
Work sequenced by dependency and payback; each item given an owner and an estimate.
Handover
Walkthrough with the teams who will build it, and with whoever signs the budget.
What you receive
A document your engineers can build from and your CFO can fund, rather than a set of principles.
Decision map
The decisions the estate exists to support, and what each one currently lacks.
Current-state assessment
Sources, flows, ownership gaps, quality findings and present cost.
Target architecture
Storage, movement, governance and AI readiness, with technology choices justified and priced.
Sequenced roadmap
Horizon-by-horizon plan with owners, estimates and the decision each item unblocks.
Ownership model
Accountable owner per significant dataset, with the escalation path when data is wrong.
Cost model
Current spend, projected spend under the target, and the levers that move it.
Is this the right engagement?
Worth being direct. Data Strategy and Architecture is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- Data lives in enough places that nobody can say which copy is authoritative.
- AI or analytics work keeps stalling on access, quality or ownership.
- Platform spend is rising without an obvious relationship to value.
- A significant build or migration is imminent and the target is not agreed.
- You want a plan your own engineers can execute rather than a dependency on us.
Choose something else if
- You have one clean source system and a single reporting need.
- The decision is already made and you need hands to build it. Start with pipeline development.
- The real problem is which AI initiatives to pursue. That is AI strategy.
- Nobody senior can commit to owning datasets afterwards, which makes any strategy decorative.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
How is data strategy different from AI strategy?
AI strategy chooses which AI initiatives are worth doing and sequences them by value and feasibility. Data strategy decides what the underlying estate must look like for those initiatives to be buildable, priced and governed. Most organisations need both, and when only one is affordable first, fixing ownership and access usually unblocks more than a prioritisation exercise does.
Do you recommend specific platforms?
Yes, with reasons and prices, and only after the requirements are settled. We work across the major cloud warehouses and lakehouse stacks and have no reseller relationship with any of them, so the recommendation can be 'stay where you are' when the migration cost exceeds the benefit — which is more often than the industry admits.
How long before we see value?
Value from the strategy itself is the clarity of the first horizon, which arrives at the end of the engagement. Value from the estate depends on what the first horizon contains, and we deliberately sequence something visible into the first three months rather than asking for eighteen months of foundation work on faith.
What if our data quality is genuinely poor?
That is the common case and it is a finding, not a blocker. The assessment measures quality where it matters and the roadmap sequences cleaning and enrichment against the decisions that depend on it, rather than proposing to fix everything. Fixing everything is how these programmes die.
Who owns the output?
You do, in full, on final payment: the architecture, the roadmap, the assessment, the cost model and the working documents behind them. The deliverable is written so your own engineers can build from it without us, which is the point.
Often paired with this
Most clients combine two or three engagements from the Data Engineering and AI Readiness pillar. These are the ones that most often run immediately before or after.
Data Lakehouse and Warehouse Build
A governed lakehouse or warehouse with a modelled core layer, access control and predictable cost.
Read more →Data Pipeline Development
ETL and ELT pipelines that survive schema drift, late data and reruns, with tests and monitoring from day one.
Read more →Data Cleaning, Quality and Enrichment
Profiling, deduplication, standardisation and enrichment, with automated checks that stop quality decaying again.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.