What is configurability?

Configurability is the ability to change application behavior (functionaility) and the interface by changing application parameters, without the need to rewrite code. This can either be done in the front-end by users, or through back-end configuration. On the other hand, customization requires making change to the application code to modify existing or support additional requirements. Sophisticated application design (e.g. web hooks) can permit customization by externalizing the new functionality. But modifying existing functionality in a multi-tenant application is really not advised.

Top 3 / All-time favorite requirements

1. Web forms / Custom fields: Customers may require the flexibility to add additional fields to a particular document/record (object). Moreover, there would be a need to validate the input to the field based on data-type, or a script. For example, tenant A may require tax-ID as an additional integer field on the customer information object, and also make it a mandatory input. This has grown to be complex enough to support attachment fields, link to master data, controlling access to specific roles/user, etc.
2. UI customization: Customizing the user interface involves matching the look-and-feel with the customer’s branding: corporate color scheme and adding their logo. Allowing users to customize their own data views (record lists, reports) is just assumed to be there. Sometimes controlling data elements could also be a requirement. (E.g. End-users wont know certain information, so a section needs to be hidden for them. But the next user in the workflow should be able to complete it). Customizing the print views is another one. (E.g. Payroll software needs to be able to print pay-slips in the format the customer follows)
3. Configure the process: Although a highly complex requirement, several business applications allow configuring a business process in the system. This involves defining custom workflows and changing the navigation flow based on conditions and state of the object. For example, some companies may need finance to check budgets before sending a purchase order for approval, while others may want to do it just before sending the order to the supplier.

Tips/Caveats for a product manager:

• Configurability involves high cost. Apart from demanding high development effort, it also affects system performance because the system changes behaviour at run-time. Use real good judgement when adding configurability.
• Business requirements should be thoroughly analyzed and qualified configuration requirements should be put in to one of these 3 categories depending on how the frequency of change & impact:
  • configurable through the frontend (customer needs to change this often, and change needs to be instant)
  • configurable through the backend (customers don’t need to change this often and can wait for the vendor to make the change, of course without modifying the application code)
  • customizable in the backend (a particular customer needs this change to meet their specific business need and requires modification to the application code)
• While you may assume things, such as the customer’s operating currency, to be configurable, it is important that you let engineering know in the early development stage. If they go about hard-coding value, parameter-izing the value later could be costlier.

This post is part of the SaaS Application Development series, extracted from my final dissertation submission at BITS, Pilani that closely looked at rapid-development of SaaS-based applications.