- HANA is usually discussed by those that promote HANA.
- Why it is essential to separate the generalized statements from the specific improvements.
As anyone who works in SAP knows, HANA has been the largest SAP marketing point of emphasis for several years now. However, much of the information comes from a one-dimensional perspective, one that is more promotional in nature than focused on enhancing the understanding of how and when HANA is appropriate to be deployed.
See our references for this article and related articles at this link.
This article is intended to help readers apply a framework for asking the right questions about HANA.
What is SAP HANA?
If one could sum up HANA briefly, it is accurate to say that it is essentially a combination of moving the application and data to solid state device drives (SSDs) from hard drives combined with attempting to move clients that currently use Oracle databases over to Sybase (SAP’s acquisition). SAP uses the standard argument that they are better integrated and will lead to higher performance. This part of the program is false, as Oracle has been providing useful databases for SAP applications for decades – and is nothing more than a sales program to increase sales of Sybase. As for the first part of HANA, software vendors like Teradata have been moving to SSDs for some time – without developing an enormous marketing program, the SAP has for HANA. We began only purchasing SSD based computers around four years ago, but we did not put out a press release.
A History of False Assertions
SAP has a long habit of misinforming its customers on technology, and HANA is merely another example of this. It also has a dangerous aspect to it that is described in the following bullet points:
- Future Selling: HANA will be used (in fact, is being used current) to provide false hope to many problematic SAP implementations. As in “If you are concerned right now, don’t worry because HANA is coming.”
- Confusion as to HANA Benefits: HANA, which is isolated to the hardware layer, is generalized to improve the actual application – such as its business logic. HANA has nothing to do with business logic, but SAP is implying that it is, and KPMG is not educating its clients as to why this isn’t true.
Item #1: Working Out HANA’s Expense
HANA is a solution, which is more expensive than other alternatives. There are several reasons for this. First, HANA uses more costly hardware. Much of the performance boost in analytics is due to hardware upgrades, a fact which we cover in the article How Much is Hardware Responsible for HANA’s Performance. Outside of hardware, it is difficult to determine any performance improvement with HANA, and HANA underperforms competing databases even at a far lower cost, one area of performance issues is what we cover in the article How to Understand Why HANA is a Mismatch for S/4HANA and ERP.
Secondly, it is more expensive because of the premium that SAP charges for HANA software. This is covered in the article How to Understand the Pricing of S/4HANA and HANA.
Thirdly it is more expensive because HANA is still being worked out under the covers, and this means more implementation complications than other SAP alternatives that have had more implementations.
Fourthly, in cases where HANA is implemented for an already live system, it means making a change and changes cost money. Something which I have yet to see elaborated upon in print is something that I think is quite obvious and that is that anyone can gain more performance by increasing the input or investment into a domain. But it is essential to mention that the input/investment is different when making statements regarding improvement. As an example, I can say that a Maserati performs better than a Honda.
However, if we leave the price out of the equation, then it’s not a fair comparison. Too many articles and conference presentations give little attention to costs and instead are entirely focused on explaining the benefits of HANA. One recent article that I read showed the cost savings that come from HANA from the improved capabilities that a company would obtain, but nowhere in the article were costs discussed. It almost appeared as if HANA, along with its implementation, were simply free.
Item #2: Different Benefits Per Application
There is no doubt that business intelligence applications benefit significantly from HANA. But outside of this single processing type, HANA underperforms the other alternatives. And SAP is recommending HANA for all applications, whether their primary processing type is analytics or not.
And this means that more implementations have occurred for SAP BI than for other SAP applications, and using HANA for SAP BI is much easier because of how business intelligence applications work versus transaction processing applications like SAP’s ERP system, makes the effort involved in migrating to HANA far easier. Secondly, the benefits differ per the type of application.
For this issue analyzed from multiple dimensions, see our article archive on HANA on BI/BW.
Item #3: Part of HANA’s Benefit is Simply Buying Faster Hardware
Part of the benefits that SAP is isolating to HANA is a natural transition to simpler data structures that interoperated with improvements and cost reductions in random access memory and solid state memory. But SAP has massively oversold the changes to actual usage. Even before HANA was introduced, the biggest bottleneck in analytics systems was not processing time, but the problems around the complexity of report or analytics creation. HANA does not address this. It reduces the work in creating star schemas, but that was also not the bottleneck in report creation.
SAP decided to make HANA their central marketing pillar by focusing on this change –, replacing the previous marketing platform of “NetWeaver.” However, we can learn quite a bit by analyzing the history of technological improvements in information technology. The servers that are presently being purchased for business intelligence applications may have 500 gigabytes of RAM in addition to multi-terabytes of solid-state storage along with the traditional hard storage. However, even servers with these types of specifications are not particularly expensive anymore. With this type of capacity, it makes less sense to place data into cube structures to enhance query performance. Therefore, much of what SAP is doing with HANA is just taking credit for the work of hardware developments, that are available to all software vendors.
Whenever hardware makes a great leap forward, it takes time for the software to unwind the complexity that was built into it to accommodate the previous generation of hardware. So companies that no longer need the cube structures they have created will continue to use them – only because it takes more time to pull the data out of cubes that they have already built and place them into simpler structures. Hardware can change a lot faster than software.
HANA does not Mean Benefits to All Application Elements
As a person that works both the sales side and the implementation side, I have reservations about how HANA is described as improving every facet of SAP’s applications. For salespeople, it is generally desirable to be able to make these statements. But it sets up implementation problems because implementation must manage highly-generalized expectations for improvements in too many areas. While it may be considered visionary to generalize the benefits of HANA, applications are a series of moving parts that each has their own heritage, the current state of development and impact on the function of the application. HANA is an infrastructure element, a good analogy being the suspension of a car. To take this analogy further, most people would intuitively understand that improving the suspension of a vehicle does not improve every other element of the car’s performance. Quite obviously, it does not make the engine more powerful or improve the radio or the visibility from the driver’s seat.
Some other areas may improve – for instance, a better suspension can have a positive effect on the steering/controllability of the car, but the specific improvement to other elements should be explained in terms of the cause and effect and not merely assumed. However, statements regarding HANA’s speed improvement are quite frequently generalized to improve all other areas of the application without any specific explanation as to why this is the case. In the same way, HANA has no impact on the business logic of SAP or its user interface.
HANA puts infrastructure at the center of the conversation, but the infrastructure cannot continually be the center of the conversation because it is only one piece of the puzzle. And so far, SAP has presented no compelling evidence that their database is superior to the databases of competitors, which is not all that surprising as SAP is a database novice.
A Specific Example of Falsehoods About HANA for Supply Chain Planning
In addition to providing false information around the technology capabilities of HANA, SAP, and SAP consulting companies have been providing incorrect information around business benefits. This example will demonstrate how SAP’s claims can be deconstructed.
Here is the quotation from an SAP sourced blog article:
“Our customers adopted HANA for its ability to deliver significant net new business value. For example, a customer used HANA as an agile datamart to predict potential out of stock situations during promotional periods by analyzing several millions of rows of point of sale data. The business benefit of this use case is improved forecast accuracy and more precise replenishment. For this customer, the POS analysis helped them successfully predict potential out of stock situations thereby, increasing customer satisfaction and revenue. More importantly they were also able to reduce their replenishment lead time from 5 days to 2 days resulting in lowering inventory levels in their supply chain. What is it worth to you if you can remove a day’s worth of inventory from your supply chain? What is the impact on your working capital? There are numerous examples like the one above across our customer base where HANA was able to unlock significant net new business value.”
This story does not hold up to scrutiny, but let us break it down to specific points:
- Promotion Planning
- Promotions Come from Sales/Marketing
- What Happened to Replenishment Lead Times Again?
- What Benefits Accrued?
The datamart that was created is referred to as promotional forecasting.
Most companies perform promotional forecasting very poorly, but there is little reason to create a data mart to do this because promotion forecasting functionality exists in forecasting applications. I have a soon to be published book on promotions forecasting, and if someone, were to propose creating a data mart to perform promotions forecasting the first question I would ask, is “why.” Applications already exist to manage promotions, although it is true that neither ECC nor DP is the right tools for the task.
There is no law that states that a company must use SAP applications where there are more suitable applications. Why was this company creating a data mart to review data that is not useful for promotional forecasting when there are so many other tools available for the job that is designed to do this.
Secondly, this type of analysis is not very processing intensive. Even if the company wanted to build a data mart, they would not need an analytical database like HANA to do so.
This is an abysmal example of how to leverage an analytical database.
Promotions Come from Sales/Marketing
Promotions are known within the company — as they are creating the promotion (unless the intent here was to determine the promotional effect of competitor promotions — which is unlikely). The promotional result of previous promotions — which can then be used to create uplifts is already in the demand history.
How analyzing POS data helped this company determine stock out likelihoods is extremely difficult to understand.
What Happened to Replenishment Lead Times Again?
Lowering inventory levels in the supply chain does not reduce replenishment lead times. The two just don’t have very much to do with one another.
If the supply chain was so filled with inventory, requiring extra trucks to be kept in the warehouse yard such that it interfered with getting product through the supply network, or material was stacked in aisles so that workers could not get through the aisles, then that is a broader issue of incompetence on the part of supply chain operations. This is an SAP resource who is guessing on topics which they don’t understand.
What About SAP’s Page on HANA?
How much accuracy can be found on SAP’s web page on HANA?
Let’s take a look.
Quotes from the SAP’s Main HANA Page
What is HANA?
Deployable on premise or in the cloud, SAP HANA is an in-memory data platform that lets you accelerate business processes, deliver more business intelligence, and simplify your IT environment. By providing the foundation for all your data needs, SAP HANA removes the burden of maintaining separate legacy systems and siloed data, so you can run live and make better business decisions in the new digital economy.
Almost all HANA instances are on premises. So while SAP often presents the idea of such broad choice among its offerings, customers are not choosing to use the cloud option SAP’s non-acquired offerings.
It is not at all clear that HANA simplifies the IT environment. The proposal is that all applications can reside on a single HANA instance. However, even if this were desirable and feasible, HANA is too expensive to manage this way. HANA is the most costly database in the market (at Brightwork, we maintain the ability to price HANA accurately, unlike how SAP will price HANA using some inaccurate assumptions. Part of this is covered in the article The Secret to Not Talk About HANA Pricing.) But even if HANA were lower price, it still would not necessarily make the IT environment more simple. The change-over from the current databases being used adds complexity to the IT environment. And information from HANA implementations is that HANA has a lot more maintenance costs than competing databases.
SAP said this also about their ERP system in the 1980s, and none of those predictions came true. The concept was that SAP’s ERP system would eliminate the need for all legacy systems, as is covered in the article How SAP Used and Abused the Term Legacy.
Key Benefits of HANA
Simplify IT with ONE platform for trans-analytic applications. Use SAP HANA to analyze live data to support real-time business, while reducing data redundancy, footprint, hardware, and IT operations.
No, there is no evidence of this occurring. There are no case studies where customers have moved most of their applications to HANA. Secondly, HANA is a single purpose database, and it is designed for analytics. AWS, a PaaS that provides many databases does not offer HANA type databases for all applications. Instead they provide specific databases for specialized application. Transactions, Analytics, Big Data, are not optimally served from the same database type.
Modernize your data center with flexible SAP HANA deployment options – public or private
cloud, tailored data center, or 1000+ certified appliance configurations from 13 leading vendors.
HANA is in almost all instances deployed as an on-premises delivery model. SAP has a lot of options, but those options are not particularly relevant because they are not exercised but customers.
Achieve better business outcomes with SAP HANA. Learn how companies are seeing 575% five-year ROI by using SAP HANA to increase innovation, while decreasing data management costs.
SAP has never provided actual evidence for any ROI claims. HANA is the most expensive database that can be purchased, so having this type of eye-popping ROI on such a costly database would be peculiar.
Key Capabilities of SAP HANA
SAP HANA transforms database management. It processes transactions and analytics in-memory on a single data copy – to deliver real-time insights from live data. And simplify operations with modern tools and a secure, rock-solid foundation.
Evidence from the field indicates that HANA has performance issues with transactions, which is most of what any ERP database does. SAP stopped performing the transaction processing benchmark, as is covered in the article, What is the Actual Performance of HANA?
SAP HANA transforms data management. Access quality data wherever it best resides using data virtualization, integration or replication. Manage data across multi-tier storage to achieve best performance and total cost of ownership.
SAP has no studies that show that HANA provides a better TCO. Forrester produced a study, sponsored by SAP that stated that HANA might reduce TCO, but it was not based in any evidence of actual HANA implementations. It is considered by Brightwork to be an illegitimate study.
SAP HANA transforms analytic intelligence. Use advanced data processing for business, text, spatial, graph, and series data in one system to gain unprecedented insight. And deliver deeper insights using powerful machine learning and predictive analytics capabilities.
This is again unproven by SAP. Transforms is a significant word that SAP uses quite frequently, but which it does not provide evidence for. SAP is very often using the term digital transformation, which is illogical for most IT implementations as is covered in the article The Problem with Using the Term Digital Transformation for Modern IT Projects.
Simplify application development with in-memory computing
IT and software development professionals view in-memory computing as a viable option to increase simplicity and real-time performance. Discover how in-memory computing can spur the creation of custom-built applications to meet distinctive needs and enable integration across the enterprise.
SAP seems to be blending several concepts here. These include the following:
- Real-time performance
- In-memory computing
- Custom build applications,
- Integration across the enterprise
However, the only terms that have anything to do with HANA are real-time performance and in-memory computing. The rest as simply being added willy-nilly to the sentence. This is a common tactic by Hasso Plattner, which is to simply throw so many terms at the reader that they become overwhelmed.
Built on SAP HANA, SAP S/4HANA is a next-generation business suite designed to help customers thrive in the digital era. Digitize and simplify your processes – and provide a personalized user experience with the SAP Fiori UX.
SAP’s accuracy on S/4HANA is covered in the following article.
SAP Vora is an in-memory, massively distributed data processing engine that allows you to analyze Big Data stored in Hadoop. Use it to gain real-time, relevant insights that support faster and more informed decisions.
- Process and analyze Big Data in Hadoop
- Correlate Hadoop and SAP HANA data
- Organize massive volumes of unstructured data
This will be covered in a future article dedicated to Vora.
SAP BW/4HANA is an integrated data warehouse solution optimized to fully leverage the SAP HANA in-memory platform. SAP BW/4HANA dramatically simplifies development, administration and user interface of your data warehouse resulting in enhanced business agility.
- Simplify your data warehouse architecture
- Integrate SAP and non-SAP apps and data into one logical data warehouse
- Built for on-premise and the cloud
This will be covered in a future article dedicated to SAP BW/4HANA.
This SAP article has a Brightwork Accuracy Score of 2 out of 10.
To get value from HANA, companies must move past the generalities that are often applied to HANA to the specifics. The specifics include the price of HANA for each area that it is applied. Not all applications are going to be moved to HANA, certainly not in the next few years. So which applications should, and what is the cost-benefit analysis for doing this, is an important question to ask. For most companies, the first place to implement HANA will be in their analytics.
Secondly, statements that generalize the benefits of HANA to every aspect of the application should be disregarded and emphasis given to statements that show specifically both how and why HANA will improve specific areas of the application, which should then be estimated in terms of business benefits. Being able to improve query performance by a factor of 1000 sounds great. But it may not be the primary problem that company has, and other shortcomings, such as the configuration of the system or the understanding of the functionality within the application may be far more pressing concerns. Technology improvements are much easier to estimate than business improvements. But technological improvements do not necessarily lead to proportional business improvements. As an example, increasing the horsepower of a car from 150 horsepower to 300 horsepower has little effect on the average speed that car is driven. This is because other constraints – ranging from speed limits to traffic, to physical laws regarding how a car can be driven without crashing into something still exist after the engine has been replaced. By purchasing HANA and investing more resources, queries can no doubt be performed more quickly. However, there are many things that an implementing company wants to improve, and this is only one area of focus. Investments in HANA must be traded off against other investments that improve other areas of the technology landscape that are also important. This logic applies not only to HANA but to any improvement that a company would make to its systems.