- SAP proposes that HANA’s technology is unique to SAP, however, it isn’t.
- SAP has also generalized the column-oriented performence in analytics to the other types of processing the database performed.
Introduction Locating Performance Improvement
HANA is often represented by SAP as if it’s underlying technologies are unique to SAP, or they were invented by SAP. Repeatedly terms like “innovation” have been applied by SAP to HANA.
SAP has presented HANA as so unique that customers should be prepared only to run the new ERP system — S/4HANA on HANA, and that S/4HANA will not ever be ported to any other database platform. As the vast majority of SAP ERP systems currently run on Oracle, that is quite a bold stance.
SAP’s Proposed Reasons for Its Position
SAP proposes that the reason for taking this position is the following:
- No other database vendor can match SAP’s performance.
- SAP has moved code — called stored procedures — into the HANA database, and by implication, that the application is now tied to the database.
- SAP has been more obscure about other applications outside of ERP, but SAP desired state is only to replace other databases with HANA so that it’s applications and its databases are tied at the hip.
What is HANA and Is the Technology Unique to SAP?
What is HANA? Well, HANA is a columnar oriented database. But what SAP does not explain is that all the other major database vendors have some similar design available. In fact, columnar databases have been in existence since the 1970s. What changed was that the price and capacity of random access memory or solid-state memory had improved so significantly that the database design can now be better leveraged. Interestingly with Oracle 12c, a competitive database can not only match HANA in analytics, but it can switch between row based and column based tables and change for the same table.
Now that SAP has a competitive product with Oracle’s database, the issue of SAP not issuing the certification to Oracle has arisen, something that is explained in the article Which is Faster, HANA or Oracle 12C?
Columnar databases have their advantages. However, they are not universal benefits. SAP HANA is presented by SAP as a universally advantageous combination of database design combined with faster memory/storage. The less one knows about databases, the more this seems credible.
What Improves with the Columnar Database?
While it is true that a columnar database is a radically different a row-based table database, and the differences do not stop at the configuration of the tables – it also means the use of fewer indexes. This is a positive development for database cost because building indexes for analytical purposes is a source of overhead and rework for companies that use standard relational databases for analytics.
This means that by breaking the table into one file per column, the database stored in random access memory or solid-state memory can access only the fields that are part of the query.
Now queries that only pull two fields, perform much faster than queries that pull four areas. And this example has been when a table contains ten fields or columns. However, tables much larger than this are very common.
It is not at all uncommon to find tables with 100 fields/columns. On average, a query will have between 3 to 5 fields/columns.
An Important Lesson on SAP HANA Benefits
As I explained in this previous article titled Has SAP’s Relentless HANA Push Paid Off?, I brought up the fact that SAP has redirected its marketing efforts to focus to a very significant degree on SAP HANA
SAP HANA does not benefit every business function equally, because not all functions of activity are a bottleneck due to speed limitations, and SAP HANA does not work the same way regarding its speed for every application.
- To understand the benefits of SAP HANA, as well as its limitations, it is necessary to get into the computer science of what makes up SAP HANA.
- A solution like SAP HANA allows businesses to do things that it could not do before, so some forecasting or projection is required to fully leverage SAP HANA because merely doing the same things one is currently doing faster is not where the opportunities with SAP HANA lay.
A columnar database like SAP HANA is not at all new. Most of what I have written above was true decades ago. However, the difference is that columnar databases have a particular advantage when used with memory versus disks. This is due to how the media is read, and it turns out that a database with “narrow” tables — (the narrowest being 1 column) combined with that database being stored in memory makes for very fast retrieval. However, this is an analytics purpose. And not all computational functions are analytical.
While all data actions improve with faster hardware, specific actions are better or worse depending on the type of action taken. Therefore, it should be specified that the column based database is only optimized for the data retrieval action.
HANA’s underlying technologies — in-memory databases and the column-based database (as opposed to the row based) were not invented by SAP, and the techniques are not unique to SAP.
- It is incorrect to propose columnar databases as a newer design since both columnar and row-based databases have been around for about the same amount of time — it is merely that columnar databases were never accessible or attractive.
- With the ability to use more significant amounts of memory, columnar databases, or emulated columnar databases have begun to receive more attention, but outside of SAP, this attention has been almost entirely for use in analytics. SAP is the only software vendor that proposes that columnar databases are better for all applications.
Below is a video that explains columnar databases. You will note that the presenter is a professor and does not use the term HANA anywhere in his explanation.
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.
I cover how to interpret risk for IT projects in the following book.
The Risk Estimation Book
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.
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