Introducing the Enhanced Layered Scalable Architecture (LSA++)

SAP built the Layered Scalable Architecture (LSA) around the best-practice model that was created by one of the thought-leaders in data warehousing, Bill Inmon. The basic principle of the Inmon model, known as the Corporate Information Factory, was to develop a set of consistent and highly re-useable data modeling layers that included data acquisition, primary storage and data delivery. Acquire data once and propagate multiple times was a key idea behind this approach. SAP added to this architecture with its own design principles such as the introduction of a virtual layer between the data persistence layer and reporting.

Let's remind ourselves of the layers of LSA and the objects used to implement the layers:

• Data Acquisition layer: This layer represents the interface from the data warehouse to its source systems. It picks up source data from various systems and initiates the processing in SAP BW. The data is held in the format of the source system and not changed (yet). Typical object types of this layer are SAP BW DataSources and their corresponding PSA tables.

• Harmonization layer: Here, the data is adjusted so it is standardized. Missing data fields are added, values are corrected and converted. Data is sourced from multiple systems so the key role of this layer is to harmonize the data so that a consistent data set is the result. The harmonization effort depends heavily on the source from which the data originates. No target application-specific logic is processed in this layer; only changes that are valid for all target applications are applied. If multiple transformations are necessary, they can be connected via InfoSources; however, it is acceptable for data to be buffered persistently in DataStore Objects in exceptional cases. Typical object types of this layer are Transformations and InfoSources.

• EDW Propagation layer: This layer represents the heart of the system because it serves all BI applications. Fast distribution and reusability are key goals of this level. The information is stored in DataStore Objects that should also be partitioned semantically in larger systems. Typical object types in this layer are standard DataStore Objects.

• Business Transformation layer: Here, the data is transformed in accordance with the individual requirements (business logic) of individual applications. In the same way as in the harmonization layer, InfoSources enable you to link multiple transformation rules. It may also be necessary to buffer data in DataStore Objects, depending on the complexity of the required business logic. Typical object types in this layer are Transformations and InfoSources.

• Architected Data Mart layer: The result of the business transformation is stored at this level so that SAP BW reports can be defined for analysis. Here, InfoCubes are usually used so that you can work with the results data quickly and flexibly. To increase the database performance even further, you can create additional aggregates, perform semantic partitioning or use the BW Accelerator. You can also map planning scenarios in this layer. The typical object type of this layer is InfoCubes.

• Virtualization layer: For reasons of flexibility, it is always recommended to creating queries on virtual InfoProviders. This separates the reporting layer from the physical data. Typical objects types of this layer are MultiProviders and InfoSets.

• BW Reporting layer: Here, the data models of the individual data marts are made accessible for reporting tools. The base object for reporting is the report definition, which is created in the form of SAP BW Queries and processed by the BW analytic manager at runtime. Relevant objects types of this layer are BW queries.

• Corporate Memory: The corporate memory is filled with the source data independently of all other layers. A complete granular history of the loaded data is constructed so that you do not have to rely on the source systems for reconstructions in the event of errors. Typical object types are write-optimized DataStore Objects.

• Operational Data Store: This area is intended for operational and timely data analysis. Source data is extracted at short time intervals and, where applicable, integrated into the EDW propagation layer. Instead of this resource-intensive procedure, you can access the data virtually and directly to better satisfy the real-time aspect. Typical object types are DataStore Objects, virtual InfoCubes or HybridProviders.

Now we have reminded ourselves of LSA, let's now introduce the enhanced version that was developed to support SAP BW/4HANA. It is called Layered Scalable Architecture (LSA++).

LSA++ innovates on the original LSA concept in the following ways:

• The new approach provides a great level of flexibility, because the layers are no longer mandatory. You implement only the layers that you need. The layers no longer strictly depend on each other, and data can be consumed from every individual LSA++ layer. This means the business requirements drive the complexity of each application and redundancy should be minimized. When you move an application to LSA++ or redesign it from scratch, you should carefully evaluate to which degree it is necessary to retain persistent layers. For example, separate DataStore Objects in the Architected Data Mart layer should only be defined, if business logic is required which cannot be implemented in the layers below. If the additional logic is not complex, it is also worth checking whether it could be implemented in the BW query definition or in the layers below.

• The new SAP HANA-optimized InfoProviders replace the obsolete ones.

• A new area has been added: BW Workspace layer to provide the business users with their own, local data modeling space.

• The inbound layer, previously known as the Data Acquisition layer, has been renamed to Open Operational Data Store layer and the scope of functions has been extended. For example, all features of the LSA Operational Data Store are taken over by this new LSA++ layer which means there is now direct access of the Virtual Data Mart layer to the input level of the EDW.

