h1

There goes the neighbourhood

January 17, 2010

The term ‘multi-tenanted’ is another of those misunderstood and abused terms.  Multi is pretty easy to understand – but ‘tenant’ is where the confusion lies.

I love communities; by locale and/or by sport or anything.  Groups and communities make the world go round.  Lets start with where you live; it’s a community (for city folk anyways), and if you’re in a unit block (and you rent) you are a tenant.  There are other tenants in other units, they come and go, and there are other unit blocks nearby with tenants.  Somewhere there may be a pool or other shared resource, available to the community, or some portion of.

Basing a ‘multi-tenanted’ IT system on that paradigm is what we tried to achieve at expanz.  Ultimately it means different things to different folk, so flexibility is paramount, but you gotta start somewhere.  Remember, we are a platform first and foremost, and our ERP system is simply a sample implementation.  So at the platform level, even the whole notion of multi-tenancy must be optional – not every system needs that.  Most LOB systems certainly dont.  What the ESA gives you is the concept of a tenant id at a session level (technically called a Context Id – more generic) that does not need to be used.  If used, when a user logs in (creates a Session) you can assign a Context Id and easily refer to that from anywhere in your code.

Now thats the most complex way to achieve it.  You could simply create application servers and databases as required, with zero coding effort and complete isolation between tenants.  But that doesnt scale to large numbers, and – in our minds more importantly – breaking that isolation is tough.  Back to the community thing.   In our ERP system, we use Session Context as Host Company Id – a Host Company being a tenant, with unlimited users per tenant.  Being a full featured ERP system, we have the concept of Articles (and services) as an abstract concept with stock being defined as an Article at a Stock Location.  Now we have a handful of ERP installs (each with their own AppServer farm); each of these is a different community.  There is an Event Management community, a Distribution community etc.  Each of these communities has a few shared resources and specialisations unique to that community, and common/shared data as well.  This is paramount.  When two companies trade goods, and they are both tenants in our ERP system, its best to have a common set of articles, rather than forcing a many-many mapping.  Sure you need to have an internal and external part number for trading partners outside the community, but for multiple tenants trading on the same community article abc123 should be universal.  Certainly there needs to be tenant-specific details – descriptions, pricing, stock etc but much of the data should be common.  This applies to a handful of features in the ERP system, and can differ by community.

Another great use for this is in accounting – different divisions of the same company can run as multiple tenants, with their own unique ledgers, but can share articles, suppliers etc and the parent company can then perform group-level or aggregated financial reporting.  This of course breaks the isolation between tenants, but for good – not evil – purposes.

Finally, where different tenants in a community have customisations, those customisations need to live side-by-side with core code and other customisations.  The ESA allows for this purely through metadata (and technically via reflection).  So a company that has a custom Sales Order class simply overrides the default classname with its own in the configuration and when a SalesOrder for that tenant is requested, the factory gives it a custom class.  Of course, the underlying database schema needs to be thought of carefully, and customisations necessarily must use non-mandatory columns for their Fields, but in general most of the customisations are code-based, not data-based.  For a community at least.  The schema of our Event/CRM database is different from the schema of our Strata Management database.

OK, one last point – at the platform level again, that good ole’ Session Context can be used to gather statistics and influence certain aspects of a Site (Load balancer + application server(s)).  Eg statistics by tenant, coercing SLA/performance features etc.  You don’t want one bad tenant hogging resources.  There goes the neighbourhood.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: