Architectures Design Strategy

Sunil Singh

April 7, 2026 • Updated November 2026

20 min read

Architecture hub

Architecture decisions that define your SAP analytics stack

SAP analytics architecture is not a product diagram. It is a responsibility model across five decision surfaces: where your semantic layer lives, how planning architecture is shaped, where integration stops and extension begins, how governance and access control work, and what path modernization takes. In 2026, these decisions carry greater weight than ever—zero-copy data sharing, event-driven integration, and master data governance have reshaped where and how analytics assets should live. Each decision affects system behavior, team operations, governance risk, and your ability to adopt emerging patterns like Joule agents, model stacking, and federated governance. This hub provides decision frameworks grounded in current SAP product capabilities as of November 2026.

The five architecture decisions

Most blocked SAP analytics programs are not missing features. They are missing clarity on these five decisions. Architecture quality improves when you treat each surface separately before designing integration.

Decision sequencing: Which to make first?

The order matters. Start with governance and control (Decision 4), then semantic ownership (Decision 1), then planning architecture (Decision 2). Integration and extension boundaries (Decision 3) become clearer once you know where data lives and how it flows. Finally, sequence your modernization path (Decision 5) based on what you learned. This sequence prevents rework and ensures decisions compound rather than contradict.

Step 1 (Governance first): Decide on access control and lifecycle rules. This shapes everything downstream.
Step 2 (Semantic ownership): Choose whether semantics live in Datasphere, BW, or SAC. Once locked in, migration is costly.
Step 3 (Planning architecture): Design planning models and their connection to source systems. Depends on semantic ownership choice.
Step 4 (Integration boundaries): Define where cross-system plumbing happens. Clearer once you know the destination (semantic layer + planning model).
Step 5 (Modernization path): Last decision. You now know the target architecture and can sequence the migration approach.

Decision 1: Where should the semantic layer live?

The semantic layer is where business meaning becomes canonical. A "customer," a "revenue transaction," a "cost center" — these concepts need a single, governed definition that downstream applications and teams can depend on. In 2026, you have three distinct choices, and the choice shapes everything downstream.

SAP Datasphere Analytic Models

The strategic destination. Datasphere spaces are the governed home for semantic ownership. Spaces manage resource allocation, storage quotas, and access boundaries. Analytic models support dimensions, hierarchies, measures, and row-level security via Data Access Controls (DACs); sensitive columns stay out of general models and are exposed only in restricted views. Custom data products package governed data for sharing (Data Product Studio, announced for GA in H1 2026, has no confirmed GA yet; BDC data product governance added terms, steward approval, and access agreements in September 2026). Datasphere publishes to SAC, Business Data Cloud, and external platforms via BDC Connect zero-copy sharing, and SAP plans BDC data products inside Joule Studio for GA in Q1 2027. With the Reltio acquisition now closed (announced March 2026, completed May 7, 2026) and SAP Reltio in SAP Business Data Cloud generally available, master data governance becomes a first-class semantic concern, not an afterthought.

BW InfoProviders

Still in active use at many enterprises. BW InfoProviders such as advanced DSOs and CompositeProviders remain valid for organizations with heavy BW investments; SAP plans to support BW/4HANA to at least the end of 2040 through successive releases. In SAP Business Data Cloud, SAP BW, private cloud edition is SAP's strategic route for running existing BW; SAP BW bridge (no OLAP engine) remains for staging and business content. Migration to Datasphere is gradual, not forced.

SAC Import Models

Useful for small, self-contained use cases where semantic scope is narrow and reuse across teams is not expected. Import models store data directly in SAC and support planning input. However, they are consumption-optimized, not governance-optimized — calculations defined in stories stay in each story, and the model's semantics can't be reused outside SAC. Use for departmental analytics, not enterprise semantic layers.

Architecture recommendation: Datasphere Spaces are the long-term strategic choice for semantic ownership. They provide governed access control, dimension-based row-level security (via DACs), resource isolation, and reusability across SAC, BDC, and external platforms; keep sensitive columns in restricted views. In practice (composite examples): A retailer with SAP and Snowflake data science moves its semantic layer to Datasphere, publishes core metrics as data products, and shares them zero-copy to Snowflake for ML model training—no more manual ETL. A financial services organization uses DACs tied to cost-center dimensions to enforce regional regulatory boundaries across a federated analytics structure. Use BW (SAP BW, private cloud edition in BDC, or BW/4HANA) only for coexistence during modernization. Never use SAC import models as enterprise semantic layers — this creates consumption coupling and breaks reusability. Analytic model stacking in Datasphere (since 2025.08) layers models on top of each other and inherits their definitions, which supports layered governance patterns.

