Forum Discussion
Microsoft Fabric for GCC data operations: how would you structure the platform for scale?
- 16 days ago
Hi kiara-mehra35,
Yes, I would use a federated model rather than having one central Fabric team own every pipeline and dataset.
Microsoft’s current Fabric deployment guidance treats workspaces as the main collaboration/security boundary, while domains can group those workspaces by business area and support delegated governance.
I would split responsibilities roughly like this:
Central Fabric/platform team: - capacity and tenant settings - workspace/domain provisioning - naming and security standards - Git / deployment pipeline patterns - shared monitoring and operational standards - reusable templates and common libraries Domain engineering teams: - ingestion pipelines - notebooks and transformations - domain-specific data-quality rules - ownership of bronze/silver/gold data products - business-specific SLAs and supportFor Dev/Test/Prod, I would keep the environments separated and use Git plus Fabric deployment pipelines for promotion rather than letting engineers modify Production directly.
Microsoft’s CI/CD guidance also recommends treating orchestration and environment-specific configuration as part of the deployment design.
For shared pipelines or data products, I would distinguish between shared platform capability and shared business logic.
For example:
common ingestion framework / logging / audit utilities -> centrally maintained Sales-specific ingestion and transformation rules -> owned by the Sales domain team trusted Customer or Product data product used by several domains -> one clearly assigned owning domain/team, with a published contract and SLAThat avoids two extremes:
central team becomes a bottleneckor
every domain invents its own standards and duplicated pipelinesI would therefore aim for centralized guardrails, decentralized ownership.
Fabric’s medallion guidance also supports separating layers and responsibilities across workspaces when that improves governance and operational ownership.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
Hi kiara-mehra35,
Thank you for reaching out to Microsoft Fabric Community.
For a Fabric environment with multiple data engineering teams, I recommend organizing workspaces by data or business domain and use separate Dev, Test and Prod environments. Use Git integration and deployment pipelines for CI/CD and establish common standards for workspace naming, ingestion, transformations, monitoring and ownership.
A Medallion architecture (Bronze, Silver, Gold) can also help keep ingestion and transformations consistent across teams. This allows teams to work independently while maintaining centralized governance and avoiding duplicated pipelines and inconsistent implementations.
Thanks and regards,
Anjan Kumar Chippa
Thanks for the guidance. I agree that domain-based workspaces, separate Dev/Test/Prod environments, and common CI/CD standards provide a good foundation for a multi-team Fabric setup.
Where I’m still curious is the governance model around that structure. In a larger GCC environment, would you recommend having a central Fabric/platform team responsible for workspace provisioning, security, monitoring and deployment standards, while individual domain teams retain ownership of their pipelines and data products?
I’d also be interested in how you would handle shared data products or pipelines that are consumed by multiple domain teams without creating duplicated logic across workspaces.
- v-achippa16 days ago
Community Support
Hi kiara-mehra35,
Yes, a central Fabric/platform team can manage workspace provisioning, security, monitoring and CI/CD standards, while individual domain teams retain ownership of their pipelines and data products.
For shared data products or pipelines, it is better to maintain the common logic in one centrally governed location and allow other domain teams to consume the resulting data product. This avoids duplicating data, pipelines, and transformation logic across workspaces while allowing each domain team to maintain ownership of its own workloads.
Thanks and regards,
Anjan Kumar Chippa