How to Properly Evaluate the Proposed Benefits of SAP HANA

Executive Summary

  • HANA is normally discussed by those that promote HANA.
  • Why it is important to separate the generalized statements from the specific improvements.

Which Way on HANA

Introduction

As anyone who works in SAP knows, HANA has been the largest SAP marketing point of emphasis for several years now. However, much of the information comes from a one-dimensional perspective, one that is more promotional in nature than focused on enhancing the understanding of how and when HANA is appropriate to be deployed. This article is intended to help readers apply a framework for asking the right questions about HANA.

Item #1: Working Out HANA’s Expense

HANA is a solution, which is more expensive than other alternatives. There are several reasons for this. First, HANA uses more expensive hardware. Secondly, it is more expensive because of the premium that SAP charges for HANA software. Thirdly it is more expensive because HANA is still being worked out under the covers, and this means more implementation complications than other SAP alternatives that have had more implementations. Fourthly, in cases where HANA is implemented for an already live system, it means making a change and changes cost money. Something which I have yet to see elaborated upon in print is something that I think is quite obvious and that is that anyone can gain more performance by increasing the input or investment into a domain, but it is important to mention that the input/investment is different when making statements regarding improvement. As an example, I can say that a Maserati performs better than a Honda.

However, if I leave the price out of the equation, then it’s not really a fair comparison. Too many articles and conference presentations give little attention to costs and instead are entirely focused on explaining the benefits of HANA. One recent article that I read showed the cost savings that come from HANA from the improved capabilities that a company would obtain, but nowhere in the article were costs discussed. It almost appeared as if HANA along with its implementation were simply free.

Item #2: Different Benefits Per Application

There is no doubt that business intelligence applications benefit greatly from HANA. And this means that more implementations have occurred for SAP BI than for other SAP applications, and using HANA for SAP BI is much easier because of how business intelligence applications work versus transaction processing applications like SAP’s ERP system, makes the effort involved in migrating to HANA far easier. Secondly, the benefits differ per the type of application.

Item #3: Part of HANA’s Benefit is Simply Buying Faster Hardware

Part of the benefits that SAP is isolating to HANA is a natural transition to simpler data structures that are now feasible due to improvements and cost reductions in random access memory and solid state memory. SAP decided to make HANA their central marketing pillar by focusing on this change –, replacing the previous marketing platform of “NetWeaver.” However, we can learn quite a bit by analyzing the history of technological improvements in information technology. The servers that are presently being purchased for business intelligence applications may have 500 gigabytes of RAM in addition to multi-terabytes of solid-state storage along with the traditional hard storage. However, even servers with these types of specifications are not particularly expensive anymore. With this type of capacity, it makes less sense to place data into cube structures to enhance query performance. Whenever hardware makes a great leap forward, it takes time for the software to unwind the complexity that was built into it in order to accommodate the previous generation of hardware. So companies that no longer need the cube structures they have built will continue to use them – simply because it takes more time to pull the data out of cubes that they have already built and place them into simpler structures. Hardware can change a lot faster than software.

HANA does not Mean Benefits to All Application Elements

As a person that works both the sales side and the implementation side, I have reservations about how HANA is described as improving every facet of SAP’s applications. For salespeople, it is generally desirable to be able to make these statements, but it sets up implementation problems because implementation must manage highly-generalized expectations for improvements in too many areas. While it may be considered visionary to generalize the benefits of HANA, applications are a series of moving parts that each has their own heritage, current state of development and impact on the function of the application. HANA is an infrastructure element, a good analogy being the suspension of a car. To take this analogy further, most people would intuitively understand that improving the suspension of a car does not improve every other element of the car’s performance. Quite obviously, it does not make the engine more powerful or improve the radio or the visibility from the driver’s seat. Some other areas may improve – for instance, a better suspension can have a positive effect on the steering/controllability of the car, but the specific improvement to other elements should be explained in terms of the cause and effect and not simply assumed. However, statements regarding HANA’s speed improvement are quite frequently generalized to improve all other areas of the application without any specific explanation as to why this is the case. In the same way, HANA has no impact on the business logic of SAP, or its user interface. HANA puts infrastructure at the center of the conversation, but the infrastructure cannot continually be the center of the conversation, because it is only one piece of the puzzle.

Conclusion

In order to get value from HANA it is necessary for companies to move past the generalities that are often applied to HANA to the specifics. The specifics include the price of HANA for each area that it is applied. Not all applications are going to be moved to HANA, certainly not in the next few years. So which applications should, and what is the cost-benefit analysis for doing this, is an important question to ask. For most companies, the first place to implement HANA will be in their analytics.

Secondly, statements that generalize the benefits of HANA to every aspect of the application should be disregarded and emphasis given to statements that show specifically both how and why HANA will improve specific areas of the application, which should then be estimated in terms of business benefits. Being able to improve query performance by a factor of 1000 sounds great, but it may not be the primary problem that company has, and other shortcomings, such as the configuration of the system or the understanding of the functionality within the application may be far more pressing concerns. Technology improvements are much easier to estimate that business improvements. But technological improvements do not necessarily lead to proportional business improvements. As an example, increasing the horsepower of a car from 150 horsepower to 300 horsepower has little effect on the average speed that car is driven, because other constraints – ranging from speed limits to traffic, to physical laws regarding how a car can be driven without crashing into something still exist after the engine has been replaced. By purchasing HANA and investing more resources, queries can no doubt be performed more quickly, however, there are many things that an implementing company wants to improve, and this is only one area of focus. Investments in HANA must be traded off against other investments that improve other areas of the technology landscape that are also important. This logic applies not only to HANA but to any improvement that a company would make to its systems.

Search Our Other HANA Content

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.

HANA & S/4HANA Research Contact

  • Interested in Research on S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is not possible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

https://blogs.saphana.com/2019/04/17/sap-hana-native-storage-extension-a-cost-effective-simplified-architecture-for-enhanced-scalability/

How Accurate Was John Appleby on What In-Memory Database for SAP BW?

https://help.sap.com/viewer/42668af650f84f9384a3337bcd373692/2.0.04/en-US/c71469e026c94cb59003b20ef3e93f03.html

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.

Chapters

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

Is SAP’s Warm Data Tiering for HANA New?

Executive Summary

  • SAP is telling customers that they can use data tiering in HANA to use a new innovation in database design.
  • How accurate is SAP data tiering being new?

Introduction

SAP has communicated a new item for SAP HANA. It is an amazing technological breakthrough where apparently the data is processed in the computer’s memory, but then written to the disk for something called “persistence.”

We cover this amazing development in this article.

Our Analysis

Let us being by reviewing the quotes from SAP.

“SAP HANA native storage extension is a general-purpose, built-in warm data store in SAP HANA that lets you manage less-frequently accessed data without fully loading it into memory. It integrates disk-based or flash-drive based database technology with the SAP HANA in-memory database for an improved price-performance ratio.”

This is amazing.

Translated for the laymen it means that with SAP’s super-advanced technology enables companies to use both memory and disks and even flash drives in something called a “server.”

We have a top secret image shown below. These photos of a prototype of the device used by HANA were smuggled out of SAP at great risk to our agents.

Apparently, the server is a piece of hardware, that has the memory, the disk drives and the flash drives inside of a metal box. 

But the story gets even better. Apparently, some of the data does not need to be accessed all of the time. This is what SAP calls “warm data.” Let us review SAP explanation of this new data classification.

“Between hot and cold is “warm” data — which is less frequently accessed than hot data and has relaxed performance constraints. Warm data need not reside continuously in SAP HANA memory, but is still managed as a unified part of the SAP HANA database — transactionally consistent with hot data, and participating in SAP HANA backup and system replication operations, and is stored in lower cost disk-backed columnar stores within SAP HANA. Warm data is primarily used to store mostly read-only data that need not be accessed frequently.”

While certainly impressive, it is different from SAP’s earlier statements about HANA, where HANA was to be better than all other databases because all of the data was to be loaded into memory. And through shrinking the database size, you could..

“Run an ERP system off of a smartphone.”

In an article published in 2013, John Appleby stated..

“HANA was the only in-memory database with full HA.

The SAP HANA Native Storage Extension?

SAP calls this SAP HANA Native Storage Extension. However, it is actually nothing. It is merely a restatement of what all the competing databases have been doing for decades.

Its called memory optimization.

Let us look at SAP’s graphic where they describe their contraption.

We congratulate SAP on this observation.

