How Accurate was Bloor Research on Oracle in Memory?

Executive Summary

  • Bloor Research produced a study which questioned the benefits of Oracle in memory.
  • Bloor Research proposes that the maintenance overhead increases with Oracle in memory.
  • This perspective is mostly missing from media coverage of in memory.


On October 1, 2013, Bloor published the article Oracle In Memory, but Philip Howard

In this article, we will review this article for accuracy.

Article Quotations

The Oracle Announcement

“Oracle has announced an in-memory option for the 12c version of the Oracle Database. It’s expected to be available sometime in the early part of next year but no official release data has been announced.

Basically, the idea is that data will be stored on disk in a conventional row-format and a second copy of the data will be stored in columnar format in memory. This will mean that you won’t have to define analytic indexes for the data on disk as the columns act as self-indexing constructs. This in turn means less administration and tuning for the data on disk and you should improve analytic performance significantly (because data is in memory) and OLTP performance (because there are fewer indexes).”

Yes, that is quite right.

What is Not to Like?

“So, what’s not to like?

Well, the first thing is that all that memory is going to be relatively expensive. More importantly, you will either need to deploy a lot of memory or the DBA will need to include/exclude specified columns (which will be an option) from the table to be loaded into memory. However, this is a manual step (therefore the DBA must know in advance what queries will come into the database so they can set those columns up in memory or otherwise you default to putting the full table in memory), which means that what you gain on the non-indexing administration you lose on the memory administration. Secondly, the DBA must allocate a set amount of memory for the in-memory tables. Once that memory fills up that’s it: you can’t load any more tables into memory. And that means that you have to statically set the amount of space you need for your in-memory objects – whereas what you would really like is a dynamic way of re-allocating memory as required – which means a further administrative burden.”

All true. So it is more expensive, and it means more maintenance. And while it was SAP that primarily what drove Oracle to make this addition, the question remains how necessary it is.

The Current Data Warehouse Design

Currently, the data warehouse creates most of the analytics, particularly the complex analytics, and can use a database customized for this task. Meanwhile, the application can use a database customized for its task, be it transaction processing (such as for an ERP system) or for intensive processing (such as for a supply chain optimizer). What is the overriding need to combine these two database needs into one database?

Second, how good is the performance of such a database. An AWS blog questions this with the following comment.

“And, if you’ve mixed online transaction processing (OLTP) and analytics-style data access, moving from a one-tool-for-everything Oracle setup to using a separate warehouse for reporting and analytics can improve both your application responsiveness and your analytics capabilities. There are options to create a dedicated Postgres-XL–based warehouse or use Amazon Redshift as a powerful managed warehouse.”

What!! How is that possible? Isn’t Oracle In Memory (combined OLAP and OLTP the best??) This is the problem with copying a vendor like SAP that does not know very much about databases and places so much emphasis on marketing over reality.

The Overhead of the Design

“The other question that you might ask is how this in-memory column store relates to the hybrid columnar compression (HCC) used in Oracle Exadata?

It turns out that the compression for in-memory is different than HCC.

You can still have the tables stored on disk using HCC but when they are loaded into memory you have to decompress the data, then break the table apart and recompress it using the new in-memory compression algorithms for each column. Frankly, and to use an old English term: that sounds barmy.”

It appears that there is confusion here between in-memory column store and HCC. HCC is used by Exadata to compress old data. But it is independent of Oracle In-Memory.

This commingling of Oracle In-Memory functionality versus HCC makes it difficult to interpret what Bloor is attempting to say.

But the question that is not generally asked is how necessary any of this is.

“I have to say that while the top line story sounds good, I am less impressed when you look under the covers. Oracle does not appear to have done the in-depth re-engineering that you would really like to support this sort of feature. No doubt this will come in due course but from what we know now this is in contrast to, for example, IBM’s BLU Acceleration. In this context, IBM seems to have really gone down into the weeds of the technology to make sure not just that it works but that the different elements of BLU Acceleration complement one another and do not take away with one hand what they give with the other.”

This is a very good point brought up by Philip, and it is the first time I can recall anyone bringing up this issue. But there is not enough evidence in this quotation for me to evaluate if this is true.

But there is something gnawing at me that relates to this topic.

How Necessary is a Dual Type (Row and Column Store) Database?

So if we look at what drove Oracle and IBM to add column stores to their relational/row-oriented databases, it was certainly HANA.

SAP proposed that it was critical that a single database can do both OLTP and OLAP.

However, how important is this need?

Companies still tend to use row-oriented databases for most applications, and then move data over to a specialized analytics system, which have different hardware and either column oriented capabilities, or uses star schemas to speed relational database performance for analytics. SAP made this emphasis in the marketplace that OLTP and OLAP should be equally well performed by a single database, but this turns out to be difficult to do. Certainly, SAP has never been able to do it.

Oracle and IBM have more database capabilities than SAP, so naturally, they have gotten closer, but if we step back for a moment, I question SAP’s proposal that this is, in fact, all that necessary. It seems we are driving database vendors to push their databases in this direction without asking the question of how necessary it is in the first place.


There are multiple dimensions to the questions of column stores for row-oriented databases. This is a trend started by SAP and then marketed to the hilt with HANA. But there is little evidence this functionality is particularly necessary.

Philip Henry does a very good job of surfacing some issues related to complexity and maintenance that are entirely original, although some technical observations are hindered by comingling HCC with Oracle In-Memory as well as requiring a fuller description of how Oracle optimizes memory during queries.

This article receives a score of 8 out of 10 on the Brightwork Accuracy Scale.

Brightwork Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible 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.


