Architecture Justification

This section provides a way for you to explicitly state how the non-functional requirements you stated in the non-functional view are satisfied by your architecture. This is an important yet often forgotten piece of the architecture puzzle, and clearly communicating your architecture’s fitness for purpose will help provide everybody with the confidence that your solution will work. If you built an executable reference architecture to prove some of the key non-functional requirements, this is where you can reference that work and the proof of its success.

• For each of the non-functional requirements, is it explicit how the architecture satisfies it?
• In the case of performance and scalability targets, are the test cases and results referenced?
• If true 24x7 availability is required, is redundancy and automatic failover built into all aspects of the architecture?
• Are there any single points of failure?
• What happens if a component fails?
• What happens if an external system you rely on fails?
• Does this affect your availability? Are your transactions ACID?
• Would you have 2PC transactions in-doubt?
• Can you recover from a system failure?
• Who is responsible for system recovery and failover?
• Can you recover in a business continuity scenario?
• Will all data have been replicated between sites?
• How do you tell system components to use alternative resources in the event of DR/BCP?
• Has the architecture been reviewed by in-house security risk teams (if applicable)?

The key question you're trying to answer here is whether your architecture "works".