Phase 02 — Platform & Tenant Architecture
Architectural objective: move from knowing what SAP Datasphere is to understanding how a real Datasphere tenant is structured, governed, secured, and operated.
Phase 01 established the mental model.
This phase establishes the platform boundary.
You will learn to answer:
- What is a Datasphere tenant?
- What belongs at tenant level versus space level?
- Why are spaces the primary isolation boundary?
- How do global roles differ from scoped roles?
- Who can create and administer spaces?
- How should storage and compute be allocated?
- How should spaces be organized by domain, environment, or workload?
- How does one space consume data from another?
- When should objects be shared?
- How should development, test, and production be separated?
- How do standard spaces differ from file spaces?
- How should an enterprise design its space topology?
The goal is not to memorize the UI.
The goal is to understand the architecture behind the UI.
2.1 The platform mental model
At the highest level, think about SAP Datasphere as four nested architectural layers:
SAP Business Data Cloud / Enterprise Data Platform
│
▼
DATASPHERE TENANT
│
┌────────────┼────────────┐
│ │ │
Security Lifecycle Platform
& Roles & Transport Operations
│ │ │
└────────────┼────────────┘
▼
SPACES
│
┌────────────┼────────────┐
│ │ │
Connections Data Objects Users
│ │ │
└────────────┼────────────┘
▼
Integration / Modeling
│
▼
Consumption
A tenant is the overall Datasphere environment.
A space is a controlled working environment inside that tenant.
A useful rule is:
Tenant establishes the platform boundary. Space establishes the data and workload boundary.
SAP describes spaces as secure areas where data acquisition, preparation, and modeling occur. Data is not available outside a space unless it is shared or exposed for consumption.
2.2 What is a Datasphere tenant?
A Datasphere tenant is the organization's managed Datasphere environment.
It provides the platform boundary within which administrators configure:
- users
- roles
- spaces
- connectivity
- storage
- compute characteristics
- monitoring
- lifecycle capabilities
- security
- integration capabilities
The tenant is therefore much larger than a database schema.
A beginner may think:
Tenant = Database
A better mental model is:
Tenant
├── Identity and security
├── Global roles
├── Scoped roles
├── Spaces
├── Connectivity
├── Storage and compute
├── Monitoring
├── Lifecycle
└── Data workloads
SAP's administration guidance places users, roles, connectivity, spaces, resource allocation, and monitoring at the tenant administration level.
2.3 Tenant versus space
| Concern | Tenant | Space |
|---|---|---|
| Overall platform | Yes | No |
| Users and global roles | Yes | Scoped through roles |
| Create spaces | Yes | No |
| Data objects | Through spaces | Yes |
| Connections | Platform capability + space assignment | Used by space users |
| Data isolation | Platform boundary | Primary data boundary |
| Storage allocation | Tenant capacity | Space allocation |
| Workload management | Tenant configuration | Space/process policies |
| Cross-domain sharing | Through space architecture | Explicit sharing |
| Ownership | Enterprise/platform | Domain/team |
A strong architect must know which problem belongs at which level.
2.4 The space is the fundamental Datasphere boundary
A space is simultaneously:
- a modeling boundary
- a data-access boundary
- a user-assignment boundary
- an ownership boundary
- a workload boundary
- a sharing boundary
- a governance boundary
That makes space design an architecture decision, not merely an administration task.
2.5 Why spaces exist
Imagine an enterprise with:
- Finance
- Procurement
- Sales
- Supply Chain
- HR
- Customer
- Corporate
Putting everything into one space creates a very large blast radius.
A domain-oriented topology can instead establish boundaries:
FINANCE
PROCUREMENT
SALES
SUPPLY_CHAIN
HR
CUSTOMER
However:
One business department does not automatically mean one space.
Space boundaries should be driven by meaningful differences in:
- ownership
- security
- lifecycle
- workload
- integration
- data classification
- operating team
- reuse
2.6 The space topology spectrum
Extreme A — One giant space
ONE_ENTERPRISE_SPACE
├── Finance
├── Procurement
├── Sales
├── Supply Chain
├── HR
└── Customer
Advantages:
- simple initial administration
- fewer cross-space dependencies
- easy object discovery
Disadvantages:
- weak isolation
- difficult ownership boundaries
- larger blast radius
- harder security design
- competing workloads
Extreme B — Space explosion
Finance_GL
Finance_AP
Finance_AR
Finance_TAX
Procurement_PO
Procurement_PR
Procurement_VENDOR
...
Advantages:
- strong isolation
Disadvantages:
- administrative overhead
- excessive sharing
- more dependencies
- harder lifecycle management
- fragmented architecture
The enterprise architect's job is to find the useful middle.
2.7 A better space-design rule
Instead of asking:
"How many spaces should we create?"
ask:
- Who owns the data?
- Who can modify it?
- Who can consume it?
- What security boundary exists?
- What workload boundary exists?
- What lifecycle boundary exists?
- What should be reusable?
- What must remain isolated?
- What should be shared?
- What should never be shared directly?
This produces a much better topology.
2.8 Standard spaces and file spaces
Current Datasphere architectures need to distinguish between standard spaces using SAP HANA Database storage and file spaces using SAP HANA Data Lake Files.
Standard space
A standard space is the primary environment for conventional Datasphere modeling and warehousing workloads.
Typical capabilities include:
- local tables
- remote tables
- views
- data flows
- analytic models
- data access controls
- graphical modeling
- SQL modeling
- consumption
File space
A file space uses SAP HANA Data Lake Files storage and is intended primarily for large-volume, lower-cost staging and preparation.
SAP documents the object store as an inbound layer for staging large quantities of data cost-effectively. File spaces can receive data through replication flows and use Apache Spark transformation flows for preparation before data is shared to standard spaces.
2.9 Standard space versus file space
| Capability | Standard space | File space |
|---|---|---|
| HANA Database storage | Yes | No |
| HANA Data Lake Files | No | Yes |
| Local tables | Yes | Local tables (file) |
| Views | Yes | No |
| Data flows | Yes | No |
| Analytic models | Yes | No |
| Data access controls | Yes | No |
| Replication flows | Supported | Supported as target pattern |
| Apache Spark transformation flows | Not the primary model | Yes |
| Large staging workloads | Possible | Strong use case |
| Semantic consumption layer | Yes | No |
| Typical role | Modeling and consumption | Inbound staging and preparation |
A file space is not simply a cheaper standard space.
It has a different architectural role.
2.10 Object-store architecture
A useful pattern is:
External Sources
│
▼
Replication Flow
│
▼
FILE SPACE
SAP HANA Data Lake Files
│
▼
Spark Transformation Flow
│
▼
Prepared File Table
│
▼
Share
│
▼
STANDARD SPACE
│
├── Views
├── Data Flows
├── Semantic Models
└── Analytic Models
SAP documents file spaces as staging/preparation environments and explicitly describes sharing file tables to standard spaces for use by flows, views, and analytic models.
2.11 File-space limitations
A file space is not another full modeling space.
Current SAP documentation states that file spaces cannot create several conventional modeling objects, including:
- views
- data flows
- data access controls
- analytic models
- E/R models
- Business Builder content
Therefore the common architecture is:
FILE SPACE
↓
Stage / Prepare
↓
Share
↓
STANDARD SPACE
↓
Model / Secure / Consume
Do not force the semantic architecture into the file space.
2.12 Tenant resource architecture
Tenant capacity can involve:
- storage
- memory
- vCPU capacity
- performance class
- optional data lake storage
- optional elastic compute
- availability configuration
SAP currently documents performance classes including Memory, Compute, High-Memory, and High-Compute, with supported storage and memory combinations depending on configuration and hyperscaler.
Therefore:
Never hard-code sizing numbers into an enterprise standard without checking current SAP sizing guidance.
2.13 Tenant capacity versus space allocation
Think about capacity at two levels:
TENANT CAPACITY
│
├── Memory
├── Compute
├── Disk
└── Optional data lake
│
▼
SPACE ALLOCATION
│
├── Finance
├── Procurement
├── Sales
└── Enterprise Shared
The tenant defines the overall envelope.
Space design determines how workloads are organized within that envelope.
For FinOps, this distinction matters.
If Procurement grows aggressively, first ask:
- what workload is growing?
- is the workload justified?
- is data being persisted unnecessarily?
- are queries inefficient?
- is the storage tier appropriate?
- should historical data use a different pattern?
- should staging use the object store?
- is the workload competing with other domains?
2.14 Memory and disk: architectural thinking
A simplified conceptual model is:
HOT DATA
│
├── Frequently queried
├── Recent
├── Performance sensitive
└── Memory-oriented
│
▼
WARMER DATA
│
├── Less frequently queried
├── Historical
└── Disk-oriented
SAP documents memory storage for frequently accessed and mission-critical data, while disk can hold master data and less recent transactional data to reduce storage costs.
The architect should ask:
"Does this data need to be constantly hot?"
rather than:
"Can I put everything in memory?"
2.15 Workload isolation
Consider these workloads:
- executive reporting
- operational monitoring
- large batch transformation
- massive replication
- exploratory SQL
- data science preparation
They do not necessarily have the same resource profile.
A good topology makes workload contention visible:
TENANT
│
┌────────┼────────┐
│ │ │
Enterprise Domain Staging
Shared Spaces Spaces
│ │ │
Semantic Finance File Space
Assets Sales Object Store
Procurement
2.16 Users and identity
Access is constructed through:
USER
│
▼
ROLE
│
├── Global privileges
│
└── Scoped privileges
│
▼
SPACE
A user may have:
- tenant-wide administration capability
- modeling capability in one space
- viewer capability in another
- no access to a third space
SAP's scoped-role model explicitly supports users having different roles in different spaces.
2.17 Global roles
Global roles apply across the tenant.
They are appropriate for responsibilities such as:
- tenant administration
- user management
- role management
- space creation
- catalog administration
- platform-level administration
SAP's current standard roles include System Owner and DW Administrator, plus space-oriented role templates.
Architectural principle:
Use global privileges only when the responsibility genuinely spans the tenant.
2.18 Scoped roles
A scoped role applies a role's privileges to selected spaces and users.
Conceptually:
ROLE TEMPLATE
│
▼
SCOPED ROLE
│
┌────┴────┐
│ │
Users Spaces
│ │
└────┬────┘
▼
Effective Access
For example:
DW Modeler
│
├── Finance
└── Procurement
The same person could be:
Finance → Modeler
Sales → Viewer
HR → No Access
SAP documents this exact principle for scoped roles.
2.19 Why scoped roles matter
Without scoped roles, organizations tend to create excessive global permissions.
That creates:
- larger blast radius
- unnecessary access
- weaker segregation of duties
- difficult auditability
- harder offboarding
With scoped roles:
PRIVILEGE
+
SCOPE
+
USER
=
CONTROLLED ACCESS
This is much closer to an enterprise least-privilege model.
2.20 Standard roles you should understand
At minimum, understand the intent of:
System Owner
Extremely privileged tenant-level role.
Use sparingly.
DW Administrator
Tenant administration around users, roles, spaces, and platform administration.
DW Space Administrator
Space-level administration.
DW Modeler
Modeling-oriented access.
DW Integrator
Integration-oriented access.
DW Viewer
View-oriented access to relevant space content.
DW Consumer
Consumption-oriented access for users who do not need the Datasphere modeling environment.
SAP's current standard-role documentation distinguishes tenant administration roles, space-oriented roles, and consumption-oriented roles.
2.21 Space administrator versus tenant administrator
Tenant administrator
Thinks about:
- the entire tenant
- users
- roles
- spaces
- resource allocation
- platform configuration
- global administration
Space administrator
Thinks about:
- assigned space
- space users
- space configuration
- data access controls
- connections
- objects
- integration tasks
- space operations
SAP documents that only administrators can create spaces, allocate storage, and set space priority and statement limits, while space administrators manage assigned spaces.
2.22 Space ownership
Every production space should have explicit ownership.
Recommended metadata:
| Attribute | Example |
|---|---|
| Space ID | PROC_CORE |
| Business owner | Procurement Data Owner |
| Technical owner | Data Engineering |
| Security owner | Data Governance |
| Platform owner | Datasphere Platform Team |
| Criticality | High |
| SLA | 15 minutes |
| Consumers | SAC, AFO |
| Source systems | S/4HANA, supplier DB |
| Data classification | Confidential |
This turns a technical space into an accountable enterprise asset.
2.23 Naming strategy
Naming helps:
- monitoring
- security reviews
- automation
- troubleshooting
- support
- lifecycle management
Example:
PROC_CORE
PROC_STG
PROC_SHARED
FIN_CORE
FIN_STG
SALES_CORE
ENTERPRISE_SHARED
Avoid:
TEST1
NEW_SPACE
TEMP
SPACE_FINAL
SPACE_FINAL2
Temporary names become permanent surprisingly often.
2.24 Technical ID versus business name
A space has a business name and a technical identifier.
The technical ID matters in:
- Open SQL schema contexts
- monitoring
- automation
- APIs
- CLI operations
- troubleshooting
SAP documents constraints on technical space IDs and notes that the ID cannot be changed after creation.
Therefore:
Treat the technical space ID as an architectural identifier.
2.25 Space deployment state
A space is not simply "created and done."
The lifecycle is:
Design
↓
Configure
↓
Save
↓
Deploy
↓
Runtime
This matters during troubleshooting.
If configuration looks correct in design time but runtime behavior does not match, ask:
Was the change actually deployed?
SAP documents deployment status and the need to save and redeploy changes before they are available to space users.
2.26 Connections and spaces
A connection should not be treated as an isolated technical object.
Think:
SOURCE SYSTEM
│
▼
CONNECTION
│
▼
SPACE
│
▼
DATA ACQUISITION
The architecture question is:
Which space owns the integration relationship?
For example:
S/4HANA Procurement
│
▼
PROC_CORE
rather than allowing every space to independently connect to the same source without governance.
2.27 Central integration versus domain-owned integration
Pattern A — Central integration
S/4HANA
│
▼
INTEGRATION
│
├── Finance
├── Procurement
└── Sales
Advantages:
- centralized connectivity
- reusable acquisition
- centralized monitoring
- consistent extraction
Risks:
- central bottleneck
- ownership ambiguity
- larger blast radius
- excessive sharing
Pattern B — Domain-owned acquisition
S/4HANA
│ │ │
▼ ▼ ▼
FIN PROC SALES
Advantages:
- clear ownership
- domain autonomy
- localized troubleshooting
Risks:
- duplicated connections
- duplicated extraction
- inconsistent source logic
The correct choice depends on governance and scale.
2.28 Shared-data architecture
Datasphere supports controlled sharing of supported objects between spaces.
Conceptually:
SOURCE SPACE
│
│ share
▼
CONSUMER SPACE
│
├── Further modeling
└── Consumption
SAP states that tables and views can be shared to other spaces and used as sources for further modeling and consumption.
2.29 Sharing is an architecture decision
Before sharing an object, ask:
- Is it stable?
- Is its grain documented?
- Is the owner known?
- Is its security classification understood?
- Is the consumer authorized?
- Should a view be shared instead of a raw table?
- Is row-level security required?
- Is it intended as a reusable data product?
- Will downstream consumers depend on it?
- What happens if it changes?
A shared object creates a dependency.
Therefore:
Treat a shared object like an API contract.
2.30 Prefer stable contracts
Suppose a raw procurement table is shared with five downstream spaces.
A column rename can break multiple consumers.
A more stable pattern is:
PROC_CORE
│
├── Raw acquisition
├── Harmonized tables
└── Published semantic view
│
▼
Consumer spaces
The published view becomes the contract.
2.31 Cross-space architecture
A large enterprise may use:
TENANT
│
┌──────────────┼──────────────┐
│ │ │
FINANCE PROCUREMENT SALES
│ │ │
└──────────────┼──────────────┘
│
ENTERPRISE SHARED
│
▼
CONSUMPTION
Avoid creating a fully connected graph of spaces.
A dense sharing graph becomes difficult to govern.
Prefer:
Domain Spaces
│
▼
Shared / Published Layer
│
▼
Consumption
where justified.
2.32 Data-product thinking
A mature organization moves from:
"Here is a table."
to:
"Here is a governed data product."
A data product should have:
- owner
- business definition
- grain
- quality expectations
- security classification
- freshness SLA
- lineage
- supported consumers
- change policy
Example:
PROCUREMENT SPEND DATA PRODUCT
│
├── Owner
├── Definition
├── Grain
├── Measures
├── Dimensions
├── Refresh SLA
├── Security
├── Quality
└── Consumers
Governance and data products are covered deeply in Phase 15.
2.33 Development, test, and production
A mature landscape should distinguish environments:
DEVELOPMENT
│
▼
TEST / QA
│
▼
PRODUCTION
Possible patterns include:
Pattern A — Separate tenants
DEV TENANT
TEST TENANT
PROD TENANT
Strong isolation.
Higher administration and cost.
Pattern B — Separate spaces
ONE TENANT
│
├── DEV
├── TEST
└── PROD
Simpler.
Weaker tenant-level isolation.
Pattern C — Domain and environment
PROC_DEV
PROC_TEST
PROC_PROD
FIN_DEV
FIN_TEST
FIN_PROD
Clearer domain ownership but more spaces.
There is no universal answer.
2.34 How to choose environment topology
| Requirement | Architectural implication |
|---|---|
| Strict regulatory isolation | Consider tenant separation |
| Strict release controls | Strong environment separation |
| Small team | Simpler topology may be sufficient |
| Many domains | Domain-oriented spaces |
| High data sensitivity | Stronger isolation |
| Strong cost sensitivity | Avoid unnecessary tenant proliferation |
| Independent operating teams | Stronger ownership boundaries |
Architecture must reflect the operating model.
2.35 Sharing versus transport
These concepts are different.
Sharing
Runtime data/object accessibility between spaces.
Transport
Moving design-time content between environments or tenants.
Think:
SHARING
Space A ─────────► Space B
runtime dependency
TRANSPORT
DEV ─────────► TEST ─────────► PROD
lifecycle movement
Do not use sharing as a replacement for environment promotion.
2.36 Security boundary model
A simplified security model is:
TENANT
│
├── Identity
├── Global Roles
└── Scoped Roles
│
▼
SPACE
│
├── Object permissions
├── Data access controls
├── Sharing
└── Exposure
A user being able to log into the tenant does not imply access to every space.
2.37 Space access is not row-level security
These solve different problems.
Space membership
Answers:
Can this user access the space?
Object permissions
Answers:
Can this user work with this object?
Data access control
Answers:
Which rows can this user see?
Therefore:
SPACE ACCESS
↓
OBJECT ACCESS
↓
ROW ACCESS
This distinction becomes essential in Phase 14.
2.38 Example: regional procurement security
Suppose:
GLOBAL PROCUREMENT
│
├── Europe
├── Americas
└── Asia
A user may be allowed into the Procurement space but should only see Asia.
The architecture can combine:
- space access
- object permissions
- data access controls
Do not create dozens of spaces merely to solve row-level security.
Conversely, do not use row-level security to solve a true organizational isolation requirement.
2.39 Enterprise space topology pattern
A useful starting architecture is:
DATASPHERE TENANT
│
┌────────────────────────┼────────────────────────┐
│ │ │
SHARED / PLATFORM DOMAIN SPACES STAGING
│ │ │
│ ┌─────────┼─────────┐ │
│ │ │ │ │
│ FINANCE PROCUREMENT SALES FILE SPACE
│ │ │ │ │
└──────────────┼─────────┼─────────┼──────────────┘
│ │ │
▼ ▼ ▼
Semantic / Published Data
│
▼
SAC / AFO / APIs
This is a conceptual pattern, not a mandatory SAP template.
2.40 Enterprise shared space: use carefully
A shared space can be useful for:
- common dimensions
- enterprise reference data
- calendar
- currency
- controlled master data
- reusable semantic contracts
But it can also become "the new giant space."
Avoid putting every reusable object into a shared area.
A shared layer should have strict ownership.
2.41 Workload management
As usage increases, workload management becomes important.
Typical workload categories:
- ingestion
- transformation
- replication
- interactive query
- persistence
- analytical consumption
A production architecture should monitor:
- long-running statements
- memory pressure
- expensive statements
- storage consumption
- failed tasks
- concurrent workloads
- space-level utilization
SAP provides monitoring for system and space performance, storage, tasks, and related issues.
2.42 Capacity planning
Capacity planning should follow:
Business Volume
+
Data Volume
+
Concurrency
+
Transformation Complexity
+
Retention
+
Freshness SLA
↓
Resource Requirement
Not:
"We have 500 GB of data, therefore we need X GB."
Data volume alone is not sufficient.
2.43 Space sizing is not only storage sizing
A space can create pressure through:
- large persisted datasets
- inefficient transformations
- high query concurrency
- poor join design
- excessive replication
- unnecessary copies
- long-running tasks
- badly designed semantic models
Therefore:
Resource allocation and workload engineering must be considered together.
2.44 Space deletion is a major operation
Deleting a space is not harmless cleanup.
SAP documents that deleting a space permanently deletes the space, its content, and its data from the database.
Therefore:
- production deletion should be tightly controlled
- ownership must be clear
- dependencies must be reviewed
- recovery expectations must be understood
- automation needs guardrails
2.45 CLI and automation
Enterprise administration is not limited to the UI.
SAP provides a Datasphere command-line interface for operations such as managing spaces.
This matters for:
- repeatable provisioning
- automation
- CI/CD
- governance
- environment setup
- operational scripts
Think:
Manual UI
↓
Repeatable Procedure
↓
Automation
↓
Controlled Platform Engineering
2.46 Architect decision: one tenant or multiple tenants?
Prefer one tenant when:
- domains share governance
- security can be handled with spaces
- common platform operations are desired
- lifecycle can be centrally managed
- workloads can coexist safely
Consider multiple tenants when:
- strict isolation is required
- independent operating organizations exist
- regulatory constraints require stronger separation
- lifecycle policies must be completely independent
- contractual boundaries require separation
Multiple tenants increase:
- administration
- integration complexity
- lifecycle complexity
- monitoring complexity
- cost considerations
Therefore:
Do not create multiple tenants merely because multiple teams exist.
2.47 Architect decision: one space or many?
Create a separate space when at least one of these is materially different:
- ownership
- security
- lifecycle
- workload
- integration
- data classification
- operating team
- reuse boundary
Avoid a separate space when the only reason is:
- different table
- different report
- different developer
- temporary experiment
- naming preference
2.48 Architect decision matrix
| Requirement | Likely direction |
|---|---|
| Strict tenant isolation | Multiple tenants |
| Domain ownership | Multiple spaces |
| Row-level security only | Data access controls |
| Shared reusable data | Controlled object sharing |
| Large staging | File space |
| Semantic modeling | Standard space |
| Production release separation | Environment separation |
| Global administration | Tenant-level role |
| Domain administration | Scoped role |
| Consumption only | Consumer-oriented access |
These are starting points, not automatic answers.
2.49 Reference enterprise architecture
Consider a global company with:
- S/4HANA Finance
- S/4HANA Procurement
- Salesforce
- external supplier data
- BW/4HANA historical data
- SAC consumption
A possible topology:
DATASPHERE TENANT
│
┌───────────────────────┼───────────────────────┐
│ │ │
PLATFORM / SHARED DOMAIN SPACES OBJECT STORE
│ │ │
│ ┌─────────┼─────────┐ │
│ │ │ │ │
│ FINANCE PROCUREMENT SALES FILE SPACE
│ │ │ │ │
│ └─────────┼─────────┘ │
│ │ │
│ Published Data ◄─────────────┘
│ │
└───────────────────────┼────────────────────────
▼
Analytic Models
│
▼
SAC / AFO / APIs
The topology is intentionally modular.
2.50 Mapping BW/4HANA knowledge
If you come from BW/4HANA, a useful bridge is:
| BW/4HANA | Datasphere |
|---|---|
| System landscape | Tenant / platform landscape |
| InfoArea/domain organization | Space/domain organization |
| ADSO | Local table / persistence pattern |
| Transformation | Data flow / transformation pattern |
| Process Chain | Task chain |
| Open ODS / virtualization | Remote or virtual access patterns |
| CompositeProvider | Semantic/analytical modeling patterns |
| Authorization concept | Roles + scoped access + data access controls |
| Transport | Datasphere lifecycle/transport mechanisms |
These are learning bridges, not 1:1 equivalents.
Use them to understand the architecture, then learn Datasphere-native behavior.
2.51 Mapping Native HANA knowledge
If you come from Native HANA:
| Native HANA | Datasphere |
|---|---|
| Schema | Not equivalent to a space |
| Calculation View | Graphical/SQL modeling patterns |
| Virtual table | Remote access patterns |
| Table persistence | Local table / persisted view patterns |
| HANA user/role | Datasphere tenant/scoped role model |
| SQLScript | SQL modeling capabilities |
| PlanViz | Datasphere has different performance tooling |
Again:
Use the analogy to learn, not to replace the Datasphere mental model.
2.52 The five boundaries every architect should identify
For every Datasphere solution, explicitly document:
1. Tenant boundary
Who owns the platform?
2. Space boundary
Who owns the data and workload?
3. Object boundary
Which objects are reusable?
4. Security boundary
Who can access which data?
5. Environment boundary
How does content move from development to production?
This five-boundary model is a useful architecture-review framework.
2.53 Space-design anti-patterns
Anti-pattern 1 — One giant space
Everything is placed together.
Anti-pattern 2 — Space per table
Creates fragmentation.
Anti-pattern 3 — Global admin for developers
Violates least privilege.
Anti-pattern 4 — Raw table sharing everywhere
Creates unstable dependencies.
Anti-pattern 5 — No owner
Nobody is accountable.
Anti-pattern 6 — Production as a development sandbox
Destroys lifecycle discipline.
Anti-pattern 7 — File space used as semantic layer
Wrong architectural role.
Anti-pattern 8 — Multiple tenants without justification
Creates unnecessary operational complexity.
Anti-pattern 9 — No workload governance
One workload can affect everyone.
Anti-pattern 10 — No resource monitoring
Capacity problems become incidents.
2.54 Architect exercise
Scenario
A multinational enterprise has:
- 4 S/4HANA systems
- 2 BW/4HANA systems
- Salesforce
- Oracle supplier system
- 8 business domains
- 400 analytics users
- 40 modelers
- 10 integration engineers
- strict regional data restrictions
- SAC as the primary consumption platform
- near-real-time operational analytics
- large historical data
Your task
Design:
- Tenant strategy
- Space strategy
- Role strategy
- Domain ownership
- Shared-data strategy
- File-space strategy
- Environment strategy
- Resource allocation strategy
- Security boundary
- Monitoring strategy
Then defend:
- Why did you choose this number of spaces?
- Why not one space?
- Why not one tenant per domain?
- Which data is shared?
- Which data remains isolated?
- Which data belongs in a file space?
- Who can create spaces?
- Who can administer spaces?
- Who can model?
- Who can consume?
- How do you prevent global privilege sprawl?
2.55 Hands-on lab
Lab 1 — Design a space topology
Create:
Tenant
│
├── Shared
├── Finance
├── Procurement
├── Sales
├── Staging
└── Consumption
For every space document:
- purpose
- owner
- users
- data
- source systems
- security
- expected workload
- storage pattern
- consumers
Lab 2 — Design role assignments
Create a matrix:
| User group | Global role | Finance | Procurement | Sales |
|---|---|---|---|---|
| Platform Admin | Admin | Admin | Admin | Admin |
| Finance Modeler | None | Modeler | None | None |
| Procurement Modeler | None | None | Modeler | None |
| Sales Analyst | None | Viewer | Viewer | Viewer |
| Business Consumer | Consumer | Consume | Consume | Consume |
Then challenge your own design:
Can any user access more than necessary?
Lab 3 — Design cross-space sharing
Create:
PROCUREMENT
│
├── Supplier Master
├── Purchase Orders
└── Spend Semantic View
│
▼
FINANCE / SALES
Decide which objects should be shared.
Explain why.
Lab 4 — File-space architecture
Design:
External Source
↓
Replication Flow
↓
File Space
↓
Spark Transformation Flow
↓
Prepared File Table
↓
Shared
↓
Standard Space
↓
Analytic Model
Document:
- why staging is separate
- why semantic modeling occurs in the standard space
- which data is retained
- how data is monitored
- how failures are handled
2.56 Troubleshooting framework
When a user says:
"I cannot see the table."
Do not immediately assume the table is missing.
Check:
1. Is the user in the correct tenant?
↓
2. Is the user assigned to the correct space?
↓
3. Does the role contain the required privilege?
↓
4. Is the object in that space?
↓
5. Was the object shared?
↓
6. Is the object deployed?
↓
7. Is consumption exposure configured?
This is much faster than randomly changing permissions.
2.57 Troubleshooting: user cannot edit
Check:
- space membership
- role assignment
- scoped role
- Data Builder privileges
- object state
- deployment state
- ownership
- whether the object is shared from another space
The key question is:
Which authorization layer is blocking the operation?
2.58 Troubleshooting: space is slow
Do not immediately increase resources.
Check:
- expensive statements
- memory pressure
- concurrent workloads
- large persisted views
- inefficient joins
- unnecessary replication
- excessive data movement
- partitioning needs
- transformation design
- consumer query patterns
Performance engineering becomes a dedicated topic in Phase 12.
2.59 Troubleshooting: storage is growing unexpectedly
Investigate:
Storage Growth
│
├── Local tables
├── Persisted views
├── Replicated copies
├── Historical retention
├── File-space data
└── Temporary / intermediate datasets
Then ask:
Which data has business justification for persistence?
2.60 Production readiness checklist
Ownership
- Business owner defined
- Technical owner defined
- Support owner defined
Security
- Scoped roles defined
- Least privilege reviewed
- Data classification defined
- Data access controls considered
Integration
- Connections documented
- Source ownership documented
- Freshness SLA documented
Data
- Grain documented
- Retention documented
- Persistence strategy documented
- Sharing strategy documented
Operations
- Monitoring configured
- Failure handling defined
- Capacity reviewed
- Workload priority defined
Lifecycle
- Development environment defined
- Test process defined
- Production promotion defined
- Recovery expectations defined
2.61 Architect interview preparation
What is a space in SAP Datasphere?
A secure environment in Datasphere where data acquisition, preparation, and modeling occur. Space membership and permissions establish important data and workload boundaries.
What is a scoped role?
A role whose privileges are applied to selected spaces and users, allowing the same user to have different responsibilities in different spaces.
Who creates a space?
Tenant administrators with the required global privileges create spaces and allocate resources.
What is the difference between a standard space and a file space?
A standard space supports conventional Datasphere modeling and warehousing capabilities using SAP HANA Database storage. A file space uses SAP HANA Data Lake Files and is designed for large-volume staging and preparation.
How do spaces share data?
Supported entities such as tables and views can be shared from one space to another, creating controlled cross-space dependencies.
Is space access the same as row-level security?
No. Space access determines whether a user can work with the space. Data access controls can further restrict which rows a user can see.
Should every domain have its own space?
Not automatically. Domain ownership is one input. Security, workload, lifecycle, integration, reuse, and operational boundaries must also be considered.
One tenant or multiple tenants?
Use multiple tenants only when isolation or organizational requirements justify the additional administration and operational complexity.
What is the biggest mistake in space design?
Treating space design as an administrative naming exercise instead of an enterprise boundary decision.
2.62 Architect checkpoint
You should now be able to explain:
Tenant
↓
Roles
↓
Spaces
↓
Users
↓
Connections
↓
Objects
↓
Sharing
↓
Security
↓
Consumption
↓
Monitoring
If you cannot explain why each boundary exists, revisit the architecture sections before moving forward.
2.63 Final mental model
Remember:
The tenant is the platform. The space is the operating boundary. The role is the permission model. Sharing is the dependency mechanism.
A mature Datasphere architecture therefore looks like:
TENANT
│
┌──────────┴──────────┐
│ │
PLATFORM GOVERNANCE SECURITY
│ │
└──────────┬──────────┘
│
SPACES
│
┌────────────────┼────────────────┐
│ │ │
DOMAIN SHARED STAGING
SPACES DATA / FILE
│ │ │
└────────────────┼────────────────┘
│
SEMANTIC DATA
│
▼
CONSUMPTION
The most important architectural principle is:
Design spaces around meaningful boundaries, not around technical objects.
2.64 What comes next
Phase 03 — Data Integration Architecture
The next phase moves from platform topology into integration architecture:
- source-system patterns
- connections
- remote access
- federation
- replication
- ingestion architecture
- SAP and non-SAP integration
- latency decisions
- source-system impact
- integration ownership
- data movement decisions
- architecture trade-offs
- integration reference architectures
Phase 11 will later provide the deep implementation treatment of:
- Data Flows
- Transformation Flows
- Replication Flows
- Task Chains
The concepts will be introduced earlier, but Phase 11 is where they become a full engineering discipline.