System Architects in Medical-device Development

The system architect’s role

The architect shapes the structures and principles through which the system must satisfy its requirements over time. The role focuses on decisions that are expensive to reverse, affect several disciplines or determine how safety, security, performance and maintainability can be demonstrated.

Start with concerns, then choose viewpoints

Identify who needs to reason about the architecture and what decisions they must make. A functional view may support requirement allocation; a deployment view may expose trust boundaries; a state view may explain safe recovery; a data view may reveal privacy and integrity risks. Every model should have a stated purpose, scope and audience.

Use MTL-210 — Systems Engineers in Medical-device Development to connect architecture with the wider systems process.

Establish a small set of enforceable principles

• Separate safety-critical control from convenience functions where this improves assurance.
• Minimise trusted components and privileged pathways.
• Make states, ownership and failure behaviour explicit.
• Use stable, versioned contracts across organisational and technical boundaries.
• Design for observability, diagnosis, test and controlled recovery.
• Contain faults and prevent a single dependency from defeating necessary controls.
• Keep released configurations reproducible and supportable.

Principles are valuable only when they influence design reviews and exceptions require explicit rationale.

Define boundaries and responsibilities precisely

Show the device, accessories, users, networks, cloud services, mobile applications, manufacturing systems, service tools and external information systems. Within the product, define hardware, firmware, application, data and third-party responsibilities. At every boundary specify what crosses, who owns it, how it is trusted and what happens when it fails.

Describe system behaviour across time

Static decomposition without behavioural views is insufficient for devices whose safety depends on sequence, timing or recovery.

Make the safety concept visible in the architecture

Show which elements implement, support or monitor risk controls; their common dependencies; diagnostic intervals; independence; safe states; user actions; and recovery authority. Consider systematic and random faults, combinations, latent failures and risk created by the control itself.

Connect architecture to MTL-104 — Essential Performance and Safety Concepts and MTL-114 — Medical-device Risk Management.

Integrate cybersecurity into system structure

• Identify assets, threat surfaces, trust boundaries and privileged components.
• Define identity, authentication, authorisation and key-management responsibilities.
• Protect data in transit, at rest and during processing according to risk.
• Separate networks, services and privileges to limit propagation.
• Design secure boot, update, rollback and recovery paths.
• Provide security logging, monitoring and vulnerability-management hooks.
• Assess the safety consequences of compromised availability or integrity.

Use MTL-109 — Medical-device Cybersecurity throughout the product lifecycle.

Architect for external and third-party dependencies

Identify operating systems, libraries, processors, cloud services, networks, identity providers, external APIs and supplier subsystems. Define required properties, support periods, failure behaviour, substitution strategy and version compatibility. Avoid architectures that cannot be maintained because a critical dependency can change or disappear without a controlled response.

Record consequential decisions and trade-offs

An architecture decision record should state the concern, context, options considered, decision, rationale, assumptions, consequences and evidence needed. Record decisions while alternatives and reasoning are still visible. This supports review, onboarding, change assessment and defence of why the chosen structure is appropriate.

Plan evidence for architectural claims

Use focused reviews, analyses, prototypes, simulations and tests to challenge performance budgets, fault containment, timing, capacity, interface behaviour, independence, security controls and recovery. Verify emergent properties at the level where they exist. Architecture is not proven by document approval; its claims must be connected to objective evidence.

Preserve architecture through variants and change

Define variation points, compatible combinations and prohibited dependencies. Assess every change against architectural principles, interfaces, safety, cybersecurity, performance, verification and fielded configurations. Use MTL-129 — Configuration and Change Management to prevent gradual architectural erosion.

Lead architecture as a collaborative discipline

Architects need authority to coordinate decisions, but should not become the sole source of truth. Build shared understanding with systems, electronics, mechanical, software, quality, risk, cybersecurity, manufacturing and service teams. Use reviewable models and clear decisions, and invite challenge from those who will implement, verify and maintain the system.

Common misconceptions