What is described above is a standard memory-optimized database. The same design used by other database vendors decades ago and still used to this day. Without being able to load data into memory, it would be impossible to perform a calculation or any type of processing actually. This can be tested by taking any computer or server and removing the memory modules and then rebooting the computer or server. But according to SAP, this design is perfect for replacing “legacy databases,” as the following quotation attests.

The Perfect Architecture to Replace Legacy DBMS Technologies

SAP has a general sizing guidance for HOT vs. WARM data ratio and Buffer Cache size. However, it is ultimately the application performance SLA that drives the decisions on HOT vs. WARM data ratio and Native Storage Extension Buffer Cache size.

For the hardware to implement Native Storage Extension, simply add necessary disk capacity to accommodate WARM data and memory to accommodate Buffer Cache requirements as per the SAP sizing guidance.

The combination of full in-memory HOT data for mission-critical operations complemented by less frequently accessed WARM data is the perfect and simple architecture to replace legacy DBMS technologies. This also eliminates the need for legacy DBMS add-on in-memory buffer accelerators for OLAP read-only operations requiring painful configuration and management.”

But now the question arises,

“If SAP has such a similar design to other databases, why are those databases legacy?”

To this, we have the answer. But before we get to that we would like to take this opportunity to introduce our innovation.

Introduction the Brightwork Piston Gas/Diesel System

This diagram describes something we have named a “piston.” It comes in two types, an energy source we call “gas” and a second which uses something called “diesel.” Our proprietary design deploys a four-stroke design, which is as follows, Intake, Compression, Combustion, and Exhaust. (Patent pending, so please respect our IP)

We are thinking of deploying this technology in some type of propulsion system.

Stay tuned for more details!

Conclusion

SAP’s warm data tiering is nothing new. Furthermore, it contradicts everything SAP said about HANA years ago. HANA is now increasingly backtracking on earlier pronouncements that were designed to make it appear different from other databases. 

From the beginning of HANA’s introduction as a product SAP was told you cannot place everything in memory. SAP told everyone that they did not “understand” and that with their proprietary technology they had achieved zero latency because of their special ability to manage memory in a way that Oracle or Teradata and others could not. This meant loading all data into memory with zero swapping. We had to investigate the HANA documentation to find it was actually memory optimized, and SAP lied about this.

SAP is not an all-in-memory database, nor has it ever been. 

SAP receives a Golden Pinocchio Award for making something that all databases have sound innovative.

Search Our Other HANA Content

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.

HANA & S/4HANA Research Contact

  • Interested in Research on S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is not possible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

https://blogs.saphana.com/2019/04/17/sap-hana-native-storage-extension-a-cost-effective-simplified-architecture-for-enhanced-scalability/

How Accurate Was John Appleby on What In-Memory Database for SAP BW?

https://help.sap.com/viewer/42668af650f84f9384a3337bcd373692/2.0.04/en-US/c71469e026c94cb59003b20ef3e93f03.html

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.

Chapters

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

Is SAP Correct that Customers Should Use HANA CDSs?

Executive Summary

  • SAP has told customers that they must use HANA CDSs.
  • How accurate is SAP on this topic?

Introduction

SAP has been communicating to customers that they should use HANA CDSs as a primary way to access SAP HANA data.  And that CDS views are the way SAP will go forward in the future, which are available through OData interface.

Our Analysis

  •  The OData interface is both problematic and not as flexible as SQL.
  • SAP should not be defining how you consume of view the data. SAP offers CDSs. Customers can use them or not use them depending upon whether they find they fit their needs.
  • Business logic cannot be published to the CDSs.

Conclusion

SAP has this way of presenting their options as if they are natural law. If the CDSs are good, a test will show this when compared to your alternative. The things that SAP are saying on this topic are adding up. We record false statements that are routinely made to customers. The idea inside of SAP is that customers have no real right to any truth, anything is said that simply supports whatever SAP wants the customer to do.

Search Our Other HANA Content

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.

HANA & S/4HANA Research Contact

  • Interested in Research on S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is not possible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

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.

Chapters

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

Is SAP Correct that Customers Should Use BW4HANA Instead of Other BI Tools for Integration to HANA?

Executive Summary

  • SAP has told customers that they must use BW as a BI solution for HANA.
  • How accurate is SAP on this topic?

Introduction

SAP has been communicating to customers that they should buy BW4HANA for BI under the premise that SAP is not designed to integrate well with 3rd party solutions.

Our Analysis

  • Using BW means very serious productivity issues long term.
  • BW is not effective where it is implemented.
  • The idea that an RDBMS can’t connect effectively to anything but a specific BI tool is very odd. This brings up the question of what is an RDBMS. Overall, this topic needs to be analyzed. This is not to say it is not more difficult, but adapters can be written to any database.

This is pointed out in the following quote.

“HANA is widely SQL92 compliant, CDS views are an extension of SQL92. It may be an issue that third party BI vendors do not yet invest in HANA extensions and optimizations. Anyway, there is no CDS view that can only exist in S/4 or BW/4HANA. In the end it are native database artifacts that can be created via DDL statement.– Dr. Rolf Paulsen

Conclusion

SAP’s arguments are based upon integration and the logic that customers must use what they provide. That says nothing about what is actually effective or good.

Search Our Other HANA Content

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.

HANA & S/4HANA Research Contact

  • Interested in Research on S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is not possible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

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.

Chapters

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

Is SAP Simply Backward Engineering Other Databases to Create HANA?

Executive Summary

  • SAP has made enormous claims around HANA being innovative.
  • We evaluate the accuracy of these claims.

Introduction

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.

Conclusion

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

HANA & S/4HANA Research Contact

  • Interested in Research on S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is not possible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

https://blog.agilityworks.co.uk/sap-hana-news-from-sap-teched-2016

https://www.asug.com/news/sap-positions-new-hana-platform-release-hana-2-for-fast-track-it-innovation

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.

Chapters

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

How to Understand AWS’s Multibase Versus SAP’s Singbase Approach

Executive Summary

  • SAP has been proposing that all companies should use a single database type and that they should buy HANA.
  • AWS’s CTO explains the benefits of the multi-base approach.

Introduction to Multibase

What is often left out of the analysis of database advice from commercial software vendors is how biased it and self-centered it is. Commercial database vendors don’t provide any information to a customer that is not in some way designed to get the customer to invest more deeply in the vendor’s commercial products. As bad as Oracle’s “advice” to companies has been, Oracle at least has respected, although highly self-centered, knowledge of databases. SAP’s rather insane advice to their customers has been far worse, and far more self-centered. For years SAP has been telling customers that they need to perform multiple

For years SAP has been telling customers that they need to perform multiple types of database processing from a single database. This is wholly false but has not stopped either SAP or their partner network for saying its true. We have covered in detail how SAP’s proposals about HANA have ended up being proven incorrect in article ranging from What is HANA’s Actual Performance?, A Study into HANA’s TCO, to How Accurate Was Bloor on Oracle In-Memory.

In this article, we will expand into a topic which shows how wrong SAP is. This perspective we will address is not brought forward by either SAP, Oracle, IBM or Microsoft, but by the entity providing thought leadership on the future of how databases being used…which is AWS.

Verner Vogels on Multiple Database Types

In an excellent article by Verner Vogels who is the CTO of AWS. Let us begin with how he starts the article.

“A common question that I get is why do we offer so many database products? The answer for me is simple: Developers want their applications to be well architected and scale effectively. To do this, they need to be able to use multiple databases and data models within the same application.”

Notice the last part of this paragraph, where Verner describes using “multiple databases and data models within the same application.” Wait what was that? We all know that applications have a single database right? How does a single application use multiple databases? What is Verner talking about?

Well, it turns out Verner is describing software development that is different than the monolithic environment. Verner goes on to say this..

“developers are now building highly distributed applications using a multitude of purpose-built databases.”

That is the application that we think of is one way of developing, but this is giving way to distributed applications that can access multiple databases. It is an unusual way of thinking about applications, for those of us who came up under the monolithic model.

The Limitations of the Relational Database

Verner goes on to describe the limitations of the relational database.

“For decades because the only database choice was a relational database, no matter the shape or function of the data in the application, the data was modeled as relational. Is a relational database purpose-built for a denormalized schema and to enforce referential integrity in the database? Absolutely, but the key point here is that not all application data models or use cases match the relational model.”

This we have seen in the rapid growth of databases like MongoDB and Hadoop that specialize in either unstructured data or data with lower levels of normalization. Verner describes how Amazon ran into the limitations of using the relational database.