[Oracle in-memory | Bloor](

Analysis of Bloor’s Article on SAP HANA 2014 Update

Executive Summary

  • Bloor produced a research piece on HANA.
  • We review the accuracy of this research.


On Mar 7, 2014 Bloor published an article titled SAP HANA Update.

In this article, we will evaluate the accuracy of this Bloor article.

Article Quotations

I have, in the past, written somewhat critically about SAP HANA. A part of the problem is that the product is something of a moveable feast with new versions appearing on a pretty regular basis—perhaps not surprising for a technology that is still relatively new—but, nevertheless, this means that it is difficult to keep up with. Also, historically at least, there has been a perception that SAP has been over-hyping SAP HANA.

Yes, HANA has been one of the most overhyped products I have ever analyzed.

HANA to Cure Cancer?

For example, Larry Dignan, reporting for ZDNet, recently wrote that “Vishal Sikka, SAP’s technology lead and member of the company’s executive board, stopped short of saying HANA would cure cancer, but not by much.” While Larry was no doubt writing this with some of his tongue in his cheek it is worth noting that, in SAP’s defence, the company (using SAP HANA) has been working with the Stanford University Medical Center and the National Center for Tumor Diseases in Heidelberg, Germany (NCT), to help the Human Genome Research Institute to put the therapeutic promise of the Human Genome within reach. And the White House recently honoured these three companies for the genomics advances they have achieved (Nov 2013).

Yes, that is true. Both Vishal Sikka and Hasso Plattner stated that SAP would release a health care research product. Vishal Sikka stated that they were writing cancer curing algorithms in HANA.

Upon evaluating SAP’s 309 long product list, the term health or medical still does not appear years later.


All that being said, I have had a recent update from SAP and it is worth reporting a number of salient points. The first thing is that SAP HANA is intended to support both OLTP and analytic processing in the same instance. By SAP’s surveys, around a quarter to a third of HANA customers use it this way, with another quarter using it purely in warehousing environments and the remainder being specialised developments created by partners.

It is not technically feasible to do this. An analytics database has a different design from a transaction processing database. IBM, Oracle and SQL have actually improved on SAP’s design regarding adding a column store to an RDBMS. But it still will not match the performance of a dedicated analytics database. At the heard of this is the debate as to whether analytics should be pushed to a specialized database.

In addition, in data warehousing environments, HANA is not seen by SAP as the sum total of its solution. In particular, it sees SAP HANA integrating into existing environments with Oracle, Teradata, to SAP IQ (formerly Sybase IQ), Hadoop, streaming analytics systems like SAP ESP and other data sources. In the case of SAP IQ, SAP HANA will manage perhaps the last 6 months’ or a year’s worth of data while seasonal or trending information can be stored in IQ.

That is SAP’s dream, but it looks decreasingly like this will ever happen.


Speaking of SAP IQ, HANA primarily stores data in columns (rows are an option) and SAP is now using the same compression techniques as employed in SAP IQ, except that in SAP HANA it is bit-level compression rather than byte-level, so it should be even more efficient. As an aside, bit-level compression has already been added to SAP IQ 16, released in 2013. Also, on the issue of compression, SAP has assured me that when conducting query processing the data is never decompressed except for result sets. Of course, this will also apply to intermediate result sets and that is likely to explain why I have criticised the product in the past for what I have described as spikes in memory usage.

SAP IQ is very rapidly declining in the market and SAP is looking for basically any excuse to use it. The new idea is to use it for archival.

HANA Faster than the Competition?

But the truth is that all database products are going to be subject to the materialisation of intermediate results and there is no reason to suppose that SAP HANA is either any better or any worse when it comes to this than any other vendor. Indeed, intermediate results are dropped as soon as the data is joined, while the results are cached. What will be important is that queries are written in such a way that the materialisation of intermediate results is minimised. Of course, this also applies to business intelligence and analytics that may be used in conjunction with SAP HANA (or any other database).

The first part of this paragraph was true when Philip wrote it in 2014. But now information has come to light that indicates SAP HANA is slower than DB2 or Oracle 12c. This is covered in the article Which is Faster HANA or Oracle 12c. 

While on the subject of memory, the standard maximum memory for SAP HANA is 1TB. However, the company tells me that this is not the technical limit—this is only what is certified as standard—and actually you can run up to 4TB per sever. For example, Intel, in its recent Ivy Bridge launch demonstrated an Intel 4TB E7 v2 Ivy Bridge system using SAP HANA and SAS together to analyse a real-time oil and gas pipeline pump malfunction. The SAS/SAP HANA analysis came back in 5 seconds, 129x faster than the E7 v1 using SAS and a disk-based database.

In addition, you can scale out using multiple servers. Moreover, a feature I particularly like is that SAP HANA has data virtualisation built in, so that you can optimise (and the database optimiser knows about the data virtualisation) queries across distributed SAP HANA servers and also when using SAP HANA in conjunction with SAP IQ. This will also be relevant when you want to combine structured and unstructured elements (SAP HANA has a text pre-processor and also supports machine-generated data) in a single query. Thus for most environments there should be no issues about the availability of sufficient memory.

The problem with listening to SAP is that just about every single statement is an exaggeration. After a large amount of time spent researching HANA, Brightwork’s conclusion is that SAP never had anything with HANA that the other database vendors did not have, and that they were better at doing. SAP was successful in motivating other vendors to bring out flexible column oriented stored for the RDMBSs.

To summarise: I still think that SAP over-hypes SAP HANA and the fact is that it is not the answer to a maiden’s prayer. That said, for the right application/analytic environments it should certainly represent a credible solution.

All true. However, while HANA does have good read performance, the evidence is in that its read performance is worse than the competitors that it seeks to supplant at customers.


Bloor receives a Brightwork score of 9.5 out of 10 on the article. More information has come to light since Philip wrote this, but he has to go down as an early predictor of what we would eventually uncover about HANA.


How to Best Understand Bloor’s Research on S/4HANA

Executive Summary

  • This article covers Bloor’s research into S/4HANA.


On June, 2017 Bloor Research produced the white paper titled Exploding the Myths of SAP HANA.

In this article, we will evaluate the accuracy of this Bloor Research article.

Article Quotations

Like the other things we have discussed, this is not straightforward. You might think that S/4 HANA is simply the replacement for Business Suite: that it is SAP’s new ERP suite, but it is not that simple. This is because some of the applications that were previously in Business Suite are now only available as SaaS (software as a service) solutions running in the cloud. For example, SAP SuccessFactors is a human resources application, while SAP Concur is a SaaS application for managing business travel and expenses. Other such applications include SAP Ariba and SAP Fieldglass. All of these have been acquired because SAP saw a danger that competitive vendors such as Workday or would eat into its customer base. However, as acquisitions these are not native SAP HANA applications, and in fact they run on the SAP HANA Cloud Platform, which, as we have seen, is not necessarily HANA-based at all!

These statements are true…however, they are a unique way of looking at the issue.

Basically, SAP is offering a number of applications that offer superior functionality and usability to the standard functionality in ECC, or now S/4HANA. Previously these were called best of breed applications. Now if these vendors were not owned by SAP, even though there is very little integration benefit to SAP having acquired them (SAP is notoriously slow at developing adapters for acquisitions — literally having it take over 5 years in some cases) SAP would have told customers to absolutely stay away from these products when they were independent. Deloitte, Accenture et al would have said that exact same thing..bemoaning and pointing to the terrible thing that is application integration.

According to SAP, and to the passive repeaters that are SAP’s reliable consulting partner network, all the required functionality is contained within ECC. As well as all best practices as well as is covered in the article How Valid is SAP’s Best Practice Claims?

However, as soon as an application is acquired, literally SAP’s story does an 180 and the customers should absolutely now purchase this “third party application.” What is curious is that the story changes literally the day after the acquisition is made, far before SAP does anything with the product from an integration perspective.

So while it is true that these applications are prescribed by SAP, and true that they replace lagging functionality (mostly, HRM payroll has no real equivalent in SuccessFactors), Bloor’s perspective here is quite interesting, and seemingly a new way of looking at SAP’s acquisitions with respect to the pitch for S/4HANA.

The Story on Fiori and HANA

In this context, it should be noted that SAP Fiori, which is a framework for porting applications across mobile environments, is based on SAP NetWeaver and does not use or require SAP HANA for SAP transactional workloads.

I agree in one respect in that there is absolutely no technical reason for Fiori to be connected to HANA (although SAP tries to convince people that there is). However, SAP has connected Fiori to HANA in order to lure people into using HANA and to using S/4HANA. The evidence? Well first, the presentation layer is not related to the database layer. But second, before customers pushed back on SAP through user groups to stop SAP for charging for Fiori, Fiori used to be developed for AnyDB. But when SAP decided not to charge for Fiori (due to resistance) they stopped making Fiori apps for AnyDB.

Technically there is also no reason that Fiori could not be used with ECC. However, SAP has no interest in providing something that while it may improve the user experience, does not drive companies down the pathway that SAP wants.

Fiori Based on Netweaver?

Now as for Bloor’s contention on Fiori being based on Netweaver. Netweaver is really a marketing term that describes things inside the construct or the box of Netweaver, as covered in the article Did Netweaver Ever Actually Exist? For the purposes of this discussion, the topic is really neither here not there. The central point made by Bloor regarding the lack of dependence between Fiori and HANA is 100% correct.

Improvements in S/4HANA?

The other – usually on-premises – parts of S/4 HANA are direct replacements for current Business Suite functionality (expect for SAP industry-specific solutions, where direct functional mapping into S/4 HANA industry solutions may not be currently available) and, at least at present, these application modules only run on SAP HANA as the underlying database. While we do not intend to dig into the particular features of these modules, we will make the comment that there are valuable new capabilities in these applications and there is an improved user interface.

I would have to see the list that Bloor is referring to. It becomes a lengthy and complicated discussion. Secondly, a lot of functionality is removed, and some of that functionality was relied upon. If some are better, there is enormous complexity in moving to it due to the analysis required and the issue of dropped functionality, etc..

Regarding Fiori, this would be true if Fiori were implemented, but Fiori has a lot of overhead in setting up, and most companies are using a far cut down number of apps, as a number of apps do not work.

However, these new capabilities are generally not core features but ancillary: useful but not essential, at least in most cases. We therefore return to the point made earlier: that you need a compelling business case before you consider the costs and trauma of migrating to S/4 HANA.

This is exactly as I just pointed out. One can debate the potential benefits of changes, and SAP and Deloitte and Accenture et al will be pushing hard on a one-sided view of the benefits. But there is simply no debating that the costs of obtaining these benefits (even if they do exist) are very large.

Now SAP and Deloitte and Accenture et al do not care about the costs. Deloitte and Accenture et al revenues are in part the mirror of these costs.

What Areas of Emphasize Over Others

Moreover, in our view, any such decision will typically be in competition with competing demands such as transitioning to a data-driven enterprise, meeting new compliance requirements such as general data protection regulation (GDPR) or implementing Internet of Things (IoT)-based technologies. We would argue that these are more likely to be priorities than upgrading your ledger systems. 60% of DSAG (German speaking user group) users see adopting to the digital economy as the first priority.

Bravo. Absolutely spot on. SAP is trying to place the emphasis back on ERP, but the fact is that ERP systems never provided the ROI that Gartner or SAP said that they did, which is covered in the book The Real Story Behind ERP: Separating Fact from Fiction.

The data is in, and the right answer is to reduce one’s investment in ERP (which should have been reduced by now given the decades of investment companies have already put into ERP) and move those funds into investments outside of ERP.


It is also worth commenting as an aside, and in the IoT context, that while SAP is certainly active in the IoT space (for example, SAP Leonardo), the company does not appear to be as committed to open source technology as some other vendors active in the IoT space.

Now here I really have to disagree with Bloor. However, I disagree with Bloor in a way that actually strengthens Bloor’s overall case. For those interested in the details, they are covered in the article Why SAP’s Leonardo Seems so Fake.

Multiple Implementations of S/4HANA?

This is in contrast to IBM, for example, which has a long history of supporting both open software open standards (for example, Node.JS, Eclipse, Apache, Linux, Hyperledger, Node-RED, IoT, JAVA, Spark, Spark ML, JanusGraph, Open Data Platform).Despite all these comments, we recognise that for some organisations it may make sense to consider migration to S/4 HANA. However, even here, life is not simple.For example, the first module of S/4 HANA to be released was so-called “Simple Finance”. There were several drawbacks associated with the original release of this. For example, there was (and is) no integration with Business Suite processes. Moreover, there was (and is) no easy migration tool to allow you to move smoothly from Business Suite to Simple Finance. This remains the case for all S/4 HANA applications. Further, the latest version of Simple Finance (16.10) is not compatible with the earliest version of that product –– meaning that you cannot simply upgrade (you have to do a “system conversion”) from the latter to the former but will have to migrate (with, again, all the costs and risks that that implies) to the latest version. Frankly, we consider this to be remarkably short-sighted on the part of SAP. You could hardly design a process more likely to put people off moving away from Business Suite.

This is a devastating indictment of SAP’s strategy. Not only was there never a migration path to S/4HANA from ECC, but there is also no migration path from the earlier versions of Simple Finance (now Finance) to the more recent versions. How many times does SAP expect customers to reimplement its products?

Investing in Best of Breed

Finally, if you are seriously considering the move to S/4 HANA, bear in mind that there are third party competitors to Ariba, Concur, SuccessFactors et al. Indeed, the pressure that SAP has been applying to Business Suite users to migrate to S/4 HANA has backfired at a number of companies, where not only have they not migrated to HANA (with or without S/4) but they have started to use competitive SaaS products like and Workday.

And this is actually the best strategy, which is outlined in the article How SAP is Now Strip Mining its Customers.

SAP’s Financial Innovation?

So, one obvious question is: what do you do if you don’t migrate away from Business Suite? The answer is that SAP has committed to maintaining support until 2025. So, we don’t think there is any rush. Moreover, things change. For example, SAP has relatively recently joined the Hyperledger consortium, which is developing Blockchain as a mechanism for supporting financial ledgers. This is likely to revolutionise the way we process account information in the future, but the applications to support this will be profoundly different from those we use today. So, do you really need Simple Finance today?

Great question/assertion. Are SAP customers really in need of replacing their FI/CO module currently, or are those needs met better with other finance applications that can be connected to FI/CO.

The Digital Boardroom

On a comparable note, SAP will suggest that migrating to SAP S/4 Enterprise Management is a critical component that contributes to digital/front-office IT enabled business innovation. However, our experience suggests that many enterprise clients do not consider one to be a pre-requisite for the other.

Correct. This assertion by SAP is merely marketing fiddle faddle. SAP has been carrying on about the Digital Boardroom, but this is not a real thing.

Costs of Non SAP Databases

A second consideration is that SAP has been increasing the charges that it applies to using third party databases, in an obvious attempt to encourage users to
move to SAP HANA environments. This may need some explanation.

Historically, there were benefits for licensing AnyDB choices from SAP SE. As a result, many companies previously opted to license AnyDB directly from SAP under OEM agreements. However, SAP is driving up the cost of these. Hence there is an increasing differential between the costs of licensing and maintaining these directly from IBM or Oracle as opposed to going through SAP. We would therefore advise looking at this as a possibility.

Well even still, moving to HANA is actually more expensive on a TCO basis. SAP should also be cognizant of the fact that IBM and Oracle have the knowledge to drop the hammer on HANA if they saw fit. The only reason, that they have been so silent up until this point is because they have been playing nice with SAP.

But SAP’s Achilles heel is that most of their statements about HANA are technically inaccurate.

The third major question is whether SAP will relent on its insistence that S/4 Enterprise Management applications can only run on the SAP HANA database.

I think they will as I wrote a while back now in the article Why SAP Will Have to Backtrack on HANA.

Moving S/4 to AnyDB

Some time ago a spokesperson for SAP assured Bloor Research that if third party database vendors could demonstrate equivalent functionality with equal or better performance then SAP would certify those products to run with S/4 applications. Similar statements have recently been repeated in E-3 Magazine, that SAP may support Db2 BLU with S/4 HANA.

SAP should have to enter Liar’s Annonymous for making this statement.

To date, no such certification has been forthcoming, despite pressure from SAP user groups such as the following statement from DSAG: “in terms of specific requirements, we want SAP to maintain a real freedom of choice for customers when it comes to databases, among other things.

Once again, DSAG is the only SAP user group with any independence from SAP.

Optimizing Sales of S/4

Alternatives to SAP’s HANA database must remain possible with no restrictions on functionality or performance.” From our point of view, it is fairly obvious that SAP would achieve significantly more S/4 sales if S/4 was allowed to run on third party database products. Moreover, Bernd Leukert (SAP executive board member) explicitly emphasised, during a press conference at the DSAG yearly congress, that it would be technically possible to convert Db2 with BLU for S/4. Thus, the question is, which is more important: S/4 or HANA?

At the moment, it would appear that the answer is the latter, which begs the question of how long this state of affairs will last. As we head into the next decade it may be a question of who blinks first.


SAP cannot both optimize the sales of S/4 while also stipulating that all S/4 customers accept their database. And actually accepting a new database also means that SAP will nudge their customer to increasingly replace as much of their Oracle and DB2 infrastructure with SAP products.

We do not want to suggest that you should not consider implementing or migrating to S/4 HANA. However, we do suggest that you do this only if you have a compelling business case for doing so. And by business case we mean functionality rather than performance or scalability. Moreover, you should think carefully about whether this is where you want to invest, as opposed to transitioning to a data-driven enterprise (the Internet of Things, Industry 4.0 and so on). In addition, the truth is that if you have issues with anything other than features and capabilities you will probably be better off upgrading your existing AnyDB implementation. And finally, we strongly suggest that you support your user group in putting pressure on SAP to support S/4 running on AnyDB.

The problem is that what is the business case for using S/4HANA? Even if one could somehow develop one, could it


What I love about Philip Howard’s writing is that he presents things and thinks on things in a way that is in stark contrast with how most people interpret an issue. Therefore he makes me think about things in a new way. There are literally several paragraphs in this paper that present things in a way that I had never thought of before. I knew the component parts, but I never thought to present things in that way.

Unlike a lot of material released as research, I consider Philip’s work to really attempt to get to the core truth of the covered topic.

This article is part of The S/4HANA Implementation Study. Please see that study for the overall conclusions.

Brightwork Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible 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.


The Real Story on ERP Book

ERPThe Real Story Behind ERP: Separating Fiction From Reality

How This Book is Structured

This book combines a meta-analysis of all of the academic research on the benefits of ERP, coupled with on project experience.

ERP has had a remarkable impact on most companies that implemented it. Unplanned expenses for customization, failed implementations, integration, and applications to meet the business requirements that ERP could not–have added up to a higher Total Cost of Ownership for ERP were all unexpected, and account control, on the part of ERP vendors — is now a significant issue affecting IT performance.

Break the Bank for ERP?

Many companies that have broken the bank to implement ERP projects have seen their KPIs go down— but the question is why this is the case. Major consulting companies are some of the largest promoters of ERP systems, but given the massive profits they make on ERP implementations — can they be trusted to provide the real story on ERP? Probably not, however, written by the Managing Editor of SCM Focus, Shaun Snapp — an author with many years of experience with ERP system. A supply chain software expert and well known for providing authentic information on the topics he covers, you can trust this book to provide all the detail that no consulting firm will.

By reading this book you will:

  • Examine the high failure rates of ERP implementations.
  • Demystify the convincing arguments ERP vendors use to sell ERP.
  • See how ERP vendors take control of client accounts with ERP.
  • Understand why single-instance ERP is not typically feasible.
  • Calculate the total cost of ownership and return on investment for your ERP implementation.
  • Understand the alternatives to ERP.


  • Chapter 1: Introduction to ERP Software
  • Chapter 2: The History of ERP
  • Chapter 3: Logical Fallacies and the Logics Used to Sell ERP
  • Chapter 4: The Best Practice Logic for ERP
  • Chapter 5: The Integration Benefits Logic for ERP
  • Chapter 6: Analyzing The Logic Used to Sell ERP
  • Chapter 7: The High TCO and Low ROI of ERP
  • Chapter 8: ERP and the Problem with Institutional Decision Making
  • Chapter 9: How ERP Creates Redundant Systems
  • Chapter 10: How ERP Distracts Companies from Implementing Better Functionality
  • Chapter 11: Alternatives to ERP or Adjusting the Current ERP System
  • Chapter 12: Conclusion

How to Best Understand Bloor’s Research on HANA

Executive Summary

  • Bloor Research investigated HANA which calls into question SAP’s claims on HANA.
  • These areas include the claims regarding in memory, HANA 2.0, the HANA platform, AnyDB versus HANA, and the supposed performance from HANA.
  • We analyze the Bloor Research article.

Introduction to Bloor Research’s White Paper on HANA

On June, 2017 Bloor Research produced the white paper titled Exploding the Myths of SAP HANA.

In this article, we will evaluate the accuracy of this Bloor Research article.

Article Quotations

“If you are a long-time SAP application user then SAP  would you like you to migrate to SAP HANA. However, this is not a simple decision: it is an expensive option, and it is disruptive from a technical point of view.”

This is quite true. I cover this topic of HANA’s expense in the article The Secret to Not Talking About the Cost of HANA.

“SAP HANA is a brand as well as a product. As a product, it is a database, but it is also the brand name for SAP’s latest enterprise resource planning (ERP) applications (S/4 HANA Enterprise Management) and the company’s cloud-based applications. This has enabled SAP to make marketing claims about “HANA” which we would argue have been misleading. We, therefore, deplore this deliberate blurring of the lines between what HANA is as a product and what it is as a brand.”

Brightwork has pointed this out multiple times, one example being How to Deflect That You Were Wrong About HANA. Another is the article Was the HANA Cloud Platform Designed for Cloud Washing

In Memory?

“..SAP HANA is often marketed as an “in-memory” database. But in-memory is simply a deployment option, not an architectural description. Moreover, all databases make use of memory and always have done, so using “in-memory” as an epithet is simply marketing fluff. Where SAP HANA is different is that it is designed to run entirely in memory (whereas IBM Db2, for example, is designed to optimise performance regardless of how much memory is available).”

This is an excellent point.

Actually, anyone who wants to can place an entire database in memory. But it is wasteful and therefore it is rarely done. SAP seems to be the only vendor who thinks that this is a good use of resources. Normally tables that are accessed are put into memory. It makes little sense to place the entire database into memory as most of the tables in the database are not used most of the time.

It is strange that this is not brought up and commonly understood as SAP receives enormous differentiation from constantly proposing that they have an in memory solution when other vendors do not.

“optimizing memory usage is much more mature technology (for example, leveraging Db2 caching algorithms and buffer pools) and is likely to be more cost effective.”

SAP’s Brute Force Approach

So SAP’s brute force approach to improving the speed of the database is a poor use of resources as the ability to move tables into and out of memory is already quite sophisticated functionality at other database vendors. This explains why HANA cannot match Oracle 12c’s performance, as covered in the article What is the Actual Performance of HANA. It may not be able to match IBMs or SQL Server either. I simply have not researched the topic.

IBM is conflicted when criticizing HANA because they receive far more money from consulting in SAP than they do from selling DB2. But IBM’s funding and showcasing of Bloor’s research may indicate that IBM has tired of having to not defend its database against SAP’s exaggerated claims for HANA.

“Column stores enable a better compression rate which, in theory at least, reduces storage requirements. However, SAP HANA stores multiple copies of the in-memory data for redundancy purposes, and you also need a further copy for log space. In other words, most of what you gain on the swings you lose on the roundabouts: you would need a compression rate of approaching 90% to gain significant storage savings.”

Hasso’s One-Sided Statements

This is all true. And this is the problem with listening to anything that Hasso Plattner has to say. Hasso is constantly providing only one side of every argument and why I don’t take anything he has to say seriously. Hasso is looking for low information IT decision makers so he can provide them with mostly false simplistic platitudes that are based upon erroneous information. For example, SAP has PowerPoints that show that HANA reduces the database footprint by 98.5%. This is, first ludicrous, but secondly, is not backed up by project experiences with HANA from the field. When you bring this type of comment to hardened database experts, they fall down laughing. This is reminiscent of when Deepak Chopra went to CalTech and brought his magical thinking about how electrons have consciousness.

 Here is what happens when you lie to people on a topic they know about.

That type of stuff may work at a book reading at the shop that sells meditation books, incense, and crystals, but it’s not going to fly where people actually understand quantum physics. So Hasso has to be careful to not take his act to people that actually know the subject matter. But in Hasso’s bubble, where everyone at SAP kowtows to him and he is the $20 billion dollar man, no one has what it takes to tell him he is wrong.

Hasso’s Similarities with Deepak Chopra

Like Deepak, Hasso is a world class BS artist. And he has tricked many people over decades.

The same problem applies to Hasso’s assertions regarding the “simplification” of the database as is covered in the article is Does HANA Actually Have a More Simple Data Model?

HANA’s Costs?

“While this is only anecdotal evidence, we consistently hear that SAP HANA is the most expensive option you can invest in, both in outright terms and on a price/ performance basis.”

Bloor’s anecdotal evidence is supported by the TCO component costs of HANA. After a long time of not being discounted HANA began to become discounted. But the overall TCO of HANA is still exorbitant. Literally, every cost factor you look for that makes up TCO is higher with HANA. Yet SAP paid Forrester to produce an indefensible paper on how HANA would reduce TCO, as is discussed in the article How Accurate was Forrester’s Article on HANA TCO.

HANA’s Lower TCO?

For a long time SAP has continually proposed that HANA has a lower TCO than other database vendors. This was proposed by Jon Appleby (who is an SAP surrogate).

“I don’t want to get into detailed pricing debates on a blog, but I help customers implement SAP HANA every day, and it’s less expensive than Oracle, period.

Firstly, it’s available at a lower % of your SAP software estate than Oracle – so you will actually get a license payback if you implement HANA. Sure, that’s different to ROI, but it’s a nice place to start. For any apps where you don’t want to implement HANA, SAP throw in SAP ASE included in the price. And remember that if you buy S/4HANA in 2015, you will get all the future innovation included for the price of the SAP Business Suite on HANA runtime license last year.”

It appears that SAP is bundling ASE with HANA. But is this not contradictory to SAP’s argument about all non-columnar databases and all non-in memory databases being worthless? Is the argument that SAP will throw in ASE, which is a standard RDBMS design which can be used to replace Oracle, DB2 or SQL Server?

A Confused Argument

I thought the argument was that Oracle, DB2 and SQL Server had to be replaced because they aren’t 100% in memory and 100% columnar. Then SAP offers a non-in memory and non-columnar database with HANA?

SAP’s HANA runtime license is a highly deceptive method of slipping HANA into a company at a low cost, that will convert to a very high cost after it has been connected to another system. Therefore, the fact that future innovations are “included in the price” of the runtime licenses is just about the most deceptive thing I have ever heard. Apparently, John Appleby assumes his customers are stupid and that he can trick them.

Whatever Jon Appleby is talking about here, the end result is that HANA is far more expensive than the other options.

HANA 2.0

“There is one more specific point. SAP has released HANA 2.0 and standard support for HANA 1.0 will cease in 2019. This means that existing Business Suite and Business Warehouse customers running on HANA will need to upgrade HANA versions and, possibly, there will also be Linux version upgrades required, which will often be side by side appliance upgrades rather than in-place upgrades. As we shall see, this represents a recurring theme whereby SAP effectively forces users to upgrade between incompatible or semi-compatible versions of the same product. This is not just exploitative on the part of SAP, it illustrates the fact that these are not mature offerings. In our view, users would do better to wait before making any SAP investment decisions with respect to SAP HANA.”

And how does this upgrade impact the TCO? Obviously, it puts it sky high. Secondly, there is literally no performance justification for using HANA. Therefore this is money that the IT department is essentially flushing.

For a long time SAP has continually proposed that HANA has a lower TCO than other database vendors. This was proposed by Jon Appleby (who is an SAP surrogate).

“One of the things which is great about working with HANA is that innovation comes seamlessly and often. There was a time when HANA updates came too often, but that pace has slowed over the last 18 months with two major releases a year, verified for datacenter usage. There are some more frequent updates for early adopters or those testing new functionality, but for most, it’s now possible to get great innovation every 6 months with minimal disruption.”

Seamless Innovations

First of all, these “innovations” which are changes to HANA are anything but seamless. In fact, they are filled with seams. The major seam being that all HANA customers will have to upgrade to HANA 2. That is a pretty big seam. And all of these “innovations” bring HANA closer to what Oracle 12c, DB2 an SQL Server can do already.

Also, let us get real. These “innovations” are simply the product being developed. They are not things that other database vendors don’t already have, so they do not classify as innovations.

In this case, the term innovation was used to justify the fact that HANA is less stable. HANA has a much shorter history than Oracle 12c, DB2 or SQL Server. It would be like someone building a boat that has no advantages over another boat stating that because they are still building the boat and the other boats are finished, that the first boat builder is engaging in more innovation.

No, they would be engaging in boat building.

The HANA Platform

“In fact, the SAP HANA Platform includes all of SAP’s major databases. That is, SAP HANA, SAP Adaptive Server Enterprise (previously Sybase ASE), SAP IQ (previously Sybase IQ) and SAP SQL Anywhere (also previously from Sybase). Of these, the product most likely to be used in conjunction with SAP HANA is SAP IQ. This is included within SAP BW (Business Warehouse) along with SAP-NLS (Near Line Storage solution), which provides the ability to transfer data from HANA to SAP IQ in an environment where SAP HANA is used for operational analytics while SAP IQ is used as the enterprise data warehouse. HANA 2.0 provides what SAP calls dynamic data tiering, to be used in conjunction with SAP IQ, but this is a relatively new release and it does not appear to be as capable (yet) as the proven and more mature offerings available from AnyDB vendors.”

While Bloor does not get into this point, it is worth asking, what does the vast majority of this have to do with HANA?

All of this is actually part of SAP’s overall strategy to use HANA to penetrate the database layer at customers with many database products that really don’t have anything to do with HANA, but are marketed as a combined brand.

For example:

  • SAP IQ is marketed as the archival database to HANA. But SAP IQ is another column oriented design, like HANA, so it is a strange choice for archival.
  • SAP Adaptive Server Enterprise is another Sybase product that was developed many years before HANA.
  • SAP BW was also developed prior to HANA. It is one of the few natural fits for HANA as it is a data warehouse, however, why would it be part of a HANA Platform? It makes no sense and reeks of marketing commingling.

Bloor on the Adaptive Server

Bloor’s statements regarding IQ and Adaptive Server’s long-term future are accurate.

IQ is in decline, and Adaptive Server is in one of the steepest declines I have ever seen at DB-Engines. This is a site that estimates database popularity.

A good reason to not get acquired by SAP. 

Hadoop for SAP BW EDW Archiving

“Conversely, SAP is now positioning both VORA and Hadoop (MapR) technologies as SAP BW EDW archiving tiers, thus creating further data platform choices and, potentially, IT operational complexity.”

Why would any company need SAP to connect anything to Hadoop? All of the technologies related to and connected to Hadoop are open source. If SAP is saying that you need to involve them to connect to Hadoop then someone at SAP is providing some inaccurate information.

Companies can keep SAP away from archiving will be better off as this has never been SAP’s strength. I have yet to hear anyone else proposing Hadoop for BW archiving. But if anyone knows differently, please comment.

Bypassing Technology Specialists to Target C Level Executives

“…discussions we have had suggest that SAP is putting significant pressure on companies to do this. On an a priori basis the key issues here are..”

  • a) whether you will get significant price/performance benefits from this migration, and
  • b) whether those putative benefits will outweigh the costs of that migration. Leaving other considerations aside, the answer to the first question is “it’s unlikely” and to the second question is “no chance”.

“And this is not just our opinion: if you are a C-level executive just ask your own IT staff about their opinion. We would lay long odds that they will agree with us. In fact, it is clear from discussions we have had on this topic, that SAP is targeting C-level executives, and bypassing IT SAP solution and/or client architectural teams, for precisely this reason.”

Right. The worse the value, the less the solution makes sense, the more you need to remove the process from those that can evaluate the and validate the information provided. This is the standard practice employed by vendors that know they have a weak value proposition.

“…is further worth commenting that SAP’s “Simplification List for S/4 HANA” runs to 408 pages! Particular note also has to be taken if SAP Industry Solution (such as IS Utilities) functionality has been developed and deployed beyond S/4 Simple Finance and/or Simple Logistics.”

Brightwork has pointed this out in the article How to Best Understand the S/4HANA Simplification List. Actually, the term “simplification” applied to a list as complex as this list is, is a use of the term simplification as simply a term of propaganda. That is in the same way that the US Congress names bills that have the opposite outcome from what the bill is named.

Column Oriented Rows

“Data may be held in columnar format. This is not an all or nothing choice. Where it makes sense to use columns you can use columns and where it makes sense to use rows you can use rows combined with conventional indexes. Column-organised tables do not have secondary structures, such as materialised query tables, thereby eliminating any need for synchronisation. If you are looking for the sort of HTAP-based environment discussed previously then we believe that this is a more complete solution, albeit that Db2 with BLU does not formally meet the definition of HTAP.”

