SAP BW is a data warehousing application that runs on many databases, including the SAP HANA database. Most companies are aware that SAP HANA is much more than a very fast in-memory database. SAP HANA’s features include a text search engine, a web server, predictive and geospatial calculation tools, and, central to the discussion in this article, a graphical modeling tool.

When SAP HANA was first released, there were many rumors flying around about SAP HANA replacing SAP BW’s modeling environment and even SAP BW itself (see Figure 1, for a humorous take). This article addresses these rumors and provides examples of the continued use of SAP BW in an SAP HANA environment.

Figure 1

SAP HANA and SAP BW duking it out

I’ll take a deep dive into the features of SAP HANA that are similar and compete with those that come with SAP BW, and also look at some SAP HANA features that provide more functionality than SAP BW. Then I delve into some features of SAP BW that can make it an indispensable tool, at least near term, for most mid-to-large size companies. However, before I go into that, here’s a brief overview of data warehouses and why they exist in the first place.

Are Data Warehouses Still Needed?

Like all data warehouses, even custom-designed ones, SAP BW exists as a needed tool for three main reasons:

1. To reformat and re-store the data in tables and views that are optimized for reporting performance (not as they are in the transactional [SAP ERP Suite] systems where the goal is for a table design that puts saving the transactions fast in front of reporting fast)
2. To off-load reporting processing from the mission-critical ERP online transaction processing (OLTP) system.
3. To consolidate, homogenize, and cleanse data from different company systems into one cohesive format with globally valid values.

With the advent of SAP HANA, the rationale for having a data warehouse is less obvious. The speed of SAP HANA’s in-memory processing allows for traditional normalized data schemas (e.g., OLTP—online transaction processing) to also perform well in OLAP (online analytic processing) mode. In addition, if the SAP HANA system is properly sized, the load from the reporting applications should not interfere with mission-critical OLTP functions.

There also might be more features related to optimizing performance, such as Dynamic Tiering and SAP HANA-tenant database containers, which could assist in making sure ERP performance is paramount. As a result, reason number three above is left as the justification for having a separate data warehouse application. Or, to be more clear, let’s say this reason, plus any analysis features that are needed above those which SAP HANA can currently perform, are the major justifications for keeping SAP BW.

Let’s take a more detailed look at this analysis.

Consolidate, Homogenize, and Cleanse

Looking deeper into reason number three, an SAP HANA-only advocate might argue that SAP HANA’s newer tools that come with Support Package 9 and above chip away at SAP BW’s consolidation claims. They would argue that SAP HANA Enterprise Information Management’s data quality and data integration tools, combined with its ability to leave enterprise data where it sits via SAP HANA Smart Data Access or virtual tables, out-perform SAP BW’s built-in extraction, transformation, and loading (ETL) capabilities.

Rather than argue with the SAP HANA-only supporters, I partially agree with them. Native SAP HANA has a lot of BW-like features that can be leveraged to build out a warehouse. However, my full response to the SAP HANA-centric school of thought goes further than just agreeing, and is more pragmatic.

For big companies (or even smaller ones), when data is stored outside of SAP HANA, reporting against globalized data requires merging the data and then physically sorting it, or you have to use the slower option of virtualizing it and sending it over a network to be joined with SAP HANA data. For those few companies that can run 95 percent of their data on SAP HANA, as in the integrated ECC-on-SAP-HANA scenario (Figure 2), virtualizing five percent of the data is not a bad option.

Figure 2

SAP BW and SAP HANA deployment scenarios

However, as more and more data exists outside of SAP HANA (for example, when a company is acquired) and as users become accustomed to the speed of using data sitting on SAP HANA, the need to physically merge and store data in SAP HANA becomes more and more important.

SAP BW has features to handle the physical consolidation of data and to keep track of the data loaded. These features are discussed below, and in themselves perhaps could justify the need and use case for SAP BW. Also discussed are some of the added features SAP BW brings to the table that SAP HANA currently cannot do natively. Before I dive deeper into a discussion of each of these features, I want to explore the available installation options, again focusing on a company with ECC, and determining if SAP BW is needed or not.

Installation Options

Figure 2 defines a few of the options for using ECC with or without BW. In the following sections I outline in more detail some of these options, and the reasons for selecting them—or not. The three installation options—sidecar, SAP BW (only) on SAP HANA, and an integrated scenario—are all possible methods for deploying SAP HANA. The last option—the integrated scenario—has some other sub-options that I also discuss.

The Sidecar Installation Option

Many companies currently using ECC, especially the ones that think SAP BW is disappearing, might experiment with the sidecar approach (the middle section of Figure 2). They move data to SAP HANA and use it to quickly report operational information (low-level detail in real time) from SAP HANA. If they have SAP BW (and a majority of companies do), they keep the SAP BW system for consolidating data from non-SAP systems and for strategic reporting purposes.

