Skip to main content

Process Risks in Software Architecture

The architecture of a system is the result of a set of technical decisions that determine its structure, security properties, capacity to evolve and operational impact.

Regardless of the architectural style, technology or domain, the architectural decision process is subject to risks of its own which, if not explicitly addressed, compromise the security of the delivered system.

1. Architecture as drawing vs architecture as decision​

A recurring risk is treating architecture as a technical drawing exercise (diagrams, boxes and arrows), instead of an explicit decision process.

Typical consequences:

  • absence of owners for the decisions;
  • impossibility of justifying the accepted trade-offs;
  • difficulty in reassessing decisions when the context changes.

In SbD-ToE, architecture is decision, and must be treated as such.

Relates to. Violates ARC-004; materialises MT-065.

2. Architectural decisions without an explicit owner​

Architectural decisions without a clear owner introduce:

  • ambiguity of responsibility;
  • difficulty of auditing;
  • risk of architectural drift over time.

Every relevant architectural decision must have an identified owner and an approval date/context.

Relates to. Violates ARC-004; no linkable threat in the current catalogue.

3. External dependencies treated as neutral infrastructure​

External services, managed platforms, third-party APIs or components outside the organisation's direct control are architectural decisions, not mere implementation details.

Associated risks:

  • dependency on third parties as a single point of failure;
  • exposure of data and metadata;
  • limitations on control, audit and exit (exit strategy).

Accepting an external dependency must be treated as an explicit architectural decision.

Relates to. Violates ARC-004; no linkable threat in the current catalogue.

4. Implicit data flows not modelled​

Beyond the explicit functional flows, modern architectures generate implicit flows, such as:

  • logs;
  • metrics;
  • telemetry;
  • observability events and signals.

Ignoring these flows leads to:

  • inadvertent exposure of sensitive data;
  • non-compliance with retention and minimisation requirements;
  • gaps in the threat analysis.

These flows are part of the architecture and must be treated as such.

Relates to. Violates ARC-008; no linkable threat in the current catalogue.

5. Opaque or non-deterministic components​

Components whose behaviour:

  • is not fully predictable,
  • depends on external state,
  • or is not fully observable,

introduce additional architectural risk.

The architecture must provide for:

  • containment of impact;
  • validation of critical outputs;
  • safe degradation mechanisms;
  • sufficient observability to detect deviations.

Relates to. No linkable requirement in the current catalogue; materialises MT-062.

6. Uncritical reuse of previous architectures​

Reusing existing architectures is common practice, but it becomes risky when:

  • the context has changed;
  • the risk profile is different;
  • new dependencies or flows have been introduced.

Inherited architectures must be treated as initial hypotheses, not as validated truths.

Relates to. Violates ARC-007; materialises MT-064.

7. Divergence between documented architecture and real architecture​

When the documented architecture does not reflect the system actually implemented:

  • decisions become invalid;
  • threats are no longer covered;
  • the evidence loses its value.

This risk requires periodic review mechanisms and explicit architectural gates.

Relates to. Violates ARC-013; materialises MT-069.

8. Implications for SbD-ToE​

SbD-ToE assumes that:

  • architectural decisions are fallible;
  • architectural process risks must be explicitly addressed;
  • mitigation requires human decision, validation and verifiable evidence.

The decision and evidence criteria are defined in this chapter's architectural decision file.