Data and Analytics on Microsoft Azure
Data and analytics on Microsoft Fabric and Azure
Microsoft Fabric puts ingestion, engineering, warehousing, real-time analytics and Power BI on one governed footprint over OneLake, which removes much of the copying that used to sit between those layers. That matters most if your organisation already runs Microsoft 365, Entra ID and Power BI, because identity, sensitivity labels and a large part of the licensing are already in place. We design the tenant, capacity and workspace structure first, then build the pipelines, models and reports on top of it.
Why Azure
When this is the right platform.
- OneLake gives every Fabric workload a single storage layer in Delta format, so a warehouse table, a Spark notebook and a Power BI semantic model can read the same data without a separate copy being made for each tool.
- Where Microsoft 365 and Power BI are already licensed, the identity model, sensitivity labels and sharing behaviour your users know carry straight across, which shortens the adoption work considerably.
- Power BI remains the strongest fit when finance and operations teams want to build their own reports against a governed semantic model rather than raising a ticket for every question.
- Microsoft Purview covers cataloguing, lineage and sensitivity classification across Fabric and the wider Microsoft estate, so governance is not a separate product decision made later.
- Direct Lake storage mode lets Power BI read Delta tables in OneLake without a scheduled import refresh, which suits large models previously constrained by the length of the refresh window.
Where it is less suited
We would rather say this now than after a migration.
- Fabric capacity is a shared pool. One badly written notebook or an over-frequent refresh can throttle unrelated workspaces sharing that capacity, so workload isolation and consumption monitoring need deliberate design rather than defaults.
- The platform moves quickly. Features change behaviour between releases and some capabilities reach general availability later than the announcement implies, so we build against current behaviour and avoid depending on preview features unless you accept that risk in writing.
- Direct Lake has conditions attached, including model size and query patterns that can cause a fallback with a noticeable performance difference. It suits many models but it is not a universal replacement for import mode.
- If your organisation has little existing Microsoft 365 or Power BI footprint, much of the licensing and adoption advantage does not apply, and the platform should be judged on its technical fit alone.
Business outcomes
What Azure delivers here.
- Reporting consolidated onto one platform
- Teams currently spread across Excel, on-premises reporting services and standalone Power BI files work from shared workspaces and a single semantic model. The measure agreed up front is how many production reports resolve to that model rather than a private extract.
- Refresh windows stop constraining the business
- Analysts no longer plan around a nightly import that takes hours, because Direct Lake reads the Delta tables in OneLake directly. We baseline current refresh duration and report the change once the model has been migrated.
- Capacity cost you can attribute
- Platform owners see which workspaces and workloads consume Fabric capacity units, so an over-refreshed model or a runaway notebook can be found and fixed. Success is a monthly capacity report with an agreed utilisation threshold that triggers a review.
- Sensitivity handled once and honoured everywhere
- Labels applied through Microsoft Purview travel with the data into Power BI and into exports, so a confidential dataset stays marked when someone downloads it to Excel. Coverage is measured as the proportion of production datasets carrying both an owner and a label.
- Operational data available the same day
- Fabric Real-Time Intelligence handles event streams from plant, fleet or application telemetry so exception dashboards update through the day instead of overnight. Latency targets are agreed per measure before anything is built.
Common client problems
What we usually hear first.
We have Power BI everywhere and no idea which report is the official one
We audit the tenant for workspaces, semantic models and reports, identify duplicates and orphaned content, and consolidate the survivors onto shared models in governed workspaces. Publishing rights are then tightened so personal workspaces stop quietly becoming production.
Someone told us we should move from Power BI Premium to Fabric and nobody can explain what actually changes
We map your current capacity, workloads and refresh patterns against Fabric capacity behaviour, including how bursting and smoothing affect what you are billed. You get a written comparison naming the workloads that benefit, the ones that do not, and a migration sequence with effort attached.
Our data still sits in an on-premises SQL Server and reporting runs off a nightly copy
We assess whether each workload belongs in Azure SQL Database, a Fabric warehouse or a lakehouse, based on query pattern, latency need and how the application writes to it. Ingestion is then built with Fabric Data Factory and the on-premises source stays in place until the new reports reconcile.
We already run Databricks and we are not throwing that away
You do not need to. We keep Azure Databricks where the heavy engineering and machine learning work already lives, surface its curated Delta output into OneLake through shortcuts, and use Fabric and Power BI for the serving and reporting layer.
Every new report request turns into a three-week project
That is usually a modelling problem rather than a capacity problem. We build a governed semantic model with the measures the business argues about already defined and tested, so most new questions become a report an analyst builds in an afternoon.
How we deliver
Our Azure delivery approach.
- 01
Assessment and advisory
The Azure assessment is largely about what you already own. Most Microsoft-centred organisations are paying for more analytics capability than they are using, so the plan starts with what can be recovered before anything new is bought.
- Audit the Power BI tenant: workspaces, semantic models, reports, refresh failures, gateway dependencies and content nobody has opened in ninety days.
- Review current licensing and capacity, including the Fabric or Power BI Premium capacity in use, utilisation patterns and where throttling or bursting is already occurring.
- Catalogue source systems and existing pipelines across Azure Data Factory, SQL Server Integration Services packages, on-premises gateways and manual extracts.
- Establish where Microsoft Purview is already deployed and what classification, lineage and label coverage exists in practice rather than on paper.
- Compare a Fabric-first design against retaining Azure Databricks, existing Azure Synapse Analytics workloads or Azure SQL Database, with cost and effort attached to each option.
- Define the success measures for the first release, including refresh reliability, data latency and the specific reports to be retired.
- 02
Architecture and implementation
We settle tenant, capacity and workspace structure before the first pipeline is built, because retrofitting workspace boundaries and naming afterwards is expensive and disruptive. The first business domain then goes end to end into production.
- Define tenant settings, capacity assignment and a workspace structure separating development, test and production, with Fabric deployment pipelines between them.
- Land raw data into OneLake through Fabric Data Factory, using shortcuts to Azure Data Lake Storage or existing Delta tables instead of copying files where a shortcut will do.
- Build cleansing and conformance in Fabric Data Engineering notebooks or dataflows, with the code held in Git and peer reviewed before promotion.
- Serve curated data through a Fabric Data Warehouse or a lakehouse SQL endpoint, chosen on whether consumers write T-SQL or read through the semantic model.
- Build the Power BI semantic model with explicit measures, hierarchies and Direct Lake storage mode where table size and query pattern actually suit it.
- Stand up Fabric Real-Time Intelligence with Azure Event Hubs only for the measures that need sub-hour latency, and leave everything else on batch.
- 03
Security and governance
Fabric inherits Microsoft Entra ID and Microsoft Purview, which makes these controls straightforward to implement and equally easy to leave at their defaults. We configure them as part of the build, not after it.
- Grant workspace and item access through Entra ID security groups mapped to roles, with no standing access held by individual named accounts.
- Apply row-level and object-level security in the semantic model and test it with a representative account for each role before the report is released.
- Configure Microsoft Purview sensitivity labels so classification applies inside Fabric and persists into Power BI exports to Excel and PDF.
- Scan Fabric and its source systems into the Purview data map so a reported measure can be traced back through its lineage on request.
- Restrict tenant settings covering publish to web, external sharing and unmanaged personal workspaces, and document every approved exception.
- Enable Fabric and Power BI activity auditing and forward it to the log destination the security team already reviews.
- 04
Adoption and enablement
Power BI's real strength is that business users can answer their own questions. That only works when the model underneath is trustworthy and someone has shown them how to use it properly.
- Run separate sessions for report consumers, self-service authors and the small group who will maintain the shared semantic model.
- Apply the certified and promoted endorsement standard in the tenant so endorsed datasets are visibly distinguishable from someone's working draft.
- Provide a written measure dictionary explaining each certified measure in plain language, with its refresh schedule and its owner.
- Agree retirement dates for the spreadsheets and legacy reports being replaced, and confirm reconciliation with the owner before switching them off.
- Set up a request path for new measures, with a review step deciding whether a request extends the shared model or belongs in a personal report.
- Review workspace usage metrics after launch and revisit any content with no viewers over an agreed period.
- 05
Managed service continuation
Capacity consumption, refresh reliability and semantic model performance all drift as usage grows and as the platform releases change. We watch them and act before users notice.
- Monitor pipeline and semantic model refresh outcomes, alerting on failures, skipped runs and refreshes exceeding an agreed duration.
- Track capacity unit consumption by workspace and workload, identify throttling events and recommend resizing or workload separation.
- Tune slow models and reports, including partitioning, measure rewriting and moving tables between import and Direct Lake where the evidence supports it.
- Manage upstream schema changes and Fabric platform updates, testing the impact on downstream models in a non-production workspace first.
- Review Purview label coverage, workspace permissions and tenant settings on an agreed cycle and report any drift from the approved baseline.
- Report monthly on refresh reliability, data quality test results, report usage and capacity cost against the measures agreed at the start.
Technology reference
The Microsoft Azure services we build with.
A reference architecture view of the platform services used in this domain, and what each one does in the design.
Lakehouse foundation
Microsoft FabricThe platform we standardise on for Microsoft-centred clients, so ingestion, engineering, warehousing and reporting share one capacity, one security model and one deployment pipeline.
OneLakeThe single storage layer every Fabric workload reads and writes, which lets us shortcut to data already held elsewhere instead of creating a copy per tool.- Azure Data Lake StorageWhere an existing raw landing zone already sits. We normally keep it and expose it into OneLake through a shortcut rather than migrating the files.
Ingestion and data engineering
Fabric Data FactoryPipeline orchestration and copy activity for source ingestion, including incremental loads, watermarking and retry behaviour for sources that fail intermittently.
Fabric Data EngineeringSpark notebooks and lakehouse tables for cleansing, conformance and the transformations that are clearer expressed in code than in a low-code flow.
Azure DatabricksRetained where heavy engineering or machine learning workloads already run, with curated Delta output surfaced into OneLake for the serving layer.
Operational and streaming sources
Azure SQL DatabaseThe transactional store behind line-of-business applications we ingest from, and occasionally the target when a workload needs relational behaviour rather than analytical scale.
Azure Cosmos DBSource for document and high-throughput operational data, ingested into the lakehouse rather than queried directly by reports.
Azure Event HubsIngestion point for telemetry, device and application event streams before they reach real-time analytics.
Serving, modelling and reporting
Fabric Data WarehouseThe T-SQL serving layer for teams and third-party tools that expect a warehouse and connect over SQL.
Fabric Real-Time IntelligenceEvent stream processing and querying for the measures that must be current within minutes, such as production exceptions or dispatch delays.
Fabric Data ScienceNotebook-based modelling and experiment tracking for forecasting work that stays inside the same governed platform as the data it uses.
Power BIThe semantic model and reporting layer, where agreed measures are defined once, secured by role and consumed by self-service authors.
Governance and cataloguing
Microsoft PurviewCataloguing, lineage and sensitivity classification across the Fabric estate and the source systems feeding it, so ownership and access are documented rather than assumed.
Product names and icons are trademarks of Microsoft and Amazon Web Services, reproduced unmodified from their official architecture icon libraries to identify the technologies used in these architectures. Their presence does not indicate partnership, certification or endorsement by either vendor.
Related industries
Where this work has the most leverage.
Manufacturing and Distribution
Demand and inventory intelligence, production analytics and supplier automation built on data your planners already trust.
Professional Services
Governed enterprise search, document intelligence and secure copilots that respect matter confidentiality and conflict boundaries.
Construction and Property
Tender intelligence, addenda tracking and project reporting that keep estimators and contract administrators ahead of the documents instead of buried in them.
Free discovery workshop
Start with a data and analytics discovery workshop.
Bring one challenge. We will assess whether Microsoft Azure is the right platform for it before recommending anything.