Application Integration

Digital Connectivity

Interfaces designed, delivered and then kept running.

Integration projects go wrong on the things nobody wrote down: the nightly job somebody built five years ago, the field that means one thing in the ERP and something else in the warehouse system, the interface with no owner. We start every engagement by cataloguing what already runs — source, target, trigger, format, volume, and the name of the person who gets called when it stops.

Design comes next, and the honest answer is not always a hub. A direct point-to-point link between two systems that will never have a third consumer is cheaper to build and cheaper to keep. Where the same data has several consumers, or the endpoints change on different release cycles, the traffic goes through the enterprise service bus so that adding a consumer is configuration rather than another bespoke link. EDI, managed file transfer and APIs are the transports underneath; the design decision is about coupling, not protocol.

Most of the effort is mapping and master data. Field-by-field mappings are agreed with the people who own the data, not inferred from a sample file, and product, customer, supplier and location codes are reconciled between ERP, CRM and WMS before build starts — because a mapping that is correct and a code set that disagrees still produces a failed message. Connector work is delivered on the Quadrant EDI and integration stack.

Then it has to be run. Interfaces get the same treatment as the applications they connect: separate development, test and production environments, a regression pack of real messages, releases that are versioned and reversible, and a cutover that runs the new and old links in parallel before anything is switched off. In service, every interface is monitored, every failure alerted, and every exception has a documented reprocessing route with an owner attached.