Data & AI · Data platforms
A data platform where every table has a zone and an owner
We design the zones, data contracts, storage layout and access model for your analytical platform, on Microsoft Fabric, Azure Databricks, BigQuery or Snowflake. Everything lands as code in your repositories, and your data team runs it without us.
The problem
Where this usually breaks down
One copy per consumer
Each report, model and extract takes its own copy of the same source. The copies drift apart, nobody knows which one is authoritative, and an upstream change breaks consumers nobody knew about.
No line between raw and trusted
Raw extracts and cleaned tables sit side by side under similar names. Analysts cannot tell which tables are safe to build on, so each of them repeats the cleaning in their own way.
Access granted table by table
Permissions are granted by hand as requests arrive. Personal data spreads into places it should not be, and answering who can see a column means reading grants one at a time.
What we do
What we set up, and how each part works
We work in your repositories and through your change process, so everything we set up can be reviewed, run and changed by your engineers after we leave.
Landing, curated and serving zones
Raw data lands unchanged in a landing zone, is cleaned and conformed in a curated zone, and is shaped for consumers in a serving zone. Each zone has its own storage, permissions and retention rules.
Data contracts at every source boundary
Each source that feeds the platform has a contract: its schema, keys, freshness expectation, owner and how breaking changes are announced. A load that breaks its contract stops at landing instead of reaching curated tables.
Open table formats where they earn their place
Where more than one engine must read the same tables, we store curated data in Delta Lake or Apache Iceberg. Where one warehouse serves every consumer, its native storage is often the simpler and cheaper choice.
Catalogue, classification and access policy
Unity Catalog or Microsoft Purview holds the inventory, classification and ownership of every dataset. Access is granted to groups per zone and domain, and columns classified as personal data are masked by policy, not by convention.
Environments and workspaces as code
Workspaces, storage, compute policies and permissions are defined in Terraform for development, test and production. A new domain or environment arrives as a merge request and is reviewed like any other change.
Compute sized to each workload
We separate compute for loading, transformation and interactive queries, set auto-stop and quotas, and tag every resource by domain. Spend then shows up against the team that caused it, and idle compute shuts down on its own.
What you keep
What stays with your team when we finish
Everything is committed to your repositories or written into your documentation, under your access controls. Nothing depends on us to keep running.
Platform Terraform in your repository
Modules for workspaces, storage, compute policies, the catalogue and permissions in each environment, with the plan reviewed on every merge request.
A zone and naming standard
Where each kind of data lives, how schemas and tables are named, which retention applies, and which zone each type of consumer may read from.
Data contract templates
A contract template and worked contracts for your first sources, plus the checks that enforce them as data arrives in the landing zone.
Decision records and runbooks
Written decisions on engine, table format, catalogue and access model, and runbooks for onboarding a source, granting access and restoring a table.
How we work
How an engagement runs, phase by phase
Each phase ends with something your team reviews and signs off before the next one starts. We work inside your change control, not around it.
01
Map sources and consumers
We list the source systems, the reports, models and applications that consume their data, and who owns each. That map decides which domains and zones come first and which sources can wait.
02
Choose engine and layout
We weigh the options against your estate, your team’s skills and your existing licences, then agree the engine, table format, zone layout and catalogue. Each decision is recorded with the alternatives we set aside.
03
Build the first domain
One domain is built end to end, from a contracted source through landing and curated zones to a serving table that a real consumer uses. Your engineers write much of it alongside ours.
04
Extend and hand over
Further domains follow the same pattern, with your team leading and us reviewing. By handover, your engineers onboard sources, grant access and change the platform code without us.
Technology
The tools this work runs on
Each group says whether a tool appears in our published work, so you can tell what we have shown from what we offer.
Offered, not in published work
- Microsoft Fabric
- Azure Databricks
- BigQuery
- Snowflake
- Delta Lake
- Apache Iceberg
- Unity Catalog
- Microsoft Purview
- Terraform
Questions
What teams ask before we start
Should we choose a lakehouse or a warehouse?
It depends on your workloads and skills more than the label. If most work is SQL and reporting, a warehouse such as BigQuery or Snowflake is often enough. If you need Python, streaming or machine learning on the same data, a lakehouse on Azure Databricks or Microsoft Fabric usually fits better.
Can you work with the platform we already run?
Yes, and that is the usual starting point. We keep your current engine and storage, introduce the zones and contracts one domain at a time, and retire old copies once their consumers have moved. Replatforming only comes up when the current engine blocks something you need.
What access do you need to our data?
For design work, metadata is usually enough: schemas, lineage and access grants. For build work, we use development environments with masked or synthetic data where possible, and every production change goes through your pipeline and your approvals.
Who owns the platform once you step back?
Your data platform team. The Terraform, the standards, the contracts and the runbooks live in your repositories from the first commit, and your engineers build the first domain with us, so they already know how each part works.
Related services
What teams often need alongside this
Data engineering and pipelines
Contracted ingestion, tested transformations in dbt or Apache Spark, and lineage at every stage, run from version control through one deployment path.
Analytics and semantic models
A semantic model with governed metric definitions, so board reports and team dashboards in Power BI or Looker show the same numbers.
Infrastructure as code with Terraform
Terraform modules, a plan reviewed on every merge request, applies only from the pipeline, and drift reported before it becomes an incident.
Next step
Plan your data platform with us
Tell us which sources you run, who consumes the data today and where it hurts. We will come back with the questions that shape the zone and access design.