How Accurate Was IFS on the Potential of In Memory Computing?

Executive Summary

  • Dan Matthews, the CTO of IFS wrote an article on in memory.
  • We review how accurate he was in his article.

Introduction

Dan Matthews’s paper 3 Things Business Decision Makers Need to Know About In Memory Enterprise Software and was published in May, 2017.

The Quotations

Gartner Defines What is In Memory?

Gartner says that in order for a technology to be classified as in-memory, it requires “the database structure to be in-memory, specifically the main memory of the server.” This, according to Gartner, is in contrast with databases that would commonly rely on a disc-based Database Management System (DBMS) that feeds data in and out of a database stored on a disc or server, and may perhaps keep some data in cache to speed up performance. Gartner’s definition of an in-memory application requires an In-Memory DBMS, or IMDBMS.

We have previously critiqued Gartner for not understanding databases and for being paid by SAP promote HANA which we covered in the article How Gartner Got HANA So Wrong. We estimate Gartner is paid over $120 million per year to promote SAP products and move them up in the rankings. Gartner makes the rather absurd proposal that having a single employee who works as an “ombudsman” was we covered in the article How to Best Understand Gartner’s Ombudsman., makes that $120 million per year irrelevant.

Therefore, it is difficult for us to take what they seriously on these topics. The statement…

“the database structure to be in-memory of the server”

Is a meaningless statement. It sounds like it means something but it doesn’t. What is “the database structure”? Is that a table? What does Gartner mean here? They don’t know. Again we have yet to see a single time that Gartner has displayed any knowledge of databases. In our analysis of Gartner’s ODMS MQ which is at Can Anyone Make Sense of the ODMS Magic Quadrant?, should make this quite clear.

The following sentence..

“This, according to Gartner, is in contrast with databases that would commonly rely on a disc-based Database Management System (DBMS) that feeds data in and out of a database stored on a disc or server”

Is also meaningless.

This is because of all databases, even SAP HANA which has stated that it stores all of the database in memory doesn’t. All databases move data from storage into memory as needed in something called memory optimization.

However, we don’t mark down Dan or IFS for quoting Gartner. Even though Gartner adds no value and is a considerable value subtract in discussions around databases, they are still widely respected. It should also be mentioned that no vendor can call out Gartner for either being corrupt or not knowing their subject matter. This is because Gartner can retaliate against any vendor that does not show them the “proper deference” as Gartner has a near monopoly or vendor ratings.

Now let us see what Dan does with this quote.

“Under this definition, the in-memory column store capabilities of the Oracle 12C Enterprise Edition, which IFS leverages to deliver its in-memory offering, qualifies as a true in-memory solution, but one that recognizes real-life challenges faced in enterprise computing. It contains both a traditional DBMS and an IMDBMS working in parallel and always in sync. It enables an application user to keep all or part of the database in memory, so that columns and tables that are frequently queried by business analytics tools or referenced in ad hoc queries can be kept in memory while other data is stored in a physical disc.”

Well, if can now kick Gartner to the curb, Oracle does have an in-memory capability and it was added to the Oracle database back in 2013 as the graphic below illustrates.

Therefore yes, Oracle provides “in memory” functionality with a column-oriented store.

100% In Memory?

“A real-life ERP in-memory application should always be, in a manner of speaking, at least some type of hybrid solution between RAM-based and disc-based data storage. In theory, a pure in-memory computing system will require no disc space or file I/O. This is impractical in the world of ERP since a modern enterprise application may store not only structured data, but unstructured and unwieldy information like photos, technical drawings, video and other materials that are not used for analytical purposes and would consume a great deal of memory. This is one drawback of ERP applications, which by default run the entirety of a transactional database in memory. Meanwhile, the in-memory feature set of IFS Applications, for instance, will give end-users a choice of which data to house on a physical drive and which to store in-memory. Or of course, if they really want to, run the entire database and application in-memory.”

This is all quite true. And here Dan is directly contradicting Hasso Plattner of SAP. We have been contradicting Hasso Plattner on this topic since 2016. Hasso Plattner is wrong, only a small portion of the overall database needs to be loaded into memory, and that data changes depending upon what is being processed at the time.

The Need for ERP Speed?

“The chief benefit of in-memory computing in ERP is obvious—enhanced processing speed, particularly when dealing with larger data sets and queries of non-indexed tables. Data stored in memory can be accessed hundreds of times faster than would be the case on a hard disc or even flash drives. But also the columnar orientation of the in-memory storage means that it becomes very fast to find a smaller subset of data inside a very large set. In-memory is optimal for what is called “narrow queries”, where a smaller number of columns for a subset of rows is extracted from a very large data set.