Yes, SAP makes it seems as if they are the only vendor that offers a database that can store data in a columnar format. This is, as noted above, incorrect. IBM DB2 can do it. Oracle 12c can do it. SQL Server can also do it. And while SQL Server is well regarded as a good value database, I don’t know anyone who considers an innovation leader. Here is the quotation from SQL Server’s documentation on the columnar store.

Here is the quotation from SQL Server’s documentation on the columnar store.

“The columnstore index in SQL Server 2012 stores columns instead of rows, and is designed to speed up analytical processing and data-warehouse queries. Whilst columnstore indexes certainly do that effectively, they are not a universal panacea since there are a number of limitations on them. When used appropriately, they can reduce disk I/O and use memory more efficiently.”

Therefore if all the database vendors that are options for SAP can do this, and if all the database vendors that are options for SAP can use SSD and RAM in as much volume as necessary, then what is HANA’s advantage?

IBM’s Memory Assumption

“Unlike SAP HANA, which has been designed purely to provide in-memory capability, Db2 with BLU Acceleration has been designed on the premise that your environment will always exceed the amount of memory available. Of course, you can always pay significant amounts to have perhaps hundreds of terabytes of memory, but that is organisations.”

Yes, SAP has the least sophisticated interpretation of the interaction between memory and databases than do SAP’s database competitors.

