- SAP has made enormous claims around HANA being innovative.
- We evaluate the accuracy of these claims.
SAP uses terms for propagandistic effect more than any vendor that we study at Brightwork Research & Analysis. Using terms for propaganda means that the term 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 rapidly 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.
Innovation Used to Excuse Database Instability
Another major use of the term innovation by SAP has been to serve as a 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 in general.
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.
Search Our Other HANA Content
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.
The Risk Estimation Book
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