This speed is particularly useful when companies are running ad hoc queries of the database underlying their ERP software product, for instance to identify customer orders that conform to specific criteria or determine which customer projects consume a common part.”

This is true.

But it leaves out the fact that if you spend time on ERP system accounts, the performance of the ERP system is really rarely the issue. We live in a time of great hardware capacity. And the processing requirements of ERP systems have not increased very much over the past few decades, but hardware capabilities very much has increased.

Secondly, “in memory”/column oriented solutions speed analytical workloads primarily, and as we covered in the article HANA as a Mismatch for S/4HANA and ERP, ERP systems are primarily transaction processing applications with a few CPU intensive operations like MRP and DRP. Therefore, they do not benefit much from the analytical processing capabilities of in-memory databases. The vast majority of companies still perform reporting on a specialized data warehouse, which does make sense to use some “in memory” capabilities, although it does not need to reside within a “Swiss Army Knife” database like Oracle 12c. For example, one could use Redis combined with a row-oriented database.

Dan addresses this issue of data warehousing in the following quote.

Real-Time Visibility?

“In order to eliminate the database as a constraint, most business intelligence tools or analytics instead query a copy of the transactional data that is kept separately in a data warehouse. This data is updated periodically, so it does not truly offer real-time visibility. In-memory technology can provide that real-time view of the business, at least when the data is coming from a single source system or application. In-memory technology in itself does not replace the need for transformation and mapping that typically has to happen when performing analysis across data from multiple source systems.”

This is true, but real-time visibility is not particularly important. A report that is based upon data that is a day old or 12 hours old or 6 hours old, normally will not tell you much more than a real-time pull. The biggest problem in companies is not data currency, its subject matter expertise. I work in forecasting improvement projects. The problem that faces these projects is knowledge of things like forecast error measurement, data storage of different inputs, testing knowledge, how to document, how to follow a scientific approach. The lack of real-time visibility is just not a high priority issue. Secondly, any specific item can be found in real time from the ERP system. And ERP systems also have more rudimentary reports that are also real time.

The Incentives to Add In-Memory to ERP

“The incentives that may drive a company running ERP to adopt in-memory computing are straightforward.

For the enterprise software vendor, though, in-memory computing may be a way to address underlying issues in their application architecture. If an enterprise software product was originally designed in too complex a fashion, the application may have to look in more than a dozen locations in a relational database to satisfy a single query. They may be able to simplify this convoluted model and speed up queries by moving from disc-based to in-memory data storage.”

This is an interesting observation. Our interpretation (although we can’t prove that Dan means this) is that in memory can be used to counteract poor application design. Analyzing this article is timely for us because we just finished the article The Four Hidden Issues with SAP’s BW-EML Benchmark. And in this article, we pointed out that the BW-EML benchmark entirely leaves out the quality of the SAP BW applications, which is atrocious and which we have previously easily beaten with different software running on a laptop. That is an intelligent application design can be effective with far fewer resources.

Increasing Sales with In-Memory?

“Promoting an enterprise application that relies entirely on an in-memory database may also be a way for an ERP vendor to derive more revenue from the software sale by pushing customers to purchase a new database rather than the Oracle, Microsoft or IBM databases they would typically otherwise use. For the customer, however, this could mean re-learning and re-training of IT staff to manage a new, and proprietary, in-memory database in addition to the additional license investment for this technology.”

Yeeeeeees! Vendors try to maximize revenues. And certainly, SAP does this. In fact, this is quote is directly aimed at SAP. SAP has been selling HANA on false claims since HANA was first introduced a Brightwork Research & Analysis has been the most vocal entity calling out SAP on this, while virtually the entirety of the IT media, Gartner, Forrester and SAP’s massive consulting ecosystem has simply parroted SAP’s false claims as we covered in What is the Difference Between an SAP Consulting Company and a Parrot on HANA?

And Dan is also correct that the costs of transitioning to HANA are very large. Although we also would add on that HANA is far less stable than more mature databases like Oracle or DB2. Brightwork receives no income from any vendor, so have no reason to take any vendor’s side, and are reporting what our research has concluded.

Valid Uses for In-Memory: Big Data?

“Analyzing enormous quantities of data while it is in movement requires tremendous computing resources and real-time access to data. Information in a traditional data warehouse will be old and therefore less useful, but continuous queries on the transactional database could lead to performance issues.”

True. Although we would be remiss if we did not mention that companies are often challenged in performing analysis on univariate data. And many benefits of Big Data are conjecture. They presume that looking at many data factors will lead to great insights. The early Big Data bubble was mostly about throwing large amounts of unstructured data into data lakes and saying “we will look at it later.” Data scientists are having great difficulty showing the forecasted benefits of this combination of Big Data and data science. We have run many of the ML algorithms ourselves and are often unimpressed with the outcomes.

