3,000 m
The architecture
A catalogue is a product, not a wiki page
Most organisations have an integration catalogue. It lives on a wiki, it was last updated by someone who has since moved to a bank, and it lists forty patterns in a table nobody scrolls to the bottom of. So every new project invents its own way of calling the ERP, and the catalogue grows by one row of history rather than one row of reuse.
Treat the catalogue as a product with an owner and very few entries. Five patterns that cover ninety per cent of cases beat forty that cover everything. Each entry needs a name people will say out loud, a worked example in the repository, and a plain statement of when not to use it. That last part is the one that saves projects.
300 m
The delivery team
Put the patterns where the work starts
Engineers do not go looking for patterns. They go looking for the ticket, the repository and the nearest working example. So put the catalogue there. Link the relevant pattern from the story template, keep reference implementations in the same repository as the code that uses them, and make the integration checklist ask which catalogue entry the change follows.
Reuse happens at the moment someone starts, or not at all.
When the answer is none, that is fine, as long as it is written down. A new pattern that nobody catalogued is a future incident with no runbook. A new pattern that went through a ten minute conversation with the integration lead is a candidate for entry number six, and the catalogue gets a little more useful instead of a little more ignored.
