Why one workflow across twelve departments fails

Every internal platform arrives at the same fork. You have twelve departments doing roughly the same thing twelve different ways, and you can either model the twelve or model the one underneath them.

Modelling the one is enormously tempting. It is the cleaner schema, the smaller test surface, the shorter build, and it is the answer that sounds right in the room where the decision is made, because everybody in that room can see that the twelve variations are mostly historical accident.

They are mostly historical accident. They are also what those departments trust at two in the morning, and a platform that requires people to abandon a working process on the promise of a better one has to be right about everything else immediately, because it only gets one attempt.

What worked on on-call scheduling was drawing the line differently. The platform owns the things that must be true globally: who a person is, whether two commitments conflict, and how the result reaches a phone. Departments keep their own rotation rules, their own escalation order, their own definitions of who counts as covering. Twelve processes, one source of truth, and nobody was asked to give up the part they had opinions about.

The concrete test I use now: if getting this wrong hurts someone outside the department, the platform owns it. If getting it wrong only hurts the department, the department owns it. Conflict detection is the platform's, because a double-booked consultant is a hospital problem. Whether the rotation runs weekly or fortnightly is not.

There is a cost to this. The schema is genuinely more complicated, and every feature has to consider that departments differ. That cost is visible in the codebase forever. The alternative cost is invisible, because it shows up as a platform that nobody uses, and nobody files a ticket saying they have gone back to the spreadsheet.