The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Enterprise "ConsultingWare" architecture.


I have a web application that I am planning to "productize" and resell to other companies.  As you can imagine each client has slightly different requirements so each installation will need some custom code.

As I see it my options are some variation of:

1) I could simply create a new branch in my version control system for each client.  This will give me a lot of flexibility but will lead to heaps of duplicate code and a potential maintenance nightmare.

2) The other extreme would be to have a architecture where all clients are on the same database and running on the same code.  All customizations are done through configuration screens.  At this stage I require a lot of flexibility to meet the needs of my clients.  (Basically I don't understand the domain well enough to know the level of customization future clients will require)

3) The middle ground would be some amount of common code with each client having a "clients" directory where I can override the default themes and classes.  There would be a shared database but the flexibility to create client specific databases for new functionality.

Has anyone figured out a good architecture to do this that allows a lot of flexibility but doesn't have a ton of duplicated code?
Wednesday, April 04, 2007
When you say "resell" to other companies, are you planning to give them the software and they host it on their machines? Or are you planning to host the applications themselves and "lease" access to the companies?
Wednesday, April 04, 2007
So...  our current roadmap has us "leasing" the application and hosting it on our servers but I might need to bundle up the application on a computer and ship it off to bigger companies so they can host it inside their firewall.
Wednesday, April 04, 2007
This is one of those times you want to develop a very clean API with a plugin system for the custom code/business logic.  Ideally, you can keep the custom code in each of the plugins/modules and not have to change the core system very often.  Realistically, I've never seen it work that way.

Regardless of whichever way you go, this is a situation absolutely *screaming* for Unit and Integration Tests.  If for no other reason to have validation that your API works as expected... if you break customers' extensions without *lots* of notice/explanation/planning, you will kill your sales.
KC Send private email
Wednesday, April 04, 2007
+1 for KC

Whatever way you look at this it is very difficult to maintain a product that is "customized" for each deployment without going fully down the consultingware model.

I'd be inclined to resist customer specific customizations but try to add features that grow your product core and are likely to be of interest to a number of clients.
Arethuza Send private email
Thursday, April 05, 2007
"Basically I don't understand the domain well enough to know the level of customization future clients will require."

Before you code anything more than a proof of concept, ask people about the domain until you're comfortable with the answer.

I know, I know, it's obvious, but depending on the product, the type of support you'll offer and the price point, you'll typically go either one way or the other, not both. As in a 95% to 5% ratio. For example, Salesforce hosts almost all of their services - part of their cost savings is in centralized management. SAP in contrast rarely hosts the software - they prefer the customer deals with the hardware support.

Since you have a roadmap that wants to start with hosting and leasing the service out to customers, I'm inclined to go with option 2. It's more work for you up front (a lot more) but it gives you the most flexibility down the road if you later determine you're going to sell it and let them host it.
Thursday, April 05, 2007

Thanks for the response.  We designed the application to be "software as a service" but nearly all of our potential customers are pleading to pay a lot more money so that we can customize the application and they can host it themselves behind the firewall.
So we are debating right now whether to completely switch our strategy.  (At least we have an application people are willing to pay for).

It seems like if we go completely in the SAP direction you architect your "base system" and then have a separate branch for each client?  It seems like so much duplication coming from a SaaS background.
Thursday, April 05, 2007
It seems to me that since you are in a learning mode you are simply going to have to allow for both possibilities.  The configuration is superior if you can do it but it may not be possible for some types of customizations. 

I would give a lot of thought in advance to my upgrade to new version methodology since that will be an important part of your plans.  You not only need to allow for separate versions for clients but also for separate versions merging back together as you improve your configuration capabilities.

Most likely early adopters will need special handling since they will be the ones that need the most special customization.  Later adopters will have access to the advanced configuration capabilities that you are forced to create because of early adopter requests.

Bill Hamaker
Bill Hamaker Send private email
Thursday, April 05, 2007
you can also just do the brute force approach: keep a common code base, fork it (branch) if there are too many changes for a client, then merge at a later time once you understand how to generalize them.
Early30sNerd Send private email
Friday, April 06, 2007
3rd approach works for our software. We can't sell without customization at all, but try to make versions for vertical markets. After one three development years we have 10 "versions" of the same software - core, some vertical market specific, some - single customer specific.

About half of each customer's customization getting to core / vertical market specific version, the rest is realy custom software (like import form customer-specific files or forming non-trivial reports).
Maxim Wirt Send private email
Monday, April 09, 2007
The 3rd option is kind of new territory but there's some good resources on this approach out there - google "software product lines"...or there's a few good books on it too. 

In general, if you go the 1st route, it'll be hell when your customers want to upgrade to new versions or apply patches.  This is typically bad for you and bad for your customers - you can't get any additional revenue because they can't upgrade, and they can't leverage your enhancments/bug fixes. 

One approach is to allow for option 1, but tell them that only your consultants can do enhancements/bug fixes to their installation.  This way you can funnel any specific bug fixes back into your core product (to use for other customers)...and you can also resolve any conflicts when it comes time to apply a patch or upgrade for that customer.  Letting them host it is smart, but don't give them the keys to your code for customization!
Ben Northrop Send private email
Wednesday, April 11, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz