The last few months, my team has been working on a sample SaaS application to demonstrate the multi-tenancy concepts I’ve been describing in my papers and blog. One of the areas we spent some cycles thinking about are the aspects of configurability that a SaaS provider should allow the tenants to have. I want to share some design lessons from my team’s discussions:
· Code upload – allowing third party to customize behavior through code upload is a dangerous pursue. You never know what kind of security holes can get introduced by untested third party code. If you think that this point is too obvious, imagine the scenario when you are considering letting your tenants customize the application workflow by introducing new steps in the workflow. It is tempting to make the configuration really powerful by letting tenants upload code that would handle the new steps in the workflow. (In Windows Workflow Foundation, the steps are known as activities). It is usually better to back off such temptation and scope down the level of configurability from a list of “templatized” activities instead. By templatized, what I mean is pre-canned activities that you the ISV have implemented yourself. For example, our human resource sample application has a recruiting workflow that lets the tenant add a new activity at the end of the workflow, but they can only choose from a list of approved activities that we implemented, such as one that sends email notification to indicate the outcome of a job applicant’s interview loop.
· New application logic – can get introduced even when the tenants are not uploading code. For instance, while allowing the tenants to modify the business rules seems like a good idea, you should limit the kinds of rules operators they can use. As an example, you may only want to allow the use of the <, > and == operators in business rules. Allowing tenants to add branches (for e.g. new if-then-else branch statements) in workflow can lead to workflow that does not terminate, hence resulting in non-deterministic behavior such as infinite loops. So again, the application should allow such modification very judiciously. Your application workflow designer may want to incorporate a validator to ensure that workflow changes will terminate deterministically.
· Extensions to entity definitions – Real world business concepts are often represented in the application as business entities. For example, the notion of a product catalog. In the physical world, what a product catalog looks like very much depends on the type of business the catalog is used for: a book dealer’s catalog item will want to include a field like “publication date” whereas a car dealer will want to keep track of the car model in the catalog. Therefore, a SaaS solution must often make provision for entities to be extended by the tenants. In many situations, adding new fields or modifying existing optional fields within an existing business entity can be accomplished without too much problems, as long as there is no new data relationship that needs to be specified between the new fields and other entities. On the other hand, allowing the tenants to specify entirely new business entities is very difficult and can break the application. For instance, if the tenant runs a pharmacy business and wishes to add FDA information to the product catalog. Instead of allowing a new business entity to be defined for the FDA data, the application should limit the definition of the FDA data as new fields defined within an existing entity. Allowing tenants to add and define new entity is a tricky feature because new database tables and often data relationships with other existing entities will have to be defined. Without doing a proper data schema analysis, it can be difficult to decide if the database tables and relationships supporting the new entity make sense or needs to be further optimized. This task is even harder when you consider a data architecture that uses the shared database, shared schema approach (as mentioned in our multi-tenant data architecture paper). Another consideration is, allowing tenants to add arbitrary new tables can potentially cause the shared database to run up against the maximum table limit pretty quickly.
In practice, does it mean that the ISV should always disallow code upload, new workflow activities and branching logic and new entities? This, I think, is a business question. All the above can definitely be done with additional code and data level design, implementation, testing and perhaps isolated deployment. The cost of providing the solution increases and it becomes a custom hosted solution for the tenant. You the SaaS ISV will have to decide if it makes good business sense to try bow hunting in Mongolia if there are low hanging tropical fruits in the long tail market.
I suppose it depends on how hungry you are.