Feature Modeling: Configuration AND Customization?

The question then is what happens when you want to go beyond the feature modeler and it raises some interesting design questions for anyone trying to create a highly flexible Software Product Line . . .

At SystemsForge, our feature modeler allows you to define a feature as a collection of statements in any of our DSLs. Each statement is either essential (you want the feature, you need that statement) or optional (some people using the feature will find the statement useful). Optional statements can also be set as "default=true" for those statements that we think most people will want as part of their starting point.

What are the statements? The description of an object, a property, a relationship, a value list, a custom data type, a notification, a screen or any of the other elements that we have DSLs for.

So, with our core feature modeler, you can select any prepackaged feature and then configure it based upon our previous experience in generating such systems. This gets most of our clients most of the way to where they want to be. The question is how best to handle the "yes, but we also want" and "no, not like that" comments that always arise when you've finished configuring a system and need to start customizing it.

At first we allowed people to just add custom statements in any of the DSLs, so if you want to overload an essential statement, just add a custom statement with the same name and it'll replace it (and you're on your own if that breaks things . . . "with great power . . ." :->). Equally if you want to extend your solution by adding additional statements, you can just add new statements in whatever DSLs you need (a new object, property, or screen, perhaps?) and you're good to go.

That works up to a point, but lets say you have a catalog, shopping cart and checkout - all of which relate somewhat to a Product object. Lets say you add a custom Product.ShellsPerInch property to capture one of the key metrics for your lovely Australian shell necklaces and then later you decide to remove the shopping cart and checkout, should we automagically remove Product.ShellsPerInch or not? Because the statement isn't associated to a feature, it really isn't clear. In fact in this case your intent was to extend the catalog feature, so removing the other features shouldn't affect this statement.

There are work arounds for this. For example, most things in a system depend on objects (can't have a user list screen, a Boss relationship or a User.MiddleName property without a User object) so it would be possible to write something that removes any custom elements when the feature that originally provided the underlying object is removed, but that'd miss things like the fact that Product.Weight might only be required if you were shipping by a weight based shipper (depending on your use case) and might want to be associated to a configuration setting within the shipping feature which is part of the commerce system rather than being left in until you finally delete your catalog.

More importantly, for a really flexible system it'd be nice to allow end projects to add their own features. If I want to generate a disease tracking application for CDC, it might make sense to create some custom features like "Diesease Manager" for that project to pull together the potentially large number of statements that relate to that system (because they may well also be using the standard CMS feature and perhaps a standard discussion board system along with their own extended newsletter system to automatically notify first responders in case of outbreaks based on triggers in the custom DieaseManager feature).

An approach I'm thinking about now would allow each project to create custom features and to extend standard features so we have a better sense of intent for custom statements (we know what feature they are primarily designed to supplement - not just the object that they relate to). You'd then be able to just manage features like you would any other master:custom object where you can create and modify custom objects as well as being able to associate/disassociate to master (shared) objects and also to extend any shared objects with custom statements. The generalized CRUD and db schema need a little thinking, but I just think this approach is going to make the final system more usable.

Any thoughts?