# Forces, Constraints and Decisions > Architectural forces, concerns, constraints, architecturally significant requirements, architectural decisions, decision records (ADR), decision management and guidance. ## Forces, concerns and constraints - [Architectural Constraint](https://arc.fuet.ch/concepts/forces-decisions/requirements-versus-constraints.md): An architectural constraint is a requirement that limits how freely architects can design and build a system. Teams must always deal with constraints, though some can be negotiated. Writing them down shows where the design is free and where it is not. - [Architectural Force](https://arc.fuet.ch/concepts/forces-decisions/architectural-forces.md): Forces are pressures that pull an architectural decision in different directions, such as deadlines, cost, skill, and change. Architects weigh them against each other. Constraints, by contrast, must be dealt with. - [Architecturally Significant Requirement](https://arc.fuet.ch/concepts/forces-decisions/architecturally-significant-requirement.md): An architecturally significant requirement strongly shapes the architecture because it is hard to meet, costly to change later, or risky. Teams spot these with a qualitative seven-criterion test and keep a short list of about ten. - [Concern](https://arc.fuet.ch/concepts/forces-decisions/concern.md): A concern is something a stakeholder cares about in a system, such as performance, security or maintainability. Concerns shape architecture, can conflict, and must be explicitly addressed in the architecture description. - [Solution as Moving Target](https://arc.fuet.ch/concepts/forces-decisions/solution-as-moving-target.md): The solution a team delivers rarely matches the one imagined at the start. Business changes and decisions made along the way move it. Good practice plans for this drift instead of fighting it. - [Stakeholder Concern](https://arc.fuet.ch/concepts/forces-decisions/stakeholder-concern.md): A stakeholder concern is an interest that a person or group has in a system, such as performance, security, or maintainability. Concerns shape what the architecture must address and which views describe it. - [Twin Peaks Model](https://arc.fuet.ch/concepts/forces-decisions/twin-peaks-model.md): The Twin Peaks Model treats requirements and architecture as two bodies of work that grow together. Both start rough and become detailed through repeated rounds, each informing the other. ## Architectural decisions - [Architectural Decision](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision.md): An architectural decision is a choice of one option from several, made against stated criteria. Writing down the reasons lets others understand and retrace the choice later. - [Architectural Decisions for Availability](https://arc.fuet.ch/concepts/forces-decisions/architectural-decisions-for-availability.md): Designing for availability means asking structured questions: which parts must stay up, how faults are detected, and how the system keeps working when something fails. The answers become design decisions. - [Architectural Design Issue](https://arc.fuet.ch/concepts/forces-decisions/formulation-of-decision-issues.md): A design issue is one concern that needs an architectural decision. You phrase it as a short question, list the options, and pick one based on criteria. You then record why you chose it. - [Architecturally Significant Decision](https://arc.fuet.ch/concepts/forces-decisions/architecturally-significant-decision.md): An architecturally significant decision is hard or costly to change, or carries high risk or cost. These decisions deserve careful review and a written record. Small, local choices do not. - [Architecture as Set of Design Decisions](https://arc.fuet.ch/concepts/forces-decisions/architecture-as-set-of-design-decisions.md): Architecture is the set of important design decisions about a system. These decisions shape quality and are costly to change later. Diagrams only show the results of those decisions. - [Decision Dependencies](https://arc.fuet.ch/concepts/forces-decisions/decision-dependencies.md): Architectural decisions depend on each other. One decision can trigger or split into others. Recording these links helps teams see which decisions to make early and where follow-on work comes from. - [Levels of Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/levels-of-architectural-decisions.md): Architectural decisions are made at several organizational levels. Higher levels decide less and mainly set guidelines. Development teams make most decisions, so sharing them openly keeps the architecture sound. - [Requirements-Decision Modeling for Cyber-Physical Systems of Systems](https://arc.fuet.ch/concepts/forces-decisions/requirements-decision-modeling-for-cyber-physical-systems-of-systems.md): ReDeMo is a formal model that links non-functional requirements (qualities such as sustainability) to architectural decisions for cyber-physical systems. It comes from the TaSSAreCt research project and is built into a SysML v2-based toolchain for architects. - [Seven Types of Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/seven-types-of-architectural-decisions.md): A decision is architectural when its effects reach beyond one place. Technology choice, such as buy versus build, is one kind of such decision. Tactics are decisions too, and the reasoning behind all of them needs recording. ## Decision records and templates - [ADR Common Mistakes and Review Checklist](https://arc.fuet.ch/concepts/forces-decisions/adr-common-mistakes-and-remediations.md): Weak decision records often hide their criteria, skip alternatives, give no real "why," or leave out downsides. A short review checklist helps catch these gaps before the record is accepted. - [Architectural Decision Record](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-record.md): An Architectural Decision Record (ADR) is a short document that captures one design decision and the reasons behind it. It answers "why this design?" and helps teams avoid reopening settled decisions. - [Architectural Decision Record Example](https://arc.fuet.ch/concepts/forces-decisions/middleware-architectural-decision-example.md): An ADR example records one decision: the question, the quality goals behind it, every option with pros and cons, and the outcome with its consequences. It lets readers retrace why a choice was made. - [Architecture Decision Documentation and Requirements Management](https://arc.fuet.ch/concepts/forces-decisions/decision-documentation-and-requirements-management.md): Architects write down important decisions with their context, reasons and consequences. That lets stakeholders retrace why the system looks the way it does, and see where constraints limited the choices. - [Architecture Decision Rationale](https://arc.fuet.ch/concepts/forces-decisions/architecture-decision-rationale.md): Architecture decision rationale is the written reason behind a key design choice. It lets stakeholders later understand why one option won and retrace the decision. - [GenAI Support for Architectural Decision Records](https://arc.fuet.ch/concepts/forces-decisions/genai-support-for-architectural-decision-records.md): Teams use generative AI to draft architectural decision records (ADRs) quickly and to explore options. The output can be wrong or invented, so humans must check every ADR before it enters the record. - [Markdown Architectural Decision Records](https://arc.fuet.ch/concepts/forces-decisions/markdown-architectural-decision-records-madr.md): MADR is a short Markdown template for recording architecturally significant decisions in a structured way. Each decision is one file in docs/decisions. Full, minimal, and bare versions exist. - [Y-Statement](https://arc.fuet.ch/concepts/forces-decisions/y-statement.md): A Y-Statement records one architectural decision in a single sentence. It names the context, the concern, the chosen option, the rejected options, the quality gained and the downside accepted. ## Decision management and process - [Architectural Decision Definition of Ready](https://arc.fuet.ch/concepts/forces-decisions/definition-of-ready-for-architectural-decisions.md): The Architectural Decision Definition of Ready is a checklist of five START criteria: stakeholders, time, alternatives, requirements, template. Teams check it before deciding, so they do not decide without the key inputs. - [Architectural Decision Making Fallacies](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-making-fallacies.md): Architectural decisions often fail through familiar flawed reasoning, such as copying the crowd or leaning on one story. Each fallacy has a countermeasure. Naming them helps teams decide consciously and record decisions durably. - [Architectural Decision Management](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-management-practices.md): Architectural decision management is a set of habits for choosing which decisions to record, deciding them at the right time, justifying them well, and following through on them. - [Architectural Decision Management Cycle](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-management-cycle.md): The cycle has five logical steps for each architectural decision: identify it, evaluate options, decide, record the outcome in an ADR, and check that the problem is solved. Teams may repeat steps for the same decision. - [Architectural Decision-Making Process](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-making-in-project-development.md): Architectural decision-making is an ongoing, team-based activity. One decision triggers others, so it is never finished at once. Teams compare real alternatives, weigh trade-offs, and revisit their choices. - [Architecture Challenges at Project Start](https://arc.fuet.ch/concepts/forces-decisions/architecture-challenges-at-project-start.md): At project start, architects must make basic decisions with little certainty. Requirements change, constraints limit freedom, and early choices may prove wrong. Good timing and recorded decisions help teams correct course. - [Definition of Done for Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/definition-of-done-for-architectural-decisions.md): A Definition of Done for architectural decisions lists the conditions that must hold before a team calls a decision finished. The ecADR proposal uses five: evidence, criteria, agreement, documentation, and realization and review. - [Last Responsible Moment](https://arc.fuet.ch/concepts/forces-decisions/last-responsible-moment.md): The last responsible moment is the point where not deciding would remove an important option. Teams delay commitment until then. Waiting past the right moment is also harmful, so timing needs care. - [RACI Matrix](https://arc.fuet.ch/concepts/forces-decisions/raci-matrix.md): A RACI matrix lists, for each task or decision, who is Responsible, Accountable, Consulted and Informed. It shows who does the work, who answers for it, who gives input and who is told.