Extension architectures on the HANA Cloud Platform: Multi-tenancy and beyond
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.
General discussion
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.
Conclusion
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.
Dick thx - they say there are no dumb questions so I'll test that here. 🙂
I've had a chance to see the HCP SuccessFactors extensions and Chris Paine and Luke Marson also shared some valuable insight. So far, I like what I see.
My question becomes: if extensions are truly necessary to facilitate the process of developing add-on apps, and you'll need extensions for each application on the HCP (SuccessFactors, Ariba, hybris, Cloud for Customer, etc), doesn't it start to become pretty complex to maintain those extension sets and keep them current.
If so, doesn't that conflict with the goals of creating a easy-to-use development environment and keeping cost of maintaining such a platform under control? Wouldn't it be more ideal to be able to issue a ton of APIs and not worry about building and maintaining a bunch of extension sets?
I'm sure I"m missing something here but as SAP is still early on in building out extension sets I'd love to hear your take on what the best practice would be from an architectural standpoint, and if it will hold up from extension set to extension set or is each one going to need to have its own nuances?
Overall I love to see SAP investing in making HCP world class, just want to better understand what this is going to take.
Jon,
API's require the same amounts of maintenance as extensions would as it's only a more technical description of what the other would do, but you're right on the money. new additions make the whole system even more complex and more prone to systemic failure, but there's a trade-off between integration and its cost. very often, it resembles spending good money after bad as new versions and compatibility troubleshooting require new rounds of "extending".
just my 2 cents.
rgds,
greg
Dick really touches upon a lot of topics and I still have to let it sink a bit. However, my initial thoughts here is that we are mixing up several topics....
The way I see it APIs are the foundation enabling extensions. That said, APIs need to be adhere to certain characteristics e.g. being backwards compatible, being well-documented and stateless. In the classical ABAP space there are BAPIs and Enterprise Services to address that need. In general, such APIs should be exposed in such a way that they can be consumed from both internal functions and outside processes.
Now, in order to extend the business logic or to alter the processing flow you'd need to have a built-in extension mechanism. For that, there are two options: the extension mechanism is a) built-into the app or b) built-into the container/platform. A classic examples are BAdIs (Business Add-Ins). These allow you to alter the processing logic and they are multi-tenancy compliant, meaning every tenant can have a different set of BAdI implementation being active.
For those interested to dig deeper into the topic, you may want to read the corresponding chapter 2 of this (free) ebook: Building Extensible Composite Applications with SAP [free PDF]. (While the book was written with on-premise composite solutions in mind, the underlying principles are the same and can be applied to cloud solutions as well.)
Now, with all that in mind I think the key topic is how-to integrate the extension into the original solution environment (e.g. Employee Central) as seamless as possible. This is where the extension packages come into play in my point of view....
In general, my advice to solution providers is to provide extensibility within your solution right from the beginning as it's the only sustainable way to ensure that your solution can grow/adopt over time. As Dick mentioned, a vital aspect of such a capability is to expose some sort of "context" that extensions have access to in order to hook into the processing.
A while back I have written a post about how one can use the HANA Cloud Portal to create extensible UI5 applications: Extending SAPUI5 web applications with SAP HANA Cloud Portal
Cheers,
Matthias
Matthias thanks for this. The comments on APIs, business logic and Dick's own views on exposing context definitely helped me.
As Matthias suggests, there are various topics that can be explored with this blog as a starting point. I didn't want to tackle all of them at one time and thus, many aren't explored further.
Dick
Dick thanks for the blog and the illuminating follow on comments. These are meaty issues and in my view critically important so I will read further updates from you with interest.
Dick, thanks for putting these diagrams together, will make explaining how some of the extensions I'm working on "work" much easier!
It should be noted I think, that the current extension offering with SuccessFactors sees the customer paying for their own space in the HCP and using multi tenancy is rather redundant. Each application will get it's own schema if it chooses to persist data outside of SuccessFactors. Multi tenancy in this case seems to be wasted effort, unless you build a separate global shared "app" that all customer apps can speak to. (not sure you have this diagram!) However, in this case of a global non-customer specific data store, the space and CPU for the shared instance needs to be provided by the app provider and is not under the control or monitoring of the customer. Customers will need to be aware of this when they subscribe to these application extensions.
In the case of multiple customers having their data in a multi tenancy environment, I wouldn't see the customer extensions talking directly to a shared DB but would have a model/service layer over the top of any shared DB at the very least - patching every instance of every customers' extension at the same time so that changes could be made to the data model of the common DB for example would be very very hard - but maintaining a standard API to the common data would be much easier.
I would be interested if it would be possible for multiple extensions to share information. In the solution I'm building right now, we considered whether it would be worth offering "sub modules" of the application as additional extensions or not. We decided not, it will mean more hassle in the provisioning of the functionality to customers (which modules should be enabled or not) and also in the organisation and payment of subscriptions (no ability to enter credit card (wouldn't that be nice) and have it all done auto-magically) however, it does means that the integration hassles of getting different extensions to talk to each other are side stepped. It also allows us to offer some nice "try before you subscribe" options which don't require additional installs by the customer. (In our cases the size of the custom software is dwarfed by the libraries that are used to implement it - having multiple modules that aren't used is a tiny tiny overhead for a customer).
Anyway - speaking of the extensions that I'm working on "now" I should really do some of that work. Thanks for this piece and getting my name up on the SCN front page 🙂
Cheers,
Chris
Chris,
I really enjoyed your comment, because it is based on the practical experience of someone who is actually using this technology. Your remarks also show that the architectural issues are indeed non trivial and must be considered by customers and providers of such extensions.
SAP places much attention on the basic extension technology but the real challenge will come as more extensions become productive. There is still much work to be done dealing with these other issues that will gain in importance as the platform matures.
Thanks for taking the time to comment. 😉
D.
Hi
As you mention at conclusion "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".
I understood 'Extensions for SuccessFactore' is only available. However I didn't understand whether extension for Ariba is available or not now.
Could you let me know regarding extension for Ariba?