Skip to Content

How much of the game will HANA change?

As HANA starts on its maturity curve, we as users of the technology need to get a clearer understanding of the potential speed bumps. HANA started as an in-memory data base on which you can build analytical applications. Next up, from November, it becomes an optional DB for BW . And further down the road – it becomes the DB for the business suite, and pretty much everything SAP builds. That is the vision. But just by putting HANA as a database, will we get enough benefits?


First up – how does HANA speed up software apps? It is primarily by making the application’s interaction with database super fast. On top of holding data in memory, in columns, and using insert only deltas – HANA can apparently also do massive parallel processing.


So first thing obviously is to pass a SQL or MDX query to hana that is tuned to how hana works. This is not a simple task – optimizing BW or ECC to pass  queries to HANA in a way that is optimum is quite complex. If you don’t trust me – just expiriment with some of the MDX statements created by BW or BPC to get a hang of it. SAP has steadily improved this for RDBMS with every new release, and going by past experience, they will need some time to make it work for HANA too. I expect SAP to solve this quickly by drawing on past experience with RDBMS.


HANA is considered to be optimized for BI 4.0. That is probably a true statement compared to other tools. But if you see what gets transfered between HANA and BI layer, it is not always very optimized. In some of the POCs, we had to write handwritten SQL and point BI to that, instead of using standard BI functionality. Again, it will only get better with subsequent releases of both HANA and BI. The point is – it is not easy to write generic programs that can generate highly optimized SQL for many different cases.  It is especially harder in HANA’s case, since it is getting a lot of revisions internally too.


Moving on , so what happens when data starts to scale? Say the compressed data cannot fit into one 2 TB box, and several such boxes need to be linked together. Now there is an over head of moving data within memory before it can be used. This scenario can also happen within one box – since not all parts of memory can be processed at same efficiency. So we need to understand all the nuances of scalability too. And this needs to be demonstrated and benchmarked somehow using commercially available hardware from multiple vendors.


Massive parallel processesing can help improve performance tremendously. But Not all applications were written with this paradigm in mind. So if an existing application largely needs its instructions to be executed in a strict sequence – which is normal for several normal applications – then there is not much benefit that HANA can bring to make it better. There is an overhead to constantly allocate and deallocate memory, but probably this can be done in the background without affecting the actual processing of data. I am keen to find out how SAP does this – and hopefully someone from SAP can educate us on this.


What about applications who are already efficient in database level, but are not optimal in say the ABAP layer? There is very little HANA can do in these cases. A lot of ECC transactions were written with multiple tables storing line item and aggregate tables. They probably have optimized DML already. But unless they are rewritten to use a leaner data model, there is only so much that HANA can do to help them. But rewriting a stable application is not an easy thing to do. So most probably SAP will need to keep existing datamodel, and build a parallel schema that can use the power of HANA . This applies to BW and BPC too – a lot of processing happens in ABAP layer.


To net it out – to me, it means two things


1. If HANA’s power needs to demonstrated to the world, SAP and its ecosystem are better off writing applications that are designed ground up in a way that is optimized for HANA.


2. As layers collapse (like how Vishal Sikka explained in his keynotes), SAP has an opportunity to shorten the path to value realization. It needs every part of SAP’s development organization to articulate this in their execution, and that is not easy to pull off consistently for such a large organization.


I am sure that SAP has a solution (or a plan at least) for all of these. We just need to get educated on those solutions and plans.

