- 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 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