January 22, 2018 at 2:21 pm
I'm seeking your advice and / or experience about why and how for the following:
Let says you're developing a software. That software has core features that can be augmented with additional "selectable" (a la carte), from a marketing perspective, options.
Core features are always active.
For instance you could have that scenario:
Customer #1: Core features + option A, B, D
Customer #2: Core features
Customer #3: Core features + option D
Which database approach / design would you use and why?
- All features always available inside the database (therefore each deployment has always everything, same schema everywhere, but options are enable or disable by the application somewhere else)
- Only usable options that the customer paid for are deployed in the database, therefore the database schema (tables, sp, views, indexes, name it) is different from installation having different option selected.
In the example above, all 3 customers will have distinct database schema.
Customer #4: Core features + option D will have the exact same schema as Customer #3
I tend to see the "all features available" with far less maintenance overhead but I'm seeking advices and experience on that topic in case of something I might overlook.
Regards,
January 22, 2018 at 3:46 pm
I came from an environment where each customer has different and evolving customization needs. The application was designed in such a way that each customer can demand their own mix of feature set. The approach was to include everything in each release. Custom scripts were maintained at each customer's site (within the database). Paid custom features were enabled by a license key.The feature set mix is transparent to developers - they only need to write code. Deployment team would alter the feature set as new or new custom features become available. As for the feature set, there was a default feature set that everyone needs. On top of that, customers can define their own mix. Every feature set can call another set using a 'include'. Of course, duplicate features fro the 'included' feature set will be overridden.
No matter how thorough you are in the design phase, sooner or later you run into situation that demands exception handling. So it was not unusual to see customer name hardcoded into a script (we had to check installation code, which is based on customer name) that get deployed to all customers during product upgrade. As long as it didn't break anything, we had never had any complaints.
January 23, 2018 at 6:29 am
Thank you for sharing me this experience.
You're right there will be exceptions down the road.
January 23, 2018 at 7:26 am
Megistal - Tuesday, January 23, 2018 6:29 AMThank you for sharing me this experience.You're right there will be exceptions down the road.
I worked for a couple of commercial software companies - they used the "all features" approach. It seemed like a more standard implementation this way and then used customized scripts for different customers to enable/disable. It was relatively easy to add or remove features and the maintenance would read the settings so implementing that was standard across the board.
Sue
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply