One data engineering workspace acts as the hub, containing all pipelines, lakehouses, and transformation logic. Multiple data analytics workspaces connect to it as spokes, each serving a different consuming team. Each spoke accesses the hub's Gold layer through shortcuts and builds its own semantic models and reports.
Engineering hub
- Pipelines
- Gold lakehouse
Shortcuts to the Gold layer
Finance spoke
- Semantic model
- Reports
Sales spoke
- Semantic model
- Reports
Operations spoke
- Semantic model
- Reports
Why teams move here
This scales the Split model to support multiple consumers without duplicating the engineering layer. The platform team owns the hub; consuming teams own their spokes, each with its own access controls, capacity allocation, and deployment cycle. The trade-off is coordination: more workspaces mean more shortcuts to manage, more cross-workspace dependencies to track, and more communication between hub and spoke teams.
Pros and cons
Pros
- Single source of truth. All curated data lives in one place, so consuming teams work from the same Gold layer.
- Team autonomy. Each spoke builds, iterates, and deploys without waiting on the platform team.
- Granular access control. Finance sees Finance reports, Marketing sees Marketing reports, and no one stumbles into another team's work in progress.
- Independent capacity and billing. Allocate more capacity to priority teams, or charge back costs by department.
- Scales horizontally. A new consuming team means a new spoke and a shortcut. The hub doesn't change.
Cons
- Shortcut proliferation. Every spoke needs shortcuts to the hub, and the number to create, maintain, and audit grows with each one.
- Hub becomes a bottleneck. If the platform team is slow to deliver tables or fix data quality, every spoke is blocked.
- Limited cross-spoke visibility. Two teams needing to share assets or collaborate first have to figure out where something lives and who owns it.
- Coordination overhead. A schema change in the hub can break multiple downstream workspaces at once.
- Growing governance complexity. More workspaces mean more to audit, more capacity to monitor, and more deployment pipelines to manage.
Where this fits
- Central BI platform serving multiple business units. A platform team owns engineering; Finance, Marketing, Operations, and Sales each have their own analytics workspace sourced from the same trusted data.
- Regulated data with multiple consumer groups. The hub restricts access to the engineering layer; each spoke gets only the aggregated, compliant views it's authorised to see.
- Multi-region deployment. One central hub with spokes for EMEA, APAC, and the Americas, each with localised reports and capacity while sharing the same underlying data.
When this breaks down
- Different domains need fundamentally different source systems or engineering logic, and one hub can't serve them all
- Spoke teams want to own their own data engineering, not just analytics
- The platform team can't keep up with demand from all the spokes
- Cross-domain data products need tighter integration than shortcuts can cleanly support
When you hit these limits, Domain mesh topology is the natural next step.
Considerations
- Define the hub-to-spoke contract. Be explicit about which tables, which refresh cadence, and which quality guarantees the hub provides.
- Establish a change notification process. Schema changes affect every spoke, so build a communication channel with advance warning before breaking changes land.
- Standardise spoke setup. A template or checklist for new spokes keeps naming, folder structure, default roles, and monitoring consistent.
- Monitor the hub closely. It's a single point of failure; alert on pipeline failures, data quality issues, and capacity contention.
- Plan for spoke lifecycle. Have a process for decommissioning spokes, including cleaning up shortcuts and reclaiming capacity.