The SAP BW Only on SAP HANA Installation Option

The next group of companies installed SAP BW only on SAP HANA (the left side of the figure). Many purchased just the database license for SAP HANA with SAP BW and did not use any SAP HANA-specific modeling tools. They just wanted a much faster SAP BW. In this case, the hope was that using an application layer specifically designed for data warehousing on top of a superfast database would lead to a best-of-both worlds result.

The Integrated Installation Option

The last group of companies followed SAP’s vision—which is, all the SAP-related products and custom-designed internet applications run on the same SAP HANA system (shown on the right side of Figure 2). When the ERP suite of products is running in tenants, each product would normally have its own application server using a common SAP HANA database. In this case, one tenant could be SAP BW, again with its own application servers.

This integrated scenario is really made up of three sub-scenarios, as follows.

The Integrated Installation Option: Sub-Scenario 1

The first sub-scenario is only just recently possible with SAP HANA Support Packages 9’s tenant database containers. These tenants isolate applications from a resource-use perspective. In this sub-scenario, SAP BW and ECC are on separate tenants. To make this clear, I call this tenant on ECC and SAP BW on SAP HANA.

The Integrated Installation Option: Sub-Scenario 2

The next sub-scenario is one that I am not sure SAP condones officially, but it is worth a mention. It is similar to the right side of Figure 2, but with the SAP BW system being installed on the same application servers as the ECC system, and one SAP HANA database supporting both ECC and BW, but not its own tenant.

Many companies are not aware that the SAP BW software is normally installed by default in a different client on the same application servers that are running ECC. This is to facilitate the use of the SAP BW query engine on top of ECC data. This SAP BW system is not meant to be used for the physical storage of data, but rather as a reporting pass through. This basically means the application servers are shared between SAP BW and ECC. This option, which I call ECC with fake SAP BW (the official term is embedded BW), is worthy of further consideration. This is because when you implement this fake BW, you have the option  to use the query designer and virtual providers without having to install separate application servers for BW.

The Integrated Installation Option: Sub-Scenario 3

The final sub-scenario relates to the addition of SPS9’s Dynamic Tiering option. This is not really a scenario, but rather a cost saver. When you move all your applications to SAP HANA, it results in a big SAP HANA system, and an expensive one. Dynamic Tiering allows you to use a fast, disk-based system (SAP Sybase IQ) to offload less needed data and thus save money. It allows a cheaper and a bit slower SAP HANA.

In the big picture of things, nearly all reporting and analytics results are based on database views. These views are collections of tables joined at run time to present data to reporting tools (for example, BusinessObjects tools). Both the SAP BW application running on SAP HANA and the native SAP HANA modeling tools can create these views. One might argue SAP HANA’s views are more flexible than SAP BWs InfoProviders, but SAP BW’s InfoProviders are easier to model.

Reasons for Using SAP BW After Installing SAP HANA

In the following sections I list just a few of the reasons companies might have for keeping SAP BW, and for deciding it is a needed application on top of an SAP HANA database. In some cases, however, it might be that SAP BW is not needed. For example, if your company has 99 percent of its data only originating in ECC and you cannot foresee getting data from outside SAP HANA, you can run it directly on SAP HANA or move the data to a sidecar SAP HANA installation. So, in this case, this would be an example of where SAP BW’s advantages would be limited.

Following is a list of reasons why BW could still be needed:

1. Request IDs
2. Hierarchies
3. Variables are better
4. Planning
5. Scheduling loads (although a graphical scheduling tool for native SAP HANA is in the works)
6. The BEx Query designer

Request IDs

SAP BW is a great tool when you need to physically merge data and do not want the performance hit of virtualization. Whenever data is loaded physically into an SAP BW object (and the tables under the covers), the system assigns a sequential ID to all the data loaded. This request ID (or load ID) is just an extra column in the dataset, but it is a key piece to enable the system’s ability to manage the data—for example, if you want to eliminate just the data that has errors without wiping out the entire dataset. Using an order data ID or other ID is not as robust a marker as this request ID concept. Without this request ID, as well as the other options available in the Manage tab of a SAP BW object, administration would be very difficult in a data warehouse relying only on native SAP HANA when data needs to be physically stored. All data administration would have to be done via SQL code, making mistakes all but inevitable.

Hierarchies

Hierarchies allow for a nested roll-up of customers, cost centers, or other objects into summary nodes for analysis and reporting. They come in two flavors in SAP BW: a so-called external hierarchy option and a display-as-rows hierarchical option.

