how to maintain multiple components for multiple client for multiple features?

Question

Basically my project is product based. Once we developed a project and catch the multiple client and deploy the application based on their needs. But We decided to put the new features and project dependent modules are as component. Now my application got many number of customer. Every customer needs a different features based on the component. But we have centralized component for all client . we move the components additional feature to client specific folder and deploy. My problem is , I am unable maintain the components features for multiple client. My component feature code is increased and I am unable to track the client features. Is there any solution for maintaining the multiple component features for multiple client ?

Answer 1

You are essentially talking about software product lines (SPLs): variations from a common base. Since you already package your features as components, you need a specialized tool to manage such variations.

You can then build a complete custom application based on a configuration that is unique to any given customer. Easier said than done, of course.

A model-driven software development(MDSD) approach can help a lot on this task. One such system that can support this development setup is ABSE, an emerging MDSD approach that among other things, can implement a software product line (info at http://www.abse.info - Disclaimer: I am the ABSE project lead). There is no product yet though. An alpha preview is coming.

Again, I know some companies that, using an MDSD coupled with code generation, have achieved what I understand you want: products that are half pre-packaged, half custom.

Answer 2

I've worked for a couple of companies in a similar space - product software but very heavily customised.

Essentially there is a decision the company needs to make - are you a product company (that is you ship broadly the same to every client) or are you a bespoke company. At the moment it sounds like they're between two stools and wanting the economies of being a product company with the ability to meet specific client demands the way a bespoke software company can.

Assuming the company wants to be a product software company, unless there are specific technical reasons why you can't, you need to move to a single code base with the modifications for each customer being handled through customisable options (i.e. flags saying how this particular situation is being handled, whether this feature is available and so on).

These can be set at run time (so they can be changed as the client wants - think options in Word or Excel), or build time (so code is included / excluded when you do the build), but the key things is that every client has to be pulled from the same code base.

But this needs to be agreed with the business as it limits what they can sell - every change they sell has to fit into an overall vision which can be accommodated by the single product.

The alternative is that you're essentially producing bespoke software for each client (that is coded specifically for what they want) but using many common libraries. That's fine and allows you to produce something which is exactly what they want but in the end it is going to be more work and the business needs to understand and cost for that.

We actually do a bit of both - there is a server product which is identical for all clients, and then web and mobile clients which are specific to them (in the case of mobile you can't have lots of dead code on the device - the web stuff is historic and will be moving to a standard product for all clients).

Good luck though, it's a difficult problem with no easy solution.