Identify the SAP BW/4HANA Layered Scalable Architecture (LSA++)

The Layered Scalable Architecture (LSA++) can be applied to design an enterprise data warehouse with an SAP BW/4HANA system. The following are the three primary objectives:

1. Description of a generally valid architecture that is complete and scalable, is based on proven practices, and takes recognized EDW principles into account.
2. Definition of guidelines and standards for setting up high-performance, flexible, and maintainable EDW applications, even in complex, globally active organizations.
3. Provisioning of a reference for deriving customer-specific data warehouse architecture concepts.

The Layered Scalable Architecture (LSA++) reference architecture is split into layers as shown in the preceding figure. These build strictly on one another, and are therefore dependent on one another. Only omit a layer in exceptional cases. Starting from the data acquisition, the data flow proceeds upwards into the individual reporting applications. Specific SAP BW/4HANA objects are used in each layer.

Watch the following video to see an overview of the different layers and their usage.

The LSA++ contains a maximum of different SAP BW/4HANA concepts, but not all layers must be realized. Which layers are required, depends on the complexity of your requirements, and on your strategy. Especially, you have to decide when to use SAP BW/4HANA layers with persistent storage, and when to use virtual SAP HANA models.

The LSA++ wisely combines elements with data storage (EDW, local agile extension), and virtual layers (agile data mart, virtual layer, BW reporting layer). Within LSA++, virtual layers are preferred. Persistence layers must have a business reason. For example, you must store a history of data if you want to detect a trend. Use an agile data mart (SAP HANA view) to see today's sales.

A typical LSA++ consists of only one or two physical layers of the core EDW. The Open ODS layer doesn't need to be persistent if loading values into the global core EDW layer (usually a Standard DataStore Object) is reliable and fast enough. Transactional data of the same granularity from different sources can be stored in one big DataStore Object (advanced).

Architected data marts can be modeled as CompositeProviders if transformations are simple enough, such as joins or unions of PartProviders. Only store the physical result of a join after thorough investigations on runtime versus storage costs. For example, check if the temporal join in a CompositeProvider is fast enough to derive the tracking history scenario "historical truth."

For slightly more complicated transformations, check if they can be calculated in a Query. If CompositeProvider or Query are insufficient, use transformations and a new physical layer. Typically, this architected data mart is a multidimensional Data Mart DataStore Object: that means, all characteristics are key fields.

On top of every physical provider, use a Wrap CompositeProvider, and if combinations of different physical providers are needed, another composition layer (using Composition CompositeProviders) is recommended. They form the basis for Queries.

We recommend using a naming convention for the technical names of InfoProviders and other SAP BW/4HANA objects that indicate the layer (and the object's significance).

The first letter, or letters, is reserved for a name space for a top-level area of responsibility, such as a business section. The next letter is reserved for the LSA++ layer. The following letters are a proposal for such namespaces:

• Z: DataSource (based on existing naming conventions in SAP source systems)
• O: Open ODS Layer (Open ODS View)
• CM: Corporate Memory Layer (Staging DataStore Object)
• DW: Data Warehouse Layer / Delta Calculation (Standard DataStore Object)
• DM: (Architected) Data Mart Layer (Data Mart DataStore Object)
• W: (Virtual) Wrap Layer (CompositeProvider)
• V: (Virtual) Composition Layer (CompositeProvider)
• CV: Calculation View (Agile Data Mart Layer)

If such a detailed authorization concept is needed, the next letters can be reserved for the business topic or domain.

For some time, the original sources (ITeIO and Retailer King 3000), will remain separate areas of responsibility. However, a strategic target is to join these areas and to reduce the differences until finally, they will no longer be separated. ITeIO therefore wants to separate them in a flexible way that can be changed easily. As it is difficult to change this concept later, you must consider this decision process carefully. What is a best practice procedure to design this system landscape model?

First you analyze how your business is organized. In the business review, you have identified different business processes that contribute to the data warehouse. Usually, each process corresponds to one or more areas of responsibility, for example, a subsidiary or reporting topic. An important question is whether different areas of responsibility must share common objects, and how dynamic these assignments are.

1. Define relevant business processes and clearly assign separate areas of responsibility, such as sales and purchases.
2. Identify sub-areas of responsibility, such as Sales Europe, Sales Asia.
3. Investigate thoroughly where overlaps between business processes occur. Define a global responsibility for cross-topic issues such as competition between different sales organizations.
4. Identify which basic elements are involved, such as orders, customers, products, countries, and currencies.
5. Identify especially, if these elements are specific to one process or business area:
   1. Global elements such as country, time, currency, company code are relevant in many areas,
   2. Specific "local" elements are specific to one process, such as sales discount, cause for denial, delivery delay.
6. Identify on which level, a reorganization of responsibilities might be an issue in future.

How are different areas of responsibility separated technically? Consider what happens if the company is reorganized, or if new processes and systems are established. The complexity increases, and assignments that appeared to be fixed have to be changed. Therefore, if you are in doubt, we recommend that you choose the more flexible concept. The preceding figure distinguishes three different concepts:

• Separate applications as separate source systems

  Some areas of responsibility must be separated in a rigid, stable way with strict technical access barriers. For instance, you can separate an HR data warehouse from a CRM data warehouse using different SAP BW/4HANA applications. Similar to the source system level, if no or few common objects are required, big companies often use different SAP BW/4HANA systems for different processes. However, sharing common objects is difficult. Extra effort is required to combine data from several SAP BW/4HANA applications into a global report. You could, for instance, extract relevant data slices into a third, global data warehouse.

  Changes of the organization are difficult to implement in this concept.

• Separate namespaces (a set of possible technical names for objects, usually defined by its starting letters) in one system.

  Examples: X,Y,Z for three different areas of responsibility.

  For smaller areas of responsibility that must be separated in a rigid, stable way with many common objects, we recommend that you use different namespaces. For instance, you can create different namespaces for procurement and sales, and a global namespace for common objects such as day, product, employee, or business partner. Global reports combining data from both areas of responsibility can be created as views over both areas in the common objects namespace.

  Changes of the organization are difficult to implement in this concept.

• Separate folders in a hierarchy (InfoAreas)

  Keep in mind that the design of responsibilities can change over time. Areas of responsibility are regularly further divided into subareas. For these cases, use a folder hierarchy that reflects a dynamically changing hierarchy of areas of responsibility. In SAP BW/4HANA, you use InfoAreas. For example, create InfoAreas for online sales and live sales as sub InfoAreas of Sales.

  Changes of the organization are easier to implement in this concept, as the hierarchy of InfoAreas can be changed later.

  .

In fact, combinations of these concepts are common in data warehouse implementations.