Therefore we see a need for more understanding applied to data analysis rather than a focus on in memory.

Valid Uses for In-Memory: In Memory Queries?

“If there is data in an application that is subject to frequent queries for decision support or ad-hoc reporting, it may make sense to move those tables in-memory. Otherwise, these queries could take a while to complete—long enough to affect the user experience. The load on the transactional database could also affect the experience of other users. If you want to summarize a thousand rows out of a million or a billion, or to retrieve a handful of columns in a table for one thousand of a percent of the total data volume, this is one area where a targeted approach to in-memory computing shines.”

Sure. Nothing wrong with that.

In Memory and Transaction Processing?

“Running an entire transactional database in-memory will probably never be optimal, but it is possible. Databases may run faster in-memory by the time there are hundreds of millions of rows in a table. For a very large database with tens or hundreds of thousands of transactions per second, in-memory across the board may be the best way to ensure performance without event loss.

High-volume transactional environments on this scale are rare, however. In most cases, it will still make sense to move only carefully-chosen subsets of a transactional database in-memory. If these critical subsets of the database, cumulatively, are numerous or extensive enough to constitute the majority of the database, it may be easier and make more sense to load the entire database in-memory. But again, these situations will be vanishingly rare.”

Yes exactly. Basically, this is simply back to memory optimization. Perhaps more memory is used — more memory will generally always be used as hardware specifications continually increase.

What Data Gets Moved into Memory?

“A hybrid approach to in-memory, with some data stored in a spinning disc or flash memory environment, makes even more sense when we remember that in a fully functional enterprise application, we are not just talking about tabular data but, often, attached files. The benefit of moving imagery—like the photos an electric utility may take of meters—into memory would be minimal whereas the cost could be high. These data are not queried, do not drive visualizations or business intelligence, and would consume substantial memory resources.”

This is actually an excellent point that I have never heard brought up before. But many data types really make no sense to move into memory. Good for Dan to point this out, and the specific reason why it makes no sense to do so.

How About a Reasonable Approach to What is Loaded into Memory?

“IFS Applications customers can choose to keep some, all or none of their database in memory. Although our technology supports running the entirety of IFS Applications in memory, we believe that a more focused in-memory approach may be desirable. To help our customers choose the right things to put in memory, we provide an In-Memory Advisor as well as pre-configured In-Memory Acceleration packages for common scenarios in manufacturing, asset and service management.

In essence, at IFS, we have worked hard to package this technology in a way that is accessible enough for middle-market companies, robust enough for the largest global organization, and agile enough to adapt to changing data usage patterns over time.”

This is in great opposition to SAP’s approach — which is to hype customers upon in-memory to get them to buy the exorbitantly priced HANA database, the pricing of which we covered in the article How to Understand S/4HANA and HANA Pricing.

Conclusion

This article receives a 10 out of 10 for accuracy.

The enterprise software market is so filled with promotional information, it is extremely rare for any article to receive a high score from us, much less a perfect score. There is nothing communicated which is inaccurate, and the article is brave for going against the conventional wisdom on in memory. It is easy to simply write an article telling customers and prospects that whatever new thing is necessary, but this article has a genuine interest in educating the reader.

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.

References

https://www.ifsworld.com/corp/sitecore/media-library/assets/2017/05/02/in-memory-enterprise-software/

TCO Book

 

TCO3

Enterprise Software TCO: Calculating and Using Total Cost of Ownership for Decision Making

Getting to the Detail of TCO

One aspect of making a software purchasing decision is to compare the Total Cost of Ownership, or TCO, of the applications under consideration: what will the software cost you over its lifespan? But most companies don’t understand what dollar amounts to include in the TCO analysis or where to source these figures, or, if using TCO studies produced by consulting and IT analyst firms, how the TCO amounts were calculated and how to compare TCO across applications.

The Mechanics of TCO

Not only will this book help you appreciate the mechanics of TCO, but you will also gain insight as to the importance of TCO and understand how to strip away the biases and outside influences to make a real TCO comparison between applications.
By reading this book you will:
  • Understand why you need to look at TCO and not just ROI when making your purchasing decision.
  • Discover how an application, which at first glance may seem inexpensive when compared to its competition, could end up being more costly in the long run.
  • Gain an in-depth understanding of the cost, categories to include in an accurate and complete TCO analysis.
  • Learn why ERP systems are not a significant investment, based on their TCO.
  • Find out how to recognize and avoid superficial, incomplete or incorrect TCO analyses that could negatively impact your software purchase decision.
  • Appreciate the importance and cost-effectiveness of a TCO audit.
  • Learn how SCM Focus can provide you with unbiased and well-researched TCO analyses to assist you in your software selection.
