Systems integration, so the software you already own works together

Usually not, and that is the point. Integration exists so you can keep systems that work and stop paying people to bridge them. If a system genuinely cannot be integrated we will say so, but that is rarer than vendors suggest.

There is nearly always a route — a database view, a file export, a scheduled report, or a supported middleware connector. Older systems are usually harder rather than impossible, and the mapping stage establishes which before anything is promised.

That is a business decision, not a technical one, and it is the question most integration projects skip. For each kind of data we establish which system is authoritative before building anything, because an integration built on an unresolved disagreement will keep producing conflicts forever.

Often not. Real-time synchronisation is more complex and more expensive to run, and a great deal of business data is perfectly well served by a scheduled sync. We would rather match the frequency to the actual decision being made.

It should raise an alert and, where possible, retry. The dangerous failure is the silent one, where data quietly stops moving and nobody notices until the numbers are wrong, so monitoring the integration is part of the work rather than an extra.

It depends on how many systems you are connecting. Two or three systems rarely justify the cost of a platform; once you are past five or six, point-to-point connections become their own maintenance problem and a shared layer starts to pay for itself.