Understanding the HANA Enterprise Cloud: An initial whiteboard
During the press conference last week where the HANA Enterprise Cloud (I’m taking the liberty of abbreviating it as HEC) was announced, there was a heated discussion on Twitter about the new offering and how it fit into the overall SAP Cloud strategy:
In the meantime, there have been a few blogs (Aiaz Kazi, Björn Goerke and Vijay Vijayasankar) attempting to clear things up.
I decided that I wanted to try and figure things out on my own and started sketching in my notebook. Eventually, I moved my almost illegible drawings to PowerPoint and started writing to describe the resulting diagrams.
This blog reflects my journey to better understand this new cloud / HANA offering from SAP. It includes tons of diagrams to illustrate various points. Sometimes, I take false paths and have to retrace my steps and go a different direction – so bear with me.
Note: As always, please remember that I’m describing my interpretation of the HEC which may be different from SAP’s actual plans / intentions for the offering.
In order to understand the repercussions and meaning of the announcement, first we have to place it in the context of existing SAP cloud and HANA activities / strategies.
Great – now we have Business Suite in the Cloud
Business Suite is already available for productive usage on the Amazon Cloud – this deployment is not based on HANA but other supported databases.
Business Suite and BW (usually not HANA based) are also offered by various partners in private clouds -for example, Accenture private cloud solution for SAP.
Here are the resulting diagrams of these two scenarios.
Note: Many of my initial diagrams are relatively simple but they provide the foundation for what comes later.
Great – Production deployments of HANA in the Cloud are now possible
HANA One on AWS is already available for productive usage.
Here is the resulting diagrams of this scenario.
This is the first occurrence of SAP hosting applications in the Cloud
SAP already has a variety of cloud applications (Business ByDesign, Sales OnDemand, Travel OnDemand, etc) that already exist and for which SAP has full responsibility.
The important distinction is that these applications are SaaS applications whereas HEC is based more on an IaaS rather than SaaS model. Business Suite and BW can be deployed on the HEC Cloud but they aren’t SaaS applications. These are “dedicated single customer productive systems”
In his blog that was published during the press conference, CTO Vishal Sikka described the new offering as being composed of three elements:
- A breakthrough cloud infrastructure (previously known as “petabyte farm”), that is rethought for real-time architecture and optimized for modern trends in elasticity, storage, networking and compute layers.
- An open cloud platform (SAP HANA Cloud Platform), as the foundation to run modern applications and analytics.
- The ability to run mission critical applications such as SAP Business Suite, SAP Business Warehouse and several big data applications delivered as a managed service. These services help customers assess, migrate, and run rich applications with the simplicity of the cloud.
Note: It is important to distinguish between the “breakthrough cloud infrastructure” and existing SAP cloud infrastructure.
A graphic representation of these elements is included the HEC solution brief.
This diagram implies that the managed applications are based on the SAP HANA Cloud Platform.
Based on the three elements described by Vishal, let’s try and graphically represent the entities in relationship to one another.
Thus, the HEC is much more than just managed Business Suites / BW instances on HANA running in the Cloud – it is an attempt to consolidate SAP’s various cloud assets in one common structure.
Note: Please note that I didn’t say ‘consolidate all of SAP’s cloud assets’. At the moment, this offering doesn’t include SuccessFactors, Ariba, etc – although I assume that these offerings may use the Petabyte Farm at some point in the future.
The HANA Cloud Platform
A Simple Diagram
As might be expected, the simple diagrams above hide a great deal of complexity. Let’s dig a little deeper to fully understand what the HEC includes.
First, we need to take a more detailed look at the HANA Cloud Platform. As Aiaz describes in his recent blog , the HANA Cloud Platform has different layers.
Based on this structure, let’s take another look at our original HEC diagram and add some additional details.
Let’s take a moment and consider this diagram. As we described above, my initial analysis is based on the assumption that the managed applications somehow run on of the HANA Cloud Platform.
Currently, the HANA Managed Service focuses on the Business Suite (ERP, CRM, etc) and Business Warehouse (BW, BPC) – yes, I know that custom applications are also planned in this environment –more on that topic later. My assumption is that the currently managed applications are not going to be using the functionality included in the Platform’s Application Services layer since similar functionality is already present in the existing applications – albeit in a different form. The managed applications are also on-premise applications and are, therefore, accustomed to an entirely different landscape. If the applications in the HANA Managed Service will not be initially be using Application Services or the Enablement Services, then the managed applications can only be using the HANA DB Services – there are no more layers present in the Platform. Since the applications are already exploiting HANA, my assumption is that some of the functions used in the HANA DB Services layer (for example, “transactions” or “analytics”) are being used.
The problem with simple diagrams
We now have a good idea about how everything fits together. Right?
Reading the recent blog from Bjorn about the HEC, I came across the following description which I feel is a more accurate portrayal of the current role of the Platform.
While in general allowing to build a wide variety of application types on top, the platform is particularly optimized for two major use cases:
1. Serving as an open extension platform for
- SAP Business Suite solutions running on-premise in a customer landscape,
- SuccessFactors solutions running in the Cloud as a Software-As-A-Service offering and of course, since the recent announcement,
- SAP Business Suite solutions powered by HANA running in the SAP HANA Enterprise Cloud.
2. Building completely new, powerful and high-performance applications on SAP HANA
To be truthful, this focus on the extension of other OnDemand or OnPremise applications is a remnant of the NetWeaver Cloud before it was swallowed by the larger HANA Cloud Platform; however, regarding HANA Managed Service (at least in their current state), a “extends” relationship is probably more accurate than any other description.
Indeed, the use of HANA Cloud Platform to extend Business Suite applications running in the HANA Managed Cloud might actually bring additional advantages (performance, etc) over OnPremise-based Business Suites.
Based on this description, let’s change our diagram.
Note: My assumption is that HANA Managed Services “directly” access the HANA assets stored in the Petabyte Farm rather than through the intermediary of the Platform.
Going back and looking at my tweet stream from the HEC press conference, I found this tweet from Aiaz that also emphasizes this role.
In the conclusion in his blog, Bjorn describes the relationship between the two entities:
Both SAP HANA Enterprise Cloud and SAP HANA Cloud Platform are running collocated in the same certified SAP Data Center sites and hence allow to be efficiently combined and put to action for dedicated scenarios. In a way, SAP HANA Cloud Platform is available with SAP HANA Enterprise Cloud, or it is contained in it, but somehow these statements appear to be a bit academic to me. What is really important is that these two offerings fit and work together: One does not replace the other, but each of them solves a specific problem of our customer and partner ecosystem. They compliment each other: [SOURCE]
Based on this description, we can create a diagram that provides a better explanation:
The most important realization I had was:
- The HANA Cloud Platform is part of the HEC but also exists as an independent entity that can fulfill requirements that aren’t related to the HANA Managed Service.
The other cloud offerings
The HEC doesn’t exist in a vacuum and SAP has a variety of other cloud assets which aren’t part of the new offering. How are they involved? The FAQ to the question “Q: How does this relate to other SAP cloud offerings, Ariba and Crossgate offerings?” has this response:
Cloud solutions from SAP come in different categories. SAP HANA Enterprise Cloud is for running mission critical applications like SAP Business Suite in a dedicated way for enterprise customers. We also have cloud line of business applications that are multi-tenant, a cloud business network with Ariba (including Crossgate), and cloud-based social collaboration with SAP JAM. Each of these provides solutions to different business solutions
Thus, the existing Cloud solutions (in the diagram below, represented by Sales OnDemand) are distinct from the HEC.
Based on this description, we can create a diagram that provides a better explanation:
Note: The diagram could be enhanced with SuccessFactors and Ariba but I was running out room in my slide – so I decided to leave that exercise to other blogs / bloggers
The Cloud Infrastructure (Petabyte Farm)
I’m just going to touch on a few interesting points regarding the infrastructure. I’ll leave a more detailed analysis to others who have more knowledge in this area.
Is the HEC Cloud restricted to SAP?
At the press conference last week, the first customer to go productive on HEC was announced:
“We are thrilled to be the first SAP ERP and SAP NetWeaver BW powered by SAP HANA pilot customer running live on SAP HANA Enterprise Cloud,” said Don Whittington, CIO, Florida Crystals. “As part of our aggressive global growth strategy, it was paramount that we have the ability to deploy mission-critical SAP applications powered by SAP HANA as quickly as possible via the cloud without any compromise. [SOURCE]
During my research for this blog, I found an interesting press release from partner Virtustream – which proudly announced “Virtustream Goes Live With the First SAP ECC Production HANA System in the World”.
Virtustream, Inc., the leading enterprise class cloud software and Infrastructure as a Service (IaaS) provider, today announced that the first SAP ECC-on-HANA in the cloud is now live in production on the Virtustream Enterprise Class Cloud powered by its xStream cloud management software. This is a significant addition to Virtustream’s SAP capabilities and allows customers to deploy SAP HANA® as a managed service, with no up-front hardware costs and a fully managed HANA environment.
Note: I also found a more detailed description of this Florida Crystals deployment from SAP’s recent Cloud and Virtualization Week.
Now, I don’t know exactly if there is a conflict between the two press releases (for example, was the Go-Live on the environment of Virtustream or SAP) but I found them both regradless intriguing.
Most of the media focus has been on SAP’s as host of the HEC – yet HEC is a generic offering that can also be offered by partners. This is also described by the FAQ:
SAP and partner solutions will be either running on the SAP HANA Enterprise Cloud or partner hosted offerings leveraging the cloud platform capabilities of the SAP HANA Enterprise Cloud [My Emphasis] [SOURCE]
The associated press release provides even more detail
SAP plans to deliver the SAP HANA Enterprise Cloud along with its partners in an “open + us” strategy. SAP intends to adapt this open ecosystem strategy with its managed service providers to offer the capabilities of SAP HANA Enterprise Cloud from their data centers, as well as from multiple SAP data centers worldwide [SOURCE]
This characteristic leads to such a diagram:
As Head of Database & Technology Marketing Amit Sinha tweeted during the event, there will even be a country-specific plan to promote such partners.
Yet, there may be more potential than the use of isolated partner DCs to increase customer usage. A tweet from Virtustream CEO Rodney Rogers provides details on what might be coming in the future.
Federation between HANA DCs might look this:
HANA Managed Service
What is included in the managed service?
I am always curious as to what exactly an IT managed service contains and, therefore, was interesting to dig into the associated offer in the HEC.
And when you use SAP HANA Enterprise Cloud, you get built-in skills, leading to much faster implementation and simplified operations once live.
What’s more, SAP HANA Enterprise Cloud is designed and built for mission-critical operations. With no trade-offs whatsoever, you get the performance, integration, security, failover, and disaster recovery of an onpremise implementation with the elasticity, automation, and ease of administration you’d expect from a cloud solution. And with the experts from SAP or our trusted partners managing the deployment for you, you get the benefits of unparalleled expertise and the freedom to refocus existing IT resources on core competencies. [SOURCE]
Thus, it appears that SAP will perform the operations-related tasks for these instances. This can also been seen in the SLAs for the HEC: (99,5% combined monthly availability of DC, HW, HDB, application uptime).
I kept thinking about SAP’s decision to sell its existing European external hosting customer base to T Systems in 2009 – much has changed in IT since then.
When I asked about details about HECoperations on Twitter, regarding updates, Enhancement Packs, etc, Vijay answered:
This aspect of the offering is also described in the HEC solution brief:
And because system management is our responsibility, you’ll remain on the latest, most up-to-date hardware and software without the disruptions of periodic upgrades if you choose to do so. [SOURCE]
When I asked about the impact of customization in such environments, Jeff Word and Vijay Vijayasankar commented.
This ability of the customer to choose which version of the software is to be used provides a great deal of flexibility for customer but increases the administrative effort for SAP. As Forrester analyst Stefan Ried suggests
Bringing your own licenses and application versions literally destroys the economy of scale for the provider at a higher level. To turn the Business Suite on the Hana Cloud into a SaaS offering, SAP should only support a single version, based on a modern SaaS license model, in its new cloud.
I’ll be watching to see how this model scales as more customers move their environments into the HEC.
Early in my blog, I displayed a diagram that shows one interpretation on the relationship between the applications in HEC Managed Service and the Platform.
In the current manifestation of the HEC, this drawing appears to be incorrect. It appears that the applications in the HEC Managed Service don’t really use the features of this platform but rather are extended by it.
An intriguing thought is that in the future the applications in the Managed Service might really use the services provided by HANA Cloud Platform (security, portal, mobile, collaboration, etc). This change would mean that the cloud version of these applications (CRM, BW, etc) would be different from their older OnPremise counterparts but this move would greatly simplify the underlying architecture and make it truly revolutionary.
Great blog Dick and thanks for helping SAP to understand how our current cloud message is perceived by our ecosystem.
You're right. Right now, the SAP HANA Cloud Platform is part of the bigger HANA Enterprise Cloud and not the underlying platform (yet). It's more positioned as in inherent extension platform to develop applications (should we call them 'Cloud Composites') that provides means to integrate various solutions.
I'm sure we'll hear much more about these aspects the next few days...
Great blog and really a monster. Thanks a lot for explaining in detail. I hope it will get more clearer for developers also probably after
Big Thanks !!
Great Blog! 🙂
Still haven't read the whole piece, but one thing that confuses me is: you seem to think the Managed Services are the same as Business Suite/BW running on HANA.
I've got the impression that the Managed Services are really (consulting-like) services, like for instance on boarding of customer's ECC onto the platform, etc.
Excellent piece btw, and I'm glad you've done the hard work, while 'we' (the rest of us) could wait for the result.
imho, managed services mean like the "it outsourcing" tasks such as sustaining ongoing systems, planning upgrades, scheduling backups, downtimes etc.
Managed Services means more than just BW / BW or HANA running in the cloud - it means that SAP or the partner involved has responsibility to assure that the system is up and running, etc. It is similar to an OnPremise corporate service that IT offers its business users. Although technology is involved, it is everything else (KPIs, SLAs, etc), is equally or more important.
Thanks for the clarification Dick,
Didn't 'get' that from the blog, think we're on the same page here.
Another piece of the puzzle I've not heard about so far in the SAP publications on the matter:
Excellent & informative blog
Super blog indeed, thank you !!
Very Informative - thanks
Great blog. I'm a simple guy, so simple diagrams are all I need.
Just looking at the size of your blog and (as it seems correct) assumptions, its a shame that its very difficult for SAP to sell this as an easy story. When we, "the experts" have great difficulty digesting the (not so future cloud) direction of SAP, how can our clients?
Again thank you for making HEC understandable.
I also like simple diagrams - they really help me understand a topic.
Excellent analysis..Thank you very much for sharing your ideas.
I would like to just add one comment with respect to the statement regarding the distinctions in 3rd figure
"The important distinction is that these applications are SaaS applications...."
This is NOT entiretly true for ByDesign as it is NOT only a SaaS solution but also a PaaS for developers and as such I would also add the PaaS level for ByDesign similar to the HANA Cloud PaaS box in the figure.
Good point. The question is how you define PaaS and how you view ByDesign. In the past, SAP described the technical foundation of ByDesign as an ABAP-based PaaS (Core vs Edge) that could be used to develop new LoB applications. Indeed, the official description still reflects this: "the SAP Business ByDesign studio is a PAAS based software development kit (SDK) which enables SAP Partners to adapt and expand the solution capabilities of SAP Business ByDesign. In recent marketing efforts by SAP, however, PaaS is usually only used in reference to the HCP.
Excellent analysis..Thank you very much for sharing your ideas. I also like simple diagrams - they really help me understand a topic.
Please note that your blog is now featured in the "Community Experts" section of sap.com/hana. Well deserved recognition!
Thank you for the effort in putting up this terrific and clear explanation.