John Appleby stated the following back in 2013 on this topic.

“All three of the major RDBMS vendors have released in-memory add-ins to their databases in the last year. All of them support taking an additional copy of data in an in-memory cache, or in IBM’s case columnar tables. All of them provide improved performance for custom data-marts. But make no mistake; caching data has been around for a long time, while an in-memory database platform to run transactions and analytics together in the same instance is a new innovation.

Traditional database caching solutions are similar to the GM and Ford response to hybrid cars – take their existing technology and bolt new technology to it. SAP HANA is more akin to Tesla, who rebuilt the car from the ground up based on a new paradigm.

And so HANA’s capabilities from a business application perspective are 3 years ahead in technology from what others have.”

That is curious. Because none of these proposals by SAP/John Appleby seem to allow HANA to compete with Oracle 12c in either benchmarking or in feedback from the field. And by the way, John, how many cars does Tesla sell in a year?

Is the Tesla Analogy Accurate?

Right. However, even if the Tesla analogy were correct it may not necessarily apply to HANA. For instance, I could say that HANA is just like cold fusion. That is a lot of hype with no benefit. But have I proven anything by saying this? No, I have not. Analogies only work if the person offering the analogy is not intent on misleading the listener.

Caching Data

Caching data has been around for a long time, and it works very well. The fact that something has been around a long time is not an argument against it, it is an argument in favor of it. Things that are around for a long time work. Moving all of the transactions and analytics together is infeasible because databases don’t work that way. If John Appleby does not know this, then he should not be writing about databases. Because it is infeasible, it is not an innovation (check the definition of innovation, it must be a positive contribution). As is pointed out in the article What is HANA’s Actual Performance, SAP has never released a benchmark for transaction processing for HANA? It is the speed demon on transaction processing that John Appleby claims why not? Furthermore, results from the field show that HANA actually has a performance degradation in transaction processing.

