An architect must agree an integration contract with an external partner whose interests differ. What negotiating approach produces a durable technical agreement?

The approach

Negotiate interests, not positions. A partner's position may be "we will only provide a nightly batch file". Their interest is usually something else — protecting a fragile system, avoiding operational burden, controlling load, or simply having no capacity to build anything else.

Discovering the interest opens options the position forecloses. If the interest is load protection, a rate-limited incremental API may be acceptable where an unlimited one was not. If it is operational burden, you offering to run the integration changes the conversation.

What to agree explicitly

1. The reliability contract, not just the interface. Expected latency, availability, rate limits, and what happens when either side is unavailable. An interface specification without these is half a contract, and the half that causes incidents.

2. Failure semantics. What the partner returns when they cannot answer, whether retries are safe, and whether operations are idempotent. This determines whether your side can be built correctly at all.

3. Change and deprecation. How much notice for a breaking change, how versions coexist, and how each side is notified. Without this, an unannounced change is a production incident with no recourse.

4. Data handling. What each side may store, for how long, and what happens on termination. This is a privacy and contractual matter with architectural consequences.

5. Escalation and support. Who to contact, expected response times, and how incidents are coordinated across organisations.

The architectural protections regardless of the agreement

Design as though the partner will breach the agreement, because eventually one will:

• An adapter isolating their peculiarities, so partner changes touch one place.
• A per-partner reliability profile as configuration — timeout, retry budget, concurrency ceiling, circuit state — so a degraded partner is a tuning change rather than a code change.
• Treat them as optional wherever the product permits, with partial results as the normal case.
• Reconciliation, because data will drift regardless of what either side promised.

The durable-agreement principle

An agreement that requires the partner to behave well is a hope. The durable version specifies what happens when they do not — which is both better engineering and, usually, easier to agree, because the partner is not being asked to promise something they are unsure they can deliver.