Skip to Content

The BW – HANA Relationship

With the announcement of HANA*, some customers, analysts and others have raised the question on how HANA relates to BW with a few of them even adding their own, home made answer in the sense that they speculate that HANA would succeed BW. In this blog, I like to throw in some food for thought on this.

Currently, HANA’s predominant value propositions are

  • (i) extremely good performance for any type of workload
  • (ii) a real-time replication mechanism between an operational system (like SAP ERP) and HANA

Let’s match those for a moment with the original motivation for building up a decision-support system (DSS) or data warehouse (DW). In the 1990s, a typical list of arguments in favour of such a system looked like this:

  1. Take load off operational systems.
  2. Provide data models that are more suitable and efficient for analysis and reporting.
  3. Integrate and harmonize various data sources.
  4. Historize – store a longer history of data (e.g. for compliance reasons), thereby relieving OLTPs from that task and the related data volumes.
  5. Perform data quality mechanisms.
  6. Secure OLTPs from unauthorized access.

Installing a DW is typically motivated by a subset or all of those reasons. There is a particular sweet spot in that area, namely a DW (e.g. an SAP BW) set up for reasons 1. and 2., but with all the other arguments not being relevant as it is connected to basically one** operational system (like SAP ERP). Here, no data has to be integrated and harmonized, meaning that the “T-portion” in ETL or ELT is void and thus that we are down to extraction-load (EL) which, in turn, is ideally done real-time. So value proposition (ii) comes along very handy. Critics will argue that such systems are no real data warehouses … and I agree. But this is merely academic as such systems do exist and are a fact.  So, in summary, there is a good case for a certain subset of “data warehouses” (or reporting systems) that can be now built based on HANA with (i) and (ii) as excelling properties – see the top left scenario in figure 1 below.

Now, will this replace some BWs? Yes, certainly. In the light of HANA, a BW with a 1:1 connection to an ERP might not be the best way anymore. However, will this make BW obsolete in general? No, of course not. As indicated above: there is a huge case out there for data warehouses that integrate data from many heterogenous sources. Even if those sources are all SAP – e.g. a system landscape of multiple unharmonized ERPs, e.g. originating from regional structures, mergers and acquisitions – then this still requires conceptual layers that integrate, harmonize and consolidate huge volumes of data in a controlled fashion. See SAP NetWeaver BW: BW Layered Scalable Architecture (LSA) Building Blocks for a more comprehensive discussion of such an approach. I sometimes compare the data delivered to a data warehouse with timber delivered to a furniture factory: it is raw, basic material that needs to get refined in various stages depending on the type of furniture you want to produce – shelves might require less steps (i.e. “layers”) than a cupboard.

Finally, I believe that there is an excellent case for building a BW on top of HANA, i.e. to combine both – see the bottom right scenario in the figure below. HANA can be seen as an evolution of BWA and, as such, this combination has already proven to be extremely successful: Understanding Query Performance in NW BI and BIA have been in the market for about 5 years, SAP BW 7.3 beta is available albeit mainly focusing on the analytic layer of BW (in contrast to the DW layer). When you continue this line of thought and when you assume that HANA is not only BWA but also able to comply with primary storage requirements (ACID etc.) then the huge potential opens up to support, for example,

  • integrated planning (BW-IP): atomic planning operators (used in planning functions) can be implemented natively inside HANA, thereby benefitting from the scalability and performance as seen with BWA and OLAP and also from avoiding to transport huge volumes of data from a DB server to an application server,
  • data store objects (DSOs): one can think of implementing such an object natively (maybe as a special type of table) in HANA, thereby accelerating performance critical operations such as the data activation.

This is just a flavour of what is possible. So, overall, there is 4 potential and interesting HANA-based scenarios that I see and that are summarized in figure 1. I believe that HANA is great technology that will only come to shine if the apps exploit it properly. SAP, as the business application company, has a huge opportunity to create those apps. BW (as a DW app) is one example which has started quite some time ago on this path. So the question on the BW-HANA relationship has an obvious answer.

* High Performance ANalytic Appliance
** The case remains valid even if there are a few supporting data feeds, e.g. from small complementary sources.

potential HANA scenarios
Figure 1: How HANA can potentially evolve in existing SAP system landscapes … in a non-disruptive way.