Chapters
  • Chapter 1:  Introduction
  • Chapter 2:  The Basics of TCO
  • Chapter 3:  The State of Enterprise TCO
  • Chapter 4:  ERP: The Multi-Billion Dollar TCO Analysis Failure
  • Chapter 5:  The TCO Method Used by Software Decisions
  • Chapter 6:  Using TCO for Better Decision Making

How to Understand Why In Memory Computing is a Myth

Executive Summary

  • AWS covers HANA’s in memory nature. Placing a database 100% placed into memory is simply not a good thing.
  • We cover the long history of database memory optimization.

Introduction to In Memory Computing

SAP has been one of the major proponents of something called “in memory computing.” Hasso Plattner has written four books on the topic. You will learn how in memory for databases works.

Hasso Plattner has been pushing the importance of in-memory computing for a number of years. Hasso Plattner’s books aren’t books in the traditional sense. They are sales material for SAP. The books we have read by Hasso Plattner uniformly contain exaggerations as to the benefits one can expect from “in memory computing.”

If you read any of Hasso’s books or read his interviews, he is continually jumping from one topic to the next. People that are programmers are aware of a series of sequential and unending goto statements. But after two days of running an infinite loop, eventually, people will figure out “hey, these goto statements are not doing anything.” Programmatic goto statements run to quickly to be useful in tricking people, but it appears that evidence-free assertions can last a very long time.

There have been some inaccuracies concerning the specific topic of memory management with HANA.

In an article titled SAP’s HANA Deployment Leapfrog’s Oracle, IBM and Microsoft published in Readwrite, the following quote reiterates this popularity.

In-Memory Databases

Many companies today offer in-memory databases for a variety of tasks. The databases are much faster than traditional technology because all data is stored in system memory where it can be accessed quickly. Standard relational databases write and read to disks, which is a much slower process.

This may be rock ReadWrite’s world, but other databases use memory as well. They load tables into memory that are needed by the application. There is a debate as to whether one should load all tables into memory, which is how SAP does it. However, the benefits of doing this are not demonstrated in any benchmark, which is covered in the article What is the Actual Performance of SAP HANA? SAP has made so many statements about the benefits of HANA, but in their entirety, they are nothing more than unverifiable anecdotes provided to them about mostly anonymous customers.

In the absence of evidence, SAP’s proposal that they have the best way of dealing with memory and databases should be considered conjecture. But ReadWrite seems to treat it as if is a natural law, as established as gravity.

What is Non In Memory Computing?

So all computing occurs in memory there is no form of computing that is performed without memory because the results would be unacceptable. Computing has been using more and more memory as anyone who purchases a computer can see for themselves. While at one time a personal computer might sell with 4 GB of memory (or RAM), 16 GB is now quite common on new computers.

The Problem with the Term In Memory Computing

SAP took a shortcut when they used the phrase “in memory” computing. The computer I am typing on has loaded the program into memory. So the term “in-memory computing” is a meaningless term.

Instead, what makes HANA different is it requires more of the database to be loaded into memory. And HANA is the only database I cover that works that way. With this in mind, the term should have been

“more database in memory computing.”

**There is a debate as to how may tables are loaded into memory. Not the large tables and not the column-oriented tables. This is the opposite of what SAP has said about HANA. The reason for this debate is SAP has provided contradictory information on this topic. 

That is accurate. SAP’s term may roll off the tongue better, but it has the unfortunate consequence of being inaccurate.

And it can’t be argued that it is correct.

Here is a quote from AWS’s guide on SAP HANA, which is going to tend to be more accurate than anything SAP says about HANA.

“Storage Configuration for SAP HANA: SAP HANA stores and processes all or most of its data in memory, and provides protection against data loss by saving the data in persistent storage locations. To achieve optimal performance, the storage solution used for SAP HANA data and log volumes should meet SAP’s storage KPI.”

However, interestingly, this following statement by AWS on HANA’s sizing is incorrect.

“Before you begin deployment, please consult the SAP documentation listed in this section to determine memory sizing for your needs. This evaluation will help you choose Amazon EC2 instances during deployment. (Note that the links in this section require SAP support portal credentials.)”

Yet it is likely, not feasible for AWS to observe that SAP’s sizing documentation will cause the customer to undersize the database so that the customer will purchase HANA licenses on false pretenses and then have to go back to purchase more HANA licenses after the decision to go with HANA has already been made.

Bullet Based Guns?

