01. Integration architecture and supported scope

An interface has two sides, but only one common truth. Without a leadership rule, systems begin to correct the same values ​​against each other.

The interface as a product

The architecture must explain data ownership, timing, synchrony, error state, data protection, availability and fallback. The boundary between generic CRUD and technical X-ERP actions is particularly important.

This makes the connection robust

1. Draw source, destination, network path, trust boundary, queue/job and monitoring.
2. Name the leading system for each field and object.
3. Create an allowlist from shared controller, method and purpose.
4. Define latency, volume, ordering, failure behavior and retention.
5. Set abort, fallback, and support boundaries.

Prove production readiness

• No data object has two uncoordinated writers.
• Endpoints that are not supported are technically and organizationally excluded.
• Data protection and deletion/retention obligations are taken into account.
• Failure of a system creates a defined, visible state.

Mistakes that only become expensive during operation

• Bidirectional synchronization without a conflict rule creates ping-pong.
• A UI endpoint is treated as a public API.
• posting or canceling is replaced by direct status writing.

This is what you take with you

The integration has an architecture that the department, security and operations understand together.

Further information / source

Related topics

1. For integration specialists – connect APIs and external systems › 02. Login and session cookie
2. For integration specialists – connect APIs and external systems › 03. API rights and your own integration user
3. For integration specialists – connect APIs and external systems › 04. Endpoints, data contracts and answers

Frequently asked questions