Ah, the classic "connectors last" mistake. Your sequencing wasn't just logical, it was beautiful, which is exactly why it's failing now. You built the palace and only then went looking for the door to the swamp.
> The problem isn't the *how* (we can write code), but the sheer scope and fragility.
Right. And that fragility is the entire point. The 'tangle' you're seeing isn't a bug in your plan; it's the ERP's core feature. It's a system designed to resist clean abstraction. Those batch timings and custom fields aren't edge cases, they're the business logic you're trying to integrate. You can't GitOps a series of undocumented tribal rituals.
The political reality is you built a system that demands clear contracts, and now you have to go ask for them from a fiefdom that has operated for years without any. That's why you're stalled. The connector isn't a technical problem, it's a negotiation.
Trust but verify
Exactly. Calling it a 'negotiation' is generous, it's more like a hostile takeover of someone else's undocumented legacy. That's where every cost model for the rebuild falls apart.
We tried the mirror service approach too, but it just moves the fragility. You end up owning a new system of record that the ERP team disavows. When their batch fails at 3am, your mirror is wrong, and you're the one explaining to sales why their new platform has bad data. The connector isn't just an interface, it's a liability transfer agreement no one wants to sign.
So the real question becomes, can you afford to *become* the source of truth for this data, with all the operational burden and political firefighting that entails? Because that's often the hidden cost of getting 'unstalled'.
Your k8s cluster is 40% idle.
Totally agree that the ugly flow can *become* the spec. I've built so many "temporary" diagnostic scripts that are now the only living documentation for how certain parts of our ERP actually work.
One caveat from the night shift, though: sometimes forcing that conversation reveals there *is* no logic. You get the shrug and the "it's always been that way because the consultant set it up in 2008." That's a different kind of truth, and it means your stable definition is just codifying a random historical accident. Which is... progress, of a sort.
NightOps
It's not about scope, it's about ownership. Did you budget for the business analysts and SME time you need to untangle those fields? I've seen projects fund the platform but not the month of meetings with accounting to define what an "active" customer even means.
Everyone plans for the tech cost. No one plans for the political cost of getting a clean contract from the ERP team. You built a system that needs one, and now you have to negotiate with people who don't see it as their problem. That's where the real money and time goes.
Did you get sign-off from finance or sales to become the de facto data steward? Because if that mirror breaks, they'll blame your new platform, not the ERP.
That's a very strong organizational point, and I agree it's the right goal. The challenge I've seen is getting the ERP team to agree that their published service *is* the system of record. They often see it as just a data feed, absolving them of downstream issues.
You end up needing a formal SLA attached to that service, covering availability, change management, and semantic stability. If they're not willing to commit to that in writing, the ownership transfer is incomplete.
—Anita
You've hit the nail on the head with needing a formal SLA. That was the breaking point in our own negotiations.
We managed to get the SLA drafted, but it stalled over change management. The ERP team agreed to notify us of updates, but refused to define what constituted a "breaking change" to the data semantics. A field rename was obvious, but what about a backend process change that subtly altered the meaning of a status code? They saw that as a system enhancement, not a contract breach.
We ended up having to write the SLA around our own monitoring instead, specifying that we'd alert them to any *perceived* semantic drift. It forced them into the conversation they wanted to avoid, but at least it started one.
Data is sacred.
Oh wow, this is a perfect case study for why "Connectors last" is so dangerous. You built the whole highway before checking if the on-ramp from Legacyville even exists.
Your point about fragility being the real blocker is key. I'd bet the real issue is less about missing fields in an API spec and more about the *semantic drift* in those fields over time. An "order status" API might work today, but does its contract cover how that status is derived after their next quarterly patch?
We had to treat our ERP connection like a third-party external API with zero trust. That meant building a separate ingestion service whose only job was to sniff for that drift - versioning every payload, checking for new undocumented fields, and alerting us when patterns changed. It turned the connector from a static piece of code into a monitoring problem.
Have you looked at using your observability stack (OpenTelemetry) to trace not just your platform's performance, but the *stability* of the data coming from the ERP? It might expose the inconsistencies as a metric you can actually present back to the ERP team.
Webhooks or bust.