Calling HANA “in-memory computing” is the same as saying “bullet based shooting,” when discussing firearms.

Let us ask the question: How would one shoot a firearm without using a bullet?

If someone were to say their gun was better than your gun (which in essence SAP does regarding its in-memory computing) and the reason they give is that they used “with bullet shooting technology,” you would be justified in asking what they are smoking. A gun is a bullet based technology.

How to Use a Term to Create Confusion Automatically

This has also lead to a great deal of confusion about how memory is used by computers among those that don’t spend their days focusing on these types of issues. And this is not exclusive to SAP. Oracle now uses the term in-memory computing as do many IT entities. Oracle references the term also as can be seen in the following screenshot taken from their website.

Is 100% of the Database Placed into Memory a Good Thing?

However, the question is whether it is a good or necessary thing. And it is difficult to see how it is.

It means that with S/4HANA even though only a small fraction of the tables are part of a query or transaction, the entire database of tables is in memory at all times.

Now, let us consider the implications of what this means for a moment. Just think for a moment how many tables SAP’s applications have, and how many are in use at any one time.

Why do tables not involved in the present activity, even tables that are very rarely accessed need to be in memory at all times?

Oracle’s Explanation on This

In August 2019 Oracle published the Oracle for SAP Database Update document. In this document, Oracle made the following statement about HANA versus Oracle.

Oracle Database 12c comes with a Database In-Memory option, however it is not an in-memory database. Support-ers of the in-memory database approach believe that a database should not be stored on disk, but (completely) in memory, and that all data should be stored in columnar format. It is easy to see that for several reasons (among them data persistency and data manipulation via OLTP applications) a pure in-memory database in this sense is not possible. Therefore, components and features not compatible with the original concept have silently been added to in-memory databases such as HANA.

Here Oracle is calling out SAP for lying. Furthermore, we agree with this. SAP’s proposal about placing all data into memory was always based upon ignorance and ignorance on the part of primarily Hasso Plattner.

If SAP had followed Oracle’s design approach, companies would not have to perform extensive code remediation — as we covered in the article SAP’s Advice on S/4HANA Code Remediation.

The Long History of Database Memory Optimization

People should be aware that IBM and Oracle and Microsoft all have specialists that focus on something called memory optimization.

Microsoft has documents on this topic at this link.

Outsystems, which is a PaaS development environment that connects exclusively to SQL Server has its own page on memory optimization to the database which you can see at this link.

The specialists that work in this area figure out how to program the database to have the right table in memory to meet the demands of the system, and there has been quite a lot of work in this area for quite a long time. Outside of SAP, there is little dispute that this is the logical way to design the relationship between the database and the hardware’s memory.

Conclusion

In summary, if a person says “in-memory computing” the response should be “can we be more specific.” Clear thinking requires the use of accurate terms as a logical beginning point.

SAP’s assertion the entire database must be loaded into memory is unproven. A statement cannot be accepted if it both has no meaning and if what it actually means (as in the entire database in memory) is unproven.

Financial Disclosure

Financial Bias Disclosure

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

Search Our Other HANA Performance Content

References

https://www.oracle.com/a/ocom/docs/ora4sap-dbupdate-5093030.pdf

I cover how to interpret risk for IT projects in the following book.

*https://readwrite.com/2013/01/10/saps-hana-deployment-leapfrogs-oracle-ibm-and-microsoft/

https://www.ibm.com/blogs/research/2017/10/ibm-scientists-demonstrate-memory-computing-1-million-devices-applications-ai/

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-in-memory

https://s3.amazonaws.com/quickstart-reference/sap/hana/latest/doc/SAP+HANA+Quick+Start.pdf

 

Did Hasso Plattner and His PhD Students Invent HANA?

Executive Summary

  • Hasso Plattner and SAP have put forth a false backstory for how HANA was developed.
  • We cover whether removing aggregates from HANA is the breakthrough it is proposed to be, where TREX and P*Time came from, the importance of “zero response time” from a database and the University of Korea connection.

Introduction

The story of HANA’s development looks more suspicious the closer one looks at it. Luckily for SAP, few people do. You will learn the most probable story for HANA’s origin, and how that story was changed by SAP to glorify Hasso Plattner and to help SAP make false innovation claims.

SAP’s Official Story on the Origin of HANA

Hasso Plattner has been widely credited with inventing HANA. The following quotation from Quora covers the common understanding of this.

“I think I am late to answer this, but I completely agree with Anuj. Vishal was the marketing guy or the idea guy but Hasso designed HANA. Both of them are geniuses and at SAP, Vishal will be always missed.”Quora

And here is the explanation of its genesis from Wikipedia.

