Skip to Content

Are we putting the cart before the horse?

Recently I read a blog: “Vishal Sikka Gets Real on SAP HANA Benefits and Barriers”. URL:

Here is one small part from that blog:

========================================================================== What keeps you up at night about SAP HANA?

Sikka: The adoption, the training and so forth. There is a strong temptation to fall into the trap of the traditional, middle institutions—the systems integrators. And nothing against the systems integrators—they are great partners of ours. But we want customers to control their own destiny. On the one hand we have this strong strategic need to not have the partners come in to implement HANA. If that happens, then we have failed, and Hasso told me that. But on the other hand, we are not there yet, in terms of training, the examples, etc.

And also, to mature the product—to scale it, and to make it incredibly bullet proof, which takes decades for companies like Oracle and IBM to do.


I’ll revisit and explain the significance of above statements later in this blog. First please let me explain my background:

I began my career as a Software Developer in 1988. Initially I worked in a project using C-ISAM routines developed internally by the company I worked for. Unix was our operating system. I don’t remember a day Unix system staying up all day; the system crashed at least once every day. Anyone could crash Unix system those days. Unix used to be so sensitive.

A few months later, we decided to use RDBMS. We considered Sybase, Informix and Oracle; finalized on Informix based on price.

We started with Informix Standard Engine. Our development database size used to be 10-50MB(yes, Mega Bytes). We used to take good care of our database. We used to shut the db down every day before leaving for the day. I believe it was one of the best practices recommended by the vendor. And almost every day either DB or Unix would crash due to either heavy load – 2 to 3 developers compiling concurrently used to be the definition of heavy load – or Informix’s/tool group member’s programs accessing illegal area in memory.

DB or Unix’s crashes used to be normal. This continued – gradually decreased of course – for several years. In 1994, while working for a customer in US, the database crashed. The crash was due to disk error. No striping or mirroring was popular in 1994. We used to take back ups but not logs. So we couldn’t do point-in-time recovery. We tried very hard to fix the disk – because that was a payroll week, all processing was completed during the day after backup – by speaking to the vendor. They dialed in using 9600 baud rate modem and tried everything they could to get it fixed. We worked all night. No, nothing worked. We lost data.

In 1996, I worked on non-SAP Data Warehouse project for a very large telecom company. It was one of the largest databases at that time, 500GB. The database was Informix on HP-UX 9000, very powerful server at that time. Both DB and the server(to a lesser extent) used to crash. The DB’s version was 7.0(or 7.1?); we upgraded to 7.3 to minimize the number of crashes. 

From 2002-2005, I was working on both AIX-Oracle and z/OS-DB2 environments. Both DB2 and Oracle used to crash(fail-over) despite vendors working with us full-time. We used to move BW from one LPAR to another during quarterly-end processing leaving only R/3 running in that LPAR. That’s how we accomplished scalability in 2003! Of course, moving BW to another LPAR made new LPAR hang. Basically we moved chaos from LPAR A to LPAR B to LPAR C etc.

From 2006-now, db crashes are not that frequent; last DB crash was in 2009 Dec. I’ve read blogs discussing DB crashes while importing DB during Unicode Conversion recently.

Now let us revisit the paragraph – or Q/A – I posted at the beginning of this blog:

========================================================================== What keeps you up at night about SAP HANA?

Sikka: The adoption, the training and so forth. There is a strong temptation to fall into the trap of the traditional, middle institutions—the systems integrators. And nothing against the systems integrators—they are great partners of ours. But we want customers to control their own destiny. On the one hand we have this strong strategic need to not have the partners come in to implement HANA. If that happens, then we have failed, and Hasso told me that. But on the other hand, we are not there yet, in terms of training, the examples, etc.

And also, to mature the product—to scale it, and to make it incredibly bullet proof, which takes decades for companies like Oracle and IBM to do.


Dr Sikka says it took decades for companies like Oracle, IBM to stabilize it, scale it and to make it incredibly bullet proof. Yes, it took decades;Anyone disagree?

Here is what Larry Ellison said last year regarding SAP’s HANA: Source:

