An interface inventory is the least glamorous document in an implementation and the one most likely to determine whether it lands. It is also the one clients most often believe they already have.
What they usually have is a list of systems. That is a different thing. A list of systems tells you what exists. An interface inventory tells you how data moves between them, who notices when it stops, and what breaks downstream.
Why the count is always wrong
Because interfaces are not only the things engineering built. Three categories get missed almost universally.
Human interfaces. A person exporting a report from one system on Monday and importing it into another on Tuesday is an interface. It has a schedule, a data contract and a single point of failure who takes annual leave.
Inherited interfaces. Built by someone who left, still running, undocumented, and nobody is entirely sure what depends on them. These are found by switching things off in a test environment and waiting for complaints.
Outbound obligations. The file you send a customer weekly. The stock feed a marketplace pulls. Nobody thinks of these as integrations until a migration breaks one and a customer calls.
How to find them
Do not start from the system list. Start from the data and follow it.
Pick an entity, not a system. Take an order, an item, a supplier, a payment. Ask where it is created, then where a copy of it ends up. Follow each copy until it stops moving.
Interview by task, not by system. Ask people what they do on a Monday morning, not which systems they use. Manual interfaces surface as routine tasks, never as integrations.
Read the scheduler. Whatever runs your cron jobs, scheduled tasks or batch queues is a list of interfaces someone already wrote down without calling it that.
Check the mailboxes. Shared inboxes that receive automated files are interfaces. So are the rules that file them.
Ask what breaks at month end. Anything a close depends on is an interface with a deadline, which makes it a higher-severity interface than its daily equivalent.
The interfaces that hurt in a migration are never the ones on the architecture diagram. They are the ones somebody built quietly because it was faster than asking.
Implementation lead, AxonRaysSeven things to record about each one
Keep it to one row per interface and resist the urge to add columns. The point is a document that stays current, not one that is comprehensive once.
Source and destination. Which system produces the data and which consumes it. If there are three consumers, that is three rows, because they fail independently.
What moves. The entity and the fields, at a level of detail someone could rebuild from. "Order data" is not an answer.
Trigger and frequency. Event-driven, scheduled, or a person. If a person, name the role rather than the individual.
Direction of truth. Which side wins when they disagree. This is the single most valuable column and the one most often blank.
Owner. A named role that gets told when it fails. Not a team, and not a system.
Failure behaviour. What happens now when it breaks: silent, retried, alerted, or noticed by a customer. Be honest, because this sets the priority.
Downstream consequence. What stops if this stops. A feed nobody reads and a feed that blocks dispatch need very different treatment.
What the finished inventory is actually for
Three things, in order of value. It tells you the true scope of the project, which is almost always larger than the module list suggested. It tells you which interfaces need designing properly and which can stay manual for now. And it gives you a document to hand your own team at the end, so the next implementation does not start with the same archaeology.
If you take one thing from this: fill in the direction-of-truth column for every row before anyone configures anything. Nearly every integration argument later in a project is that column, unresolved.