SAP BW as an Enterprise Data Warehouse and How SAP HANA Changes the Game

I read two very interesting blogs from Steve Lucas (Does SAP HANA replace BW – Part 1) and from John Appleby (Does SAP HANA replace BW – Part 2) and felt inspired to add to the blog my
experience using SAP NetWeaver Business Warehouse (BW) in “Pure Play” and “Mix Environments” scenarios. As a BW consultant, a BI IT executive and
a Reporting and data process owner implementing ‘reporting solutions’‘, I have extensive experience in working with SAP BW, SAP BWA, Teradata, Netezza, and custom RDBMSs data warehouses.

You may wonder way I use the word “reporting solutions” above? In my mind, a data warehouse or an EDW in itself does not present a business benefit and is therefore only a cost center. By expanding the definition of data warehouses,
data marts, and EDWs to include all kinds of reporting (off-the-shelf, analytics, analysis, data mining, dashboards, scorecards, etc.) we are actually delivering business value and becoming a potential profit center.

I would like to share my real-world experience with SAP BW as an EDW in three blogs. My first blog will focus on the technical aspects of SAP BW as an EDW and how SAP HANA will be, as I see it, a game changer. In my second blog
I will focus on potential IT and business cost savings and take a look at how revenue and/or profitability can be achieved in running BW on HANA. My third blog will discuss the governance and organizational aspects needed for making “reporting” successful,
as even many of the most technically brilliant “reporting solutions” have not been sustainable as these solutions did not address “people, process, and technology” in the long run (beyond simple post production care).

Steve Lucas, in his blog, describes possible use cases for SAP BW including BW on HANA as an EDW use case. John Appleby weighs in on this topic by making some great points about SAP BW performance (or the lack of thereof) which
have led many SAP customers today to adopt SAP BWA to meet the EDW needs for many SAP-centric organizations. However, he adds that new business scenarios (such as growing volumes of consumer data) are pushing the SAP BW use cases to new limits that are challenging
to address even for companies that have a SAP BWA solution in place.

My first SAP BW experience was with version SAP BIW 1.2b. At that time, implementation teams were just happy that they were able to reduce the stress on SAP R/3 COPA, SIS, and LIS systems that regularly brought SAP R/3 (SAP ECC)
to a stand-still. The BW teams could help customers solve their technical and business reporting issues quickly (i.e. helping them to understand their information to make better business decisions). But I would argue that these issues were not adequately resolve
with earlier versions of BW. With constant evolution though, BW matured and seemed to be ready for “EDW prime time”. During that period of evolution, I was tasked to assemble a team that would be able to simplify the data warehouse landscape of a Fortune 15
wholesaler using as much as possible the SAP provided business content in both SAP R/3 (SAP ECC) and SAP BW.

This project was both technically challenging and a huge business transformation. The corporate direction in transitioning to the use of SAP business processes, terms and definitions enabled the organization to rely on the SAP standard
business content significantly. However, performance was an issue not only in SAP BW but also in SAP R/3 (SAP ECC) systems. Additionally, the SAP BW EDW needed to take over
operational reporting (transaction granularity), analytics, data mining while feeding a legacy RDBMS for data transmission purposes. The SAP R/3 (SAP ECC) system was 98% utilized for transaction processing.

To handle data loads, it was necessary to consequently apply data warehousing concepts and applying them to SAP BW. The implementation team designed a custom ODS staging layer for “raw” transaction data, developed data distribution
mechanism to semantically partition storage and reporting objects (ODSs and InfoCubes), and introduced the MultiProvider as the layer for flexible reporting, analysis, and data mining. In addition, it was required to implement physical database partitioning
and database compression on the RDBMS level. You might make an argument that this sounds like developing a custom EDW. While I agree with this statement to a certain point, it is important to point out that leveraging SAP business content (and data warehouse
management processes) reduced deployment time significantly! Using the predefined tools SAP provided enabled the project team to get a head start and deploy a 40TB ready SAP BW EDW in nine month with subsequent frequent reporting solution releases over a three-year
period. I am happy to say that, in my view, the SAP BW EDW solution remained relatively simple, and most importantly, the reporting solutions created significant business benefits.

In looking at the evolving maturity of SAP BW over the years, let’s look at another example of a BW customer that I worked extensively with in the past. This customer leveraged SAP BW for its wholesale operations on a global scale.
Here it was necessary to not only meet all the same reporting demands but also the needs of Internet online stores, integration and feeding of non-SAP systems with SAP and non-SAP data on a global scale with distinct load and up-time requirements. This required
an expansion of the concepts described in the earlier paragraphs. The expansion of the concepts was necessary due to the hundreds of millions of data rows that were received daily from an SAP ECC industry solution and then distributed to the SAP BW EDW, legacy
data warehouses and transaction systems. Performance and data management goals were achieved by separating the SAP BW EDW layered architecture into separate SAP BWs. A high-availability staging SAP BW was implemented to which all data warehouses and operational
systems could subscribe. Additionally, a high-performance operational reporting SAP BW provided high-speed reporting access at defined and guaranteed SLAs to Internet online stores. At massive transaction level SAP BW was used to integrate SAP and non-SAP
data into a “Corporate Memory” which was termed the “Single Version of Truth” for the corporation. Lastly an analytical SAP BW was available for off-the-shelf analysis, data mining, and disposable reporting solutions. This approach allowed the company to build
a “logical SAP BW EDW” that met, in my opinion, performance, loading, and reporting requirements – but barely so. Many of the concepts that were developed for facilitating the distribution, management and reporting of data made it into the SAP BW 7.x and SAP
BWA product suite. I would argue that even today, now boosted by the SAP BWA, this “logical SAP BW EDW” is working and performing as designed.

