Replacing a device can preserve the architecture while still requiring an impact assessment. Change impact analysis establishes what stays the same, what changes and what evidence supports that conclusion.

Start with three questions

  1. App: do the code, libraries and peripherals work in the new environment?
  2. Identity and security: do sign-in, permissions and device management preserve expected rules?
  3. Communication: do API contracts, connections and the complete user journey still work?

Example

Practice-inspired educational scenario: a company replaces tablets while user tasks and the server stay the same. A small trial checks sign-in, work-order processing and result submission. Actual differences define the next steps. Assume neither zero impact nor a complete redesign.

How can C4 help?

A context diagram shows the system, users and external systems. A container diagram can show the device app, server and communication. Comparing before and after can reveal a new dependency or trust boundary. C4 describes architecture; it does not certify compatibility.

Record the decision

Capture scope, unchanged and changed elements, representative trial results, open questions and a way back. If boundaries, contracts or important quality properties change, extend the review accordingly. If they do not, support that conclusion with evidence.

Limits

One successful test does not prove every device model and configuration compatible. Choose a sample reflecting actual use. An architecture model does not replace running the app on the target device.

Practise: new tablets → · Source: C4 context diagrams