Preferred way for dealing with customer-defined data in enterprise application

Question

Let's say that we have a small enterprise web (intranet) application for managing data for car dealers. It has screens for managing customers, inventory, orders, warranties and workshops.

This application is installed at 10 customer sites for different car dealers.

First version of this application was created without any way to provide for customer-specific data. For example, if dealer A wanted to be able to attach a photo to a customer, dealer B wanted to add e-mail contact to each workshop, and dealer C wanted to attach multiple PDF reports to a warranty, each and every feature like this was added to the application, so all of the customers received everything on new update.

However, this will inevitably lead to conflicts as the number of customers grow as their usage patterns are unique, and if, for instance, a specific dealer requested to have an ability to attach (for some reason) a color of inventory item (and be able to search by this color) as a required item, others really wouldn't need this feature, and definitely will not want it to be a required item. Or, one dealer would like to manage e-mail contacts for their employees on a separate screen of the application.

I imagine that a solution for this is to use a kind of plugin system, where we would have a core of the application that provides for standard features like customers, inventory, etc, and all of the customer's installed plugins.

There would be different kinds of plugins - standalone screens like e-mail contacts for employees, with their own logic, and customer plugin which would extend or decorate inventory items (like photo or color).

Inventory (customer,order,...) plugins would require to have installation procedure, hooks for plugging into the item editor, item displayer, item filtering for searching, backup hook and such.

Is this the right way to solve this problem?

Answer 1

Many systems have a "configuration" section for a dealer. This is often a simple (dealer_id, name, value) truple in a database. The code reads all this in and can show/hide (or, using server side technology, include/exclude) certain user interface options. Often, a user_id is tied to the dealer_id, so you know who gets what.

You CAN do all this with user roles, but it can become confusing that way.

I have often found that custom code makes for distribution and testing nightmares. I believe it can be done successfully, but it sure seems simpler to just turn stuff on and off in configurations.

Make sure your database columns are nullable or have decent default values, of course.

Answer 2

You are on the right track. Plugins provide a clean mechanism for extending the core data and application with client specific data and business logic.

You have to architect your database such that client specific data can be added to any of the core data.

Let's say you want to provide an extension mechanism for customer data. Let's also say that core customer data consists of:

1. ID
2. Name (first, last, middle)
3. Address

You could add to that:

4. Extension

Extension could include the ID of the dealer and a list of database names where the extension data can be found.

In your example for client A, you could create a table for storing photographs of customers. That table and the logic for manipulating the photographs could be packaged into a plugin for client A. If another client requests for the same functionality, you could install the "customer photograph" package to them.

Since the extension data allows for multiple extensions, a client could request as many plugins as they want to use.

You have to manage packaging of the right set of plugins for each client.

Answer 3

In the beginning, you will develop "custom" designs for your existing customers. Once you have a "critical mass" of these "custom" designs (for your original customers), you will be able to mix and match your designs for newer customers. At this point it will make sense to have specific installation procedures, hooks, editors, etc.

Answer 4

Looks like you need to put authorization in your system. Develop all functionality but put client ids against each services /UI and based on the current client id fetch the specific feature.

Answer 5

When you build modular systems you have to think about how extensions will be permitted to manipulate/augment your exposed extension points. This always adds some complexity to a design, but when well done, provides for a superior product. Consider how various browsers are designed for plugins.

Practially speaking I would build extension points on an as-needed basis in order to accommodate desired customizations. That is, instead of simply extending your software to do X, consider how to best provide an extension point that would allow X to be plugged in.