Hi Ryan,
thanks for putting up a definition. I wanted to get back quickly for now but will also attempt a more detailed answer later on.
In summary, I think that if we removed the tenant-level admin privilege, we won't have a multi tenanted system and would run the risk of implementing half a solution with the difficult bits to add later on (which will cause major issues in my experience).
It probably needs further analysis and explanation but as it stands, I would advise against removing this from the scope of the MVP (if we really want to achieve it).
Definition:
The key defining factors for MT for me are:
- single codebase
- tenant level admin functionality
- full data separation between tenants
- super admin privileges
Conversely, I don't think that the URL comes into play. I have seen (and designed in part) MT system implementations, which feature multiple URLs, e.g. to achieve the feeling of a separate system and bring in tenant-specific branding.
Explanation:
Single codebase is self explanatory but it's worth highlighting that the database infrastructure may not be a single one. I.e. I think having multiple databases used by the same codebase is valid and permissible (although it's often a workaround for a less well designed system or retrofitted MT).
Tenant-level admin. The crux (hardest part) of multi tenancy is achieving the data separation for admin level access. This is where non-true MT systems will fall down. If we store this up for later, we run the risk of getting it wrong now. My sense was also that by going with a node.js and from scratch approach we would stand the best chance of solving this issue and build solid foundations. Should scope & timelines be the underlying issue, I therefore recommend taking the approach of developing less admin functionality but making all of it 'true MT' (= solid foundations).
Achieving full data separation between tenants is at the heart of achieving true MT, i.e it's the reason for going with MT in the first place. So rather than dividing up system functionality into the examples given above (users, projects/courses etc), the aim should be 'the whole system'. We have learnt this on fitting MT into Moodle / Totara and I'd be keen to share examples of the issues we have seen with this if that would help. One of these examples is that unless you have full-system MT out of the box, you will have to base additional functionality on items like groups, which means interweaving functionality which will make writing code much more complex and prone to error / performance issues. I also think that users could (not should) in time have access to multiple tenants - the example here is basecamp and a real life thought might be that a content producing services company (like Kineo or Learning Pool) could run/host a tool for our clients and our internal staff may need access to multiple tenants to work across projects for different clients.
The presence of a super admin or tenant admin account is a further sign of a true MT system. This would be to manage global system config (e.g. to do with the underlying infrastructure config) and to administer tenants, quotas and the like. This account would be disconnected from any regular use of the tool.
I hope this makes sense. As I say, thanks for posting this and it's a very important debate to have at this stage.
Thanks, Sven
PS: I'll try to engage with the other items and questions raised in a further post.