"Many roads lead to Rome." Following this guiding principle, there are many paths that lead to an SAP BW/4HANA system (
).
When defining your own Road 2 BW/4HANA, you need to consider both your current situation and the goals you want to achieve by introducing BW/4HANA. Your corporate strategy and IT strategy are also key factors in this context. In this article, we would like to clarify the paths that lead to SAP BW/4HANA, provide initial recommendations, and outline an approach that can help you find your Road 2 BW/4HANA.
A holistic approach is necessary
First, it is important to understand that SAP BW/4 HANA is not simply the next release of SAP BW 7.5. Its introduction will require major changes to the data model and structure. The number of BW objects has been reduced from 10 to 4. The "old" objects are no longer supported and must be migrated. 3.x data flows also no longer work and must be partially recreated manually. It should also be noted that row-by-row processing in ABAP routines is not optimal for the column-oriented SAP HANA database. The implementation of logic via code must be rethought and implemented differently (HANA SQL). Row-by-row processing in ABAP can only be accelerated to a limited extent because the type of programming is no longer optimally compatible with the database.
Finally, dependencies must be taken into account. The BEx Suite, which many of our customers use, is no longer supported. Although BEx Query is included in the new BW Query, there is no successor for the Analyzer or Web Application Designer, including support for migration. This means that a new BI tool must be procured. Integrated planning is also no longer included. If planning is to continue, migration to BPC 11 must take place.
The usual advice applies here. Talk to your account executive. However, as a general rule, new licenses must be purchased for SAP BW/4 HANA and BPC 11.
The explanations show that migration should always be considered holistically, taking all dependencies into account.
Paths leading to SAP BW/4HANA
SAP now offers a wide range of options for implementing SAP BW/4HANA. Depending on the initial situation, there are two basic approaches: new installation (= greenfield) or migration.
The following diagram provides a good overview of the respective variants:
The greenfield approachnaturally allowsa high degree of freedom in setting up an optimal data warehouse architecture and development methodology. For example, the approach allows the use of InfoObjects or field-based modeling from the outset, depending on requirements. If an existing SAP BW system is already in place, it is possible to transfer selected SAP BW/4HANA-compatible objects via transports. Customers gain the opportunity to learn from the past and rethink the data warehouse – for example, by virtualizing large parts of the data warehouse. On the other hand, existing investments in previous systems are largely discarded and effort is required to run the old and new solutions in parallel. In most cases, this approach will result in the highest level of effort.
There are three different approaches to migration that can be used to address many customer situations.
in-place conversion
- Migration to SAP BW 7.5 and installation of BW/4HANA Starter Add-On
- Gradual migration of existing data models to BW/4HANA-compatible objects
- System conversion to SAP BW/4HANA
- SAP BW 7.5 SP5 powered by HANA
Remote conversion
- SAP BW/4HANA will be newly installed and operated in parallel with the old system until it is replaced.
- Selective transfer and migration of data models, including data (e.g., requests), to a new system
- SAP BW 7.3 (in Any DB)
Shell conversion
- SAP BW/4HANA will be newly installed and, until it replaces the old system, will run in parallel with it.
- Selective transfer and migration of data models to new system (without data)
- Minimum SAP BW 7.0 (on any database)
In-place conversion involves migrating an existing system. This means that all objects and codings must be SAP BW/4HANA-ready before the actual SAP BW/4HANA update of the existing system can take place. Extensive preparatory work is required and is supported by various SAP tools. The advantages of SAP BW/4HANA can only be exploited at a relatively late stage because the entire SAP BW system had to be migrated at the object level before the actual update to SAP BW/4HANA could take place. Revising the architecture in line with LSA++ involves a lot of manual rework and is not part of a technical migration. In our view, this approach is suitable if the primary goal is to migrate an existing system to SAP BW/4HANA from a technical perspective and satisfaction with the existing solution is very high.
Remote and shell conversion take a different approach. Here, a new SAP BW/4HANA system is set up. Previous developments can be transferred selectively or completely. During this transfer, the necessary migration of objects is carried out. In contrast to shell conversion, remote conversion also migrates all data (including requests) from the legacy system. The advantages of SAP BW/4HANA can be utilized immediately. New applications can be implemented directly in the new environment. Risks are minimized by the phased parallel operation of the old and new systems. However, this can also result in additional effort. Because data flows are selected for migration, there is also a risk of transferring unnecessary objects to the target system, which leads to subsequent cleanups. From our point of view, however, there is a good trade-off between the opportunities offered by a greenfield approach and the protection of existing investments. That is why SAP often refers to brownfield or accelerated greenfield in these cases.
Landscape transformation allows multiple SAP BW systems to be consolidated into a central SAP BW system during migration. This involves combining the in-place and remote conversion approaches.
The detailed procedural models for the migration approaches are very well documented in several SAP blogs and provide useful assistance with implementation. For this reason, we will not go into further detail in this article. Instead, we want to focus on the approach to defining your own SAP BW/4HANA strategy.
Are there any general recommendations?
SAP has formulated generic recommendations for choosing your own path to implementing SAP BW/4HANA depending on your current data warehouse solution (see figure). These recommendations can be understood as a rough guide to which scenarios might be useful and what can be ruled out, for example, due to certain release statuses.
- Three check marks: Highly recommended path
- Two check marks: Recommended path
- A check mark: Possible alternative path
- Cross: Not supported
However, in our opinion, there can be no blanket recommendation that fits every customer situation. There are, however, key factors that influence the definition of your own Road 2 BW/4HANA.
- Effort required to perform the technical migration
SAP Readiness Checks can be used to analyze how many objects need to be adapted when migrating an existing system. This involves examining which objects are not BW-ready and why. Many objects can be migrated automatically. For some others (e.g., 3.x data flows), however, this is not possible. Manual rework is required in these cases. SAP programs can be used to create a worklist and estimate how much effort would be required for a migration.
- Effort required to perform the technical migration
If you do not yet have an SAP BW system but have already decided to implement SAP BW/4HANA, then the path forward is already defined. We are talking about a greenfield approach.
In many cases, however, the starting pointwill be an existing SAP BW system in which investments have been made over many years. We recommend first creating transparency regarding the problem areas and possible fields of action of the existing system. Infrastructure aspects (e.g., release status) as well as content-related aspects of the specific solution should be examined. If there are fundamental problems in the data warehouse, an in-place migration does not make sense. In these cases, a simple technology change would do little to alleviate the problems. If it is determined that satisfaction with the SAP BW system is very high and problems are primarily related to performance, in-place migration may be exactly the right approach.
It is also important to consider whether SAP planning solutions such as BPC or BW-IP are in use. Both solutions must also be migrated to SAP BPC 11.
- Target vision for the data warehouse
Certain goals are being pursued with the consideration of introducing an SAP BW/4HANA data warehouse. The goals should be transparent and clearly formulated. It is also important to consider the long-term orientation of the data warehouse or data management in the company so that future requirements are also taken into account. This raises many questions that should be considered: Should data science solutions be integrated? Should the data warehouse be further developed using agile methods in the future? Is a real-time DWH necessary? Are non-SAP BI tools used? Are there big data scenarios? Is an S/4HANA implementation imminent? etc.
All these aspects influence the target vision and the future role of a data warehouse in companies. The findings can be used to formulate requirements for the future data warehouse and allow conclusions to be drawn as to whether and what type of migration is possible.
- Target vision for the data warehouse
Only by comparing the initial situation with the objectives of the data warehouse can a "delta" be identified that needs to be bridged. This is where you can start to consider the best way to close this gap. The assessment can only be carried out on an individual basis.
Our approach for your Road 2 BW/4HANA
Based on our experience, we have developed a procedure for determining a Road2BW/4 HANA.
The first step is a 1-2-day joint workshop to prepare for all further steps. We will examine your situation and the changes brought about by SAP BW/4HANA (technical, methodological, architectural). We will also work together to plan the next steps and framework conditions. The aim is to create a common understanding of the implications of SAP BW/4HANA and to plan the next steps. Further details about the workshop can be found here.
It is helpful to examine the BI ecosystem with regard to the targeted target state or the goals of BI and, in comparison with this, to transparently record the actual state. If this examination is carried out in a structured manner with the right stakeholders, the result is a coordinated target system for the "new" SAP HANA-based system. By comparing this with the current state, recommendations for action can be derived and prioritized. We have developed our own methodology for conducting this analysis: BI maturity assessment. This involves analyzing BI systems in structured interviews from the perspective of up to six focus areas (architecture, organization, key figures & processes, users, application management, and data). The scope of the maturity assessment can be jointly determined during the preparation phase and can be designed in a modular fashion – a quick check of the focus area of architecture, for example, can be carried out within a few days.
As part of the maturity assessment, strategic objectives are also identified based on the IT strategy. This provides insights into the strategic direction of the company and its impact on the future data warehouse (3-5 years). If, for example, an initiative for agile working methods or the widespread introduction of IoT devices and big data in production is planned, this will have an impact on the requirements for a data warehouse.
With the help of the collected findings, it is possible to make a recommendation for the target architecture. In addition, migration paths are identified and evaluated in terms of cost and benefit. On this basis, it is possible to make an informed decision on the target architecture and migration approach. At this point, a great deal of information and decisions are available. The next step in creating Road-2-BW/4HANA is to develop a detailed plan for implementing the migration as preparatory project planning. This also incorporates the results of the SAP Readiness Check and migration process models (see example of shell conversion). However, these are adapted and planned in detail with regard to your specific case.
As a result, you will receive a coordinated and robust Road-2-BW/4 HANA for the implementation of your project (Fig.: Example of shell conversion).
Christopher Kampmann
Head of Business Unit
Data & Analytics
christopher.kampmann@isr.de
+49 (0) 151 422 05 448