Hasso Plattner Congratulating John Appleby for Distributing False Information on HANA

Is it possible that John Appleby exaggerated HANA’s benefit in return for something of value provided to him by SAP? SAP implementations perhaps? We know one thing. Hasso really really liked John Appleby’s articles.

“WELL DONE JOHN (and your team)!

HANA is just too good to be missed. I am currently working on a mixed system configuration, using both a SMP system for scale up and a cluster for scale out. We wont have any size limitations any more pretty soon.

The technical conversion of large ERP systems to ERP running on HANA is relatively easy and fast, but to check all the modifications and extensions unfortunately will take some time. Many large projects have started and I am very pleased, that You talk about Your experience all the time. I understand that customers are afraid of switching the database they are used to for many years. But at least they should really know what they might be missing.” – Hasso Plattner

Yes, when you mindlessly agree with everything Hasso sends over to you and serve as a passive repeater, you get a lot of positive feedback.

AnyDB Versus HANA

“SAP has been emphasizing the performance advantages that this brings to S/4 and HANA without mentioning that AnyDB support for CDS means that those users should get the same benefits that SAP Business Suite clients. The key issue here is that as SAP re-optimise many millions of lines of ABAP SAP Business Suite application code for HANA, databases like Db2 and/ or Oracle then leverage CDS in ways that result in significant performance benefits for existing SAP Business Suite users with AnyDB solutions.”