“We found that about 70 percent of our operations were key-value lookups, where only a primary key was used, and a single row would be returned. With no need for referential integrity and transactions, we realized these access patterns could be better served by a different type of database (emphasis added). This ultimately led to DynamoDB, a nonrelational database service built to scale out beyond the limits of relational databases.”

Let us remember, AWS has a very fast growing relational database service in RDS. However, they also have fast-growing non-relational databases like DynamoDB.

The Different Database Types According to Verner

Below we have provided a synopsis of the different database types, their intended usage, and the database that reflects them by Verner.

  • Relational: Web and Mobile Applications, Enterprise Applications, Online Gaming (e.g., MySQL)
  • Key Value: Gaming, Ad Tech, IoT (DynamoDB)
  • Document: When data is to be presented as a JSON document (DynamoDB)
  • Graph: For applications that work with highly connected datasets (Amazon Neptune)
  • In Memory: Financial Services, Ecommerce, Web, Mobile Applications (Elasticache)
  • Search: Real-time visualizations and analytics generated by indexing, aggregating, and searching semi-structured logs and metrics. (Elastisearch Service)

And actually, it is a bit more complex than even Verner is letting on. This is because some databases that AWS releases or releases access to, end up being used differently than first intended. This is described in a comment on Verner’s article.

“It turns out that your products are so good that people do end up using them for a different purpose. Take Amazon Redshift. I remember when Amazon Redshift was launched, a question came from the audience if you can use Redshift as an OLTP database, even though it’s OLAP. Turns out using Redshift in an OLTP scenario is one of the major use cases, to build analytical applications. We are one of those use cases, we’ve built an analytical app on top of Redshift. The OLTP use case stretches Redshift once you start putting a serious number of users on it. Even with the best WLM configuration.

To solve for that, we’ve used a combination of Amazon RDS, Amazon Redshift and dblink plus Lambda and Elasticsearch. Detailed write-up on how we did it here:”

The Multi-Application Nature of Solutions Distributed by AWS

The multi application nature of solutions is explained as follows by Verner.

“Though to a customer, the Expedia website looks like a single application, behind the scenes Expedia.com is composed of many components, each with a specific function. By breaking an application such as Expedia.com into multiple components that have specific jobs (such as microservices, containers, and AWS Lambda functions), developers can be more productive by increasing scale and performance, reducing operations, increasing deployment agility, and enabling different components to evolve independently. When building applications, developers can pair each use case with the database that best suits the need.”

But what are packaged solutions offering? Well, monolithic applications that are the exact opposite of this. And as SAP is a perfect example of a monolithic application provider, SAP wants customers to use a single database, and further, they want customers to use “their” single database as in HANA. Which according to SAP can do all the processing as well as all the different database types described by Verner above? The one problem being, HANA can’t.

The AWS Customers Using Multibase Offerings

  • Airbnb: DynamoDB, ElastiCache, MySQL
  • Capital One: RDS, Redshift, DynamoDB
  • Expedia: Aurora, Redshift, ElastiCache, Aurora MySQL
  • Zynga: DynamoDB, ElastiCache, Aurora
  • Johnson and Johnson: RDS, DynamoDB, Redshift

Verner goes on to say.

“purpose-built databases for key-value, document, graph, in-memory, and search uses cases can help you optimize for functionality, performance, and scale and—more importantly—your customers’ experience. Build on.”

The Problem with SAP and Oracle Cloud and Leveraging the Multibase Approach

SAP and Oracle have been touting their cloud. However, with SAP and Oracle, the cloud is only a pathway to lead to SAP and Oracle’s products. This is as much true of databases. SAP and Oracle are closed systems. They dabble in connecting to non-SAP and non-Oracle, but only to co-opt an area so they can access markets. AWS and Google Cloud are quite different. Notice the variety of databases available at Google Cloud.

There are over 94 databases out at Google Cloud, and far more out at AWS. These databases can be brought up and tested very quickly. Selecting one of the databases brings up the configuration screen. Furthermore, the number of database and database types is only increasing with AWS and Google Cloud. 

Right after this is launched, one can bring up a different database type, (say NoSQL, or Graphic) and immediately begin testing. Under the on-premises model, this would not be possible. Instead of testing, one would go through a sales process, a commitment would be made, the customer would be stuck with (and feel the need to defend) whatever purchase had been made. We have entered a period of multi-base capabilities, and AWS and Google Cloud are the leaders in offering these options. This will transform or is transforming how databases are utilized. And the more open source databases are accessed, the worse commercial databases look by contrast. 

Conclusion

Packaged solutions ruled the day for decades. After the 1980s, custom coded solutions were for losers. They were to be replaced by “fantastic ERP” systems that would make your dreams come true. And who agreed to this? Well vendors and consulting companies with packaged software and packaged services to sell. Consulting companies became partners with packaged software companies, parroting everything they said, without evidence. Even to the point where almost no one in IT is even aware that packaged ERP systems have a negative ROI as we cover in the book The Real Story on ERP. ERP proved to be a false God and delivering both a negative ROI (but a positive ROI for vendors and consulting firms) while saddling companies with systems that put the ERP vendors in the driver’s seat of account control to extract more and more out of their “customers.”

Now as I read about distributed applications accessing multiple databases, are we entering a period where the pendulum switches to custom coding again. Under the SAP or Oracle paradigm, you accepted the databases that were “approved” by SAP and Oracle. All competition was driven out of the process. Oracle applications worked with the Oracle database. SAP finally decided to introduce HANA to push the Oracle DB out of their accounts. SAP now thinks that all SAP applications should sit on a SAP HANA database.

Verner is describing a combination of components that are selected and stitched together. Most of these databases are open source. And one can choose from a wide variety offered by AWS. This is inherently contradictory to packaged applications, because the packaged application uses one DB, and works in a particular and defined way.

While this is little-discussed AWS/GCP can be viewed as opposed to packaged applications. Sure, leveraging AWS/GCP will start with the migration of packaged applications, but once companies get a taste of freedom, it will begin breaking down the rules enforced by the packaged software vendors. And who will tell this story? Will it be Gartner? No. Gartner receives 1/3 of it is multi-billion dollar per year revenues from packaged software vendors, and it is doubtful that AWS or GCP will pay Gartner to sing their praises the way that the package software vendors have. Gartner presents SAP Cloud, Oracle Cloud, AWS and GCP as if they offer basically the same thing, but that AWS is simply “ahead” of SAP Cloud and Oracle Cloud. Gartner has no interest in educating their customers as to the reality of AWS and Google Cloud, as it cuts against their own corrupt revenue model.

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.

HANA & S/4HANA Research Contact

  • Interested in Research on S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is not possible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

Search Our Other HANA Content

References

https://www.allthingsdistributed.com/2018/06/purpose-built-databases-in-aws.html

AWS and Google Cloud Book

How to Leverage AWS and Google Cloud for SAP and Oracle Environments

Interested in how to use AWS and Google Cloud for on-premises environments, and why this is one of the primary ways to obtain more value from SAP and Oracle? See the link for an explanation of the book. This is a book that provides an overview that no one interested in the cloud for SAP and Oracle should go without reading.

How True is SAP’s Motion to Dismiss Teradata’s Complaint?

Executive Summary

  • SAP filed a motion to dismiss Teradata’s complaint.
  • How accurate are the statements proposed in the motion to dismiss?

Introduction to the SAP vs Teradata Lawsuit

Teradata filed a complaint against SAP in June of 2018 asserting many things that Brightwork Research & Analysis has been saying for several years. (although our research does not agree with all of Teradata’s allegations.)

Naturally, SAP said they did nothing wrong, and filed a motion to have the complaint dismissed. The reporting of the contents of the motion is from The Register. We looked for but were not able to find the actual motion to dismiss. We evaluate SAP’s statements against our own research.

Our Disclosure

We have any financial or non-financial relationship with either SAP or Teradata.

Now let us get to the quotes from the motion.

SAP Changing the Topic on the Teradata’s Complaint

“It (the complaint) also made antitrust allegations claiming SAP had attempted to edge Teradata out of the market by locking customers into its tech, noting the German giant’s ERP suite S/4HANA can only run on HANA.

However, SAP slammed these claims in a motion to have the case dismissed for once and for all, which was filed with the District Court of Northern California at the end of last month.

It argued the joint venture, known as the Bridge Project, started because Teradata “had a limited customer base” and wanted to appeal to SAP’s users – but SAP painted Teradata’s push as wildly unsuccessful, saying that just one customer signed up.”

