How to Upgrade to SAP BW on HANA Roadmap
Customers who have already upgraded or are planning to upgrade to SAP BW 7.4 should strongly consider migrating to SAP HANA afterwards. In our FREE guide "How to Upgrade to SAP BW on HANA Roadmap"; we explain the different flavors of HANA implementations and the different strategies for upgrading and migrating to BW on HANA. The team at SAP has worked hard to rebuild the BW environment from the ground up in version 7.4, with much focus on completing the integration of BW on HANA. There are many options and paths to take in the journey and each opens up different possibilities for your organization technologically.
Some customers may choose the simplest path, accelerating their entire BW operations with HANA as a simple database accelerator. The performance benefits are astronomical in comparison to traditional RDBMS databases. The amount of processing now being processed natively in the HANA in-memory system by the BW system is nearly all there and cleaning closer to 100% with each service pack release.
Some customers may choose to unlock their HANA investment directly with HANA studio based modeling. Once again, the customer has several more decisions to make, which ATCG can help with.
- Will you want to migrate everything to HANA and retire your BW investment?
- Will you decide on a hybrid solution, leveraging your existing investment in BW and moving forward with new development natively in HANA?
- Will you dedicate HANA studio development to special applications and continue to leverage BW for its SAP ECC/CRM/SRM/APO integration capabilities?
- Will you merge your reporting capabilities with BOBJ BI by connecting to each system separately?
- Will you want to leverage HANA for SAP ECC and BW and simplify the "real-time" reporting gap?
Upgrade and/or migrate today by contacting ATCG Solutions. Don't forget to download our FREE guide that accompanies this post!
Our guide covers the upgrade and migration of a SAP BW 7.x to 7.4 on HANA environment. To discuss other scenarios, please leave a message in our download form and a representative will contact you shortly.
What is SAP HANA or BW on HANA?
The first thing to understand about SAP HANA is that it is both an in-memory database that can replace disk based DB's such as DB2, ORACLE, SQL. It is also similar to the concept of SAP Net Weaver, in that it can also provide a complete development environment. ABAP, sqlscript, data modeling, reporting, data loading, security and communications are all supported. This means that HANA can supercharge your SAP BW, ECC, SRM, CRM applications as well as non-SAP systems. It can also handle hybrid scenarios between HANA Enterprise, BW, ECC, and non-SAP systems.
The second thing to understand about HANA is that when combined with SAP BW, your development costs, time to market, and storage costs will be reduced. I know, I know, HANA is expensive, but it doesn't need to be either. That will depend on your roadmap and whether you decide to clean up your BW environment first and then migrate to HANA.
You see, BW was great at accelerating reporting and overcoming the limitations of traditional disk based storage. Data was copied out of the main ERP system to BW (PSA), then into a corporate memory layer (DSO). The data was further uploaded into OLAP specific info cubes based on the star schema. Smaller copies of the data were built and maintained based on the report requirements as either datamarts or aggregates or both. As you can tell, data has to be moved around many times and kept in sync at all points. Each of these steps is a possible point of failure in the data update and reporting processes. The storage volumes grow exponentially as well with each added reporting area and optimization step. This also increases refresh times and backup times.
As you may have guessed, all these steps require time to put together by an expensive BW resource. Not only are they having to model the same data over and over, they also have to maintain all the objects together, creating long complex process chains for automation of data loading, and always introducing limitations to the reports capabilities (loss of granularity in exchange for performance).
Data Volume Savings
When you move to BW on HANA, there will be an immediate compression of data due to the way HANA stores information. Aggregates for all info cubes in the system are also immediately disregarded, as are indexes. These steps will need to be removed from the process chains as well eventually. The info cubes themselves are also compressed after being optimized to in-memory models. Rather than having upwards of 36 tables between dimension tables, SID tables and fact tables, you now have one simple table with several partitions.
The next step is easier if your BW architect used multicubes as an abstraction layer in your data warehouse design. You will be able to simply swap out cubes for their predecessor DSO's and drop the cube data for great savings in storage cost.
Going forward, your development costs will drop since your BW developer resources will not have to decide between multiple copies of the data, create extra layers, or maintain as many steps.
Your refresh time's for the system will also improve dramatically after reducing the number of steps involved. Imagine a BW system that only takes an hour to refresh rather than all night and sometimes until the morning after people arrive in the office.
What Strategy Should You Choose?
I recommend Strategy #1 in our guide if you are interested in a quick win and aren't worried about the initial size of your BW storage. An immediate lift and shift to HANA will provide immediate benefits in terms of performance that will be greatly noticeable to your user community.
If however you prefer to minimize your HANA investment, I recommend Strategy #2. You would simplify your BW data models first, either in a side-by-side sandbox environment or in your dev box. There are ways to avoid disruptions in either scenario with careful planning. Strategy #2 involves setting up a BW on HANA sandbox that is a blank slate in regards to data models. You would then either continue to use your production system while migrating in parallel or if your scenario allows it, move over to BW on HANA and re-release the reporting areas 1 by 1. Each reporting area or data model would be simplified in the development environment and then transported to the new BW on HANA environment and loaded from scratch (take special consideration of the volume of any LIS related logistics data).
This option provides the cleanest end result, but also takes the longest to complete if you have a non-standard data warehouse model. It also helps minimize your upfront HANA costs.
Don't forget to download our FREE guide that accompanies this post to help create your own roadmap!
Check out some of my other related links on the topic of SAP BW 7.4 upgrades and migration to HANA.