Workspace planning strategies and design models - DataWorks - Alibaba Cloud - DataWorks

Learn how to plan DataWorks workspaces for different scenarios based on permission models and organizational needs.

Workspace permission models

Permission isolation levels vary across the main services in DataWorks:

Service	Permission model
Workspace management	Workspaces are completely isolated from each other. You configure member roles and compute engine instance settings independently for each workspace. Note The owner of every workspace is an Alibaba Cloud account.
DataStudio	Data development is completely isolated between workspaces. Workflows and nodes are developed independently in each workspace and do not affect each other. Within a workspace: Only members with the Developer or Workspace Manager role can create, edit, or delete nodes. Only members with the Developer, O&M, or Workspace Manager role can commit deployment packages. Only members with the O&M, Deployer, or Workspace Manager role can deploy to the production environment. Note You can configure scheduling dependencies for nodes across workspaces.
Operation Center	O&M is partially isolated between workspaces. Real-time, periodic, and manually triggered node operations are isolated within each workspace. Only members with the Developer, O&M, or Workspace Manager role can perform them. The Overview page is isolated within each workspace and displays summary data about node runs. The Alarm feature is shared across workspaces, allowing you to create baselines that monitor nodes in multiple workspaces. Only an Alibaba Cloud account or members with the Workspace Manager role can create baselines.
Data Map	Data Map is shared by all workspaces within a tenant. In Data Map, you can search for and view the metadata of all workspaces within the current tenant and region. Note Only metadata is shared. Read and write permissions to the actual data are not shared. Typically, read and write permissions in a development environment are shared among members with the Developer role, while data permissions in a production environment are exclusive to the production account.
Data Quality	Data Quality is completely isolated between workspaces. Only members with the Developer, O&M, or Workspace Manager role can configure data quality monitoring rules in a workspace.
DataService Studio	DataService Studio is partially isolated between workspaces. API group definitions are shared across workspaces, but APIs registered or published in a workspace are visible only within that workspace.
Data Security Guard	Data Security Guard is Global Sharing. Workspaces share a set of data security rules and sensitivity levels. If you set the Access Mode parameter to Safe, only members with the Safety Manager role can perform operations in Data Security Guard.

Workspace planning strategies

Plan workspaces based on your company's departments, business projects, or data warehouse layers, or use a hybrid approach:

Dimension	By department	By business project	By data warehouse layer
Basis	Align workspace organization with your company's organizational structure. For example, create workspaces for departments such as production, marketing, human resources, and finance. Each workspace handles data development and table management for its department.	Organize workspaces based on specific business projects. For example, create workspaces for projects such as the Quarterly Sales Sprint, Production Safety Inspection, and Executives Cockpit Report. Each workspace ingests data from multiple business systems and processes it to support the project.	Structure workspaces according to the layers of your data warehouse. Each layer can have one or more dedicated workspaces. For example, you can create workspaces for data layers such as the data access layer, operational data store (ODS) layer, and data warehouse summary (DWS) layer.
Scenarios	Suitable when departmental business needs are straightforward, team members have development skills, and cross-departmental data sharing is minimal.	Suitable for high-priority, business-driven projects that require collaboration across multiple departments.	Suitable for large-scale data warehouses, enterprise-level common data layers, and data middle-platform architectures.
Advantages	Team composition aligns with the organizational structure, ensuring stability and data security. Cost attribution for compute and storage is straightforward.	Each workspace has a focused business scope. Teams can be assembled dynamically based on project needs, and data lineage is clear.	The data architecture is clear and data sharing is straightforward. Development skills and resource allocation can be tailored to the characteristics of each layer.
Disadvantages	Can lead to data silos, resulting in duplicate computation and storage, complex cross-workspace dependencies, and potential resource contention.	The overall data architecture can become unclear, with inconsistent business logic across projects. Fluid team composition within workspaces can increase data security risks.	Can lead to longer development cycles and extended maintenance pipelines. In standard mode, deploying an upstream node to production may require code changes in downstream nodes.
Architecture stability	★★★★★	★☆☆☆☆	★★★★★
Personnel flexibility	★☆☆☆☆	★★★★★	★★★★☆
Business complexity	★★☆☆☆	★★★★☆	★★★☆☆
Data security	★★★★★	★★☆☆☆	★★★☆☆
Maintainability	★★☆☆☆	★★★★★	★★☆☆☆
Data sharing	★★★☆☆	★☆☆☆☆	★★★★★

You can combine these strategies into a hybrid model. A common approach is to organize workspaces by data warehouse layer and then subdivide each layer into multiple workspaces.

Data access layer (STG): Organize by source application system, such as stg_marketing_system or stg_production_management_system.
- Nodes: Contain only Data Integration nodes.
- Tables: Store only raw data with a short time to live (TTL).
- Members: Database administrators (DBAs) from the respective source application systems.
- Resource focus: Resource groups for Data Integration and storage space.
Operational data store (ODS) layer: Organize by department, such as ods_human_resources or ods_production. Data is standardized within each department, and sensitive information is cleaned or masked.
- Nodes: Contain only SQL nodes with a single input and a single output.
- Tables: Consist of ODS layer tables.
- Members: Data cleansing specialists assigned by each department.
- Resource focus: Resource groups for scheduling for early time windows (for example, 00:00 to 02:00) and compute engine resources.
Data warehouse summary (DWS) layer: Consolidate into a single workspace or organize by business domain, such as dws_customer_domain or dws_product_domain.
- Nodes: Contain only SQL nodes with multiple inputs and a single output.
- Tables: Consist of DWS layer fact tables and dimension tables.
- Members: Dedicated developers for the common data layer.
- Resource focus: Resource groups for scheduling for mid-range time windows (for example, 02:00 to 05:00), compute engine resources, and storage to handle data growth.
Tag data model (TDM) layer: Consolidate into a single workspace or organize by business object.
- Nodes: Contain only SQL nodes with multiple inputs and a single output.
- Tables: Consist of tag tables.
- Members: Dedicated developers for the common data layer.
- Resource focus: Resource groups for scheduling for later time windows (for example, 05:00 to 07:00), compute engine resources, and storage to handle data growth.
Application data store (ADS) layer: Organize by business project, creating a separate workspace for each specific business initiative.
- Nodes: Contain SQL nodes and Data Integration nodes.
- Tables: Focus on tables that directly support business applications.
- Members: Members of the project team.
- Resource focus: Resource groups for scheduling for the latest time windows (for example, 07:00 to 09:00), compute engine resources, and resource groups for Data Integration.