SAP introduced the term Layered, Scalable Architecture (LSA) to describe a method of structuring the data in your system. At its core, it is a recommendation to consider your data warehouse as objects organized into layers, in which each layer performs a different task (Figure 1).

Figure 1

The LSA model

LSA has the following features:

• Predefined architecture standards with common standards, created through academic learning from industry and research
• Clear terminology that removes ambiguity
• Isolation from the source system, which allows you to work on the reporting system without affecting your source system

These features are responsible for the following benefits to your system:

• Reducing the likelihood of avoidable mistakes
• Creating a stable foundation on which to grow your system in the future
• Creating a more fault-tolerant system, which is easier and cheaper to support

So why, if LSA delivers these attractive benefits, is it not more widely used and recognized?

The current literature on LSA is difficult to understand because it’s detailed, complex, and theory driven. Little time is spent on discussions of its application in real environments. I believe people aren’t using LSA because they don’t understand it and therefore don’t see its importance. What’s more, they think that because they’ve already built their systems, the topic isn’t relevant to them.

The reality is that LSA delivers tangible performance benefits and can be retrospectively applied to systems quite easily. While the LSA name is new, the concepts behind it are not. Once you’ve cut through the confusing language and information surrounding LSA, you can see that many of the concepts are already used and referenced in SAP NetWeaver BW by different names.

Keep in mind that you do not need to implement all the LSA layers at once. In fact, you may find that some areas are less important to you, and, therefore, you can return to them later.

You can take a number of steps to move your organization toward LSA concepts:

• Step 1. Understand LSA and its terminology
• Step 2. Translate your data model to LSA
• Step 3. Fill the gaps in your implementation and using LSA concepts

A Real-World Example of LSA

Figure 2 shows a typical sales reporting system that doesn’t use LSA. Using this real-world example, I will look at the layers and components in LSA and match them to their SAP NetWeaver BW counterparts.

Figure 2

An example of a typical sales reporting system (left) and its LSA counterparts (right)

 Key points of the sales reporting system’s design include:

• The MultiProvider combines data from two different regions
• The Level 1 DataStore object (DSO) is a permanent store of the source data. This means reloads are often possible without re-extracting from the source. There is no relation between layer numbers and DSO level numbers.
• The system imports the delivery information. While the system is mainly interested in sales, some key information is required from the delivery, such as the transit time.
• All the business logic is encapsulated between the Level 1 and Level 2 DSOs
• The InfoCubes contain aggregated data

Examining the Layers

Let’s look in detail at the veracious layers that make up LSA.

Layer 1 — Data Acquisition Layer

Layer 1, the data acquisition layer (DAL), is a mandatory component of LSA. It is only a temporary store (also referred to as a fast pass-through layer) for the data, which can be cleared out periodically. It contains an exact copy of the data as it is passed to the data warehouse. No type conversion, translation, or other manipulation is undertaken.

This layer includes the following features:

• It allows changes to be extracted from the source system and loaded into the reporting system
• If any problems exist with the data loads, then the loads can be repeated easily
• Handling data loads is the job of the data warehouse and not the transactional system. Once the data has been successfully loaded into the DAL, the source system considers its job complete and removes any storage, flags, or pointers.

In my example in Figure 2, the DAL already exists as the persistent staging area (PSA). Therefore, to move my example to an LSA model, no real work is needed — only the terminology changes.

Layer 2 — Quality and Harmonization Layer

After it has been extracted from the source system, data needs cleaning and tidying in the quality and harmonization layer (QHL). Typical changes you may need to apply are converting alpha characters, removing invalid characters, converting values into valid types or upper-case conversion, and converting values into a standard format.

No business rules are permissible within this layer because business rules can be incorrect or change as the business changes (e.g., you do not convert currency for an exchange rate at this level). The lower down in the layers an issue exists, the harder it is to correct, because every subsequent layer then has to be emptied and reloaded. The conversions that take place in this layer do not change the meaning of the data. They just turn it into a consistent, valid format that you can use within the data warehouse.

The data does not have to be permanently stored within this layer. Features of this layer include:

