Before I draw a single box on a whiteboard I ask a set of questions. Not about technology. Not about frameworks. About the system.
I have been designing software platforms for 16 years: distributed systems, clinical platforms, regulated environments. The technology has changed significantly. The questions have not.
What does failure look like, and who finds out first?
Not the happy path. The failure path. Where does the system degrade? Who notices: the monitoring stack, a clinician, a patient? This tells me more about what the architecture needs than any requirements document.
If the answer is a patient finds out first, everything changes.
What changes most frequently?
Every system has a stable part and a part that moves. The architecture should isolate what moves from what does not. If you touch the same module every sprint it is doing too many jobs. If a vendor change breaks three internal systems you have the wrong boundaries.
What are the blast radius boundaries?
If this component fails, what else fails with it? I draw failure domains before I draw components. The boundaries between them are the most important decisions I will make. They are where security lives, where change control lives, and in a regulated system where the DHF traces to.
What does this system need to prove?
Every system has stakeholders who need evidence. Users need reliability. Operations need observability. Regulators need traceability. If producing that evidence requires significant extra effort, the architecture is working against the team.
How does this get better over time?
Not how does it scale. How does it improve. Can a team add capability without touching four other codebases? Can a vendor be swapped without a six month migration?
The systems I have seen fail do not fail because they were poorly built. They fail because they were built for day one, and nobody thought about day one thousand.
Seen this differently?
Questions, corrections and counterexamples are welcome.