potential HANA scenarios
You must be Logged on to comment or reply to a post.
  • This blog certainly answers the scope of HANA and BW. And thank you for this blog. Your blog supports there is a time and a place for everything.
    What are your thoughts on stories that either HANA or HANA type DB(in-memory) replacing OLTP systems thereby replacing BW systems? I even heard stories that-in order to deliver this solution in non-disruptive way(buzz word these days)-SAP will come up with some kind of an abstraction layer which could distinguish a SQL statement written for traditional RDBMS from one written for columnar in-memory db. And this abstraction layer would-according to those stories-automagically convert RDBMS-SQL statements to columnar in-memory DB statements so no migration to columnar in-memory DB would be required(great vision;since I'm a little bit cynical type, would this be cost-effective?, I'm wondering. Those stories also suggest in-memory DB would eventually replace BW systems. Your thoughts?

    Thanks once again for writing this blog validating my thoughts on the scope of HANA and BW.

    • Hi Bala,
      I find it hard to follow some of the rumours you cite above. Do they make sense to you? Maybe I'm simply lacking the wider context in which they were sifted.
      • Hi Thomas,

        No, they don't make sense to me. I read those rumors in, comments to blogs etc). They appeared sometime after Sapphire '10. Since I didn't attend Sapphire '10, I didn't know if they were based on SAP's statements or not. At any rate, you've answered my question. Thank you very much.

        Best regards,

    • Hi Vitaliy,
      the side-by-side scenarios will work with v1 of HANA, due end of this year. The other two are further ahead but have already been publicly mentioned at SAPPHIRE and Teched.
      The above is no official roadmap but simply intending to put stuff into a logical context independent of time.
      I hope this helps at least a bit.
  • Hello Thomas,

    thanks for the blog, it helps understanding what HANA can do or in the near future will be able to do. However, I am really wondering who on earth
    would implement this "agile data marts" scenario.
    I know many BW customers who are in desperate need of a BWA (because of horrible BW query response times), but refrain from buying a BWA. And of course there is only one reason not to
    buy a BWA. So I wonder who on earth has the money to buy a BWA and HANA?

    Maybe time will fix this. Once SSDs are getting cheaper, the reasonable way to proceed might be
    to put the "X DB" on SSD until SAP makes the BWA (or HANA) affordable. Not my preferred solution,
    but economics might dictate this way.



    • Hi Mark,
      putting price considerations aside: the "agile data mart" scenario does exist today: replace HANA by any commercial RDBMS. Actually, they exist all over the place. The motivation frequently is that such an "agile data mart" is controlled by a business department rather than IT. The latter needs to run the BW (EDW) along rules like SLAs, compliance, company-wide consistency etc. and are therefore less flexible to implement or change models in an agile way. However, a marketing department (that decides to initiate a new campaign today) might want to create a cube to track that campaign and that might be 3 weeks down the road.
      So, in summary, an "agile data mart" is a place that technically might run a similar workload to the EDW but that is managed in a significantly different way.
      Also, you can look at HANA in that particular context as a competitor to an arbitrary RDBMS.
      You are certainly right that there is always a price component to this as TCO increases. Obviously, the benefits (of the gained agility) need to outweigh that additional TCO.



  • Blades are not cheap - so I wonder if a significant portion of the SAP instalbase can make use of HANA. Sure the top 100 or top 500 might have the CAPEX budget, but what about the rest?

    Also, why would I need to maintain BW and HANA in future. Why shouldn't I expect HANA to do everything that BW does (and then some), so that I don't need to keep multiple systems for similar purposes?  If BW cannot be phased out some time in mid term, I wonder if HANA will delver on its full potential.

    • Hi Vijay. SAP HANA in the first version is not targeted to BW customers, but to ERP customers without BW (left top quadrant on Thomas's chart) as an "real-time" "fast-performing"
      analytics with "agile modeling" for business users. As such the value proposition is really appealing, and the question is exactly the one you raised - what would be the ROI of this solution. -VR
    • Vijay,
      w.r.t. comment on phasing out BW via HANA: HANA is basically a DB, i.e. pure technology. BW is a DW management application sitting on top of a DB. So it's apples and oranges. Likewise, a pure Teradata installation is not a DW as you have to complement it with programs and tools that manage semantics, data containers, mappings, processes, consistency mechanisms etc.
      There is a good use case for replacing BW when most of this constitutes an overkill - see Vitaliy's comment or the paragraph in the blog on operational data marts.


  • I found the concerns/thoughts that "HANA will replace BW" similar to "creating a reporting system on top of PSA only". It's technically possible, but would you do it?
  • This is probably covered somewhere amongst the recent blogs about In-Memory and HANA, but I couldn't clearly pick it out.

    I don't have much experience with the newer flavours of BI/BW yet, so please forgive my noob questions 🙂

    If I was a customer just running ERP Financials/HR and maybe SRM could I use HANA as the platform for my analytical reporting, instead of BW?

    In addition to the appliance, what are my reporting toolset options?  Business Objects only?  If so, which ones will work with HANA?

    And lastly, when will all this actually be available to customers?  

  • Thomas,

    Thanks for this. A couple of comments/questions:

    1. "I believe that HANA is great technology that will only come to shine if the apps exploit it properly." - Absolutely agree, just hope SAP sales really understand this 😉 How is it possible then to separate out what business scenario does HANA supply and which does BW supply? If "(i) extremely good performance for any type of workload" is true, then why doesn't it replace every scenario which BW is used? I do believe value prop (ii) is a very valid case of which no current SAP solutions exists (RTA and hourly loads aren't real-time).

    Maybe a value-prop matrix might make sense: (correct me if I'm wrong here)

    Value prop (i): Evaluate whether HANA or BW is needed based on business logic requirements.
    Value prop (i+ii): Use HANA
    Value prop (ii): Use HANA (but restrictive in the sense that you only see the individual business tables..i.e. no extra logic)

    2. I'm trying to understand where HANA might replace BW ... Let's say you have a current BW system and one of your business areas is FI-CO (vanilla FI-CO data extracted from ERP and using BI CONT to bring that data to a reporting layer). Would a HANA appliance be a suitable replacement for such a scenario? If so, what are you trying to offer as a lowered TCO? Since this scenario is very vanilla (read-> relatively easy to implement) then wouldn't installing a BWA in the existing structure be much easier and satisfy all requirements (functional and performance). Plus gives you the flexibility in the future to add some additional business logic you want later...OR is this what you mean by putting BW on top of HANA, so that if you wanted to extend something later you have the ability to do so via BW?

    3. Since BWA is not ACID compliant (AFAIK), what is different in HANA that makes it ACID compliant? Maybe too techie of a question for a simple answer 😉

    4. I'm not sure why this hasn't been mentioned in discussion yet, but what happens if the appliance turns off? Isn't data stored in RAM?

    -Michael Bestvina

    • Micheal,
      Based on the limited information available about HANA today, I tend to agree with you that "BW+BWA" is more flexible solution for performance problems unless you have to have real time data.

      Let's use your FI-CO example; as we know almost nobody uses SAP delivered content 100%, so we make some custom changes in user exits, start routines, DTPs, FMs etc. Personally I prefer to customize the reporting system(BW) then the transactional system(ERP).

      Another reason to keep the "BW + BWA solution" is, it is easier to bring data from all other non-SAP ERP environments to BW then to ERP.

      For these 'practical' reasonons I believe the best solution will be "BW 7.3 + BWA 7.2". With BW 7.3 OLAP will be accelerated, DSOs, master data reporting will be supported by BWA etc. But I am very optimistic and excited to see what HANA 1.5 (for BW) will offer.

      Lastly, when it comes to creating "practical" business cases for HANA 1.0 (except providing real-time data), wouldn't it be unbelievable to have ad-hoc reports on top of CDPOS and CDHDR tables(ERP change logs)?


    • Hi Michael,
      I try a brief answer - you have raised many good points and they are all worth a comprehensive discussion.
      Ad 1.: I think Tansu has provided some good points here.
      Ad 2.: You are already speculating in the right direction.
      Ad 3.+4.: In-mem databases store the data also on disk. That provides the "D" (durability) in "ACID". The idea is that RAM is leading and holds the data in its original version while disk keeps snapshots + logs (to recreate the recent state from a snapshot). In traditional RDBMS it's the other way round: RAM caches "blocks" ("pages") of data, basically as a 1:1 copy from disk. So the disk structure is leading.
      The term "in-memory" has been heavily used by marketing and sometimes oversimplifies things. One group argue that the disk-based RDBMS use huge RAM caches (so they are in-memory too) while the other group says that in-memory DBMS have disks which comes sometimes as a surprise. Wikipedia has a good introduction on this.

      I hope this helps.


      • Thomas/Tansu,

        Thanks for the information. I'll carry the discussion on with some of your dev colleagues in the next comings weeks. It will be important to completely understand this from the perspective of sales, value prop, support and consulting.

        Ad3+4: Thats what I speculated, but wasn't completely sure. This is where MaxDB fits in then right?

        @Tansu - Long time no see 😉


    • All,
      About HANA replacing BW - I think people are not worrying about losing BW, but rather losing its capabilities that can't be found in ERP systems.

      Maybe we should list them for HANA architects to consider developing them for future releases.

      There are some obvious reasons that we prefer having BW such as
      * extracting and consolidating data from different source systems
      * one master data/one truth
      * be able to cleans and/or manipulate data while extracting data in user exits, etc.
      But what else? Here are some minor but important things to be considered
      1) Time-dependent master data reports
      2) Non-cumulative key figures/cubes-now ERP systems have to handle this
      3) Information broadcasting/data bursting reports?

  • - Hana is an appliance but in all the above figures I see that HANA is going to eventually become the underlying database ( In Memory ).
    - In BWA technology failover is DB what will be failover in HANA
    - How long will it take to make HANA stable and robust enough like an RDBMS today.
    - Will the in memory technology help even if the data model is bad.
    - Data Life cycle management - How will the archiving work?( will it require another HANA for backup or archiving )
    - Disaster Recovery -> Is it ready.

    So far whatever has been advertised about Hana, it does not seem to do any other function other than accelerating data.
    What is so different about HANA and BWA ( apart from the blades and software and OLAP + OLTP capability )

    • Sanjay, ideally questions should be posted at the forum: SAP HANA and In-Memory Computing

      Some of the answers where already covered, so I put just links there.
      - Hana is an appliance but in all the above figures I see that HANA is going to eventually become the underlying database ( In Memory ).
      VR: Please see for distinction between HANA and its database
      - In BWA technology failover is DB what will be failover in HANA
      VR: In BWA failover is to another blade; same is going to be with HANA - fail-over to another node (rack or blade - depending on the used)
      - How long will it take to make HANA stable and robust enough like an RDBMS today.
      VR: HANA is built on existing technologies: MaxDB, TREX, P*Time, Sybase and inherit many of the existing features. Nevertheless it is a new product, so let's see.
      - Will the in memory technology help even if the data model is bad.
      VR: Please have a look at point a) at
      - Data Life cycle management - How will the archiving work?( will it require another HANA for backup or archiving )
      VR: Future release of HANA should include data aging functionality: hot data - in RAM, cold data - on disk
      - Disaster Recovery -> Is it ready.
      VR: You mean ready for 20 Dec 2012? ;-)))

      • Hi Vitality,

        You are Guru. I was not expecting the crisp and solid answers. Thank you very much. I am a newbi so far HANA is concerened. But will keep a watch. I read your other blog and so nicely written from context to content. Hats off to you.


        • Hi Sanjay. If I am Guru, then the end of the world is closer than I expected ;-))
          Thanks anyhow for reading my blogs and sharing your positive experience.
          Good night. -Vitaliy
  • Hello Thomas,

    Thank you for the excellent article.
    however , there is one question on my mind which is unanswered.
    How abt managing security for the data already loaded into the RAM ?
    or in other terms , what is the authorization model that we are looking at for HANA ?


    • Hi Ramesh, data is stored in memory, but still accessed by applications through standard interfaces, like SQL or MDX. All security in applications (BW, SBO BI) and at SQL level still apply. Is there something else that I miss, but that makes you worry?
    • Hi Ramesh,
      HANA provides a security concept. This concept will apply when data sits in RAM or not. It's like with any other DB.
      HANA will provide standard SQL-like concepts but also concepts that originate from an analytic contexts (where - eg - security is frequently based on hierarchies within a dimension).
      I hope that this answers your question.
  • Hello Thomas,

    Article is very informative and clarifies many questions. However I've an unasnwered question which is related to the existence of BWA and HANA in parallel! We already have BWA installed (from last 3+ years)in our landscape and if decided to go for HANA will it be possible to eventually replace BWA with HANA!
    I would appreciate if you can enhance Fig 1 with
    BWA scenario!

    Bala Koppuravuri

  • Hi,

    Great article and insight. I do have 2 questions, thanks in advance.

    1, For an environment running SAP Business Warehouse (BW), can HANA be installed on the same box…or does it need a dedicated box?

    2. For non-SAP sources, can that data be accessed real-time?  For instance, if an Oracle DW already exists, can that data be brought into HANA real-time, or is it a batch move from the Oracle DW to the HANA box?  If it can be accessed real-time, what tool is used to handle the real-time data feeds?  For this same scenario, does an initial data load need to be done and then is Change Data Capture used to bring small message packets to bring any changes that are applied on the Oracle DW?


    • Hi Derek. Here are my answers, but keep in mind that HANA things are changing faster than me typing.

      1. You will not install HANA db on existing BW installation. Instead you will need to do OS/DB Migration for BW from existing database to HANA as the target database. HANA db comes only on certified hardware configurations, so the proper question will be "Will you plan to put BW app server on the same box as HANA db?" There is no answer to this question yet - at least from me, as HANA 1.0 SPS3 is not yet released.

      2. If it is Oracle DW (and not Oracle db under SAP ERP or CRM) - you can use only ETL-based load with BO DataServices. I heard from SAP Solution Management about plans to extend trigger-based replication with SLT from SAP sources into non-SAP as well, but no further details at this time. Again, at least from me 🙂

      I think going through HANA Master Guide would be helpful for you.

      In the future I would recommend to post questions to In-memory forum: SAP HANA and In-Memory Computing


    • Hi Derek,
      you touch some interesting points which I interprete as how a BW and potentially an arbitrary table schema (e.g. one originating from an Oracle DW) can coexist on HANA. It's a topic that is difficult to discuss in a short answer. Actually, I've a diagram on slide for this that I'm using in presentation and I've been thinking for a while to convert this into a blog which I will do as soon as I find the time for that.