What happens if an enterprise software vendor adds a required field to a widely-integrated interface, believing it is a minor change?
Show the full answer Hide the answer
What happens
Every integration that does not send the field breaks, and they break at different times — whenever each one next runs.
The failure distribution is what makes this severe:
- Interactive integrations fail immediately and are noticed.
- Nightly batch integrations fail at 2 a.m., discovered the next morning, having skipped a day of data.
- Quarterly or annual processes fail months later, long after the change is forgotten, and the investigation starts from scratch.
- Partner integrations fail on the partner's side, so the vendor learns through a support escalation rather than through monitoring.
For enterprise software, "widely integrated" often means integrations built by third-party consultancies, running in customer environments, with no telemetry back to the vendor. The vendor cannot enumerate the consumers, cannot measure the impact, and cannot roll back a change that customers have already adapted to.
Why "required" is the specific problem
Adding an optional field is safe: existing callers ignore it, new callers use it. Adding a required field changes the contract's precondition, which is a breaking change regardless of how small the field is.
The same asymmetry applies throughout:
| Change | Safe? |
|---|---|
| Add optional field to request | Yes |
| Add field to response | Usually — unless consumers validate strictly |
| Make optional field required | No |
| Remove field | No |
| Rename field | No — it is a remove plus an add |
| Narrow a value range or enum | No |
| Widen a value range or enum | No for responses — consumers may not handle new values |
That last row surprises people: adding a new enum value to a response breaks consumers that switch exhaustively on the old set.
The correct approach
Expand and contract. Add the field as optional. Deploy consumers that populate it. Measure adoption until it reaches effectively 100%. Only then make it required — and only if that is still necessary, which it frequently is not.
Tolerant reading on the consumer side, established as a platform convention: ignore unknown fields, do not fail on unexpected enum values, do not depend on field ordering. This is the discipline that makes response evolution possible at all.
A registry of consumers, derived from telemetry rather than from self-declaration. Most fear of changing an interface is fear of unknown consumers, and that is an information problem.
Contract tests owned by consumers, running against the provider's build, so a breaking change fails in CI rather than in a customer's overnight batch.
The principle
In an enterprise integration landscape, an interface is not a contract with a team — it is a contract with an unknown population over an unknown timescale. The only safe change is one that cannot break a consumer you have never met, and the only safe deprecation is one measured before it happens.