The integration surface is the project

The model is the easy part now

This was not true three years ago and it changes how projects should be planned. The reasoning is largely solved for the tasks most enterprises want; what remains hard is everything around it.

On a typical engagement here, the model work is perhaps a fifth of the effort. The rest is getting data out of systems that were not designed to give it up, writing it back safely, and building the operational scaffolding that makes the whole thing runnable by people who did not build it.

A useful reframe for a steering committee: this is a systems integration project with a model in it, not an AI project with some integration. It sets expectations correctly and it puts the right people in the room.

What you find when you look

It lies about failure

HTTP 200 with a fault in the payload, or an empty result meaning error. Never trust the status alone.

No usable pagination

Or pagination that is unstable while data changes underneath it.

The clock is wrong

Local time with no offset, or a timezone nobody documented. We have seen a date format change from day-first to month-first without notice and mis-date a quarter of postings.

An undocumented rate limit

Enforced by getting slower rather than by refusing, so you discover it in production.

No test instance

Because it is shared with a production process nobody will pause. Assume this from the start.

Find out before you commit to a date

The single highest-value activity in the first week of an engagement is calling the endpoints. Not reading the documentation about them, calling them, with real credentials, against real data.

1. 1.Get credentials on day one. If that takes three weeks, you have learned the most important fact about the timeline and you have learned it early.
2. 2.Pull a hundred real records and read them. Every quirk you find now is a week you do not lose later.
3. 3.Try one write, into whatever sandbox exists, and if none exists, that is the finding.
4. 4.Capture every request and response, including the malformed ones. This becomes the fake you develop against when the system is down for month-end.
5. 5.Write down what you asked for and did not get. When the replacement project starts, that list is the requirements document.

Contain it rather than fight it

The old system will not be replaced during your project. The design goal is that nothing else in the architecture learns its shape.

One adapter knows what it looks like and exposes your types. Its XML, its magic status codes, its five-minute timeouts and its nulls stay inside. The test is whether you could delete the old system and reimplement the adapter against something else without touching anything upstream. When that leaks, and it leaks through dates, status codes and nulls, you find its quirks reproduced in business logic four modules away, and by then it is genuinely expensive.