- John Appleby made many claims around HANA.
- We review his accuracy in terms of moving BW to HANA
On Sept 5, 2012, Mitch and Murray……I mean….Bluefin Solutions published the article Building the Business Case for SAP BW on HANA.
Now with close to five years of hindsight, we will review how accurate the accuracy of this article.
“Implementing SAP’s NetWeaver BW Data Warehouse on its in-memory platform SAP HANA (otherwise known as BW on HANA) might just be SAP’s fastest growing product line in history, with 150 projects within 3 months of General Availability of the product. One of the elements my team is most involved with right now is building the benefits case and business case for the capital investment. This blog gives an overview of what is required and what the elements are.”
Let us head out to DB-Engines to verify this claim of HANA being or “might be” the fastest growing SAP product line in history.
Does this look like the fastest growing product in SAP’s history? It should be stated that Bill McDermott called HANA the fastest growing product in the history of software — which means that it beat Angry Birds. We covered this claim in the article How Accurate Was SAP on HANA’s Growth?
So not a great way to start off the article. Let us move on.
“As with any business case, we have a set of capital and operational expenditures, which offset or avoid costs, or bring tangible benefits. The biggest difficulty with this as relates to Data Warehouses is that the benefits of faster, better decision making are hard to measure. What we tend to do instead is to create the business case based on savings, and describe the benefits case as coming “for free”. Yes – despite the capital expense, BW on HANA will save almost any business money.”
This has turned out to be fabulously wrong.
Let us look at the cost side of the equation.
At Brightwork, we estimate that HANA has the highest TCO of any of the databases that it competes.
This is covered in A Study of SAP HANA’s TCO.
- The license is higher (although lower since they started discounting HANA)
- The resources are more expensive (they are less common)
- The HANA database is less stable. It is constantly having patches, new components that must be installed, etc..
- The consulting projects for HANA are longer due to maturity issues. Our estimate is 1.25 years to take HANA live. This is based on information coming in from projects globally.
Every single item that builds up the TCO is higher with HANA than any other competitive offering.
Now let us look at the benefits side of the equation.
As covered in the article What is the Actual Performance of HANA?, there is no evidence that HANA is faster than competing solutions like Oracle 12c or IBM Blu or even SQL Server — all of which now how column-oriented stores. In fact, the evidence is that HANA is slower than these databases, and it is also far less stable. A database is not only measured based on its performance. Stability is an even more important factor for rating databases.
SAP HANA Licensing
“The great thing about SAP HANA DataCenter Edition pricing is its simplicity. You pay one price per 64GB unit for all use cases including all features, including some that other organisations like IBM and Oracle charge for: compression, tuning, high availability etc. It is important though to understand how many 64Gb units you need for current and future needs – assessing how big your system will be and how much future compression you can hope to get.”
Nice try John, but due to the competitive pressure, SAP increased the price of the databases they OEM or resell to match the higher cost on HANA.
This is covered in the article How HANA is Being Used to Block Out DB Vendors.
These comments by Appleby are utterly false…and wait a minute…
Ding Ding Ding!
We award John Appleby our Golden Pinocchio award for proposing that HANA, the most expensive database that exists, is lower than competing offerings.
“SAP HANA hardware is available from all major vendors in 128GB-1TB single nodes, or clusters of up to 16x 512GB or 1TB nodes. My advice for anyone with a moderate size BW system: only buy 512Gb “medium” nodes and start with 4.”
HANA uses the most expensive hardware setup because it inefficiently requires more of the database into memory, but HANA does less with the same amount of hardware as other database vendors.
Interestingly, Appleby does not even attempt to mislead people here on the cost of HANA hardware.
But, no matter what the customer “starts with” the evidence is now clear that HANA will use a far larger hardware configuration than any competing offering. Due to HANA’s design issues that SAP is still trying to work out, HANA will not be able to address much of that hardware depending upon the database processing that is performed.
“There is a cost to support SAP HANA. You will need to include software, hardware and systems support costs, depending on the period over which you choose to build the business case (I suggest aiming for 3 years with a 1 year ROI).”
Why is that true? HANA has discounted support. So 15% instead of 22%.
If SAP removes support costs on HANA, this is the first we have heard of it. And this is exclusive of the high degree of support that HANA instances require that are not covered by SAP support. Appleby is remiss in mentioning it, because….you guessed it, Bluefin Solutions offers these services.
“There will, of course, be a cost to implement SAP HANA, either by migrating your existing BW system or by creating a new one.”
That is a fantastic admission on the part of Appleby. It’s quite educational to read through Appleby’s articles to learn that SAP products have implementation costs. Thank you, John. That might be the only true thing in your article.
HANA will not only have implementation costs, it will have the highest implementation costs of any of the competing database for the reasons already provided.
“Most organisations spend a substantial amount on BI projects, and with BW on HANA they will either spend less (fewer full time employees or consultants) or achieve more for the same, in a shorter elapsed time. Our benchmarking suggests that project build times are 20-30% less with BW on HANA, leading to an overall saving of 10-12% or more for capital projects.”
It’s unclear why anyone would listen to Appleby, who released a continual stream of false information, on any of his benchmarks. Secondly, it is maddening to see a consulting company like Bluefin Solutions that has repeated inaccuracies that are promotional in nature pose as if it is a research entity. Nothing Bluefin Solutions says about HANA can be accepted without verification.
Furthermore, BW has a very poor development productivity. HANA would simplify this, but there are far better data warehouses on the market that would reduce the built times even more than Appleby’s dubious reduction.
The question should arise, that if one wants better report development productivity, why have one of the least productive data warehouses in the BW? Put another way, if report development productivity was a focus, why was BW chosen by the customer in the first place?
This is usually enough to pay for SAP HANA on its own, several times over.
- Appleby is trying to sell HANA services, he is not a researcher. He will not have any idea if this is true. If a consulting organization that sold Oracle services stated that Oracle has lower costs should you listen to them? Of course not.
- Appleby is assuming the HANA portion of the implementation is lower maintenance than the database it replaces, but that is incorrect. Due to HANA’s overhead, the maintenance costs on HANA drastically increases according to information from the field.
Most organizations have one or more Full-Time Employee (FTE) dedicated to performance tuning of existing solutions. This may be a DBA or BI resource; I have run projects that used 500-1000 man-days for performance tuning of large EDW environments. With BW on HANA this is a thing of the past.
Another pie in the sky projection….with unicorns jumping over rainbows that do not match the information coming back from HANA projects.
HANA has not only performance tuning, but it has maintenance overhead that competing databases do not have. If a company implemented HANA 1 below SPS 9, that company will have to reimplement to get to HANA 2 completely! Get real John Appleby!
Maintenance Problems with HANA
“In addition, SAP HANA is less costly to support than other databases because it requires almost no maintenance. Expect savings here.”
Appleby wrote this article in Sept 2012. Let us bring up the chart again.
According to DB-Engines, HANA had almost no implementations as of Sept 2012.
How would Appleby have any idea what the maintenance of HANA at that time was? Oh, right SAP told him, and he repeated it.
HANA will also have higher maintenance costs than competing offerings. Immature products require higher maintenance.
Hardware and Spinning Disks Taking Up So Much Space
“BW on HANA hardware is cheaper and greener than other EDW platforms. Many other platforms require hundreds of spinning disks which are costly and take up space. With BW on HANA you know exactly how much you need based on the size of your Data Warehouse and you do not need bolt-on accelerators like BWA or Exalytics, taking up more space.”
Here Appleby returns to a topic that he already addressed but left out the costs. It turns out he is going to propose that HANA has a lower hardware cost than competing databases.
This is inaccurate because HANA requires so much memory, and RAM and SSD memory is more expensive than disks.
- How do hundreds of spinning disks take up space? Has Appleby ever seen how much space 200 hard disks take up?
- And why does the company need hundreds of spinning disks again? Does Appleby realize how much capacity a spinning disk has?
We are going to help Appleby by going shopping for disks online.
This is an 8 TB disk by Seagate. It costs $459 on Amazon. It does not seem that large. When installed in a server, it’s larger, but a single rack can hold a huge number of spinning disks.
Appleby should probably keep up to date on the sizes of disks before stating that it takes hundreds of spinning disks and that SAP customers can’t afford the room to place the disks. The statement is wrong in multiple dimensions. It is a laughable conjecture, and therefore….
Ding Ding Ding!
Appleby gets a second Golden Pinocchio award for this statement that spinning disks take up a lot of space.
If your are a BWA customer then SAP will allow you to trade in that purchase, often to 100% of the original purchase amount. Talk to your SAP account team for more details.
Is this the way a person who is pretending to be independent is supposed to speak? As in..
“Visit a Chevy dealer near you!”
This is the kind of sentence used at the end of a commercial. And let’s remember….
ABC, always be closing. Always — be — closing. Always ——- be ——— closing!
- The first place prize at Bluefin Solutions for selling HANA is a Cadillac El Dorado.
- Second places is a set of steak knives.
- Do you want to know that third place is?
“When you make your first purchase of SAP HANA, you may be eligible for a services rebate of up to 30% of your license price that can be used by a BW on HANA Systems Integrator (including Bluefin!). In some cases you can save money by purchasing more HANA units and getting a bigger rebate. Talk to your SAP account team for more details.”
Once again Appleby really wants the reader to talk to their SAP account team! It almost seems like Appleby is coordinating messaging with SAP. But that can’t be true as Bluefin Solutions there to look after the interests of their customer. They would never sell that out…..right?????
“Many organizations are set up in such a way that they have budget set aside for infrastructure projects like upgrades. If you have an older Data Warehouse then it may be time to upgrade it and if you combine the upgrade with the migration to SAP HANA then you will save money on the overall program of work.”
And if you trade in your old car, it will reduce the price of your new car.
Appleby should be aware that software vendors normally update their products. So if a data warehouse has been implemented for a while (that is old according to Appleby) there is a good chance it has been upgraded. Therefore it may not actually be “old.”
Just a question……could any of this desire to have companies move to SAP HANA for their new data warehouses have to do with Appleby’s firm offering HANA and or BW consulting services? Is Appleby giving advice or ABCing again?
Third Party Analytics
“How much money does the business spend directly with third parties because they can’t get what they need out of their existing EDW? Chances are with SAP HANA, you will be able to provide what they need and you can cut the cost of third party Analytics suppliers.”
This is another projection that did not work out.
SAP has been promising analytics for a while but has provided very little. HANA is primarily installed under BW. BW has one of the highest TCOs in the analytics space. See our BW TCO Calculator for details. (It is free) And the HANA predictive analytics don’t appear on the SAP accounts that I see.
Look, Appleby does not care about cost reduction. His company, Bluefin Solutions sells HANA consulting services. Let’s get real.
“Looks back through your last year of BI projects and talk to the project managers. How much over-run was there on those projects and how much was attributable to performance problems? Moving to BW on HANA will allow you to reduce over-runs.”
I see many SAP accounts, and I don’t know of customers that have HANA performance problems with Oracle or DB2. Secondly, simply upgrading to Oracle 12C or DB2 BLU will speed the performance more than pulling out previous versions of these databases and replacing them with HANA.
This is covered in the article What is the Actual Performance of HANA?
SAP has had years to provide evidence of HANA’s superior performance, and they have provided nothing to support any of their marketing claims.
The Benefits Case
“Hopefully by now you will be able to create a basic cost/saving sheet for BW on HANA – in every example I have seen, it has saved organisations money either in TCA (for new implementations) or TCO (for migrations of existing EDWs). This makes BW a “no brainer” in the eyes of the people I have spoken to, and so we can focus on making the soft benefits case attractive.”
Based on what?
All of the information provided by Appleby up to this point has been false. Much of it ludicrously so. Bluefin Solutions makes its money from implementing SAP and was very focused on getting HANA business at this time. Who would trust a salesperson to provide assumptions to develop a benefits case?
“Performance problems are the single biggest reason why BI projects overrun and are delayed. With BW on HANA you still need to design performant solutions, but you don’t have to worry about large or complex data models.”
That is not at all what we have seen on projects. The number one complaint about BW on Oracle or DB2 is unrelated to the database. It has to do with the productivity issue with the BW.
The most direct and cost-effective way to address this is to replace the BW with a more competitive data warehouse application, not to but BW on HANA.
“Implementing BW on HANA becomes a no-brainer for most organising who try to build a business case in this way. What elements have I missed and what other components are you using to build the business case? Let me know and I will update this article to include them!”
This article has been a no-brainer, in that you would have to lack a brain to believe it. It is chocked full of lies, and with Appleby repeating whatever SAP marketing told him to say.
This article appears to be a competition to see how much Appleby can ingratiate himself to Hasso Plattner. When Hasso sees a nice compliant article like this (and HANA is his baby) he is likely to shower the entity that carries the flag for HANA with benefits. This is another problem in that Appleby is partially writing this article to score points — accuracy is the furthest thing from his mind. All the messaging provided here was coordinated with SAP before Appleby wrote the article. And once you can see what went on in the background it is quite insulting to the reader.
It also drives down to an unsettling pathway with Appleby continually trying to get SAP customers to contact their SAP sales rep.
This article receives a 1 out of 10 for accuracy.
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.
The Risk Estimation Book
Better Managing Software Risk
The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.
Finding What Works and What Doesn’t
In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.
Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model