The topic of SAP HANA and multi-tenancy has generated plenty of hand-wringing and fierce debate. If it was just vendors taking pot shots for bloggers to sift through, we could leave it alone. But the end result matters to customers also (for the skeptics – more on that shortly).
In one of the surprising developments of SAP TechEd && d-code Las Vegas, SAP clarified the role of HANA and multi-tenancy with a combination of news and subsequent clarifications that were far more coherent – and realistic – than what we have heard in the past.
Start with the news: SAP HANA Service Pack 9, a point of emphasis at SAP TechEd, is now officially announced, with an expected release date before year end 2014 (likely in November). One of the key features? Multi-tenancy support.
But hold on a sec – what does this mean? Given that the HANA Cloud Platform already supports multi-tenant applications, what is the news here? And who stands to gain?
Digging into the HANA multi-tenancy news
During an on-site blogger meeting with Ingrid Van Den Hoogen, SVP of Products and Innovation Marketing and Irfan Khan (with spanking new job title and role, CTO for SAP Global Customer Operations), we dug in. In our follow-on video with Khan and Den Howlett, Khan provided a nutshell view of HANA’s multi-tenancy support and why it matters:
- SAP has been internally hashing out the lessons of cloud applications and multi-tenancy in the context of improving SAP HANA.
- Historically, a customer running multiple SAP systems (example: BW and ERP), didn’t have the capability to effectively manage workloads in one environment.
- HANA’s new multi-tenancy support enables a customer to manage all their SAP systems in a single environment, creating potential for consolidation savings.
- HANA multi-tenancy also has implications for the bugaboo of applications code customization, which can now be done on the database layer.
Khan on why this is a new development:
With the advent of HANA as a platform, the intent is to be able to congregate – or at least aggregate – a lot of these different workload environments, like BW, maybe ERP, running it within a single environment. So historically, with HANA being introduced to the market, that wasn’t a supported configuration. There wasn’t an ability to be able to lift and shift those two distinct, different sort of workloads and bring them in to one single instance of HANA, and allow them to be able to operate independently, without compromising one or the other. What we now have with multi-tenancy is the ability to have that very thing.
This exchange hones in on the TCO benefits that SAP anticipates:
Khan: Multiple instances could be perhaps 3 or 4 ERP instances that you have scattered around. When you bring them all together in to one HANA environment, you would ring fence off each ERP instance-
Howlett: As you need it.
Khan: Correct, as you’d require it.
Howlett: So that gives me the benefits of consolidation, hopefully lower TCO, but I still have the ability to take those instances separately if I need them (separate)?
Khan: Yes – the benefit of this now new multi-tenancy capability is that, you could literally create multiple independent versions of those database environments and run it under one single instance of HANA.
Khan emphasized these benefits won’t be limited to SAP’s own applications:
If you look at the maturity of the new core of HANA, in terms of the multi-tenancy, the dynamic tiering, the ability to start screening data from wherever – whether it’s sensors or other Internet of Things data sources, it really gives you a foundation that is capable of supporting of many, many different classes of applications. Not just SAP, but also your custom applications that are being developed as well.
Multi-tenancy can quickly become a rabbit hole where architectural purists hold sway and customers tune out. From a customer value perspective, what matters are the tangible benefits, not the technical minutia. In this case, the ability to consolidate and manage multiple SAP systems in one database environment is clearly a step forward, and one viable answer to the chaotic tentacles that have spun from some global SAP deployments.
It’s important to note that the multi-tenant capabilities we are talking about here are at the database level, which means that in theory, existing SAP customers could achieve such consolidation benefits via an on-premise version of HANA, or also via the hosted “HANA Enterprise Cloud” that is managed by SAP and its partners (I’m seeking more details on this currently and will update).
It is refreshing to see SAP move closer to modeling their solutions off of the industry’s accepted definitions of multi-tenancy (I’m partial to NIST’s definitions, see our own Phil Wainewright’s expert views on multi-tenancy and multi-instances). In past press conferences and meetings, SAP has given the impression that it is either openly hostile to multi-tenancy or applying its own self-serving definition.
Now an alignment with more generally agreed definitions seems to be building, which in turn reinforces confidence in SAP’s product roadmaps. Looking ahead, this should also make building so-called “next generation” apps on SAP’s HANA platform that much easier. SAP’s growing open source participation in OpenStack, CloudFoundry and beyond is surely contributing to this ability to talk in de facto (if still evolving) standards terms, such as workload management and elasticity, that those not schooled in SAP cloudspeak can readily understand.
Support of existing multi-tenant SaaS applications in the SAP portfolio is a different matter (meaning: multi-tenant at the application layer). In the long run, SAP’s SaaS applications will run on HANA and be extendable via the HANA Cloud Platform (including SuccessFactors, Concur, and Ariba). SuccessFactors extensions are being built on the HANA Cloud Platform now, something Den and I have covered in a fresh demo shoot of Enterprise Jungle with SAP Mentor Chris Paine.
Prior keynote stage exuberance implied a much faster timeline for SaaS applications like SuccessFactors to run entirely on HANA. Ergo, some vendors have had a field day pointing out that SAP’s SaaS apps still run on a certain competitor’s database.
For the first time I can personally recall, at SAP TechEd/d-code I heard much more open talk from SAP about the process of moving its SaaS portfolio to HANA. In our meeting with Khan and Van Den Hoogen, we were told it was a matter of, broadly speaking, 3-5 years until these transitions would be complete (for the record, SAP says it has been communicating this timeframe since 2013, so factor that into the math).
SAP would not commit to an exact date or exact timeframe – only the firm intent to move all SaaS apps to HANA. I don’t have an issue with that – in fact, the open discussion about the transition to HANA, not to mention the technical issues being conquered along the way – should be shared more publicly. I won’t delve into the wonky tech details, but the point is that optimizing multi-tenancy is hard work. That’s why established SaaS vendors spent (and continue to expend) considerable effort ensuring their multi-tenancy architectures are robust.
Give me open talk about the challenges of porting SaaS apps to HANA anyday – it’s far better than the keynote ear candy of years past. Plus, we now have the delicious irony that SAP’s much-maligned(but still alive and kicking) cloud ERP solution, Business ByDesign, is the first major SAP SaaS app to run entirely on HANA (customers are being gradually transitioned now).
SAP can’t clear up its approach to multi-tenancy in one conference, but this show was an notable step towards clarity.