Recently I met a friend of mine who is an analyst and I noticed that there is a little confusion about what HANA and HANA solutions really are. I understood that there is an obvious interest from SAP competitors to characterize HANA as a BI solution. As it is somehow widely known, HANA is the new SAP proprietary database technology leveraging the recent changes in the server architecture, allowing for computing intensive queries performed against information residing in memory and not anymore in disks.
SAP in the recent months has released (or better "is releasing") a number of point solutions designed to bring immediate wins to their customers (check the SAP page here) while the customers figure out how to structure their HANA adoption roadmap. It seems to me that there are two classes of "HANA Solutions" :
- HANA native solutions
- NetWeaver solutions leveraging the HANA technology as a Database.
For sake of clarity and simplicity, my simplest way of explaining this is to refer to the handwritten sketch I am attaching here below.
Let me take two solutions I know: S&OP on HANA and Demand Signal Management (DSiM) on HANA. The former is a solution where the User Interface, or better let us call it "Presentation Layer", is given by an MS-Excel "plug-in" that connects to the HANA server providing data extraction, data update, recalculation etc. The application logic is completely contained within the HANA server and the beauty of the solution lies in the ability of configuring a completely dynamic "Model" both in terms of master data and key figures. The native HANA applications do not need a Netweaver stack to run.
The latter --in my example DSiM that was developed from a SAP Consulting solution -- is based (in the current release) on a NetWeaver/BW stack. The main advantage lies on the fact that that solution can leverage the full flexibility of BW, but the Application logic is mainly contained within the NetWeaver stack. It is possible to perform application logic algorithms within the HANA server, with certain particular queries that ship with the solution and other "new" ones that could be programmed using the "R" language, which is intended for statistical operators and patterns recognition.
One can ask at this point: what is the best option? My take is that it depends. It would not be feasible for SAP to deliver only fully native apps on HANA from day one: the technology is relatively new (compared to the typical SAP software lifecycle) and the HANA studio development environment has still room for improvement to reach the productivity level of the ABAP environment. After commenting about the obvious (this is common for any new technology introduction cycle), the main advantage of solutions based on the NW/BW stack is their supportability: SAP can support easily an on-premise delivery model even for the queries to be run in the HANA database as procedure can be attached as text files in the correction notes and the on-premise model would still work.
On the other hand the real application revolution, both in terms of application design and in the direction of "big data", will only be possible with a native HANA approach where column storage, data compression and all the other amenities delivered with the HANA technology will be the norm for every computing intensive application.