08What mission-critical demands

Some products cannot be allowed to fail. Software that controls a medical device, supports a clinical decision, settles payments or runs critical infrastructure must do more than work. Its builders must be able to show that it works, explain why, and keep that true for years. That changes what the development process has to produce.

Provable

In regulated and critical domains, confidence is not enough. Someone outside the team, a notified body, a regulator, an auditor or a client's risk function, will ask for evidence. For medical device software, IEC 62304 asks for documented requirements, an architecture that identifies software items and their interfaces, verification at each level and traceability between them, with rigour scaled to the software's safety class. ISO 14971 asks for hazards to be identified, risks estimated and controls verified. In financial services, the European Digital Operational Resilience Act (DORA) asks firms to identify, protect and test their critical ICT functions.

The common thread is demonstration. It must be possible to show which requirement a piece of code serves, which risk it controls, how it was verified and what a change would affect.

Sustainable

Critical systems also live long. A medical device platform or a core banking system is commonly maintained for ten or twenty years, by people who were not there when it was designed. Over that period the domain changes, the regulations change, the technology underneath changes, and the system must keep its guarantees through all of it.

Sustainability, in this sense, means that a change can be made with a known and limited impact, that the reasoning behind the design can still be understood, and that the evidence produced for the last release can be updated rather than rebuilt.

What Scrum brings, and what it leaves

Scrum helps more than its reputation in these industries suggests. Short loops expose defects early, the Definition of Done can include verification and documentation, and every sprint produces a version that could be assessed. AAMI TIR45 has shown for more than a decade how agile practices can satisfy medical device expectations.

But Scrum is silent on the structure that evidence requires. Traceability needs stable things to trace to. Risk control needs to know where a hazard can arise and where its control lives. Impact analysis needs boundaries that changes do not cross. None of these come from the framework. They come from the architecture, and in a domain-heavy system the architecture is only as clear as the model behind it.

Table 5 · What mission-critical products demand, and where Scrum alone stops.

The right-hand column describes, almost item by item, what DDD produces. The next three sections show how.