Why SAP-HANA Should Start Replacing BW!

[former_member182313]

• 
  Introduction
  


• 
  1 The Status of BW
  


• 
  2 Compatibility between BW and HANA
  


• 
  3 Compatibility between BW and other products
  


• 
  4 OLTP, OLAP and OLTAP
  


• 
  5 EDW=DB+X Vs OLTAP
  


• 
  6 Near Real time versus Real-time
  


• 
  7 Past versus Futuristic
  


• 
  8 Cubes Versus Flat, Raw, Operational Data
  


• 
  9 Lessons from the past...
  


• 
  10 Two messages versus one message
  


• 
  UPDATES (Added June 28, 2012)
  
  • 
    Screenshot 1
    
  
  
  • 
    Screenshot 2
    
  
  

Introduction

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 :sad: .

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.

4 OLTP, OLAP and OLTAP

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?

5 EDW=DB+X Vs OLTAP

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 vishal.sikka/blog/2011/10/04/living-in-the-layers

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.

        Courtesy: SAP-HANA Guide

Screenshot 2

   Courtesy: SAP-HANA Guide

       Courtesy: Think_Different