How an overly broad entity breaks every integration
The pattern is always the same. In the first version of the software there is one central object: the work order, the production line, the bill-of-materials line. Over time that object accumulates more and more fields, because every new request is parked inside it rather than in a new, focused model. After two years that single table has forty columns, a third of which are empty in most records. When you then build a connection to an ERP system, you have to explain what field 27 means. The ERP system has no idea. The developer writes a mapping, the mapping works, until someone adds a new field type to the work order. Then the mapping breaks. This is not an incidental bug. It is the structural outcome of a data model that was never involved in the integration.
Relations patched in after the fact: the silent killer of API stability
Worse than broad entities are relations that are bent into shape after the fact. Suppose a work order and a customer order start as separate concepts, but at some point someone decides to put the customer order ID directly inside the work order as a shortcut. Convenient for one screen. Disastrous for every API that has since relied on that relation. Because a customer order can drive multiple work orders, and a work order can later be split. The data model says otherwise; reality says differently. The API then returns stale or duplicate data, depending on which screen was built first. Integrations with customer portals or MES systems that rely on that API return incorrect production statuses. Not always, because that would be easy to spot. Occasionally, just often enough to make troubleshooting time-consuming.
When should you redesign the data model before continuing with integrations?
The honest question is not whether you will ever need to redesign the model, but when. There are two signals that indicate you can no longer avoid it. The first signal: every new integration takes longer than the previous one, even when it appears to be the same type of connection. That means the mapping logic is growing, not the integration itself. The second signal: bugs in the integration cannot be reproduced without knowledge of the internal state of the system. If an external party, a client, or a new team member cannot make sense of your API output without an explanation of six historical decisions, the model is the bottleneck. At that point, redesigning the model is cheaper than continuing with adapters. Not cheaper in the short term, but cheaper over the first twelve months after the decision.
When is a temporary adapter sufficient in manufacturing software?
There are situations where an adapter is the right choice: when the existing system is stable and the connection to an external system is limited in scope, meaning one direction, a small number of field types, and a low mutation frequency. An adapter is also defensible when the organization is in the middle of a larger migration and the connection is intended as a bridge. What an adapter never is, is a structural solution for a model that is too broad. Adapters copy the problem to a different layer. They translate noise into noise, just in a different format. After a year you have two complex problem areas instead of one.
What you can do concretely when integrations keep breaking
Start by mapping the entities that appear in more than two integrations. Those are the candidates for redesign. Then look at each entity to see how many fields are optional, and whether those optional fields actually belong to a subtype. A work order for revision is different from a work order for production, even if they currently fit in the same table. Separating them takes little effort in the model, somewhat more in the existing integrations. But it is finite work, unlike the endless repair of breaking APIs. If you reach this point and the system on which the integrations run is older than five years, it is also the moment to assess whether the software itself is due for replacement. Not always the answer, but a question you need to be willing to put on the table.