Content Copyright © 2015 Bloor. All Rights Reserved.
When I first looked at S/4HANA I was somewhat sceptical. However, I am considerably more impressed now that I have delved into it more deeply. But this isn’t an article about S/4HANA per se but about its dependence on SAP HANA as opposed to the third party databases (which SAP refers to as “AnyDB”) that typically underpin the existing Business Suite.
The initial material around S/4HANA was pretty dismissive about the AnyDB products. This wasn’t helped when Franck Cohen, who is President of EMEA for SAP, stated at a recent analyst conference that “relational databases are dead”. Given that SAP HANA is a relational database – it still stores data in tables even if it is by column and processing is in-memory – then you only need to append the inference “long live SAP HANA” to recognise this as an oxymoron. SAP would do well to tone down its hype.
Leaving that aside SAP has given the impression that S4/HANA will only ever run on SAP HANA. This isn’t necessarily true. SAP has told me that if and when other database suppliers provide equivalent functionality to SAP HANA, and provided that they also meet SAP’s performance, architecture and capability benchmarks then the company would be open to certifying third party database support for S/4HANA.
This is not going to be a trivial exercise. There are several features of SAP HANA that are used by S/4HANA that are not in AnyDB. For example, in S/4HANA transactions are written directly to columns in-memory. This isn’t the way that AnyDB works. For example, DB2 supports shadow tables that are column-oriented but you write the data initially in row-based format. Another factor is that S4/HANA has no locking: it has processes to resolve any contention but no locking.
A further issue is that SAP HANA has a graph engine built into it. Moreover, S/4HANA directly makes use of the graph engine in its applications. For example, Simple Logistics, which has recently been released in a public cloud edition, makes use of the graph engine for bill of materials. While Oracle has had some significant graph capability for some time this is a major potential issue for IBM. Triple store support was introduced into DB2 some time ago but its capabilities have not been enhanced. When the triple store was first announced it was the intention to add an inferencing engine but this was dropped. In any case, the graph engine in SAP HANA supports pattern graphs. It is likely that AnyDB vendors that want to support S/4HANA are going to need to implement pattern graph support as well as writing directly to columns before any certification by SAP. This is not going to be a short term project.
While on the subject of graph databases IBM does have a research project called System G, which is a graph database. I have asked several times when or if the product is going to be brought to market but the answer is consistently no, though some elements of the System G project will be reused within Watson. My guess is that IBM is going to have to think again: unless it reuses some of the System G functionality within DB2 it is going to lose the SAP market and I don’t think it can afford to do that.