The first option (external hierarchy) is much more robust than the second. In the first option, you use a graphical guided user interface (GUI, transaction code rsh1), to maintain the hierarchy relationships. Basically, using cost centers as an example, you build a tree in which the leaves are cost center numbers, but the branches (called nodes) are any text that you want to use to describe a grouping. These nodes can contain other nodes or cost centers. In the external hierarchy GUI, you can build or move around branches or leaves at will. For example, you can move cost center X from the cost center group East Coast to the cost center group West Coast via a simple drag-and-drop UI. With external hierarchies, the relationships (tree) is separate from the transactional data (cost center postings)

Contrasting this external hierarchy option with the second option (display rows hierarchically) is easy. This second option is tied to the transaction data, so it just allows you to display the columns of data in a nested reporting view in those tools that support this display option. For example, if you have three columns, in this case, Country, State, and Cost Center, and decide to look at the data in a costs-by-country nest, then you simply expand countries to states, then to the city level and finally the cost center details. This type of hierarchy would work, but you’re just altering the display of the data; you can’t make any changes to the underlying data itself. You can’t move one cost center to a different state or city. The only way to show a move for one cost center to a different city would be to actually reload all the data for the 1,000,000 cost center transactions, but now with the cost centers in a different city.

SAP HANA currently only supports the second display rows hierarchically option for looking at data hierarchically, not the critically needed External Hierarchy tool set in RSH1 that allows separately-maintained hierarchies.

Variables

SAP BW and SAP HANA both support the concept of dynamic values for filtering on attributes by adding user input to formulas at run time—for example, by using so-called prompts such as “what year do you want?” or “what percentage should sales increase by?” In SAP BW, these prompts are called variables. SAP HANA, on the other hand, terms them variables when they are tied to an attribute, but calls them input parameters when they are not. In SAP BW these input parameters would be considered formula variables.

In BW, most variables are tied to the InfoObject level (like a field) and they are automatically reusable wherever the InfoObject is involved. For example the What Customer variable is tied to the InfoObject 0CUSTOMER. If the 0CUSTOMER InfoObject is used in any transaction or master data object, SAP BW by design gives the user access to all the variables connected to this 0CUSTOMER InfoObject. This nearly forces or, at the very least, greatly encourages designers to expose the same prompt (variable) to users.  

In SAP HANA, the modeler can build dimension calculation views or attribute views to represent the master data and each one can have different variables; as a result, this makes it harder to reuse common variables. In addition, the input parameters must be created for each view where you want to use them separately. There is no way to have a common input parameter, for example, % Increase, to be available on many different SAP HANA views without building the input parameters again and again.

In addition, SAP BW comes delivered with many SAP-supplied variables for time, such as current month and current year. SAP BW also has options for variables tied to hierarchy nodes (mentioned above) and ones tied to authorizations. These options allow you to autopopulate, for example, which cost centers each user might choose, based on the cost center’s data that users can actually see. Other options, such as pre-calculated value-set-based variables, let you feed a dynamically populated table of values as the choice behind a user variable selection option, all without having to do any coding. 

For all these reasons, I prefer SAP BW’s variables modeling over the equivalent functionality in SAP HANA. Maybe not on its own a reason to keep SAP BW, but rather another good feature that would be missed without SAP BW.

Planning

SAP BW has a very strong planning infrastructure. Since the SAP Business Planning and Consolidation (BPC) and BI Integrated Planning tools have been combined into the Unified Planning application, planning in BW is even more improved. Sales forecasting and financial planning are applications that can really leverage the power of SAP HANA, but they need SAP BW on top of SAP HANA in order to get the most from SAP HANA.

Although there are new SAP HANA-only-based planning applications (for example, Integrated Business Planning) dedicated to the supply chain, and talk of other SAP HANA cloud-based planning applications being released in the near future, until this becomes a reality, and something can replace BPC and BI Integrated Planning, the need for SAP BW for planning still exists. On the bright side, with SAP BW on SAP HANA, planning applications run much faster than on any other current database.

The BEX Query Designer

With native SAP HANA modeling tools, modelers can create both restricted columns and calculated columns. In SAP BW these are called restricted and calculated key figures, and they’re designed in the BEx Query Designer. The issue here is that the BEx Query Designer tool is designed for the business expert, not an IT modeler. With the elimination of the BEx Query Designer, the process becomes much more complex. In many companies SAP BW BEx Query design is done in production quickly. However, the equivalent modeling task in SAP HANA is never done in production because you’re altering delivered views. This is a huge plus in the SAP BW column in the list of SAP BW versus native SAP HANA tools.