Right. SAP has proposed that only HANA can take advantage of the rewritten S/4HANA code. They do this when they state that S/4HANA has been optimized for HANA. But has it? In fact, as Bloor points out, it is optimized for AnyDB that can also have some columnar table capability (one does not need all the tables to be in columns as SAP states). A second argument used by SAP is that they cannot make S/4HANA run on AnyDB because they use stored procedures, which is code moved from the application layer to the database layer. Yet, there is really no reason this code could not be either put back into the application layer or moved into AnyDB. IBM, Oracle and Microsoft would be more than willing to help SAP do this.
There is no technical reason why S/4HANA is limited to HANA. There is, however, a commercial reason as covered in the article Why SAP Will Have to Backtrack on S/4HANA.

Performance Improvement from HANA?

…the bottom line is that if you have a performance issue it may be because you have not explored all the options. Migrating to SAP HANA for this reason is, in our opinion, unlikely to be the best option. It also depends on where the performance issue is. For example, our understanding is that HANA will not do much for you, in particular, if have you have long running batch processes and/or database intensive z code.

Right. But I think the evidence shows this is too optimistic. HANA will provide a performance degradation over at least Oracle 12c. I cannot say with as much confidence regarding DB2 and SQL Server, not because I think HANA would beat them, but simply because I have not researched those databases as I have Oracle 12c. But results from the field demonstrate that HANA only does one thing well — which is read, which is why its only application is for analytics.