• There is separation of type conversion from business logic
• The task of data conversion is isolated and kept within part of the system
• Data that cannot be converted can be retained at this stage for later manual processing
• Data without issues can be released to the subsequent stages in the flow

In my example in Figure 2, the QHL is implemented within Transformations and InfoSources prior to loading into the Level 1 DSO.

Layer 3 — Corporate Memory Layer

The corporate memory layer (CML) contains an exact copy of all the data provided by the source system. Every day, as data changes within the source system, a copy of the data is retrieved and stored within the CML. As a result, the CML can become significantly larger than the source system.

You are unlikely to need to access this data, and, therefore, you should not implement it within SAP NetWeaver BW as a typical DSO. Ideally, store data in low-cost, slow-to-access, offline storage — for example, near-line storage (NLS). For many SAP NetWeaver BW systems, the CML is one of the most significant new concepts, and often it is not implemented.

In common with Layers 1 and 2, the CML contains all the fields within the source tables. At this stage I have not removed any redundant fields. Features of this layer include:

• It acts as a back-up, meaning a full restore can be done without going back to the source
• It provides an archive of all your data, including the version history
• New requirements can be satisfied by loading from the CML, rather that re-extracting from the source system

In my example in Figure 2, you can see via the NLS designations that the CML has not been implemented yet. This illustrates how you can retroactively apply LSA to a working system without having to change it. You can implement it by using a third-party NLS product.

Layer 4 — Data Propagation Layer

The data propagation layer (DPL) is a key stage in the architecture. It is from this point that the data contained within the objects is distributed to the subsequent different reporting areas.

From Layer 4 onward, it is permissible to remove fields that are no longer required. This reduces the development effort and storage requirements. You can add any fields that you subsequently decide are needed, and then can load the data from the CML without having to go back to the source system.

Typically in SAP NetWeaver BW, this is implemented as a Level 1 DSO. Most SAP NetWeaver BW implementations use this concept and if they don’t, it can be applied afterwards.

Features of this layer include:

• The delta records generated by the DPL are quick updates to all subsequent layers
• Logical partitioning allows partial reloading or other system activity without affecting the entire user base
• Multiple reporting layers can be fed by a single source of data. This ensures that the entire reporting system is consistent and helps the data warehouse to achieve its goal of a single version of the truth.

In my example in Figure 2, the Level 1 DSO is the DPL. It feeds multiple stages with delta records. The Level 1 DSO is often used to serve some of the purpose of the CML, and is used to deliver new requirements and reloads without re-extracting from the source system.

Layer 5 — Business Transformation Layer

The business transformation layer (BTL) is the most useful stage of the LSA. It contains any business rules or transformations needed and is the only part of the LSA where it’s permissible to incorporate business logic. Many reporting systems make significant use of business logic to provide greater reporting capabilities than simply viewing data. For example, it is within the BTL that you combine different pieces of data or undertake complex calculations.

Within the LSA definition, the BTL is considered optional. This is interesting because in many situations, it is actually the most important and useful, so it is difficult to consider it as being unnecessary. However, when you think about simple data models that do not have any complex logic or data transformations, you could easily choose to not implement this layer. 

Features of this layer include:

• All business logic is contained within a single set of objects. This makes the system easier, and, therefore, less expensive, to maintain.
• Business logic processes data separately from either the extraction or reporting stages. This allows appropriate tools to be designed and used for each different task.
• The business logic is often the hardest thing to develop, and, therefore, can be the hardest part to move to another system. By keeping all the business logic within a single layer, you can enhance or change the extraction or reporting tools without affecting business logic.

In my example in Figure 2, the associated deliveries are found for each sales order in the BTL. Using this data, you can calculate some key pieces of information: Was it delivered on time in full? Is there an open quantity still on the order awaiting shipment? How soon after the order was the product shipped?

Layer 6 — Flexible Reporting Layer

The flexible reporting layer (FRL) is a detailed dataset used to provide data for reports, and is typically implemented by flat table structures (e.g., DSOs). It substantially aids reconciliation and support if the data within this layer is kept at its most granular and contains such key identifying fields as document number and document item.

All other LSA layers are not intended to provide data for reports. While SAP NetWeaver BW provides functionality to allow this, it is not considered desirable within the LSA. Reports that use data within this layer are typically detailed granular reports. High-level reports do not perform well when they use non-aggregated or highly detailed data, so these reports are not recommended for this layer.

