How do you implement customer specific differences in your web app?

Question

We have a Seam 2 based web application with the usual user login and a couple of views which have handler classes interacting with a local database and a web service.

Now, we need to implement customer specific differences - so the use cases are basically the same, but for example customer A wants a couple more fields on the form, customer B a different web service call and customer C another role with different access rights.

I know my question isn't very specific - but I'm looking for general ideas how to handle such a scenario without having to maintain different separate versions of the application or having lots of ifs in the XHTML or the java code for getting different behaviour.

So since this is I guess a common scenario - how do you handle it?

Answer 1

Fields

If the business case is the same and the fields don't influence it directly you might just opt-in for a user- or companysetting. So just a checkbox which modifies the layout. Hard thing which you should be aware of is validation of required fields. Since that might differ between your customers.

A step further you could go for flexible fields and all that kind of things but that will get quite complex directly. If you don't need to don't go there.

ACL

The ACL could be just made flexible enough to support different settings per customer, that shouldn't be a big issue.

Webservice

The other webservice: If it is another webservice but it gives the same info back you could just implement an interface. That way you could flexibly switch per customer. The nice thing is that your application get unaware of which webservice it actually is but it understands the interface. More on this: decoupling is the keyword.

This also generates a well testable piece of software which allows you to develop in the future further without much hassle.

Know when to stop

If it gets too far with customization understand where to stop. Don't get into too many difficulties, when a customer want a customer piece of software it should become one at some point in time. See also: http://gettingreal.37signals.com/ch05_Start_With_No.php which is quite relevant, you can't satisfy everyone with a standard piece of software. There will be lots of hidden costs: http://gettingreal.37signals.com/ch05_Hidden_Costs.php

Think that gives a well overview. If you need more details maybe separate this question because each of the three questions has it's own issues.

Answer 2

This is a very common problem in software development without a clear answer, so the best answers you will find will end up being advice.

The dirty little secret that we know is that unless you are selling software in a box on a shelf at Staples, then you are probably just providing the illusion of a product that cloaks truly custom software.

Because ultimately when developing business applications, all of your customers want custom built software, but they want to believe they are purchasing a product. It is simply human psychology, when we buy a product we tend to not only feel like we got a better deal but that we will be more forgiving of slight flaws or annoyances. When buying something custom made we immediately tend to feel like we are overpaying for a luxury, so if everything doesn't turn out exactly as I want it, it will be unacceptable.

The best way I have found to handle this is to have a person in your company with the strong authority of being a Product Owner. This person will be the Alpha and the Omega on every feature and change that goes into your software. It is the Product Owner's job to mitigate the disparate and sometimes completely opposing customer requests into a single set of software requirements and features that will make the majority of customers happy the majority of the time.

Simply by the way your question is worded you are already approaching the problem incorrectly by wondering how to technically deal with your different customer requests. The only customer you should care about as a developer is the Product Owner, whose job it is to tell you what custom features, settings, flags, resource bundles and forms should be included and how to flip different features on or off to satisfy the companies customer needs.