Every integration team we meet runs the same play: buy a general engineering platform, spend two quarters bending it toward spacecraft, then describe the result with the same two words, almost works. That phrase has nothing to do with a missing custom field. The tool is telling you it was built for a different problem than the one you have.
The tools are good at their jobs. A PLM suite like Teamcenter or Windchill tracks parts, bills of materials, and revisions across a supply chain, and it does that well. A requirements tool like DOORS holds thousands of shall-statements and their traceability links. A SysML environment like Cameo lets a systems team model behavior and structure. Teams reach for these because they exist, they are already bought, and they cover most of the program. Then an avionics box from one vendor has to talk to a propulsion controller from another, and someone has to own that interface. The tool has no native shelf for it. So the team attaches a spreadsheet to a part record, or models the interface as a custom requirement type, and on day one it holds.
The interface is not a first-class object in any of these tools
Look at what each tool treats as its atomic unit. For a PLM system it is a part: something with a number, a revision, and a place in a bill of materials. For a requirements tool it is a requirement: a sentence with an ID and links to other sentences. For a SysML tool it is a model element in a diagram. None of them has, as a native type, the thing an integration program actually fights over: the executable contract between two subsystems, owned by two vendors, versioned on its own clock, able to generate the artifacts that prove conformance.
You can represent an interface in any of these tools the way you can represent a spreadsheet inside a word processor. You paste a table and it sits there. Representation is not support. The moment you need the interface to behave like an interface, the tool has nothing to offer, because the concept was never in its model.
You can point at the exact line where the tool stops
Watch an engineer work and the boundary is visible. The interface lives inside the platform right up until someone needs it to do something: drive a software-in-the-loop run, generate the MIL-STD-1553 message table, confirm that the bus voltage one side transmits matches what the other side expects to receive. At that point the engineer exports to CSV and opens a script.
That script is the edge of the tool. Everything past it is hand-built and unversioned, written by whoever drew the short straw and understood by them alone. The platform you pay for ends where the integration work begins. It manages the description of the interface and leaves you alone with its behavior.
A general tool configured for a specific problem does not converge on fit. It asymptotes: closer every quarter, never arriving.
Mars Climate Orbiter was an interface stored in the wrong place
In 1999 the Mars Climate Orbiter burned up in the Martian atmosphere because two pieces of software disagreed about units. Lockheed Martin's ground software reported impulse in pound-force seconds. JPL's navigation software read those numbers as newton-seconds. The interface contract existed. Engineers had agreed on the unit. The agreement lived in a document, and no tool checked the running code against it.
That is the failure mode of an interface kept as a description. A document records what two teams intended. It cannot enforce what their code does. When the interface is a document, conformance is a hope you re-verify by hand. When the interface is code, conformance gets checked the way anything in code gets checked: by machine, on every change, long before the parts share a room. The orbiter is the loud version of a problem that surfaces on every program that stores its interfaces where its tools cannot read them.
Each round of configuration costs you twice
The team's instinct, when the tool almost works, is to configure harder. Add a custom item type for interfaces. Script the export. Add fields for the things the script needs. Each addition makes the deployment more specific to your organization and more brittle. Then the engineer who built it moves to another program, and the next integration cycle inherits a structure nobody fully understands and nobody wants to touch.
Now the tool almost works in a way that is expensive to fix. You have paid once for the license and once for the workaround that quietly became load-bearing. The friction you felt on day one never left. It moved underground and started charging rent.
What changes when the interface is the thing you version
Put the interface where the firmware already lives. Define it in code, in the repository, next to the subsystem it belongs to. Generate the ICD, the 1553 table, and the simulation model from that definition rather than maintaining each by hand in a separate tool. Check conformance on every commit. The document becomes an output you trust because a machine produced it, not a file you trust because someone swore they had updated it.
This is not a feature you bolt onto a parts database. It is a different first object. The teams that stop fighting their tooling are the ones that stopped asking a parts catalog, a requirements ledger, or a behavior model to also serve as an interface system, and gave the interface a home of its own.
"Almost works" is the most expensive review a tool can earn, because it reads like success. A tool that failed outright would have been ripped out years ago. The one that almost works survives every budget cycle, collects another layer of configuration, and sets the ceiling on how fast you can integrate. You cannot configure your way to the last few percent, because that last few percent was never inside the tool to reach.
