Recently I read a blog: "Vishal Sikka Gets Real on SAP HANA Benefits and Barriers". URL: http://www.asugnews.com/2011/09/21/vishal-sikka-gets-real-on-sap-hana-benefits-and-barriers/.
Here is one small part from that blog:
==========================================================================
ASUGNews.com: What keeps you up at night about SAP HANA?
Sikka: The adoption, the training and so forth. There is a strong temptation to fall into the trap of the traditional, middle institutions—the systems integrators. And nothing against the systems integrators—they are great partners of ours. But we want customers to control their own destiny. On the one hand we have this strong strategic need to not have the partners come in to implement HANA. If that happens, then we have failed, and Hasso told me that. But on the other hand, we are not there yet, in terms of training, the examples, etc.
And also, to mature the product—to scale it, and to make it incredibly bullet proof, which takes decades for companies like Oracle and IBM to do.
==========================================================================
I'll revisit and explain the significance of above statements later in this blog. First please let me explain my background:
I began my career as a Software Developer in 1988. Initially I worked in a project using C-ISAM routines developed internally by the company I worked for. Unix was our operating system. I don't remember a day Unix system staying up all day; the system crashed at least once every day. Anyone could crash Unix system those days. Unix used to be so sensitive.
A few months later, we decided to use RDBMS. We considered Sybase, Informix and Oracle; finalized on Informix based on price.
We started with Informix Standard Engine. Our development database size used to be 10-50MB(yes, Mega Bytes). We used to take good care of our database. We used to shut the db down every day before leaving for the day. I believe it was one of the best practices recommended by the vendor. And almost every day either DB or Unix would crash due to either heavy load - 2 to 3 developers compiling concurrently used to be the definition of heavy load - or Informix's/tool group member's programs accessing illegal area in memory.
DB or Unix's crashes used to be normal. This continued - gradually decreased of course - for several years. In 1994, while working for a customer in US, the database crashed. The crash was due to disk error. No striping or mirroring was popular in 1994. We used to take back ups but not logs. So we couldn't do point-in-time recovery. We tried very hard to fix the disk - because that was a payroll week, all processing was completed during the day after backup - by speaking to the vendor. They dialed in using 9600 baud rate modem and tried everything they could to get it fixed. We worked all night. No, nothing worked. We lost data.
In 1996, I worked on non-SAP Data Warehouse project for a very large telecom company. It was one of the largest databases at that time, 500GB. The database was Informix on HP-UX 9000, very powerful server at that time. Both DB and the server(to a lesser extent) used to crash. The DB's version was 7.0(or 7.1?); we upgraded to 7.3 to minimize the number of crashes.
From 2002-2005, I was working on both AIX-Oracle and z/OS-DB2 environments. Both DB2 and Oracle used to crash(fail-over) despite vendors working with us full-time. We used to move BW from one LPAR to another during quarterly-end processing leaving only R/3 running in that LPAR. That's how we accomplished scalability in 2003! Of course, moving BW to another LPAR made new LPAR hang. Basically we moved chaos from LPAR A to LPAR B to LPAR C etc.
From 2006-now, db crashes are not that frequent; last DB crash was in 2009 Dec. I've read blogs discussing DB crashes while importing DB during Unicode Conversion recently.
Now let us revisit the paragraph - or Q/A - I posted at the beginning of this blog:
==========================================================================
ASUGNews.com: What keeps you up at night about SAP HANA?
Sikka: The adoption, the training and so forth. There is a strong temptation to fall into the trap of the traditional, middle institutions—the systems integrators. And nothing against the systems integrators—they are great partners of ours. But we want customers to control their own destiny. On the one hand we have this strong strategic need to not have the partners come in to implement HANA. If that happens, then we have failed, and Hasso told me that. But on the other hand, we are not there yet, in terms of training, the examples, etc.
And also, to mature the product—to scale it, and to make it incredibly bullet proof, which takes decades for companies like Oracle and IBM to do.
==========================================================================
Dr Sikka says it took decades for companies like Oracle, IBM to stabilize it, scale it and to make it incredibly bullet proof. Yes, it took decades;Anyone disagree?
Here is what Larry Ellison said last year regarding SAP's HANA: Source: http://www.pcworld.com/businesscenter/article/195768/plattner_to_renew_pitch_for_inmemory_databases....
"Get me the name of their pharmacist," Ellison said at the time. "I mean, I know a lot about in-memory databases. In fact, we have the leading in-memory database, TimesTen. This is nonsense. There is no in-memory technology anywhere near ready to take the place of a relational database. It's a complete fantasy on their part."
Ellison also implied that SAP simply doesn't have the technical chops to deliver on its vision.
"An in-memory database is enormously complex. We do a lot of in-memory database work. It's an enormously complex job," he added. "If they've been working on it for a decade or so, or a couple of decades, maybe they'd be getting close. It's just so absurd that it's very hard for me to comment with a straight face. They should just keep to accounting."
Thoughts
Based on my experiences and background, here are my thoughts on HANA:
- I know 10+ years ago, most customers began their BW implementation poorly; that practice still continues. I know co-workers who asked me how to create a cube with absolutely no background/knowledge on Star Schema or traditional(heard of 3rd normal form data models?) schemas. All they wanted to know was the steps to create a cube using RSA1. Yes, creating a cube is not that difficult using RSA1. They learned that, copied the data model/flow used by others, used BW buzz words to impress everyone, started implementing BW for the customers/employers. I know situations where cubes were copied 1:1 ratio in data mart scenario(Does this make sense?) and then asked Basis team to optimize the data load runtimes from cube A to Cube B with dimension tables as large as fact tables(60m+ records). It seems we're starting to make similar mistake(see (4) below) on HANA.
- Vijay is asking great questions(How much of the game will HANA change?). I agree. Timing of some questions?. Larry Ellison says an In-Memory solution would take at least a decade if not couple of decades. I know he exaggerates. SAP has been working on HANA for probably 2+ years. Too early for scalability, MPP-type questions in my opinion.
- As long as SAP doesn't make serious design mistakes - I'm sure they wouldn't -, it would be easy to scale(or find a way to scale) later once the solution is identified and HANA becomes stable.
- In my opinion, in order for SAP not fall into the trap of the traditional, middle institutions—the systems integrators, I guess SAP needs to come up with innovative ways to identify and train people based on their experience, skills, aptitude, background, suitability, adaptability etc. The quality of people who implement initial HANA projects would play a critical role in HANA's success.
