One of the most important characteristics of cloud software is the high degree of standardization which allows for lower prices for the customer and greater efficiency for the SaaS provider. Yet customers also want to customize such environments to more closely fit their needs. One way to meet this requirement is through the use of extensions.
In the SAP Cloud space, the HANA Cloud Platform (HCP) is the platform of choice for such applications. There are various extensions that already exist (Accenture HR Audit and Compliance as well as the extension from Chris Paine and Discovery Consulting) and a tighter integration with the HANA marketplace for SuccessFactors extensions has just been announced. Yet, the architectures of such extensions are largely undocumented. By architecture, I’m not only referring to the internals of the extensions themselves but also their interaction with the extended applications.
Note: There is no single pattern / architecture for extensions. Depending on the characteristics of the extended application and the business requirements behind the scenario, different combinations of the existing technologies in the HCP are possible.
Note: Extensions could potentially run on a multitude of platforms – there are various PaaSs that would fulfill this purpose – but I’m going to concentrate on those extensions running on the HCP.
A simple diagram depicts the fundamental relationship between an extension, the application that is being extended and the platform on which the extension is based.
Note: The extended application in question can be a Cloud- based or OnPremise application
In order to extend the application in question, the extension needs information about the context in which it must exist; therefore, it must access the underlying data of the application. The extension can accomplish this via three methods:
- Dynamic via an API that is provided by the extended application. Excellent examples of this pattern are the SuccessFactors Extensions which use oData (for example sap_hcmcloud_core_odata and sap_jam_odata) to access HR-related data. For OnPremise applications, this access might be based on the Cloud Connector.
- Static storage where the necessary data is transferred from the extended application to the data storage of the HCP. This may take place via the integration tools (for example, using HANA Cloud Integration (HCI))
- A combination of both API / static storage.
Extensions in a multi-tenant world
The architecture of a single extension within the HCP is relatively straight-forward. However, as the popularity of the HCP increases – leading to more customers using extensions and more partners / SAP creating such extensions- then things get rapidly more complicated. .
HCP supports multi-tenancy and extensions which run in this environment are provided with various technologies / patterns to meet this business requirement.
An initial scenario deals with an extension that supports multi-tenancy.
What happens, however, when multiple extensions for the same extended application from different partners are present in the HCP? The extensions will probably exist in the particular server instances that partners have purchased and thus have no direct interaction with each other.
There are different scenarios in which the related data storage-related requirements would play a role:
- The customers / tenants for each application are different. In this scenario, the use of the usual multi-tenancy technologies is the preferred architecture to deal with such situations.
- The same customer(s) use different HCP-based extensions coming from different partners.
The second scenario is more interesting to explore.
The generic pricing structure for extensions on HCP is still open but the package prices for the SuccessFactors extensions are based on various factors (number of apps, number of custom MDF objects, etc) including the amount of data stored in the DB. Thus, a customer would have an incentive to avoid duplication of its data. Multiple copies of its data also mean that synchronization with external data sources must occur multiple times; thus, increasing complexity.
Ideally, there would be a single data source for each customer. What are the technical possibilities to achieve this goal?
Note: Although HCP supports MaxDB and the HANA database, I’d like to focus on HANA.
Dedicated HANA instances – – would make this possible.
The database structure for such extensions is non-trivial inasmuch as the particular extensions need to store their extension-specific data as well as have access to the common customer data shared by all extensions.
The administration of such databases is difficult inasmuch as the permissions / rights for such environments are complex.
Another option would be to separate extension-specific data in a separate database that would be able to store data from multiple-tenants.
Internal extension architecture
Although I’ve concentrated primarily on the interaction between the extension and the platform itself, I’d also take a quick look at the internal architecture of such extensions.
I know of just a few extensions where details about internal architecture are available (for example, the sample extension on github). The primary development language of such applications is Java and based on API access (for example, the oData interfaces in SuccessFactors). As the popularity of HCI increases then the prevalence of HANA-based data storage (for these scenarios) in HCP will likely increase as well.
Polyglot (HANA XS + JVM-based) applications are a perfect combination to meet the unique requirements associated with such extensions.
Note: You could probably use HANA-XS to create an API dominated extension but this really isn’t the optimal use case for this environment.
Extensions are critical for the success of the HCP.
Currently, only SuccessFactors-related extensions are up and running but you can expect extensions for other SAP offerings (Ariba, Hybris, etc) to start emerging as the platform matures and the ecosystem realizes the potential of this technology. In these early days, complex usage scenarios must be examined / understood now in order to assure that best practices are established to avoid any delays / speed bumps as the level of market penetration / acceptance accelerates.