• The Virtualization layer, which provides data for the reporting tools, is significantly broader and more flexible in LSA++ because it can consume data from practically every other layer. This is possible because SAP BW/4HANA queries can also be executed on DataStore Objects (advanced) without any performance issues. For example, you can build reports on the EDW propagation layer without having to set up a business transformation and a separate data mart.

The following section describes all LSA++ layers and refers to the previous meaning in the LSA context where applicable, as well. We also list the SAP BW/4HANA objects that are typically leveraged:

• Open Operational Data Store layer (DataStore Object (advanced), SAP HANA Calculation View, DB-tables or DB-views): This layer is the central input layer of the LSA++ architecture and is discussed in more detail later in the next section of this lesson.

• EDW Transformation layer: New name for the LSA Harmonization layer; purpose and object types unchanged.

• EDW Propagation layer: Based on the DataStore Object (advanced) and enhanced with the option to provide data models of this layer to the SAP BW reporting layer directly via the Virtualization layer; otherwise unchanged.

• Business Transformation layer: The role is unchanged, but it has become optional.

• Architected Data Mart layer: This layer has become less important because in LSA++, due to the fact that it is no longer required to set up data marts to map a complete EDW architecture for reporting. However, the prerequisite for omitting this layer is that the logic of the Business Transformation layer can be integrated at another point (BW Reporting layer or EDW Transformation layer).

• Virtual Data Mart layer: New name for the Virtualization layer and based on CompositeProviders in general. Open ODS Views and BAdI-Providers can be used for specific scenarios as well.

• BW Reporting layer: BW queries are now maintained in BW Modeling Tools, otherwise unchanged.

• Corporate Memory: Now created by DataStore Object (advanced); otherwise unchanged.

• BW Workspace layer This new area is intended for supporting ad-hoc requirements which would be too lengthy and resource-intensive to implement in the core architecture of the data warehouse. The aim is to enable experienced users to make enhancements to existing SAP BW models independently of the central IT department. To enable them to do this, they receive the corresponding tools in the form of BW workspaces based on Local Providers (local data sets) as well as local CompositeProviders.

LSA++ defines the Open Operational Data Store layer as the first layer where data is acquired virtually or physically into the data warehouse. This means data is acquired and carries the semantics, syntax, and quality of the source system, which serves the following requirements:

1. Initial Staging of data based on the standard BW objects like DataSource, Transformation, or DataStore Object (advanced) and BAdI-Provider for exceptional cases, into the consistent EDW core of SAP BW/4HANA, where data might undergo quality checks and harmonization processes as required. The delivery and data management are under full control of the SAP BW/4HANA application. That is, it is managed by the SAP BW/4HANA application and the data is stored in the so-called BW-managed schema of the SAP HANA database where only the SAP application has read-access.

2. Immediate Consumption of data without further staging and integration into the EDW core of SAP BW/4HANA. This means data does bypass the SAP BW/4HANA data integration interfaces (Source System, DataSource). In this case, the data is managed in DB-tables or DB-views of customer-defined SAP HANA schemas different from the SAP BW-managed schema (aka Externally managed schema).This data can be modeled and integrated to any required degree into SAP BW/4HANA based on the Open ODS View or SAP HANA Calculation Views.There are many reasons why data may be managed in SAP HANA schemas independent from SAP BW/4HANA:

   1. Direct Provisioning: Data is loaded directly to SAP HANA based on provisioning methods such as ETL tools (SAP Data Services or third-party tools) as well as replication technologies (for example, SAP LT Replication).

   2. Other Applications: Applications different from SAP BW/4HANA run on the same SAP HANA system and post their data into their own application-managed schema. Some SAP applications can coexist with SAP BW/4HANA on the same SAP HANA platform as SAP BW/4HANA, see SAP note 1661202 (Support multiple applications one SAP HANA database).

   3. Data Federation: Data is managed on external sources but is virtually integrated into SAP HANA based on so-called Remote Connections leveraging SAP HANA standard integration features (i.e. SAP HANA Smart Data Access (SDA) or SAP HANA Smart Data Integration (SDI)).

   This data is not in the range of influence of the BW application. Therefore, it is initially unknown in EDW but can be integrated into SAP BW/4HANA via dedicated modeling objects (Open ODS View, SAP HANA Calculation View). The Open Operational Data Store layer therefore offers standardized access to data on the entire SAP HANA platform as well as to sources connected via the standard BW source system.

   All data of the Open Operational Data Store layer can be consumed via the Virtualization layer directly. Integration in the other LSA++ layers is possible, but not mandatory. Real-time operational reporting, for example, would be a typical use case where other LSA++ layers are omitted. On the other hand, if reporting requirements enforce data cleansing, harmonization or transformation, then processing the data in the LSA++ EDW Propagation layer is the default approach.