Read deeper: Where the semantic layer should live

Decision 2: How should planning architecture be shaped?

Planning models face a different set of requirements than reporting models. They need input capability, version management, approval routing, and the ability to store plan data separate from actuals. SAP offers two approaches, and the choice depends on your connection strategy.

SAC Model with Measures + Seamless Planning

The modern approach. With seamless planning, an SAC planning model built on the new model type (with measures) stores its fact and master data in a Datasphere space, while SAC keeps the model structure, calculations, and planning processes. It needs SAC on SAP HANA Cloud and a 1:1 link between the SAC and Datasphere tenants, runs in the Optimized Design Experience, and supports the full planning workflow: input, versions, multi-currency, allocations, and approvals. Actuals can come from Datasphere as live versions instead of imports.

Classic Account Model

The legacy approach. The classic account model has a single measure and a mandatory account dimension. It is still supported, but SAP recommends models with measures for new builds, and classic account models can't be deployed to Datasphere for seamless planning. Keep it only where existing content depends on it.

External Live Data Access

SAC live data access to Snowflake (since 2026 QRC1), Google BigQuery, and Azure SQL (since 2026 QRC2) runs through the data access agent: fact data is read at runtime as read-only live versions, while model structure, master data, and plan data stay in SAC. Databricks data is reachable through BDC Connect (GA since October 2025). Both enable blended planning that combines SAP actuals with external forecast or simulation results without physically replicating the external data first.

Architecture recommendation: Choose models with measures and, where Datasphere is your data platform, seamless planning: plan data then lives next to actual data in Datasphere, without dual storage. Use live versions for read-only actuals and planning models for input. Cost and complexity: Seamless planning reduces data duplication; planning functionality is licensed through SAC users, while storage and compute for planning are licensed through Datasphere capacity units. Writeback authorization and version control still need careful access design. When data science workloads run in Snowflake, Databricks, or Google BigQuery, use SAC live data access or BDC Connect to keep planning models connected without manual ETL—critical for collaborative forecasting. Tabular predictions from SAP-RPT-1.6 (SAP-RPT-1 retires by December 31, 2026) can bring ML outputs closer to the planning layer. Retire classic account models where you can—they add operational complexity in modern landscapes. In a composite example, a manufacturer replaces Excel-based planning sprawl by centralizing supply-chain plans in a seamless planning model, with demand forecasts read live from Snowflake—a single source of truth and shorter plan revision cycles.

Read deeper: SAP Analytics Cloud topic

Decision 3: Where does integration stop and extension begin?

Many teams blur integration and extension into one delivery stream, weakening design and operations. The boundary is clear: if it transforms or routes data, it is integration. If it adds business logic or UI, it is extension.

SAP Integration Suite (Integration)

The strategic middleware for moving data between systems. Cloud Integration (formerly CPI) handles transformation, routing, and orchestration of messages. API Management governs API lifecycle, security, and rate limiting. Event Mesh enables event-driven, real-time patterns, with advanced event mesh for high volumes. Open Connectors provides 160+ pre-built connectors for non-SAP systems like Salesforce, Workday, ServiceNow, Shopify, and others, alongside native adapters. SAP Business Data Cloud (BDC) Connect provides zero-copy sharing with Databricks, Snowflake, and Google BigQuery without data movement overhead. This is where integration logic lives.

SAP BTP (Extension)

The runtime for custom applications, workflow, and business logic. Cloud Foundry and Kyma provide compute for custom microservices. SAP Build enables low-code application development, and SAP Build Process Automation handles approval routing and orchestration. If you are building a custom approval process triggered by an analytic event, or a custom UI layer on top of analytics data, it lives in BTP — not in integration.

The Boundary

