The difference between integration and interoperability is the difference between a private road and a highway. Integration connects two specific systems through a custom interface. Interoperability connects any number of systems through a shared protocol. Both get you from A to B, but only one scales.

The integration trap. Every integration point is a custom project: custom data mapping, custom error handling, custom monitoring, custom documentation. Five systems require ten integration points. Ten systems require forty-five. The cost grows quadratically, and the maintenance burden grows even faster because each integration point is a unique piece of code that must be updated whenever either system changes.

The interoperability principle. Interoperability replaces custom integration with agreed protocols: data formats, authentication mechanisms, error reporting standards, and versioning conventions. Any system that implements the protocol can communicate with any other system that implements the protocol. The cost grows linearly—each new system implements the protocol once, regardless of how many other systems it needs to communicate with.

Protocol design. A good interoperability protocol specifies: the data model (what entities exist and what attributes they have), the transport (how data is exchanged—REST, messaging, file transfer), the security model (how authentication and authorization work), the versioning strategy (how protocol changes are communicated and adopted), and the error model (how errors are reported and resolved). Each of these is a binding contract between systems, not a configuration option.

Government context. The EU ISA2 programme and its successor, Interoperable Europe, are built on exactly this principle: define common protocols for cross-border digital services so that any member state can connect to any other without bilateral agreements. TED tenders that reference ISA2 specifications are not asking for custom integrations—they are asking for protocol compliance. On the US side, SAM.gov contract vehicles for federal systems increasingly reference FHIR for health data, OCDS for procurement, and other open standards.

The organizations that will thrive in the interoperability era are those that invest in protocol design, not integration projects. A well-designed protocol is an asset that appreciates. A custom integration is a liability that depreciates.