SIGMATIC 8 July 2026 · Mujahid · 7 min read
Discovery before build: a data platform discovery assessment guide
Last updated 2 August 2026
Every over-budget, rebuilt-twice data platform we’ve been called in to fix started the same way: someone was confident enough about the requirements to skip straight to build.
A discovery and design assessment is what happens before that. It is a short, fixed-scope piece of work that establishes the current estate, the problem actually worth solving, and a target architecture, so the build that follows is scoped against evidence rather than assumption. It typically runs two to four weeks. It routinely saves six figures in rework. If you read nothing else in this article: agree what you are building and why before anyone starts building it.
What a data platform discovery assessment actually covers
A proper discovery covers more ground than most organisations expect, and less than a full requirements-gathering exercise. The output is a decision, not a document nobody reads.
At minimum, it should establish: the business context and the decisions the platform needs to support, not just the systems it needs to replace; a current-state inventory of data sources, pipelines, warehouses and reporting tools, including what is actually used rather than what is merely running; the pain points and manual workarounds that are quietly costing time every week; the reporting and consumption patterns the new platform has to serve on day one; the governance and access model the organisation actually needs, not a generic template; a genuine cost baseline covering compute, storage, licensing and the manual effort spent working around the current platform’s limits; and a target-state architecture with enough detail to scope an MVP, informed by established patterns such as the Databricks well-architected lakehouse framework rather than invented from scratch.
That combination, current state plus target state plus a defensible reason to move from one to the other, is what turns discovery from a scoping exercise into a decision-making tool.
Why skipping it costs more than it saves
The organisations that skip discovery are not being reckless. They are usually under pressure to show progress, and a discovery phase can look like delay when what stakeholders want to see is a working platform. The problem is that the cost of skipping it does not disappear, it just moves later in the programme and gets bigger.
Rework is the most visible cost: a data model built around an assumed reporting requirement that turns out to be wrong, a catalog structure that has to be redesigned once real access requirements surface, a pipeline rebuilt because nobody checked whether the source system could actually support the intended ingestion pattern. Less visible, but usually more expensive, is scope creep: without an agreed target architecture, every stakeholder request becomes a reasonable-sounding addition, and the MVP quietly grows into a much larger, harder-to-deliver programme. Governance retrofitted after the fact is worse again, because access models and ownership decisions made under delivery pressure tend to get baked into pipelines and dashboards that are painful to unpick later.
The least visible cost is trust. A platform that ships fast but gets the first few numbers wrong spends the next year rebuilding confidence with the same stakeholders it was built to serve. Discovery is what buys that confidence upfront, before it has been spent.
What good discovery is not
It is worth being clear about what discovery should not turn into, because the term gets used loosely.
It is not a sales pitch for a specific platform or tool dressed up as neutral analysis. If the recommendation was decided before the discovery started, it was not really discovery. It is not an open-ended series of workshops with no fixed end date. If the timeline keeps slipping because there is always one more stakeholder to interview, the scope was not tight enough at the start. And it is not a hundred-page document that gets circulated once and never opened again. The output that matters is a target architecture, a roadmap and an MVP scope that a delivery team can actually work from, not a report that exists to prove the exercise happened.
A framework for judging any discovery engagement
Whether you run this internally or bring in outside help, the same deliverables separate a discovery that changes the outcome of a programme from one that just delays it.
| Deliverable | What good looks like | Red flag if it’s missing |
|---|---|---|
| Stakeholder alignment | A short, written statement of the decisions the platform needs to support, agreed by the people who will use it | Requirements gathered from IT alone, with business stakeholders informed rather than consulted |
| Current-state inventory | A real map of sources, pipelines and reports, including what is actually used | An inventory built entirely from documentation, never checked against real usage |
| Cost baseline | Compute, storage, licensing and manual effort, stated in figures the finance team recognises | A cost argument built backwards from a promised saving |
| Target architecture | Specific enough to scope an MVP: catalog structure, ingestion patterns, environment separation | A generic reference architecture with the client’s logo added |
| Roadmap and MVP scope | A phased plan with a first deliverable small enough to prove the approach | A single big-bang delivery date with no intermediate checkpoint |
| Risk register | Named risks with owners and a mitigation, not just a list | Risks acknowledged verbally but absent from any written output |
If an engagement cannot produce most of the left-hand column, it has not really done discovery, regardless of how long it took.
From discovery to delivery
Discovery only earns its cost if it visibly changes what happens next. In a well-run programme, the shift looks like this:
- Discovery — current state, target state and the decisions the platform needs to support, agreed in writing.
- Target architecture and roadmap — catalog structure, ingestion patterns and environment design, phased into stages.
- MVP delivery — the smallest slice that proves the architecture against a real workload, not the easiest slice to build.
- Scaled delivery — repeatable patterns extended across the rest of the estate, with cost and governance designed in rather than retrofitted.
Skip step one, and steps two through four still happen. They just happen more slowly, with more rework, and with the target architecture decided implicitly through a series of small technical choices rather than deliberately.
How this connects to a wider migration or modernisation programme
A migration is really just discovery applied to a specific question: should this workload move, and to what. Our guide to moving from Azure Synapse to Databricks covers the same discipline in that specific context, including why the first useful output of a migration assessment is a smaller scope, not a bigger one. The principle holds whether the trigger is a platform migration, a governance overhaul, or a first move into AI readiness: understand what you have and what you actually need before committing engineering time to changing it.
What this looks like in practice
On a regional housing retrofit and net-zero data platform, discovery is what identified that the hardest problem was not data volume, it was reconciling inconsistent identifiers and definitions across seven councils and multiple delivery partners. That finding shaped the entire target architecture, from the validation framework through to the council-level access model, before a single pipeline was built. Skipping straight to build would have produced a platform that moved data quickly and still couldn’t be trusted.
How Sigmatic Analytics runs a discovery assessment
We run discovery as a fixed-scope, fixed-timeline engagement, typically two to four weeks depending on estate size, feeding directly into the wider range of Databricks and data engineering services it exists to inform: current-state and cost baseline, target architecture, governance model, and a roadmap with a genuinely minimal MVP. The deliverable is something a delivery team, yours or ours, can start building from immediately, not a document that needs translating into a second plan before anyone can act on it.
Not sure whether your next step is discovery or straight into delivery? Book a data-platform discovery discussion and we’ll help you work out which one actually saves you time.