“We need an interface.” Perhaps.

Start with a real event

Take one event that should cause data to move: a person joins, an application is approved or a record is corrected. Describe what each side believes has happened. Does “approved”, “active” or “complete” mean the same thing in both systems?

Ask who may decide

For each shared field, identify who may change it and which system is authoritative for which purpose. A synchronisation mechanism cannot settle a disagreement about authority. It can only implement a rule, including an accidental one.

Make failure part of the design

What should happen when the connection is unavailable, one side rejects an update or a correction arrives late? Decide who sees the problem, who can resolve it and what should happen in the meantime. These are service and responsibility questions as well as engineering questions.

Write down the agreement first

A useful starting document is short: the event, the meaning of the data, decision rights, expected timing, error handling and an operational owner on each side. A prototype can then test that agreement instead of quietly inventing it.

A question to take away

Are we missing a connection between applications, or an agreement between the people responsible for them? Often it is worth investigating both.