However, I would like to stress that this “logical SAP BW EDW” described above was mainly possible through extensive IT involvement (“engineering marvel”) that would be worthwhile to be shown on the Discovery Channel. It was necessary
to employ the best and the brightest SAP BW and data warehouse folks to design, build, and maintain the system. However, I believe that “complexity kills the cat” as the maintenance and retaining of talent became a significant factor which is a challenge for
any sustaining IT organization.

However, I also came to the conclusion during this time that using non-SAP RDBMS solutions was never a realistic alternative to SAP BW. When trying to use these technology platforms, it was possible to engineer for performance but
difficult to re-engineer the 30 years of SAP business solution knowledge and the 10+ years of SAP BW business content capabilities. I found that the costs for business solution integration and data integrity on a non SAP BW EDW platform were too prohibitive
for an SAP centric enterprise.

Before I finish part 1 of my blog by painting the vision of SAP BW on SAP HANA as an EDW game-changer, I would like to share one quick examples on how SAP BW 7.x and SAP BWA significantly reduced the technical complexities of the
previous two examples.

Implementing SAP BW as an EDW became much easier with the advent of SAP BW 7.x and SAP BWA. As an example, in working with manufacturer with strong retail and consumer focus, I was able to not only leverage the SAP business content
but also all the advanced data warehouse management functions from Process Chains, Data Staging, and to Semantic Partitioning. Finally, one could fully focus on the business reporting solutions and not worry as much about technical performance. With the help
of BusinessObjects reporting suite of tools and the SAP BWA, the SAP BW EDW solution was able to provide predictable and reliable performance to business functions. The SAP BW EDW was fully business mission-critical but data load performance remained a watch
item. John Appleby, in his blog, points out that SAP BW as an EDW has two issues “working” against it:

Increase data volumes
Increased performance expectations driven by iPhone and Google type of uses cases

At this manufacturer I experienced similar issues. It was possible to mitigate reporting performance by using the SAP BWA and carefully architecting the BEx and BusinessObjects reporting solutions. However, the expansion of business
cases/use-cases to include consumer data created new challenges. Consumer data was needed for

Retail sales reporting in country, regional, and brand offices
Consumer analysis and sentiment reporting of various marketing and R&D functions
SIOP and integrated financial planning

This “new consumer centric” data that was traditionally not even modeled in SAP had to be loaded into the SAP BW EDW. It was required to design new SAP Master Data objects, which sometimes “collided” with standard SAP BW definitions
that are governed by SAP ECC. Extensive data transformation rules had to be designed in globally distributed POS systems or ETL tools which made daily timely loading a challenge. Furthermore, if Master Data issues occurred, data loads had to be stopped in
some cases or manually addressed by non-business knowledge aware support staff. This created a constant risk for delay or potential for incomplete data.

In my opinion, using SAP HANA as the foundation of the SAP BW EDW will be a “game-changer” in the scenarios described above. As the SAP HANA Data Services and SAP BW ETL functionality is moved into in-memory, loading times are significantly
reduced. The layered data warehouse architecture can be simplified by “virtualizing” InfoCubes as much as possible. One consideration could be of potentially having transaction level granularity (in InfoProviders) as the source for the “Corporate Memory”,
“Single Version of Truth”, and reporting solutions. This simplification reduces time-to-deployment, simplifies technical designs, and provides the opportunity to leverage more commoditized support staff. For example, SAP BW on SAP HANA would allow for fast
loading of POS sales data into SAP HANA, easy data cleansing within SAP HANA using Data Services, and integration of the POS data with Supply Chain/Finance data at the relevant “data visibility” level – all within one simple SAP BW EDW on SAP HANA.

From my perspective, most importantly, SAP BW on SAP HANA would allow for the design of non-SAP data models within the same SAP BW EDW leveraging both SAP BW’s and SAP HANA’s native strength to their fullest extent. Complex detail
consumer information for consumer behavior analysis can reside in the SAP BW EDW without interfering with the referential integrity of SAP ECC driven master data (consumer data is inherently unclean and incomplete). Cleansing algorithms can be run using SAP
HANA Data Services technologies to cleanse and complete data necessary for SIOP or sales reporting while marketing can quickly respond to consumer behavior by analyzing and changing marketing campaigns in real-time. I believe that this example becomes even
more exciting if on-line consumer information is included into the mix.

I believe that with SAP BW on SAP HANA it is now possible to take advantage of SAP 30+ years of business experience and the SAP BW business content and combine it with the power of SAP HANA in-memory technology and BusinessObjects
capabilities thereby allowing companies to leverage SAP’s and their own investment in SAP BW even more so in the future.

Stay tuned for my second blog as I discuss the IT and business cost savings in running BW on HANA and take a look at how revenue and/or profitability can be increased.