Engineering guides / Architectural consequences
This Works Here. What Changes Elsewhere?
Use this when a component works well in a test and you need to assess its consequences for the rest of the system.
You’ll be able to identify the dependencies and assumptions that determine whether a local improvement supports a wider change.
The distinction
A component can work well while changing what the rest of the system must do.
The test tells us how the component behaved. What depends on that behavior determines how far we can carry the result.
Observed benefit → Dependencies and assumptions → Recommendation
01 / A promising change
“Did the change save, or should I try again?”
A support agent edits a customer’s account. On busy days, the screen waits, then reports that the request took too long. The agent opens the account again to find out whether the change was saved.
The engineering team tries a different approach: the screen immediately says “Update received” and shows the change as pending while it saves in the background.
In a test with many updates arriving together, every update is eventually saved correctly. The screen responds promptly instead of leaving the agent wondering whether the request went through.
“Should we use this approach for account updates?”
Before answering, someone asks: “What are we updating—and what needs that update next?”
02 / Same result, different consequences
What needs the new value next?
Keep the proposed change and the test result the same. Consider three contexts: two where the use is known, and one where it is only partly understood.
1. An internal nickname
The update changes the nickname staff use to recognize an account. Here, the nickname is only a display label: invoices, deliveries, and account matching use other fields. Staff can see when a change is pending.
Nothing needs the new label immediately
- Nickname received
- Saved later
- New label appears
Background processing could remove a frustrating wait without holding up another task. That makes it promising here, provided the delay is acceptable to staff.
This depends on: Staff can tolerate seeing the old nickname while the change is pending. The test established eventual saving, not how long staff would be willing to wait. If a save fails, staff need to know whether they can simply repeat the edit or must investigate what happened.
A possible recommendation
Use background processing for nicknames if the delay is acceptable to staff and failed saves are easy to recognize and recover from.
2. A billing address used for the next invoice
The update changes a billing address. The invoicing system submits that change, waits for confirmation, then creates the invoice using the saved address.
Current approach
- Address saved
- Confirmation
- Invoice uses the new address
New approach, if invoicing treats “received” as “saved”
- Update received
- Invoice created
- Invoice could use the old address
When the invoice is created, the address might still be waiting to save. A prompt acknowledgment no longer tells invoicing what it needs to know. The test did not produce a wrong invoice; this is a possible consequence of leaving invoicing unchanged.
This depends on: Background processing could still work if invoicing waits until the address is saved. Someone must take responsibility for that change.
A possible recommendation
Keep confirmation of a completed save for this workflow unless we also change invoicing to wait. Changing the account service alone is insufficient.
3. A contact address with partly understood uses
The update changes a contact address. One system reads it overnight; that use could tolerate a delay if the change is saved before the overnight read. Several older integrations also read it, but the team has not established when they do so or what they do with it.
What is unknown: Do the other systems read the address before or after the queued change is saved?
There is no demonstrated failure. There is also no basis for assuming that every use tolerates a delay.
- If a stale address only causes something easy to correct, the benefit of a prompt response may justify accepting that risk.
- If a stale address triggers an action that is difficult to undo, preserving confirmation of a completed save may matter more than the prompt response.
This depends on: How often corrections would be needed, and how much work they would create, remain unknown.
A possible recommendation
I would favor background processing if using an old address causes only occasional, inexpensive corrections. If it could trigger an action we cannot readily undo, I would preserve confirmation of a completed save until we understand that dependency.
The next question: Which integration uses the address next, and what happens if it gets the old one?
03 / Take the idea with you
What becomes someone else’s job?
The component passed the same test in all three contexts. What changed was the meaning of its response to the rest of the system. The field’s name is a clue; how people and systems use it determines the consequence.
A local improvement can move work elsewhere: waiting for completion, recognizing failure, correcting an action, or investigating an uncertain outcome. Whether that is worthwhile depends on who takes on that work and what happens if they get it wrong.
“This works better here. What must be true elsewhere for it to be a better change?”
About this example: the story and test results are fictional, written to explore the reasoning behind an architectural choice.