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.
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. ]
- SAP Managed Tags:
1 Comment
