A resilience analysis technique that identifies disruptive events, their architectural effects, detection signals, and mitigations.
Stressor analysis examines how disruptive events arising from an uncertain organizational and market environment can affect a software system. It supports resilient design by making hidden stressors visible and guiding shared mitigation decisions. section 12.1.2section 12.7
Use the technique to distinguish three connected ideas:
A hyperliminal system is an ordered, predictable, mappable, and testable software system operating inside a disordered organization. section 12.1.2
A stressor is an event arising in an unknown future that the system was not designed to handle. section 12.1.2
An attractor is a limited state, or group of states, to which the network repeatedly returns after different stressors. section 12.1.2
Treat apparently irrelevant stressors as potentially significant, because different disruptions may produce the same attractor and affect the system. section 12.1.2
Apply the findings collaboratively to shape mitigation strategies and resilient software architectures rather than relying on isolated architectural assumptions. section 12.7
How Collaborative Software Design: How to facilitate domain modeling decisions covers it
How deep it goes
Defines stressors, hyperliminality, and attractors, but does not provide a complete step-by-step analysis procedure.
Examples
Illustrates stressors through unknown future events and attractors through recurring states in a system’s network.
What it assumes
Assumes collaborative software design in an unpredictable organization while introducing residuality theory concepts from their definitions.
What you can do after
Diagnose hidden stressors and guide mitigation strategies for more resilient software architectures.
This explainer was generated by Manning's knowledge graph from the text of Collaborative Software Design: How to facilitate domain modeling decisions. The section links point to the parts of the book it draws on.