This is not related to at least the heart of Teradata’s complaint. When SAP partners with a vendor it is never (from SAP’s perspective) to improve that vendor’s ability to sell into SAP’s customers. SAP uses partnerships to neuter competitors and to copy intellectual property, but normally work against the competing vendor’s interests. As we covered in the article How SAP’s Partnership Agreement Blocks Vendors from Fighting Indirect Access, partnerships with SAP have helped to keep competing vendors from publicly complaining about indirect access.

This is of course not to deny that Teradata wanted to appeal to SAP’s users/customers. They certainly did. That is always the motivation for vendors to engage in partnerships with SAP. However, Teradata had been doing this for decades…..that is before SAP introduced HANA and began deliberately blocking out other database vendors. Teradata’s complaint is that SAP effectively blocked them out of accounts that they shared by using HANA and the restrictions around HANA to do so. We covered this topic in the article The HANA Police.

Therefore, in this argument, SAP is attempting misdirection.

HANA is Innovative?

“SAP had been working on its own database product for years before that deal, it said, and branded “the assertion that HANA is the result of anything but SAP’s technological innovation, investment, and development is factually groundless”.

Teradata was only bringing the lawsuit because it has “fallen behind” the competition, SAP claimed.”

SAP did not “work on its own database product for years before the deal.” SAP had several databases for years, and they also acquired Sybase, but those are not related to this topic. What ended up becoming HANA were two small acquisitions purchased roughly a year before HANA was released. We covered in the article Did Hasso Plattner and His Ph.D. Students Invent HANA? That while SAP falsified a story around Hasso Plattner and his students creating HANA from scratch, the supporting technologies for HANA was purchased with the intent of making them into HANA. SAP’s big addition to the design was to remove aggregates and indexes. Hasso Plattner nor Vishal Sikka, nor Hasso Plattner’s Ph.D. students ever contributed anything that could be called intellectual property to the exercise.

How do we know?

We analyzed what was claimed by Hasso Plattner in his books and in the SAP marketing/sales material where these contentions were made.

Hasso Plattner’s books aren’t so much books as marketing pitches. Riddled with exaggerations and inaccuracies, part of what Hasso Plattner’s books do is create a narrative where Hasso and SAP created some superlative innovation in column-oriented databases. None of Hasso’s claims regarding innovation hold up to scrutiny. All of Hasso’s books (4 in total) have one purpose….not to inform, but to sell HANA. 

There is little doubt that Teradata had superior database knowledge and that SAP did seek to learn from Teradata and to use the partnership to do so. Furthermore, SAP has a history of doing exactly that with other software vendors. SAP’s xApp program was really an extensive competitive intelligence gathering operation designed to extract IP from vendors so that it could be placed into SAP’s products. We covered the xApp program in 2010 in the article Its Time for the xApp Program to End.

HANA’s design is highly problematic and cannot meet SAP’s statements about it — except in analytics, where it is only better than older versions of competitive databases and only when using far larger hardware footprints as covered in How Much of HANA’s Performance is Hardware? SAP’s statements about HANA’s superiority are false.

The Mystery of HANA’s Lack of Use Outside of SAP Accounts

HANA is not purchased outside of SAP accounts; it is only purchased by accounts controlled by SAP where the IT customers failed to perform their research into SAP’s claims. If the outlandish claims around HANA are true, why aren’t non-SAP customers using it? No other database fits this profile.

  • Oracle sells databases to everyone not just to customers that buy Oracle’s applications and where they have account control.
  • SQL Server is found everywhere, not only on accounts where Microsoft sells their ERP system.

Bill McDermott stated that HANA works “100,000 times faster than any competing technology.” If that is true, why do only SAP customers buy it?

Teradata’s IP Puffery

Through the original complaint, Teradata overstates its intellectual property implying that they have some secret sauce no one else has. The designs that are similar to HANA are all over the place. AWS has Redshift which is similar in design to HANA. And both Google Cloud and AWS have Redis, which is also similar to HANA (although in a different dimension). Reading Teradata’s complaint is symptomatic of commercial software companies perpetually overstating how unique their software is. However, the claim is axiomatic, declarations of uniqueness and innovation are known to correlate with commercial software sales positively. Teradata’s complaint also exclaims how employees are made to sign NDAs so that Teradata’s technology secrets are not distributed outside of Teradata, but neglects to mention how much Teradata benefits from those same employees add to Teradata’s IP. Apparently, by inference, all of the Teradata IP was created by executives, and not employees. And where did Teradata originally develop its database from? That is right, from using database concepts that were in the public domain.

As with pharmaceutical companies which commercialize research that performed by universities and is funded by taxpayers through the National Institutes of Health, as soon as a software vendor wants to sell software, the public domain very conveniently recedes into the background, and the narrative of “their IP” is wheeled out front and center.

Big Money Equals More IP Protection?

As readers can tell, we find the IP theft argument made by Teradata to be the least persuasive part of their complaint. Other vendors have far greater claims regarding SAP stealing their IP than does Teradata. But Teradata is a rich software vendor and has the money to bring a case like this. Therefore, their IP concerns are considered relevant, whereas a smaller software vendor’s IP concerns are considered less relevant (perhaps irrelevant?).

Teradata Has Fallen Behind…….SAP’s Marketing Department?

SAP states that Teradata has “fallen behind” SAP. However, in technical circles, SAP is still not a respected database vendor. Teradata, although they are known to charge far too much for what they offer and to overpromise, are technically respected. The only place that Teradata has fallen behind SAP in databases is in marketing.

Teradata Cannot Compete with S/4HANA?

SAP goes on to make an assertion that is so absurd, that SAP must believe the judge will make zero effort to fact check the statement.

“Teradata has not been able to compete effectively with S/4HANA because it only focuses on its flagship analytical database and has failed to offer innovative and relevant compelling products,” the filing stated.

Teradata does not compete with S/4HANA. They compete with HANA.

The reason Teradata has not been able to compete in SAP customers with S/4HANA is that SAP made it a requirement that HANA only copy data to a second instance of HANA. This made Teradata uncompetitive as it would massively increase the cost (HANA is an exorbitant database in its TCO, which we estimated in the Brightwork Study into SAP HANA’s TCO) This is not merely a Teradata issue, SAP is using these rules against all the database competitors and using them against SAP customers. Reports of these abuses come in from different places around the world to us.

Therefore, SAP’s statement about failing to offer innovative and “relevant competing products” rings hollow. This is particularly true since HANA is not an innovative product, but as we covered, in Did SAP Simply Reinvent the Wheel with HANA.

SAP backward engineered other databases combined with its acquisitions of other database components. To hide this backward engineering, and to seem innovative, SAP has renamed items that already had generally accepted names. For instance, what SAP calls “code pushdown” is simply the same old stored procedure as we covered in How Accurate are SAP’s Arguments on Code Pushdown and CDSs.

Teradata Must Develop an ERP System to Compete?

The sentence related to Teradata only focusing on its “flagship analytical database” by SAP contains an important assumption that should be fleshed out by the judge during the case. The assumption made clear by this statement is that Teradata should not offer only analytical/database products to compete with SAP, but needs to develop its own ERP system.

This fits within the construct that SAP finds appealing, which is that the ERP vendor should control the entire account. And it is an inherently anti-competitive assumption. What is most curious, is that SAP does not even appear to realize how this exposes them as monopolistic in their thought processes. That is not supposed to be the assumption of ERP systems. ERP vendors are entitled to offer the customer more products, but selling the ERP system to a customer does not entitle that vendor to all of the IT spend of that company.

SAP Lacks Power in Its Own Customers?

One has to really stand in awe of SAP’s next proposal to the judge. SAP would like the judge to think that SAP lacks influence in……SAP accounts.

“SAP said Teradata’s allegations that it was monopolising the enterprise data analytics and warehousing market also fell flat, arguing it had failed to even identify SAP’s power in that market.

“The [complaint] alleges nothing more than that Teradata now has to compete in its favored marketplace,” SAP said.”

Here SAP’s attorneys try another sleight of hand. Rather than addressing anything true, SAP’s (what must be very highly paid) attorneys prefer to change the subject to see if the judge will notice.

Can judges be hypnotized? If so, SAP has a chance with this argument. 

Teradata’s allegation is that SAP is blocking them out of SAP accounts. And that this is anti-competitive. SAP has created false technical proposals including the incredible bizarre restrictions that HANA must be copied only to HANA and not to Teradata. I have discussed these limitations with people with decades of database experience, and none of us can make any sense of the restrictions. They are unprecedented and designed merely to capture market share. Those are real impediments to Teradata, and they are meant to be.

