Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 

This blog is the second in a series of three. Part 1 can be found here:"BW on HANA … Now What?" (Part 1 of 3).

As promised in the previous blog, in this blog I will present a stepwise approach to move towards the better SAP BI world described before.

Step 0: Migrate to HANA database

You already took this step, otherwise you wouldn’t have been attracted by the title of this blog. Am I right? (If not, contact me. I can arrange a discount 😉 .) As I said earlier, you will gain a factor 3 performance increase on average just by taking this step alone. You may be disappointed in the performance increase after migration for queries you already put a lot of effort in with “old school” methods such as aggregates and hot caching. Why is that? Because the old tricks also worked. But they took a lot more effort and maintenance.

Step 1: Use new (virtual) BW objects

Now that you have a high version of SAP BW software available, you can make use of the new BW objects: Advanced DataStore Objects (ADSOs), Open ODS Views and Composite Providers. Open ODS Views and Composite Providers are virtual, ADSOs are persistent. ADSOs and Composite Providers are combinations and simplifications of “old school” BW objects. With Open ODS views and Composite Providers you can build 100% virtual “data flows” in BW.

After migration, you will probably introduce the new objects in newly built data flows and data flows to be redesigned for some reason. You may even launch an optimization project aimed at replacing old objects by new ones in existing data flows …

Step 2: Pilot for Native HANA

… but in parallel you can explore the possibilities of Native HANA by starting a pilot project. To demonstrate potential business value, choose a reporting area that benefits strongly from real-time reporting functionality, and that does not require broad and complex data-integration. The pilot will get your organization acquainted with all the new backend and frontend technology and will demonstrate the added value that Native HANA may have for your organization.

Step 3: Mixed architecture BW/ Native HANA with BW in the lead

Once your Native HANA pilot project is finished, you basically obtained a mixed architecture of BW and Native HANA data flows in your data-integration platform. Nothing wrong with that. However, you should not confront your reporting users with different frontend tools for the different backend

scenarios. With BW still being dominant, it makes sense to have BW in the lead for frontend tooling. The Composite Provider objects makes it possible to combine persistent and virtual objects with Native HANA Views in one report. Below, this is displayed graphically. If the Native HANA data flow ends with one final step to a BW Composite Provider, users can still apply the frontend tools they are accustomed with to disclose the Native HANA data.

Step 4: Mixed architecture BW/ Native HANA with Native HANA in the lead

At a certain point in these developments, BW may cease to be dominant in your data-integration platform. This is the time to consider moving to frontend tools better suited or even specifically designed for Native HANA. In the SAP portfolio Lumira and Business Objects (BO) Cloud currently fall into this category. The integrating backend object for this scenario is the “Generated HANA View”. See picture below.

It is tempting not to take this step too early, as the before mentioned frontend tools are still under construction. Currently, the BW-based frontend tools offer more functionality and stability.

Step 5: Fully Virtualized Native HANA data-integration platform

A final step could be … abandoning BW altogether. A sad step this could be for a lot of people, for example … me. Sob. However, remember the “horror of data loading” as described in the previous blog, straighten your back, and just go for it!

Seriously, you may not get to this final step. But at least there is a clear roadmap of “next steps” following successful “previous steps”. You may need to slow down every once in a while to wait for SAP’s technology to become more mature. But I have confidence in SAP’s proven innovative power. Fully virtualized data integration is not a theoretical concept. It is doable, and sooner than we think.

Follow-up

Abandon the classical data warehouse. Or not? As noted previously, in certain situations data persistency in the data-integration platform is still required: historic data, “snapshots” and data from systems without direct access coupling. I will address this in more detail in the next blog, along with topics like the new BW objects, frontend tools, programming in Native HANA and any topics that you would like to propose. Just post your suggestions in the comments below.

The author works as Principal Consultant SAP Business Intelligence for Experis Ciber NL: http://www.ciber.nl/

Labels in this area