Use this worksheet before agreeing a delivery date. Complete it with the people who own the systems and the business process. Record an owner and a resolution date for every important unknown.
The business workflow
- What event starts the workflow, and what business result completes it?
- Which customer, team, or operating process depends on the connection?
- What is the smallest useful first release?
- Which activities remain manual, and who is responsible for them?
Example: An external system supplies project identifiers, while the SaaS application controls local operating status. This is an illustrative scenario, not a description of a client implementation.
Systems and ownership
For each important record or field, capture:
- The authoritative system and the team responsible for it.
- The identifier used in each system and the rule that matches them.
- Who may create, correct, deactivate, or delete the record.
- Whether local settings can override imported defaults.
- What happens to historical activity when a source value changes.
Avoid one broad “source of truth” label when different systems own different fields or decisions.
Access and data use
- How does each system authenticate, and what access does the connection need?
- Who provisions, rotates, and revokes credentials?
- How are customers or organizations kept separate?
- Which data may be transferred, logged, retained, or replayed?
- What happens when a user, customer, or integration relationship ends?
Record responsibilities and requirements here. Store actual credentials through the approved operational mechanism.
Timing, reliability, and recovery
Write down the expected behavior for each scenario:
- A message arrives twice or arrives late.
- A request times out after the receiving system may have accepted it.
- A record contains invalid or incomplete business data.
- One system is unavailable for an extended period.
- A source identifier changes or records are merged.
- Historical data needs to be imported or replayed.
For each, name the detection method, automatic behavior, person responsible, and safe recovery path. Define how the teams will reconcile disagreement between systems.
Delivery dependencies
- Who provides documentation, test access, sample data, and customer-specific mappings?
- Which provider constraints, rate limits, or vendor changes must be confirmed?
- Who signs off on the business behavior and technical acceptance scenarios?
- Who operates the integration after launch, and what information can support staff inspect?
- Which assumptions could change the estimate or delivery sequence?
The architecture handoff
A useful handoff includes a system diagram, mapping and ownership table, authentication and permission model, failure-and-recovery matrix, acceptance scenarios, unresolved decisions, and a staged delivery plan.
Integration Architecture is a way to work through these questions before they become assumptions embedded in code.