You create two workspaces: one for data engineering (pipelines, lakehouses, transformation logic) and one for data analytics (semantic models, reports, dashboards). The analytics workspace references data from the engineering workspace through shortcuts or Direct Lake connections.
Engineering workspace
- Pipelines
- Lakehouse
Shortcut or Direct Lake
Analytics workspace
- Semantic models
- Reports
Why teams move here
This is the natural evolution from Starter topology once you need to separate concerns. Engineers and analysts get their own space, with different capacity, access controls, and deployment cycles each. The trade-off is managing the connection between them: shortcuts need to be created and maintained, and changes upstream can ripple into downstream analytics assets.
Pros and cons
Pros
- Clear ownership boundaries. Engineering and analytics work happen in distinct spaces, so accountability is explicit.
- Independent access control. Analysts get the DA workspace without exposure to engineering assets or raw lakehouse data.
- Capacity isolation. Each workspace can sit on different capacity, so heavy pipeline runs don't starve report rendering.
- Independent deployment cycles. Push a report fix without waiting for pipeline changes, or the reverse.
- Cleaner audit trail. Workspace-level activity logs become meaningful without filtering through unrelated activity.
Cons
- Shortcut management overhead. The DA workspace needs shortcuts into DE lakehouse tables, and upstream schema changes can break them.
- Cross-workspace dependency tracking. A rename or schema change in DE can silently break semantic models downstream.
- Two security models to maintain. Users who need both workspaces need roles assigned in both.
- More infrastructure to govern. Two workspaces mean two sets of settings, deployment pipelines, and capacity assignments.
Where this fits
- Distinct engineering and analyst roles. A clear split between people who build pipelines and people who build reports, matching the workspace boundary to the team boundary.
- Contractor or external access. External consultants build reports without ever touching your data engineering layer.
- Capacity chargeback. Engineering is funded by IT, analytics by the business, and separating workspaces makes cost allocation cleaner.
- Regulatory separation. Audit requirements mandate that raw data access is restricted and logged separately from aggregated reports.
When this breaks down
- You have multiple consuming teams with different access needs, and one DA workspace isn't enough
- Different business units want their own report development space, without sharing with others
- 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, and the hard boundary becomes friction
When you hit these limits, Hub and spoke topology is the natural next step.
Considerations
- Decide your shortcut strategy early. Should shortcuts point to Gold only, or can analysts shortcut into Silver for exploratory work? Document the contract.
- Establish a change communication process. Schema changes in DE can break DA assets. A shared changelog or release process gives engineers a way to signal breaking changes.
- Monitor both workspaces. Capacity isolation only helps if you're watching both sides for contention.
- Use consistent naming. A convention such as domain-de-dev and domain-da-dev helps people and automation find the right workspace fast.