Furthermore, these restrictions are costing SAP customers in a major way. SAP wants customers to upgrade to S/4HANA, which comes with HANA, and as soon as they do, they will find themselves subject to all manner of restrictions that did not exist with the previous database they were using (Oracle, DB2, SQL Server). SAP plans to use these restrictions to push out from ERP making HANA mandatory and “making the customer’s choice for them.”

Teradata need not identify SAP’s “power in the analytics market,” as SAP has enormous and undisputed power in their clients. Anyone who has worked in SAP consulting knows this. Now those clients previously were happy to use Teradata and SAP side by side and did for many years. But SAP, through these restrictions made it difficult for Teradata to continue to do business in SAP accounts. In fact, according to the Teradata complaint, many of their customers they shared with SAP gave them ultimatums that they would have the previous levels of interoperability with SAP, or their customers would leave them. This is quite believable, as SAP greatly reduced the value of Teradata in SAP accounts by making the integration to Teradata so much more expensive.

The entirety of SAP’s restrictive policies is to injure competitors and to absorb more income from customers. SAP is in a particularly weak position here now that all of their claims regarding HANA’s superiority have been pierced as we covered in Articles that Exaggerate HANA’s Benefits and How to Deflect That Your Were Wrong About HANA.

S/4HANA and HANA are the Same Product?

“Regarding antitrust claims, SAP said Teradata “does not plausibly allege that SAP coerces its customers into purchasing HANA”. It added assertions that S/4HANA unlawfully ties HANA to ERP software are misguided, as they aren’t separate products.

Rather, it is one integrated product sold to customers as so, compared to separate ERP and database wares.”

SAP’s attorneys should have checked this with the technical resources at SAP because these two paragraphs are unsupportable and make it plain that the attorneys mean to trick the judge.

First S/4HANA is unlawfully tied to HANA because…

  • a) There is no technical reason to restrict S/4HANA to HANA. The evidence is that HANA underperforms the competing database alternatives as we covered in What is the Actual Performance of HANA. and..
  • b) Products that are tied together in order block out competitors are illegal under the tying arrangement clause of the US antitrust law. This is the exact clause of our antitrust law used by the DOJ to win a judgment against Microsoft back in the 1990s.

Something else which will be difficult for SAP to explain — how is an application like S/4HANA and a database like HANA a single integrated product? Can SAP name another ERP system that is “integrated as a product with its database?” Here is another question, if S/4HANA and HANA are the same product, why are they priced separately and listed as different products in the SAP price list? A third question. Is HANA now integrated to the BW also? As BW can be deployed on HANA, they must also be a single fused product!

Teradata’s Real Complaint is SAP Would Not Integrate with Teradata’s DB?

“Teradata’s real complaint is that SAP chose to offer this integrated system with HANA, rather than integrating with Teradata’s database; the antitrust laws, however, are designed to prevent injury to competition, rather than injury to competitors,” SAP said.”

This is a very strange wording by SAP. However, the issue that SAP is hoping the judge is confused by is that the restrictions are not technical. Teradata has been integrating to (often Oracle) databases on customers with SAP applications for decades. The issue is not technical; it is how SAP setup the charges and used indirect access to cut off their database from being accessed by Teradata. Indirect access is a violation of the tying arrangement discussed previously and covered in the article SAP’s Indirect Access Violates US Anti Trust Law. Notice Teradata’s use of the specific term tying arrangement in this quote from the complaint.

“On information and belief, SAP has also begun significantly restricting Teradata’s ability to access customers’ SAP ERP data stored in HANA (which is necessary for the functional use of Teradata’s EDAW products), thereby ensuring the success of its tying arrangement in coercing customers to adopt HANA.”

The second part of the paragraph from the SAP quotation regarding “designed to prevent injury to competition, rather than injury to competitors seems to be some type of wordplay. This would be like saying laws against murder are designed to protect society in general but are not designed to protect the murder of any one particular person.

Teradata is being blocked because of SAP’s unwarranted tying arrangement between S/4HANA and HANA. Teradata is a competitor, and SAP is not competing with them by offering customers to choose between HANA and Teradata. They are using the SAP ERP system, previous versions which did not have these restrictions, to be restricted.

This is stated in the Teradata complaint.

“Moreover, and on information and belief, SAP has begun significantly restricting Teradata’s ability to access customers’ SAP-derived data. Through this conduct, SAP has deliberately sought to exploit its large, existing ERP customer base to the detriment of Teradata and its customers. Given the extremely high costs of switching ERP providers, SAP’s ERP customers are effectively locked-in to using SAP’s ERP Applications, and SAP is now attempting to lock them into using only HANA in the EDAW market as well.”

This is the exact reason we have argued against ERP systems; they are continually used to take control of the customer’s IT spend through account control, as covered in the article How ERP Systems Were a Trojan Horse. 

The strategy by SAP’s attorneys here is called “muddying the water.”

SAP Requires More Explanation as to Inefficiencies?

“For instance, SAP said the US-based Teradata was vague about the “inefficiencies” it claims to have identified in SAP’s systems it offered; failed to precisely identify what trade secrets were stolen; and failed to allege that SAP breached the contracts drawn up for the Bridge Project.

“To the contrary, much of what the [complaint] alleges as purported misconduct (which SAP denies) is expressly permitted by the relevant provisions of the Bridge Project Agreements,” the ERP giant said.”

Here we agree with SAP on the trade secret allegation.

Conclusion

What can be taken from this motion to dismiss? The arguments related to trade secrets seem correct. SAP most likely did benefit from Teradata’s advice and expertise related to how to improve HANA. SAP would have naturally tried to learn things from Teradata. SAP was very unsophisticated regarding databases, particularly back when they were cobbling together HANA from acquisitions and with ideas gleaned from other databases vendors. But this backward engineering was not restricted to Teradata. And we have yet to see evidence that Teradata offered a substantial portion of IP that eventually became HANA.

Furthermore, HANA is not a competitive product. Therefore, whatever SAP may have taken from Teradata was either not particularly good, or SAP screwed up the implementation of the concept. HANA’s power comes from its association with SAP, not from HANA’s capabilities as a product.

SAP’s arguments against Teradata’s claims regarding anti-competitive behavior go beyond anything reasonable, dance in the area of insulating and make one wonder about the attorneys used by SAP. Any person who would make these arguments to me would so ruin their credibility; I would never listen to them again.

The impression given is that SAP hopes to find a weak judge who would believe such arguments. A motion to dismiss is automatic, but if this is what SAP came up with (assuming there was no miscommunication with the attorneys and SAP) this case appears to be a substantial risk for SAP. Teradata is asking for SAP to change the way they do business essentially. Teradata’s request is entirely consistent with demanding the SAP follow the normal rules of competition. SAP is asking that the US courts allow them to use tricks and deception to push vendors out of “their” customers. SAP claims to own them because they have sold them an ERP system. Teradata is asking for the courts to bar some of SAP’s behaviors as covered in the following quotation in the Teradata complaint.

“Teradata therefore is entitled to an injunction barring SAP’s illegal conduct, monetary damages, and all other legal and equitable relief available under law and which the court may deem proper.”

US courts are not the best place for anticompetitive enforcement. One question might be, why is the FTC not investigating SAP? The exact issues listed by Teradata in their complaint have been reported to us for years. But as the FTC no longer is interested in enforcing antitrust law, this is Teradata’s only option. The US economy is increasingly dominated by larger and larger entities, something which reduces competition and depresses wages.

Other vendors should show an interest in this case because SAP is claiming the vendor selling the ERP system has the right to push the other vendors from the account. If the US courts allow them to do it to Teradata, which is a vendor with large amounts of resources, they can do it to anyone.

Search Our Other HANA Content

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.

HANA & S/4HANA Research Contact

  • Interested in Research on S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is not possible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

https://www.theregister.co.uk/2018/09/03/sap_response_teradata_lawsuit/

https://www.businesstoday.in/current/corporate/day-after-teradata-filed-ip-theft-suit-against-sap-vishal-sikka-terms-charges-baseless-outrageous/story/279442.html

https://assets.teradata.com/News/2018/2018-06-19-Complaint.pdf

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.

Chapters

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

How HANA Takes 30 to 40 Times the Memory of Other Databases

Executive Summary

  • HANA takes extremely enormous levels of memory compared to competing databases.
  • HANA has continual timeout issues that are in part due to HANA’s problem managing memory.