“The first major demonstration of the platform was in 2008: teams from SAP SE, the Hasso Plattner Institute and Stanford University demonstrated an application architecture for real-time analytics and aggregation. Former SAP SE executive, Vishal Sikka, mentioned this architecture as “Hasso’s New Architecture”.”

In this article, we will analyze how HANA was invented and who invented it.

The Explanation Who Invented HANA

Hasso wrote four books on HANA. In one of the books The In-Memory Revolution: How SAP HANA Enables Business of the Future. In this books, Hasso Plattner explains the genesis of HANA.

“Its fall 2006: I, Hasso Plattner, am a professor for computer science at the HPI in Potsdam Germany. My chair has the focus on enterprise system architecture, and I have to find a new research area for my PhD candidates. Yes, they have to find the topic for their dissertation themselves, but I wanted to guide them towards something I was really familiar with, a concept for a new Enterprise Resource Planning system. All my professional life I have worked on such systems, and I ask myself, what would they look like if we could start from scratch?”

On a side note, it is interesting that Ph.D. candidates are being directed to work on something beneficial for SAP. So this is a strange university as it seems to be a research outfit for SAP rather than a university. That is how much will the Ph.D. candidates be paid to work on this?

SAP Exploiting Cheap Ph.D. Student Labor?

That is how much will the Ph.D. candidates be paid to work on this?

Let’s see the next quote from Hasso on HANA.

“Ever since we have been building such systems, first at IBM, and now at SAP, they were based on the idea what we know exactly what the users want to know. In order to answer their questions in a reasonable time frame, we maintained aggregated data in real time – meaning that whenever we recorded a business transaction we updated all impacted totals. Therefore, the system was ready to give answers to any foreseeable question, thus labeled a real time system. The new idea I come up with is to drop those totals completely, and to just compress the transaction data per day while keeping all additional data intact. It has not much , one piece of paper, but it is a start.

With this I went to my team of PhD candidates and educated them about data structures and data volumes in typical ERP systems. After a lengthy session on the whiteboard, one student asked me what the compression rate might be from the transaction data to the compression data. I did a calculation for a fictitious financial system, and after a while, came up with the answer.

The student wasn’t the least bit impressed, and said, “From an academic point of view, this compression rate is not very impressive.” My new idea, all that I had, was shattered. I took the eraser, wiped out the aggregates in the drawing on the whiteboard and replied, “Okay, no aggregates anymore.”

Why is the objective here to move to such compressed data? Storage is inexpensive.

Hasso Plattner’s Obsession with Compression

I have read many of Hasso’s writing on this topic of compression. What I can’t determine is if he has a serious mental block on this topic and is fixated on data compression, or if he believes data compression is a big deal. If I had to bet, I would bet that he knows it is not something worth focusing on, but that he does so because it so happens that column-oriented databases like HANA compress better and that he can trick senior executives into thinking it is an important advantage. Throughout HANA’s existence, SAP has been careful to bring the HANA message to the people highest in companies that know the least about databases. Hasso cannot debate and win against people that know databases.

Furthermore, Hasso has greatly overstated the compression that HANA is capable of (and which was subsequently repeated through SAP’s passive surrogate network) as is covered in the article Why John Appleby was So Wrong About his HANA Predictions.

This overall conversation is strange, and it implies that Hasso is making major changes to the design based on the input of a single Ph.D. candidate. And when told about his response Hasso says that “my new idea — was shattered” seems a bit melodramatic.

Is Removing Aggregates a Breakthrough?

“This was the breakthrough I was looking for. No one had ever built a financial system without materialized aggregates, whether updated in real time or through batch updates.”

Is “breakthrough” the correct description of was had occurred? Aggregates are precomputed tables, which allow fast retrieval of information. They take up space, but they are quite useful. Without them, the database must calculate everything that it uses on the fly every time the request is made.

Also, what is the benefit of dispensing with aggregates? The database will be smaller, but unless you price the database per its size, this is hardly an issue. And as it happens, HANA did end up becoming priced per GB/TB. There is an important reason why no one had built a financial system without aggregates. There is close to no benefit to doing so. Every year storage becomes less expensive.

Is This the Proper Research Question?

“Back on the offensive, I asked, “What if we assume the database always has zero response time, what would an ERP system look like? This was a proper research question, and the academic work could begin.”

First, why is this the proper research question? Who out in SAP’s client base was asking for a zero response time database for ERP? I ask because I know that SAP customers have been asking for a lot of things, better customer support, better maturity before releasing products, lower costs, etc..Why weren’t those things the proper research question. Second, who cares? ERP systems don’t require zero response time. ERP systems record transactions and they do it quite quickly already. ERP systems can run into issues when it comes to processing. For instance, performing a procedure like MRP.

