The Problems with Configuration Based Software Product Lines's

Back in 1999 I co-founded a company called The Strategy Factory in Houston Texas. The goal was to deliver "million dollar websites from a thousand bucks a month" . . .

At the Strategy Factory we effectively used a configuration management approach. We had a number of features (shopping cart, checkout, discussion board, etc) each of which had configuration options and a framework that would provide each client with the functionality they requested.

This worked OK for the first few clients, but as we got more and more projects, each wanted to change another element that we'd considered invariant. Let's look at the shopping cart/product catalog functionality as an example. First clients wanted to change the properties of products. Then they wanted to change the approaches to calculating shipping and tax rules. Before long they wanted to change the number of screens in the checkout and to add custom business rules giving different users completely different checkout flows.

It certainly didn't help that we were using a procedural language at the time and that none of the team had experience in architecting software product lines, but before long we were buried under an avalanche of configuration options and both the configuration interface (with a small i) and the underling code base were becoming unmanageable.

At SystemsForge we've always taken a very different approach. We use a collection of horizontal DSLs for describing views, controller actions, business objects, object relationships, object properties, object behaviors, validations, workflows and the like. Of course, the problem with such an approach is that on it's own it wouldn't provide a quick enough development experience. If you just need a standard shopping cart and I have to ask you to describe all of the properties of orders and order items and all of the screens and controller actions, my approach could take hours to develop a system you could get from Yahoo! stores in about 2 minutes.

The solution to this is to add some kind of configuration management/feature modeling solution for common requirements. However, crucially, instead of implementing the configurations using a 3gl, each configuration simply adds or replaces statements in the various horizontal DSLs. So, if you want to add a shopping cart, it'll require order and order item objects with the base necessary relationships, properties and validations and a default set of views and controller actions. You could also choose different configuration options for a cart that each would add, remove or replace certain statements within the underlying DSLs.

In this way you get a number of benefits. Firstly, because each feature is implemented using DSLs providing a fairly high level of abstraction, it is much quicker and easier to implement completely new features. Coding a simple discussion board feature in a 3gl might take a week or more. Describing it using our DSLs might only take an hour.

Secondly, any given application only includes the code required to implement the required functionality. All of the configuration is implemented through adding or removing DSL statements from the model so you don't need to implement configuration mechanisms at runtime to allow for a wide range of configurations you might now actually require. In practice this makes it very easy to handle large numbers of possible configurations as providing they can be described using the DSLs no changes to the core framework or code are required to add new potential features - you just come up with a different set of statements.

Unfortunately, there are also drawbacks to the approach, but I'll leave that for my next posting!

Thoughts?