Introduction…
A previous post in this blog (shown below) covered the business benefits of executing a successful business platform strategy – as opposed to building siloed business applications ad nauseum. Perhaps the most famous example of an enterprise successfully executing a platform strategy is Amazon. Amazon began life as a retailer in 1994 and over time evolved into offering complementary services such as Marketplace, AWS, Prime Video, Payments etc. Amazon’s Platforms have led to an ever-increasing panoply of services, higher revenues, promoted more directed consumer interactions and higher network effects. Each of Amazon’s platforms generates its own revenue stream and many are large standalone corporations in their own right. However, the sum of these platforms is higher than the sum of the individual products & services they offer. This has, in part, led to Amazon becoming the most valuable company in the world (as of early 2018).
As a refresher, the below blog covers key business benefits and drivers of a platforms centric mindset & business model.
We now discuss the important technology considerations in creating a flexible multitenant Platform. Specifically, a Platform that hosts business services that can be offered as a SaaS to hundreds of enterprise customers.
What Designers Should Plan For…
The five key ways in which Platforms based approach will differ as compared to building one-off applications are shown below –
#1 Simplified Customer Onboarding
A unified and simplified customer experience is the biggest design consideration in a SaaS Platform. This is made more complex when existing customers agree to be licensed for newer applications. This needs to be made easy to perform via three capabilities for the Cloud admin team– Configuration vs coding, Integrated User Management, and Account administration. This means that different customers will have their entitlements and features dynamically managed by a ‘configuration wizard’. SaaS-based customer delivery can “check the boxes” to enable/disable specific solutions as opposed to requiring the implementation of this functionality in code. The SaaS platform should also offer features for customers to be able to configure their own organization units (business units, locations across various geographies and users mapped to those) as well as business workflows within those units. Further, the platform should enable customer administrators not only to perform policy-based governance on their users but also help them ensure that the usage of the SaaS platform is in accordance with any compliance requirements their particular industry is subject to.
#2 True Client Multi-tenancy
Across the Platform deployment, architects need to maximize utilization and improve security across all the four tiers – Web, Application, DB & BPM. What this will ensure as much as possible is that the provider will not be running dedicated instances per application per customer. Using mechanisms such as Linux Containers, applications across the Web/Application and BPM tiers will share the same underlying hardware yet be isolated from one another. This is, however, trickiest to solve at the Data level, each customer will have their own dedicated tables & data shall not be allowed to mix across applications & datacenters. The design needs to ensure true data isolation beginning with ingesting to analysis.
#3 Unified Customer Domain Models –
For reusability, it is key to ensure that domain models and the semantic definitions of entities (e.g. customers, users, orders, reports etc) in the core platform and the applications built on the platform both conform to a given standard. This Unified Risk domain model will permit two key capabilities – i) Collection – the ability to collect data across various tenant applications with their permission. This should be done with a view to improving the software for all clients. This will also permit the introduction of new business models as well as improvement of existing services. (E.g. The vendor offering a centralized data exchange for clients who are part of the community, offering a credit rating service for various clients by reusing). ii) Reusability – the ability for the SaaS vendor to establish one common metadata baseline for a given artifact – e.g. business rules, reports etc. These artifacts will only need to be managed and tested once so every tenant can inherit the business capability conferred by them. The design also needs to accommodate and deliver the effectiveness of this capability from a temporal standpoint e.g. versioning, upgrades and an ability for certain tenents to standardize on a given version of the artifact.
#4 Customizability
A key focus in reusability is to ensure a common software core for applications across all tiers – UX, Application Backend & Database. All core services should be reusable across the backend with an ability for customers to plug in their specific customization which does not break or hinder the baseline functionality. Accordingly, the vendor’s Product Management will help their technology teams define what areas are deemed to be customizable versus which are offered as a standard.
#5 Centralization of Business Processes & Case Management
The collection of all business processes defined by the vendor should be centralized in a BPMS (Business Process Management Suite) platform and these should be offered as a Service over RESTful protocols. The BPM workflows themselves will be wrapped around microservices to ensure their scalability. Care should also be taken to ensure the reusability of these business processes over time. Some level of inheritance can also be conferred on them using the notion of subprocesses which can be reusable based on a common library. However, this is open to further discussion and product definition based on the industry domain.