System Interdependencies Module
This section of the source is an unfinished draft
Four sentences in the source handbook stop mid-way, the Tools and models section is empty, and the Inputs section is a single placeholder line. The material below is everything the source actually contains. Nothing has been written to fill the gaps, and each one is marked where it occurs.
Purpose
The purpose of the module is to establish or identify the relationship between individual elements within a system, or across different systems.
What a system is
The handbook takes its definition from Meadows:
An interconnected set of elements that is coherently organized in a way that achieves something.
Two features of that definition do real work here:
| Feature | Consequence for transport |
|---|---|
| Elements can be physical elements or social constructs such as ideas or organisations | An organisational boundary is as real a system element as a bridge |
| Elements interact and can influence each other | Behaviour emerges from the connections, not just the parts |
Why reductionist analysis is not enough
The handbook makes a specific methodological claim: interactions between a system's elements can create complex and intertwined patterns which may not be understood through reductionist analysis.
In other words, examining each asset thoroughly and separately will not reveal them. That is the justification for having this module at all, and it is the same argument that runs through the DSP's critique of management by asset class.
The module maps these patterns between a particular asset and the other assets, networks, users, and the organisational and policy context it interacts with.
The five system groups
The module consists of five groups of systems:
| Group | |
|---|---|
| Climate change | The changing environmental conditions the system operates in |
| Assets | The physical infrastructure |
| Networks | How assets combine into connected systems |
| Users | The people and organisations that depend on them |
| Policy and organisational contexts | The institutions, rules and responsibilities around them |
These five were chosen to extend understanding of interdependencies beyond assessment of physical interdependencies, to include the social, environmental, policy and organisational linkages as well.
The source contradicts itself on the number of groups
The purpose section names five groups, as listed above. The methods section says to "use four system categories which are predefined: Asset, Network, User, Policy and Organisational", omitting Climate change.
This handbook presents five, because that is the list the source explains and justifies. The authors should confirm whether climate change is a system group in its own right or an external driver acting on the other four.
The system mapping approach
Figure 1. System mapping approach.
Where the module is used
The module is described as part of two DSP processes: Problem framing and Portfolio optimisation. That matches the master diagram, which shows System Interdependencies inside exactly those two stages.
The explanation is cut off
The source reads: "Systems interdependencies module is the part of two main modules of the DSP: Problem Framing and Portfolio Optimization. In the Problem Framing," and stops there.
The account of how the module is used within each of the two stages is missing.
Methods and principles
The source gives one complete instruction and one fragment:
- Use the predefined system categories: Asset, Network, User, Policy and Organisational
The second method is cut off
The source's second bullet reads "Identify" and stops. What is to be identified is not stated.
Tools and models
Empty in the source
This section is a heading with nothing beneath it. No tools or models are named for this module.
Inputs: data sources
The source says only that inputs "can be obtained from various sources". No sources are named.
Outputs
The named output is an interdependency map or canvas.
The explanation is cut off
The source reads: "Interdependency maps/canvas: The output varies depending on at what stage of DSP the interdependencies" and stops.
The intended point appears to be that the output differs between the problem framing and portfolio optimisation stages, but what that difference is was never written.
Dependencies on other modules and processes
The explanation is cut off
The source reads: "Systems interdependencies module is embedded in two modules as a process that helps identifying connections amongst" and stops. The only sub-heading that follows is Problem Framing and Context, with no text.
What can be stated from elsewhere in the handbook:
| Related module | The relationship |
|---|---|
| Asset Registry | This module depends on the registry most heavily of all, because asset relationships, dependencies and system boundaries are a key part of what the registry holds. Its outputs may enhance and update those recorded relationships. |
| Asset Performance | Uses performance information to understand how deterioration or failure in one asset affects connected assets, systems, users and networks. Critical dependencies it identifies may reshape monitoring and forecasting priorities. |
A definition included in the source
The source places the following definition in this section, without connecting it to the surrounding text. It is reproduced here because it is the handbook's only definition of systemic resilience.
Systemic resilience. A property of an infrastructure system that arises dynamically when the national infrastructure is organized in such a way that it can provide agreed critical services (power, heat, communication channels, mobility services, potable water, and wastewater and waste removal) despite endogenous and/or exogenous hazards, and despite the addition, modification and removal of infrastructure components.
IPCC Glossary, Life-Links
Why it may belong here
The definition describes resilience as a property that arises from how a system is organised, rather than from the strength of individual components. That is the same claim this module rests on, which is presumably why it was placed here.
Source reference
Meadows, D. H. (2008). Thinking in Systems: A Primer. Chelsea Green Publishing, page 11.