Skip to Content

Why SAP-HANA Should Start Replacing BW!


SAP introduced the term SAP-HANA two+ years ago. At that time, the industry was skeptical with SAP’s vision. Most scoffed at the idea of In-Memory database; some said – without revealing any details – they had been using In-Memory Databases for years. A year later, SAP delivered SAP-HANA. Ever since, the industry is not discussing whether or not In-Memory DB is viable; rather they discuss how to use it. Currently one of the hot topics within SAP is if HANA replaces BW or not. One school of thought – it appears a majority of people hold this school of thought – is that HANA augments BW, not replaces it. You can read blogs 1 & 2.

In this blog, I’m going to discuss why HANA should start replacing BW. In my opinion, SAP-HANA replacing BW is a great thing. I’ll give top 10 reasons.

1 The Status of BW

Business Warehouse is a great product.Technically. I love it. BW SAP-development team has done an amazing job in designing and developing the framework. However they didn’t do a good job of teaching the customers how to use it. As a result, the customers started using it with no or little background on Data Warehouse concepts. The customers believed all they needed to know was a list of radio buttons, checkboxes, tcodes etc. Due to lack of education, they started activating or deactivating an option with no or little understanding of its long term impact. BW also helped them design on the fly and implement or meet the business needs quickly.

What happened as a result! Not good. General perception of BW is not good worldwide 🙁 .

I read comments such as:

BW content is highly overrated. Only extractors are most used content.

And response to that comment:

True – Most people only use extractors. But that is not because the rest is bad – it was also due to implementation methodologies failing to use it well.

You can read those comments and the blog here

Yet another comment from SAP Mentor Jamie Oswald:

I do find it interesting that SAP folks think of data warehouses largely in cube terms, but not everyone has that same imagery.

This is general perception about BW. BW is always thought of in terms of cubes instead of Data Warehouses. Cubes of course are important and most critical component of a data warehouse. However that’s an end state of good data model and design. How many discuss data model and design while discussing BW?

SAP Mentor Ethan Jewett says:

My point is that the idea most people seem to have about BW – that it is just about extracting and aggregating data from SAP ERP for performance reasons – is not a realistic description of what BW is capable of when used well.

I agree with Ethan that what most think of BW is not a realistic description of what BW is capable of when used well. The question is: How many use BW well? Vitaliy’s blog answers this question.

Read Vitaliy’s Blog Is your BW the Data Warehouse, anyway?

Vitaliy says in his blog:

There seems to be a big wall between the worlds of BW and “traditional EDW” (whatever it means). Go to the LinkedInforum of The Data Warehouse Institute (TDWI) and try to open a mouth that you are working with BW – you will be smashed immediately with many comments like “[BW] has always been an ancient, clunky and monstrous solution to implement.”, “I’m yet to come across an SAP customer that isn’t into their Nth attempt at trying to get it to work properly or efficiently.” or “How much did [BW implementation] cost (software, hardware, consulting, etc.), how long did it take and how much frustration did the business users feel while waiting for a solution?”

2 Compatibility between BW and HANA

BW stores data in aggregate form. SAP-HANA’s primary objective is to get rid of aggregates and run reports off of raw, operational data. BW was developed using technologies that were available 10-15 years ago. 10-15 years ago, the constraints we had on CPU and memory resources were resolved by pre-calculating data and storing it in aggregate form. This not only introduced additonal layers but also lacked flexiblity of meeting dynamic business requirements. Watch this video to understand how the customers use SAP-HANA:

3 Compatibility between BW and other products

BW was introduced 12+years ago. In the last twelve years, SAP has acquired several companies. One of them most relevant to BW is Business Objects. Folks working in Business Objects and BW speak two different languages. Recently I happened to listen to this podcast. One of the speakers eloquently explains the challenges he had in meeting the customer’s requirements due to the incompatibility of BW data model and Business Objects’s requirements. Based on the feedbacks I read, it is clear BW and Business Objects are not made for each other. Why struggle to make BW and Business Objects work together when there is a golden opportunity to make Business Objects work with SAP-HANA by taking advantage of latest and greatest developments everywhere.


BW was developed when technology dictated two different systems, one for OLTP and another for OLAP. However as you can see from Vishal’s video, SAP-HANA would support both OLTP and OLAP in one system. Should SAP-HANA introduce a new system: OnLine Transactional and Analytical Processing (OLTAP) system instead of discussing 20+ years old OLTP and OLAP systems?