Data flows through Integration Suite. Business logic and UX run on BTP. A scenario: External partner shipment data arrives via Integration Suite (Cloud Integration + Open Connectors), is mapped to SAP logistics definitions in Datasphere (integration), then triggers a custom approval workflow in BTP that notifies supply chain managers (extension). Integration suite handles the connection. BTP handles the decision-making and routing.

Architecture recommendation: Separate integration and extension into different teams and delivery streams. Integration Suite (Cloud Integration + Event Mesh + Open Connectors) handles all data movement, transformation, and event routing. BTP (Cloud Foundry, Kyma, SAP Build, and SAP Build Process Automation) handles all custom logic, approvals, and specialized UX. Do not build custom adapters in BTP when Integration Suite has a pre-built connector. Do not try to route events through Cloud Integration when Event Mesh is designed for the job.

Read deeper: Integration vs platform extension boundaries

Decision 4: How should governance and access control work?

Governance architecture is often an afterthought, bolted on after deployment. In modern SAP landscapes, access control and lifecycle management should be designed alongside the semantic and planning models.

Data Access Controls (DACs) in Datasphere

Row-level security defined through a permissions entity (a table or view of user IDs and authorized values) mapped to dimension columns. If you have a dimension "Cost Center" with values 1000, 2000, 3000, the permissions entity can restrict a user to Cost Center 1000; to manage roles instead of individuals, join a user-role table to a user table in a view and use that view as the permissions entity. DACs filter rows, not columns: keep salary data, price points, or customer identifiers out of general models and expose them only in restricted views. DACs are the first defense in semantic layer security.

SAC Tenant Strategy

Multi-tenant architecture with dev/test/prod separation. Content lifecycle is managed through a combination of manual transport and SAP Cloud Transport Management (cTMS), which carries SAC content network packages. cTMS allows you to define nodes (dev, test, prod), create transport routes between them, and execute controlled promotions. This replaces ad-hoc file uploads with governed pipelines.

Content Network and Story Versions

SAC's content network moves content packages (stories, models, and other objects) between tenants. Since 2026 QRC1, optimized stories also keep up to 10 file versions that owners can restore. Use packages and folders to separate certified content from work in progress, so teams consume a certified version while developers iterate on the next one.

Architecture recommendation: DACs are the primary row-level security mechanism. Always build permissions entities tied to organizational dimensions (cost center, business unit, geography). Keep sensitive columns in restricted views. Establish a clear SAC tenant strategy with at least dev/test/prod separation and SAP Cloud Transport Management (cTMS) for lifecycle control. Master data governance dimension (new in 2026): With SAP Reltio generally available in SAP Business Data Cloud and SAP MDG a core BDC component, master data quality, lineage, and stewardship become analytics-governance concerns. Build DAC permissions entities from governed master data so dimension ownership is explicit and auditable; when ownership changes in the master data, the next load updates who sees what. Quality gates are pipeline logic you design: when a governed hierarchy breaks, hold back the load or flag the affected records and notify the steward. Never use role-based security alone in Datasphere — pair scoped roles with dimension-based DACs for fine-grained control and auditability. In a composite federated model, business units own their cost-center domains in SAP Reltio or SAP MDG, the governed records feed the DAC permissions entities, and audit evidence from each system is documented together.

Read deeper: Governance and control boundaries

Decision 5: What is the BW modernization path?

SAP plans to support BW/4HANA to at least the end of 2040 through successive releases (release 2023 runs to the end of 2030). The modernization question is not "if" but "which path." SAP now offers five distinct paths. Choosing correctly prevents forced, risky migrations.

Path 1: Datasphere Migration

Full migration to Datasphere's native modeling framework. Re-engineer BW metadata as Datasphere analytic models, dimensions, and measures. Best for greenfield scenarios or organizations ready to redesign their semantic layer. Supports full hierarchy structure, conformed dimensions, and complex business logic. In SAP Business Data Cloud, the Query Template Generator moves BW queries into analytic models as a starting point.

Path 2: SAP BW Bridge

Hybrid coexistence for staging. SAP BW bridge runs BW-style data staging inside Datasphere: ODP extraction from on-premise sources, transformations, and business content. It has no OLAP engine (no BW query execution or analysis authorizations), so query semantics must be rebuilt as analytic models. SAP positions SAP BW, private cloud edition as the strategic route, with the bridge for business content and ECC extractors or for BW decommissioning.

