On every enterprise software project, there is a category of work that everyone hopes will be easy: the integrations. Connecting to the ERP. Pulling data from the data warehouse. Federating identity with the SSO. The PO system that's “basically REST.”
These integrations are where projects die. Not the business logic. Not the UI. Not even the database design. Integration debt — discovered late — is the single biggest reason enterprise software projects miss their deadline.
Why integration is consistently underestimated
Three reasons:
- The complexity is hidden in someone else's system. You can't estimate complexity you can't see. Integration scope only reveals itself when you start writing code against the other system.
- The owners of the other system are not on your project. ERP team, identity team, data warehouse team, vendor. Each one has their own roadmap. Each delay compounds.
- Failure modes are political, not technical. The technical work is often straightforward. What kills you is access requests, security reviews, and approvals that take 6 weeks each.
The integration-first pattern
We start every engagement with a 1–2 week integration audit before we touch the rest of the architecture. Three artifacts come out of it:
1. The integration map
Every external system, every direction of data flow, every protocol, every owner, every access path. We diagram it. We list the contact name, the SLA, and the access process for each one.
2. The hard-parts inventory
For each integration, we identify the riskiest part — usually a combination of authentication, data model mismatch, and rate-limit constraints — and put it in week 1 of the build, not week 18. The first feature we ship is always something that proves the hard integration works in production.
3. The dependency unblock plan
For every dependency outside your team's direct control, we publish a written request — what we need, when we need it, and what we'll do if we don't get it. This gets sent to your CIO or the integration owner's leadership before code is written. The 6-week security review starts on day 5 of the engagement, not day 60.
The team that ships first is the team that asked for access first.
What this looks like in delivery
Concretely: on a 9-month MES build we did last year, the first deliverable in week 4 was an end-to-end transaction from a single PLC into the new system, into the new data warehouse, into the OEE dashboard. It wasn't the prettiest feature. It wasn't the most valuable. It was the proof that every integration in the architecture worked.
Once that's shipped, every subsequent feature is just business logic. Project velocity becomes predictable. The deadline holds.
What goes wrong when this is skipped
On the same MES platform — three years earlier, before we engaged — the previous vendor had deferred integration to month 5. By month 7 they discovered that the legacy MES exposed OEE data only through a flat-file batch process that ran nightly. Their entire real-time dashboard architecture was unworkable. They rebuilt it. The project landed 11 months late.
How to apply this if you're building internally
- Before any business-logic work starts, list every external system you'll touch.
- For each, document protocol, owner, access timeline, and the riskiest part of the integration.
- Make week 1 of your build a thin end-to-end slice that exercises every integration with real data.
- Send access requests on day 1, not day 30.
This is one of the practices we lift directly into every engagement we run. If you'd like to see the integration audit template we use, get in touch — we'll share it.