- A General System
- Detail Complexity Versus Systems Complexity
- Throughput Accounting for General Systems
- A System of Software Development
- A More Complex Software Development System
- The System Goal
- Financial Metrics for General Business Systems
- Financial Metrics for Software Development Systems
- Predicting the Future
- Framing the Problem
- Understanding Software Production in the Value Chain
- Throughput Accounting Versus Cost Accounting
- Summary
Detail Complexity Versus Systems Complexity
It is not unusual to meet people who are good at coping with complexity. However, probably only a few of them are systems thinkers. Much of the complexity in life is detail complexity [O'Connor 1997, p. 15]. Detail complexity describes something that has many parts, for example, a project plan with 1,500 tasks has detail complexity. Software analysis has detail complexity. UML class diagrams or database entity-relationship diagrams have detail complexity.
On the other hand, a system with many nested feedback loops, where small variations in the operation of the system can leverage enormous differences in the outcome, is said to have "inherent complexity." Understanding inherent complexity is difficult. It does not come naturally. Understanding inherent complexity means deducing the rules of the system operation, understanding the emergent properties and how varying the rules will leverage effect on the output of the system. If the inherent complexity is properly understood, it should be possible to expend the minimum amount of energy to leverage the maximum amount of improvement in the adaptive behavior (or outcome) of the system. A failure to understand the inherent complexity can result in changes that lead to undesired adaptive behavior or to expending excessive amounts of energy in the system in order to achieve the desired outcome. Expending excessive amounts of energy happens when the leverage point is chosen incorrectly because of a failure to fully comprehend the system.