Sorting through the many SAP HANA deployment options

With SAP HANA, an enterprise's options for tapping the cloud are wide open -- and only getting wider.

When it's time to sort through the many deployment options for SAP HANA solutions, an enterprise's primary choice is between running HANA on-premises or from the cloud. Although that one choice seems simple enough at the outset, both options lead to a whole new set of choices.

In addition, it's not as if SAP HANA deployment options are static. At the time of this writing, at least 15 SAP partners combine to offer several hundred options for certified SAP HANA hardware appliances, and although SAP has its own SAP HANA Enterprise Cloud services (see the sidebar "Differences between SAP's two HANA cloud services"), the company also has at least 50 partners that offer varieties of SAP HANA solutions in the cloud. As SAP invests more and more of its future in HANA, SAP's partner ecosystem constantly innovates to grab its own slice of the HANA pie.

"We're seeing a lot of the partners jumping in with some of the groundbreaking options," Sean Moore, Capgemini's North America leader of SAP Business Analytics and HANA, said. "For example, HP, which is one of our partners, is doing a flexible capacity hardware approach, which is cloud-like. Effectively you pay for what you use, and it's hardware as a service … driven by the massive power -- and cost -- of HANA."

In one flexible service model, Moore explained, a company might want to accelerate its three-month close. During a three- to five-day span, the company might want a super high level of performance capability -- but only for a few days. "Once that heavy lifting is done, they want to go back to the lower-cost hardware. So HP, AWS, Cloudera … a lot of these companies are offering this sort of a hardware-as-a-service option as a way to leverage HANA, whether they are point solutions or for an enterprise approach."

On-premises deployment options

The traditional SAP HANA deployment scenario is an appliance delivery model where an SAP hardware partner sets up a fully preconfigured system with preinstalled software packages supported by SAP. Within the appliance delivery model, customers can choose a scale-up or a scale-out system, but the options don't stop there. It's also possible to get into a hardware virtualized model at the firmware level through Hitachi's logical partitioning (LPAR) technology on x86-based servers. In the data center, these logical partitions act as independent bare-metal servers, letting customers run multiple but separate HANA-based workloads on the same system.

Later this year, customers will also have the choice of deploying SAP HANA on IBM Power Systems servers running Linux with POWER7+ or POWER8 processors, which will bring another set of LPAR deployment options to HANA.

With SPS 09, SAP introduced multi-tenant database containers, which allows for multiple tenant databases within a single SAP HANA system -- and their memory sizing and CPU consumption can be configured independently, too. A company could use multi-tenancy to make more efficient use of an underutilized appliance, or ultimately choose to deploy on a larger system in the first place to account for increased HANA implementations over time.

What about running SAP HANA virtualized with VMware vSphere? It's now a viable option, although it is primarily of interest to enterprises that have already invested in VMware virtualization solutions for their entire data centers and want to use it to help manage SAP HANA resources. SAP HANA customers can utilize vSphere on a certified appliance -- or with SAP HANA tailored data center integration (TDI) verified hardware -- which brings up TDI deployment options.

TDI offers the most flexibility but also the greatest complexity. TDIs enable enterprises to install SAP HANA on existing hardware in their data center as long as the hardware -- and related networking components -- is certified to meet performance standards by SAP. The core value proposition is to save money by using existing capacity, while also gaining flexibility. However, while Gartner has reported that TDI interest is picking up, according to John Appleby, global head of SAP HANA for Bluefin Solutions, it might be a long way from a mainstream deployment choice today. Bluefin Solutions is a global independent consultancy and SAP partner that works primarily with larger SAP customers.

"I have never seen a TDI in the wild for a productive deployment," Appleby noted. In fact, although Appleby acknowledges that some TDI solutions may be in production, he doesn't believe they will take off in any significant number in 2015.

"All the customers we work with deploy separate systems for BW, for Suite," he said. "They have separate systems, separate licenses so far, and they are all -- without exception -- on certified appliances."

Scale-up versus scale-out

Although scale-out systems tend to cost less at the time of acquisition by allowing a business to add nodes as they grow, scale-out solutions can increase operational complexity and sometimes end up costing more in the long run.

"My recommendation to customers is really clear: Do scale-up first and scale-out if you need to, but if you don't need to scale-out, don't do scale-out," Appleby said. "Now we have scale-up systems available at reasonable costs up to 2 terabytes ... and that covers up to 80% of customers," he noted, adding that most of Bluefin's customers choose scale-out for their large Business Warehouse implementations but choose scale-up for Business Suite on SAP HANA.

In addition to SAP's own SAP HANA cloud services, many partners offer SAP HANA solutions of various sizes and capabilities, with and without additional services. These options bring additional deployment choices. For instance, in late 2014 SAP and IBM jointly announced that SAP HANA Enterprise Cloud services would be available through IBM's SoftLayer cloud services. So why choose to deploy HEC via IBM? IBM brings additional data centers, located around the world, along with a wide variety of non-SAP cloud services. A customer might choose IBM Cloud for SAP HANA workloads because it might also use IBM for other parts of its IT enterprise.

