Architecture Review Guideline

Architecture Review Goals

• Evaluate the architecture early to avoid developing something that doesn't fit.
• Ensure consistency throughout the system. This will improve maintainability in the system and avoid duplication within the system.
• Validate that the architecture builds a better understanding of the System Requirements, as well as identify any missing important system requirements.
• Increase the overall knowledge of the product/system.
• It's important to formally document, and review, the architecture to comply with standards (ISO 9001, IEC 62443, IEC 61508, and others).
• Ensure all documented architecture is also reviewed. If the architecture is worth documenting, it's also worth reviewing it.

Architecture Review Checklist

When performing the architecture review, make sure to consider the following:

• Is this content updated according to all relevant input requirements? Consider both specific functional or non-functional requirements and generic requirements e.g. requirements on architectural principles for security or other areas.
• Is the described functionality following relevant input Architecture Specifications?
• Are all major software/hardware components identified and their relevant interfaces defined?
• Does the architecture specification have the right level of abstraction? The architecture specification shall provide an overview of and an introduction to the architecture using diagrams and textual descriptions on a high conceptual level.
• Is the functional decomposition well described? For each functional element, there shall be a description of the provided functionality/service, the internal decomposition/structure, and the internal and external conceptual interfaces.
• Is the dynamic behavior well described? Important concepts and functions shall have a description of their dynamic behavior on a high and conceptual level.
• Is the information model described? The most important data entities relevant to the architecture, including their relationship, shall be described by the information model.
• Is the deployment described? The deployment of functional elements into its execution environment shall be described.
• Are architecture decisions described? The most important architectural decisions, including their motivations, shall be described.
• Do all entities in the architecture have consistent names? All functional elements and conceptual interfaces shall have consistent naming. The same word shall have the same meaning throughout the description. Names shall be self-descriptive in terms of intent and behavior, and abbreviations shall be avoided.
• Are sufficiently precise (i.e. sufficient quantity to be useful) descriptions put on:
  • a) compatibility
  • b) standard compliance (for example IEC 611131-3, IEC 62443, or OPC UA)
  • c) availability
  • d) configuration
  • e) assumptions and dependencies
• Is all mitigation of risks described in the threat model covered?
• Is the architecture considering best practices?
• Is the architecture feasible for refinement to a functional design (Description of Function)? Is the architecture described clearly and in detail?
• Is the reuse of existing trusted and verified software modules/libraries considered?
• If applicable, is the architecture structured so that reuse is possible for other components or products?

Template

Traceability is important throughout the entire development process. To simplify traceability for architectural review, use the template available in the Tools & Templates translated into markdown format.