Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We have developed one product for payroll processing. We have 10+ customers who are using this software product.

Our existing and new customers are giving us customization changes w.r.t. their needs, and now we are facing the problem of product management. Please give some guidelines to us.

How to manage single software product to multiple customers?

Software developement details :
Front End Tools : Visual Studio 2008 (ASP.net web application)
Source Code Mangement : Visual Source Safe (VSS)
Back End : Sql Server 2005
Team Size: 12

share|improve this question
add comment

5 Answers

Fundamentally there are two ways to approach this:

  1. Have a single product that can be customised principally via configuration to suit an individual client's requirements
  2. Build a product for each client based on a standard framework and a common core set of libraries.

The problem with the former is reconciling conflicting requirements from different customers the problem with the latter is that you're now supporting a product per client and that things will drift apart over time. In both cases you want to have mechanisms for managing the specific configuration data for each client.

My personal view is that (without a lot more detail) you're almost certainly better off dealing with a single application - certainly I had reasonable success with feature toggles in a multi-client web application but keeping track was challenging.

Looking at your toolset, there's reasonable support for Themes within ASP.NET and lots of scope for plug-in systems - but you should be looking at updating your tools and especially getting a more reliable/more capable version control system.

share|improve this answer
    
+1 for stop using Visual Source Safe –  Michael Feb 13 '13 at 13:45
add comment

Changes that customers need will fall into one of 4 categories in my experience:

  1. Changes which other customers will find useful but the "initial" customer is willing to pay for.
  2. Changes which other customers will find useful but the "initial" customer is not willing to pay for.
  3. Changes which other customers will not find useful but the "initial" customer is willing to pay for.
  4. Changes which other customers will not find useful but the "initial" customer is not willing to pay for.

For 1, make the changes in the core product and release an updated version to all your customers (you get paid for developing it and you get goodwill going forward).

For 2, make a business decision on if the change is valuable enough to generate further sales to make it worthwhile, if so, make the change in the core product.

For 3, Create some kind of plugin system where you can create a custom add-in component for specific customers.

For 4, I'd recommend not doing this at all.

share|improve this answer
    
While a useful answer, this seems to be related to "mbas" more than "programmers". But the original question is so vague I don't know if this is what he's asking for or not. –  tieTYT Feb 13 '13 at 20:08
add comment

In such an application it would be wise to separate the code into generic parts (database driver, widget library), and a configuration part which describes the specific implementation of those generic parts. I would strive to keep the dynamic part as small as possible, and reuse as much as possible. Each customer would have a joint generic part, and a custom configuration part. If any changes are needed to the basic infrastructure, these changes can also be applied to the other customers.

In practice, you could split the software into two repositories, one for the generic part and one for the configuration part, this last one unique for each customer.

share|improve this answer
add comment

This is one of those times where you want to look at configurable options. I know this is an anti-pattern for some cases, but not in this case.

What you need to identify is the areas that clients are looking for customization. Make those the points where you break out configuration files or put values into a configuration db.

Don't go overboard, try to keep the sales team in check with what you can and cannot customize. I have seen this too and it gets very messy very fast.

If these types of configurations are not possible, look at creating interfaces to services or libraries that contain the common code between all clients and the code that is unique. Again the sales team needs to know where these lines are and how expensive it is going to be to create each customization.

share|improve this answer
add comment

I have found a podcast that talks about these issues. Maybe this will be useful for you to listen to.

In this episode Michael interviews one of our regular listeners: Petri Ahonen. Petri introduces Software Configuration Management by defining key terms and describing relevant concepts

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.