How to Understand Fake Innovation in SAP HANA

Executive Summary

  • SAP has made many claims around the innovative nature of HANA.
  • Our analysis is that these claims by SAP are marketing hyperbole and to not hold up.


SAP uses terms for marketing or propagandistic effect more than any vendor that we study at Brightwork Research & Analysis. Using these terms has no other purpose other than to mislead the audience.

In this article, we will explore the specific issue of how SAP uses the term innovation as a term of propaganda and in order to convert a weakness into a strength, in particular with respect to the SAP HANA product. In this article, we made the following observation about innovation and HANA that we have not seen articulated elsewhere.

HANA and Innovation?

In the article How HANA 2 Was a Cover Story for the Real Story, we covered how SAP repeatedly used the term innovation as cover for the fact that something very undesirable occurred with HANA 2. Something that customers of earlier versions of HANA would have never imagined they would have to deal with. HANA 2 was not backwards compatible with HANA 1 SPS 9 and below.

“What is really changing is SAP enabling customers to choose how they manage their update cycles. Currently, SAP releases a new SPS pack for HANA every 6 months and expect customers to be within 2 SPS levels as part of the terms of their maintenance contract. For some organisations this rate of change is just too much but something they have to manage to retain support, meaning those organisations often have to live with the constant change – this constant change of their core landscape can often kill innovation.” – AgilityWorks

Research at Brightwork into HANA indicates that SAP and their surrogates use the term “innovation” to simply mean development. HANA is behind its competitors and is developing more rapidy in order to catch up. But the correct word for this is not innovation. Here is the definition of innovation.

But the correct word for this is not innovation. Here is the definition of innovation.

The Definition of Innovation

Here is the definition of innovation.

“Innovation can be defined simply as a “new idea, device or method”. However, innovation is often also viewed as the application of better solutions that meet new requirements, unarticulated needs, or existing market needs.” – Wikipedia

What does SAP have with HANA that other DB vendors did not already have? If SAP has nothing new, but is merely catching up with DB2 and Oracle 12c how is that innovation? Is SAP simply reversing engineering other databases and calling it innovation?

It appears to be the case.

After writing this, we realized that we did not consider HANA to be innovative. Yet SAP was constantly using the term innovation to describe the ongoing development of HANA. In fact, SAP and ASUG adopted a term from Gartner called Bi-Model IT. The idea is that IT can be broken into more maintenance of stable applications and database and then more innovative items.

Mixing It Up in a Blender with “Digital Transformation”

“The aim with the new platform release is clearly to tie HANA more closely into SAP’s overall message of digital transformation. Think of HANA 2 as an underlining from the vendor that its platform can act as the basis for organizations to transform their businesses into fully digital enterprises. Leukert also talks about where HANA 2 fits in one approach to digital transformation, the concept of ‘bimodal IT,’ a term analyst firm Gartner has coined. As an aside, it’s worth mentioning, other research organizations are not so convinced of the benefits of this approach.” – ASUG

The problem with this, is it assumes that HANA is innovative. Our research shows that HANA does not have anything that other database vendors do not also have. SAP as the first to focus on adding column-oriented tables to an application database. However, their implementation of this design was overdone. As is covered by IBM white paper on HANA, which is covered in the Brightwork article IBM Finally Fights Back Against HANA, placing all tables into memory is a wasteful approach. In this way, SAP came up with a way of speeding up analytics using a column-oriented design but seems to have negatively innovated. That is they came up with an approach that was inferior to what was already available.

SAP had already purchased Sybase IQ, which is a column-oriented database that never sold particularly well — so SAP has a steep hill to climb to either prove that they came up with something new with a column-oriented design, or that their implementation of a column-oriented design constituted an improvement.

Innovation Used to Excuse Database Instability

Another major use of the term innovation by SAP has been to serve as cover for product immaturity. SAP has repeatedly talked about how customers would receive “rapid innovations.” However, again, these areas SAP is developing are not new. They are new to HANA, but that does not make them new to databases.

What SAP has been doing is because HANA is not stable, SAP again brought out the trope of innovation. Therefore, the fact that SAP was “innovating” was why customers should not expect stability. The obvious fact that the same functionality is available from far more established database vendors that already have the same features and that also have stability is not observed by SAP or by consulting companies that advise companies on SAP.


SAP is dishonestly using the term innovation as a cover for the fact that HANA lags other database options, and that HANA has had instability issues because HANA was rushed to market.

The Necessity of Fact Checking

We ask a question that anyone working in enterprise software should ask.

Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?

If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.

In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other HANA Used to Block Out Other Databases Content


The Risk Estimation Book


Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.


Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model