Risky bet or Hana on GitHub?
Good software can become even better if, for example, the underlying database platform, the operating system and the hardware become better. A trivial insight that can be observed in all IT areas. But what if the interfaces between application, middle, DB and hardware are hardwired?
Many years ago, numerous colleagues were able to "boost" their SAP ERP system by switching databases. At that time, I had become Group CIO with a lot of enthusiasm and we were faced with the decision: continue with Oracle or accept IBM's very tempting offer for DB2? SAP itself made a risky bet with Hana: Hana has no added value! Hana can be an excellent database platform for S/4 - but nothing more. "Don't be immodest," my wife admonished me when I told her about this column, "At the end of the day, you have to get along with me for life, too - or are you cheating lately?"
I immediately replied: "with lifelong and undivided loyalty", but said that I could take her to the sea as well as to the mountains on vacation. With Hana, I can only run S/4! Ex-SAP Chief Technology Officer Vishal Sikka had quite different plans. He wanted to establish Hana as a new offering in the database market, and he dreamed of broad Hana deployment beyond SAP's ERP. There were even plans to position Hana as open source, and Sikka presented some startups in Palo Alto, California, that were starting to implement their innovations on Hana.
My SAP regulars know that Vishal Sikka now has a consulting contract with Oracle and that there are no longer any start-ups fighting for Hana in the long term. Hana is an SAP software product like many other applications and this circumstance is a risk for us existing customers: Who will develop Hana further? Who is firing up Hana with new algorithms? Who will take care of an ecosystem around the Hana database platform? Who will bear the costs and license fees for parallel DB operation with Hana and AnyDB?
Because Hana is singularly located in the SAP world, SAP also remains the sole responsible party for this product. This is a great responsibility - and it is to be feared that SAP will not always be able to live up to this responsibility in the turbulent years to come. Already, there are calls for a Hana 3, which has been falsely announced again and again by Editor-in-Chief Färbinger - as if he could force SAP to do so. Regardless of his fantasies, however, a Hana retread is in the offing.
SAP is still in talks with Microsoft, IBM and Oracle regarding a conciliatory AnyDB transition period until 2030, but mistrust regarding DB strategy is high between the parties. Another DB switch from Hana to AnyDB for an S/4 successor might be arguable from a business perspective, but it would organizationally overwhelm most SAP IT departments.
SAP will continue to meet its obligations with regard to Hana maintenance in the coming years. But the question is: Who will continue to develop Hana innovatively? There is no free Hana community. There are no start-ups eager to develop on Hana. There is no market for Hana add-ons and services outside the narrow confines of S/4. SAP bears sole responsibility for Hana.
One solution to the dilemma would be to fall back on Vishal Sikka's idea and release Hana into the open source scene: in other words, to deposit the Hana source code on GitHub and hope that free developers will also find interest in developing the database system further. A very bold idea would be, for example, to run this open-source Hana together with IBM and to bring it into a joint venture with Red Hat. Our young software developers get misty-eyed at the combination of IBM Power, Red Hat Linux and Hana. Okay, dreaming is also allowed in the SAP community - but we all need a viable solution for Hana together.
