Integrations rarely fail because of the programming language. They fail because of unclear ownership, missing error paths and assumptions about data quality that were never verified.
Typical starting situations
- Two systems need to exchange data while disagreeing on what a record actually is.
- An interface that grew over time works, but nobody can say what happens when it fails.
- A legacy system is being replaced while it stays in production.
- An export runs overnight, and nobody notices when it doesn't.
The technical work
- Designing, building and operating interfaces between existing systems
- Making data migrations repeatable and verifiable
- Defining error, retry and abort behaviour explicitly
- Documenting where responsibility between systems begins and ends
- Building applications that complement existing systems instead of duplicating them
How we approach it
The first question is not the data format but ownership: which system is the source of record for which information? Protocols and formats are decided only once that is settled.
Failure behaviour is agreed next — before the first line of code. An import that stops on malformed records is a deliberate decision. One that skips them silently is a future incident.
System context
Integrations almost always touch identity and permissions. Who is allowed to see which data, and how does the target system know? That question leads directly to identity & access management — and should not be asked last.