Data science roadmap

Hi powerbidev123,

One lesson I would emphasise is that OneLake being logically unified does not mean the organisation should treat everything as one unrestricted data area.

I would structure the environment around clear business domains and use workspaces as the main operational and security boundaries. For example, Finance, Marketing and Customer Analytics could each have dedicated workspaces, with Fabric domains grouping related workspaces and allowing governance responsibilities to be distributed appropriately. Microsoft also recommends using dedicated workspaces for data domains and managing access, cost visibility and operational policies at the workspace level.

Some practical considerations I would plan for are:

1. Avoid unnecessary duplication: OneLake shortcuts are useful when data already exists in another OneLake location, ADLS or supported external storage. They allow teams to access the same data through a unified namespace without creating another physical copy. However, shortcut ownership, credentials and downstream dependencies should still be documented carefully.

2. Separate raw, curated and consumption layers: I would use a medallion-style structure:

• Bronze for raw ingested data
• Silver for validated and standardised data
• Gold for business-ready data products

Microsoft identifies the medallion lakehouse pattern as the recommended design approach for organising data in OneLake.

3. Design security before onboarding users: Workspace roles alone can become too broad if they are used as the only access-control mechanism. I would apply least privilege, use security groups rather than assigning individuals repeatedly, and decide where access should be controlled at workspace, item, folder, table, row or column level. OneLake security roles now provide more granular control, but the complete permission path still needs to be tested because workspace and workload permissions can interact.

4. Treat governance as an operating process: Naming standards, ownership, endorsement, sensitivity labels, lineage and data-product responsibilities should be defined before the estate becomes large. The OneLake Catalog can provide a central view of Fabric items, permissions and governance state, while Microsoft Purview can support broader discovery and governance requirements.

5. Monitor capacity from the beginning: OneLake storage and data operations still affect cost and capacity consumption. I would monitor workspace-level consumption, throttling and workload peaks through the Fabric Capacity Metrics app rather than waiting until users report slow performance.

A common mistake is to focus only on getting data into OneLake and postpone ownership, security and lifecycle decisions. It is much harder to introduce consistent governance after many teams have already created their own workspaces, lakehouses, shortcuts and permission patterns.

My suggested starting point would be:

• Define the business domains and owners.
• Establish workspace and naming standards.
• Design the Bronze, Silver and Gold data-product flow.
• Define access using groups and least privilege.
• Create a shortcut and duplication policy.
• Configure lineage, endorsement and governance monitoring.
• Establish capacity and cost-monitoring responsibilities.

I would be interested to hear whether others have found workspace sprawl, permission complexity or capacity management to be the biggest challenge in their own implementations.