Get me the name of their pharmacist,” Ellison said at the time. “I mean, I know a lot about in-memory databases. In fact, we have the leading in-memory database, TimesTen. This is nonsense. There is no in-memory technology anywhere near ready to take the place of a relational database. It’s a complete fantasy on their part.”

Ellison also implied that SAP simply doesn’t have the technical chops to deliver on its vision.

“An in-memory database is enormously complex. We do a lot of in-memory database work. It’s an enormously complex job,” he added. “If they’ve been working on it for a decade or so, or a couple of decades, maybe they’d be getting close. It’s just so absurd that it’s very hard for me to comment with a straight face. They should just keep to accounting.


Based on my experiences and background, here are my thoughts on HANA:

  1. I know 10+ years ago, most customers began their BW implementation poorly; that practice still continues. I know co-workers who asked me how to create a cube with absolutely no background/knowledge on Star Schema or traditional(heard of 3rd normal form data models?) schemas. All they wanted to know was the steps to create a cube using RSA1. Yes, creating a cube is not that difficult using RSA1. They learned that, copied the data model/flow used by others, used BW buzz words to impress everyone, started implementing BW for the customers/employers. I know situations where cubes were copied 1:1 ratio in data mart scenario(Does this make sense?) and then asked Basis team to optimize the data load runtimes from cube A to Cube B with dimension tables as large as fact tables(60m+ records). It seems we’re starting to make similar mistake(see (4) below) on HANA.
  2. Vijay is asking great questions(How much of the game will HANA change?). I agree. Timing of some questions?. Larry Ellison says an In-Memory solution would take at least a decade if not couple of decades. I know he exaggerates. SAP has been working on HANA for probably 2+ years. Too early for scalability, MPP-type questions in my opinion. 
  3. As long as SAP doesn’t make serious design mistakes – I’m sure they wouldn’t -, it would be easy to scale(or find a way to scale) later once the solution is identified and HANA becomes stable. 
  4. In my opinion, in order for SAP not fall into the trap of the traditional, middle institutions—the systems integrators, I guess SAP needs to come up with innovative ways to identify and train people based on their experience, skills, aptitude, background, suitability, adaptability etc. The quality of people who implement initial HANA projects would play a critical role in HANA’s success.
