Foundations of BW Data Modeling: InfoObjects, InfoProviders, and the Layered Architecture
Introduces the core building blocks of SAP BW data modeling—InfoObjects, InfoProviders, and the layered (LSA/LSA++) architecture—and explains why structured modeling matters for reporting accuracy and performance.
Explanation
SAP BW Data Modeling is the discipline of designing how business data is structured, stored, and made available for reporting. Before any transformation or query can be built, a consultant must understand the fundamental objects: InfoObjects, InfoProviders, and the layered architecture that governs how data flows from source systems to end-user reports. InfoObjects are the smallest reusable modeling units in BW. They come in two categories: characteristics (e.g., Customer, Material, Cost Center) which represent business entities used for grouping and filtering, and key figures (e.g., Revenue, Quantity, Amount) which represent measurable values. Characteristics can carry master data (attributes, texts, hierarchies) that is loaded and maintained independently of transaction data, enabling reuse across many data flows. This reusability is central to BW's design philosophy—an InfoObject like 0CUSTOMER is defined once and referenced across dozens of InfoProviders, ensuring consistent business semantics enterprise-wide. InfoProviders are the objects that queries run against. In classic BW (on HANA or other databases), common InfoProvider types included InfoCubes (multidimensional star-schema models) and DataStore Objects (DSOs) for granular, document-level storage. In BW/4HANA, the modeling paradigm consolidated around the Advanced DataStore Object (ADSO), which can be configured in different types (write-optimized, standard staging, or reporting-enabled) to replace the separate InfoCube and classic DSO concepts. This simplification reduces redundant physical layers while preserving the semantic distinctions between staging and reporting data. The Layered Scalable Architecture (LSA, and its evolution LSA++) is the standard design pattern for organizing these objects. It typically separates data into: a Corporate Memory / Acquisition layer (unchanged, granular data as received from source), a Harmonization/Quality layer (cleansed, business-rule-applied data), and a reporting layer (denormalized, query-optimized structures, often exposed via CompositeProviders). This layering exists because raw source data rarely matches reporting requirements directly—harmonization applies currency conversions, unit conversions, master data lookups, and business logic, while the reporting layer optimizes for query performance rather than storage efficiency. CompositeProviders are a modeling layer (not physical storage) that combine multiple ADSOs, InfoObjects, or open ODS views via union or join operations, allowing reporting-layer flexibility without duplicating data. Understanding when to use a union versus a join in a CompositeProvider is a core early skill—unions combine similar structures (e.g., multiple fiscal years of data), while joins combine complementary structures (e.g., sales data joined with a customer master attribute view). A beginner's key mental model: data enters BW at the acquisition layer, gets cleaned and enriched moving through harmonization, and is finally exposed for reporting through a semantic layer. Every physical object (ADSO) has a defined type and purpose within this flow, and skipping layers or conflating their responsibilities is one of the most common early modeling mistakes, leading to poor auditability and performance problems later in the project lifecycle.
Real project scenario
A retail company migrating from ECC to S/4HANA with embedded BW wants a sales reporting model. The team defines 0MATERIAL and 0CUSTOMER InfoObjects with attributes and hierarchies reused across three separate business lines, builds a write-optimized ADSO to store raw billing document data unchanged (acquisition layer), a standard ADSO for harmonized data with currency conversion applied, and exposes the final structure to Analysis for Office users via a CompositeProvider joining sales data with a customer segmentation InfoObject.
Common mistakes
• Loading transaction data directly into a reporting-layer object without an acquisition/staging layer, making reprocessing or audit trace-back impossible • Creating duplicate InfoObjects for the same business entity across different application areas instead of reusing standard or custom shared InfoObjects • Confusing union and join semantics in CompositeProviders, resulting in incorrect record duplication or missing combinations • Not defining navigation attributes correctly, causing characteristics to be unusable for drill-down in queries • Overloading a single ADSO with both staging and reporting responsibilities, harming maintainability
Best practices
• Always model characteristics and key figures as reusable InfoObjects rather than embedding fields ad hoc • Maintain a clear acquisition-harmonization-reporting layering discipline even in smaller projects • Use write-optimized ADSOs for high-volume, unchanged staging data to avoid unnecessary activation overhead • Document the purpose of each ADSO type within the data flow for future consultants and support teams • Reuse standard business content InfoObjects where possible instead of creating redundant custom ones
Interview angle
Interviewers commonly ask candidates to explain the difference between an InfoObject, an InfoProvider, and a CompositeProvider, and to justify why a layered architecture is used instead of loading data straight into reporting objects. Be ready to discuss the purpose of write-optimized versus standard ADSOs and give an example of when you would choose a union versus a join in a CompositeProvider.