SAP HANA is an in-memory database, designed to maximize the performance of SAP’s next generation software, S/4HANA. HANA offers significant advancements over previous generations of databases including:
SAP HANA 2.0 has built on the original SAP HANA, providing improvements to database replication, UX and other features.
The term “HANA” has taken on a range of overlapping meanings, which can cause some confusion. The core database itself is called HANA, but businesses also use the term to refer to a system that runs on that database.
SAP users moving to HANA have two basic choices: upgrading their application software (e.g. SAP ERP) to the current generation which has been rebuilt for HANA, or keeping their previous applications for the time being.
For SAP ERP users, the choice is between S/4HANA and Suite on HANA. For companies running SAP Business Warehouse, the choice is between BW/4HANA and BW on HANA. Companies will generally need to upgrade legacy software to the latest version before moving to the HANA database.
SAP’s ultimate goal is to provide all the functionality their users require within S/4HANA. For many use cases, they’re already there. However, there are certain applications and use cases — such as business warehouses — that still depend on an alternate application suite. By 2025, however, they’ll be ending support for legacy software, requiring that all of their customers move to S/4HANA.
What SAP HANA Means, In Short:
Using HANA generally means using the database, along with either the current generation of software (usually S/4HANA), or the previous generation (typically Suite on HANA).
To understand how SAP HANA works, you need a little background in how previous interact with data. Databases are data repositories designed around two essential sets of functionality:
Online Transactional Processing: A transaction is a short step or sequence of steps to record, exchange or process information. When a customer orders a pair of shoes, or a company pays a vendor, the database needs to go through multiple steps to complete the transaction, a process called Online Transaction Processing (OLTP).
For example, to order shoes, the database needs to check inventory, record the customer’s order, obtain personal information (name, address and so on), securely record payment, and inform fulfillment that the order has been requested. Transactions are short and easy to compute, but the database needs to be able to perform a lot of them very quickly and accurately.
Online Analytical Processing: Online Analytical Processing (OLAP) is the process of analyzing and reporting on business data. For example, a footwear vendor might want to run a report on what shoes customers are purchasing to forecast demand for the next period.
The database would need to be able to analyze all purchases over the last quarter, break them down by patterns, such as regional or demographic trends, and compare them to historical data over the last five years. For OLAP to be effective, the database needs to be both powerful and flexible, so that it can answer arbitrary questions about the data, such as “how many New Balance size 12 shoes should we stock next quarter?” or, “how will this new competitor affect our market?”
Historically, databases have used separate systems for OLTP and OLAP. The OLTP data structure would be optimized for quickly performing standard transactions (ideally, at near real time), while the OLAP data structure would be designed to facilitate complex queries and reporting.
Part of the reason was computational limits. Traditional databases stored their data on disks, and could only fit a small proportion of that data in memory. Disks are slow, and the process of loading that data into memory, analyzing, recording the results and grabbing another chunk of data could make reports drag on for days.
Databases have also been row-oriented, meaning they store data by rows. Rows in databases are similar to rows in spreadsheets: they store one set of related data. For example, a row in a data table about purchase history might contain a single customer’s name, date of purchase, items ordered, cost and payment status. This method of storing data is more efficient for OLTP, at the expense of OLAP performance.
The SAP HANA database was designed to overcome the limits of previous generations of databases, with three major innovations:
All of this means an extremely fast and efficient landscape. In many cases, HANA can run reports in hours that used to take days. But HANA is more than just a faster version of the same thing. It has actually advanced the limits of what databases can do.
Speed and a smaller footprint are the most easily quantified advantages of HANA’s design innovations.
But those innovations provide a secondary benefit that’s even more impressive: real-time visibility.
When OLTP and OLAP were kept separate, it put limits on how up-to-date data could be. OLTP was current by definition, but OLAP solutions couldn’t be; they were filled with processed data designed to answer certain kinds of queries, and updating that data took a lot of resources — resources that were usually needed for other purposes.
As a result, companies rarely were making strategic decisions based on current data. At best, you’d get a fairly comprehensive view once per quarter.
However, because SAP HANA has OLAP and OLTP in a single structure, OLAP is always operating on current data. And because it can analyze that data much quicker, that provides something incredible: real-time visibility. A well-designed HANA in-memory database allows you to see, in real-time, what is happening across your business, from broad financial trends or consumer demand statistics, to the fine details of cash flow, inventory and logistics.
Fully harnessing the benefits of a technological advance takes time. SAP HANA’s performance gains made it possible for SAP to change the way it offers business tools, providing more functionality with a smaller set of software, on a system that’s easier and less costly to run. This project is called Simplification, and it’s been ongoing since the release of HANA.
To do this, SAP HANA has been working to consolidate all their functionality in S/4HANA, while providing a path to HANA that’s as simple and cost-effective as possible.
Right now, there are still some use cases that require other software. For example, if you run an SAP Business Warehouse landscape, your destination is BW/4HANA, not S/4HANA. However, by 2025, S/4HANA should support the full range of use cases served by SAP software.
Once companies adopt S/4HANA, simplification becomes a powerful asset. They can move from running multiple applications contained in their own servers, to a single system on S/4HANA.
This reduces the cost and complexity associated with running an SAP landscape considerably. It also enables simple, non-disruptive upgrades and rapid adoption of new features and functionality. If a company changes its business model and needs more powerful logistical support, or better business planning functionality, they won’t need to install an SAP Transportation Management system or SAP BPC — they can enable those features natively within HANA.
SAP promises deeper insights across a wide range of industries. That’s not something you can plug in. Getting better use of your data (and better data) requires an organization to grow and evolve. It requires leadership, patience and most importantly, the right tools.
SAP Leonardo is one of those tools. It’s difficult to characterize, partly because it has so many applications. SAP described it as a “digital innovation system” in the 2017 relaunch, and focused on its core cutting edge technologies.
SAP has designed Leonardo to work in six key segments: Machine Learning, Blockchain, Data Intelligence, Big Data, IoT and Analytics. But Leonardo is as much of a program as it is a technological component. To implement Leonardo, SAP experts meet with business and IT stakeholders and discuss Leonardo use cases. The organization shadows end users to investigate their pain points, then partners to take you through a prototyping process to deliver a solution and then scale it up to production.
The use cases are many — and powerful. For Environmental Health and Safety Management, Leonardo can use machine learning (ML) to help protect employees from environmental hazards. Companies can more effectively monitor sensor readings and track levels of hazardous materials to keep employees safe. For industries involving dangerous equipment, Leonardo can help predict and reduce injuries. By looking at various factors such as user behavior, skill level and the state of the equipment, it can find patterns that might escape a human analyst, and guide the business to safer operation.
Leonardo also has other applications. For BASF, it automated accounts receivable payment. Internally, they were able to automatically match 70% of payments to invoices — a significant achievement, but one still leaving major gaps. SAP Leonardo enabled them to correctly match 94% of payments automatically.
With the Aimickey Shoe Company, SAP worked to bring a very targeted service to market: custom shoe manufacturing. Customers can now have their feet scanned, design their own shoes using an app, preview those shoes in VR and receive them — all within a week.
SAP HANA 2.0 is the successor to SAP HANA. SAP regularly releases updates called "Support Package Stacks," which add new functionality and improvements to HANA. Like installing a new SPS, moving to HANA 2.0 is a fairly routine and easy process that shouldn’t pose significant disruption. However, the changes between HANA and HANA 2.0 are more significant than a typical SPS.
Some of the most important advances in HANA 2.0 have to do with high availability and resiliency. When something goes wrong in a landscape, administrators sometimes joke about “going back in time” to fix it before the original mistake was made.
In reality, that isn’t something you can do in most databases. Erasing data or misconfiguration is a huge problem. Restoring lost data or fixing a broken landscape is disruptive and time-consuming, and you may lose some data anyway. A modern high-availability disaster recovery system can greatly reduce the risks and extent of data loss, but it can’t completely eliminate the risks of a data center outage, equipment failure or human error from disrupting your landscape.
Secondary time travel turns going “back in time” from a piece of wishful thinking to an easy-to-use tool. With time travel, you can start a secondary system (a system used to backup the primary landscape your business runs on) at a previous point in time. If the primary system suffers a data loss, or is damaged by an improperly installed update, you can quickly return it to a previous state using a snapshot. Your administrator can configure when snapshots are taken, and how long previous images of the system are retained, to ensure time travel provides adequate protection while conserving resources.
HANA 2.0 SPS 03 also introduces native multitarget replication, meaning that you can automatically back up your primary system (or parts of it) onto multiple backup systems. For example, you can backup your primary landscape onto an on-premise secondary system, while also creating a primary and secondary backup system at a remote location, or on a different cloud service.
Multiple backup copies can be used to increase resilience against a range of disaster recovery scenarios. The local backup can protect you from a hardware failure in your primary system. If something happens to damage both your primary and secondary system, you can rollover to a duplicate in another data center.
Replication visibility has also been improved. Until SAP HANA 2.0, there was no way to check the size of tables, which made it much more difficult to analyze the way your system is using resources, and plan for growth or data replication. HANA 2.0 provides much more insight into replication, including the ability to analyze the size of data tables.
SAP HANA 2.0 has also improved system administration in a variety of ways. The new SAP HANA cockpit incorporates functionality that was previously separated off in the Database Control Center, providing a more intuitive and transparent tool for admins. The improved cockpit helps SAP HANA administrators manage workloads to ensure the system doesn’t get overwhelmed by demand spikes. It also makes it easier to administer Multitenant Database Containers (systems with multiple databases running on the same set of resources and software).
All of these improvements add up to one thing: a landscape that’s safer, easier and more cost-effective to manage. For the vast majority of SAP HANA 1.0 users, upgrading to version 2.0 should be an easy decision.
For most businesses, the vast majority of functions their ERP software provides aren’t new or cutting edge. They’re things like processing orders, paying suppliers and recording the movement of resources within your business — things you’ve been doing for decades. For these routine functions, the SAP HANA in-memory database provides the high speed, reliability and consistent performance your company should expect from enterprise-class software.
But it’s the next-generation features like real-time reporting, organization-wide visibility and powerful machine learning that take you beyond the capabilities of an ordinary database, enabling your company to stay on the cutting edge.