Do you speak SAP HANA®?

Of late there has been hardly one week in which we were not asked if our dab:Exporter 3.0 data extraction software was compatible with SAP HANA®.

Of course, as the producer of an SAP®-specific data extraction solution we must and will deal with the problem, and are already in the process. Nevertheless, here too it is a matter of staying calm and not falling into a state of hectic floundering or shock as soon as you read or hear these four letters – HANA – somewhere.

What ac­tu­al­ly is SAP HANA®?

SAP HANA® (previously High-Performance Analytic Appliance) is an in-memory database platform that exists fully detached from SAP® Business Suite applications (ERP, CRM, SRM, etc). Being hybrid memory, SAP HANA® is able to save and process data both column-oriented and line-based. Data permanence is naturally secured by a persistence layer. This is especially important when you consider that SAP HANA® is also meant to take a strategic place as a database under transactional SAP® applications, and is not only intended for use as an SAP® BW substitute or analysis platform. The article in the magazine >Computerwoche< "In-Memory-Konzepte im Vergleich" [In-memory concepts compared] by Susanne Franke in April 2014 provides quite a good summary.

The im­pact short­term

I cannot yet fully judge what that means for the world of big data analysis, but here are two thoughts to start with:

1. Say you have an SAP HANA® instance available as a pure analysis platform. Then you are faced with the challenge of filling it with data from transactional systems. It is difficult to say whether or not this always works to your full satisfaction for auditing purposes. Thus, today you relatively seldom find elementary important information like SAP® change documents in the BW systems actually intended for analysis purposes. So SAP HANA® as an analytic platform for auditing purposes will only work if ALL necessary data sets are filled, and these are present in a comprehensive history. It remains to be seen to what extent the in-memory effect impacts these quantities of data.
2. If SAP HANA® is used directly as a transactional database under SAP® Business Suite applications, that will probably and mainly be for the reason that the processes mapped are very much critical in terms of time, call for extremely short response times, or present analysis and formating, necessary in the transactional systems, should be significantly speeded up. In this scenario a concern of auditing or other business units strikes me as really "untoward": That in turn large quantities of data including change documents should be directly analyzed on precisely this critical platform. So I think the subject with the sacred cow is more likely to become aggravated.

If I may draw a short conclusion in between: The demand by internal auditing and other areas (e.g. accounting for double payment analysis) for data extraction software and their "own" analytics tool will not reduce shortterm or even disappear. For this reason it is important for us to have the certainty that dab:Exporter also works with SAP® applications that use SAP HANA® as a database.