SAP BW/4HANA Tutorial (Part 1)

BW/4HANA is SAP's data warehouse solution designed exclusively for the SAP HANA database, positioned as the successor to classic SAP BW (which could run on any database) and BW-on-HANA (classic BW code running on HANA but not re-architected). Understanding why BW/4HANA exists matters because most consultants entering a project will either be building greenfield BW/4HANA systems or converting an existing BW landscape, and the business/technical drivers shape almost every design decision.

Classic BW grew over two decades and accumulated multiple InfoProvider types: InfoCubes, DataStore Objects (classic), MultiProviders, InfoSets, and various acquisition layers (PSA, transfer rules, update rules). This flexibility came at a cost: redundant data layers, complex transformation chains, and database-agnostic code that could not fully exploit HANA's in-memory, columnar processing. When SAP moved BW onto HANA (BW-on-HANA), the underlying database changed but the modeling paradigm largely stayed the same, so many customers still carried forward unnecessary data layers and legacy object types.

BW/4HANA addresses this by simplifying the object model into a smaller, HANA-native set: the Advanced DataStore Object (ADSO) becomes the single, flexible physical data storage object (it can act like a classic InfoCube, standard DSO, or write-optimized DSO depending on its configured type), CompositeProviders replace MultiProviders and InfoSets for combining data across providers with union/join semantics, and Open ODS Views allow virtual, non-persistent access to source data without full staging. Classic objects like InfoCubes, classic DSOs, and InfoSets are not directly creatable in BW/4HANA; they must be converted to their ADSO-based equivalents during migration.

From an architecture standpoint, BW/4HANA also emphasizes a layered scenarios approach (often summarized as data acquisition, corporate memory/harmonization, propagation, and reporting layers) built with ADSOs of different types, rather than the older layered scalable architecture (LSA) built from InfoCubes and classic DSOs. Process chains, transformations, and DTPs remain conceptually similar to classic BW, so consultants with classic BW experience can transfer most process-chain and transformation skills, but the target objects and some transformation rule options differ.

Deployment context matters: BW/4HANA is available as an on-premise/private-cloud product installed on HANA, and SAP also offers embedded BW capabilities inside S/4HANA (called embedded BW or BW embedded in S/4HANA) for lightweight reporting without a separate BW/4HANA system. These are architecturally related but not identical products, and consultants should not assume every BW/4HANA capability is automatically available in an S/4HANA-embedded BW context, or vice versa. Public cloud S/4HANA scenarios typically rely more on embedded analytics (CDS views, embedded BW artifacts) than on standalone BW/4HANA, while large enterprise landscapes often keep a dedicated BW/4HANA system for cross-system, historical, and heavily transformed reporting needs.

For a beginner, the practical takeaway is: BW/4HANA is not just "classic BW running faster on HANA"—it is a deliberately reduced object model intended to force simpler, HANA-optimized designs, and every classic BW skill you bring must be re-mapped onto ADSO-based equivalents before it is production-relevant.

A retail company running classic BW-on-HANA for ten years has accumulated dozens of InfoCubes and classic DSOs feeding overlapping MultiProviders for sales reporting. Management mandates a BW/4HANA conversion project. In the kickoff workshop, the lead consultant explains to the client's reporting team that InfoCubes will become ADSOs configured for reporting, MultiProviders will become CompositeProviders, and that some previously redundant layers (created historically to work around InfoCube limitations) can likely be eliminated because ADSOs handle both transactional and master-data-heavy scenarios more flexibly, reducing the overall object count during the redesign phase.

• Assuming BW/4HANA is simply classic BW installed on a faster database, without recognizing the object model is fundamentally reduced.
• Trying to create classic InfoCubes or classic DSOs directly in a BW/4HANA system, which is not supported; only ADSO-based equivalents exist.
• Confusing standalone BW/4HANA with embedded BW capabilities inside S/4HANA and assuming feature parity between them.
• Underestimating the redesign effort by assuming a like-for-like object conversion is always possible without any remodeling.
• Ignoring that process chains and transformations, while conceptually familiar, may require rule adjustments when targets become ADSOs.

• Learn the ADSO type options (standard, write-optimized, etc. conceptually) before assuming any classic object maps one-to-one.
• Clarify early in a project whether the target is standalone BW/4HANA, embedded BW in S/4HANA, or a hybrid, since this changes scope and tooling.
• Use the conversion/migration planning phase to also rationalize redundant legacy layers rather than mechanically converting everything as-is.
• Confirm with the client which reporting tools (BEx, embedded analytics, third-party BI) will consume BW/4HANA data, since this affects provider design choices.

Interviewers commonly ask candidates to explain the architectural difference between classic BW, BW-on-HANA, and BW/4HANA, and to name the core simplified objects (ADSO, CompositeProvider, Open ODS View). A strong answer distinguishes 'same database, same model' (BW-on-HANA) from 'new database-native model' (BW/4HANA), and acknowledges that migration is a remodeling exercise, not a lift-and-shift.