Path 3: BW Data Product Generator

Gradual incremental modernization. With SAP BW, private cloud edition in SAP Business Data Cloud, the Data Product Generator replicates InfoProvider data into Datasphere's object store and publishes it as custom data products. It doesn't convert BW models or queries. This approach avoids big-bang migration risk and lets teams modernize at their own pace. New workloads start on Datasphere while legacy BW objects continue running.

Paths 4 & 5: Private Cloud Edition and BDC Lift-and-Shift

Managed cloud deployment for organizations not ready to change the modeling paradigm. Path 4: BW/4HANA runs on SAP-managed private cloud infrastructure (SAP handles infrastructure and patching). Path 5: lift BW into SAP Business Data Cloud as SAP BW, private cloud edition—SAP's strategic route. BW 7.5 there gets mainstream maintenance to the end of 2030 instead of 2027, with an optional SAP BDC Modernization Option from 2031 to the end of 2033. Both preserve the existing operational model.

Architecture recommendation: The modern target is Datasphere. However, modernization requires a sequenced approach. SAP plans BW/4HANA support to at least the end of 2040 through successive releases, which gives you time for thoughtful transitions without forced timelines. Start new workloads on Datasphere while existing BW keeps running, preferably as SAP BW, private cloud edition in BDC with the Data Product Generator, or with SAP BW bridge for staging and business content. Practical path: Year 1: identify which BW objects drive the highest business value and which are low-volatility legacy reports. Publish high-value InfoProvider data as data products with the Data Product Generator (or replicate it), and rebuild the queries as analytic models; the Query Template Generator gives a head start. Route consumption to Datasphere while BW keeps running. Year 2-3: retire BW objects incrementally as business confidence in Datasphere grows. Use analytic model stacking to create derived semantics in Datasphere that would have required painful calculated key figures in BW. Avoid forced migrations of complex BW landscapes. Instead, adopt a "new on Datasphere, legacy on BW" posture, gradually retiring BW objects as replication to Datasphere completes. SAP's multiple paths exist specifically to prevent risky big-bang changes. In a composite example, a CPG company modernizes supply-chain analytics in stages: planning moves to Datasphere first (business impact visible quickly), forecast and allocation logic is rebuilt with analytic model stacking, and BW runs read-only in parallel until it is retired.

Read deeper: BW modernization topic

Reference architecture patterns

These four patterns cover the most common combinations of the five decisions above. Each represents a coherent, supportable architecture.

SAP-Native Analytics

Best for: All-SAP shops with S/4HANA and strong SAP platform commitment. Shape: SAC + Datasphere + S/4HANA. Semantic layer in Datasphere spaces (row-level DACs; sensitive columns in restricted views). Planning via SAC models with measures and seamless planning (data stored in Datasphere). Live connections for reporting, planning models for input. Integration via Integration Suite and Datasphere replication flows. Lifecycle via SAP Cloud Transport Management (cTMS). When to choose: Simple supply chains, strong data governance needs, no external data science teams.

Hybrid Multi-Cloud

Best for: Organizations with data science teams running Databricks, Snowflake, or Google BigQuery. Shape: Datasphere + BDC Connect + Databricks/Snowflake/BigQuery + SAP Reltio master data. Semantic layer in Datasphere with analytic model stacking for layered semantic governance. Data products shared with external platforms via BDC Connect zero-copy sharing (no data movement, reduced latency). Planning via SAC with live data access to Snowflake or BigQuery. Tabular predictions from SAP-RPT-1.6 can feed the Datasphere analytics layer. Data scientists consume governed SAP data products without ETL. Master data dimensions governed in SAP Reltio for quality and lineage transparency. Joule agents built in Joule Studio act across systems, and BDC data products inside Joule Studio are planned for GA in Q1 2027. Governance boundary remains at Datasphere, extended via event-driven patterns to external systems. When to choose: Advanced ML, cross-cloud analytics, zero-copy data sharing for scale, federated governance where external teams need SAP data with provenance assurance.

Planning-Centric

Best for: Organizations where budgeting, forecasting, and rolling forecasts are the primary use case. Shape: SAC planning + seamless planning in Datasphere + S/4HANA actuals. Planning models store plan versions in Datasphere. Actual data from S/4HANA arrives through Datasphere replication flows or SAP-managed data products. Live data access to Snowflake for blended planning (combining SAP cost actuals with market forecast data). Approval workflows via SAC calendar tasks. When to choose: Finance, supply chain planning, workforce planning where planning rigor is the core need.

