A new cut on the SAP mantra: Innovation without Disruption: HANA-induced thoughts from a TechEd Keynote
As I watched SAP Executive Board Member (Technology and Innovation) Vishal Sikka’s keynoteyesterday at the TechEd in Las Vegas, I reflected on past keynotes at previous SAP events and found some interesting patterns.
The underlying message in most SAP keynotes at these events is always the same – “Innovation without Disruption”. Existing customers – usually with OnPremise installations – shouldn’t be worried that new technology could detrimentally impact their existing environments but the accompanying innovations of this technology should bring benefits (lower TCO, better usability, etc.). What is interesting is the manner in which SAP has attempted to achieve this goal.
This year’s panacea is HANA but in the past, other technologies have been placed in the spotlight. Past innovations (I’m not going to try to describe in which year these innovations were presented) included:
- The Switch Framework and Enhancement Packages
- NetWeaver Composition Environment (CE)
- Enterprise Services
Most of these technologies focused on innovation external to the Business Suite – for example, Gateway provided(s) mobile clients easy access to data from the Business Suite core without having to change Business Suite functionality. CE was envisioned as a platform to create innovative applications that accessed Business Suite data but ran on the Java stack.
Here is the official description of a specific Enhancement Package (EnhP) and the Switch Framework.
Enhancement package 4 represents the new advances for SAP ERP that are delivered through a unique business software delivery model that offers customers the ability to adapt new functionality without the disruption of system upgrades. As a result, customers are empowered to improve and update their enterprise software systems in a shorter timeframe and with more discrete testing cycles, driving down costs and simplifying enterprise software management significantly. [SOURCE]
The main purpose of the Switch Framework “is to simplify an ABAP-based system landscape by adopting one or more industry solutions in a standard system”. [SOURCE]. EnhPs are provided via an innovative mechanismto provide new functionality to the Business Suite without disruption – the functionality provided by these EnhPs, however, isn’t necessarily innovative.
HANA –at least in its latest incarnation presented yesterday – provides innovation by replacing the existing database layer – hopefully, without disruption. HANA focuses on innovation that is internal to the Business Suite. Of course, this definition is closely associated with how you define the Business Suite Core – is the database layer included or not? In my opinion, the database/data layer is part of the Core.
The externalapproach was based on the desire to protect the Business Suite from change – even if this change was in the form of innovation. The internalapproach is based on the desire to improve the Business Suite from within. The reason behind this shift could be based on 1) the newly-rediscovered self-confidence of SAP managers in their own technology, 2) the understanding that the Business Suite Core can not be allowed to languish / become outdated and deserves a make-over.
Removal of layers leads to simplification but raises other questions
Vishal presented one slide in yesterday’s keynote that showed how HANA will become the underlying data layer for various applications (CRM, ECC, BW, etc) -replacing existing databases in these Business Suite applications.
[SOURCE: Screenshot from keynote replay]
I was confused by this slide, because I don’t know whether to look at it from a purely technical perspective or from a very high-level architecture perspective. Is the implication that there will be one HANA database for all these applications or will there be separate HANA databases for each application with no connection to another (data duplication danger ahead! – where is MDM when you need it) or will there be separate HANA databases for each application with some sort of replication occurring between them.
If I was a customer, I’d be trying to figure out what impact this change will have on my landscape. In terms of the hardware needed to support it, will I have to purchase new “Ready for HANA” boxes for my environment? If there is just one giant HANA-based data pool, do I have to dig up the contact information for those since-retired mainframe salesmen and buy a new box that is big enough to support this much data.
How will developers be affected by the replacement of the data layer for Business Suite applications? Lately, there has been some degree of Podcast: HANA TechEd Preview and Skills Discussion – SAP Mentor Style and how one can acquire such capabilities. Much of this discussion has been associated with HANA-based analytic applications. Initially, I’m assuming that developers (especially those ABAP devs) won’t be impacted by presence of the new HANA data layer. Indeed, this should be the case if the exchange really is non-disruptive. It is only over time when the broader implications of the increased processing speed in such environments are understood that developers will change their code to take advantage of the resulting changes.