3.3 The (yet) unknown option: SAP HANA as “Corporate Data Pool”

Let me at this point remind you of two important assumptions I have made before:

1. At this point we still treat SAP HANA as “simple” database
2. My approach is to re-use the data management technology that the SAP systems use or will use pretty soon anyway (that is: HANA) in order to leverage synergies. I am not trying to provide a comprehensive comparison with other technologies.

For the technical concepts of HANA I would like to direct you to the respective SAP websites which you will find under the "More on this topic" link above. It would exceed the scope of this blog to reiterate everything. So I will rather give you a summary of how I answered the list of requirements I presented in chapter 3.2 in real customer situations. Before I do this let me briefly explain where in the product lifecycle HANA currently is.

HANA came to market in late 2010 after several years of research and development outside of SAP. In several steps SAP first moved isolated small applications and accelerators, then its data warehouse and finally the ERP-system (SAP Business Suite, formerly known as R/3) onto the HANA database. This means that for more than five years we know how to operate systems on HANA and we have quite a number of productive SAP customers running mission-critical applications on it. There are analytical systems on HANA in the market with up to 100 TB of data and more. So HANA is obviously able to handle a big load. We also have non-SAP applications built from scratch on HANA, oftentimes implemented in Java. We have pilot migrations of existing mission-critical non-SAP applications on HANA but not yet productive. And we do not have a Corporate Data Pool on HANA implemented in productive environments yet.

What I intend to do here at this point in time is to prove to you that the concept of a Corporate Data Pool on HANA works and that you should therefore start to think about a roadmap how to get there immediately –  because your competitors might do it right in this moment, too.

Now, back to the list from chapter 3.2. We know from over five year’s experience with SAP systems that HANA is extremely fast and that it works as designed. The interesting and totally unknown part of the story (up to now) is that all of this works in pure non-SAP environments as well. Later in this blog I will describe in greater detail some of the exciting results we got. What we learned in our projects is that for the implementation of a Corporate Data Pool the most important feature is primarily not a low response time. It is the ability of massive parallel processing of different requests expecting different data models which is in the case of HANA just amazing. At least if you have enough computing cores in your hardware but this is neither a big issue nor a major cost driver anymore nowadays.

With that we can check almost all of the requirements from chapter 3.2 However there is one tricky point in the list which to my experience is widely misunderstood in the market and – sorry SAP: you are not doing a good job in explaining it. I am talking of “4. Protection of investments - existing applications continue to run on HANA” which means nothing less than protection of thousands of person days in business logic in C# or Java or anything else. The perception at many customers, SAP and non-SAP, is that they can only use HANA if they either a) run SAP software on it or b) develop their application from scratch. An important part is missing:

Fact: Existing (non-SAP) applications run on SAP HANA!

Here is the full truth:

• We can migrate any data from any source (including mainframe) to SAP HANA.
• Any application implemented according to the client-server paradigm with the respective technologies will run on SAP HANA but please do not expect to run Cobol code from your mainframe on HANA. This has nothing to do with HANA, this code won’t run anywhere else either. But there are tools and methods to bring it into the new world.
• The applications will need adaptations. The effort largely depends on how many proprietary technologies from other vendors you use (like PL/SQL in the Oracle world). My team and I have moved Java applications to HANA where the adaptation work was done in less than three days.
• The adaptations usually need to be done in the source code of the application. This means if you are not the owner of the code you will have to talk to the respective vendor or service partner. 

"Moving" applications in the sense above means that we migrate the data from the relational database to HANA, we keep the application on its server and we connect it to the HANA database.

For now the conclusion is: SAP HANA matches all of the requirements from the list in chapter 3.2. And it does most of it out-of-the-box. Therefore it is technically feasible and obviously beneficial to use HANA as technology for our Corporate Data Pool.

In chapter 4 I will go into more detail what exactly happens when we do that.