Modernization in Flight

Best for: Organizations transitioning from BW to Datasphere. Shape: BW (BW/4HANA, or SAP BW, private cloud edition in BDC) + Datasphere + SAC. Legacy BW queries keep serving SAC through live connections to BW; new workloads are built on Datasphere and consumed live in SAC. SAP BW bridge, where used, handles staging and business content only (no query execution). Governance via DACs in Datasphere and existing BW analysis authorizations in BW. Plan gradual retirement of BW objects as Datasphere replication completes. When to choose: Any BW migration, minimize risk of big-bang change.

Architecture playbooks

These five playbooks map to the five decisions above. Each includes a route card with related links and resources.

Semantic ownership

Where should reusable business meaning live?

Use this playbook when the real issue is metric consistency, analytical semantics, data-product design, and whether meaning is being buried in dashboards instead of governed upstream.

Semantic layer guide Datasphere topic SAC vs Datasphere

Planning architecture

Where should input, versions, and plan integration sit?

Use this playbook when the challenge is to shape planning models, actual-versus-plan flows, forecast logic, approvals, and the relationship between SAC planning and connected source systems.

SAC topic SAC vs BW Planning reference kit

Integration and extension

Where does connection stop and platform logic begin?

Use this playbook when teams are mixing Salesforce feeds, catalog synchronization, external data-platform handoffs, open connectors, event-driven patterns, APIs, orchestration, workflow, custom runtime, and application extension into one blurry delivery stream.

Boundary guide BTP topic Integrations topic

Governance and lifecycle

Where should trust, access, review, and transport control live?

Use this playbook when your architecture risk is really an operating-model risk: roles, stewardship, lifecycle checkpoints, monitoring, content administration, and secure rollout.

Control-boundary guide Governance topic Governance reference kit

Modernization and coexistence

How should BW-era assets coexist with newer cloud layers?

Use this playbook when the central question is transition timing, semantic continuity, retained trust, and the realistic target state across BW/4HANA, Datasphere, SAC, and Business Data Cloud.

BW modernization topic Modernize or still fit? Modernization reference kit

Official reference kits

These kits prioritize official SAP Learning, SAP Help, and SAP Community surfaces. The summaries are original, but the factual product baseline comes from primary SAP sources.

Semantic kit

For business meaning, spaces, and governed consumption

Planning kit

For plan models, approvals, and connected planning flows

Integration kit

For APIs, orchestration, workflow, and mixed-landscape boundaries

Governance kit

For roles, administration, monitoring, and lifecycle control

Modernization kit

For coexistence, migration paths, and BW-era target-state design

Key takeaways

Semantic ownership is architectural

Where your semantic layer lives determines reusability, governance, and downstream platform choices. Datasphere Spaces are the strategic destination. BW (BW/4HANA, or SAP BW, private cloud edition in BDC) provides coexistence during transition; SAP BW bridge covers staging only. SAC import models are consumption-only.

Planning models are not dashboards

Planning requires version management, input capability, approval routing, and separate storage for plan vs. actual data. SAC models with measures plus seamless planning (data in Datasphere) are the modern architecture. The classic account model is legacy.

Integration and extension are different disciplines

Integration Suite moves data. BTP runs business logic. Confusing them weakens architecture. Use Cloud Integration for transformation, Event Mesh for event routing, Open Connectors for third-party systems. Use BTP for custom logic, workflows, and specialized UX.

Governance is not optional

Data Access Controls (row-level DACs mapped to dimensions) are the first defense. SAP Cloud Transport Management (cTMS) provides lifecycle governance. Define these at architecture time, not after deployment.

Modernization requires multiple paths

Datasphere is the target. But forcing migration of complex BW landscapes creates risk. Use SAP BW, private cloud edition in BDC (with the Data Product Generator) or SAP BW bridge for staging to coexist. Start new workloads on Datasphere. Retire legacy BW gradually.

Architecture serves operations

The best design is the one your team can operate. Include roles, governance, monitoring, and support models alongside product choices. Architecture without operations is incomplete.