S/4HANA and AnyDB
Published:
Content Copyright © 2015 Bloor. All Rights Reserved.
Also posted on: Accessibility
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.
Comments are closed.
A well written article, thank you.
I could not see any mention about the BLU. I think IBM is well prepared for the In-memory with the open power and DB2 BLU for performance and z13 and DB2 IDAA for robustness and availability. Both should be running S4 when it is completely GA. As far as I know SAP is committed to bring all the future technologies in any In-memory database meeting the standards set by Dr. Hasso Plattner. Check https://open.hpi.de/courses .
Let us hope IBM will meet the requirements in DB2 BLU.
I’m posting this on behalf of a reader who emailed me directly:
Hi Philip, this is a great summary of the facts around AnyDB, HANA and S/4 HANA. Maybe
over 99% of the databases running SAP Business-Suite and SAP BW systems are
still on AnyDB. The support of Business-Suite/NW applications is extended
until end of 2025 (plus 2 years extended maintenace until 2027). This 10/12
years are in the IT a very long time for the customers to evaluate the
possible offerings in the market. In this time frame the customers can
check the S/4 development and how SAP opens it for AnyDB and other
operating systems.
You are right that there is oxymoron about relational databases and disk
based databases. All databases (including the in-memory databases) are
needing RAM, cores and storage. Therefore the customers should always
compare the needed RAM/cores/storage before and after the in-memory
implementation.
Gürsad
Hi Philip,
this is a great summary of the facts around AnyDB, HANA and S/4 HANA. Maybe
over 99% of the databases running SAP Business-Suite and SAP BW systems are
still on AnyDB. The support of Business-Suite/NW applications is extended
until end of 2025 (plus 2 years extended maintenace until 2027). This 10/12
years are in the IT a very long time for the customers to evaluate the
possible offerings in the market. In this time frame the customers can
check the S/4 development and how SAP opens it for AnyDB and other
operating systems.
You are right that there is oxymoron about relational databases and disk
based databases. All databases (including the in-memory databases) are
needing RAM, cores and storage. Therefore the customers should always
compare the needed RAM/cores/storage before and after the in-memory
implementation.
Regards,
Gürsad
Two points to mention:
1. Obviously, SAP just told you that S4/HANA will run on “Any HANA DB”. Wow… SAP HANA and its interface e.g. SQL script are proprietary. So I do not see any analogy to AnyDB.
2. I guess It is a bit misleading to claim that S4/HANA does not have locking. Open SQL in R/3 used a (very:-)) least common denominator of database capabilities from the 80ies, so even read locks / avoiding dirty reads had to be solved by the application server. Hopefully these days are over with SAP HANA and they do not use buffer tables anymore to avoid dirty reads (which is unnecessary for e.g. Oracle for many years).
In R/3, programmatic pessimistic locking using enqueue server was common practice. This technique causes performance issues and an obvious mismatch when using modern, stateless, web based programming models.
These pessimistic locking are gone in S4/HANA, they have probably been replaced by common optimistic locking techniques that are standard for several years e.g. in Java EE (JPA).
Hi – I too was expecting SAP to say that S4/HANA supported optimistic locking but the spokespeople (several of them) have specifically stated “no locking”.
An interesting and thoughtful item, I also was also thinking if, as large Enterprise SAP clients seek to map existing on-premise business process aligned, broad, deep, and customised SAP Business Suite / SAP NetWeaver functionality into a phased S/4 HANA enablement and deployment strategy (Simplified Financials, Logistics etc etc). It is then likely that this will practically take some time and/or maybe even additive in a “side car” like deployment strategy as the base HANA rdbms technology continues to be developed and mature. Hence in turn the resulting phased transition and functional mapping and matching requirement will then naturally provide time for AnyDB vendors to enable additional S/4 HANA functionality for clients who require and prefer a choice of rdbms platforms and/or increased platform and/or data compatibility with existing SAP (and non SAP applications) deployments enabled via techniques like CDS (core data services) with SAP NetWeaver 7.40 SPS08. Kind Regards Tim
Hi Philip, optimistic “locking” is no discrepancy to “no locking”.
From a technical point of view, optimistic locking is a wrong/misleading expression. The correct term is “optimistic concurrency control” meaning that there are NO LOCKS between concurrent transactions: Each transaction has to verify that no other transaction has modified the data it has read. If data modifications by other transactions are discovered, the transaction is rejected. Optimistic concurrency control (a.k.a. optimistic locking) is just a special and in most cases sufficient way to resolve contention between transactions.
Hi – very interesting input describing what several average SAP customers are planning for the next years, before they take the inevitable step towards S4/HANA (unless they migrate to another ERP Suite). The suspenseful question is how long will this phase last, how these non-cloud customers will adapt S4/HANA and how other rdbms platforms will line up.
Probably SAP itself is not interested very much in opening S4/HANA for other db vendors. We should not expect that a “phased transition” to S4/HANA will be possible and reasonable. The gap between SAP ERP Business Suite and S4/HANA simply is too large. Customers will take steps towards HANA enablement in the next years. First with minimal footprint (side car) and later by moving on SAP Business Suite on HANA. But even the latter is basically different from what you get with S4/HANA.
To illustrate this, look at Open SQL. With S4/HANA, there is neither right to exist nor need for Open SQL as an abstraction layer since there is only one database supported: HANA. Furthermore, in S4/HANA, SAP gave up the outdated concept of putting data of multiple tenants into the same database tables and seperating the content by extending each SQL statement with “WHERE mandt = ..” Multi tenancy in S4/HANA is built upon the multi tenancy capabilities inside the SAP HANA platform (support package 9).
Therefore the differences between Open SQL (as an abstraction from AnyDB and a means to support multi tenancy) and native SQL will vanish.
Even CDS is essentially a technology to bridge the gap between very limited Open SQL on the one side and both the mature capabilities of all “AnyDBs” and the “no-need-to-aggregate” of SAP HANA on the other side. It will be interesting to see if CDS will survive inside S4/HANA, more precicesly: how the successor of CDS inside S4/HANA will look like.
How will a next generation ABAP dictionary look like, which tool is used to define tables and views? The integration between DDL generated from CDS and the ABAP Dictionary today is somewhat incomplete and clumsy, this will be harmonized, but how will it look like?
The current locking concept (lock objects, enqueue server…) inside the SAP ABAP Application Server is still available on SAP Business Suite on HANA, but must and will be banished from S4/HANA – SAP UI5 / OData are stateless technologies.
Conclusion: We do not know today how persistent data will be defined and accessed in S4/HANA. So we should not assume that steps to enhance SAP Business Suite with HANA features will be wrapped up in S4/HANA. The investment protection of these activities should be considered realistic. Kind regards Rolf