The benefits of platform multi-level
multi-tenancy

A while ago I was on a business trip to
New York for some meetings in Manhattan. One of the appointments we
had there was at the top floor of a skyscraper in the southern part
of Manhattan. I won’t easily forget the experience I had, stepping
out of the elevator: a stylish and spacious lobby with an
eye-catching wall to wall and top to bottom window offering a
magnificent view across the Hudson river with the Liberty statue in
the distance. You were almost physically pulled towards that window
to enjoy the view. The infinity pool concept applied on an office
floor…

This experience popped up in my mind when
I was thinking about how to explain a somewhat abstract concept as
multi-level multi tenancy. The idea of tenants and multi-tenancy in
the cloud surely has been picked from the real estate business
anyhow.

Most of these skyscrapers have multiple tenants hiring
space on a particular floor or on multiple floors. When I entered
this building I had to register at the front desk in the lobby
showing my ID etc. That’s a “shared service” for all the tenants.
When we got picked up by our host and got our badges, we could pass
the tourniquet and got access to the elevators, passing by other
shared services in the form of lunch restaurants, an espresso-bar
etc.

Translated to cloud multi-tenancy this is a pretty classic
example of how multiple organizations would share infrastructure-,
platform- and software as a service.

What’s interesting is
that this concept of getting access and sharing services was
actually applied again within this building by the company that we
were visiting. Our access to the meeting center was “controlled” by
registering our presence at the desk in this top floor lobby.
Clearly, we were received in a executive meeting center that was
set up to offer visitors an “experience”, not a regular office
space. I am pretty sure that our host got a charge on his cost
center for using the facility and so would anyone else from other
divisions and departments in his company who would be booking
meeting rooms over there.

Imagine that the landlord of the
building would only offer the top floor for rent if the tenant
takes the whole building. Imagine that the host of our meeting,
working for a particular division, could only receive us in the
meeting center if he would book that room for the whole year in
advance. I am pretty sure that I would not have had the opportunity
to enjoy the view on the Hudson from this height if that was the
case.

From the skyscraper to the cloud

It’s an
analogy obviously, but we are having very similar discussions with
enterprise customers and independent software vendors ISVs who are
seeking for ways to flexibly apply the multi-tenancy concept. Not
just subscribing to one or multiple tenants, but playing with
setting flexible levels of isolation and sharing across tenants as
per the need of departments, divisions, partners, and even their
customers.

A large enterprise interested in consuming Cordys
Cloud as PaaS, may want to share data, applications and process
across multiple participating divisions / lines of business, but
may need dedicated and isolated sub-tenants for some of those
divisions to run specific division level apps at the same time.

Similarly, an ISV offering software as a service applications
based on a cloud platform needs to offer multi-tenancy to their
customers as well. For ISVs it’s equally important to be able to
run application logic in a shared space across all the tenants, as
it is to support customizations of UIs, processes and even parts of
the application logic for individual customers in an isolated
environment.

So from a Platform as a Service offering
perspective, it makes a lot of sense to offer the PaaS customers
the possibility for them to use multi-tenancy as well within their
main tenant.

As we have been working intensely with large
enterprises and ISVs around our cloud offering, feeding us with
those ideas and requirements, we have been able to come with this
concept of multi-level multi-tenancy. We were very fortunate that
our technology foundation called the Smart Services Grid turned out
to be an ideal starting point for flexible and fine-grained
configuration of the multi-tenancy model, by just configuring the
desired level of isolation. Here’s how it works:

Smart Services Grid Foundation

Cordys Smart
Services Grid forms the technology foundation of Cordys Cloud and
the products and solutions that are built on the platform. All the
components in the Cordys platform, both design-time and runtime,
are implemented as services, grouped in Service Containers that are
hosted and managed on the Cordys Smart Services Grid.

Cordys
has used the Smart Services Grid as a bootstrap layer to build the
entire platform. Customers who build customer specific solutions on
Cordys, or ISVs who build standard applications, can leverage the
same powerful grid capabilities to build scalable solutions for
cloud and on premise.

For example, a process application
that is designed in Cordys has a User Interface, application logic,
a set of business process flows and web service integrations to
another application. It is a collection of design time definitions,
packaged into a Cordys Application Package and executed or
interpreted in the runtime. The application runs by handling
various instructions via the right service containers on the Cordys
Smart Services Grid. For instance, the User Interface (UI) service
container handles the UI requests; the Process service container
handles the execution of process flows, and so on.

A unique feature
of the Smart Services Grid is that it supports full multi-tenancy
with configurable levels of isolation on the Service Container
level. Cordys Cloud supports two-layer multi-tenancy with tenants
and sub-tenants (we call the latter ‘organizations’).

Configurable multi-tenancy

As the Service
Containers handle specific types of requests, you may configure
that a process definition is shared across tenants but the database
is isolated. All of our design time and runtime components, as well
as what customers and ISVs build on Cordys, automatically inherit
the multi-tenant behavior that can be configured as per the
customer’s needs.

We can configure multi-tenancy for models
like Shared Hardware, Shared OS, Shared Database, Shared Containers
and Shared Everything according to Gartner’s definition of
multi-tenancy models, and of course blends of those main models.
Each application built on Cordys can be deployed on the
organization level with configurable level of sharing of the
underlying resources like database, business process- and
application service containers.

Applications can be deployed
in shared mode on the main-tenant as well as on organization level.
The styling of the application can be arranged on organization
level.

Organization level customizations

Cordys
supports the concept of organization level customizations for
applications running on Cordys. Let us suppose that an application
contains a standard approval workflow that one particular customer
would like to implement differently, where the rest
of the
application will be used as per the standard.

In this case,
a customer specific workflow will be created and deployed in the
customer’s organization. Whenever the workflow is triggered, Cordys
will “know” that there’s a customer specific workflow that
supersedes the standard. It’s just this workflow that is customized
and deployed; the rest of the application runs from the shared space
on the main-tenant level.

The configurable multi-tenancy playing
with the level of isolation applied on main-tenant and sub-tenant
level comes with significant advantages:

• Sharing the right resources on platform and application level
  further reduces cost of “ownership”
• The ability to apply customizations on sub-tenant level offers
  the opportunity to create a tailored user experience at marginal
  additional cost
• For large enterprises if offers a unique opportunity to share
  corporate master data and horizontal applications across multiple
  corporate tenants that can be leveraged by various divisions and
  departments when building applications on sub-tenant level. This
  concept can even be extended to transactional data e.g.
  collaborating on a single object instance of an order by multiple
  supply chain participants.
• For ISVs it’s the way to leverage the benefit of the cloud in
  terms of lowering application life cycle management cost while
  staying flexible in addressing customization requests from
  individual customers.

If you’re interested to learn
more about the unique Cordys Cloud architecture, here’s
a link to the white paper describing it in detail.  BTW: As
we have one and the same version of our platform for the cloud and
on premise, you can leverage all of these concepts on prem as well.
If you’re interested we can share some great examples at lighthouse
customers with you.