RE: HANA Cloud Platform – Revisited – Improvements ahead and turning into a real PaaS by Holger Mueller


Analyst briefings are always a good pulse check to see to what extent your strategy & messaging resonates with the outside world and as such it’s common to schedule such meetings prior to big events or announcements. HANA Cloud Platform (HCP) is among the most strategic technologies in SAP’s portfolio and as you can imagine the platform will be a prominent topic at the upcoming SAP TechEd && d-code events. Consequently, we did setup a meeting with Holger Mueller from Constellation Research to give him a rundown on all things HCP upfront.

Personally, I have closely been following Holger’s work ever since he joined Constellation Research and in fact became a frequent reader of his blog. His writing is backed by his enormous amount of experience in the enterprise software space and his vast technical background qualifies him to look deeper than most. What I like in particular about his style of blogging is that he always mentions both – the good & the bad – and that he provides reasons for his conclusions. Of course, that is not to say that I always agree with his assessments or analysis!

As it happens, there are a couple of points in his recent blog post about HCP that need clarifying from my point of view and as such I opted for writing this reply.

Re: Purpose

Naturally PaaS players with evolving PaaS capabilities prefer to be more nebulous than clear on this key area – as the capabilities of the platform expand and naturally vendors don’t want to lose developers to other platforms because of a too restrictive positioning.

That’s a tricky subject and from my personal experience I can say that properly addressing this is indeed a challenge for platform providers. In general, most Platform-as-a-Service offerings have a comprehensive set of capabilities for a great range of use-cases and usage-scenarios. HCP is a prime example for this! However, given the technical nature of PaaS it’s quite hard sometimes for non-technical people to truly understand the value of such a cloud platform purely based on technical capabilities. Here it helps to sketch out common usage-scenarios to give CxOs and decision makers a better idea about the possibilities of cloud platforms. In that context, the outlined scenarios are purely intended to start the conversation about potential scenarios and should be considered as exemplary use-cases. The three mentioned scenarios are certainly the top most talked about use-cases in the context of HCP, but others – such as Internet of Things (IoT) – are getting more and more traction as well.

Re: Usage scenarios

So credit goes to SAP to provide more clarity in this area, with three major usage scenarios being the focus of HCP now:

  1. New Cloud Apps – SAP wants a portion of the ‘born on the web’ apps, which makes sense – but is probably the most competitive area of the three scenarios.
  2. On-Premise Apps – Building cloud extension to on premise apps with the help of HCP is the most common scenario for SAP internally, and a good one to draft in as a potential HCP user.
  3. Cloud Apps – Building cloud extensions to cloud solutions. For SAP that would be e.g. putting new cloud based apps on top of SuccessFactors or Ariba, another scenario that is relevant for SAP and with that decision makers should have a relatively high comfort level HCP can help them for the same or similar project scenarios.

1) Fair enough, however SAP’s domain expertise in numerous industries paired with the collective know-how of partners gives SAP a unique opportunity to constantly increase the number of innovative cloud solutions running on HCP. That may be line-of-business applications or so-called verticals targeting specific industries. Not to forget that HCP is to-date the only enterprise in-memory PaaS in the market, which is a strong unique selling proposition in itself.

2) In fact, on-premise extensions are very interesting for SAP’s installed-base, which seem to share SAP’s point of view that future IT landscapes will remain hybrid comprising both on-premise and cloud solutions. For many customers and partners, such hybrid scenarios are a good starting point to extend their businesses into the cloud and get experience with cloud platforms. Just think of Fiori-like scenarios, which bring immediate value and that’s just the tip of the iceberg.

3) In regards to cloud extensions there are two points I’d like to emphasize on that explain the unique selling proposition of HCP: seamless integration and co-location. Let’s take SuccessFactors Employee Central as an example to explain that. New solutions or extensions build with HCP seamlessly integrate into the look & feel of the original application, which ensures a great and holistic user experience. As both SaaS solution and extension are co-located in the same data center there is practically zero latency.

MyPOV – SAP is smart at packaging these 3 different scenarios in the usage of HCP – all three of them being close to what SAP needs to do internally anyway, so why not make it good enough / attractive enough for customers and partners attempting to do the same.

I don’t quite understand what Holger implies when he writes “all three of them being close to what SAP needs to do internally anyway“, yet it may be misunderstood and eventually result in people getting a wrong conception of the vision/mission of HCP! Let’s be clear about this: the platform aspect is not an afterthought, but has been the primary motivation for HCP from day one!

