18.12 Enterprise Multi-Cloud Architecture
1. Reference architecture
SAP APPLICATIONS CLOUD WAREHOUSES OBJECT STORAGE
| | |
+-----------+-----------+----------------------+
|
integration layer
|
+----------+----------+
| |
federation replication
| |
+----------+----------+
|
DATASPHERE
|
+-----------+-----------+
| |
enterprise semantics data products
| |
+-----------+-----------+
|
SAC / BI / APIs
2. Platform ownership
Define one owner for each layer:
| Layer | Example responsibility |
|---|---|
| Source | operational correctness |
| Integration | movement and reliability |
| Datasphere | harmonization and semantics |
| Governance | classification and policy |
| Consumption | business experience |
3. Multi-cloud principles
Principle 1 — Do not copy by default
Copy data only when the copy provides measurable value.
Principle 2 — Keep semantics close to ownership
Business definitions should have an accountable domain owner.
Principle 3 — Separate raw from governed
A raw landing area is not an enterprise semantic product.
Principle 4 — Design failure domains
Every external source can fail independently.
Principle 5 — Measure freshness
"Near real time" is not an architecture requirement until translated into a measurable SLA.
4. Architecture trade-offs
Centralized Datasphere
Pros:
- common semantics,
- governance,
- reusable data products.
Cons:
- central dependency,
- possible bottleneck,
- cross-domain ownership complexity.
Federated domains
Pros:
- domain autonomy,
- local ownership.
Cons:
- duplicated semantics,
- governance complexity,
- inconsistent definitions.
A hybrid model is often appropriate.
5. Architect capstone
Design an enterprise platform containing:
- S/4HANA,
- BW/4HANA,
- HANA Cloud,
- Redshift,
- Oracle,
- SQL Server,
- S3,
- SaaS APIs,
- Datasphere,
- SAC.
Your architecture must define:
- source ownership,
- integration pattern,
- persistence,
- semantic ownership,
- security,
- monitoring,
- recovery,
- cost controls,
- retirement strategy.