I had four conversations this week about the same damn problem, which is fixable.  Enterprise software buyers often request, and get, customized versions of the software they buy.  Building and supporting these customizations can exhaust even the best development team, and can slow down the vendor's product cycles to the point where the business is in danger.  If you aren't an enterprise software vendor, you can thank your lucky stars and move on.  Otherwise, read this article to find some solutions to this persistent problem.

If you sell enterprise software, you sell to big organizations that hopefully will pay you a lot of money.  In exchange for their business, they will ask for customizations, enhancements, and special features.  You will find that your biggest and most lucrative deals hinge on providing customization.

Sometimes, this can be a good thing.  The customer requests improvements that you need anyway, and is even willing to pay for them.  However, if aren't well organized, you will find that all of your energy goes into building and supporting customizations, and that your core product development effort stalls.  And, the delays only increases over time as you support more customizations.  My job is to figure out how to accelerate software development, so I consider those delays unacceptable. 

Figure 1 shows the simplest way that you can organize a customization.  You go to your core development team, and ask them to fork the code and build a custom application.  It's certainly the fastest way to get started.

The Fork and Go process causes two problems.  First of all, you are using your core development team, which is a limited resource.  It's not scalable.  And, supporting forks is SO PAINFUL and inefficient that most development organizations will go to extraordinary lengths to avoid this fate.

Typically, the team will move to the process shown in Figure 2 below. Instead of forking the code, they wrap everything into the core product, and the put in configuration switches to turn off things that the other customers might not want.  This gives you a smooth way to share the improvements that you really do want to include in the product.

Now you aren't officially supporting a fork, but you still have the problem that your core development team is doing the work, and that's not scalable.  And you have two new problems.

The short term problem is that you have just destroyed your agile release process, the process that works best if you release at a release on a timed schedule, rather than when features are ready.  Under this plan, you have promised specific features to a major customer in the next release, and you cannot release until they are ready.  The core product release will inevitably be delayed.

The long term problem is those configuration switches.  If you have N switches, you have 2^N ways to turn them off and on. Your product becomes exponentially harder to test for all configurations.

You may not even be able to specify the system.  I had a client that supported about 30 different configurations with about 100 switches.  Each switch triggered some sort of "if-then" behavior in the code.  This allowed them to accomodate a lot of different customers on one SaaS code base.  But when they wanted to move to a new implementation with a new programming language, it became clear that there was absolutely no way to fully specify the behavior of the system.  Instead of making a new system to spec, we had to write a translator to compile the old code into the new language, and then compare the behavior of the old and new system.  Obviously, it was impossible to test more than a tiny percentage of the possible combinations.

The solution is to move the customization to the customer side, as shown in figure 3. You provide an API, which has fixed and testable behavior, and the customer, or a new customization team, makes (and tests) the custom code.  This has huge advantages if you can do it.  You don't have to maintain forks, because the API is stable enough to support the custom apps in each new release.  And, you have created a scalable process.  You can  engage new teams to make the customizations.

But, there is a critical problem for new product development.  New products are new.  They don't have fixed API's or even fixed behavior.   You promise the customer that the API will be fixed and stable.  The very act of offering the API stifles future innovation.  The API should be introduced LATE in the product cycle, not early.

If you have any intention of innovating, I recommend the process diagrammed below in Figure 4.

This process is derived from the way that open source projects are organized. If you want something new in an open source project, you can ask the "maintainer" of the project to  include it in the core roadmap.  He can refuse on the grounds that there is a lot of other stuff to do, which makes it your problem, the customization team's problem.  That's what makes the process scalable.  However, you still have the option to build  your enhancements, and "contribute" them to the maintainer.  If they make sense, the maintainer will include them in the build and maintain them in future releases.  You get innovation without forking.  If the maintainer does not accept the enhancements, you end up with a fork and some future merging.  However, you still get the scalability and freedom of running your own team with it's own custom release cycle.

This is a no-lose situation for the core team, since they are protected from disruption by the maintainer.  It's exactly what we were hoping for as a way to accelerate core development. 

When you combine this with an API or some other extensible architecture, you get the best of both worlds.

This is a good way to integrate a distributed team, working on customizations and customization architecture, with an established core team.