LSA & LSA++ Overview

In the previous blog we seen about the overview and introduction of SAP BW and R3 Architecture, in this Blog am  going to tell about the overview of LSA and LSA++ for SAP BW/HANA. 

What is LSA & LSA++ ?

LSA is Layered Scalable Architecture and helps in designing and implementing various layers in the BW system for data acquisition, data distribution and data analysis.

Let's see about the 7 layers. 

1) Data Acquisition Layer.

2) Quality (or) Hormonization Layer. 

3) Corporate Memory.

4) Propogation Layer.

5) Business transformation Layer.

6) Reporting Layer.

7) Operational Data Store Layer. 

Fig 1.1.1

If we were to break down the above picture bottom upwards:

1. The ETL/Extractor which brings data from ECC and other sources would be the data acquisition layer. (This would be the 'SLT' & 'CDS View' step in the Native HANA scenario)

2. The BW transformations would be the EDW transformations & propagation layer

3. The Architected data marts would be the Info cubes and Data Store objects which store the physical data.

4. The BW Virtual data mart layer would be the Composite Providers, Virtual Providers and Transient Providers

5. The presentation layer would be the Bex queries, Business Objects queries, Lumira etc.

The biggest difference between SAP's earlier LSA and the above HANA LSA++ is the fact that queries can be directly built in BW on HANA on the DSO level and the additional layer of an Info cube /Multi provider is not needed. This eliminates data redundancy and huge cost savings in terms of daily maintenance. No more data load failures and trouble shooting and missing SLA's (service Level Agreements). No need of building Info cubes for optimized reporting. In the Native HANA scenario it's even better as we can get away with just performing SLT at the basic table level and replicating data into HANA. From there on we can create joins and SQL in Analytical and Calculation views to perform data merge and consolidations without reloading multiple levels.

 What is Enterprise warehouse?

Over the course of the past few years, Enterprise Data Warehouse systems (EDW) have become one of the most important components of modern decision support systems. Their main benefit consists in bringing together data from different sources – not available in appropriate form in the operational systems, for instance because of missing historical data – in one central location and preparing them for analysis, or bringing together data from diverse sources that may have totally different formats. Added to this is a landscape that is increasing significantly in complexity and acting as the source of structured data (e.g. ERP systems), unstructured data (social networks) and even Big Data (e.g. sensor data from numerous events).

Thanks to the use of an EDW system, the typical risks inherent in heterogeneous data warehousing that most companies are faced with, i.e. losing track, increasing data redundancy and long decision-making paths, can be avoided effectively.

All relevant partial data from the most important data sources along your company’s entire value chain are brought together simultaneously in a way that facilitates rapid and purposeful decision-making at all company levels. Various types of information, for instance on suppliers, products, production, stock levels, partners, customers, staff and sales, are all combined in the data warehouse system to provide a holistic view.

What is Architected Layer ?

The Architected Data Mart layer consists of the Business Transformation layer, the Reporting layer and the Virtualization layer.

Business Transformation Layer

In the Business Transformation layer, the data is transformed based on business logic. The data in the previous layer (Data Propagation layer) should not be transformed based on business logic, to ensure that the data can be used again. It may be the case that DataStore objects in this layer are needed to compile data from several DataStore objects in the Data Propagation layer.

Reporting Layer

The Reporting layer contains the objects that are used to perform queries for analysis. This layer is modeled mainly using InfoCubes. These cubes save data in BWA. To improve the database performance, you can semantically partition the InfoCubes. Special InfoCubes enable you to create planning scenarios here. Using this InfoCubes as a basis, you can create data views (in the form of aggregation levels) and methods to change data (for example, planning functions and planning sequences). VirtualProviders allow you to access source data directly. Different composite objects (HybridProviders, InfoSets) provide benefits for analysis. Depending on the scenario, you can use these composite InfoProviders.

Virtualization Layer

Queries should always be defined on a MultiProvider for reasons of flexibility. These queries form the Virtualization layer.

Operational Data Store

The Operational Data Store supports operative data analysis. Data can be updated to an operational data store, on a continual basis or in short intervals, and then read for operative analysis. You can also forward the data from the Operational Data Store layer to the data warehouse layer at set times. This means that the data is stored in different levels of granularity. For example, whereas the Operational Data Store layer contains all the changes to the data, only the day-end status is stored in the data warehouse layer.

Here i'm completing about my SAP BW/HANA LSA++ overview.