Home > Blog > Blog > 2012 > June > 13
Currently Being Moderated
Steve Lucas

Does SAP HANA Replace BW? (Hint: No.)

Posted by Steve Lucas in Blog on Jun 13, 2012 6:14:09 PM

Well – I can’t say I am surprised by all the debate on Twitter about SAP HANA potentially replacing BW. I wrote this blog in response to about 50 tweets I saw on Friday about the topic. I want to thank Vijay Vijayasankar from IBM for his contributions! I plan on covering four scenarios in this blog that will hopefully help guide people. Those scenarios are:

 

1. I have SAP ECC and BW, what do I do?

2. I have SAP ECC and may want BW, what do I do?

3. I have SAP ECC, but someone told me SAP BusinessObjects Rapid Marts are better, what do I do?

4. I have SAP ECC and someone told me they will design a data warehouse for me from scratch, what do I do?

 

The easiest place to start answering these questions is by defining BW first. The reason being that it’s fairly obvious that not everyone defines “BW” the same way. Some people don’t even call it BW, but rather SAP BIW or BI. In defining BW, I will first quote the source of all truth, Wikipedia: “SAP NetWeaver Business Warehouse (SAP NetWeaver BW) is the name of the Business Intelligence, analytical, reporting and Data Warehousing solution produced by SAP AG. It was originally named SAP BIW (Business Information Warehouse), then abbreviated to SAP BW, but is now known as "SAP BI" at the end-user level. In contrast, "BW" is still used to describe the underlying Data Warehouse Area and Accelerator components. It is often used by companies who run their business on SAP's operational systems.”

 

The posting on Wikipedia further goes on to state that “SAP’s BW solution has a pervasively employed data warehouse and contains a large number of pre-defined business content (pieces) in the form of InfoCubes, Info Objects, authorization roles, and queries. This allows the ability to leverage SAP's experience and to reduce implementation cycles. The business content can be modified to meet an organization's specific requirements; however, this requires a longer process of customization of the pre-defined elements.”

 

Finally, the posting states that BW has several components, including, but not limited to:

  • An optimized Extraction, Transformation and Load (ETL) layer for moving data around.
  • A Data Warehouse Area that stores data in a star schema design.
  • A reporting component for consuming information from the data warehouse.
  • Planning and analysis to simulate operations like budget calculations.

 

The point I am trying to make here is not to over-quote Wikipedia. But since I am writing a blog on whether or not HANA replaces BW and there are barely two people on the planet who will define BW as the same thing, a little grounding can’t hurt!

 

Now that we have the official definition of BW, here’s my definition: It’s a system. A system consisting of a warehouse, a pre-defined business schema, as well as content and related tools for improving analysis of data stored in the SAP Business Suite. Plain and simple. Either all or part of this system has been deployed at over 13,000 customers, it has thousands of third party apps certified by SAP running on top of it, and it delivers reliably (note, I didn’t say quickly). And BW is free. But it’s NOT a database. It works ON top of a database, and that distinction needs to be kept in mind. You also spend money on a slow disk based database to power your BW today and often accelerate it with a hardware solution like Business Warehouse Accelerator (BWA).

 

Moreover, for the past 15 years, for every module in the Business Suite (not quite, but pretty much most of it), we’ve built logic to convert the 4 character table names in SAP ECC to have "business meaning" via BW content. So the question to contemplate as you read this blog post is: Should one set out to rebuild content that SAP spent 15 years building for you because it's perceived as "difficult"?

 

As for my definition of SAP HANA: It’s a database. (You can’t use that quote without the rest of the story below...).

 

Granted HANA is a special KIND of in-memory database that delivers insanely great performance when coupled with systems LIKE BW, but at its most basic level, it’s a database. HANA does not replace BW. It is meant to enhance BW. On the speed note, it’s worth noting that I view one of the major challenges with running BW on a traditional RDBMS as poor reporting performance. With HANA as the database for BW, reports (amongst many things) absolutely perform better. If you can get SAP BusinessObjects (BOBJ) as a front end to BW, even better.

 