You must be Logged on to comment or reply to a post.
  • I am wondering when HANA starts to be used in ERP systems.  What will happen to our preformance?  We probably not be taking advantage of all the power with our older programs.

    So I wonder away.  I sat by someone at lunch who said HANA will not work with BI/BW unless the “cubes” are set up correctly.  (Way over the limited knowledge I know.)


    • Hi Michelle,

      This is partly my comment so that I get notified about further comments, but I figured I do something useful and respond to you as well.

      I think there may have been a misunderstanding over lunch 🙂 When BW runs on HANA, all cubes and DSOs will be stored on HANA, so they should all work fine. If I’m understanding the BW team properly, these objects will be stored differently on HANA than they would be on a “normal” database. But from the point of view of the person working on BW in RSA1 I would think there won’t be much of a difference, if any.


  • Hi Vijay,
    It’s very nice blog.
    Just adding to that we have to think two more points. Firstly during start-up, the SAP HANA based system how much time it will going to take for 1TB or 2TB or more into main memory. Secondly if SAP going to provide SAP HANA as database for main memory then what database for Secondary memory / Disk or we are going to use same third party database for disk.
    Rafikul Hussain
    • Rafikul, in fact HANA db is hybrid storage database, i.e. managing 2 data stores: in RAM and in regular storage. SAP as well started socializing the idea of using 3rd party solution (PBS?) based on SybaseIQ as NLS for HANA. I am scratching my head why…
      • Thank you so much for the explanation its cleared some of my points for NOW.
        Regarding the SybaseIQ, as per my understanding, From BOBJ system the data directly execute in HANA but for ERP and any other tool the data will come to HANA environment and the SybaseIQ convert/replicate then only it execute.Correct me if I am wrong
  • Hi Vijay,
    I have been following HANA blogs crazily.
    Hitherto, I have been very optimistic that even if I directly don’t get to experience working on it on real time in near future, it would be used elsewhere extensively.
    But then will all such limitations, how do you expect to convince your partners to upgrade DB to HANA?
    I am also wondering that changing to HANA would be beneficial only if the amount of data is massive and is not for all.Many more discussions to happen.


    • These “limitations” are all normal for a 1.0 version I think. Once SAP clarifies what gets resolved in each release, it should help customers adjust their hana roadmap accordingly.

      Massive amount of data at line item level is definitely a good reason. high speed is another good case. Compression is yet another.

  • Thanks for an insightful blog. I have been looking for valuable, concise analysis of the impact of this new technology for some time (I’m sure I’m not the only one), and it is some times hard to distil much (or any) “hard knowledge” from the sometimes hyped-up writings that seem to be the norm at this early stage.

    I initially understood that HANA is primarily related to BI/BW, but have seen that it is also in the pipeline as an underlying foundation for the entire SAP ERP offering. The paradigm shift this is going to cause, is both interesting and mind-boggling. I’m sure other ABAP-centric developers, like myself, will have very exciting times to come, when trying to grapple with this new technology and how it will impact our mindsets and way of work.

    Thanks again for some very clear and pragmatic points about the way forward for HANA. Definitely the best blog I’ve read so far on this very important topic!


    • Next Gen ABAP will work with ABAP.
      You are completely right about mindset change – developers need to know how best to make use of this powerful engine.
  • Hello Vijay,

    “Next up, from November, it becomes an optional DB for BW.”
    Does this mean the ramp-up of HANA as a database for BW starts in November? I haven’t been on TechEd in Las Vegas, so probably I missed some announcement here.

    Also what about the appliance? Does one need to buy the appliance to use HANA as a database for BW or can we install HANA DB ourselves on (certified) hardware with SLES 11?

    As Rafikul I am wondering how long a database startup of an 1-2 TB HANA instance would take in real life. I believe this cannot be compared to a database startup of a 10 TB Oracle/DB2/MaxDB or whatever RDBMS.



    • Hi Mark

      Yes – November 7th is when it goes into ramp.

      From what we saw in POCs, it does not take a long time to start like with traditional DB. These are all things SAP should benchmark and publish, and I am told it will be done soon


  • Hi Vijay,

    While simply taking an existing ABAP application and running it on top of HANA (as a database) is going to be possible, this approach is really not going to achieve significant benefits over current architectures.

    The true benefits will only come with redeveloping the entire application platform and optimising this for use with HANA.  I was both pleased and surprised to hear confirmation (in session TEC102 at TechEd) that SAP are already developing a new ABAP code-line (currently dubbed Next Generation ABAP) which is optimised for HANA, and will not be backward compatible to existing ABAP servers.

    I consider this a bold, but ultimately necessary move by SAP, as it provides them with an application layer that can truly leverage (and be optimised for) the HANA platform, as well as the opportunity to modernise the entire architecture and provide improved support for standards, APIs and SDKs. 

    In my view, the next logical step is then to start rewriting the existing Business Suite for this next generation code-line, with the expectation that this “next generation” version of SAP will ultimately supercede the current versions.

    Great blog, good questions as always.


    • Where’s the +1 button when you need it???

      Thinking (wildly) out loud, maybe the strategy here to encourage customers off their ‘legacy’ versions of the Business Suite (where legacy = anything not running on HANA & Next-Gen ABAP) by offering the carrot of high-performance, in-memory transactional systems with the cost of what almost amounts to a re-implementation?

      That wouldn’t sounds like such a bad option to me, but I’m not exactly afraid of change either…


    • +1 again…  The game has to change!

      I like the idea of changing into a better language and a faster response time for users.  +1 Sascha, It makes sense to me, that your wild thinking out of the box is true! 

      I have no inside information.  I’m not from SAP.  And I would guess most of the people from SAP have no inside information.  But I agree it will force us to learn and use the new language.  That way everything we write will be faster.

      Ah but there are millions of lines of SAP code out there.  I think the change for that will be slow.  It will take some time to rewrite the code.

      BUT our custom code – well – hopefully we will be able to make it fly fast!


  • Hi Vijay,

    (You might’ve already watched the videos referenced below. Please pardon me if I’m restating the obvious).

    As I understand it, In-Memory solution(end-state) is still in design stage. Source:

    For everyone’s benefit, here is more info on what I learned from the videos posted in

    In one of the videos( titled No Aggregate Tables), Dr Plattner says the new data model for Accounting System will have only two tables 1) Accounting Doc Header and 2) Accounting Doc Items; everything else will be done on the fly(2m50sec in the video). The Configuration tables would be a part of the program(s).

    In another video, titled “Reduction of Layers”, Dr Plattner says “this will be huge if we can pull this off”. I like his modesty and sincerity. Please listen to what he continues to say about caching.

    These videos were posted 18 days ago and grouped under “Trends and concepts in the S/W industry 2011 – In-Memory Applications”.

    It seems SAP is still working on the solution. Am I wrong Vijay?

    Best regards,

  • Hello Vijay,

    I try to follow up on HANA content as I consider it a very important pointer for me as a #sapadmin for my future SAP career. I’m eagerly awaiting #sapteched Madrid to get my hands on it HANA administration.

    What I’m wondering is how long will it take before HANA will become the database for Business Suite.

    If you would have to believe the new SAP (innovation, collaboration, faster sw life cycles etc) one would expect it should better be there sooner than later but I haven’t really seen any prediction.

    Any idea when we could expect to see this, in a year or rather in five years or?

    Kind regards


    • Hi Tom

      I actually have no idea – but I sure hope it does not take 5 years for SAP to get there. Maybe in one of the upcoming SAPTECHED events, Vishal might make the announcement


  • Hi Vijay,

    Thanks for sharing your thoughts. Reading through your very valid concerns, I am glad you’re not the first one having those thoughts. However, I have never seen it expressed in such clarity – thanks!

    You blog makes me wonder why no SAP HANA experts have commented so far – so let me (certainly not a HANA expert but with some insight) share my $.02

    As discussed further down in the comments section, the HANA roadmap foresees BW running on HANA by beginning of November, and further down the road we want to run ByDesign, the Business Suite and pretty much every SAP application on HANA.
    Right now HANA is available as this super-fast database (you very nicely outlined the combination of technological advancements that all together make it so fast). Optimized for BI 4.0 as consumption toolset (yes, we’re not fully there regarding the optimization, but getting better at a high frequency. So high that people complain about HANA DB updates every other week…), and with real-time updates from SAP backends via SAP Landscape Transformation replication. A very promising solution for operational reporting already now.

    So what’s the deal with BW on HANA. The obvious first step is to migrate your BW database – instead of database xyz, you’re now running on HANA DB. Thanks for the optimizations my colleagues build into HANA and BW (you’ll need BW 7.3 to run on HANA), you will most likely experience a slight performance increase as compared to your current solution. Slight??? Did I say “slight”??? Why bother then?
    Because that’s just the starting point. The non-disruptive part of the evolution.
    You are basically doing the same thing – periodic extractor runs to get data from ECC into your BW ODS. Periodic flushes of the ODS into your InfoCubes. Periodic calculations of aggregates. And then periodic refreshes of your BI dashboards, reports or whatnot. Powered by in-memory technology, all the steps should be faster – but the path to dramatic improvement only starts here.
    Following your own priorities as a customer, you can now cut out the aggregates – HANA can aggregate numbers at extremely high speed, no need to pre-calculate. You can also think about replicating the data in real-time instead of waiting for the next extractor job to run. Along you own priorities, you can increase the recency of the data you’re reporting on from several hours (if not days) down to – instantaneously. And the cool thing about BW on HANA is that nothing will have to change on the consumption side and you can do it at your own pace. The change under the hood is non-disruptive (I think I mentioned that before. Or maybe that was Vishal. Or Hasso. Or maybe all of us in reverse order).

    Having said that, yes: there is a lot of work to be done regarding optimization. And I think that’s a good thing. HANA is pretty fast right now, it feels good to know there’s even more potential 🙂

    Now, the Business Suite. You’ve said it, Jon said it in his comment and others said or thought it, too. By putting your transactional system onto a super-fast in-memory database you gain pretty much nothing. SAP has become so good at offloading the database that it’s no a bottleneck. And where’s no bottleneck, there’s not a lot of optimization potential. So what is the deal here?
    SAP has already started to re-write performance-critical tasks, optimized for HANA. Yes, this is pretty much a from-scratch programming of existing functionality. To make good use of HANA, you have to get with of these

    SELECT * FROM db_tab INTO itab.
    LOOP AT itab INTO rec.

    You have to push expensive processing down to the database, and that’s what our colleagues are doing. I guess if you name a random long-running batch job (Dunning was Hasso’s first example two years ago), there’s probably a team at SAP working on this batch job already now. If not, thanks for pointing us to it.
    Next generation ABAP will be optimized for HANA, but for the SDN community, I don’t think NGAP is all that important yet – it’ll be quite a while until that will be introduced in the business suite. What is important, though, is to think how you can structure your logic to push more of it into the DB. So even with the “same old ABAP”, you have to program differently and we all should get ready for that. Yes, that includes you, Michelle 😉

    Long comment. Maybe I should have written my own blog post instead. Whatever, let me finish by agreeing with your summary:
    SAP has to demonstrate that HANA is worth the effort of educating yourself in a new way to do ABAP and re-writing existing programs for HANA. And we accept the challenge!


    • Hello Jürgen,
      that sounds like a great idea! Yes, please write a blog post of your own. And thanks for providing additional insights to Vijays fine blog.
    • Hi Juergen,

      Thanks for providing additional details.

      Are there two(or more) HANA development teams to meet short/mid and long term goals? Identifying and rewriting every(or did I misunderstand Dunning example?) long running job appear to meet short/mid term goals. Rewriting the application using a new data model(2 tables for the accounting system) would meet long term goal. This(rewrite) would automatically take care of long running jobs, isn’t it?  I’m slightly confused with the approach to rewrite long running jobs.

      Or SAP has identified a list of activities/tasks(20 or so as Hasso pointed out. ex: reduction of layers(caching layer), no aggregate tables etc ) to reach the end state of HANA;is rewriting every long running job one of them?

      I really like SAP’s openness and willingness to share their sincere/modest thoughts on HANA not just here in SCN but elsewhere(HPI, etc). Just incredible I can hear Hasso’s technical opinion directly from him on things that matter to me::).

      Best regards,

    • Hi Juergen

      First off – many thanks for commenting, especially wonderful since you took time off from vacation to do so. I was quite surprised that no one from SAP bothered to comment, when the general trend is to retweet and comment like crazy if HANA is mentioned anywhere online 🙂

      And I do think you should have written your own blog. Scratch that – you should write a few going forward. You play with all the new toys before any of us do, and we will be very grateful for your insight.

      Now on to your comments – I am in general agreement.  I have some additional questions after I read through your reply.

      1. What specifically is SAP doing to the code base to make it HANA friendly? Are these things that BW developers should know, so that they design accordingly when they implement 7.3 ?
      2. As data increases – is there a way to pass hints to HANA to query in a certain way? Plus when will SAP explain the details on how hana scales?
      3. Will there be a utility in BW 7.3 that can point developers on what needs to be done to make an existing datamodel and dataflow hana friendly?
      4. Will code inspector in NGAP change to give tips on how to make code hana friendly?

      I will stop here, and leave something for the conversation at Madrid

      Many thanks again for chiming in.


    • But what a fun journey it will be!  I’m so excited! 

      I believe the old shouldn’t be forgotten.  I can’t believe that some of the same “old” ABAP won’t have pieces that will work with Hana.   There will always be some “old” tricks to use.  And some new ones to find.  But I won’t debate you until I see it.

      The new ABAP that is coming!  Or whatever you want to call the language.  I can’t wait.  Bring it on!  I’m ready today….  Next week…  Next year… ahhh… next millennium?

      Um – when was that going to change again? 🙂

      All in good fun!


      I really am excited about the new stuff.  And even though I’m being a little … I do wonder when we’ll get to see it and what it will look like.  I can’t wait to see a blog detailing what the new logic will look like.

      It will be interesting where now we avoid DB processing.  In the future we will use a lot of “DB” processing which is really processing in Hana.  At least that’s how I think about it.

      And then I think about the 1000s of programs out there.  Maybe add a couple of zeros.  And then we have to decide what should be changed, and what can be left alone for a while.  I know we probably can leave all of them alone and they just won’t take advantage of Hana.  Or there may be a tool that we can use to help point to areas that should be rewritten.  I’m wondering about SAP code as well.  I just talked about a lot of this with a co-worker.  She’s says that she is thinking she’ll be retired in 6 years.  (And that Hana for ABAP won’t be her in that time.) 

      Darn it Juergen!  You have me writing a book now!  Please blog, and let us know what’s going on.

    • Hi Juergen,
      I have a probably obvious question to your post. I understand that for BW 7.3 SAP will support HANA and also traditional databases, and I assume that this will be the same for ERP. But the ABAP optimized for HANA will not perform well on a traditional DB. Will we end up having two ABAP codes doing the same thing, one optimized for HANA and the other for DBs?
      Thank you to everybody for the interesting blog and comments
      • Valentina, you can have a look at good post by David Hull at

        BW has had forks in the code based on the database for a while already: specific calls depending on DB2, MS SQL etc. Then with BW 7.30 there were additional forks included into the code – for Teradata and HP Neoview support, where DSO activation is different depending if regular or MPP databases are used. Now HANA will add just additional branch in the forks.

  • Vijay:

    Awesome post as always…you need to give me some blogging tips -;)
    I have read a few about HANA, so you’re blog really helps me to have a better picture…thanks for that…
    And for NGAP I was lucky to see a small part of it while at DKOM Montreal…and I can say…damn! I want to start developing on that -:) Hope to soon have a NGAP Sneak Preview here on SCN…

    So, just to add something a little bit useful…I agree…SAP would need to change a lot of things to make customers and us to get the full of HANA, otherwise it would be just a waste of money and effort to have something that it’s going to speed things up just a little bit…but being NetWeaver as huge as it is…I don’t see it coming too soon…you can still find pretty old code in NetWeaver or R/3…


    • Thanks Blag. You know I am a big fan of your blogs and comics too.

      NGAP excites me too – and I am pretty excited to see ABAP talk to HANA. I actually think the demojam entry that offered an opportunity of using HANA already, was quite nice and deserved a shot at placing in top 2.

      In my opinion, SAP wasted an opportunity by not giving this option sooner. A big part of SAP developers in the ecosystem is ABAP friendly. And sitting them out of the hana deal till some day in future is unfortunate

  • Hello Vijay,

    that’s a great blog and a very good summary of questions I do get in my meetings as well.

    I am heading the project team who builds up the BW powered by HANA infrastructure within SAP and for the future reporting and planning scenarios within SAP. No prototype, no demo solution – the real architecture to run company business on it.

    See also this blog: Corporate scale SAP Business Warehouse powered by SAP HANA

    But our new architecture does not ‘only’ have BW on HANA, but also ECC and CRM by-side HANA. In this most complete new environment – together with a new BI 4.0 platform – we did proof in the last months that we can build amazing new BI scenarios for our SAP internal business users.

    My next blog will be ready on Monday. I will share more details on the planned architecture and insights in a HANA-BW-BI business scenario.

    All the software components I do use today will be available in ramp-up in November.

    For me it is amazing to see what I can do with this architecture already today – after 10 years BW experience.

    I am looking forward to continue sharing our project experience.

    Matthias Wild (follow @MatthiasWild on Twitter for frequent infos)

    • Hi Matthias,

      Thanks for chiming in, and for the link to your blog. I will start following you on twitter too.
      My handle is @vijayasankarv

      Looking forward to your next blog