But MRP can be sped by adding memory and CPU capacity to the machine, or by doing things like removing the invalid product location combinations run through the system. Database performance is a bottleneck for analytics, but not ERP systems. This is not to say that it can’t be. Furthermore, even if it were true, there is no evidence that HANA is faster than alternatives, and this is particularly true for HANA with ERP, as is covered in the article What is the Actual Performance of SAP HANA.  On the contrary, HANA is not only slower than the alternatives, but it is less stable and the highest maintenance database of the other options.

The Importance of a Zero Response Time Database?

“But how about some experimental work? Shouldn’t we check for a database that could come close to this ideal? Was this, in the end, possible at all? This is the wonderful part of doing research at a university. 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.”

Perhaps, but in the industry, a zero response database would have been less accepted because the benefits versus the costs aren’t there, particularly for ERP systems. Ph.D. students will be more willing to work on things that tend to be less practical. In some cases, this can be a good thing. But in this case, Hasso lead his students on a wild goose chase because databases are already quite sufficiently fast to support what companies want to do.

“We asked SAP whether we could have access to the technologies behind their databases; TREX, an in memory database with columnar storage, P*Time, an in memory database with row storage, and MaxDB, SAP’s relational database. My PhD candidates started playing with these systems, and it became clear in a very short time that building a new ERP system was, by far, not as interesting as building a new database. In the end, they were all computer scientists — accounting, sales ,purchasing, or human resource management are more than the scope of a business school student.”

Is This a Believable Story?

So HANA exists because Hasso’s Ph.D. students found it more interesting to create a new database? It is too bad I was not invited to this little soiree because I could have communicated to Hasso and Hasso’s Ph.D.s that this is a poor use of time. SAP has many problems with their customers. And database speed is not even in the top ten list of problems.

“The compromise was that we build a database prototype from scratch, and all the application scenarios with which we were going to verify the concept of a super fast database had to match those of real enterprise systems.”

Hasso set upon his Ph.D. candidates to build a new ERP system? Is that wise? ERP systems are massive combinations of functionality that should probably be undertaken by SAP development. This is not a good subject for a dissertation.

If Ph.D. candidates are developing a new ERP system for Hasso Plattner, this seems quite exploitive (were they getting stock options), and some Ph.D. candidates aren’t the right people to do it.

Where Did TREX and P*Time Come From?

Hasso states that they “asked SAP” if they could have access to TREX and P*TIME. First, that is unlikely that anyone at SAP would deny Hasso this. It is well-known that McDermott is a puppet and Hasso still runs SAP. So imagine Larry Ellison asking to use an Oracle database for a research project and that request being rejected by Mark Hurd. Would that conceivably happen?

But secondly, there is some information missing in the story presented by Hasso regarding the origin of P*TIME.

Now let us look at the timeline of HANA and its component technologies.

Why does Hasso describe P*TIME as SAP products without bringing up the point that it was recently acquired by SAP in 2005?

Also, this timing looks peculiar. Hasso tasks his Ph.D. students with developing HANA less than a year after purchasing a critical technology to HANA. Hasso was not aware he was going to use P*TIME for something like this at the time he acquired it in 2005? 

Let us look into where P*TIME was acquired.

Sang Kyun Cha, the University of Korea Professor

P*TIME was purchased from the professor Sang Kyun Cha, of the University of Korea. Let us review Sang Kyun Cha’s bio on his webpage.

“SAP HANA – My third generation in-memory database engine (SAP HANA – Wikipedia, Article (Korean))

