What "we will integrate it" actually costs
Integration is quoted as a task and behaves like a relationship. The build is the cheap part; the price is paid every time either system changes.
Two systems need to share data. Someone says they will integrate them, a number gets agreed, and the work gets done.
The number was probably about right for building it. What it rarely covers is that an integration is not a deliverable that finishes. It is a standing commitment to two systems you do not fully control, both of which will change without asking you.
What you are actually buying
The build is a fraction of the lifetime cost. The rest is:
Keeping up with both ends. A vendor deprecates an API version, changes an authentication method, adds a mandatory field, or alters a rate limit. Each is a small piece of work and each arrives on someone else’s schedule.
Handling the data that does not fit. Two systems rarely agree on what a customer is, whether a product code is unique, or how to represent a partial delivery. The mapping decisions are the actual intellectual work and they need revisiting whenever either business process changes.
Being the place blame lands. When a record is missing, neither vendor will volunteer that it was theirs. The integration is in the middle, so it gets accused first, and somebody has to be able to prove what was sent and received.
The distinction that decides everything
Integrate against a documented, supported interface and you have a maintainable arrangement. Changes are announced, versions are supported for a period, and errors come back as errors.
Integrate by working around the absence of one — writing directly into a database, scraping a screen, driving the UI, or parsing an emailed report — and you have built something that works today and will break without warning, in a way that is nobody’s responsibility to warn you about.
We will do the first. We will not do the second on a client’s production data, and if a vendor offers no supported interface we would rather say so plainly and discuss the alternatives than build something fragile and let it become somebody’s problem in eighteen months.
That is an unpopular position occasionally, because the workaround is cheaper this quarter. It is also the reason we are not being called at 6am about a screen-scraper that broke when a vendor changed a label.
Questions worth asking before you commit
- Is there a documented API on both sides, and what is its versioning policy?
- Which system is the source of truth for each field? Not “they sync”. If both can edit an address, decide now which wins, because the answer will be needed at 5pm on a bad day.
- What happens when it is down? Queue and retry, or fail and alert? Data written once or replayable?
- How will we know it stopped? See the point about silence being the alert that matters.
- Who owns it in a year? If the answer is nobody, the maintenance is unfunded, and unfunded maintenance is how integrations rot.
- Could a process change remove the need entirely? Sometimes two systems are being joined to support a handover that should not exist. That is the cheapest integration available.
Pricing it honestly
We would rather quote integration work as a build plus an ongoing responsibility, and say which parts are which, than present a single number that implies the job ends at go-live.
It makes the initial conversation slightly harder and the third year considerably easier, which is the same trade the rest of how we work is built on.