Is HANA the Right Choice for Being an EDW?

Executive Summary

  • There is the question as to whether HANA is appropriate for an enterprise data warehouse.
  • SAP has a strategy for discounting HANA that connects to their overall strategy.
  • HANA and BW can be compared to the enterprise data warehouse.

Introduction to HANA for EDW

SAP has been proposing HANA for a new purpose, namely to serve as the database for the customer’s EDW.

Is HANA a good choice for the Enterprise Data Warehouse? In this article, you will learn about the issues with using HANA in this way.

SAP’s Strategy with Discounting HANA

For the longest time, the policy on HANA was not to discount HANA. This topic is covered in the article How SAP is Now Discounting HANA (Maybe). For the longest time, HANA was targeted towards smaller databases. SAP has been falsely proposing that HANA could shrink the data footprint by 98.5%. This has turned out to be false, as the actual shrinkage is closer to 1/3. This topic is covered in the article How to Best Understand the Price of HANA.

However, with SAP’s recent change to discounting HANA (depending upon whether it decides to drop an indirect access claim on the customer later, as covered in the article the HANA Police and Indirect Access Charges), it has meant that SAP has begun proposing HANA to used in new applications. One of these applications is for theEnterprise Data Warehouse.

What is the Enterprise Data Warehouse?

The EDW stands for the enterprise data warehouse. If we look at the most common implementation of HANA, it is for the SAP BW or the business warehouse. If you check the definitions of theEnterprise Data Warehouse and the DW, they can be roughly considered synonymous with each other. So one might say if HANA is commonly used for the SAP BW, then why is this a change?

Well, the SAP BW is not a data warehouse in that it is not the singular storage location for all of a company’s data. The SAP BW typically stores the SAP data of a company. SAP would like to think that this is all the data that a company has, but SAP is always only in control of a portion of the data that a company has. Other applications (packed software) as well as internally developed applications (that SAP likes to derogate as legacy, as is covered in the article How SAP Used and Abused the Term Legacy, always exist, and they always will.

Therefore, while the SAP BW has designs on being the singular storage location of all data in a company, it never is. Consequently, it is not the Enterprise Data Warehouse. Secondly, EDWs have a series of requirements that the SAP BW does not serve very well. For one, companies that use SAP BW have such difficulty meeting the backlog of the queue of reports that the group that manages the SAP BW is typically on restricted access. They could not think of picking up more work, and managing more data even if they wanted to. Overall, the efficiency issues with the SAP BW prevent it from expanding beyond its specific role.

HANA for the Enterprise Data Warehouse?

None of this background has stopped SAP from proposing companies use HANA as the EDW. And when SAP proposes using HANA for the EDW, they also mean utilizing an SAP data application to sit on top of HANA.

  • Expense: The first problem is that HANA is still so expensive that it is not financially feasible in most cases to push so much data inside of it. HANA’s high TCO is not merely related to its license cost, but to its hardware requirements, its high implementation and maintenance overhead, the difficulty in finding experienced skills and its immaturity.
  • 100% In Memory for an EDW?: Much of the data in an EDW does not require the performance capabilities of an in-memory database. In memory databases only make sense for supporting databases that have a high query volume, not data stores that are used to feed the queried database.
  • Migrating All Data to Column Oriented Tables for Storage?: Most data in companies is not stored in the column-oriented tables that are used in HANA. For this reason, moving data into a HANA “powered” Enterprise Data Warehouse would mean changing the data from its original storage structure into the HANA structures. This is an unnecessary and overcomplicated amount of work and overhead to maintain before one even gets to the question of what SAP product should be used. SAP BW is too high in overhead to be an effective EDW tool, and Business Objects has been so starved of development by SAP, that it is no longer an application that companies should be considered for investment due to competitiveness and support issues. And once one eliminates these two data applications, there is nothing else that SAP offers that could fill this role to interoperate with HANA, even if HANA were a good choice for being the EDW database.

Conclusion

SAP is trying to pitch HANA for things that don’t make very much sense. SAP has been pressing on using what a single database type, the column-oriented design for virtually any application is. And proposing HANA for a customer’s EDW is another example of this.

Brightwork Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

https://www.sap.com/products/hana.html

The Risk Estimation Book

 

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model