This is by no means an exhaustive list, but it’s a good start, and it makes it clear that, in most of these cases, you may still need (or would at least benefit from) keeping SAP BW with SAP HANA. Now let’s take a look at what—if any—advantages native SAP HANA might have over SAP BW and if there are cases where you can get away without having SAP BW.

SAP HANA Modeling Without SAP BW

As I mentioned previously, with ECC (or other ERP suite components) running on SAP HANA as their database (or when you sidecar only ECC data to SAP HANA and do not need much or any consolidation), the SAP HANA tools alone might be adequate, at least temporarily. This would be the case primarily for small companies or mid-size ones that are not likely to acquire other companies or need to merge external data with their ERP data to any significant degree. The options of using ECC without SAP BW are illustrated in the middle and right sides of Figure 2.

So without SAP BW, you miss the features identified in the list above—request IDs, hierarchies, the query design tool, and so forth, but what are some of the positives offered by SAP HANA modeling? Here is a list of the pluses of modeling with SAP HANA without SAP BW:

1. No additional hardware or software is needed to generate views to be consumed by BusinessObjects reporting tools. SAP HANA studio running on an SAP HANA database is all that you need.
2. Information views allow modelers to create calculated columns and restricted columns. As a result, you can derive new data from the existing data in ECC tables.
3. In SAP HANA, information views range from easily created graphical views to more complex coded views that can derive values with extensive logic. Another plus (especially for newcomers to SAP) is that the logic code is SQL-based, not ABAP-based. Because most programmers know SQL before they know ABAP, this might be considered an advantage.
4. With SAP HANA, BW-like currency conversion is built in. For many companies, this ability to easily report output amounts translated to different currencies would be game-changing for a warehousing tool. SAP saw this need and has built the same currency conversion features that exist in SAP BW in SAP HANA.
5. SAP delivers predefined and extendable information views based on SAP ERP suite tables. These views are packaged in a toolset called SAP HANA Live (HA900 SAP training Class). Similar to the BW-delivered content, this allows companies using the SAP ERP suite to ramp up quickly with well-modeled views almost immediately.
6. When tables exist in other systems that need to be integrated in information views, many tools, including real-time ones (e.g., SAP Landscape Transformation [SLT] or SAP Replication Server [SRS]) that do not require SAP BW, can be used to move data into SAP HANA. One new one, SAP HANA Enterprise Information Management, allows graphical transformation of the data in combination with real-time replication.
7. If performance is not critical, legacy data tables can be virtualized and not actually moved into SAP HANA by using SAP HANA’s Smart Data Access feature. Again these are similar to BW virtual cubes, but with the even more technical power to move SQL logic to the source data base, thus moving less code to SAP HANA.

The Take Away

Although the discussion is far from over, using the analysis above, you can determine the available functionality improvements if you have SAP BW powered by SAP HANA as well as ECC. With ECC on SAP HANA, you speed up your normal ABAP reports and make some of them usable for real-time analysis of many records. Native SAP HANA modeling tools give you options for structuring data for fast analysis and direct exposure to the reporting tools (starting with SAP HANA Live content). However, with SAP BW on SAP HANA as well as ECC on SAP HANA, you gain more options, especially if the ECC and BW systems are on the same SAP HANA platform.

You can, for example, merge the SAP BW physical InfoProviders with virtual InfoProviders that are at their core modeled with native and flexible SAP HANA modeling tools. This combines the speed of physically merging external data with the flexibility of leaving it where it sits, when a slower response time is OK. With SAP BW powered by SAP HANA you get the critical BEx Query Designer, which offers business users the tools to create queries with calculations and variables, thereby freeing up the IT department. You also get the advantages of SAP BW’s external hierarchies feature and, most importantly, when you need to manage records physically merged to SAP BW, you get the request ID tools in SAP BW. You have the ability to manage global data, combining it physically or virtually. Finally, companies already running SAP BW can apply the SAP BW security model, without having to rehash the who-can-see-what discussion again.

The end result—happily ever after (Figure 3)—or at least until SAP HANA incorporates all the BW features that currently make it the go-to tool for a global enterprise warehouse.

Figure 3

SAP HANA and SAP BW working together amicably. . . for now

Ned Falk

Ned Falk is a senior education consultant at SAP. In prior positions, he implemented many ERP solutions, including SAP R/3. While at SAP, he initially focused on logistics. Now he focuses on SAP HANA, SAP BW (formerly SAP NetWeaver BW), SAP CRM, and the integration of SAP BW and SAP BusinessObjects tools. You can meet him in person when he teaches SAP HANA, SAP BW, or SAP CRM classes from the Atlanta SAP office, or in a virtual training class over the web. If you need an SAP education plan for SAP HANA, SAP BW, BusinessObjects, or SAP CRM, you may contact Ned via email.

You may contact the author at ned.falk@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.