INT203: Integration Solution Advisory Methodology (ISA-M) – SAP TechEd Lecture of the Week

Hello, in this video (@28min), SAP talks of the need “to finally agree on records to be a golden record”. Likewise, a frank admission is made that “we have, due to acquisitions, quite a lot of applications that over time only, we [i.e. SAP] can consolidate”. This leads me to several questions:

1) Is SAP still an “ERP” vendor in 201*, or is this no longer a goal at SAP ? There is little doubt that SAP’s commercial success comes from the fact that it was a vendor of a quality ERP in the 1980’s-90’s, but in 201*, it seems we have gone back to an overwhelming 1970’s landscape of heterogeneous systems and vast expense, where businesses once again have no idea how to find the “golden record” (a business problem that was solved by ERPs in the 1980’s), or how to find the technical people necessary to manage such an incredibly complex landscape ?

2) It is clear from these statements that SAP doesn’t believe that it sells an “ERP” today, and that “over time only, we [i.e. SAP] can consolidate” our large application portfolio. So, only with time can SAP consolidate its own system landscape, thereby once-again becoming an ERP vendor ? So, why would any business looking for an ERP to solve the “golden record” problem of the 1970’s be interested in SAP’s non-integrated product offerings today (or the next 5-10 years for that matter, depending on future acquisitions) ? It might well be cheaper over the long-term to develop their own ERP from-scratch — off-shore — using less-specialised programming tools.

3) It cannot be reasonably expected that clients will invest fortunes in the vast SAP product suite, only to be told that they need to then invest heavily in a very large and expensive GIP to consolidate the products they have just purchased from SAP, because “over time only can ... [SAP] consolidate” its own products. In the meantime is it really for customers to manage and pay for the consolidation that SAP is unable to provide its clients ?

4) Instead of a huge, complex and expensive GIP to be managed by the customer — at its own expense — a true SaaS abstraction layer between your various products could eliminate the need for a costly and complex GIP, as your products would instead talk directly with one another — via Service APIs — enabling them to share the same underlying DB (which would be abstracted in the form of ‘software services’) ?

5) Having said that, should SaaS even be a goal at SAP today given the simplifications made possible by the HANA DB ? Perhaps you should drop SaaS, and think instead of ‘Data as an Object’ (DaaO) ? Given the new flows being generated by M2D scenarios, where there is no genuine ‘software application’ to speak of, is what matters today software or data ? Do you really care if your clients use CRM, a traditional ERP transaction, a Fiori mobile app or a robot to update their customer’s address ? It is the underlying (object's) data that counts. Why not simply make use of the new HANA HDI Database Schema abstraction technology (an API v2 -> a DPI ?), and have ALL of your vast product offering (as well as new M2D devices) use the same underlying physical DB Schema via a DB-abstraction layer, so that there is only a single-source-of-truth, a single “golden record”, so that SAP goes back to its roots and starts selling ERP 'Modules' again ? Perhaps ERPs were always about single-source-of-truth DB-integration and never about Software-integration, given that software constantly evolves, but the underlying DB (business) objects rarely do ?

Regards,

Cameron HUNT