Possible Duplicate:
How do you manage extensibility in your multi-tenant systems?
I asked this on StackOverflow, but I thought it might be more appropriate for Programmers.
I've got a few big web based multi-tenant products now, and very soon I can see that there will be a lot of customizations that are tenant specific.
An extra field here or there, maybe an extra page or some extra logic in the middle of a workflow - things like that.
Some of these customizations can be rolled into the core product, and that's great. Some of them are highly specific and would get in everyone else's way.
I have a few ideas in mind for managing this, but none of them seem to scale well. The obvious solution is to introduce a ton of client-level settings, allowing various 'features' to be enabled on per-client basis. The downside with that, of course, is massive complexity and clutter. You could truly introduce a huge number of settings, and over time various types of logic (presentation, business) could get way out of hand. Then there's the problem of client-specific fields, which begs for something cleaner than just adding a bunch of nullable fields to the existing tables.
So what are people doing to manage this? Force.com seems to be the master of extensibility; obviously they've created a platform from the ground up that is super extensible, you add on to almost anything with their web-based UI. FogBugz did something similiar where they created a robust plugin model that, come to think of it, might have actually been inspired by Force. I know they spent a lot of time and money on it and if I'm not mistaken the intention was to actually use it internally for future product development.
Sounds like the kind of thing I could be tempted to build but probably shouldn't. :)
Is a massive investment in pluggable architecture the only way to go? How are you managing these problems, and what kind of results are you seeing?
