Pros

• Clear ownership boundaries Data engineering and analytics work happen in distinct spaces. Teams know where their responsibilities start and end. Ownership disputes reduce because the workspace boundary makes accountability explicit.

• Independent access control You can give analysts access to the DA workspace without exposing engineering assets. Contractors or business users can view reports without seeing pipeline code or raw lakehouse data.

• Capacity isolation Each workspace can sit on different capacity, or you can monitor consumption separately even if they share capacity. Heavy pipeline runs won't directly starve report rendering, and vice versa.

• Independent deployment cycles Separate workspaces mean separate deployment pipelines. You can push a report fix to production without waiting for pipeline changes to be ready, or deploy engineering updates without touching the analytics layer.

• Cleaner audit trail Workspace-level activity logs become more meaningful. You can see who accessed what in each domain without filtering through unrelated activity.

 

Cons

• Shortcut management overhead The DA workspace needs shortcuts to access lakehouse tables from the DE workspace. These shortcuts must be created, and if table structures change upstream, downstream assets can break.

• Cross-workspace dependency tracking Changes in the DE workspace can impact the DA workspace in ways that aren't immediately visible. Renaming a table, changing a schema, or moving an item can break semantic models downstream. You need lineage visibility or good communication habits to manage this.

• Two security models to maintain Instead of one workspace role assignment, you now manage two. Users who need access to both workspaces need roles in both. This is manageable at small scale but adds overhead as team size grows.

• More infrastructure to govern Two workspaces means two sets of settings, two deployment pipelines, two capacity assignments to monitor. The operational surface area increases.

 

Example Scenarios

• Distinct engineering and analyst roles Your organisation has a clear split between people who build pipelines and people who build reports. Engineers don't need to see report development in progress; analysts don't need access to raw data or transformation logic. The workspace boundary matches the team boundary.

• Contractor or external access requirements You bring in external consultants to build reports, but you don't want them accessing your data engineering layer. A separate DA workspace lets you grant access to semantic models and reports only.

• Capacity chargeback to different cost centres Engineering workloads are funded by IT; analytics workloads are funded by the business. Separating workspaces makes it easier to track and allocate capacity costs to the right budget.

• Independent release cycles Your data pipelines release weekly, but reports need hotfixes on demand. Decoupling the workspaces lets each team deploy at their own pace without blocking the other.

• Regulatory or compliance separation Audit requirements mandate that access to raw data is restricted and logged separately from access to aggregated reports. Workspace separation provides a clean boundary for compliance purposes.

 

When This Topology Breaks Down

• You have multiple consuming teams with different access needs (one DA workspace isn't enough)

• Different business units want their own report development space without sharing with other units

• You need to scale the number of analytics workspaces without duplicating the engineering layer

• Cross-functional teams need to work across both engineering and analytics in a blended way (the hard boundary becomes friction)

When you hit these limits, Hub and Spoke Topology is the natural next step.

 

Considerations

• Shortcut strategy matters Decide early whether shortcuts point to the Gold layer only, or whether analysts can shortcut into Silver for exploratory work. Document the contract between workspaces so both teams know what's stable and what's subject to change.

• Establish a change communication process Schema changes in DE can break DA assets. Whether it's a shared changelog, a Teams channel, or a formal release process, you need a way for engineers to signal breaking changes before they happen.

• Monitor both workspaces Capacity isolation is only useful if you're watching both. Set up monitoring for each workspace so you can catch contention early and make informed decisions about capacity allocation.

• Consider naming conventions across workspaces With two workspaces, naming consistency becomes more important. A clear convention (e.g. domain-de-dev, domain-da-dev) helps users and automation find the right workspace quickly.