1.3 Strategies

Overview:
Different approaches structure how a solution is designed and built. Choose an approach based on complexity, team size, reuse needs, and available components.

  • Top-down:
    Start with the whole problem, break it into major parts, then into smaller tasks until each can be implemented. Used when the overall goal is clear and you need a coherent end-to-end design.
  • Bottom-up:
    Start by creating or selecting small, reusable components, then combine them into larger subsystems and finally the whole solution. Used when you have libraries/services to build upon or when rapid prototyping of parts is possible.
  • Modularisation:
    Organise the solution into independent, well-defined modules with clear interfaces. Used to enable parallel work, easier maintenance, testing, and reuse.
  • Top-down – Benefits:
    Clear roadmap, aligns teams to a shared goal, helps manage complexity.
    Drawbacks:
    Early design mistakes can cascade; may overlook low-level constraints until late.
  • Bottom-up – Benefits:
    Encourages reuse, quick wins from working components, realistic constraints discovered early.
    Drawbacks:
    Risk of misalignment with the big picture; integration can be hard.
  • Modularisation – Benefits:
    Easier testing, maintenance, and parallel development; clear ownership.
    Drawbacks:
    Requires good interface design and governance; too many modules can add overhead.

Definition:
RCA is a structured method to identify the underlying cause(s) of an issue so you can prevent recurrence, not just fix symptoms.

When used:
After incidents, recurring issues, safety/security events, quality problems, or failed changes where long-term prevention is required.

  • Five Whys:
    Ask “why?” repeatedly (typically five times) to move from symptom to underlying cause.
  • Failure Mode and Effects Analysis (FMEA):
    Systematically list potential failure modes, their effects, causes, and controls; prioritise using severity, occurrence, and detection.
  • Event Tree Analysis (ETA):
    Start from an initiating event and map forward through branches of system responses to evaluate possible outcomes and their likelihood.

Actions after RCA:
Implement corrective and preventive actions, log outcomes, document residual risks, communicate changes, and escalate to the appropriate manager where policy, budget, or cross-team changes are required. Close the record when actions are verified.

  1. Define the problem:
    Clarify scope, impact, constraints, and success criteria.
  2. Gather information:
    Collect logs, data, user reports, environment details, and recent changes.
  3. Analyse the information:
    Form hypotheses, compare expected vs actual behaviour, identify likely causes.
  4. Make a plan of action:
    Prioritise safe, reversible steps aligned with risk and impact.
  5. Implement a solution:
    Execute the plan, communicate status, and track results.
  6. Review the solution:
    Verify outcomes, document lessons learned, and prevent recurrence.

Digital Support Services Only

Digital Incident
is a single unplanned event that disrupts service operations and negatively impacts service quality (e.g., outage, degraded performance, security alert).

Digital Problem
is the underlying cause of one or more incidents (e.g., a software defect, misconfiguration, or capacity shortfall) that must be identified and resolved to prevent recurrence.

  • Detection:
    Report, record, categorise, and prioritise the incident; assess impact and urgency.
  • Response:
    Assign an owner, diagnose, resolve and restore service, apply workarounds as needed, and record the resolution.
  • Intelligence:
    Capture lessons learned, identify root cause or link to a problem record, and share insights with stakeholders.

Problems, incidents, and strategies are linked: recurring incidents point to deeper problems that require structured strategies (e.g., RCA, modular fixes) rather than ad-hoc patches. Selecting an approach depends on impact, risk, time, available components, and required long-term reliability.

Judgement factors:
severity and frequency of incidents, clarity of the end goal, availability of reusable modules, constraints (security, compliance), and the need for quick restoration vs permanent fix.