P*TIME – Founded Transact In Memory, Inc. in Silicon Valley in 2002 (also its wholly-owned subsidiary TIM System in Korea in 2000) to fund the development of the next-generation in-memory DBMS and has led it to the successful acquisition by SAP (the #1 global business software company) in 2005. SAP transformed TIM System to SAP Labs Korea and made an official announcement in March 2008.

Sang Kyun Cha is a professor, an innovator, and an entrepreneur. He worked on three generations of commercialized in-memory database technology since he joined Seoul National University in 1992. In 2000, he founded Transact In Memory, Inc. with his vision of developing an enterprise in-memory database system called P*TIME (Parallel* Transact-In-Memory Engine). The company was quietly acquired by SAP in late 2005.

By SAP’s request, Prof. Cha led SAP’s Korean HANA development.

By early 2006, Prof. Cha’s team completed P*TIME development with an innovative OLTP scalability architecture. With SAP’s in-house column store TREX, P*TIME served as a corner stone of developing SAP HANA, the first distributed enterprise in-memory database system enabling real-time analytics over transactionally integrated row and column stores. Today, SAP and many other companies run ERP, CRM, business warehouse on HANA. By SAP’s request, Prof. Cha led SAP’s Korean HANA development.”

Where is Hasso’s recounting of what Prof Cha was doing at that time? Hasso is proposing that HANA was wholly original, but he would have approved and perhaps driven the purchase of P*TIME.

Conclusion

The story of HANA’s origins as presented by Hasso appears fishy. It has the look of a story that minimizes the inputs that were pre-existing before Hasso even entered the scene with column-oriented databases, and through a very small “addition” allows Hasso to take credit for the work of others.

Hasso seems to imply that TREX and P*TIME were just sort of “sitting around” until he and his Ph.D. candidates used them to create HANA. The story presented by Hasso in his book The In-Memory Revolution seems to minimize the technologies that they relied upon and to propose the idea in a way came out of nowhere and was a lightning bolt of creativity developed by Hasso Plattner. And this is the way in which people who are worth a lot of money (and Hasso is worth north of $20 billion) can manufacture history to position themselves as the inventors of things. A perfect example of this is Thomas Edison. Thomas Edison was a terrible scientist according to Nikola Tesla. And who initially credited Thomas Edison with this invention? It was Thomas Edison himself!

How Hasso Plattner Has Channeled Thomas Edison

A person seeking to do this follows an important pattern. They do not attribute work done before their own. Thomas Edison was famous for doing this exact thing. Column oriented databases have been in existence as long as relational databases. Hasso asserts that because he came up with the idea of not using aggregates — which is simply a switch of a pre-calculated table read for recalculation, that he created something entirely new. However, upon analysis, I can’t see anything of substance added by Hasso. And the one idea Hasso seems to have come up with — dropping aggregates is not a good idea. If you approach an area with a well-developed body of work and with functional commercial products (many column oriented databases were being sold at this time) and you add one minor idea, and that is not even a good idea, you did not invent anything. It’s not innovation, its claim jumping.

What is more apparent that Hasso pushed the idea of column oriented databases — but that is the promotion. Like Thomas Edison, Hasso is a great promoter. But a major contributor to databases? Hasso and his Ph.D.’s did not accomplish this.

The Cover Story

The story presented by Hasso in his book The In-Memory Revolution minimizes the technologies that they relied upon, and to propose the idea in a way came out of nowhere. After HANA was introduced, more inaccurate stories were told by Hasso about the supposed benefits of HANA, and those benefits — particularly vis a vis the competition have been debunked by Brightwork. (see the articles on this site for which areas of SAP’s claims about HANA’s superiority have been debunked)

It seems that not only were the proposed benefits of HANA exaggerated and inaccurate but now the origin of HANA was engineered to make it appear as if HANA was primarily Hasso’s idea. And this has filtered through to become the accepted view. This is commonly proposed by both IT media entities and SAP consulting companies who aggressively bow to anything that SAP asserts. However, how can something that had already been around before HANA was developed be an original idea?

This is a constant problem with SAP where they pose to have innovated things that they never did.

Interesting Questions on HANA’s Development

From this case study, some interesting questions arise.

  • Why did SAP purchase some of the primary components of HANA less than a year before Hasso “invented” HANA?
  • Why was Professor Cha asked to lead the Korean development of HANA?
  • On Professor Cha’s website, he states that his company was “quietly” purchased by SAP. Why was the purchase “quiet?” Was this because SAP planned to take more credit for HANA being internally developed that it was?
  • Why is it that we don’t even hear about Professor Cha in the story told by Hasso about HANA? Was Hasso unfamiliar with Professor Cha’s work, that is unfamiliar with the work of a professor that developed a company that SAP purchased?
  • Did any of the IT media look into this story, or did they simply accept the storyline that HANA and the important component technologies were the inventions of Hasso Plattner?

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.

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 and fact-checking that is outside of the SAP and SAP consulting system, reach out to us with the form below or with the messenger to the bottom right of the page.

Financial Disclosure

Financial Bias Disclosure

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

Search Our Other Hasso Plattner Content

References

https://kdb.snu.ac.kr/chask/

[P*TIME](https://dl.acm.org/citation.cfm?id=1316778)

[The In-Memory Revolution: How SAP HANA Enables Business of the Future:Amazon:Books](https://www.amazon.com/Memory-Revolution-Enables-Business-Future/dp/3319166727)

[Is Vishal Sikka really the father of HANA? – Quora](https://www.quora.com/Is-Vishal-Sikka-really-the-father-of-HANA)

[TREX search engine – Wikipedia](https://en.wikipedia.org/wiki/TREX_search_engine)

https://sites.computer.org/debull/A12mar/hana.pdf