* This was originally a part of my SAPTechEd Aftermath, but 7 pages was too much for one blog.
I have a software engineering background, so the whole analytics story kinda shoots past me, but I have very nice colleagues who catch the ball and continue the game. I’m much more interested on how HANA will impact the applications we’ve been creating in the past years. I’m happy to say that my thirst for knowledge was plenished at this year’s TechEd.
HANA is not just about speed, it’s about simplification. The complex data model of SAP ERP and CRM is mainly due to the need of optimization and persisting complex calculations that could not be done in real time. These calculations are often done by batch jobs running at night. With HANA, you no longer need to persist this calculated data, but it can be done at runtime. This means you can simplify your data model, and you can drop these batch-jobs.
But it goes beyond that. Currently, every system has its own database and the only way to communicate, is by various interfaces. Think of all the BDOCs flying back and forth between CRM and ISU, or SD. Think of the IDOCs between SRM and ERP. Think of the extractors between BI and your other systems…
With HANA, you could put all your precious systems on a single database layer. All your data resides in a scalable HANA system, and all your SAP core software can run on top of the same physical appliance. That implies that: your BI system can now read directly from your ERP data, that your ISU and CRM can share the same information, that your purchase order from SRM is directly available in your ERP MM…
This is a massive simplification of your landscapes. Out goes the middleware between CRM and ERP. Out go the extractors between BI and your other systems. Out goes the interface between your SRM and ERP.
As a software engineer, that makes my life easier as well. I no longer have to worry about data-synchronization across systems. Instead, I can just work on the current data in ERP, which was just updated in CRM.
There is a third layer on this simplification. In HANA, you can create views. Nothing new you may say. I can create views in my data dictionary too. But there is a big difference though. In your current data dictionary, your views are actually very limited. They’re modeled and restricted to some simple joins and filters. In HANA, you can create scripted views as well; Views that use basic joins and unions, but also very complex calculation routines and parameterization. Compare it to what you do with your internal tables in the code now. You select data from various sources into internal tables. You perform a bunch of routines and calculations on it and you mash everything together in the end. You can move that entire logic into the HANA computing engine, and define it as a view. You can then consume this virtual view, as if it were a persisted table in the database, by again using simple, or complex, SQL queries.
A small reality check though. If you have crappy none-optimized code now, moving to HANA is going to be a painful operation. You will have to adopt a new way of thinking, and you will have to revise your data models, your ugly code and your architecture. Tools will not be able to do this for you. Tools may help you to identify the pain-points, but you will need skilled software engineers to help you through this. I foresee a lot of “development” work for the SI’s in the coming years.
I also see some issues in security and authorizations when sharing data between different systems. Suppose you don’t have access to a certain table in ERP, which contains highly confidential data. In BI however, you have authorization to check your models. So you have access to data in BI that is confidential in ERP.
I suppose that there are easy ways to prevent this, and that actions are being taken to align synchronization of authorizations, and to even move authorization from the application layer to the data layer. I just haven’t heard anything about it yet.