Enhancing SaaS comes in many forms but the first question which should be asked is "Why extend Saas?". The answer is quite simple, one size never fits all. For many customers the functionality of SaaS is great but they need a couple of tweaks/extras to full fill their SaaS application functionality needs. At this point it is worth pointing out that there are two types of "SaaS Extensions"
For this series of articles we will be focusing on the extension and integration use cases and not the configuration scenarios.
Before going ahead and reading the rest of these articles, I invite you to listen to this short 5 minute video on "What is extending SaaS with OCI" from Arvind Srinivasamoorthy , this is posted on the Oracle A-Team Youtube channel where you will find this video and many others related to Oracle Fusion SaaS, for example Extending HCM Approvals using OCI by Mani Krishnan and Loading Data into ERP using OCI by Angelo Santagata, both of these videos are discussed in this series of articles on Extending SaaS with OCI
Before we go any further it's worth stepping back and asking ourselves , What do customers want from a SaaS extensibility platform, whilst every customer is different there are a number off common themes we hear from customers when describing features they desire/want from a extensibility platform.
When Oracle Fusion SaaS Applications (aka Fusion SaaS) was first launched, we also launched a "SaaS" friendly Java cloud called "Java Cloud Service- SaaS Extensions" (aka JCS-SX ) and a related single schema Oracle Database. Both of these services were limited in what they could do but they were totally managed by Oracle (not server-less but totally managed). With the JCS-SX service you could only deploy Java Enterprise Edition WAR and EAR files, you had no control of what OS the JCS-SX instance used, no access to the file system and you could only use JDBC against one, and only one, schema DB. All the routing , firewall, network/OS updates were done for you. Like JCS-SX the database was a "schema" database and you only had access to one schema , it was space limited, no access to the oracle god user SYS or SYSTEM and you could only access it using JDBC from a related JCS-SX instance. Both of these services sound really limited but customers effectively swapped flexibility for zero management by themselves - that's a huge win for these customers.
SaaS customers bought SaaS , "Software As A Service", and they have no desire to manage a set of services for their extensions. These two services (JCS-SX and SchemaDB) where probably Oracles first fully Oracle managed technology services where the the primary objective was that Oracle manages the service and not the customer.
Going forward the server-less style of deployment is becoming more and more attractive to SaaS customers, that's one notch beyond Oracle managed.
Painless SSO and identity propagation is something all SaaS extensibility customers desire. Any framework used must support both SSO and identity propagation either out of the box or with very little configuration.
One aspect which worked well in the past was ensuring the UIs were consistent with Fusion SaaS. When you are building a SaaS extension you are building a new "User Interface", you therefore have full control of the UI, CSS Style-sheets etc alas it's up to you to make things "look" the same . In the past we realised customers did not want to invest on keeping the UIs looking the same, they just wanted to build their applications. Given Oracle JCS-SX was Java based, and our then preferred UI technology was Oracle ADF, we published Fusion SaaS compatible CSS stylesheets and even a template ADF application which contained all the CSS stylesheets/UI templates that a customer would need to build an extension that looked the precisely the same as Fusion SaaS.
In the past Oracle launched services like JCS-SX and SchemaDB specifically designed for extending SaaS, they were good in their day but we now are looking at new modern technologies, for example cloud native services and the Oracle Cloud Infrastructure (OCI) platform. In this new world serverless is gaining in popularity and OCI supports many serverless services, e.g. "Cloud Functions". At the same time if the customer determines they want more control then they can use the Oracle Kubernetes Engine and use whatever language they want , ultimate flexibility in networking and so on. For integrations we have Oracle Integration Cloud, Oracle's modern declarative integration service.
Whilst Oracle provides services like Oracle Integration Cloud some customers still prefer to build the entire integration flow using code. A simple integration flow , e.g. soap to rest, can be built very quickly with Cloud Functions, and API gateway, these two services work well together and provide somewhere for the transformation logic to reside and API Gateway exposes the logic to the web and adds security , rate limiting and other web API related features.
The Cloud is also maturing, so instead of "pure" technical cloud services, like Kubernetes, Compute , Networking etc we're now starting to see "value added" cloud services appearing. These are services which solve a business/functional problem and examples of this can include services like the Anomaly Detection service, which when trained can alert you to anomalies in your data set, image processing and data recognition services and many more to come. These services are almost always built using cloud native technologies ( i.e. born in the cloud) and are often server-less in nature , ie you don't manage anything and pay by usage.
As a team we have written, and still writing!, a number of articles where we cover many of the "Extending Oracle Fusion SaaS with OCI" topics. Please select one of the links before to read the article and check this page often as we will be adding links to this page in the near future !.
Extending SaaS using OCI series