This is the situation that I've seen two times in a row already.
A company makes software intended to be sold to other companies. So there will be relatively few clients, but each is an important one. An obvious, though by far not exhaustive example of such software is an ERP system.
Now each client company has their own peculiar workflow and their own peculiar requirements. It is the product that must adapt to the client, not the other way around, or else the client will not buy the product.
The result is that there will be multiple, similar though different versions of the software, each version tailored to the needs of each particular client.
From my experience, the common solution to this conundrum is to attempt to make the software highly general and configurable. An entire team will be dedicated to understand the very complex configuration system and interact with the clients. This team will be responsible to click their way through this very complex configuration system, thus configuring the software for the client, adapting it to the client's needs and readying it to work.
This approach, from my experience, has important flaws.
- From the programmers' point of view, the product, in its entirety, is incoherent, too big, too complex and frankly weird. It is hard to understand it and develop it.
- As mentioned before, the configuration is really very complex. Being able to understand it and to use it properly is not a small feat, which is why there must be employees who specialize in this very task. The configuration is also dangerous, since any mistake in clicking the numerous checkboxes, selecting proper values from numerous lists, sometimes even entering pieces of code, etc., etc. will result in the whole software working incorrectly, maybe even causing data corruption.
Can this be somehow avoided?
I wonder if the famed article on the Daily WTF about Soft Coding is not the answer here. Indeed, the configuration becomes so vast that I wonder if (even if the possibility to enter custom code is ignored) it is not accidentally Turing-complete. This is because in this approach, effectively, the configuration will have to store business rules. But business rules belong in code, not configuration, and the code is where they should be modified and adapted.
It is obvious that the software must adapt to the client, not the other way around. But perhaps the proper solution is to ditch the utopic goal to make the software so very general and configurable, strip the configuration system to the bare minimum and embrace that the product will be adapted to each client through code, rather than configuration?
Maybe simply utilize conditional compilation? The product will be compiled and deployed separately for each client. Define compile-time constants denoting the client, enable or disable features in the code rather than configuration depending on the client.
The counterargument to the above is that if that was embraced, then the software engineers will become responsible to directly respond to clients' needs. Each time a client has any grievance a patch will have to be made in the code, the whole system will have to be compiled, tested, and deployed again. This will take days, if not weeks.
Such delays are unacceptable unless absolutely necessary. Whenever possible the clients' needs must be answered by sending our configuration specialist, who will then reconfigure the product within a few clicks. This will take just one day.
But, wasn't this fallacy addressed in the aforementioned The Daily WTF article? This is what The Daily WTF calls "The Dreaded Deployment". But if making changes in code and deploying is hard, then the solution is to fix the issues that make deployment unwieldy, rather than trying to avoid deployments by letting business rules be set via configuration.
Maybe, after all, there aren't any hard reasons why making changes in the code and redeploying the product must take days, if not weeks?
Also, from my experience, frequent changes in the code to respond to changing business requirements is a reality any way and the very complex configuration doesn't remove this need.
Why do companies making software sold to other companies tend to attempt to make the code general enough to meet the needs of all clients at the same time, while adapting the product to the needs of each client through configuration?
Is there a better way than that to let the product adapt to the clients?
Would stripping configuration to the bare minimum and adapting the product to each client in the code help here? Would it even be feasible?