# SI-T03: Compatibility and change

Adrian Sutherland · Version 1.0 · Refreshed September 2026

© 2005–2026 Adrian Sutherland.
Source page: https://architectureportal.org/assets/systems-integration

Fictional cancellation service. Proposed design; checks are unrun.

## Process areas

A Simple Architectural Framework (ASAF) describes four continuing areas of work.

Proposed mapping for this fictional change. A review can cover several areas;
accepted decisions remain in place unless a finding reopens them.

| ASAF process area | Work in this example | Information to retain |
|---|---|---|
| Visioning | Agree the service responsibilities and qualities the solution should provide. | System context, core meanings, alternatives and responsibilities. |
| Transforming | Design and implement contracts, rules and components; check compatible transition. | Contract and implementation versions, checks, migration and recovery plans. |
| Operating | Resolve failed exchanges, maintain service behaviour and investigate recurring faults. | Operation history, incidents, version context and proposed corrections. |
| Governing | Agree authority, shared contracts, acceptance conditions and exceptions. | Decision rights, accepted contracts, reasons and unresolved conditions. |

## Change and reason

SI-D1 (Case-service option) proposes moving the accepted-transfer register into a case service for a later increment. The purpose is to make acceptance and recovery explicit across clients. R1 (Continuous ownership) ownership and learner agreement rules continue. Expected benefits remain hypotheses.

## Affected participants

Staff clients, case-service maintainer, case owners and duty coordinator; later notification and reporting consumers. Booking service retains its authority. Optional AI access must be separately agreed. The earlier process-only trial is not assumed complete.

## Old and new behaviour

Old arrangement: shared register with accepted-transfer procedure OP-D1 (Accepted-transfer procedure). Proposed arrangement: case service owns the register and accepts SI-C01 (Transfer acceptance contract) atomically with operation history. A queued client action remains pending; the accepted case version records that the transfer has taken effect. Receiving a notification is not acceptance by the receiving person.

## Transition and compatibility

Inventory cases, assignment history, offers and agreements; reconcile them before cutover. Agree when the case service becomes authoritative and prevent independent assignment writes to an old register. Test each supported client and downstream consumer. Set the supported contract versions and retirement date before release. Avoid an interval with two writable authorities.

## Checks and acceptance

SI-V1 (Interface checks) is unrun. Add migration totals, one-current-owner checks, preserved agreement references and old/new client behaviour to the acceptance plan. The service owner accepts operational readiness with case-service support and the people taking cases. No release approved.

## Recovery after release

If cutover fails before any new accepted change, restore the agreed prior arrangement after reconciliation. If new assignments have taken effect, preserve their history and reconcile before selecting the authoritative service. Reverting code cannot erase accepted transfers or confirmed bookings. A correction needs the appropriate case and service authority.

## Durability review

A new mobile client must preserve pending versus accepted actions. A different implementation language must preserve identifiers, version checks and error meaning. A new hosting or messaging supplier must preserve the operation result and recovery obligations. A booking supplier with different confirmation behaviour may reopen the business process.

## Open decisions and measures

Open: delivery topology, storage atomicity, transport, data access/retention, retry and support timing, migration approach and named owners. No dates agreed. Observe integration lead time, support effort, unresolved outcomes and effort to replace a consumer. Long-term usefulness needs actual change history.