Migrating to S/4HANA

“To summarise, the only good reason, as we see it, to migrate Business Suite to SAP HANA, is that you intend subsequently to migrate to S/4 HANA.”

Hmmm…perhaps. But HANA comes with indirect access overhead, which should be a major concern. Secondly, what IT department would allow their application vendor to dictate which database they would be using? Also, why would you purchase a database from a vendor that had so aggressively misled you on the features of that database?
The rest of the Bloor paper deals with S/4HANA, so we will cover that part of the white paper in a separate article.


Even though this research with funded by IBM, I cannot find any inaccuracy in the white paper. I have been a reasonably long time researcher of HANA, and I learned several things from the white paper. Bloor (Philip Howard) did an excellent job of synthesizing information about HANA and presenting this information. Some of the information presented in this article I have not seen presented elsewhere. I estimated that Philip was given good access to a number of IBM DB2 resources who really know that product. I am also chuckled to myself when reading it because I think the IBM DB2 group is sick to death of SAP’s exaggerations on HANA and finally fought the political battle necessary to get this research funded. Since HANA first came out, I imagine the DB2 group was told to shut up, as to not offend SAP.

The only area where the bias shows is that all of the comparisons are to IBM. Yet Bloor and IBM certainly know that many of the statements that apply to DB2 also apply to Oracle and to SQL Server. But they choose to focus on IBM because the paper is funded by IBM and that is their area of expertise. (I do this myself because most of my research into the competing product for HANA is in Oracle 12c) That does not mean there is any inaccuracy, but it brings up the question of the reason for the omission. But Bloor does moderate this at least by consistently using the term “AnyDB” which is broadening out the research finding to non DB2 databases.

Bloor receives a score of 9.5 out of 10 on their white paper.

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible 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.



Columnstore Indexes in SQL Server 2012