SAP BW/4HANA has been on the market since 2016. SAP BW/4HANA brings many changes and advantages in the areas of architecture, agility, performance, and modeling.
To fully exploit the potential of SAP BW/4HANA, it is important to have a modern and flexible architecture in place.In our opinion, theintroduction of SAP BW/4HANA should therefore not be limited to the technical migration of existing, historically grown SAP BW systems. In this article, we would like to outline our idea of a modern and flexible SAP BW/4HANA architecture.
Problems with SAP BW – Does this sound familiar?
Thanks to our many years of experience with SAP BW systems, we know that difficulties can often arise, especially after a BW has been in operation for a long time. Perhaps you are familiar with one of these problems:
- Long response times for reports
- Increasing loading times lead to waiting times
- Redundant data storage
- Inflexible data modeling
- Long development times
- Increasing maintenance requirements and costs
- Lack of acceptance
- Shadow IT solutions alongside SAP BW
This trend is accelerated by the fact that the requirements for a modern data warehouse have changed and expanded significantly. Whereas in the past the focus was primarily on establishing a single point of truth with high quality and stability, the focus is now shifting to the integration of new data (IoT/social/geo, etc.), expectations of shorter release cycles, and agility and flexibility. Operational systems such as S/4 HANA are also increasingly offering integrated analytical capabilities.
In the past, SAP BW data models were often structured according to the so-called Layered Scalable Architecture (LSA). At its core, LSA relies on redundant layer-based modeling. The idea behind this is that processing data in layers increases its analytical value. Reporting is therefore only permitted on the top layer. This LSA architecture offers a very high level of stability, which is also the biggest disadvantage of this approach. The high level of stability also results in a high level of inflexibility, which quickly makes adjustments very costly. Agile and iterative developments are almost impossible to manage. In addition, it is neglected that in many cases source system-oriented data can have analytical value. SAP S/4 HANA, for example, offers ready-made analytical models to a data warehouse. The dogma of mandatory redundant data storage in layers simply does not make sense here.
For this reason, we are convinced that the technical migration of LSA data models will not ensure that the aforementioned problems can be overcome in the long term.
New principles for SAP BW architecture
New design principles are needed for the design of SAP BW systems, which form the basis for a new architectural design. All considerations regarding the architecture must be measured against these design principles. We have established four key principles for the architecture of an SAP BW/4HANA data warehouse, which we would like to explain below.
Simple
The data warehouse architecture should be as lean and simple as possible. The data warehouse service level is driven by business requirements, not dogmatic design specifications. This means:
- Reduction of mandatory shifts to two for data acquisition and provision.
- InfoObjects are only used when necessary or useful—modeling is generally field-based.
Agile
The architecture should support agile methods through technical means and an "evolutionarily good data warehouse design."
Business logic and joins should not be consolidated and persisted in large objects if possible. Instead, modeling should be carried out using easily expandable modular satellites. Logic should either be executed virtually or stored in data marts, encapsulated as much as possible. Duplicate data storage should be avoided. The principleof "virtualization as much as possible, persistence only where really needed" applies.
Open
I need to integrate SAP BW into the company's analytical platform. The architecture must therefore be open in terms of:
- Integration with big data and advanced analytics
- Provision of data to non-SAP BI tools
- Provision of data to other applications
- SAP HANA mixed architectures
Flexible
The days of LSA architectures with generic, universal development specifications are over. A strict set of rules with dogmatic specifications will no longer work. SAP's concept for LSA++ offers a more flexible, needs-based approach. What is needed is a flexible, modular "blueprint" that can be adapted to the needs of individual companies.
ISR reference architecture – based on LSA+++
For this reason, we at ISR have developed a modeling guide for our customer projects that is based on the above principles.
Our ISR architecture model does not describe a single approach that must always be followed, but rather a modular system that can be flexibly adapted to customer requirements by describing recommended modeling variants and scenarios. It also includes reusable "building blocks" for specific problem solutions (historization, master data modeling, , etc.) as "good practice" derived from practical experience. Our architecture design is strongly based on the LSA++ architecture approach recommended by SAP. In the following, we explain the basic ideas and design of our architecture.
Every customer situation is different – that's why our blueprint leaves many modeling options open, but includes detailed recommendations based on practical experience. The architectural design allows for a largely virtualized data warehouse as well as more traditional approaches.
The first mandatory layer in the architecture is the acquisition layer. Data is not stored (as a rule). The layer is purely an integration layer and is divided into three areas (separated by type of data integration). No data is stored on this layer. Essentially, this area only contains the data sources and source system connections.
In the RAW area, raw data from the source systems isstored in a source system-oriented manner. There is no integration across multiple source systems. Likewise, no business logic or data harmonization is performed. However, it may be necessary to make technical adjustments (data types, adding load timestamps, etc.). InfoObjects are only used when it makes sense to do so (business content, performance, etc.), i.e., modeling is always field-based.
Business logic is implemented in the "Business Integrated"area. This is where the actual "integration work" takes place. Persistence in this area should be avoided as far as possible. The principle of "virtualization first" applies. Processing logic can be implemented using both SAP BW transformations and HANA calculation views. In practice, depending on the amount of data, not all logic can be executed virtually. Logic can be persisted in data marts.
Data
Marts
are used to create persistence on a case-by-case basis. This can be done, for example,
for performance reasons or if a use case requires it.
A common example is histories, but also aDSO for
planning.
Für die Modellierung von übergreifenden, wiederverwendbaren Stammdaten haben wir uns aufgrund Ihres übergreifenden Charakters für den eigenen Bereich Master Data Area entschieden. Je nach Anwendungsfall werden fachlich definierte Business Objekte durch InfoObjects, sog. logische “Link-InfoObjects” oder openODS Views bzw. Calculation Views gebildet. Für die Modellierung von Stammdaten, Ablage und Integration mit Bewegungsdaten gibt es mehrere Entwurfsmuster (persistent <> virtuell, agil <> stabil), welche wir anhand der Kriterien Performance, Offenheit, Flexibilität, Einfachheit und Aufwand bewertet haben. Insofern gibt es nicht die eine richtige Modellierung. Fallweise muss geprüft werden welches Szenario sinnvoll ist.
Finally, the data is made available to BI tools and third-party applications (OutHub) as part of thevirtual layer. The layer contains only virtual objects, such as composite providers in SAP BW or calculation views in SAP HANA.
What is the right answer for you?
Classic response from the consultant: "It depends."
At a high level of abstraction, the basic SAP BW architecture—if based on LSA++—will look similar to the ISR pattern. The decisive factor is the specific design of the architecture in a solution design tailored to the respective situation. These design specifications define modeling requirements, show design patterns for your own use cases, define a distribution between SAP BW and HANA SQL, etc.
With SAP BW/4 HANA, many forms of data modeling are conceivable (see figure below). Our customer, BwFuhrparkService, for example, opted for a highly virtualized BW/4 HANA architecture. The initial situation at BwFuhrpark was similar to that described above. In this case, a consistently new architectural approach yielded many advantages (e.g., a significant reduction in development costs). More details about the project can be found here. For one of our long-standing customers in the energy sector, on the other hand, the key to success was to focus closely on optimized BI content. Click is the customer reference.
The examples also show that there can be no universal, blanket definition of architecture that fits every customer situation. The truth will lie somewhere between the architectural variants presented and must be the right one for the situation in question. The variants outlined are merely food for thought and are not meant to be judgmental.
How do you find the right architecture?
Our contribution has made it clear that there can be no blanket recommendations. Therefore, we can only outline the path (see also Road-2-BW/4HANA) to determining the target architecture. We generally proceed in three steps to define target architectures:
SAP BW/4HANA Workshop
In this workshop, we will cover the basics of BW/4HANA, modern and flexible architectures, agile data warehousing, and migration options.
The focus will be on a discussion with you about your situation and requirements. As a rule, an initial architecture idea will emerge during the course of the workshop.Quick check of your existing architecture
Assess your existing BI architecture with the aim of gaining a good understanding of your current situation and your vision for BI and analytics.- Architecture recommendation
Based on the insights gained, we work with you to finalize your architecture and create a solution design.
We would be happy to determine whether and to what extent all of these steps are necessary for you in a free preliminary consultation.
Christopher Kampmann
Head of Business Unit
Data & Analytics
christopher.kampmann@isr.de
+49 (0) 151 422 05 448