I’ve personally talked and written about the (cloud) platform play on numerous occasions and in SAP’s understanding it is fundamental to have a vital partner and customer ecosystem in order to be successful with platform. I believe that the SAP PartnerEdge Program for Application Development and the SAP Startup Focus Program speak volumes about SAP’s ambitions in this regard.

Re: Concerns

SAP’s cloud vision is very database centric. With the rest of the industry looking more at compute elasticity, SAP is going its own path. We discussed this previously, and it may work out for SAP one more time – but going a special path remains a risk for enterprises.

I wouldn’t call SAP’s cloud vision “database-centric”. True, HANA is an important and differentiating aspect of all of SAP’s products and technologies, yet keep in mind that HANA is more than just a database, but rather a full application development platform. More so, there are concrete plans to support other databases as well. In fact, I’d say HCP is all about choices on all layers from database to programming model. All of that is by intention to make the platform attractive for all kinds of customers, partners and – last, but not least – developers.

SAP has done good progress becoming more open source driven and using more open source (well, what is the alternative?). On the other side it has still ambition with its new programming language River – I haven’t heard from the River folks in a while – so SAP will have to balance open source vs proprietary at some point.

Happy to see Holger acknowledge SAP’s activities and strategy in regards to open-source! About River: I personally believe it may be better to think of River as a Rapid Application Development or productivity tool, rather than a programming language in the traditional sense. As such, it’s closer to tools like Spring Roo as both tools handle the creation of the respective code and database artifacts. From what I know the intention has always been to promote other languages as well, the team did just start with HANA support. All in all, it boils down to what I mentioned earlier about choices… What’s wrong with providing both options (proprietary and open) – isn’t that the best “balance”?!?

Re: PaaS

It took some time, a lot of clarification, but now HCP is moving to become a generally viable PaaS offering for enterprise applications. It would not hurt of SAP to start calling it what it is, a PaaS and tackle the remaining strategic directional questions ASAP.

I can only on behalf of the HCP team, yet we always called it a PaaS. (As insiders know we even had the word PaaS in the internal name of the platform years ago.) For reference, here’s the official announcement blog post I wrote more than two years ago. I can only assume that the similarities in name between HANA Enterprise Cloud and HANA Cloud Platform may confuse some people.

However, I’m willing to make a bet that neither Steve Lucas nor Björn Goerke will call HCP anything else than a PaaS during their keynotes at TechEd && d-code. 😉

Wrap-up

Of course I have been focusing on those points in Holger’s post where I saw the need for clarifications so let’s not forget that there are indeed many other topics that he acknowledges as the right direction/decision for HCP and SAP. I’m positive that SAP will be able to address some of the topics Holger raised during TechEd and a such looking forward to hearing what Holger and others have to say after TechEd && d-code Las Vegas.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Chris Paine

    Thanks for clarifications,

    But River and the web based ui5 development platform are/were 2 different things. No? I argued against the tooling ever being called after River, but perhaps that is not what we are talking about? Either way was pretty sure River the HANA manipulation language was indeed a language as did not see a way to get at generated code and maintain  in a meaningful way. happy to be wrong as always!

    Chris

    (0) 
    1. Matthias Steiner Post author

      Aarg… Now you get me into trouble Chris! This post was intended to clarify things about HCP, and NOT making things more confusing… but alright.

      Well, I agree with you on the naming of the web-based IDE, which is currently (!!!) called River RDE. It has little in common with River/RDL except for the vision of making the development of applications more simple/efficient. But given that we came here from an HCP discussion I rather not complain about SAP’s naming conventions, know what I mean?

      But you’re right, that’s two distinct tools/technologies rigth now. I believe that Holger was referring to River RDL, and here what I stated is still my own understanding and preferred way to explain it.

      True, RDL creates SQL script, DB tables and views and OData endpoints etc. in the background and that’s why I personally see it as a RAD/productivity tool in the first place. (You could create  the exact same app without RDL by doing it all by hand/manually.) Plus, from all I know (but I’m not the expert here) there were always plans to have RDL be able to do similiar things for other languages… Matter of fact, I recall the RDE team talk about that in an analyst briefing with Gartner last year!

      Hope that clarifies what I was trying to say.

      cheers,

      matthias

      (0) 

Leave a Reply