Thomas Zurek discusses eloquently why HANA can’t replace BW using EDW=DB+X equation. In the world of OLTAP, is that equation relevant? Shouldn’t that equation look like:

OLTAP=HANA+Y+Z where Y stands for OLTP application and Z stands for OLAP application.

6 Near Real time versus Real-time

This is a great one. When there is a potential for real-time reporting, why settle for near-real-time reporting? NCR’s Teradata introduced Active Datawarehouses in late 90’s. And what is the status SAP’s Real-time Data Acquisition(RDA)? In my opinion, both RDA and Active Datawarehouses are great concepts if we can’t have Real-time Datawarehouses.

7 Past versus Futuristic

As you can see from comments listed under (1), BW doesn’t support the customers very well. Instead of using that technology in combination with revolutionary, game changing technology such as SAP-HANA, wouldn’t it make more sense to delink that application and discuss newer ways of meeting the business needs of future?

8 Cubes Versus Flat, Raw, Operational Data

As pointed out already, the cubes store data in aggregate format. This reduces the flexiblity in users’ ability to analyze data dynamically. Whereas in OLTAP system, all data is stored in raw, operational data format. Using front end tools such as Business Objects, it would be very easy to provide what users want in real time using real time data.

Vishal Sikka in his blog:

In his moving poem “The Layers”, the great American poet Stan Kunitz wrote, “Live in the layers, not on the litter”.  A wise sentiment to help drive the renewal of enterprise landscapes, especially at a time when we keep seeing re-assembly and re-packaging of existing layers into new bundles, that seem to promise lower-cost integrated systems, but in fact add to the clutter that already exists in enterprise landscapes, at a time when we must, and we can, help enterprises achieve massive simplification, renewal, and true real-time performance and scale, without disruption.

“….true real-time performance and scale ….” would only be possible with reporting directly from raw, operational data.Period.

9 Lessons from the past…

Historically whenever new, next-generation, revolutionary technology was introduced in the past, we’ve always seen old ones being replaced not augmented. Here are a few examples:

  1. Manual processing versus computers
  2. Mainframe Versus Client/Server
  3. Newspaper Versus Internet/ePaper
  4. Snail mail Versus email, online payments, skype etc.
  5. Landline Versus Cellular Phones

As you can see, none of old technologies were replaced overnight. It took time; In addition, some(or all) of old technologies were not replaced completely. I agree SAP-HANA replacing BW would take sometime. However my point is that new SAP-HANA customers should be encouraged to migrate from HANA-optimized cubes/DSOs to native raw, flat, operational data format as quickly as possible.

10 Two messages versus one message

As you can see, SAP is communicating two messages. Hasso/Vishal try to communicate that SAP-HANA would support both OLTP and OLAP systems in one system and make real-time reporting a reality. Others within SAP say the customers would still need their BW system for reporting purposes and SAP-HANA would support near real-time reporting.

UPDATES (Added June 28, 2012)

Screenshot 1

What does the following screenshot tell us?

In non-HANA environment, we follow Classical Approach which means:

  1. DB Processing is expensive
  2. Transfer more data to the application
  3. Process/Calculate in Application Layer(Example: BW)

In HANA environment, we would follow Future Approach which means:

  1. Move Processing/Calculation to the DB layer
  2. Transfer only results

In order for this change to occur, we need to start thinking differently. A majority of problems/issues we discuss today are related to Classical Approach. That is not going to be true in SAP-HANA environment because of fundamental change in how we’re going to process. That would require designing and developing applications from scratch to take advantage of the benefits offered by SAP-HANA.

DB Layer.PNG

        Courtesy: SAP-HANA Guide

Screenshot 2

New possiblities.PNG

   Courtesy: SAP-HANA Guide


       Courtesy: Think_Different

