Entrazure
What we build
We implement Microsoft Fabric as one governed data layer, sized to what you actually run, serving both reporting and AI grounding from the same curated tables. The alternative most organizations arrive with is a data warehouse for reporting and a separate copy of everything for the AI project, which doubles the pipelines and guarantees the two disagree.
Lakehouse and warehouse design. A layered model: raw landing, cleaned and conformed, then business-ready tables that a report or an agent can be pointed at without a caveat. We are explicit about which workloads belong in the lakehouse and which belong in the warehouse, because putting everything in one of them because it is familiar is the most common design error we inherit.
Data Factory pipelines. Ingestion from SQL Server, Azure SQL, SAP, flat file drops, Dataverse and line-of-business APIs. Incremental where the source supports it, full reload where it does not, with failure handling that raises an alert instead of quietly leaving yesterday’s numbers in place. Silent staleness is worse than an outage, because nobody stops trusting the report.
Direct Lake semantic models. Models that read the lakehouse tables directly, which removes the import refresh window and the copy of the data that came with it. We build the measures, the date logic, the row-level security and the field descriptions the business actually reads in the field list.
Workspace and capacity governance. A workspace structure that separates development, test and production, with deployment pipelines between them and access granted through Entra ID groups rather than named individuals. Capacity metrics are visible to the people who can act on them, so a runaway notebook is a conversation on day one instead of a surprise on the invoice.
Cataloguing and classification. Microsoft Purview over the estate: what exists, who owns it, what is sensitive and where it is allowed to travel. This is what lets you answer, in one sitting, whether a table containing personal information is feeding a report shared with a supplier.
F-SKU sizing, measured. We start conservatively, instrument the capacity, and resize on two months of real consumption data. Buying the capacity first and finding the workload afterwards is how a data platform acquires a reputation for being expensive before it has produced anything.
Where the data comes from
- Source system Azure SQL The transactional database, read on a schedule rather than exported by hand into a file that then becomes the version somebody trusts.
- Source system Dataverse The business applications, read through their own connector, so there is no extract for anyone to maintain and forget.
- Source system File drop The monthly file that still arrives by email in most organizations. Treated as a real source, with an arrival check, rather than pretended away.
What lands it, on a schedule
- Data Factory pipeline Ingestion Incremental where the source supports it, full reload where it does not, and an alert when it fails. Silent staleness is worse than an outage, because nobody stops trusting the report.
- Notebook Conform and clean Types fixed, duplicates resolved, the same customer identified the same way across three systems. This is where most of the work actually is.
Lakehouse, three zones, in this order
- Bronze zone Raw, as it landed Exactly what the source sent, unmodified and dated. Nothing downstream is allowed to read it.
- Silver zone Cleaned and conformed Deduplicated, typed, and joined on keys that agree with each other. Still not a business answer.
- Gold zone Business ready The tables a report or an agent can be pointed at without a caveat. The only zone anything downstream reads.
What reads the gold tables
- Warehouse Reporting warehouse For the workloads that want a strict schema and SQL. We say which belong here and which belong in the lakehouse, because putting everything in the familiar one is the most common design error we inherit.
- Direct Lake Semantic model Reads the gold tables directly: no import refresh window, and no second copy of the data to fall out of step. The measures, the date logic and the row-level security live here, once.
What people and agents open
- Power BI Certified report Built on the shared model rather than on its own copy of the logic, which is how two reports stop giving two answers to the same question.
- Grounding AI workload The same curated tables ground an agent, instead of a second set of pipelines built to feed it separately. One governed layer, not two stacks.
Underneath all of it
- Storage One storage layer for the workspace Everything above is attached to the same storage. The lakehouse, the warehouse and the semantic model read one set of files, not three copies of them.
- Governance Microsoft Purview What exists, who owns it, what is sensitive and where it is allowed to travel. Whether a table holding personal information feeds a report shared outside should be answerable in one sitting.
- Access Microsoft Entra ID Workspace access granted to groups rather than to named individuals, so it follows the personnel change instead of a spreadsheet nobody updated.
- Release Deployment pipelines Development, test and production, with the item definitions in your own Git repository. Nothing important exists only inside a portal.
- A drawing, not a screenshot. Reproducing the product interface or its logo would be an imitation of a trademark, and an approximate imitation is spotted at once by anyone who uses the tool daily.
- The three zones are numbered rather than coloured. The order is the meaning, and colour alone never carries information here.
- Every box is one item in one workspace, deployed from your own repository rather than clicked into existence.
Fabric, or not
We say no to Fabric more often than the market expects. If your entire analytics requirement is eight reports over one transactional database, a well-built Power BI semantic model on a Pro license answers it, and a Fabric capacity is an operating cost with nothing behind it.
Fabric earns its place when at least two of these are true: multiple sources that must be conformed, a data volume where import refreshes have become a scheduling problem, a genuine governance requirement, or an AI workload that needs curated grounding data rather than a document dump. When it is one source and one team, we tell you to wait.
How the engagement runs
Weeks 1 and 2, sources and decisions. We inventory the sources, agree the layered model, fix the workspace and capacity structure, and pick the first two subject areas by business value rather than by ease of extraction. Output is a written decision record and a target schema, not a slide deck.
Weeks 3 to 6, first subject area end to end. Ingestion, transformation, curated tables, semantic model and one production report. End to end matters: a pipeline with no report at the end proves nothing, and a report on uncurated data proves the wrong thing.
Weeks 7 and 8, second subject area and governance. The second area is built largely by your team with us reviewing, which is where the transfer actually happens. In parallel we set up the Purview catalog, sensitivity labels, deployment pipelines and capacity alerting.
Weeks 9 and 10, hardening and handover. Failure-mode testing on the pipelines, capacity tuning against two months of metrics, documentation, and a working session with the people who own it next. We name what we deliberately left out and when it should be picked up.
What you keep
- Notebooks, pipeline definitions and semantic model definitions in your Git repository.
- The layered data model documented, with the reason for each table’s placement.
- Deployment pipelines between development, test and production, already used at least twice.
- A Purview catalog with owners and classifications on the tables that matter.
- The capacity sizing analysis, with the consumption data behind the recommendation.
- A runbook for pipeline failures, written for whoever is on call rather than for us.
- A prioritized backlog of the subject areas not yet built, with our estimate for each.
Who this is for
Organizations with several source systems that disagree, a reporting layer built on exports, and someone senior who has decided that the answer to a disputed number should take an hour rather than a week. It is a natural next step once an Azure landing zone exists, and it is the layer we recommend building before an AI engineering project, because grounding an agent on ungoverned data produces confident answers from the wrong table.
Who this is not for
If you have one clean source system and a handful of reports, do not buy a capacity. Build the semantic model instead.
If nobody in the business will own a data definition, Fabric will not fix it. The platform can show that two departments compute revenue differently. It cannot decide which one is right, and we have never seen a tool resolve that argument.
If your requirement is real-time control of a process at a plant floor, this is the wrong tool and the wrong latency. And if the intent is to buy a platform and staff it later, the platform will decay quietly until the first audit of the numbers.
Related
- Power BI consulting, the reporting layer this platform feeds.
- AI engineering on Azure AI Foundry, the other consumer of the curated tables.
- DevOps and infrastructure as code, how the platform gets deployed repeatably.
- All Azure services, the full engagement catalog.
Questions we get
What F-SKU capacity do we need?
We size it from measured workload rather than from a vendor table. In practice most organizations under 500 people start at F8 or F16, run the first two months with capacity metrics visible, and adjust. Capacity is pausable and resizable, so the expensive mistake is buying a reservation on an F64 before anyone has measured a refresh.
Do we still need Power BI Premium?
A Fabric capacity covers Power BI workloads, so most estates consolidate onto one capacity rather than running two. The exception is a tenant with Premium Per User licensing that suits its usage pattern. We model both before recommending, because this line item is usually the largest in the platform budget.
Can Fabric replace our existing warehouse?
Sometimes. If your warehouse is an ageing SQL Server carrying reporting logic in stored procedures, Fabric is a credible target and we migrate it. If it is a tuned platform your team runs well and your problem is really the reporting layer, replacing it is expensive theatre. We assess before recommending a replacement.
How is this different from just building a lakehouse ourselves?
You may not need us for the lakehouse. What breaks in month six is workspace and capacity governance, deployment between environments, semantic model ownership and the absence of lineage when a number is disputed. That is the part we build, and it is the part that is painful to retrofit.
Where does Purview fit?
Cataloguing, classification and sensitivity labels on the data before it feeds a report or an AI agent. It is the prerequisite nobody budgets for, and the reason AI projects stall in month two when someone asks which of these tables contains personal information.
Do we get the code?
Yes. Notebooks, pipeline definitions, semantic model definitions and the deployment pipeline configuration live in your Git repository from the first sprint. Fabric workspaces are Git-integrated, so nothing important exists only inside a portal.
Have a question about this work?
Three fields. An architect reads it and answers within one business day.