Dear SAP, Why Don’t You Make Hana A Success?

One reason the plan failed is because of the Hana XS Advanced development environment and its successor, the Business Application Studio, as well as the included administration tools. While they tackle nice technological challenges, they are not useful for customers and hence there was little market adoption. I have written about alternatives in the past already, so providing them should not be a problem for SAP.

The most important factors are the costs of Hana and the go-to-market. These can be fixed with the following changes.

Change One: One Hana code line

The Hana Cloud database is supposed to be a cloud-native database. As such, it must scale indefinitely, adjust fully automatically to the current workload within seconds, must not consume any resources when not in use, and yet, it has to have all the guarantees of a transactional database. All of this has been promised by SAP to be developed in a year – with one caveat: It must be developed from scratch, meaning a second Hana code line is needed.

Development did the sensible thing and containerized Hana. So, instead of installing one Hana database for one customer, a new container instance is started. This means little changes in the database core, only a stronger separation of the database files and the running instance. This is not fully elastic and has the same scaling limitations as an on-prem installed database, but it does bring the costs down. Most importantly, it was doable.

Looking at the bigger picture, the overall dev costs for SAP are higher because of these two code lines. The customers would benefit from a containerized Hana database as well, so why not make the on-prem Hana 3 another Hana Cloud container? I expect that to happen; the alternative is to stop further SAP Hana on-prem development.

Change Two: Hana @ Hyperscalers

All hyperscalers support deploying a Hana database today, either via a third-party marketplace offering, a normal installation on a virtual machine, or a scripted installation via the SAP Cloud Appliance method. How about making Hana a first-grade citizen in hyperscaler clouds instead? They offer a zoo of databases already, but none are comparable to Hana. They will come up with a competitive solution eventually, so why not make them an offer they cannot resist? From a technical point of view, it boils down to deploying Hana containers. The hyperscalers can provide Hana to customers outside the SAP market and connect their own Business Intelligence tools, application development tools, or admin tools with it. Better to get some additional revenue at no costs than none.

Change Three: Hana @ Home

Wait a second. An on-prem Hana database means starting a Hana container and connecting it with its database files. The same thing is true for SAP’s own Hana Cloud offering and all hyperscalers. However, if that is the case and both are equal, migrating an on-prem database to the cloud is trivial. Copy the database files and let SAP or hyperscalers take over the responsibility for the database administration and hardware provisioning. And vice versa.

With this move, there is no difference between on-prem, private cloud, public cloud, and SAP cloud!

Change Four: Optimize the kernel

With a single code line and a much broader customer base, it would make sense to invest into optimizations. There are quite a few areas where little changes help to bring down the process footprint and increase stability and scaling. Some aspects I have written about in other articles, but these are tasks for the very capable SAP engineers, anyhow. All I wanted to say on this point is that there is significant cost-saving potential for customers and cloud operators, including SAP.

Change Five: SAP, stop lying to yourself

SAP provides great software bundles. Due to the low price point of the bundle, it is a compelling offer. Even if a fraction of the software is used, the overall price is less than the sum of the individual licenses. The benefits for SAP are the lower cost-of-sales and the faster sales cycle. This approach has one unintended consequence, however: The individual product success cannot be measured.

The most successful SAP manager is the one who creates a compelling product story (“We do Blockchain!”, “Big Data!”, “AI!”, “We do something with containers!”), gets a good revenue recognition for each bundle, and whose product is not used. This product has fewer support incidences, low development costs, high revenue, high margin.

This is not a hypothetical issue, either. There are products that are great to demo, solve every possible customer problem – on paper. I recommend asking your own SAP experts which components of any sales bundle are in use and which are not living up to their expectations.

Change Six: Sponsor DBeaver.io

SAP wasted the last six years building a database administration toolset and a development environment. The only usable products were Hana Studio and XS Classic in the early days; both have been deprecated many years ago. With such a track record, it is probably a good idea to ask for help. I use DBeaver daily as a replacement for Hana Studio for SQL-based commands. It would make sense to ask them to add some Hana-specific administration screens to their product.

This will likely not happen.

Conclusion

Hana really deserves better. There is still a window of opportunity while other vendors have nothing comparable to offer. Snowflake is the first competitive product with more to come, for sure. The window is closing slowly and there is the danger that Hana is headed into the SAP MaxDB direction of irrelevance.

How I wish to be wrong.