Comments are closed.
  • Hi Bala,

    sorry, no disrespect, but you wildly mix up marketing, technology concepts (OLAP <> data warehousing <> aggregates!), imagination (of what could possibly happen one day) etc. There is some factual mistakes (e.g. about BW's capabilities). I think you probably and erroneously put a ? in the title where you wanted to put a !


    • Hi Alistair,

      Thank you for your input. Could you please elaborate this?:

      There is some factual mistakes (e.g. about BW's capabilities).


  • Hi Bala,

    I struggle with this. I agree that HANA provides some phantastic technical stuff for all the points you raise. However, we disagree already on the terminology and that's why I cannot really discuss with you. OLAP and data warehouses are, for example, orthogonal things. OLAP does not require a data warehouse and a DW does not imply OLAP (although a DW provides a good ground for OLAP). Btw: the OLTP + OLAP argument is around technical workloads and suggests that you don't need to separate them simply for a technical reason. In contrast, data warehousing is a methodology, not a technology.

    One more example why I struggle: what's your point on real time? First, what is the relationship here with BW? Do you imply BW cannot do real time? It actually can do 0 sec latency via virtual cubes since BW 2.0 (2001). There are productive customer scenarios building consciously on that fact. Secondly, "real time" is important when changes in the data within, say, the last minute are decisive to the outcome of the analysis. Fraud detection in e-commerce is a good scenario here. However, when the manager of your local super market runs an analysis of his slow selling items he will rather look at the last few months of sales data. What happened within the last day is probably not changing anything in the result. I'd argue that if his IT gave him the choice between analysing real time data or working on non real time data that got enriched with some demographic attributes, mashed up with some external market data from competitors and/or some other branches (with those enrichments incurring a delay of a few days) then I guess he'd clearly opt for the richer non real time scenario as the enrichment gives him more insight and is therefore worth while the effort, even at the expense of some latency. This, by the way, is also a good example that it is a smart trade off that you need to find in reality. So if your point is that "real time" is always good or is what we need to strive for then I'd simply add: "where it adds value and where it doesn't stand in the way of achieving more valuable results".


    • Hi Thomas,

      I'm in agreement with everything you said with a few exceptions:

      a DW does not imply OLAP (although a DW provides a good ground for OLAP)

      A DW, in my opinion, can be primarily used for either reporting and/or analysis(OLAP). It seems, based on my limited exposure and what I gather from others' experiences, BW is used more like a reporting tool than analytical tool.

      In contrast, data warehousing is a methodology, not a technology.

      IMO, Data Warehousing is a concept and BW uses a methodology to implement that concept (Kimball's bottom-up and Inmon's top-down are methodologies as well). We may or may not agree but it is less important.

      What is more important is that the technology that evolved to take advantage of DW concept:

      • Star Schema/Star Join
      • Snowflake Schema
      • SAP's extended star schema
      • Bit Map Indexes to support low cardinality columns. This could be used for OLTP systems but generally not used. SAP for example doesn't create bitmap indexes in delivered ECC system.

      I don't know NCR's Teradata very well; however Teradata - a MPP with shared-nothing architecture - was primarily built to run DW systems. I don't know of any customers running that machine in an OLTP environment. This implies DW needed a different technology.

      So IMO, DW includes everything: A concept, we need a methodology to implement it, technology to take advantage of DW concept and others like reporting/analytical tools etc.

      Real-time reporting: Yes, everyone doesn't need it. But if I'm going to implement SAP-HANA which can take care of both real-time and non-real-time reporting and analysis dynamically on raw/operational data, not sure why I would need - long-term - another tool to run reports on non-real-time aggregated data.

      SAP's vision on SAP-HANA is revolutionary in my opinion and viable based on what you delivered so far.

      Best regards,


    • HI.

      We must agree that SAP BW isn't EDW. It's something-something different.

      There are a lot of strange limitations in SAP BW, when you just saying ups 😉 ....

      SAP BW is like good old ford-pickup, with no realy big innovations since 2006. (BW 7.00).

      Can we use BW in real-time? Theoretical yes, but practically - with limits.

      Are HANA can replace BW? - IMHO No.

  • I think BW is here to stay for quite sometime, atleast for landscape which is predominantly SAP (atleast until DS workbench starts working).  A smallest BW reporting cube consists of hundred text tables plus all the master data tables; plus all the joins, time dependencies etc.(Via Attributes of Characteristics etc) One can only imagine the amount of work delivered when typical small BW project that requires in excess of 50 Queries is implemented

    Trying to create that in HANA using BO stack is not easy (and the problem is DS workbench is not mature enough). All those tables have to be created. All those ETL has to be created unless we use the transaction system with table reads.

    For those who are familiar with Implementation using Business Content (smartly) can put significant amount of deliveries in just few weeks, which at the moment is not possible using BO stack. Anyone who believes that data-modelling issues in bare-bone tables would be any easier than it is in BW may be missing the fact that the complexity is in Business processes and underlying Business Entity relationship. 

    While the point of extractors are well made, BW is pretty good in delivering Baseline Business Requirement through Business Content Roles and Queries. Infact even for BO projects, the BW business content can form a baseline.

    Offcourse the use case for HANA as database for BW is much stronger plus cases where SAP is not a major transactional system in landscape, BO stack may prove more advantageous.

    On the other hand, I am not convinced that BW is the reason why many projects fail. More often than not, poor understanding of business operating model itself is the foremost reason why projects fail. These are going to stay irrespective of the tool chosen.

    In my own experience of developing with HANA+BO+DS and with BW, I find BW much more faster and capable as the things stand. However if and when DS workbench matures; BO+HANA stack would look pretty good.

    • Anyone who believes that data-modelling issues in bare-bone tables would be any easier than it is in BW may be missing the fact that the complexity is in Business processes and underlying Business Entity relationship.

      Agreed. In my opinion, we - this implies only projects that I worked - followed "quick and dirty" method of implementing a solution. If we're not going to change the process and take time to develop the data models, then I agree; we might as well continue using BW. In that case, the screenshots (1) and (2) added in main blog would serve no or little purpose in new environment.

      All those ETL has to be created unless we use the transaction system with table reads.

      I meant copying tables from the transaction system to HANA and then developing the views on top of that. This is short term solution consistent with what was taught in TZHANA class. 

      On the other hand, I am not convinced that BW is the reason why many projects fail. More often than not, poor understanding of business operating model itself is the foremost reason why projects fail. These are going to stay irrespective of the tool chosen.

      Agreed. BW is not the reason why many projects fail. In my opinion, BW is a double edged sword. It can be easily misused.



  • Hey Bala,

    I'm really struggling as to whether I should reply to this because of the same reasons that Thomas and Alistair mention. But I will, because this article comes over really confused and I think that clarifying some points might help.

    1) The challenges of BW. Who can argue that BW has some challenges, but there are 17,000 installations of BW that support many customers in a business critical way.

    2) BW business content. BW has its challenges but this is the first time I have heard "BW content is highly overrated". Do you have data points for this?

    3) BW and aggregation. Most customers load line-item data into PSA and DSO. Then, they aggregate into cubes and aggregates. BW on HANA provides you with a roadmap here - first, you get rid of the aggregates and dimension tables with BW optimised InfoCubes. True, you don't get the benefit of more granular reporting (but did you need it?). Then, you can write queries against the DSO data and later remove the cubes - getting the full benefit of HANA.

    4) Real-time. To Thomas' point, most of the time you don't care about real-time when you are doing reporting. But if you do with BW on HANA, you are in an awesome please because you can replicate data in real-time with SLT, and mash it up with quality master data into a Transient Provider. That's the best of both worlds.

    5) HANA as an EDW. Good luck with automatic currency conversion, time-dependent master data, stock and all the other things that BW brings out the box. If you want to do simple reporting then HANA Enterprise is great.

    6) OLTP, OLAP, OLTAP, EDW, DB+X. No clue what you're talking about here but the concepts of a separate EDW don't go away just because HANA can do transactional and reporting on the same data. You still need to combine data from multiple sources, persist hot and cold data and perform business transformations. HANA can facilitate some of this stuff but you will still need an EDW.

    So in conclusion I find your arguments really confusing.

    But, I don't find Vishal and Hasso's message confusing. The vision is simple: in time, you will be able to combine your operational reporting into your transactional system.

    Is that incompatible with BW? No, because you still need an EDW to combine data from other sources, do complex business transformations etc. It will just sit in the same private memory cloud that is called HANA, and the movement will happen real-time and in-memory.



    • Hey John,

      Congratulations on being named part of "The leadership of the Distinguished Engineer Program" along with

      Vijay Vijayasankar, Head of SAP Forward Engineering for IBM Global Business Services; Harald Reiter, Senior Manager with Deloitte Consulting; and Jon Reed, Independent Analyst, Blogger, and specialist in SAP career planning and skills development.

      Now to your comments:

      because this article comes over really confused and I think that clarifying some points might help.

      I agree partially with the first part;I say partially because I was just a messenger(of confusion). I didn't introduce any new confusion.

      SAP Mentor Vijay Vijayasankar says:

      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.

      Is what you say consistent with what Vijay says and the screenshots I added in the blog post under UPDATES section?

      Aren't we supposed to think different for SAP-HANA because of the fundamental change in how we're going to process (that is, from application centric processing to DB centric processing as illustrated in the screenshot 1)?

      Best regards,


  • Hi All,

    I too had similar thoughts with my little knowledge on HANA and BW. I do not wanna argue or do anything but to put a layman's view on these products. Its just a commonsense that a new product in the market should reduce the complexity (SAP Landscape and implementation). In the TZHANA material SAP HANA Roadmap claims that eventually they will reduce the dependency of BW and one store for data and analytics (dont know how to attach a screenshot or something, page 23, TZHANA , SAP In-Memorry computing Product Strategy).

    After all that all I think / assume is SAP does not want to loose money on existing customer licenses (SAP please do not get offended) .

    In Business Objects Webi we have a facility to use multi source data to create a Universe, it is done very easily (again sorry for my limited knowledge comments), is Data Warehousing is a mandatory system for performing only that then why cant the same thing be imitated in HANA so that it is one less headache for the SAP customers.

    Just a simple thought.



    • Hi Krishna,

      When Larry Ellison discussed #SAPHANA for 20+ minutes in his keynote during Oracle OpenWorld 2011, I started believing more in #SAPHANA. The noise level on #SAPHANA has only increased ever since #SAPHANA chat started 2+ years ago. As a result, I invested more time and money to learn #SAPHANA. Based on everything I learned - both formal and informal - we think alike. I'm sure several others think the way we do. However for the reason you stated, everyone in #SAP may not like the reality. And soon(or already as evidenced by Larry Ellison's talk) other DB vendors may not like the reality as well. I agree 100% with Steve Lucas that the replacement of BW by #HANA would depend on how much of BW customers use(I already quoted Steve Lucas's response in response to Maik's comment).

      Thanks and best regards,


  • HI all,

    I'm a little bit confused with this article, because the headline transports a wrong message already


    HANA will not replace BW! And it has not been SAP's intention to replace BW with HANA but tearing down the performance handicap of conventional databases used for data warehouses.

    At the moment, HANA is just - not more, nor less - an alternative database concept to run BW. BW will stay alive, running as Enterprise Datawarehouse storing consistent and harmonized data. No matter if it will be stand-alone or integrated part of an ERP system

    Even if ERP and similar applications are migrated to HANA, it will be necessary to extract and harmonize the data relevant for business decisions. It will remain necessary, because of the complexity of data in transactional systems and the (growing!) need to include external data for analysis. And - this is real life - many companies are working with a highly complex system landscape supporting their business processes. So they need a platform to consolidate the data from these heterogenous systems.

    • Hi Maik,

      During Tweet Chat using #SAPChat last week, I asked this question:

      SAP-HANA is DB.App can be written for her.When wud that app start replacing BW?Already/Today/1yr/2yrs/5years/never or upto custmer?

      And Steve Lucas responded:

      to REPLACE bw for an existing customer? That will depend on how much of BW customer uses.

      This is the best answer I've got so far on whether or not #HANA will replace BW. IMHO, no one knows the answer for sure. However as Steve alluded #HANA with an application written for her can(should) potentially replace #BW depending on to quote Steve Lucas "how much of BW customer uses". And as #HANA matures, in my opinion, the scope of BW that could be supported by #HANA(plus native app) natively would only grow. The title of the blog "Why SAP-HANA should start replacing BW!" is more appropriate.(SAP-HANA here implicitly includes customer data, modeling tool, an native application etc).



          • Sorry Bala. This is starting to become an esoteric discussion/argument! BW-on-HANA is the most genuine and deeply integrated app on HANA that SAP has delivered. It leverages a large extent of HANA's processing mechanisms.

            And btw: BW <> cubes. Sorry.

          • Hi Tim,

            I'm disappointed to know that you feel this is starting to become an esoteric argument! Your response however confirms that BW on HANA as delivered today is NOT an native app.

            After attending TZHANA, TZ300 classes and getting certified, I see a huge difference between native app and BW-on-HANA. I wonder why I invested time and $$$ on education, training and certificate if everything I learned in formal classroom has absolutely no relevance to the real world!!

            Please read this blog to learn my journey on Educaton, Training and Certification!

            Best regards,


        • Hi Ethan,

          Sure if you want to continue calling native app as BW, I'm fine with that. However as I mentioned in the blog, people normally associate BW with cubes. This in my opinion would be completely untrue with native app.

          Best regards,


  • Interesting blog.

    I really like HANA and use it everyday. But if we look at the components of EDW, it has souce, data storage, ETL, information delivery/data mining and meta data management. BW, as a solution with many years history, covers most of the aspects. HANA, at the other side, is still more like a database. So it is a little bit early to talk about replacing BW with HANA, this is my personal opinion.

    At the same time, regarding the 'overrated' BW Business Content, the question is who 'overrate' it. I believe most SAP BW practitioners do not overrate it as they should know its capability very well, and most of them think BW more than 'cubes'. Rather than what people think BW is, or how they rate BW, the more important thing is what business issues BW can resolve.

    Each products has its own pro/cons. When you put BW into a client with SAP as the major ERP solution, it is probably the best option for EDW. At least, the operation infrastructure is simple. You will need less effort for data governance, metadata management, even the skillset of the support team is consistent. For the company who has smaller SAP implementation, the BW is best for the ERP data warehouse.

    Can HANA replace BW? I think yes. Actually if you put enough investment, Access can replace SQL server, notepad can replace word and SAP BusinessOne can replace SAP ECC. But this is not really a technical debate, it all depends on whether the replacement could bring value to the clients. As of now, it seems SAP think the value is not there for most of the customers. The fact is, in last year, there were 200+ new BW installations per month:)

    • Hi Eric, 

      So it is a little bit early to talk about replacing BW with HANA

      The title of the blog is: "Why SAP-HANA Should Start Replacing BW!". I guess we're discussing two different things.

      Rather than what people think BW is, or how they rate BW, the more important thing is what business issues BW can resolve.


      As of now, it seems SAP think the value is not there for most of the customers.

      Agreed. Here is what Steve Lucas stated last week:

      to REPLACE bw for an existing customer? That will depend on how much of BW customer uses.

      As the title of the blog suggests, we should start replacing BW with SAP-HANA based on how much of BW customer uses. Yes, the value may not be there for most of the customers. But is there any reason why we shouldn't start replacing BW with SAP-HANA where it makes sense?

      John Appleby says:

      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.

      And now regarding Access-SQL Server & notepad-Word, the analogy doesn't make sense (Sorry):

      1. SAP-HANA is next generation, game-changing, revolutionary technology. Here is what John Appleby says:

      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.

         John continues:

      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

            As you can see, Access, Notepad and BusinessOne are not inflection points. The blog discusses about (starting to)replacing 10+ year old BW systems with next generation database SAP-HANA(inflection point). Access replacing SQL-Server, Notepad replacing Word? Sorry. I don't understand the analogy.

          No, SAP-HANA replacing BW is NOT technical debate;I listed 10 reasons and most(if not all) of them are business reasons.

      Thanks for your input and best regards,


    • Yes it's old and it is not the mainstream opinion. Maybe even the author himself meanwhile changed his mind.

      However, these are no reasons to delete any content.

      If the author wants to do that himself, that's fine.

      Otherwise it will stay just as any other content.

      Lars (moderator)

      • Hi Lars,

        I would say I am still confused with SAP's message.

        I attended SAP HANA training program in Feb/March 2012, learned about attribute views, analytical views, calculation views etc. Wrote this blog based on that training program and reviewing other materials available at that time.

        This blog was published on Nov 18th, 2015 in Business Trends -  How is my message different from this author's(SAP employee) message?

        Thank you,


        • Hi Bala

          it's certainly not my duty to discuss other SAP employees blogs in comparison with yours. SAP employees post content here on SCN the same way everybody else does and none of that is an official statement of SAP as a company.

          From as far as I can tell by skipping over this blog and the discussions this topic had been thoroughly discussed.

          Nowadays we have customers implementing SAP BW on HANA, mixed scenarios and "native SQL" data warehouses. While SAP HANA does allow for using operational data for reporting and analysis in ways that simply weren't doable without severe impact on the transaction system, it does't take away the use case for data warehouses and corporate memory systems.

          Your blog favors a "SAP HANA should replace SAP BW" point of view. And that's not what's happening.

          - Lars

Comments are closed.