Database Portability – is SAP moving in right direction?
In SAP database world, a major shift is happening, silently.
No, I am not talking exclusively about HANA; at least, not to start with.
Refer SAP Note 2214245. The note informs us that if one wants to run Fiori apps for S/4HANA 1511 onwards, on standalone Front-End Server (FES) aka. NW Gateway Server 7.5, they can do so only on SAP-owned database.
<img />
Only on SAP-owned database?
Surely SAP supports NW 7.5 on all generally supported databases?
Yes, vanilla NW 7.5 is still supported on DB2, MS SQL and Oracle, apart from SAP-owned MaxDB, ASE and HANA. Refer Product Availability Matrix screenshot as follows.
That said, if you use that same NW 7.5 for FES purposes, then the database has to be SAP-owned.
When I heard about the restriction earlier this summer, I queried SAP via SCN; there was no soothing reply. Few weeks ago, I had the opportunity to attend S/4HANA Technical Bootcamp, where I raised the question again. The cautious reply was “there is no technical limitation”.
Now, let’s discuss HANA…
Refer to FES-database restriction along with the shift towards HANA for S/4HANA and recently announced BW4HANA – all of which exclusively run on HANA.
Does this mean SAP do not believe in other in-memory databases like DB2 with BLU, Oracle Database In-memory or Microsoft’s modest Hekaton?
When discussed on this topic with my fellow techies, general comment was “Why not?” with following reasoning:
- Most of other software vendors do the same. For example, while Microsoft .NET supports all database, BizTalk works only on MS SQL
- It will be beneficial for SAP’s clients. In case of database and/or application issues, SAP’s clients have one vendor to go to – which will reduce / avoid ping-pong of issues between multiple vendors.
- SAP allowed their products to run on anyDB when they were not in the database business. Now since they have invested a lot in DB technologies, SAP need to ensure payback on that investment.
All valid points and I agree as well. That said, are they still good enough reasons to move away from multi-product portability to single-product locking?
What are the real implications?
Let’s think again. What are the real implications for companies who run SAP for decades?
I could think of the following:
- The shift is against one of the core believes we techies were snobbish about SAP – that SAP is “portable” on any respectable database, on any respectable Operating system
- Specific to SAP FES, if one uses FES on AnyDB as a standalone hub for Firoi apps running on ERP, GRC and Solution Manager, an upgrade of ERP to S/4HANA will force a heterogeneous database migration of FES – from AnyDB to SAP-owned database.
- This is in contradiction to SAP’s claim on TCO reductions. From data centre perspective, one is now forced to introduce a new database, thereby increasing the TCO – on all matters that touches a database – DBA proficiency, backups/restores, HA/DR config to name a few.
So, does this shift mean that SAP is slowly moving away from database portability?
Is SAP writing codes that cannot run on other (in-memory-enabled) RDBMS and hence forced to use proprietary database?
While there are definite advantages of re-writing ABAP code in in-memory format, does SAP think this re-coding cannot be done in a better way by other (let me stress longer-playing) DB vendors?
At times when Apple and Microsoft talk about OpenSource, how will the wider CIO community approach SAP’s “exclusive vendor locking” on database?
Is this just a sales/marketing tactic to push DB vendors out of SAP applications? How else could you explain the SAP-only database restriction for non-analytic FES system running on NW 7.5?
Is this the start of the end of SAP database portability?
What are your thoughts?
[PS: Was originally published in LinkedIn. The opinions expressed in this article are my own, and do not reflect view of whom I am working for. I write for my own purposes, based on my experience and do not accept any form of sponsorship or paid insertions. ]
Ok, I'll bite...
My view on this is the following:
SAP had been the last remaining big ERP vendor that actually supported multi-platform and multi-DBMS setups.
With other products, you didn't have that choice in the first place.
The problem, from a development point of view, with multi-DBMS is that it invariably turns out to be a race to the common denominator of functions and features. Trying to keep up with the vendor specific special features is incredibly resource intensive and usually doesn't provide equal value.
In short: you burn a lot of development effort for little user-facing effect.
That's not what you want to do, neither as a software vendor nor as a client.
Focussing the development efforts to actually deliver better integration and leverage of the underlying platform makes a lot of sense both for us (SAP) as well as for the customers.
One aspect here is increased innovation speed. Customers can today leverage new features and functions a lot quicker, than say, 4 years ago.
Claiming that SAP is not supporting Open Source is simply lacking information, I suppose. Google "sap open source" and you should find https://sap.github.io/ for example.
The shift you claim to be silent had been explained very public: https://www.youtube.com/watch?v=b_L7jZpE0nE&index=6&list=PLT40CdhRWmHAJfY8BugLjqTouyPcDeFCn
So, no, I don't agree with the notion that SAP sneakingly forces customers to do anything.
BTW: every single one of the DBMS platforms you mentioned is proprietary - they are just from different vendors.
You ask, how will the wider community of CIO's will react? You'd hope that the CIOs, CTOs and CEOs are provided with a good overview of what SAP's solution strategy is and how it helps them to make their businesses more successful. Thinking about the vendor choice of a single commodity technology certainly doesn't capture the whole scenario here.