Cheetah.png

My ENTIRE point: BW is MUCH better on HANA, and coupled with the fact that BW is free, there is a ton of pre-built content for BW A

 

ND you get instant certified solutions on top of BW-- isn’t it worth at least CONSIDERING it if you don’t own BW? Remember, there is NO plan to sunset BW. If someone has stated that, they are unequivocally wrong. I am a BW plus HANA advocate instead of a BW vs. HANA guy.


I get that there are options to BW. Some customers have acute needs and will find a BusinessObjects Rapid Mart a quick way to move data using Data Services into a much more manageable “store” than BW. But you also will have to build (or, customize, depending on the Rapid Mart) the extracts, transforms, reports, etc. you’ll need in order to be productive. I know SAP is building some new content in HANA natively, like the Operational Reporting RDS. So one might wonder if SAP is "switching gears" in terms of where c

 

ontent is created and resides. (Again, the answer is no, we haven't switched gears at all.)

 

I get that some people will say “just design your own warehouse from scratch,” but the same issues apply. It’s classic ‘build vs. buy’ and a BW scenario with HANA or any other database is NO exception.

 

 

I am going to cover the four scenarios I promised you, so here they are:

 

Scenario #1: I have SAP ECC and BW, what do I do?

The short answer: Companies should absolutely leverage HANA as the database for existing BW deployments.

 

I mentioned earlier that speed of reporting is a big pain in BW without HANA; however, its really about end to end performance – loading, reporting, simple landscape and change management.  Due to parallel loading we dramatically reduce the time of loading data into SAP HANA for BW and it’s a essential for companies that have long nightly jobs (get HANA, spend time with your family rather than babysit these loads!)

 

Speed of ETL and Reporting is only one aspect of HANA as the database for BW. An equally important - maybe even more important - aspect is simplification. BW has some extra layers that were built solely for performance reasons. Those layers are not needed when HANA works as the database for BW. A leaner BW is more efficient to build functionality in, and manage in a production environment. The Layered Scalable Architecture for BW is evolving to make the best use of the power of HANA as its database. Functionality that used to work in the ABAP layer of BW is now being moved over time into the HANA layer to make the entire model and processing work much more efficient. An example of this is DSO activation that happens in a fraction of the time it takes with a non-HANA based BW system.

 

Often, many BW customers have SAP Business Warehouse Accelerator to accelerate their slow disk based RDBMS for BW. SAP HANA provides a much simpler landscape reducing TCO and complexity. It reduces your hardware footprint dramatically - e.g. to accelerate 5TB of BW data, you would need 21 blades in BWA  vs. 1 HANA server with the added benefit of no third party database since HANA is the single persistent database. It’s a no brainer!

 

Change management is relatively easier with the choice to build more logical layers instead of physical ones and no need to re-index results that can take hours before changes can be effective.

 

Beyond all the points I've already made in this blog post, let’s look at real results. For most customers with significant investments in BW, the opportunity to really leverage their mission critical data warehouse investment and unlock its full potential has always been the goal. I believe the opportunity has arrived with the marriage of BW and HANA.

 

The vast majority of our 50+ BW/HANA ramp-up customers have shown impressive results and fast ROI. And investing in HANA today as the database for BW has set them up to further expand the value of HANA as a foundation for real-time analytics as well as a platform of new innovative applications. What this means is HANA for BW today is the beginning of your platform for the future. The same HANA platform will enable your advanced analytics use cases, run your planning applications such as decision support/predictive analytics, text mining and search.

 

Also, it is a simple migration of your database and SAP has a cookbook to help you do this.

 

 

Scenario #2: I have SAP ECC and may want BW, what do I do?

 

The short answer: It depends.

 

It depends on a number of factors and considerations when looking at your overall data management, data foundation and analytics strategy going forward. For example, if you have planning needs, you can take advantage of solutions that are based on the BW foundation. You may consider BPC on HANA, S&OP on HANA as possible solutions (This could necessitate BW).

 

For many companies with significant investment in SAP ECC who are looking at an enterprise data warehouse approach to consolidate corporate data, provide one centralized trusted data foundation for analytics and with one version of the truth, SAP BW is the way to go. If someone tells you they can build a custom warehouse similar to BW, replicate all the "good" that comes with BW with no downside, I'd like to meet that person.

 

If SAP transaction systems are the primary source of reporting information for you - then it makes a lot of sense to use BW as your data warehouse to make use of its business content and layered scalable architecture. Also - there is no reason why you cannot have BW on HANA AND a stand-alone HANA system, both as part of your landscape at the same time if you have use cases that need it. Having both might enable you to determine what, if any, part of BW you might want to leverage.

 

That said, there are times where a company has a very specific pain, which could be better solved through a custom warehouse or SAP BusinessObjects Rapid Mart.

 

 

Scenario #3: I have SAP ECC, but someone told me SAP BusinessObjects Rapid Marts are better, what do I do?

 

Short answer: Again, it depends.

 

SAP Rapid Marts definitely do not substitute a data warehouse. (That's why they aren't called "Rapid Warehouses") But they do offer value for companies looking for a quick "plug and play" approach who need a light weight analytical datamart often to support a departmental use case. In other words, Rapid Marts should be viewed as accelerators which could be a prelude to a larger data warehousing project.

 

For those unfamiliar with Rapid Marts, they include pre-built data capture jobs, data mappings, a data foundation and packaged reporting content for accelerated BI implementations.  They target key areas of SAP ECC (e.g. Finance, HR, Manufacturing, etc.) and are great for departmental needs in a large enterprise or for smaller companies with scarce IT resources but with an immediate need to get fast insight into their ECC application.

 

 

Scenario #4: I have SAP ECC and someone told me they will design a data warehouse for me from scratch, what do I do?

 

Short answer: Designs are cheap. Deployments aren't.

 

If you don’t think this will be expensive, think again. As I previously stated, SAP spent the last 15 years building and perfecting data mappings from the suite to BW.

 

For example, let’s look at integrated lifecycle management with SAP ECC, complete transaction record integrity with ECC, pre-rationalized data models and data objectives for ECC.

 

Trying to accomplish all this for your SAP landscape from scratch would mean that you are essentially re-inventing the wheel and not unlocking any value available in BW - for free. In this scenario, an important consideration is SAP BW’s established design and pre-delivered packaged content (for fast time to implementation). This is why the BW option has been the route taken for the majority of our customers (13,000+) who have turned to BW as their data warehouse.

 

I realize that we are going to get some debate going about design vs. deployment. Like I said...design can always be done on the cheap.

 

SUMMARY

 

So back to the original question: Does HANA replace BW? I suppose the answer is: No. But putting a statement out there like "if you haven't deployed BW you shouldn't" would be incredibly irresponsible. HANA is definitely many things (A database for BW, a high-performance analytical appliance, a platform for new applications), but matching the entire "system" known as BW point-for-point is a huge project for any company.

 

I have no doubt in my mind that most of you who have BW systems today would agree and some people will disagree with me (it’s guaranteed and I expect Inmon/Kimball quotes aplenty), and spurring on conversation was certainly part of the objective. I know I only covered a few scenarios and request that responses to this blog suggest more specific scenarios for a “Part 2” of this blog.

 

For insightful discussion on BW on HANA check out the blog posts on the Experience SAP HANA site.


Comments

News Archive

SAP HANA News Archive

Filter Blog

By author:
By date:
By tag:

Contact Us

SAP Experts are here to help.

Ask SAP HANA

Our website has a rich support section designed to help you get the highest quality answers quickly and easily. Please take a look at the options below to get you answers from the SAP experts.

If you have technical questions:

If you're looking for training materials or have training questions:

If you have certification questions:

Χ