Introduction to HANA’s Problems with Managing Memory

SAP’s database competitors like Oracle, IBM, and Microsoft, have internal groups that focus on memory optimization. Memory optimization (in databases) is how tables are moved into and out of memory. However, SAP tries to push more tables into memory that are necessary (but not as many tables as they state that they do, that is not “all the tables”). However, SAP does not have the optimization capabilities of the other database vendors.

High Memory Consumption with HANA

HANA’s high memory consumption is explained in their SAP HANA Troubleshooting and Performance Analysis Guide where they state the following.

“You observe that the amount of memory allocated by the SAP HANA database is higher than expected. The following alerts indicate issues with high memory usage.”

And..

“Issues with overall system performance can be caused by a number of very different root causes. Typical reasons for a slow system are resource shortages of CPU, memory, disk I/O and, for distributed systems, network performance.”

This is odd for SAP to observe shortages of resources. This is because HANA has the highest hardware specification of any other competing database. Also, the comparison is not even close. This is pointed out again by SAP regarding memory.

“If a detailed analysis of the SAP HANA memory consumption didn’t reveal any root cause of increased memory requirements it is possible that the available memory is not sufficient for the current utilization of the SAP HANA database.”

Conclusion

The same question arises, with so much memory usually part of the initial sizing, why is undersized HANA memory such an issue?

Search Our Other HANA Content

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.

HANA & S/4HANA Research Contact

  • Interested in Research on S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is not possible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

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.

Chapters

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

How to Understand HANA’s High CPU Consumption

Executive Summary

  • HANA has high CPU consumption due to HANA’s design.
  • The CPU consumption is explained by SAP, but we review whether the explanation makes sense.

Introduction to HANA CPU Consumption

At Brightwork we have covered the real issues with HANA that are censored by SAP, SAP consulting firms and IT media. As a result of this information being censored, many SAP customers have been hit with many surprises related to implementing HANA.

In this article, we will address HANA’s CPU consumption or overconsumption.

HANA CPU Overconsumption

A second major issue in addition to memory overconsumption with HANA is CPU consumption.

HANA’s design is to load data that is not actually planned to be used in the immediate future into memory. SAP has decreased it rather unrealistic position on “loading everything into memory,” but it still loads quite a lot into memory.

The reason for the CPU overconsumption is this is how a server reacts when so much data is loaded into memory. The CPU spikes. This is also why CPU monitoring along with memory monitoring is considered so necessary for effectively using HANA, while this is not an issue normally with competing databases from Oracle, IBM or others.

SAP’s Explanation for Excessive CPU Utilization by HANA

SAP offers a peculiar explanation for CPU utilization.

“Note that a proper CPU utilization is actually desired behavior for SAP HANA, so this should be nothing to worry about unless the CPU becomes the bottleneck. SAP HANA is optimized to consume all memory and CPU available. More concretely, the software will parallelize queries as much as possible to provide optimal performance. So if the CPU usage is near 100% for query execution, it does not always mean there is an issue. It also does not automatically indicate a performance issue”

Why Does SAP’s Statement Not Make Sense

This entire statement is unusual, and it does not explain several issues.

Why HANA Times Out if the CPU is Actually Being Optimized?

Timing out is an example of HANA not being able to manage and throttle its resource usage. Timing out requires manual intervention to reset the server. If a human is required to intervene or the database ceases to function, this obviously means that resources are not being optimized. We have common reports at some companies of their HANA server needing to be reset multiple times a week.

This is supposed to be a standard capability that comes with any database that one purchases. Free open-source databases do not have the problem that HANA has.

If an application or database is continually consuming all resources, the apparently the likelihood of timeouts increases. It also presents a false construct that HANA has optimized the usage of the CPU, which is not correct. It seeks to present what is a bug in HANA as a design feature.

Why HANA Leaves A High Percentage of Hardware Unaddressed

Benchmarking investigations into HANA’s utilization of hardware indicate clearly that HANA is not addressing all of the hardware that it uses. While we don’t have both related items evaluated on the same benchmark, it seems very probable that HANA is timing out without addressing all of the hardware. Customers that purchase the hardware specification recommended by SAP often do not know that HANA leaves so much hardware unaddressed.

The Overall Misdirection of SAP’s Explanation

This paragraph seems to attempt to explain away the consumption of hardware resources by HANA that in fact, should be a concern to administrators. This statement is also inconsistent with other explanations about HANA’s use of memory, as can be seen from the SAP graphic below.

Notice the pool of free memory.
Once again, notice the free memory in the graphic.

This is also contradicted by the following statement as well.

“As mentioned, SAP HANA pre-allocates and manages its own memory pool, used for storing in-memory tables, for thread stacks, and for temporary results and other system data structures. When more memory is required for table growth or temporary computations, the SAP HANA memory manager obtains it from the pool. When the pool cannot satisfy the request, the memory manager will increase the pool size by requesting more memory from the operating system, up to a predefined Allocation Limit. By default, the allocation limit is set to 90% of the first 64 GB of physical memory on the host plus 97% of each further GB. You can see the allocation limit on the Overview tab of the Administration perspective of the SAP HANA studio, or view it with SQL. This can be reviewed by the following SQL
statement

select HOST, round(ALLOCATION_LIMIT/(1024*1024*1024), 2)
as “Allocation Limit GB”
from PUBLIC.M_HOST_RESOURCE_UTILIZATION”

SAP’s Inaccurate Messaging on HANA as Communicated in SAP Videos

Fact-Checking SAP’s HANA Information

This video is filled with extensive falsehoods. We will address them in the sequence they are stated in this video.

SAP Video Accuracy Measurement

SAP's Statement
Accuracy
Brightwork Fact Check
Link to Analysis Article
HANA is a Platform
0%
HANA is not a platform, it is a database.How to Deflect You Were Wrong About HANA
HANA runs more "in-memory" than other databases.
10%
HANA uses a lot of memory, but the entire database is not loaded into memory.How to Understand the In-Memory Myth
S/4HANA Simplifies the Data Model
0%
HANA does not simplify the data model from ECC. There are significant questions as to the benefit of the S/4HANA data model over ECC.Does HANA Have a Simplified Data Model?
Databases that are not HANA are legacy.
0%
There is zero basis for SAP to call all databases that are not HANA legacy.SAP Calling All Non-HANA DBs Legacy.
Aggregates should be removed and replaced with real time recalculation.
0%
Aggregates are very valuable, and all RDBMS have them (including HANA) and they should not be removed or minimized in importance.Is Hasso Plattner Correct on Database Aggregates?
Reducing the number of tables reduces database complexity.
0%
Reducing the number of tables does not necessarily decrease the complexity of a database. The fewer tables in HANA are more complicated than the larger number of tables pre-HANA.Why Pressure SAP to Port S/4HANA to AnyDB?
HANA is 100% columnar tables.
0%
HANA does not run entirely with columnar tables. HANA has many row-oriented tables, as much as 1/3 of the database.Why Pressure SAP to Port S/4HANA to AnyDB?
S/4HANA eliminates reconciliation.
0%
S/4HANA does not eliminate reconciliation or reduce the time to perform reconciliation to any significant degree.Does HANA Have a Simplified Data Model and Faster Reconciliation?
HANA outperforms all other databases.
0%
Our research shows that not only can competing databases do more than HANA, but they are also a better fit for ERP systems.How to Understand the Mismatch Between HANA and S/4HANA and ECC.

The Problem: A Lack of Fact-Checking of HANA

There are two fundamental problems around HANA. The first is the exaggeration of HANA, which means that companies that purchased HANA end up getting far less than they were promised. The second is that the SAP consulting companies simply repeat whatever SAP says. This means that on virtually all accounts there is no independent entity that can contradict statements by SAP.

This is an example of a statement by SAP that is designed to make a bug and design issue, something that occurred very early in the development of HANA, but which SAP never addressed (or thought they could address by simply adding more memory) into a positive feature. Other databases do not have this problem. There is no open-source database that we have ever heard of having this problem. It is just a very odd problem. HANA projects and implementations run into issues that they can’t get straight answers from SAP or from their SAP consulting firm.

Being Part of the Solution: What to Do About HANA

