+972 52-548-6969
Multi Tenancy - Approaches and Applicability
Previously on the Multi Tenancy series:
- Multi Tenancy - Definition and scenario.
- Reviewing Litware HR - P&P Multi Tenancy Sample.
- Multi Tenancy - The Physical Data Model
- Multi Tenancy - Extensible Data Model
- Multi Tenancy - Extensible Behaviors
- Multi Tenancy - Development Structure
- Multi Tenancy - Where do you put variability?
- Multi Tenancy - Scriptability and DSL
- Multi Tenancy - multi tenant apps and frameworks
- Multi Tenancy - Keep It Simple, REALLY Simple
- Multi Tenancy - User Interface
Yes, I said that the UI post was the last one before I got to the actual implementation details, but I am having a Skype chat now about the subject, and it is important.
The approach that I have outlined so far is focused on building a system that supports variability at all levels, from the database to the UI, through the entities, services and external integration points. The sweet spot for that is if you have a multi tenant application where a tenant want to have high degree of control on the way the application works.
This high degree of control often means that the tenant desires to change specific parts of the applications in ways that make sense to this tenant, but may not make sense to others. A good example would be payroll system. Here, each tenant has their own processes for how to handle this, and they tend to maintain a high degree of control over that.
A good example from the other side would be something like Subtext. Here, we have a multi tenant application that is essentially the same for all the tenants. The behavior of the system is essentially the same for everyone.
That doesn't means that if you need variability in the application, you should immediately jump to the approach that I outline here. If you have a limited number of variability points, and limited number of variability options (that is, you have X amount of strategies that you can configure for each tenant), you might want to consider that approach.
I would probably avoid that anyway, but it is something to take into account. Some people would feel that a few configuration options makes their life easier than a composite, contextual, application.
My rule of the thumb is that if you have both data extensibility and process variability you need to use the composite approach that I have spoken off. Even if you don't have data extensibility, but "merely" lot of variability in the process across the tenants that cannot be standardize, you will want to take the composite approach.
Comments
Ayende [the unsleeping], you post like a mad man. Good stuff, just hard to keep up with when you've got other things to do.
I know I'm a bit late commenting but I just wanted to say thanks for this series. Are you planning on writing some further installments sometime?
As someone who has had experience with the 3 table approach (combined with a somewhat abandoned tenantId) and dynamically generated UI, I can assure you that it is indeed very difficult to manage. I would definitely adopt the approach you propose if developing another system.
I was also curious as to whether or not you are going to continue this series. You served us theory as appetizers... now we're ready for the meat!
A new post in the series will be out soon
It's been interesting to read your thoughts on this issue. Thanks for sharing.
I have been working with a web-applikation for some years now that manages members in different organizations (scouting, shopping clubs, labour unions). So far we have managed the variety by branching off a core system and then developing all the non-standard features in a separate branch. So each customer has it's own separate code-base and database, which means it's not really multi-tenacy today.
But we are now thinking about building a real multi-tenacy system (or rather a standard applikation used on many different customer sites) and it's nice to see that our ideas about "how" so far seems to line out with others (yours and your fellow commentors).
We can handle a flexible database schema as well as getting the new fields in the UI (including validation etc.). We can also handle the various bussiness rules by composition, strategy objects and policy objects through IoC as you write yourself. But the biggest challenge I see is workflow management - it is incredible how different the procedures can be for signing up new members and signing them out again (what's that called in english?). The only solution I see to that is a complete rewrite of the workflows for each customer.
/Jørn
Jørn,
Build it in such a way that it is possible for each customer to have their own workflows, then it is easy.
See also the discussion on JFHCI
Ayende> Build it in such a way that it is possible for each customer to have their own workflows
Yep, that's also the conclusion :-)
Comment preview