Skip to main content

The true costs of implementing SAP HANA

If you want to harness SAP HANA to tackle your most critical data questions in near real time, get ready for a steep learning curve and significant cash outlays. But there are several lower-impact approaches to bringing the benefits of SAP HANA to your organization.

When it comes to high-speed, in-memory databases, there are few platforms that have the power and scale of SAP HANA. Whether it’s real-time analytics or a marketing application driven by live transaction data, SAP HANA has become the database platform of choice for thousands of enterprise customers. 

However, when it comes to implementing SAP HANA, the journey can be overwhelming. It’s not just the expense of the hardware, software, and other infrastructure components. There’s a vast learning curve associated with SAP HANA, and many companies do not have the in-house skill sets required to do it right. 

Fortunately, there are ways to reduce the pain of setting up and maintaining SAP HANA. I’ll describe some of the considerations before laying out alternative pay-as-you-go models.

Data is the new currency, but quick access is a must

Thanks to the ongoing proliferation of sophisticated applications, devices, sensors, and networks, companies now have data available to them that were practically unimaginable a decade ago. 

Every company has so much data, and it's really difficult to get anything valuable out of it in a reasonable time frame. The physical limitations of a spinning disk or network connection inhibit the speed and scale of traditional databases and the types of queries that can be performed on large datasets. This is why in-memory databases like SAP HANA are so important for mission-critical ERP, CRM, and big data applications: They let companies analyze huge amounts of data and get information and insights in near real time. 

For example, take a national retail chain that has hundreds of locations. The top-selling items in one city might be completely different from the top items in another location. Should management order an analysis to determine why one store is more profitable than the other, the database application will have to comb through millions of rows of data, including transaction records, product lists, pricing trends, and marketing history. 

Your blueprint to transitioning to an IT as a service structure.

If the application has to rely on a physical disk or cloud storage to access that information, the queries may take hours to run. With an in-memory database, the application can access the information lightning fast. You can get answers to your questions in closer to real time, rather than having to wait. 

Moreover, the speed and potential scale of the SAP HANA platform opens up the possibility of new types of applications and automation, ranging from targeted advertising to supply chain optimization, all performed in near real time.

The costs of using SAP HANA

SAP HANA can deliver major benefits to companies that use it, but there are costs to consider. 

The obvious ones relate to the hardware itself. Memory is expensive, and SAP HANA uses a lot of it: A single instance may require 4, 6, or even 12 terabytes, not to mention standby nodes that can kick in when a failure occurs. 

On top of that are the costs associated with setting up and managing the platform. This goes beyond SAP’s licensing requirements. Highly skilled IT professionals will have to be brought on board if things are to be managed in-house. System programmers will need to update the operating system software, applications, and firmware patches. Network support staff will have to maintain the networks. Specialized workers will need to perform capacity planning to ensure the system can deliver the required response time to internal customers. The fully loaded cost of a dedicated employee to perform these kinds of work may top $170,000 per year. 

The learning curve is steeper and the costs even more pronounced for companies migrating from other platforms. A company moving from Oracle or MongoDB will effectively be changing the way it does business. This means switching out the entire stack, including the applications and the database itself. The data may be the same, but it will have to go through a transformation process to work in the SAP environment. 

In the future, many companies with SAP applications running on other database platforms won’t have any choice but to use SAP HANA. The company has declared that all SAP applications (including the Business Suite ERP system) will have to be migrated to its next-generation platform, S/4HANA, by 2025. 

It should come as little surprise that companies tend to balk when presented with the initial cash outlays and operational costs required for rolling out SAP HANA on their own. It’s not just the financial and management overhead. There’s also a significant opportunity cost, as resources that might otherwise be used to grow the business are tied up on relatively low-level implementation and maintenance tasks.

Alternatives to managing SAP HANA in-house

There are several alternatives to in-house SAP HANA to consider, including cloud-based services and on-premises implementations managed by a third party.

HANA in the cloud offers the obvious benefits of a pay-as-you-go model that removes the pain of patches, server maintenance, memory upgrades, and other hassles. But adding more capacity might not be as simple as spinning up another virtual instance because SAP HANA has to be configured to the environment it is running in. For companies that are used to cloud-based applications, the cloud may be a logical place to look when planning for SAP HANA, but typically usage is limited to dev, test, and sandbox instances. 

But the cloud comes with its own drawbacks. It’s one thing to run a project management app or informational website on Amazon Web Services or Google Cloud. It’s something else entirely when core enterprise data from an ERP system or customer databases are involved. Mission-critical data is the lifeblood of modern enterprises, and there are a host of concerns related to security, compliance, and uptime for data stored in the cloud. 

There are other costs to consider, too. Computers are subject to the laws of physics, which limit the speeds at which electrons can move across silicon and network connections. Sticking things in the cloud amplifies these limitations. It’s not possible to instantaneously move terabytes of data across a network, so once it’s parked someplace, it becomes very difficult—and expensive—to move it around. 

A more flexible alternative is an on-premises managed consumption model. The basic idea is to work with a third party to architect and manage SAP HANA instances, applications, and associated hardware and infrastructure in the company’s data center. 

First, it’s metered pricing, with billing based on RAM used for SAP HANA. Second, it comes with powerful services that are tailored to the company’s business needs. In addition to managing, monitoring, and maintaining the infrastructure, this model takes a proactive approach to future needs and includes features such as capacity planning and performance tuning. 

This model effectively lowers barriers to entry for using SAP HANA. Instead of spending large cash outlays to build out and staff the SAP HANA installation in-house, companies can assign resources to activities that generate true business value while someone else handles the low-level work of updating equipment, applying patches, monitoring performance, and conducting capacity planning. If there’s a problem, the service provider can provide a higher level of support to resolve critical hardware and software incidents. 

Unlike the cloud model, data remains behind the corporate firewall. There are no worries about cloud outages impacting mission-critical applications running on SAP HANA or uncertainty about who controls the data. For companies with robust security, compliance, or data sovereignty requirements, the on-premises managed consumption model may be the only viable alternative. 

When it comes time to grow SAP HANA with the needs of the business—for instance, in response to more retail stores coming online or the activation of a new analytics application—having someone else handle capacity planning is a major advantage. SAP HANA can grow in two ways. It can grow up, called scale up, which involves adding memory. Or, it can add additional services under the control of a single SAP system, which is called scale out. There is a lot of complexity involved with both approaches, but with the help of a managed service provider, the company can determine which is most suitable.

SAP HANA is the leading database platform for high-speed data analysis and application processing. Managing it can be expensive and distracting, but with the right partner to handle low-level tasks, companies can focus their efforts on deriving real value from their data.

Implementing SAP HANA: Lessons for leaders 

  • SAP HANA is an in-memory database platform for performing high-speed processing of large datasets, typically associated with mission-critical ERP and analysis applications. Queries that might take a traditional database many hours to perform can be done in near real time.
  • Cash outlays for in-house SAP HANA installations can be significant. Besides licensing, hardware, and ongoing management of the technology, there are also opportunity costs to consider.
  • An alternative to implementing and managing SAP HANA in-house is handing off low-level maintenance tasks and capacity planning to a service provider. Because the data stays securely on premises, there are no worries about cloud outages taking down mission-critical applications.

This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.