Keep the rules out of the code and one program serves any number of customers.
What does it mean when software integrates with everything?
The claim usually means the connection works.
Connection is the part vendors demonstrate, because connection is the part that demos well. Data goes out of one system and arrives in another. Everybody nods.
The connection was never the hard part. The hard part is that the receiving system wants the data arranged its own way, on its own schedule, with its own exceptions, and the next customer wants something different.
Multiply that by every customer you have and you have the actual project. Nobody sells you that half.
How do you build software that handles hundreds of different customers?
In the early 1980s I led a project for a company called National TV Log, and their entire business model depended on solving that problem.
The idea was clever. Reach into a newspaper’s computer, take the file, insert small boldface advertisements into it, and put the newspaper back. Fully automated, no humans in the middle.
Around four hundred newspapers, each dialed up over a modem, because modems were what existed. Grab, insert, return, hang up, move to the next one.
Then the part that made it real work. Every newspaper had its own rules about where the advertisements went and how they were formatted.
Four hundred customers, four hundred sets of rules, no two the same. Every one of them wanted the advertisements handled their own way.
Why does per-customer configuration break software projects?
Because the obvious solution scales terribly and nobody notices until it’s too late.
The obvious solution is to handle the differences in code. The first customer is easy. The second is easy. By customer five you have branching logic. By customer forty you have a system nobody can safely change, because every change risks all forty. That’s the ceiling, and it arrives without warning.
Teams reach customer forty faster than they expect and the problem arrives fully formed. Nothing about it is gradual.
The modern version hides behind better words. Per-tenant configuration. Customer-specific business logic. Feature flags. Same problem, and the same teams hardcode the first three customers and discover it at the fortieth.
Where should business rules live in a system?
Outside the code, in something a person can read and change without a developer.
That’s what we did. The rules for all four hundred newspapers lived in a table, and the program read the table.
Building that table wasn’t trivial, because no databases existed to put it in. No structured query language, no commercial database engines available to us. We built the table and everything around it ourselves.
With no tools and no prior art, the design was still right. One program, and adding a newspaper meant adding a row and not writing code. Four hundred was what they happened to have. The design had no number in it at all.
Teams today have databases, configuration frameworks, and rules engines available for free, and a great many of them still put the customer differences in the code.
How do you know when to move logic out of code?
Three signals, and any one of them is enough.
The first is a conditional statement that names a customer. The moment code says if this is customer Jones, the rules have leaked into the wrong layer.
The second is a deployment required to onboard a customer. If adding a customer means shipping code, every new customer carries the risk profile of a release.
The third is a change nobody wants to make. When a small adjustment for one customer requires regression testing everybody else, the differences are entangled with the logic.
Any of those three means the rules need to come out. Doing it at customer five is a morning of work. Doing it at customer forty is a project.
What happens when a consultant does the job too well?
The code was finished and delivered, and the system worked well for them.
Then somebody from my team took a job at National TV Log and took the work over. We lost the account.
That outcome is fine, and I mean that. They got a good product, it did what they needed, and the person who understood it best was now inside their building instead of billing them.
A consultancy that builds something durable and documents it properly will sometimes lose the work to its own success. The alternative is staying indispensable by leaving the thing half explained, which is worse for the client, worse for the person doing it, and worse for the firm in the long run.
Anyone hiring a consultant should ask what happens when the engagement ends. A good answer describes how the knowledge transfers. A bad answer explains why you’ll always need them.
What can a 1980s integration project teach a modern team?
The system did its job. Four hundred newspapers, automated, running on rules in a table nobody had to compile.
None of the technology matters now. The modems are gone, the file formats are gone, the company is gone.
What survives is the decision that removed the ceiling. The rules didn’t live in the program. They lived in a table, and the program read the table, so the number of customers stopped being an engineering question.
Every platform sold today can do that. Most teams still don’t, because the first three customers don’t need it and by the time the fortieth arrives the code has already made the choice for them.