Understanding HANA

Home / Blog / Understanding HANA

I finally get it now 🙂  I’ve been trying to understand the deal with HANA for quite a while, and thanks to a very enthusiastic presentation by Dr. Jeff Word.  Jeff was one of the original founders of the HANA concept, so I can see why he is so passionate about the topic.  Now, I’m paraphrasing a lot of this, but let me give you the layman’s version.

The whole reason HANA was invented was because of hardware constraints.  It’s been a while since I took physics, but the basic concept is that hard disk drives (HDD) cannot possibly retrieve data any faster than they do today.  We have truly reached the physical limits (per Newton’s Laws) so HDD can never deliver data any faster than it does today.  In addition, you can’t read and write simultaneously to the same drive.  This alone increases the time to retrieve data because you must write to one drive, read from another and eventually marry the two sets of data, most likely using even more reads and writes.

HANA solves this by eliminating HDD’s and reading at the speed of light, using RAM.  By eliminating the hardware constraints, you finally move away from the long reads and writes.  In some instances, seeing 100’s or 1000’s of percent improvements.  In addition, this means that the application layer (SAP, ERP, or whatever) no longer needs to do all the additional logic to speed up DB reads.  Now, I’m a programmer, so I’ve found that there are a lot of tricks that can be done to improve runtime.  You can use temporary tables, loops instead of selects, and lots of additional logic.  All of this logic is done because the DB reads won’t get any faster.  With HANA, all that logic is obsolete.  According to Dr. Word, 90% of the code in R/3 (ECC) has been deleted in S/4 because now the DB does the work.  Hence why S/4 MUST use HANA.  Without HANA, S/4 would immediately crash and burn.

In addition, HANA isn’t SAP specific.  It is truly another DB that can provide lightning fast response time to any application. This means that companies can now run a single DB for ERP, BI, and any other application you want or need.  No more replicating data to a specific BI system, you just read the original SAP DB because it is so fast that it won’t be impacted by large queries.

One of the major things that struck me as interesting is that S/4 stripped out a lot of tables that are no longer needed.  For example, BSEG can now be read directly instead of using all the helper tables like COSP, COSS, etc…  but to make sure that legacy customer code continues to work, the old tables remain as views.  This means no custom code will be impacted and the read times will still be lightning quick.

So, those are the high points of what I learned.  Overall, I really liked understanding the whole point of HANA.  It finally turned the light bulb on for me.  However, at the end of the day, I still look at things the same way.  SAP marketing is still implying things that a DB alone cannot provide.  For customers on existing SAP instances (with the exception of BI), there is little financial reason to jump in and convert to S/4.  The system is cool, the premise is sound, but in my humble opinion, the ROI isn’t there for customers with an existing SAP system.  New installations without question, should do HANA, and consider S/4 (S/4 is still rather new, so it would take a lot more due diligence to determine how stable and how well it all works).  On the bright side, SAP has extended maintenance to 2025 for all the existing stuff.  So the rumors I heard about forcing everyone to HANA in the next 2 years seems to be false.  To me, it looks like SAP is working REALLY hard to sell HANA and S/4, as many other companies seem to be of the same opinion.  I guess only time will tell.

Thanks for reading,

As always, thanks for reading and don't forget to check out our SAP Service Management Products at my other company JaveLLin Solutions,
Mike

Leave a Reply

Your email address will not be published. Required fields are marked *