Why SAP HANA has not had more success than it deserves (no, I do not work for SAP)

[Former Member]

I have been working with HANA and evangelizing about its use case and value with customers and prospects and yet I found it an uphill task to get engagement from the business (and in extreme cases, even IT); this despite the fact that SAP HANA is a great product and has lots of uses. So I started researching the issue and came up with some hypothesis, based on conversations and observations.

I theorize that IT departments went ahead and acquired SAP HANA for one or more of the following reasons:

1. HANA is the newest shiny toy

2. The IT department had left over budget and had to go buy something

3. The SAP or partner AE was a very good sales person and made the CIO an offer he/she could not refuse

4. The consulting partner convinced them SAP HANA would help solve all their problems

5. The IT department had to find something new and sexy to work on so the CIO and his/her staff could show they were working on the latest technology, and could put SAP HANA (aka 'Big Data') on their resume (how can you work in IT and not have 'Big Data' on your resume......).

Now that IT had acquired the new shiny toy, they had to go find something to go fix- create a solution and then go find a problem - we have seen this before, many times. The challenge was two fold: (1) IT could not really articulate how SAP HANA would create value for the business, and (2) because of the lack of understanding of real business issues, IT picked the wrong use case or a very weak use case.

Let us now turn to the product itself; SAP HANA is great, and I believe there is huge value to be derived from this product, if rightly deployed. So why has HANA not been adopted more readily. Let us look @ some of the potential reasons:

1. HANA is an SAP product and everyone associates HANA with the core SAP ERP and CRM; so the target customers have been mostly current SAP clients.

2. Many believe that you have to be an SAP shop to leverage HANA; I was talking to a friend who is trying to build a custom healthcare app; I told him he should try and leverage HANA to build his app, and his first response was that his product has nothing to do with SAP.

2A. Because of the belief that you have to be an SAP shop with significant SAP installations and SAP data volume to be able to use SAP HANA, many customers believe that they do not need HANA because their SAP data footprint is so small. The argument I often hear is, "We have less than 80 GB of total SAP data; why would we need HANA?".

3. SAP HANA has been sold as an application, whereas it is more of a fast database and a development kit. When you buy an application, you expect to install it and start getting value out of it - like SAP ERP, Workday, Ariba, etc. HANA is not an application - it is a super-fast database AND an ADK - and similar to the Apple iOS, you can use this platform to build applications which can then be used to solve business problems- so SAP HANA is an enabler and not the end app itself.

4. People do not remember that SAP acquired Sybase a few years back and a lot of the Sybase IP is being integrated into SAP HANA; old timers like me would remember Sybase as a very robust and stable database with a lot of capabilities (Sybase IQ came with columnar data store capability). SAP  did not throw away all these features and functionality- instead these are being made part of SAP HANA.

A combination of these factors has hindered the adoption of SAP HANA both among SAP shops and non SAP shops.

For SAP shops, SAP HANA should be a no-brainer, just for using HANA Live; the pre-delivered analytics and calculated views alone can get someone trying to build a data analytics strategy a head start with SAP data. Here, of course the value of SAP HANA is dependent on the source data being SAP (see details about HANA Live in my personal blog).

But there is a much bigger value for SAP HANA for non-SAP data; you can stage large data sets from the likes of Hadoop, Teradata, and other non-SAP sources into SAP HANA, using the likes of SAP SLT* or SAP Dataservices,  and use HANA to combine data from multiple sources almost real-time, and render the data using either SAP analytics tools like SAP Business Objects, or one of the many other analytics tools available in the market. (* SAP SLT does not work for all applications).

SAP is pushing down more and more development capability into SAP HANA and this will allow more application developers to build widgets on HANA and leverage the power and capabilities of HANA.

It is incumbent on SAP, SAP AEs, and the consulting firms to educate customers on the real value of SAP HANA and more important, the fact that this is not a simple plug-and-play application- this needs planning, identifying appropriate use cases, and proving the true value of SAP HANA.

IT departments should find a good use case, build the application powered by HANA and show the application and its robust capabilities to the business- HANA should almost be not revealed or discussed with the business (how many times do you go and discuss what database you are using with your business users?). After the use case has been proved, the capability behind it, in this case SAP HANA should be revealed- lead the discussion with the business value and then talk about the technology enabling it.

Until such time, SAP HANA will remain largely a toy for IT departments and CIOs trying to show they are using cutting edge technology, with minimal penetration or adoption in the business.