We can provide feedback from multiple HANA accounts that provide realistic information around HANA — and this reduces the dependence on biased entities like SAP and all of the large SAP consulting firms that parrot what SAP says. We offer fact-checking services that are entirely research-based and that can stop inaccurate information dead in its tracks. SAP and the consulting firms rely on providing information without any fact-checking entity to contradict the information they provide. This is how companies end up paying for a database which is exorbitantly priced, exorbitantly expensive to implement and exorbitantly expensive to maintain. When SAP or their consulting firm are asked to explain these discrepancies, we have found that they further lie to the customer/client and often turn the issue around on the account, as we covered in the article How SAP Will Gaslight You When Their Software Does Not Work as Promised.

If you need independent advice completely outside of SAP or your SAP consulting firm, reach out to us at the form below.

Inaccurate Messaging on HANA as Communicated in SAP Consulting Firm Videos

For those interested in the accuracy level of information communicated by consulting firms on HANA, see our analysis of the following video by IBM. SAP consulting firms are unreliable sources of information about SAP and primarily serve to simply repeat what SAP says, without any concern for accuracy. The lying in this video is brazen and shows that as a matter of normal course, the consulting firms are happy to provide false information around SAP.

Copy of
SAP Video Accuracy Measurement

SAP's Statement
Accuracy
Brightwork Fact Check
Link to Analysis Article
HANA runs more "in-memory" than other databases.
10%
HANA uses a lot of memory, but the entire database is not loaded into memory.How to Understand the In-Memory Myth
HANA is orders of magnitude faster than other databases.
0%
Our research shows that not only can competing databases do more than HANA, but they are also a better fit for ERP systems.How to Understand the Mismatch Between HANA and S/4HANA and ECC.
HANA runs faster because it does not use disks like other databases.
0%
Other databases also use SSDs in addition to disk.Why Did SAP Pivot the Explanation of HANA In Memory?
HANA holds "business data" and "UX data" and "mobile data" and "machine learning data" and "IoT data."
0%
HANA is not a unifying database. HANA is only a database that supports a particular application, it is not for supporting data lakes.
SRM and CRM are part of S/4HANA.
0%
SRM and CRM are not part of S/4HANA. They are separate and separately sold applications. SAP C/4HANA is not yet ready for sale. How Accurate Was Bluefin Solutions on C-4HANA?
Netweaver is critical as a platform and is related to HANA.
0%
Netweaver is not relevant for this discussion. Secondly Netweaver is not an efficient environment from which to develop.
HANA works with Business Objects
10%
It is very rare to even hear about HANA and Business Objects. There are few Buisness Objects implementations that use HANA.SAP Business Objects Rating
Leonardo is an important application on SAP accounts.
0%
Leonardo is dead, therefore its discussion here is both misleading and irrelevant.Our 2019 Observation: SAP Leonardo is Dead
IBM Watson is an important application on SAP accounts.
0%
Watson is dead, therefore its discussion here is both misleading and irrelevant.How IBM is Distracting from the Watson Failure to Sell More AI and Machine Learning
Digital Boardroom is an important application on SAP accounts.
0%
SAP Digital Boardroom is another SAP item that has never been implemented many places.

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.

HANA & S/4HANA Research Contact

  • Interested in Research on S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is not possible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

Search Our Other HANA Content

References

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.

Chapters

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

Risk Estimation and Calculation

Risk Estimation and Calculation

See our free project risk estimators that are available per application. The provide a method of risk analysis that is not available from other sources.

project_software_risk

HANA’s Time in the Sun Has Finally Come to an End

Executive Summary

  • SAP has been forced to move HANA into the background of its marketing focus for various reasons.
  • Trends shifted away from proprietary databases towards open source databases.
  • Marketing claims about HANA being groundbreaking turned out to be false. HANA had no offerings that gave it an advantage over competing solutions and it proved to have the highest TCO among its competitors.

Introduction: The Real Story on SAP’s HANA Focus

In this article, we will cover the how SAP has finally moved HANA into the background of its marketing focus.

SAP’s Marketing Transition Away from HANA

In 2011 HANA became the primary marketing tentpole for SAP, replacing Netweaver which had been the primary focus at that time.

The official date where HANA was replaced in this position in SAP’s marketing orbit can be marked as June 5th. That is the first day of SAPPHIRE 2018. This is because HANA was noticeably less prominent at SAPPHIRE 2018 than it had been since its introduction.

SAP Thought it Had Cracked Oracle’s Code

SAP’s obsession with HANA reached a fevered pitch from the 2011 and to 2018 timespan. SAP had actually (I believe) convinced itself that it had done something that it had not come close to doing (which is come up with the “killer app” in the database market). SAP thought that combining a column-oriented (partial column oriented it later turned out) database combined with more memory had never been executed as had been done by SAP. As is well known, SAP acquired all of its technology for this design and my analysis which is partially documented in the article Did Hasso Plattner and His Ph.D. Students Invent HANA? 

SAP’s contribution to the combined analytics processing and transaction processing database was to market it. This powerful marketing by SAP caused Oracle and IBM to move resources into developing such functionality in their databases — a move which I think was a misallocation of resources. Research by Bloor Research which I analyzed in the article How Accurate Was Bloor on Oracle In Memory, covered the extra overhead of Oracle’s in-memory offering.

SAP Pays Forrester to Make a New Database Category

SAP paid good money to try to make mixed OLTP and OLAP from one database “a thing” going so far as to pay Forrester to create a new faux database category called the “transanalytical database.”

And surprise surprise, HANA was declared a leader in this new database category! We covered this in the article What is a Transanlytical Database?(It is a new database category, specifically for those that don’t know much about databases.)

This is something that Bill McDermott crowed about on the Q4 2017 earnings call but failed to point out that SAP had paid Forrester for this study.

One wonders how much in market cap was added because of this report, and how much that added to how many stock options that were exercised by the top executives at SAP. Even if it were a very small number of percentage points, it would still make whatever SAP paid Forrester an absolute steal.

The Trend Away from HANA

Databases have become increasingly diversified since HANA was first introduced, and because of IaaS like AWS and Azure, it is now increasingly easy to spin up multiple database types and test them. Moreover, the biggest trend is not patent software databases, but open source databases. Also, since HANA’s initial introduction, the trend towards open source database has only grown. This is offering more different database types than ever before.

There is even now a database focused on something called horizontal scalability and disaster recovery called CockroachDB. There is more opportunity than ever before to access specialized databases with different characteristics. And due to IaaS providers, these databases are far more simple to provision and test than in the past. Open source databases can be spun up and tested and distributed like never before. Yet, the presentation by SAP to customers that there are only two database processing types (analytics and transactions) that they need to worry about and that HANA covers the bases. SAP could not have picked a more incongruous messaging and strategy around databases if they set out to do so from the beginning of HANA’s development.

The best transaction processing database is a row-oriented database. The best analytic database is a database like Redis or Exadata. If one tries to get both out of a single database, compromises quickly ensue, and maintenance costs go up.

What the HANA Experiment Illustrated

For many years since HANA was introduced, I had a quite a few people who had little experience with databases telling me (and anyone who would listen actually) how earth-shattering HANA would be. These bold statements were brought forth by people with often no experience with databases. It became evident to me through many conversations that the person often was simply repeating what they heard from SAP. But the problem was that SAP made statements about HANA and databases in general that were in error.

What this taught me was that a sizable component of the population in enterprise software are willing to not only discuss things but be highly confident in presenting stuff for which they have no way of knowing if are correct. It means that a large component of those that work in SAP are faking knowledge.

The proposals were so off the wall that I was subjected to that they needed their own laugh track. I had partners from Deloitte and CapGemini and several other firms, people who would not know the definition of a database index, who have not been in anything but the Microsoft Office suite in several decades, telling me with great certitude how HANA would change everything.

“You see Shaun, once we columnar in-memory databases are used for transaction systems, the entire BI system goes away.”

Many of the statements by SAP executives or by SAP consulting partners seem very much like the Jimmy Kimmel Live segment called Lie Witness News. I could describe it but see for yourself.

These people have an opinion on the US invasion of a fictional country, without asking “where is Wakanda?” If you ask these same people “do you think SAP’s HANA database is very good and better than all other databases,” what answer would we get? 

Time to Admit You Don’t Know Wakanda Does Not Exist (and that HANA is not GroundBreaking)?

The issue is a combination of dishonesty combined with the assumption that something must be true because it is presented and proposed by a large entity (in this case the US military being in Wakanda). This happens all the time, and the people that propose things without checking are often quite experienced. This is of course doubly a problem when consulting companies see jumping on whatever the new marketing freight train that SAP has as critical to meeting a quota.

