Head of Business Analytics & Technology
Bluefin Solutions
SAP HANA - myth-busting through the marketing hype
31 May 2011
Business Intelligence (BI), HANA, In-Memory, SAP NetWeaver Platform, Consumer Business
In the aftermath of SAP's annual SAPPHIRE conference, there have been numerous pieces of analysis on HANA - but they have all missed the point. Let's do some myth-busting.
#1 - HANA 1.0 is a replacement for BW
HANA 1.0 is no more than an analytics engine on Kool-Aid, which SAP has recently taken to calling an Application Platform. I don't think HANA is an Application Platform yet, but it seems clear that it is the DNA for SAP's future platform for almost everything. This is fine for a first-generation release and as I have written before, it seems likely that early adopters of HANA - in its 1.0 release - can get serious business value. Assuming they choose an appropriate use case, that is, for HANA 1.0 is not for everyone.
For most organizations willing to invest in HANA, they need to find a business problem which either was impossible to measure or analyse before due to large data volumes, or for which a Data Warehouse like NetWeaver BW is insufficiently agile - either in change terms, or in frequency of update. Those organizations who find such a business problem should implement HANA 1.0. Probably most large organizations have such a business problem, but not all will be able to find it.
#2 - HANA 1.5 is an upgrade to HANA 1.0
By the way, it seems likely that SAP will call HANA 1.5, HANA 1.2, but that's by the by. HANA 1.x will be a very different beast to HANA 1.0 because it will replace the Oracle, DB2 or MSSQL database platform for the NetWeaver BW Data Warehouse. Existing customers will be able to migrate from their existing platform onto HANA using a regular SAP migration process - which basically involves sucking SAP out into a file and injecting it into HANA.
The astute will notice that this means HANA can be a RDBMS for almost any SAP release including any of the Business Suite products but SAP aren't ready to risk putting the core business on HANA yet. Instead, they have rewritten parts of BW in machine language so they perform much faster - 2-3x faster for calculations and planning compared to BW.
But it seems clear that HANA 1.0 and 1.x will remain as two distinct products in the short-medium term, because not everyone wants a Data Warehouse and not everyone who does, will want to run it on HANA yet.
#3 - HANA is the solution to everyone's problems
Hopefully it's clear from the above that HANA isn't for everyone. For a start, you need a budget in excess of $500,000 to implement HANA - for now - which means that it is for larger businesses, and those with capital to spend on Business Analytics. The cost is partially caused by the hardware: SAP claims it is commodity, and has recently reworded this as "high-end commodity", which is more to the point.
SAP has also shown HANA running on a Mac mini, but this is marketing because whilst HANA will run on anything from your laptop upwards, SAP won't allow it. You can only run HANA on the latest and greatest Intel blade technology and SAP is very restrictive of what hardware it can run on so it shows HANA off at its best.
In addition, the low end of licensing is not that low, because - I suspect - SAP want to implement a small number of key customers and build success stories. This means that HANA is priced out the market for the Small & Medium Enterprise - for now.
#4 - HANA is already changing the world
The details of this are a bit shaky, but details of productive customers are unclear from SAP. In addition reports from the field suggest that those customers who are implementing now, are going through some teething troubles - with HANA as a database, and also with performance using SAP BusinessObjects BI4. This isn't particularly worrying because new technology always has teething troubles, and those organisations willing to implement very early ought to know that and be willing to put up with that in order to achieve competitive advantage.
It's certainly true though that as HANA matures, the competitive advantage that can be achieved may be immense and early adopters may pat themselves on the back.
#5 - HANA is a game changer
I've gotten a bit sick of people saying that HANA is a "game-changer" because it is totally missing the point. I met up with Ike Nassi at SAPPHIRE, who has the bizarre title of "Chief Scientist". From what I can see, he puts together the hardware for HANA and has a big technical playground from Hasso Plattner. He talked about how his team were actually building new Intel blades with very specific qualities like ultra-fast Level 4 cache to improve performance.
But more to the point, he seems to actually get HANA as well as anyone I have met and he's the first person to coin my phrase: In-Memory Computing is an inflection point. We don't get to see inflection points very often - for me, they are:
- Transistor
- Mini Computer
- Magnetic Disk
- Personal Computer
- Cellular telephone
- Compact Disk
- Solid State Storage
- In Memory Computing
In my opinion at least, everything else we hold dear - the iPhone, DVD, Laptop - are nothing more than miniaturisation and evolution. But In Memory Computing is different because it allows us to do things that we couldn't dream of doing. I can't tell you what those things are because they haven't been invented yet, but make no mistake, they will be.
If you remember the CD, people said it would never replace vinyl records because it didn't have the quality. And that's the thing with inflection points: we don't understand their relevance until we can look at them in a historical context. HANA will go down in history as the start of an inflection-point that we don't yet recognise.
Comments
Mike Bestvina @techdisruptive 13 Jun 2011
@Vijay - Totally agree - and it will not stop with 20 customers. I'm still having issues with customers on BWA trying to properly size - and more importantly size it for growth. Since the IMDB is only doing "table" appends this will have to be closely looked after. From a hardware perspective does this present challenges to scaling and adding servers with a rack based system (my understanding is all of HANA is rack based at the moment)? Honestly this is something that is often overlooked. This is one of the downsides of using RAM as a medium for raw data scaling. If you begin to run out of disk, its relatively easy and cheap to scale your SAN. Not to mention most customers end up buying way more disk than they need. What happens with HANA then?
"Right now, I have couple of clients that is looking at HANA as potential customers and there seems to be more questions than answers for those in the initial planning and budgeting state.... "
I think everyone is in the same boat here, and no one (SAP or Hardware P's) is in a good position to comment. Even with QuickSizer giving SAPS for a Netweaver installation, hardware sizing is still not entirely accurate. Which is why load/performance testing is so important during the project and is often underemphasized.
I think the overall disagreement is why is SAP already speaking about compression numbers and why is Dr. Berg regurgitating these numbers. As Vijay pointed out, I believe even Dr. Plattner realizes this. The "rest of us" know from previous experience this is a dangerous place to back track later from. Until it is in a note or comes directly from SAP Dev, it's not a "FACT".
Can't we all just be good consultants and say "it depends" :)
Vijay 12 Jun 2011
There is just no good way to size HANA at the moment - it needs to go through the same cycle of pain we went through for BWA in past. Once 20 customers try it out - we will get an idea, and adjust this.
This compression debate is something I had with Hasso Plattner briefly at SAPPHIRE - and he agreed that the big number compression ratios were all related to raw data. That - to me - is slightly misleading, since customers already see compressed data via DB2 , ORCL etc. Plus, not all kinds of data gets compressed the same way.
Finally, all the current rules of thumb will need a serious revisit when write back scenarios increase in HANA.
I already posted a rant earlier on HANA after I came back from SAPPHIRENOW . http://andvijaysays.wordpress.com/2011/05/20/sapphirenow-day-3-report-out-hana-mobility-gateway-and-sting/
Dr. Berg 12 Jun 2011
Hi Vitaliy,
First, I did not imply that you were the "devil" :-) That is just a saying when someone misreads something....
Anyway, as you stated, the compression depends on the type of indexing row vs. column (as stated in the blog), and also the underlying database (i.e. Oracle compresses numbers by default upto 50%),. I guess that is why SAP presented compression numbers ranging from 1:5 (minimum) to as high as 1:25 (high). Also, the two examples I gave was for a 'cleaned' 3Tb and a 10Tb 'cleaned' BW system. Finally, yes HANA does currently not support BW until SP-3 (formerly v1.5). Anyway, as these postings illustrate, note 1514966 would probably benefit with some ‘examples’, benchmarks, rule-of-thumbs similar to those presented in May at Sapphire by SAP. Right now, I have couple of clients that is looking at HANA as potential customers and there seems to be more questions than answers for those in the initial planning and budgeting state....
So no intention to call you a 'devil' just an American saying....
Dr. Berg
Vitaliy @Sygyzmundovych 10 Jun 2011
Dr. Berg:
I am not the devil. And your blogs are not the bible. Sorry.
mgr inż. Rudnytskiy
PS. To the question of sizing - the only official sizing statement is OSS note 1514966 "SAP HANA 1.0: Sizing SAP High-Performance Analytic Appliance". We are all in a violent agreement that it says nothing and that there is a need for rule-of-thumb. If someone is taking an effort of explaining this to the broad audience, should take as well take responsibility for being clear. As we learned already with BWA - once damage done it's difficult to repair.
Original quote starts with "10TB system" with BW and ends with 1.5TB RAM sizing for HANA - besides the facts that BW cannot run on top of HANA right now, there is no data aging functionality in IMDB for the moment, so all tables - data, temp data, metadata, control data - should reside in main memory. Another fact often missed is that many RDBMSes apply their own compression to the data stored, and therefore their table storage sizes cannot be taken as initial data size without applying some additional formulas. Btw, 5:1 compression ratio estimate applies to columnar store only; row-based store benefit from compression is in the range of 10-15%. There are few more clarification statements that I could add to the sizing and the rest of the original blog, that I really had tried to avoid.
Ok, it's time for Paul McCartney's performance. Greetings from Vegas, everyone! Cheers.
Berg 09 Jun 2011
I was just shown Vitaliy's comment by a client who responded on this site, and believe I need to clarify:
I think Vitaliy is reading my blog like the 'devil reads the bible'. The quote was:
SAP has reported compression of at least 1:5 and a maximum compression of 1:25. That means that if you have a 10 Tb system, you would need at least 2Tb, memory (1 to 5: compression). However, to make sure that there is enough room for temp files, SAP recommends that customers size their environment at 50% of raw data size. For our example, this means that by only looking at raw data in our 10TB warehouse, we may have only 3Gb 'unique' data. It is this that is our base sizing parameter. The rest of the BW data may be PSA data, replicated DSO or InfoCube data, aggregates and log files that we will not place in-memory. So following this logic, and SAP's recommended sizing strategy, you would need 1500 GB memory (50% of 3Tb).
SO, let us do a math example:
10Tb raw data and 1:5 compression = 2000 Gb (or 20%)
Double this for the 'free space' = 4000 Gb (or 40%)
Add 25% room for growth/sizing err = 5000 Gb (this is 50% of 10Tb)
This has nothing to do with BWA and free RAM. It is a rule-of-thumb provided by SAP's Hoffman at a public presentation at Sapphire to account for compression...
So perhaps "color advice" shall be left to someone else...
Dr. Berg
SunnyDays 09 Jun 2011
@vitaliy,
I read Dr. Berg's post, I see that he is referring to SAP sizing regrading compression, not the double need for blades. I also asked the person he cited (SAP's Torsten Hoffman) at Sapphire if he agreed with approach to sizing that Berg quoted, and Hoffman said it was "probably the best rule-of-thumb' available.
So I don't think you need look for hitmans, but actually read the blogs and see that he was quoting SAP.
Augusto Cristicini 01 Jun 2011
I really like your inflection point message.
Every major breakthrough (inflection point) is a combination of Hardware and Software; well almost every inflection point can be broken down to this.
Imagine HANA maturity combined with Large amounts of Flash Memory and a low swap parameter forcing every calculation into that Flash Memory, or if HANA is written to do this forget about the swap parameter portion.
Now the combination of hardware software is showing its true colors. i realize HANA is hardware and software but without speaking of the Flash Memory how can we really realize the benefits here and see the competitors’ products that use Flash Memory in this way, new Oracle Sun systems claiming to do more in Flash Memory by computing IO activity. Isn't this also a break through similar to HANA?
Mike Bestvina @techdisruptive 01 Jun 2011
@Vitaliy,
Oh trust me I didn't really trust half of the info on there. Especially when he spoke about the 50% memory estimation. That's a BWA estimation and I'd be shocked if those numbers are currently readily available. I've been through the struggles of memory sizing (as I know you have) and it's never that simple.
More to my point is that the hardware is not as large of a chunk of the overall cost. I think SAP is touting that the application layer is more "valuable" - whether true or not.
"One being discussed is based on realized value - that's innovative." - I don't think any SAP AE would go for that...
@John - Sorry I didn't say it before, but very good post. As Vitaliy sort of mentioned, I wish there wasn't so much misinformation being spread.
Vitaliy @Sygyzmundovych 01 Jun 2011
Mike:
Bjarne "Dr." Berg is good discussing what colors you should use on BI dashboards, but you should be careful when reading his in-memory posts :-) Like in the one you cited Bjarne converts "50% rule" from multiplying by 2 into dividing by 2!! I stopped commenting/correcting his blogs, because I started being affraid of hit man ;-)
If you are looking for price points, check slide #37 at
http://www-05.ibm.com/ch/ibm_sap_portfolio/pdf/IBM_SAP_Forum_2011__Die_Fokusthemen_20110113.pdf (the only public HANA h/w price list I am aware of :-)
Unfortunately I am not in the position to discuss current SAP license price for HANA, but indeed there different models planned. One being discussed is based on realized value - that's innovative.
John:
I was curious as well what were your assumptions for $500K?
PS. One game-changing technology I missed on your list was GPS. You need to loose a signal to realize all of the sudden how much you depend on it - happened to me last weekend in forrests of Northern California.
Mike Bestvina 31 May 2011
1. "The cost is partially caused by the hardware: SAP claims it is commodity, and has recently reworded this as "high-end commodity", which is more to the point."
Is that actually true? This article quotes some numbers:
http://www.insiderlearningnetwork.com/dr_berg/blog/2011/05/18/the_hana_facts_from_the_floor_of_asugsapphire_2011
"Mr. Hoffman said that customers should plan to spend about $120-$140K for each TB of memory in HANA." "Also, SAP currently license HANA based on increments of 8GB memory blocks, the number of users and the system purpose. However, a good cost planning number is between $1 and $2 million per TB of memory."
These sound very reminiscent of BWA numbers. My discussions with the hardware guys about 3 years ago when implementing BWA was the BWA for the hardware vendors wasn't really as profitable as people made it out to be. SAP has always had its foothold on the majority of the overall in-memory appliance revenues. Sadly the hardware vendors haven't done a good enough job of selling services around it's implementation - lost opportunity IMO.
2. "He talked about how his team were actually building new Intel blades with very specific qualities like ultra-fast Level 4 cache to improve performance."
Yes. I think this is often overlooked. No offense to the specific hardware vendors (HP, IBM, etc) but the real key to the hardware optimization (at least in BWA) is that the application layer is very tightly tuned to the Intel chipset. The developers were explaining to me that the source code actually specifically targets how the inner workings of the Intel chips.
3. "Hey, John. Good collection of thoughts. I am still wondring how all these "industry analysts" cannot see what you see."
That's why they are industry analysts and not techies like us :)
4. "Really the point I was trying to make was that SAP are changing the HANA terminology week by week."
Ummm, welcome to SAP? haha, that was a bit sarcastically snark of me ;)
John Appleby 31 May 2011
@Vijay
Sure - I'm being a bit sensational, but I may be right. In Memory predates HANA but SAP have worked heavily with Intel to get the right CPU Core: RAM ratios. Current generation hardware brings it alive - it is a question of timing. Betamax predated VHS remember, and VHS is remembered.
@Vitaliy
Totally agree and thanks for the clarifications. I just don't seem to be able to keep up with the HANA terminology. Really the point I was trying to make was that SAP are changing the HANA terminology week by week.
Vijay 31 May 2011
great job, John - I liked the blog. These types of blogs are needed periodically to keep all parties realistic :)
The one thing I am not too sure of is your conclusion. The thing with inflection points is that they can only be found after the fact. In memory computing has been around for a bit, and has not caused the big revolution yet. HANA might be the one that gets in-memory to limelight, but I think it is rather premature to say this is an inflection point.
Vitaliy @Sygyzmundovych 31 May 2011
Hey, John. Good collection of thoughts. I am still wondring how all these "industry analysts" cannot see what you see. Or may be they do not want to see this?
The art of understanding is in reading between the lines and in hearing what was not told. For me when SAP says "HANA is game-changing technology.", they say the truth, but are just making full stop too early in the full sentence of "HANA is game-changing technology in SAP landscape". Outside of SAP bubble there are many other product delivering the promise of high-performance and SAP folks often cite Jim Gray of *Microsoft* who said "RAM Locality is King" back in ... *2006*. I've been in SAP world for quite some time, but it still annoys me when SAP marketing assumes I am dumb.
Yet to be absolutely fair, there was indeed co-innovation in Intel CPUs between Intel and SAP to make them perform better for in-memory requirements.
I need to add two small clarifications to your post, just to make sure other readers get expectations right:
1/ "... run HANA on the latest and greatest Intel blade technology...". HANA is currently running on rack servers, with blades just being on the roadmap.
2/ "... seems likely that SAP will call HANA 1.5, HANA 1.2,... " It will be HANA 1.0, but with some Service Pack which is not part of release numbering. So, something like HANA 1.0 SP X. I avoid mentioning SP number right now, as it will not make any sense with constantly changing information.
I still have multiple problems with this SP approach though, like SAP earlier statement of delivering functionality only through Enhancement Packs, or what it means to apply SP to the appliance with many software components. But it is what it is.
Ok, time for my lunch football (soccer, not American football ;-) break. Take care.
-Vitaliy