Systems Analysis & Problem Framing

Systems analysis begins before optimization. The initial input is usually a problem situation—missed outcomes, conflicting needs, unexplained behavior or an opportunity—not a clean objective function. The work is to construct a defensible decision model without pretending that the first framing was neutral.

flowchart TD
  S["Situation and observations"] --> F["Frame question and boundary"]
  F --> M["Build competing models"]
  M --> E["Collect discriminating evidence"]
  E --> D["Evaluate decisions and risks"]
  D --> V["Validate outcomes"]
  V -->|"reframe when assumptions fail"| F

This loop is the method. A linear checklist hides the fact that evidence can invalidate the objective, boundary or stakeholder model.

From concern to answerable question #

“The service is unreliable” is not yet an analysis question. Ask:

• Which stakeholders experience which undesirable outcomes?
• What event, population, lifecycle stage and time horizon are in scope?
• Which observations distinguish failure classes?
• What decisions are available, and who has authority to take them?
• What would count as improvement, and what must not be sacrificed?
• Which external conditions could reverse the result?

The result might be: “For interactive EU traffic during peak load, which changes reduce the weekly probability of a user-visible request exceeding 2 s, without increasing duplicate financial actions or violating the error budget?” That question defines observable outcomes and constraints while leaving implementation alternatives open.

Separate symptoms, mechanisms and interventions #

A symptom is an observation. A mechanism is a causal account that predicts observations under perturbation. An intervention changes a mechanism or its exposure. Jumping directly from symptom to intervention creates cargo-cult fixes.

For example, high latency can arise from capacity saturation, lock contention, retries, dependency delay, queue scheduling, packet loss or measurement error. Each predicts a different joint pattern across utilization, queue depth, service time, retry rate and dependency spans. Collect evidence chosen to discriminate among those patterns, not simply more of the easiest metric.

Maintain several live hypotheses until evidence separates them. A systems diagram is useful when it exposes competing causal paths; it is harmful when arrows are treated as established causality merely because they were drawn.

Stakeholders and objectives #

Stakeholders include users, operators, owners, maintainers, suppliers, regulators, affected communities and future lifecycle participants. They contribute needs, constraints, knowledge and risk exposure. They do not automatically get equal decision authority, and their stated request is not always the underlying need.

Translate needs into:

• measures of effectiveness: external outcomes the solution must achieve;
• performance measures: internal capabilities that support those outcomes;
• constraints: conditions alternatives must satisfy;
• acceptance evidence: observations that demonstrate the claim;
• risk tolerances: which uncertainty and downside remain acceptable.

Do not collapse all five into one score too early. A high weighted score cannot compensate for violating a safety constraint unless the decision authority explicitly chose that trade-off under a valid governance process.

Model portfolio, not one master picture #

Use the cheapest models capable of changing the decision:

Every model needs a purpose, validity domain, assumptions, data provenance and comparison against observations. Precision beyond available evidence is decoration.

Stop conditions #

Analysis is sufficient when the remaining uncertainty cannot plausibly change the decision, the critical claims have acceptance evidence, major stakeholders and lifecycle effects have been considered, and the residual risks have named owners. “The model is complete” is not a realistic stop rule.

The final product is not just a recommendation. It is a reproducible chain from situation to boundary, hypotheses, evidence, alternatives, trade-offs, decision and validation plan. That chain lets a later reader tell whether changed conditions require a new answer.