2. Architecture Constraints¶
Help: Any requirement that constrains software architects in their freedom of design and implementation decisions or decisions about the development process. These constraints sometimes go beyond individual systems and are valid for whole organizations and companies.
Motivation: Architects should know exactly where they are free in their design decisions and where they must adhere to constraints. Constraints must always be dealt with; they may be negotiable, though.
Form: Simple tables of constraints with explanations. If needed, you can subdivide them into technical constraints, organizational and political constraints, and conventions.
2.1 Technical Constraints¶
Help: List technical constraints here such as required operating systems, hardware, middleware, programming languages, frameworks, libraries, or specific versions of these.
| ID | Constraint | Description / Background |
|---|---|---|
| TC-01 | \<e.g., Programming Language> | \<Must be implemented in Java 17+ due to corporate standard> |
| TC-02 | \<e.g., Operating System> | \<Must run on Linux (RHEL 8+) in production> |
| TC-03 | \<e.g., Database> | \<Must use PostgreSQL as the primary data store> |
| TC-04 | \<e.g., Cloud Provider> | \<Must be deployed on AWS (corporate cloud platform)> |
| TC-05 | \<e.g., API Standard> | \<All APIs must follow REST conventions and OpenAPI 3.0 spec> |
| TC-06 | \<e.g., Container Runtime> | \<Must be containerized with Docker / deployed via Kubernetes> |
| TC-07 | \<e.g., Browser Support> | \<Must support latest two versions of Chrome, Firefox, Safari, Edge> |
2.2 Organizational Constraints¶
Help: List organizational constraints such as team structure, schedule, budget, development process, or standards that the organization mandates.
| ID | Constraint | Description / Background |
|---|---|---|
| OC-01 | \<e.g., Team Structure> | \<Development is distributed across two teams in different time zones> |
| OC-02 | \<e.g., Schedule> | \<MVP must be delivered by Q3 2026> |
| OC-03 | \<e.g., Budget> | \<Total infrastructure budget limited to $X/month> |
| OC-04 | \<e.g., Development Process> | \<Must follow SAFe agile methodology with 2-week sprints> |
| OC-05 | \<e.g., Approval Process> | \<Architecture decisions require Architecture Review Board approval> |
| OC-06 | \<e.g., Version Control> | \<All code must be managed in GitLab with merge request reviews> |
2.3 Conventions¶
Help: List conventions the team has agreed upon or that are mandated by the organization. These can include coding standards, documentation requirements, naming conventions, or architectural patterns.
| ID | Convention | Description / Background |
|---|---|---|
| CV-01 | \<e.g., Coding Standards> | \<Follow corporate coding guidelines (link to standard)> |
| CV-02 | \<e.g., Architecture Documentation> | \<Use arc42 template for all architecture documentation> |
| CV-03 | \<e.g., Naming Conventions> | \<Services follow the pattern svc-{domain}-{function}> |
| CV-04 | \<e.g., Testing Standards> | \<Minimum 80% unit test coverage required for all services> |
| CV-05 | \<e.g., API Versioning> | \<APIs must be versioned using URL path versioning (e.g., /v1/)> |
| CV-06 | \<e.g., Logging> | \<Structured JSON logging with correlation IDs is mandatory> |
| CV-07 | \<e.g., Security> | \<OWASP Top 10 compliance required for all web-facing services> |
Based on the arc42 architecture template (https://arc42.org).
Created by Dr. Peter Hruschka and Dr. Gernot Starke.
Licensed under CC BY-SA 4.0.