The dimensional reporting layer supports high-level or aggregated reporting and the FRL supports detailed reporting. Therefore if you are only carrying out high-level and aggregated reporting, you need only implement the appropriate layer and not the FRL.

Features of this layer include:

• Without reducing the performance of the high-level reports, detailed reporting is provided
• Reconciliation is easy when you can view reports that contain the finest level of granularity

In my example in Figure 2, order reporting could be provided by a DSO in the FRL.

Layer 7 — Dimensional Reporting Layer

The dimensional reporting layer (DRL) contains an aggregated copy of the data. Given this aggregation, it is significantly smaller than the original data set and therefore reporting performance is improved. The DRL is implemented using InfoCubes or other dimensional structures. It is not possible to implement this layer using DSOs or similar flat tabular structures. In SAP NetWeaver BW 7.3, it is possible to implement this as a HybridProvider.

Features of this layer include:

• The dimensional structures can achieve high levels of reporting performance
• The reporting layer can be modified and tuned to deliver reporting without any of the business logic being touched
• Aggregation can occur within the data (condensing your data into fewer records can positively affect reports)

In my example in Figure 2, the DRL has a high-level InfoCube providing aggregated reporting on sales orders.

Layer 8 — Access Layer

The access layer (AL) does not store data. It acts as an intermediary between the reporting layer and the storage layers. It is, in effect, a view that the reports use to bring together data from one or more different storage objects. Typically it is implemented as a MultiProvider or an SAP BusinessObjects universe. Even though the MultiProvider can have a single InfoCube, future modifications are anticipated by the system and delivered without completely rewriting the reports. In SAP NetWeaver BW 7.3, it can be implemented as a CompositeProvider.

The main feature of the AL is that it acts as an isolator between the reporting layer and the FRL and DRL, which means you can modify the FRL and DRL without affecting the reporting layer.

In my example in Figure 2, a MultiProvider has all the reports built in the AL. The MultiProvider contains InfoCubes that are partitioned according to geographic region.

Layer 9 — Reporting Layer

The reporting layer (RL) contains all the executed reports. You can use a variety of different technologies (e.g., BEx, SAP BusinessObjects BI 4.0) to implement this layer.

Within the LSA, the choice of reporting technology remains separate from the data model. Within an SAP landscape it is now possible to change your reporting technology without affecting your data model.

In my example in Figure 2, there are several reports built on the MultiProvider. These can be built using BEx technology and delivered via a Web browser.

Possible Impact of HANA

The LSA concept remains relevant within a HANA environment. The technical challenges associated with building a data warehouse will persist, such as the need to store data, perform calculations, and provide access for display within a report. In addition, business requirements continue to change, and demands for ever-larger volumes of data continue.

HANA may offer substantial performance improvements when compared to existing data warehouse systems. SAP has achieved this by using software and hardware innovations, such as in-memory storage, columnar databases, compression, partitioning, and parallel scaling over blades.

The HANA roadmap tells us that in the future, it will be possible to run SAP NetWeaver BW and SAP BusinessObjects within HANA. However, not all SAP products are yet able to run on the current release of HANA. As the product is developed and the first implementations are completed, the benefits of HANA can be confirmed.

HANA may provide vast improvements to data processing and data retrieval. Given the high cost of HANA, it is not appropriate for archiving, backup, or long-term storage of data. Therefore, HANA will affect the DRL and FRL of the LSA, while other layers, such as the CML, will be unaffected.

With or without HANA, LSA provides an SAP system many benefits, and can ensure that your data warehouses meet future demands. Now that you understand LSA, I recommend that you consider your existing data model and see how it translates to LSA. Concepts can be implemented now or when future projects allow.

George Campbell-Kelly

George Campbell-Kelly is a certified senior BI consultant at Bluefin, the United Kingdom’s largest dedicated SAP consultancy. Since first working with SAP BW in 2000, he has led the delivery of BW systems that operate with SAP R/3, SAP CRM, and Oracle JDE.

You may contact the author at george.campbell-kelly@bluefinsolutions.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.