# Architecture Challenges at Project Start

**In short:** 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.

## Explanation

Architects make their most basic decisions at the start of a project. That is also when they know the least. Several challenges appear together.

**Requirements are unclear and keep changing.** One well-known author calls changing requirements the biggest cause of trouble in the software projects they meet. This is a main reason to design in an evolutionary way, where the design grows and adjusts over time.

**Even "clear" requirements can be wrong.** A team may feel sure how a function works and still build it incorrectly. Certainty at the start is never complete.

**Constraints limit freedom.** A constraint is a fixed condition the architect must respect (see Architectural Constraint). Constraints must always be dealt with, but some can be negotiated. They often reach beyond one system and apply to a whole organization.

**Early decisions may be wrong.** Teams should expect to err in early architectural decisions. These decisions are not set in stone, and teams need the courage to fix them.

**Timing matters.** Teams want to decide at the most responsible moment (see Last Responsible Moment). Essential decisions should be recorded as Architectural Decision Records, or ADRs (see Architectural Decision Record). Even very agile teams capture the essential ones somehow.

These challenges explain why architects work systematically with requirements, constraints and decisions.

## Example

A team starts building an online booking tool. The business says bookings must be "fast" but does not say what that means. Later the customer changes the booking rules. The company also requires one specific database for all systems. The team asks whether that rule is negotiable. It makes its main choices, writes them down in short decision records, and stays ready to revise them as it learns more.

## Trade-offs

Waiting for the most responsible moment gives the team time to learn more before it commits. Recording decisions costs effort. The advice is to pick one ADR template and stick to it. Do not document everything, only the essential decisions. Staying open to revision also requires a team that is willing to admit and fix early mistakes.



## Checks

- Constraints are listed, and the document notes which ones may be negotiable and which apply organization-wide.
- Essential architectural decisions are recorded, for example as ADRs, using one consistent template.
- The document states that early decisions may be revisited and corrected.

## Related

- [Last Responsible Moment](https://arc.fuet.ch/concepts/forces-decisions/last-responsible-moment.md)
- [Architectural Constraint](https://arc.fuet.ch/concepts/forces-decisions/requirements-versus-constraints.md)
- [Architectural Decision Record](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-record.md)
- [arc42 Constraints](https://arc.fuet.ch/concepts/documentation/arc42-constraints.md)
- [Architectural Force](https://arc.fuet.ch/concepts/forces-decisions/architectural-forces.md)
- [Architecturally Significant Requirement](https://arc.fuet.ch/concepts/forces-decisions/architecturally-significant-requirement.md)
- [Solution as Moving Target](https://arc.fuet.ch/concepts/forces-decisions/solution-as-moving-target.md)
- [Architectural Decision](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision.md)

## Sources

- [Is Design Dead?](https://martinfowler.com/articles/designDead.html) — martinfowler.com, accessed 2026-11-09
- [Architectural Decisions — The Making Of](https://ozimmer.ch/practices/2020/04/27/ArchitectureDecisionMaking.html) — ozimmer.ch, accessed 2026-11-09
- [2 - Constraints | arc42 Documentation](https://docs.arc42.org/section-2/) — docs.arc42.org, accessed 2026-11-09