Introduction
Microsoft Fabric is an attractive platform for industrial organizations that want to bring data engineering, lakehouse architecture, real-time analytics, reporting, and AI readiness closer together.
The technology story is compelling: OneLake, Lakehouse, Warehouse, Data Pipelines, Eventstream, Eventhouse, Power BI, Git integration, deployment pipelines, and the broader Microsoft data and AI ecosystem create a strong foundation for modern analytics delivery.
But in practice, the hard part is not only adopting Fabric.
The harder question is how multiple business domains, development teams, data products, CI/CD pipelines, governance rules, support models, and business owners can work on the same platform without fragmenting into local implementations.
This post is a retrospective on a pragmatic, domain-driven data mesh model built around Microsoft Fabric and Azure DevOps. The key lesson is simple:
Fabric provides the shared technical platform. The development framework determines whether the platform scales.
The Original Business Drivers
The platform journey was not driven by technology modernization alone. The original business drivers were practical and measurable:
- faster delivery of reporting and analytics solutions
- clearer ownership of data across business domains
- migration away from legacy reporting and data platform solutions
- a healthier foundation for future AI use cases
- better reuse of curated data products across the organization
In many enterprises, analytics delivery starts as a sequence of point solutions. A team needs a report, an integration, a dataset, or a dashboard. The immediate problem is solved, but the organization often ends up with duplicated transformations, unclear ownership, inconsistent quality, and reporting logic scattered across systems.
A domain-driven platform model changes the question.
Instead of asking only:
How do we deliver this reporting need?
The organization starts asking:
Is this also a reusable data product that could serve other parts of the business?
That shift matters. It connects individual analytics demand to a broader data product portfolio.
As the platform model matures, improvements become visible across several dimensions:
| Business driver | Before | After the platform model matures |
|---|---|---|
| Reporting and analytics delivery | Each new solution planned and built from scratch | Standard workspace, CI/CD and medallion patterns make delivery repeatable |
| Data product onboarding | Ownership, documentation and development path clarified case by case | Data product definition becomes part of the project stage-gate process |
| AI use case preparation | Data discovery, quality checks and ownership clarified separately for each AI initiative | AI initiatives can start from governed, documented gold-layer data products |
| Domain ownership | Technical ownership clearer than business ownership | Domain-owned data products with clearer links to business owners and consumers |
The specific improvement depends on the organization and its maturity. The point is that a shared framework turns platform work into repeatable business capability.
A Pragmatic Data Mesh on Microsoft Fabric
The model can be described as a pragmatic data mesh implementation on Microsoft Fabric.
Business domains own their data products, backlogs, development priorities, and release decisions. A central platform team provides the shared Fabric foundation, Azure DevOps framework, CI/CD patterns, governance guardrails, documentation model, and support structure.
This is not data mesh as a slideware concept. It is a practical operating model with concrete engineering mechanisms:
- domain-owned Fabric workspaces and data products
- shared medallion architecture across domains
- Azure DevOps as the delivery coordination layer
- a monorepo for transparency and shared development patterns
- domain-specific Azure Pipelines with common deployment logic
- automated validation rules for governance controls
- a data product portal for discovery and consumption
- architecture and developer forums for cross-domain alignment
Domain-Driven Data Mesh on Microsoft Fabric
├── Platform Team (central)
│ ├── Fabric Foundation & Governance
│ ├── Azure DevOps Framework
│ ├── CI/CD Templates & Shared Pipelines
│ ├── Documentation Model & Operating Practices
│ └── Support Structure & Architecture Forums
│
├── Domain: Manufacturing
│ ├── Domain-owned Workspaces (Dev / Test / Prod)
│ ├── Medallion Layers (Bronze → Silver → Gold)
│ ├── Data Products & Backlogs
│ └── Domain-specific Pipeline & Approvals
│
├── Domain: Finance
│ ├── Domain-owned Workspaces (Dev / Test / Prod)
│ ├── Medallion Layers (Bronze → Silver → Gold)
│ ├── Data Products & Backlogs
│ └── Domain-specific Pipeline & Approvals
│
├── Domain: Sales
│ └── ...
│
└── Consumers
├── Reports & Dashboards (Power BI)
├── AI / Copilots / Agents
└── Custom Applications
The important balance is between autonomy and standardization.
Domains need enough autonomy to deliver business value. The platform team needs enough standardization to keep the overall platform understandable, secure, supportable, and scalable.
Fabric as the Strategic Platform
Choosing Microsoft Fabric early was strategically important, but it was not always easy.
Fabric was still maturing while implementation work was already underway. Some capabilities were evolving, and teams had to adapt as the product improved. This created friction, especially in the early phases.
However, the strategic value came from committing to a unified Microsoft data platform direction. Fabric provided a common target for lakehouse development, warehouse modeling, Power BI reporting, real-time analytics, and future AI capabilities.
Just as importantly, close collaboration with Microsoft field and product teams helped the implementation teams understand the platform direction, provide feedback, and navigate early maturity gaps.
In hindsight, the lesson was not that early adoption is painless. It is that early adoption can be valuable when the strategic platform direction is clear and the feedback loop with the vendor is strong.
Medallion Architecture as a Shared Domain Pattern
The medallion architecture became one of the most important shared patterns.
The bronze, silver, and gold layers created a common language for data maturity:
- Bronze keeps data close to the original source structure.
- Silver standardizes, cleanses, enriches, and prepares data for broader use.
- Gold exposes curated, business-ready data products for analytics, reporting, applications, and AI use cases.
The key was not only the technical layering. The key was repeating the same pattern from domain to domain.
Manufacturing, supply chain, finance, sales, service, product data, and industrial IoT or OT domains may have very different source systems and business semantics. But if each domain uses the same high-level development model, the platform becomes easier to operate.
A consistent medallion framework helps:
- domain developers understand where different types of logic belong
- platform teams provide reusable templates and guidance
- support teams troubleshoot similar patterns across solutions
- architects reason about dependencies and ownership
- business consumers understand which layer is intended for consumption
A single domain can always build a working solution in its own way. The challenge is scaling the model across many domains. That is where the shared medallion framework becomes valuable.
flowchart LR
subgraph Sources
S1[ERP]
S2[CRM]
S3[IoT / OT]
S4[Files & APIs]
end
subgraph Bronze["Bronze — Raw"]
B1[Source-aligned tables]
B2[Minimal transformation]
end
subgraph Silver["Silver — Enriched"]
SV1[Cleansed & standardized]
SV2[Joined & deduplicated]
end
subgraph Gold["Gold — Data Products"]
G1[Business-ready datasets]
G2[Governed & documented]
end
subgraph Consumers
C1[Power BI Reports]
C2[AI & Copilots]
C3[Applications]
end
S1 & S2 & S3 & S4 --> B1 & B2
B1 & B2 --> SV1 & SV2
SV1 & SV2 --> G1 & G2
G1 & G2 --> C1 & C2 & C3
The Gold Layer as an AI-Ready Data Product Layer
The gold layer should not be seen only as the last step before reporting.
In an AI-first world, gold-layer data products become a much more important foundation. AI solutions, copilots, agents, and custom applications are only as useful as the data foundation behind them.
If AI initiatives connect directly to fragmented source systems, each use case must separately solve data discovery, ownership, quality, semantics, access, and integration. That is slow and fragile.
When data is curated into domain-owned gold-layer data products, the starting point is healthier:
- the data has a business owner
- the semantics are closer to how the business operates
- the data product can be documented and discovered
- quality and contract expectations can be defined
- access can be governed
- the same product can serve reporting, analytics, applications, and AI use cases
In this sense, the gold layer becomes a business-ready data product layer, not merely a reporting layer.
Azure DevOps as the Delivery Operating Model
Azure DevOps became the strategic coordination layer for the whole development model.
Azure Boards made work visible. Azure Repos provided version control. Azure Pipelines handled validation, CI/CD and deployment. Azure DevOps Wiki became the home for documentation, architecture decisions, and shared operating practices.
This matters because multi-domain Fabric development is not only a technical platform problem. It is also a coordination problem.
Without an integrated delivery model, each domain can easily create its own backlog conventions, repository structure, release process, approval flow, documentation style, and definition of done.
Azure DevOps helped bring these together into one operating model:
- work management
- source control
- pull request validation
- deployment orchestration
- release approvals
- documentation
- architecture decision tracking
- portfolio visibility
In this model, Azure DevOps is not just a project management tool. It is part of the data platform architecture.
Monorepo for Transparency and Cross-Domain Coordination
The monorepo model improved transparency across domains.
All development was visible in one source control structure, while each domain still had its own folders, pipelines, and approval flows. The monorepo did not mean that one central team owned all development. It meant that everyone worked inside a shared technical framework.
This created several benefits:
- shared templates and deployment logic were easier to reuse
- cross-domain changes were easier to review
- platform-wide improvements could be introduced consistently
- dependencies were more visible
- support teams could learn one structure instead of many unrelated repositories
The monorepo was especially valuable when changes required coordinated releases across domains. Related changes could be reviewed, validated, and released as one controlled change set rather than as disconnected domain-specific deployments.
fabric-platform/ (monorepo root)
├── domains/
│ ├── manufacturing/
│ │ ├── lakehouse/
│ │ ├── warehouse/
│ │ ├── pipelines/
│ │ └── notebooks/
│ ├── finance/
│ │ ├── lakehouse/
│ │ ├── warehouse/
│ │ ├── pipelines/
│ │ └── notebooks/
│ └── sales/
│ └── ...
├── shared/
│ ├── templates/ (reusable pipeline templates)
│ ├── validation/ (shared quality checks)
│ └── governance/ (policy-as-code rules)
├── pipelines/
│ ├── manufacturing-ci.yml
│ ├── finance-ci.yml
│ └── platform-shared.yml
└── docs/
├── architecture-decisions/
└── onboarding/
Domain-Specific Pipelines with Shared Deployment Logic
One of the most important design decisions was to give each domain its own pipeline and approval flow while keeping the underlying pipeline structure consistent.
This preserved domain ownership without losing platform control.
Each domain could own its own release decision. At the same time, all domains used common Azure Pipelines patterns, shared templates, common validation logic, and consistent deployment principles.
This model separated two concerns:
- the platform defines how releases are done safely
- the domain decides when its own solution is ready to be released
Azure Pipelines and Fabric CI/CD tooling formed the core of this model. Fabric development became more repeatable when deployment, validation, and environment promotion were handled through common automation rather than ad hoc manual steps.
flowchart TD
PR["Pull Request\n(domain developer)"] --> VAL["Shared Validation\n(lint, schema, policy checks)"]
VAL --> REV["Domain Code Review\n& Approval"]
REV --> DEV["Deploy to Dev Workspace\n(automatic)"]
DEV --> TEST["Promote to Test Workspace\n(domain approval gate)"]
TEST --> PROD["Promote to Prod Workspace\n(domain + platform approval)"]
style VAL fill:#e0f0ff,stroke:#336
style DEV fill:#e6ffe6,stroke:#363
style TEST fill:#fff5e6,stroke:#663
style PROD fill:#ffe6e6,stroke:#633
Gold-Layer Development with dbt Cloud
dbt Cloud was selected for gold-layer transformation development because it supports analytics engineering practices: SQL-based transformations, dependencies between models, testing, documentation, and maintainable transformation logic.
However, tooling decisions have architectural consequences.
In a domain-driven Fabric model built around a monorepo, dbt Cloud introduced a repository strategy trade-off. dbt Cloud works best with its own repository structure, which means each domain solution received a dedicated dbt repository rather than being part of the Fabric monorepo.
The branching model followed Fabric workspace conventions: each development stage and Fabric workspace mapped to a development branch in the dbt repository. This kept dbt releases aligned with the overall Fabric deployment lifecycle while giving dbt projects the repository structure they require.
This is a good example of a broader lesson: tool choices are not only tool choices. They affect ownership, repository strategy, release management, governance, and supportability. The dbt decision was the right one for gold-layer development quality, but it required accepting that not all Fabric development could live in a single monorepo.
Data Product Portal and Discovery
A domain-driven data mesh needs discovery.
Data products should not remain hidden inside workspaces, reports, or technical documentation. Business users, developers, analysts, and future AI initiatives need a way to find what data products exist, who owns them, what they mean, and how they can be consumed.
A custom data product portal can serve this role when it is aligned with the organization’s operating model.
The portal can expose:
- data product descriptions
- domain ownership
- business purpose
- consumer guidance
- documentation links
- access request paths
- lifecycle status
- quality or contract information
Microsoft Purview, OneLake Catalog, and other Microsoft governance capabilities may also become relevant as they mature. But the key architectural point is independent of the specific catalog technology: data products must be discoverable and consumable, not only technically deployed.
Governance as Rules, Validation and Automation
Fabric does not provide an Azure Policy equivalent for every platform governance need. That means governance must be made explicit in the development framework.
A useful pattern is to describe governance rules as testable rules and then implement validation automation around them.
Examples include validation for:
- naming standards
- repository structure
- required documentation
- data product metadata
- workspace configuration
- environment consistency
- security and access patterns
- deployment readiness
- data contract expectations
Azure Pipelines can then enforce these rules in two complementary ways:
- scheduled validation runs across the platform
- pull request and release validations for every code change
The same validation logic should be reused in both places. This prevents governance from becoming only a wiki page. It becomes part of the daily developer workflow.
What Changed for Domains
As the model matured, domains could work more independently inside a shared framework.
The change was not only technical. It was also organizational.
Before the framework matured, the platform team was often involved in many implementation details: environments, pipelines, access, documentation patterns, deployment questions, and troubleshooting.
Over time, the platform team’s role started to shift from hands-on dependency toward enablement, governance, and facilitation.
This was one of the hardest changes. Reducing platform team dependency does not mean removing the platform team from the equation. It means moving the platform team toward the role of framework owner, guardrail provider, and platform enabler.
Another important change was the movement from technical domain ownership toward business data product ownership. A data product is not mature if it only has a technical owner. It also needs a business purpose, consumers, ownership, and decision-making accountability.
Communication Is Part of the Architecture
Domain-driven development does not remove the need for coordination. It increases the need for the right kind of coordination.
Several forums became important:
- regular architecture forums across domains
- developer forums across teams and vendors
- shared communication channels
- a core team connecting business initiatives, projects, and platform capabilities
One practical lesson was that private troubleshooting does not scale on a shared platform.
If deployment problems, design questions, or platform issues are solved only in private channels, other domains do not learn from them. The same problem may be solved multiple times. Decisions are not visible. Platform improvements are harder to identify.
The platform team therefore had to treat communication as part of the architecture. Problems, patterns, and decisions needed to be visible across domains, not only inside the team that first encountered them.
What Worked Well
The most successful architectural decisions were not isolated technology choices.
Fabric provided the strategic platform direction. Azure DevOps provided the delivery operating model. The monorepo improved transparency. Domain-specific pipelines preserved autonomy without sacrificing standardization. Medallion architecture provided a shared data engineering model. The data product portal made data products more visible.
The domain-driven data mesh model worked because it was supported by concrete engineering practices:
- common templates
- shared deployment logic
- standard validation patterns
- architecture forums
- developer communities
- consistent approval flows
- documented governance rules
- automated checks
Without those mechanisms, data mesh would have remained an abstract organizational idea.
Business Value Beyond Technical Modernization
The biggest business benefit was not simply that the organization adopted Microsoft Fabric.
The real value came from combining Fabric, Azure DevOps, CI/CD, medallion architecture, domain ownership, and data product thinking into one repeatable operating model.
This created value in several ways:
- reporting and analytics delivery became more repeatable
- domains gained clearer ownership of their data products
- legacy reporting and data solutions could be migrated toward a modern platform
- curated data products became reusable across the organization
- AI initiatives gained a healthier data foundation through governed gold-layer data products
- support and development practices became more consistent
What I Would Do Differently
If starting again, I would treat the development framework as a first-class platform capability from day one.
That means introducing the monorepo model and standardized Azure Pipelines release patterns early. In a multi-domain Fabric environment, consistency in source control, validation, and deployment patterns is not an implementation detail. It is the foundation for scaling development across teams.
I would also make data product thinking part of the stage-gate decision process before projects start.
Every new analytics or reporting request should be evaluated not only as a local solution need, but also as a potential reusable data product for the wider organization.
Finally, I would establish cross-domain developer forums and shared communication channels as early as possible. In a multi-vendor or multi-team environment, the communication model is part of the architecture. If issues are solved only in private channels, the platform does not learn.
Where This Could Go Next
The next phase should not be defined only by data engineering needs.
As Microsoft continues to evolve Fabric, AI platform capabilities, governance services, and application development services, the more interesting question is how domain-owned data products can become building blocks for AI-enabled business applications.
Several topics deserve deeper exploration in their own dedicated posts:
- data product lifecycle management and contract-driven development
- computational governance through validation automation
- cross-domain lineage and relationship intelligence
- self-service onboarding for new domains
- AI-ready data products and how gold-layer data can serve copilots, agents, and custom applications
- Backend-as-a-Service patterns for building custom applications on governed data products
Each of these is a substantial topic that benefits from focused treatment rather than a summary here.
Conclusion
A Microsoft Fabric-based data platform can start as a technology modernization effort. But it becomes truly valuable when it evolves into a domain-driven operating model.
Fabric provides the shared technical foundation. Azure DevOps makes development visible and governable. Medallion architecture makes data refinement repeatable. Domain ownership brings responsibility closer to the business. Governance automation keeps the model under control. Gold-layer data products make the platform valuable for reporting, analytics, AI, and future applications.
The lesson is not simply to adopt Fabric.
The lesson is to build a framework around it: a domain-driven data mesh model where multiple teams can create governed, reusable, AI-ready data products on a shared platform without losing autonomy or control.
