arc42 section 2: Architecture Constraints

Technical, organizational and regulatory constraints

• For each open data source, the document states its license, or that it is in the public domain. → Use of external and open data
• The building block view is a hierarchy of black boxes and white boxes, with level 1 as the white box of the whole system. → arc42 Architecture Documentation Template
• The document lists constraints in one place, with an explanation or background for each. → arc42 Constraints
• Constraints are grouped into technical, organizational/political and conventions where the list is long. → arc42 Constraints
• Organizational constraints such as budget, time or processes are recorded. → arc42 Constraints
• Data principles and architecture reference materials are identified as guidance for the Data Architecture. → Data Architecture Inputs
• Data administration responsibilities are clearly assigned. → Data Architecture Principle
• The document states which business vision or strategy the enterprise-level architecture supports. → Enterprise Architecture
• The chosen level of process integration and standardization is stated explicitly. → Foundation for Execution
• Each catalogued component shows a standardization status (standard, approval needed, or not permitted). → IT Component Catalogue
• Constraints that originate in enterprise-wide standards, such as mandated technologies, are listed as constraints. → Relationship between Enterprise Architecture and Application Architecture
• The deployment view shows the infrastructure elements relevant to the software. → Technology Architecture
• The document lists its constraints in one place, so architects can see where they are free and where they must comply. → Architectural Constraint
• The decision record lists the forces and concerns that drove each decision, for example in a Decision Drivers section. → Architectural Force
• The document states where the architects are free and where they are bound by constraints. → Architectural Force
• Constraints are listed, and the document notes which ones may be negotiable and which apply organization-wide. → Architecture Challenges at Project Start
• The document states that early decisions may be revisited and corrected. → Architecture Challenges at Project Start
• Each important decision is documented with its motivation and reasoning. → Architecture Decision Documentation and Requirements Management
• The context of a decision covers technical, political, social and project aspects. → Architecture Decision Documentation and Requirements Management
• Use cases are backed by functional requirements that itemize specific software behavior. → Requirement Types and Documents (Wiegers/Beatty)
• The document lists constraints and shows where the architect is free to decide. → Requirements and Means Influence Architecture
• The document notes which constraints come from the wider organization rather than from this system alone. → Software Architecture in Its Context
• The document names the BPMN modeling tool the team uses and whether it runs as a desktop app or a web app. → BPMN Modeling Tool
• The principles reflect what the organization values when it must compromise, not generic statements. → Architecture Principle
• Encryption at rest and in transit is chosen based on the confidentiality level of the data. → Confidentiality
• The document names lock-in risks and says which other products could be used in place of the present one. → Replaceability
• The costs of the chosen style are stated next to its benefits, such as operational complexity or network latency. → Architecture Style