The concept works with other cloud providers, of course, including the recently announced Amazon Web Services (AWS) for SAP HANA. However, finding a comprehensive list of SAP-certified SAP HANA cloud services hosting partners isn't particularly easy. The SAP Outsourcing Operations Partner Guide, for example, shows more than four dozen certified HANA hosting partners.

Differences between SAP's two HANA cloud services

SAP offers two of its own SAP HANA cloud services: SAP HANA Enterprise Cloud (HEC) and SAP HANA Cloud Platform (HCP). What's the difference?

HEC lets customers run the complete HANA set of solutions in an infrastructure-as-a-service offering along with fully managed services for the software, too. HEC is similar to having a company's full SAP HANA footprint deployed off-site and managed by SAP. Customers can bring their already licensed SAP HANA solutions or choose subscription-based pricing.

HCP, on the other hand, is more of a platform-as-a-service offering designed to help SAP partners deploy SAP HANA-based applications or extensions via a cloud model, or to let SAP customers build their own cloud-based applications to extend their own in-cloud or on-premises solutions. A typical example could be creating a mobile app that runs from the cloud but communicates with a system of record that exists somewhere else.

On-premises versus cloud

Although SAP deployments are currently dominated by appliances, more and more companies are choosing to tap the cloud (see the sidebar "Innovation cycles may be the key to SAP HANA deployment"). So when is a cloud deployment smart? Total cost of ownership (TCO) currently seems to favor on-premises deployments, but the dominant industry expectation is that the overall cost of cloud deployments will come down over time. Whether or not a company can accurately predict the TCO of a HANA solution over time, in some situations the cloud trumps on-premises deployments.

The most logical choice for the cloud comes from companies sensitive to capital expenses -- essentially, acquiring solutions that require a large up-front investment. These kinds of companies prefer operational expenses, which are more akin to ongoing service fees that don't require the purchase of concrete, physical assets.

Another situation where the cloud wins is for net new customers who have no on-premises SAP HANA investment. Capgemini's Moore said that these types of customers have a "last mover" advantage because they aren't tied to existing hardware. "There's a big difference in the way they perceive their deployment options," he noted.

Of course, enterprises of all kinds can tap the cloud to utilize discrete applications that can function in hybrid environments, either running separately from traditional ERP or connecting with it. With SAP HANA, the options are wide open -- and only getting wider every quarter.

Innovation cycles may be the key to SAP HANA deployment

For the University of Kentucky -- which went live with SAP HANA in 2012 -- SAP HANA's blistering speed has led to 420 times faster data reporting than the university's legacy system, 15 times the improvement in query load times, a data compression improvement of 77%, and up to an 87% reduction in extraction, transformation and loading times. According to one IDC study of the university's implementation, SAP HANA resulted in a 509% ROI, providing $6.17 million in benefits over five years with a payback in less than 10 months.

Before choosing SAP HANA, Dr. Vince Kellen, senior vice provost of analytics and technologies for the university, put together the business case for SAP HANA, which is a key step that helps any organization illuminate its best deployment scenario.

"We could save money by reducing the number of tools in our business intelligence collection," Dr. Kellen said, adding that they were also able to save on some maintenance and hardware costs. And the deployment choice? Certified Dell appliances installed in the university's data center.

Fast forward three years and the SAP HANA deployment choice is on course for a change -- to the cloud.

"We're actually releasing our RFP here in a couple of weeks in which we will take our entire SAP environment -- and other things -- out for bid to enterprise vendors like SAP HANA Enterprise Cloud, like IBM with their SoftLayer acquisition, to Dell with their Enstratius, and others like Virtustream, to see if it's feasible to empty our data center and move us to infrastructure-as-a-service providers," Dr. Kellen said.

What is really interesting about this move isn't the changing cost structures of a cloud deployment -- rather, it's the timing.

"The alternative to the cloud is we have to build a new data center, and that's an expensive proposition these days," Dr. Kellen explained. "There are many more options now, and we're going to shift our thinking to the cloud version only because we don't want to worry about the infrastructure ourselves."

This sort of timing, it turns out, may be the key to a smart SAP HANA deployment choice. According to John Appleby, global head of SAP HANA for Bluefin Solutions, CIOs should analyze where their organization is in relation to their own internal innovation cycle.

"Timing is everything for deployments," Appleby said. "What we tend to see is customers are aligning their deployment strategy with where they are in their innovation cycle, so if you look at hardware -- hardware is an expensive capital cost -- if you have to remove old hardware before it's been fully depreciated, you're going to take a knockdown hit. … The big thing is to look at where HANA deployment makes sense within the context of your organizational strategy."

Next Steps

Preparing for an on-premises SAP HANA installation

How one company chose from among SAP HANA's cloud partners

New enhancements put SAP HANA on path to success

Dig Deeper on SAP hosting