The upshot is that a very large number of people that repeated things about HANA without either having the domain expertise to know or without being bothered to check should be highly embarrassed at this point. And these are people in a position to advise companies, which is where the term the “blind leading the blind” seems most appropriate at this moment. Its important for SAP customers to know, if Capgemini, Deloitte, Accenture, Infosys, etc…..were trying to get you to purchase and implement HANA, they had no idea what they were talking about, or did not care what was true. They were, as required by the SAP consulting partnership agreement, and along with the sales quota incentives they have, repeating what SAP told them. And for nearly everything SAP proposed about HANA, they simply made it up. SAP not only made up the benefits offered by HANA, but they made up a fictitious backstory of how HANA was “invented” as we covered in the article Did Hasso Plattner and Ph.D.’s Invent HANA?

The rise of HANA lead to many people with only a cursory understanding of databases talking a lot about databases. Naturally, their statements, promoted by SAP, had a very low accuracy. With HANA moving back in SAP’s enormous deck of cards of SAP products, now the topic of databases can shrink down closer to the group of people that know something about them.

That is a positive development.

HANA Was Going to Change the World?

HANA was supposed to change the world. However, what did it change?

If we take just one example, the idea of loading all of the databases into memory, if one looks at the vendors with far more experience in databases than SAP, no one does this. The reason is that it is wasteful when only a small percentage of the tables are involved in the activity. This is why each database vendor has a group that focuses on memory optimization. And it was eventually determined that SAP says that they load the entire database into memory, but they don’t. Memory optimization still rules the day. This is just one example, I could list more, but outside of marketing, HANA did not change much and either all or nearly all of its projections turned out not to be true.

The Final Outcome of HANA

Customers that implemented HANA now have a higher TCO database, a far buggier database, and they have had to run more databases in parallel. After years of analyzing this topic, I can find no argument for replacing existing databases with HANA, or for beginning new database investments by selecting HANA.

Lets us traverse through the logic because it seems to be tricky.

  1. Does HANA perform better in analytics processing than previous versions of Oracle or DB2 that did not have column capabilities and ran on older hardware? Yes.*
  2. Does HANA outperform or have any other associative capability that gives it an advantage against the major competing offerings? No
  3. Does HANA have the most bugs and highest TCO of any of the offerings it competes against? Yes
  4. Is HANA the most expensive of all the offerings it competes against? Yes.

*(The topic that SAP has routinely tried to get clients to think that HANA on new hardware should be compared against Oracle and DB2 on old and far less expensive hardware is covered in the article How Much Performance is HANA?)

Where are HANA’s Sales Outside of Companies that Already Run SAP Applications?

Is some explanation for why HANA is not purchased outside of SAP accounts. The sales pitch was that HANA was so much more advanced than competing offerings that not only S/4HANA but other SAP applications could not work to their full extent without it. It was going to be so easy to develop on with the HANA Cloud Platform (now SAP Cloud or SAP Cloud Platform) that developers outside of SAP were going to flock to it because of its amazing capabilities. Right? SAP said all these things and many more.

However, if all of this was true, shouldn’t SAP be able to sell HANA to customers that don’t use SAP applications? Vishal Sikka stated that HANA was instrumental to a wide variety of startups.

Where is that market?

The answer is nowhere. That should give us pause regarding SAP’s claims.

Is SAP Dedicated to Breaking the “Dependency” on Oracle?

SAP justified all of the exaggerations in part by convincing themselves they were going to help their customers “break” their dependency on Oracle (and to a lesser degree DB2). However, one has to question how dedicated one is to “breaking a dependency” when the desired outcome is not to switch dependency to SAP. When a customer buys from a competitor, that supposedly is a “dependency.” However, when a customer buys the same item from you, that is a “relationship.” This sounds a bit like the saying that a person can either be a “terrorist” or a “freedom fighter,” depending upon one’s vantage point.

The Logic for the Transition

If we look at the outcome, HANA is not a growing database.

HANA has not grown in popularity since Feb 2017. Moreover, it has not increased significantly since November of 2015. And let us recall, this is a database with a huge marketing push.

It cost SAP significantly to redirect its marketing budget, to emphasize HANA over other things is could be emphasizing. In fact, I have concluded that really most of HANA’s growth was simply due to its connection to SAP. If HANA had to acquire customers as a startup, it would have ceased to exist as a product a long time ago. The product itself is just not that good.

A second point is that HANA was enormously exaggerated in terms of its capabilities.

Point three is that some HANA purchases were made to satisfy indirect access claims, that is they were coerced purchased. I am still waiting for a Wall Street analyst to ask the question.

“How much of the S/4HANA and HANA licenses are related to indirect access claims?”

Apparently, Wall Street analysts have a process where they keep away from actually interesting questions.

Diminishing Returns for Focusing on HANA

SAP was not getting a return from allocating so many of its is promotional resources to showcasing HANA. Furthermore, the customers were becoming “HANA resistant.” The over the top HANA emphasis by SAP had become a point of contention and often ridicule at customers (which I learned through my client interactions)

All of this would not have happened without Hasso Plattner. Hasso bet big on HANA, and Hasso was wrong. HANA was allowed to be promoted on tenuous grounds because its champion was Hasso Platter.

In Hasso Plattner’s Book The In-Memory Revolution he stated the following: 

“At SAP, ideas such as zero response time database would not have been widely accepted. At a university, you can dream, at least for a while. As long as you can produce meaningful papers, things are basically alright.”

The problem? Zero latency has not been achieved by HANA to this day. It was never a reasonable goal. And Hasso illuminated something else with this quote. University students are even less willing to push back on Hasso than career database professionals. A fundamental reason is they have much more experience.

The True Outcome of HANA

SAP is now stuck with a buggy database unable to come close to its performance promises, and which has influenced SAP’s development in other areas in a wasteful manner. For example, many of the changes that were made to S/4HANA to accommodate HANA turn out to have not been necessary and have extended out S/4HANA development timeline. Secondly, the requirement that S/4HANA only use HANA has both restricted the uptake of S/4HANA, and will continue to do so. S/4HANA could be overall much farther along if it was just “S/4” and ran on AnyDB.

Now companies that purchased HANA will try to justify the purchase (no one likes to admit they got bamboozled) because BW runs faster. However, these same executive decision makers entirely leave out the impact of HANA’s far more expensive hardware in the performance analysis. Companies that purchase HANA for BW don’t test or hire out tests to determine how much of the performance benefit is due to hardware. That is how much Oracle or DB2 (and a modern version of Oracle and DB2) would perform on the same hardware.

No, instead they tell me that performance for BW improved over an eight-year-old version of Oracle or DB2 on eight-year-old hardware that because it has much more disk than memory and cost a small fraction of the HANA hardware. So with BW companies can hide HANA’s performance limitations (although not its maintenance overhead). However, HANA has many problems meeting customer expectations for things that SAP said performance would skyrocket, which include…well everything but short SQL queries.

This means that SAP will be fighting fires no HANA performance for S/4HANA for transaction processing and MRP processing for years. SAP would have none of these problems if they simply did what they had always done, allow the companies that really knew databases to provide the database. As pointed out by a colleague..

“The far bigger threat and loss of income and account control to SAP is from IaaS/PaaS providers, not database vendors. “

Conclusion

SAP was never a database company, and now it looks like it won’t be (a significant one) in the future. And, there is nothing wrong with that. In retrospect, SAP’s acquisitions of Sybase and other purchases (that it made very quietly) that ended up being HANA could have been invested to much better effect by merely fixing issues in ECC and upgrading product support.

HANA will still be there, but SAP’s marketing focus is moving on to other things. Right now it’s unclear exactly which it will choose. C/4HANA is the new kid in town. S/4HANA is still a centerpiece. SAP has so many products, toolkits, announcements, and concepts to promote that SAP marketing is a beehive of activity. However, the overhyping of HANA to promote S/4HANA has subsided. S/4HANA will now be more sold on its functionality (as ECC always was).

What the Future Holds for HANA

SAP has shifted to making the compatibility argument to customers, but not in public. Publicly SAP says that the only application for which HANA is a requirement is S/4HANA. However, through the sales reps repeatedly makes the argument that their applications can only work as intended with HANA. We evaluate these compatibility arguments for clients and are always surprised by the new explanations that SAP comes up with to drive customers to HANA. The accuracy of these private statements to customers should never be taken on face value, but need to be evaluated on a case by case basis.

Search Our Other HANA Content

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.

HANA & S/4HANA Research Contact

  • Interested in Research on S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is not possible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

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.

Chapters

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