You must be Logged on to comment or reply to a post.
  • Hey Bala, great blog.

    Earlier today , David Hull and I had the exact same conversation on evolution of DB2 and ORCL databases.

    Best case: SAP probably does not need as much time as IBM or ORCL took in past since they would have learned by watching these things work with SAP products before.

    Worst case: SAP will need to hire some top notch experts from the deep DB and systems programming side, and assign an army of developers to make HANA fly through the maturity curve. And throwing more people seldom solves design issues – it can probably do patchwork faster. You cannot take a stance with a foundational layer like DB that let me make 3 things right and worry about the other 7 next year. Those days are over – competition will make it hard for SAP.

    I still think SAP will be very successful with HANA.

    1. Organization wide -from Chairman to lowest rung developer – every one sings from same sheet on HANA. It is clear that they won’t walk away from HANA, and hence it is a safe investment, and customers can buy for early mover advantage.

    2. Customers and Partners who have lived through the “open an OSS note for every installation of R/3” period in the 90’s – they won’t mind treating HANA as a 1.0 product.

    3. HANA will be successful the moment SAP comes up with one or two killer apps. It is only a matter of time before that happens.

    4. SAP has one of the best sales team in the enterprise SW space. They know how to sell – and SAP has a huge pipeline for HANA from what they mentioned in earnings calls.

    5. SAP also has done extremely good marketing for HANA. So there is a good chance of that getting them some customer mind share.

    I don’t know what Vishal means by “There is a strong temptation to fall into the trap of the traditional, middle institutions—the systems integrators” .  I am trying to find out though.
    Without SAP themselves or SIs helping with first several implementations, I don’t see how all the customers in their pipeline will make a 1.0 product work.  HANA is not exactly like a download and install of an iPhone app 🙂

    • Hi Vijay,

      Your feedback means a lot to me.

      I’m extremely glad to read your comments. I truly believe HANA is going to be highly successful for all the reasons you stated plus the videos I watched both in HPI and I see perseverance, hard work, discipline, modesty, sincerity, respect for this community right from Hasso. They’re making every effort to build a strong team not just within SAP but outside as well.

      In addition, SAP is also taking social-centric initiatives such as EIDI(Embracing Inclusion to Drive Innovation). This IMO is such a nice and broad-minded initiative;I don’t know of any other company of SAP size focusing on EIDI or SCN development. All these measures are going – if not already – to really help spread the love for SAP and SAP’s technologies.

      You’re correct about “the system integrators”. I would like to know what he means as well.

      Thanks for your comments Vijay. I’m feeling so positive and excited these days due to HANA and other stuff I stated above.

      Best regards,

  • Hello Bala,
    great blog – really :-))

    Personally i would not count on Larry’s statements so much – we all know his relation to SAP and his well-known bizarre behaviour.

    I always wonder about HANA:

    1) Will it be stable in the first years? – No
    2) Will it be fully recovarable after some crash? – No (afaik has HANA always some small part of data loss in case of crash)
    3) Wlll there be a HA solution (like Data Guard) for mission critical system? – No (afaik there will be no feature like that)
    4) Will it be affordable for the complete systemlandscape? – Well right now i don’t know, because of the GB price

    Stability and fault tolerancy is one of the key components of a database for an ECC or BW system – and in this point i will agree with Larry.
    Nowadays it is an illusion, that you can replace your relational database with HANA because of that key components.

    I am also not sure about the current support quality of HANA, but if it “so bad” like the SAP standard support nowadays i would never put a mission critical system on HANA and with HANA we mostly talk about the huge systems.


    • Hi Stefan,

      Thank you. I guess we’re on the same page regarding Larry’s statements. The reason I wanted to include Larry’s comments was to illustrate the complexity of HANA;I don’t take his “decade or couple of decades” comment seriously.

      I agree with your “HANA replacing RDBMS” statement. However in TechEd, I heard HANA has started replacing legacy databases. Too early? I don’t know.

      Thank you once again,

    • Hello Stefan,

      just a few comments:

      1) That’s an assumption. Of course, it will be up to us to prove (together with customers) that HANA is enterprise ready.

      2) HANA does recover everything up to the last committed transaction.

      3) HA solutions are available. Technology depends on the hardware vendor (for example based on mirrored file systems). Please contact them.

      4) Affordability is realtive. He have business cases where customers potentially save many millions of dollars by using HANA for something they could not do before.

      It’s certainly not an illusion. Ramp-up for SAP NetWeaver BW powered by SAP HANA is planned to start in November this year.

      SAP Customer Solution Adoption (CSA)

      • Hello Marc,
        thanks for your reply and make some points clear.

        1) Well of course it’s an assumption – it depends on my experience with SAP database products (MaxDB) and its client components (ODBC and content server).
           I also agree with Bala, that it took a a while for other vendors to get their RDBMS “bullet proof” – so why should it differ by SAP? We will see.

        2) Thanks for the correction. I read an article a few time ago, that states there could be data loss of a few seconds (because of the storage layer and the log behaviour afaik).

        3) I think you misunderstood. I don’t mean fault-tolerancy (like disk crash or something like that).
           I mean full HA / disaster recovery solutions like automatic failover in data center far away without data loss or safeguard your SAP system against user or adminstration errors without full restore and recovery.

        4) Really? Are there some real-life examples right on the market that save such amount of money by HANA (even with its invest costs) or is this just a business study calculation?

        Well – we will see what HANA brings – i am very sceptic for the next years.


        • Hi Marc,

          3) As Stefan explained, what happens when disk is accessible but not memory? In BWA, the users would access the aggregates in that case. How to address that situation in HANA?

          4) What factors determine whether HANA is affordable or not? Is this still evolving?

          Thanks for your time,

      • 1) This proof may spoil some customer’s business. SAP should do its homework in labs first.

        2) The recovery cannot be compared to the traditional RDBMS’ recovery. It lacks transactional isolations on higher levels.

        3) This is true. HA for HANA is quite trivial.

        4) Please be precise here. If you could not do things before, you do not save $. You spend $ for new features.

  • Hi Bala,
    Very good background of HANA.
    I would not have known the scenes behind HANA had I not clicked on the links in this blog.

    Now what are the effective ways of training?
    1. Workshop for partner companies.–in my opinion this would be very effective. Am not sure of costing involved,though.
    2. There are already many notes uploaded in service portal for installation guides. When I tried opening the link, it asked for authorization.
    3.General user manuals – documenation.
    4. Would the existing documentation of ABAP statements in ABAP editor would be modified.
    e.g. Select —end select would not be a problem now for HANA…so how would these be added and  made known to ABAPers like us.
    5. How would ABApers know how and what syntax is going to be used back or not to be used with HANA inside?


    • Hello Kumud,

      1) Class room training is available: Go to and search for TZHANA.

      2) SAP notes and some part of the documentation are only available for customers and partners. If you are working at a customer, they can provide you access.

      3) Starting point for HANA documentation is As mentioned above you will need a logon to get some of the documentation on

      4+5) There’s no impact on the current ABAP language (up to SAP basis 7.3). Of course we will provide documenation for the next ABAP release and explain all HANA related features. There certainly will be additional training courses as well.

      SAP Customer Solution Adoption (CSA)


  • Hello Bala,

    thanks for the blog (and comments). It’s nice to see more discussions in the HANA space.

    Let me just add a little background on the SAP HANA database. The code inside HANA is not entirely now. To the contrary, it’s based on TREX, SAPDB/MaxDB, and P*Time database which all have been available for over 10 years.

    No one claims it’s easy to develop an in-memory database, but we did it anyway. It’s available and capable of doing incredible things. Anyone comparing HANA to a general purpose database does not get the point. SAP is in the market for business software. We are developing HANA to be the best platform (by far) for running business applications. It does and will have features that no other RDBMS (on disk or in memory) has.

    Of course we will support our Parnter Ecosystem in learning HANA and helping customers adopt the new technology. We already trained several partners, we ran a few know-how network calls,  and are in the process of publishing HANA related how-to guides. There’s more to come so stay tuned!

    SAP Customer Solution Adoption (CSA)

    • Hello Marc,

      Thanks for providing your feedback. At the outsetl, I would like to offer few clarifications:

      1) Why I quoted Vishal’s comments: To demonstrate his comments were not of “figure of speech” type;he was literally correct on “decades”.

      2) Why I quoted Larry’s comments:
            a) To demonstrate in-memory technology is complex
            b) To point out SAP has come long way since HANA announcement last year.
            c) To demonstrate HANA was Oracle’s “sour grape” last year; I mean he rejected HANA outright last year; This year he spent almost 25% of his time discussing Exalytics, Oracle’s In-Memory solution in OpenWorld. Oracle it seems is not only specializing in building stacks;they appear to be becoming the specialists in building layers as well:
               – Exadata (Optional)
               – Exalogic (optional)
               – TimesTen
               – Essbase
               – Exalytics H/W
               – Heuristic Adaptive In_Memory Caching(Larry is proud of the name)
               – Oracle 11g (either directly connected to Exalytics or indirectly using Exadata)
               – Oracle’s 11g’s SGA
               – Interactive UI

      Why compare HANA to RDBMS?
      HANA is completely different from RDBMS. We get it. Why compare HANA to RDBMS then? Because HANA is going to replace several layers, RDBMS is one of them, primary one. So why not use RDBMS to demonstrate the complexity of HANA and use the Life Cycle of RDBMS to get an idea on how long HANA’s maturity may take.  Wrong?

      Thanks once again for your feedback,

  • Hello Bala

    Nice blog, interesting way of placing things in prespective. I think I was lucky to be born in 1984, just in time to catch some parts in the history of computer technology. I still remember being hooked to Commodore 64 as it was yesterday.

    I still wonder when we can expect HANA to appear for SAP Business Suite products as DB (not for parts of it).

    I guess SAP might not know themselves yet but a prediction would be nice.

    Kind regards