2011 was when HANA hype was on over drive – it was along the lines of “HANA will solve world hunger by feeding entire generations on perceived future business value” . Every where I mentioned HANA, customers were pushing back with raised eyebrows. That did not stop SAP from selling HANA though. SAP customers do not typically buy licenses piecemeal – they buy a basket of stuff, and apparently HANA was in a lot of baskets, especially in the last quarter. This is not unusual buying behavior – it is the norm.
And then 2011 ran out. When I came back from vacation, I was amazed with the demand for big ERP projects. And right on its heels, came demand for HANA projects. Not isolated demands – many customers, some of them VERY big names – are now sufficiently intrigued to start pilots for HANA. To say the least, it has taken me by surprise – the pleasant kind.
There is a huge amount of misinformation on HANA that has been spread knowingly or unknowingly in 2011. I think the first half of 2012 will be spent setting expectations straight.
A very common scenario I am running into these days is customers that have custom built data warehouses in Oracle or SQL Server. These have thousands of Stored procedures etc. They want to find out how to migrate this over to HANA. Or more specifically – they want to know if there is a way to semi-automate the conversion of SQL of existing solutions to HANA’s SQL. If they cannot do that – the cost of re-inventing the solution in HANA from scratch is not something they seem to have an appetite for. I have pinged SAP to ask what they think about this. If you know the answer – please post a comment.
Another common question – “so we buy HANA as a datamart, then put HANA under BW as DB, and then under ECC – will this all sit in one appliance? do we need to buy more and more licenses and hardware?”. So far I have not had to explicitly answer this question. Funny enough – they look at the expression on my face and deduce the right answer magically 🙂
Basis experts invariably ask me “hey can we virtualize HANA? Can you put it on a cloud and offer us as a service? When will SAP support non-intel processors and other OS? ” . My answer usually is to point them to existing documentation. If they persist, I show them the installation files and how it can be hacked. That is the best way to deal with techies , right?
Landscape Sizing, HA and DR are all high on CIO agenda – they just want assurances that they can safely deploy this in production. This is a lot more easier now to answer than even a few months ago, since there are more options available, and we have more experience with sizing. This is also where people start getting an idea of the real cost in putting up a HANA system – and there is always an aha moment.
The other half of the aha moment comes from clients understanding there is no one HANA consultant who makes the system stand up and work. SAP started off by saying “HANA is an appliance” – and that is partly to blame for this. An appliance is like a fridge or a wireless router – you buy from a store, bring it home and it starts working after it is powered on with very few instructions. HANA is not a true appliance in that sense- and once customers get that, they realize it is like every other project. HANA needs multiple skills to pull off successfully – data modelling, BOBJ, Admin/security, ETL etc.
BW on HANA has captured the attention of several customers. SAP is doing a good job pushing it in the field. I met several field sales people at FKOM, and was amazed to see how pumped up they are to sell HANA. But more than BW itself – a lot of customers are waiting for BPC to work on HANA. I was not very pleased with the BOBJ integration with HANA initially, but it has improved and I know more improvements are planned. It is best for SAP to nail it before customers start several projects in parallel and stress out SAP support.
Many of my customers – and me too – are waiting eagerly to see how many companies will SAP parade at SAPPHIRE as live on HANA , especially for the BW case. If SAP shows a large number of customers on the key note stage, then we should have a great HANA year in 2012. Towards middle of the year, I think many more HANA projects will start – and not just small pilots. And If SAP does come out with ECC on HANA by end of the year, it will be an excellent shot in the arm. 2012 could well ramp into a terrific 2013 for HANA.
And Vijay Says... 
such a nice explanation about SAP
LikeLike
Especially on sap hana admin. The info you provided is very useful for any interested on sap. I am very much satisfied with your info.
LikeLike
Your blog was excellent. Posted best topics for the readers help them to get to know things. Also helps the readers to choose the better career.
LikeLike
I wish I can get furthered info from you.I am very glad to say thanks for this info.
thank you very much sir
LikeLike
I do not even know how I ended up here, but I thought
this post was great. I do not know who you are but certainly you are going to a famous
blogger if you aren’t already 😉 Cheers!
LikeLike
This article info was so nice. which is very useful for me and impressed by reading.Your information is very hep full to SAP HANA ADMIN Learners. we are providing the best SAP HANA ADMINISTRATION ONLINE TRAINING with experienced IT Faculty.
LikeLike
SAP HANA is superr
LikeLike
HANA is NOT a key innovation – it is marketing hype.
The core idea of throwing things in RAM to make them run fast is legit.
In memory DBs already exist, as do columnar databases.
HANA is for OLAP (datawarehouses) only.
It is NOT currently for OLTP, and replacing DB2, SQLServer, SyBase, MySQL or Oracle is marketing Hype.
Several alternatives exist for OLAP and Big Data.
LikeLike
You can find it by using the search on what is sap
LikeLike
The article about SAP HANA was awesome.I have a few questions related to SAP HANA sqlscript version2 …
1) What is the difference between normal sql and sap hana sqlscript?
2)differences between operator logic and orchestration logic in sqlscript v2?
3)what is an sql wrapper in sqlscriptv2?
4)what is a node in sqlscriptv2?
5)what is a projection in sqlscriptv2?
6)what are programmable containers in sqlscriptv2?
7)can u give an example for the questions below?
1.) “The decision on the transformation of a single-node data flow graph into a more structured data flow graph containing several operations that can be potentially executed in parallel depends on the used SWLScript v2 language features. To transform the logic into a complex data flow graph, the prerequisites have to be met:
a. All data flow operations have to be side-effect free, i.e. they must not change any global state either in the database or in the application logic.
b. All control flows can be transformed into a static data flow graph.”
2.) “Parallelization will be achieved in two ways: operator and data parallelism.”
LikeLike
Please ask this in the Hana forum in sdn , and someone from sap will give u answers.
LikeLike
Great post. Congratulations.
Stefan
LikeLike
thanks Stefan – glad you liked it
LikeLike
Thanks for the great HANA posts!
LikeLike
I have converted many stored procedures to using set theory over the years. I had one last year in a Sybase IQ POC that took way longer then it should have to convert but in the end the run time after the initial port was 8 minutes in Sybase IQ vs 40 hours. I have used Swiss SQL some in our IQ POC’s to help with SQL conversion…. Oracle Decode -> ANSI case statements. The problem with all the code people have is no one even knows what this stuff does and how it works they ask for you to port it but they have no clue what it does. This should be a fun year after working with IQ since 1996 I am ready and eager to get into HANA.
LikeLike
Yes indeed – many people are afraid to touch old code because no one is sure what all will break if you do.
But porting by hand for 1000s of stored procs is a HUGE initiative, and makes me wonder how many will bite the bullet.
There should be a half way smarter option for this
LikeLike
If it is just changing syntax it is possible once you are into changing the logic that can be a bit more difficult. This mess got built up over time and it will take time. I think the best approach is to start with some key business processes and innovate out of the mess. It is a real mixed bag out there you look at some stored procedures they are well written and easy to adapt and convert others are old and fragile and have been modified many times these can be more difficult because the logic is obscured. If you have not seen the Swiss SQL product it can be a really big time saver, they have a web page that shows some of the capabilities http://search.swissql.com/oratosql/ in the GUI windows tool it is interesting to paste in SQL and see how it converts the statement for the different databases.
LikeLike
The approach I would take is to do a basic fresh design of where you want your calculations etc to reside, some will reside in HANA and other not for best performance and customer usage. From there try to leverage your old code as least from a logic point of view but I would not suggest just porting it over-you will not get the best solution long-term most likely.
LikeLike
I agree – but starting everything from paper for a mature DW is a long, time consuming exercise with lot of $$ needed.
That is the crux of the issue – is there a way to automate/accelerate part of the work?
LikeLike
Very valid point about the stored procedures. However, key point to note here is that SQLScript of SAP HANA is specialized and optimized for analytical processing of mass data which is stored column based.
There are fundamental differences in the concepts of stored procedures which are implemented in traditional relational databases and SAP HANA Database. For example, in a traditional database stored procedure, there will be use of cursors for processing data.
However, SAP Recommends not using cursors in SQLScript. Because this extended SQL is meant for processing data in sets. To be more precise somewhat like an Object Oriented SQL.
Ideally you should be able to draw the logic on a paper using a simple flow chart, without loops. It will definately be required to convert the old stored procedures to new SQLScript so that complex calculations can be executed by Calc Engine rather than row based relational engine.
However, i am not sure if SAP will come out with some utility to automatically convert them or atleast some help in expediting that process.
LikeLike
The more optimized DWs have mostly stayed out of cursors from what I have seen. They generally make use of sets.
Maybe people will only migrate over partly – just the high value cases, instead of a complete migration
LikeLike
As per my understanding, HANA fully supports open SQL. So any scripts written in open SQL should be working fine in HANA. But if we want to get maximum benefit from HANA, we should use HANA calculation engine (CE) functionality.
But, not sure of HANA supporting oracles/MS native SQL. But any third part tools, which can convert native sql to open sql, should be good to some extent.
Complete conversion of native SQL to open SQL using tools, might not be possible, as some of the native SQL functionality is specific to the database.
LikeLike
If HANA catches on ISV imagination, I guess someone will make tools to help with conversion. I doubt if SAP will do it themselves .
LikeLike