Architecture: for a Single website to be supported for different Clients

Question

I have developed a system with one company profile. The system is built using WCF services, asp.net.

Now another company wants to use our system as well. And they might need some customization and some of their data elements are different. So I am planning to create a separate database for the new company and branch the business logic layer.

I thought of different options to architect this and ended up with the following. So what is the best way to design a system of this sort.

Approach A: Expose the methods as two different WCF services one for each company. So there will be one WCF client interface (IClient) but two different Service classes for each company implenting them. ClientAService : IClient, ClientBService : IClient.

Problem: The problem with this is all my datacontracts and datamembers are exposed to the client in 2 different namespaces. (ClientAService.ObjectABC and ClientBService.ObjectABC). So all the objects that I use in the website are conflicted. ie(when I have a list of ObjectABC in a datasource in the webpages, the website don't understand whether its from ClientAService or ClientBService.

Approach B: Expose the methods as a single WCF Client, but 2 different business logic layer. But they will use the same datacontracts. So the methods will return the same datatype.

so I will have one service class

ClientService : IClient

{
public <ObjectABC> Method1(String Companycode)
{
if(CompanyCode == "A")
    return new AbusinessLogic().Method1();
else if(CompanyCode == "B")
    return new BbusinessLogic().Method1();
}
}

Problem: The only problem I can think of right now for every new company, I have add the above else if part for all my methods.

I am also open to know if this can done in any other better way than the stated options.

note: I was told that there might be more companies to be added in future.

Answer 1

I am in a similar problem at the moment and I am sure it is a common one. I inherited an application that was rapidly developed for a single client, however it was well known before development even started that it would need to be highly customizable for multiple clients that may exist in the future.

Typical YAGNI principles applied and it was infuriatingly tailored to specific customer requirements and NOT to higher level company requirements. Basically this was a misinterpretation of the ACTUAL client. The actual client was the company itself, the development team should have developed software that met the companies requirements for a configurable and customizable product. The customer is just the client for the company at that point.

The best answer here isn't one that can be solved at the low level design like you are thinking. This is a high level design and architecture issue. The best approach is to revist your high level design and identify global components and global business logic that will be the same or mostly similar amongst all clients. If you have trouble even finding basic similarities then STOP because your new customer requirements are probably so wildly different that it warrants a seperate application.

Once isolating common business logic and components, identify individual and specific customer needs that are unique. Unique requirements specific to your current customer can be componentized out, while unique requirements for your new customer can be planned with requirements and user stories.

Additional development tasks would be to find specific static content and resources and make those configurable and dynamic (Eg. static helper text/tooltips specific to current customer, email and other message alerts, specific images and logos, etc...). These can be packaged into resource bundles typically that are unique to a specific customer deployment.

Other examples of custom components would be different aspect oriented features for different customers, (Eg. Customer 1 needs Login form authentication provider, Customer 2 needs LDAP Integrated Single Sign On authentication provider, etc...) Selecting a good framework and architecture that supports configrable aspect oriented features is a good step. Dependency Injection/Inversion of Control frameworks are a good approach as well.

With a bit of refactoring and a solid well planned redesign, an existing application tailored to a specific customer can be turned into a customizable solution that meets the needs of many different types of customers.