Skip to main content

Module 2: BW/4HANA System Architecture

This module provides a deep architectural understanding of BW/4HANA, focusing on:

  • LSA vs LSA++ architecture
  • Data warehousing layers in detail
  • BW/4HANA system landscape
  • Modeling tools (Eclipse-based)
  • BW/4HANA vs ECC-based BW

Architecture knowledge is mandatory for:

  • Correct modeling
  • Performance optimization
  • Interview discussions
  • Designing scalable BW solutions

1. What is BW/4HANA System Architecture?

BW/4HANA system architecture defines:

  • How data flows end-to-end
  • How responsibilities are separated
  • How scalability and performance are achieved
  • How modeling aligns with HANA pushdown
Key Principle

BW/4HANA architecture is conceptual and layered, not object-heavy.


2. Layered Scalable Architecture (LSA)

2.1 What is LSA (Classic)?

LSA (Layered Scalable Architecture) was SAP’s recommended architecture for classic BW.

Core Characteristics of LSA

  • Strong persistence at every layer
  • Multiple physical layers
  • Heavy use of DSOs, InfoCubes, MultiProviders
  • Aggregates for performance

Typical Classic LSA Flow

Source

PSA

DSO (Staging)

DSO (Harmonization)

InfoCube

MultiProvider

BEx Query
Limitations

High data redundancy
Long load times
Complex maintenance
Heavy dependence on aggregates
Poor flexibility


3. Layered Scalable Architecture Plus Plus (LSA++)

3.1 What is LSA++?

LSA++ is SAP’s modern reference architecture, optimized for HANA and BW/4HANA.

It replaces:

  • Data redundancy → Virtualization
  • ETL → ELT (pushdown)
  • Aggregates → On-the-fly calculation

Core Principles of LSA++

LSA++ Design Principles

Logical layers, not mandatory physical layers
Push logic to HANA
Persist only when necessary
Reuse models
Virtualize wherever possible

LSA vs LSA++ (Key Comparison)

AspectLSA (Classic BW)LSA++ (BW/4HANA)
DatabaseAnySAP HANA only
PersistenceHeavyMinimal
AggregatesRequiredNot needed
ObjectsManySimplified
PushdownLimitedCore principle
FlexibilityLowHigh
Interview Line

LSA++ focuses on logic pushdown and virtualization instead of persistence.


4. Data Warehousing Layers in LSA++

LSA++ defines logical layers. Not all layers must be physical.

4.1 Data Acquisition Layer

Purpose

  • Bring data from source systems
  • Minimal transformation

Objects Used

  • ODP-based DataSources
  • Open ODS Views
  • PSA (optional)

Best Practices

  • Keep transformations technical only
  • Do not apply business rules
  • Keep data source-aligned

4.2 Corporate Memory / Staging Layer

Purpose

  • Store raw, historical data
  • Enable reprocessing and auditing

Objects Used

  • aDSO (Standard type)

Best Practices

  • Persist only if audit/history is required
  • Avoid unnecessary data duplication

4.3 Harmonization Layer

Purpose

  • Apply business logic
  • Integrate multiple sources
  • Harmonize keys and master data

Objects Used

  • aDSO (Standard)
  • AMDP-based transformations

Best Practices

  • Centralize business logic
  • Avoid repeating logic in queries
  • Use HANA pushdown where possible

4.4 Reporting / Virtualization Layer

Purpose

  • Combine data virtually
  • Enable reuse
  • Avoid data persistence

Objects Used

  • CompositeProviders
  • Open ODS Views (virtual)

Best Practices

  • Avoid one-off CompositeProviders
  • Design reusable models
  • Do not persist reporting-only data

4.5 Consumption Layer

Purpose

  • Enable analytics and reporting

Objects Used

  • BW Queries

Consumers

  • SAP Analytics Cloud
  • Analysis for Office
  • Third-party BI tools

Best Practices

  • Keep logic presentation-focused
  • Avoid data cleansing here

5. BW/4HANA System Landscape

Typical BW/4HANA Landscape
DEV → QA → PRD

Landscape Characteristics

  • Separate BW/4HANA system (recommended)
  • Integrated with S/4HANA, ECC, non-SAP
  • Uses CTS for transports
SAP Recommendation

BW/4HANA should be a central analytics system, not mixed with OLTP.


6. Modeling Tools Overview

BW Modeling Tools (Eclipse)
BW/4HANA modeling is done using BW Modeling Tools (BWMT) in Eclipse.

What Can Be Modeled in Eclipse?

  • InfoObjects
  • aDSOs
  • CompositeProviders
  • Transformations
  • DTPs
  • BW Queries
  • Process Chains

Why Eclipse-Based Modeling?

Advantages

Better performance
Better UI
Version control friendly
Required for modern BW features

Deprecated

SAP GUI modeling is not recommended for BW/4HANA.


7. BW/4HANA vs ECC-Based BW

Architectural Comparison

AreaECC-Based BWBW/4HANA
DatabaseAnySAP HANA
ModelingSAP GUIEclipse
ObjectsLegacy-heavySimplified
PerformanceAggregate-basedPushdown-based
FutureMaintenanceStrategic

Strategic Direction

SAP Strategy

BW/4HANA is the only strategic BW platform going forward.


8. Common Architecture Mistakes

Avoid These

Over-persisting data
Ignoring LSA++ principles
Mixing classic and modern patterns
Applying logic in wrong layers


9. Interview-Grade Explanation

Q: Explain LSA vs LSA++ in BW/4HANA.

Answer:
LSA is the classic layered architecture used in traditional BW systems with heavy persistence and aggregates. LSA++ is the modern architecture for BW/4HANA that leverages HANA pushdown, virtualization, reduced persistence, and simplified modeling to achieve better performance and scalability.


10. Summary

  • BW/4HANA uses LSA++ architecture
  • LSA++ reduces persistence and complexity
  • Layers have clear responsibilities
  • Eclipse-based modeling is mandatory
  • BW/4HANA is architecturally different from ECC BW

11. What’s Next?

➡️ Module 3: BW/4HANA Data Modeling Basics (InfoObjects)

Learning Tip

Architecture decisions made early determine performance, scalability, and maintenance cost.