Tools

Point-to-point, and what it costs later

The first connection between two systems is cheap, quick and correct. It is also the one that sets the pattern, because the second connection is built the same way, and so is the seventh.

The cost is not in building them. It is that each link is a small piece of business logic living in the space between two applications, owned by whoever wrote it, and invisible to everyone else. When one system is upgraded, every link into it has to be checked, and nobody has the full list. When somebody leaves, the knowledge of why a particular field is mapped the way it is leaves with them.

The group’s own cost work names this directly: custom-coded point-to-point integration is where the process logic quietly ends up, and where it becomes expensive to move.

When point-to-point is right

It usually is right, for a while. Two systems, a stable interface, one owner, and a mapping that changes rarely. Building an integration platform for that is overhead with a licence attached.

The question is not whether to allow point-to-point links. It is whether you know how many you have, which of them carry logic rather than plumbing, and what would happen to each if the system on either end were replaced.

What we do here

Inventory first: every connection, its owner, its direction, and whether it carries a rule or only a copy. That inventory is usually the first time anyone has seen the estate as a whole, and it routinely finds links nobody has been maintaining for years.

Then the decision, which is a commercial one rather than a technical one: which links stay as they are, which move onto a platform, and which disappear because the data they carry should never have been duplicated in the first place. The platforms page covers what that platform layer looks like when it is worth having.