Systems Thinking in Architecture
Reasoning about a system as a set of interacting feedback loops rather than as a collection of components, so that second-order effects are anticipated.
Component thinking asks whether each part is correct. Systems thinking asks what the parts do to each other, and it is where most production surprises originate — every component behaving as designed, and the whole behaving badly.
The loops worth recognising because they recur. Retry amplification: a slow dependency causes retries, which increase load, which increase slowness. Autoscaling oscillation: scaling out on a metric that scaling out changes, producing a system that thrashes. Cache dependency: performance acceptable only while the cache is warm, so any flush becomes an outage. Alert fatigue: noisy alerts cause muting, which causes missed incidents, which causes more alerts to be added. Reliability erosion: a system that has not failed recently attracts less investment, until it fails.
The mental habits that catch these: ask what happens next after each response, not only whether the response is correct; look for where a corrective action feeds back into its own cause; and be alert to delays in a loop, since a feedback signal that arrives late produces oscillation regardless of how sensible each individual response was.
The organisational version is equally real and less comfortable: a governance gate added to improve quality increases batch size, which reduces quality. Incentives, structures and processes are part of the system, and an architect who reasons only about the technical half will be repeatedly surprised by the other one.