The SAP Hana Cloud Platform (HCP) could be characterised as a binding agent for the further technological development of products in SAP’s core business.
The aim with HCP is to secure the integration of the classic SAP Business Suite with new SaaS (software as a service) products, such as SuccessFactors or SAP Hybris Cloud for Customers. Alongside this, the purpose is to offer a foundation for the renewed Business Suite (S/4) to get extensions that are directed towards the cloud.
Yet having the word ‘Hana’ in the product name confuses many customers because that directs focus toward SAP’s in-memory database.
Considering this more closely, while Hana-DB is an important supporting pillar in the platform it is by no means a precondition for using it. The in-memory aspects do not absolutely need to be the objective when using HCP. Conversely, the Hana-DB can also be operated without HCP.
In presenting the product, SAP refers to the HCP as an “open in-memory PaaS solution (platform as a service) for developing and operating business applications”. The services offered range from services close to infrastructure right through to pure business applications.
Here are a few representative examples: Web IDE: browser-based development environment, incl. GIT repository and layout editor; SAP Real Spend: business application for the administration of budgets by managers; OAuth 2.0 Service: technical administrative tasks for the OAuth Security Framework.
In total, the platform currently provides around 30 to 40 services, with additions constantly being made. The services are grouped into various areas. For instance, a service such as SAP Real Spend is located in the Business Services area. The overview on architecture from the current HCP product presentation clarifies this division of the services.
Application Cases and Openness
From the SAP side of things, the HCP is positioned as a development platform for two main application cases: development of new, cloud-based applications and extensions of existing on-premise applications and cloud applications.
Depending on the respective application case, SAP takes the open-standards paradigm as its point of orientation with regard to HCP. This path takes us towards Cloud Foundry and thus towards the Bring Your Own Language (BYOL) approach.
Alongside the development platform, the respective long-time environment is made available. Applications can be developed on a multi-client capable, ‘multi-tenancy’ basis.
The SAP Store can be used as the sales platform.
SAP is positioning the HCP as a universal extension platform for on-premise and cloud applications. This is regardless of whether S/4-Hana or SaaS applications – such as Fieldglass, Ariba, SuccessFactors or Concur – are used.
Adaptations of the SAP standard are to be de-coupled from the specific application. This enables the extensions to have a large degree of independence from particular releases, and reduces unwanted correlations with the SAP standard.
In a supporting role, Hana Cloud Integration or simply the Hana Cloud Connector can be used as middleware. This makes possible an encrypted link-up of on-premise systems, including user mapping.
HCP opens up new business models for SAP development partners, as a universal extension platform. Whereas up to now adaptations are mostly integrated directly into the back-end as a customer program, the development of the adaptations can now be de-coupled, centralised and marketed for general consumption.
Through what is by now a uniform UX strategy in the SAP universe (SAPUI5/Fiori), extensions can now be seamlessly integrated, also from the usability perspective.
As described above, the HCP serves as a kind of binding agent, connecting the classic SAP world with new products. Thus SAP continues to position the ERP successor, S/4 Hana, as the great mother ship around which a variety of specialist solutions find their base.
As a universal extension platform, HCP’s role in strategic terms is to take over from old extension concepts. This makes possible a high degree of independence from development cycles of SAP extensions; in architecture terms, this is a de-coupling from the solution that is to be extended.
This opens up whole new fields of business for SAP partner companies who have up to now concerned themselves with extensions of precisely this kind. Extensions can be developed in a less customer-specific way. Likewise, the sale of solutions of this kind is placed onto a new basis via the SAP Store.
In addition, via integration channels such as the Hana Cloud Integration, the gap between cloud and on-premise is filled. Especially among small to medium-sized companies, SAP is trying to expand its business. New customers are often gained via new cloud products, such as SuccessFactors.
Especially in the case of cloud products, the question arises as to how customers can implement wishes for extensions. And this is precisely where SAP’s answer is: HCP. SAP’s philosophy takes as its basis APIs (OData-APIs, for example) of the individual SAP standard solutions; extensions hosted on the HCP can be docked onto these.
Currently it is not foreseeable that HCP will be positioned as a PaaS for non-SAP-customers, independently of other SAP solutions. As an exception, use as a platform for new solutions from ISVs (independent software vendor) can be analysed.
ISVs & Innovation
HCP offers independent software vendors (ISVs), and SAP partners in particular, a platform for developing new software solutions. Thus once again SAP is endeavouring to establish itself as a competitor among the providers of technical platforms.
In particular, advantages offered by optionally-available in-memory technology and integration aspects with other SAP systems can motivate ISVs to use the HCP.
Yet once again SAP places its licensing policy in the way as an obstacle. HCP licensing is a multi-layered topic. Currently the easiest option seems to be the marketing of the so-called ’embedded Paas model’ (ePaaS).
This is an OEM model making it possible for SAP partners to sell their HCP solution as a whole package. A prerequisite for this is membership in the PartnerEdge Program for Application Development, including the innovation pack for Hana Cloud Platform.
For the ePaaS, SAP demands 25 per cent of the subscription income and a minimum charge. In particular, for those wishing to use advantages offered by the Hana services (Hana XS, GeoSpatial Services, etc.), the monthly basic price is at least EUR 990.
There is a range of meaningful scenarios for using HCP in the corporate context. It is primarily the application cases that deserve particular emphasis: these enable established customers of SAP on-premise systems to detach partial processes from the on-premise context and to make them available as a stand-alone app in the cloud.
This makes it possible to establish new innovative concepts and functionalities for business users, more quickly, in shorter development cycles and with flexible models for how to do this.
When a manufacturing company process its order, its staff can view the order’s current status via the ERP system or CRM system. The end-customer who has issued the order does not have this possibility. Usually someone wishing to find out an order’s current status has to call or send an e-mail.
Using a dedicated app, whether for mobile end-devices or only desktops, developed for the HCP and integrated into the on-premise system, this information can be offered to end-customers, simply and quickly. To develop apps of this kind, initially one needs a secure connection between cloud and on-premise.
For ERP systems and CRM systems, the Hana Cloud Connector offers this functionality; it constructs a secure SSL-VPN tunnel to the HCP infrastructure after the installation in the back-end.
In the HCP, for all third-party-system connections linked up via the Hana Cloud Connector, the corresponding configuration settings are then established in the connectivity services intended for that purpose.
Among other things, a determination is made about which services in the back-end system are permitted to be addressed by the Cloud Connector or – putting it differently – are on the white-list for integration. ERP systems or CRM back-end systems linked up via the connectivity services can be addressed directly in Java applications on the HCP, by means of JCo via RFC/BAPI function-call-ups.
Beyond this, it is possible to make end-points available for items in the back-end system via SAP-Gateway-OData; via REST, these end-points can be directly consumed by Java, Hana XS and HTML5 applications. This method is often preferred because it provides more flexibility in the solution architecture of the cloud application.
Companions on the market
Looking around the platform providers’ market for software development, three major product offerings cannot be overlooked: Amazon Web Services, Microsoft Azure and Google Cloud Platform. So why also consider Hana Cloud Platform and SAP as solution providers?
A comprehensive comparison of the various product offerings would go beyond the scope of this article; nevertheless we would like to single out what we see as the key characteristics of the product offerings named.
Amazon, as the pioneer of the cloud-based services, is by now offering a very large number of different services, and introducing new services to the market, more or less every year. For instance, AWS-Lambda makes it possible to execute one’s own program code in a function on an event-basis, in the cloud, so as to then continue processing the event locally or with other cloud-based services.
Beyond this, AWS offers the complete portfolio for ISVs wishing to use a platform-provider’s cloud-based services – ranging from simple storage space, a DNS administration and identity management, through to frameworks for Hadoop and IoT services.
Likewise, over the past years Microsoft has hugely invested in the expansion of its cloud-platform product offerings; by now it has put together an attractive range. Azure’s emphasis is on Microsoft technology, such as SQL Server, Azure Search, Azure DocumentDB, and Azure Batch, combined with a usage-based model for settlement of accounts.
Google Cloud Platform also offers a range of very popular cloud services, led by App Engine and Cloud Storage. As well as in Java, App Engine also supports applications in Python, PHP und Go. A particular feature of App Engine is its automatic scaling of applications, based on the degree of use, without the need to add further technical infrastructure components, such as Load Balancer.
All these three named providers offer a usage-based model for charging payments with regard to each service in their respective portfolio. Unlike AWS and Microsoft Azure, with regard to SAP HCP it is not always recognisable what the platform’s clear target-group profile is.
In view of just how different the services are, it is not easy to identify a specific usage scenario. The advantages in relation to the companions in the market are not immediately evident.
In addition, the services currently available are at very diverse stages of product maturity. There are services still classified as ‘Beta’ versions, as well as services with a very simple scope of function, while there is also a (by now) mature web development environment, like Web IDE. So without a publicly-available roadmap, uncertainties arise as regards the strategic IT planning in companies.
A key difference in relation to other providers is the still-absent tools for usage-based charging of payments for the services used; the context is to also be able to develop prototypes and POCs, with a comparable financial risk, on the HCP.
This also applies to ISVs who operate their products on the HCP and wish to offer them, and charge for them, according to usage. There is still a complete absence both of tools for charging resource-use and also of mechanisms for allocating the cost items without involving the Accounts department.
Among our market companions, such as Microsoft Azure, the use of configuration tools and price calculators makes it relatively easy to determine what costs a given solution generates.
Conclusion and licences
The HCP remains subject to a significant degree of adaptation, as regards the licensing model, and there is a whole range of different packages, individual services and various dependencies involved for each customer and each individual scenario.
This makes it harder for customers to evaluate their business case; in price terms as in other aspects, the HCP finds itself in an opaque ‘cost-cloud’ that can easily span a range from EUR 1,000 to EUR 50,000 per month.
Both technically and in terms of the subject-area specialisations, the intention is for the HCP to develop in the future, according to SAP’s plans. In technical terms, the transition to Cloud Foundry is intended to create a basis that makes it easier to extend the HCP for additional running-time environments, databases and services. It is also on the agenda to operate the HCP in non-SAP computing centres.
The subject-specialist extension consists of the offer of micro-services, as made available to SAP with the purchase of Hybris/YaaS. This means that more and more is being added in HCP’s Business Services area.
It remains to be seen how SAP succeeds in setting the boundaries between these new services, SaaS products and the classic business suite. With the HCP, SAP offers a PaaS platform that can also be interesting to non-SAP customers.