Step 5: Collect constraints and forces

What you get from this step

You get two lists. The first lists the constraints: requirements that limit how you may design and build the system. The second lists the forces: pressures that pull a design decision in different directions.

The constraint list goes into chapter 2 of arc42 (see arc42 Constraints). It shows where the team is free to choose and where it must comply. The force list helps you later, when you weigh options and write down decisions.

The two lists work differently. You must deal with a constraint, although some can be negotiated. You weigh a force against other forces. Architectural Force explains the difference.

What you need first

A rough idea of what the system must do and for whom.
The main stakeholders and the quality goals they care about most. A stakeholder is a person or group with an interest in the system. See Stakeholder Concern and Concern.
Access to the people who set rules for your project: management, the organization’s technology owners, and legal or security contacts.

If something is missing

You do not know the quality goals. Ask the most important stakeholders first. Without their goals you cannot tell which pressures matter. See Requirements and Means Influence Architecture.
You cannot tell whether something is a constraint or a force. Ask who wants it and why. If nobody can say, write it down as “unclear” and find out.
You do not know whether a constraint is fixed. Mark it “to be clarified” and name the person who can answer. Do not guess.
The list is incomplete. That is normal at the start. Constraints limit your freedom, and early choices may prove wrong, so you will revisit the list. See Architecture Challenges at Project Start.
You find a technical limit or a goal conflict while working. Record it and pass it back to the requirements. See Twin Peaks Model.

How to do it

Learn the difference. A constraint must be handled, and some constraints can be negotiated. A force is weighed against other forces. Typical forces are deadlines, cost, skills and change. See Architectural Force.
Collect all constraints in one place. One list lets architects see where they are free and where they must comply. See Architectural Constraint and arc42 Constraints.
Look beyond your own system. Organization-wide rules, such as mandated technologies, also count as constraints. Check the organization’s standards. A catalogue of approved technologies tells you which ones are standard, need approval or are not permitted. See Relationship between Enterprise Architecture and Application Architecture and IT Component Catalogue.
Check hosting and regulation. Technical constraints and rules on regulation or data location belong on the list. See Technology Architecture.
Group a long list. Use three groups: technical, organizational/political, and conventions. Organizational constraints include budget, time and processes. Conventions include programming style and naming rules. See arc42 Constraints.
Describe each constraint. For each one, write down:
- who wants it and why,
- what it costs you, such as extra effort,
- whether it is fixed or negotiable.
See Architectural Constraint and Software Architecture in Its Context.
Mark which constraints come from the wider organization. Separate them from constraints that come only from your system. See Software Architecture in Its Context.
List the forces. Name the pressures that pull in different directions. Write each as a pair of competing concerns, such as time to market versus maintainability. See Concern.
State where you are free and where you are bound. Read both lists together and write one or two sentences about it. See Architectural Force.
Keep the lists current. Revisit them when the context changes.

Example: ClinicBook

ClinicBook is an online appointment booking system for 40 small medical practices. Patients book, move and cancel appointments on the web and in a mobile app. Practice staff manage calendars. The system sends reminders by SMS and e-mail.

The team collects these constraints. The entries are fictional.

Constraint	Group	Who wants it, and why	Consequence	Fixed or negotiable
Work with the practices’ existing practice-management software from several vendors	Technical	The practices. They run their daily work on that software.	Several integrations to build and test	Fixed. The practices keep their software.
Protect health data	Technical	Patients, practices and the law. Health data is sensitive.	Extra effort for security, and checks on where data is hosted	Fixed
Launch on the agreed date	Organizational	The project sponsor	Less room to add features or integrations	To be clarified. Ask the sponsor whether the date can move.
Team of a few developers	Organizational	Budget set by the sponsor	Limits how much the team can build and run	Negotiable only through budget
Agreed code style and naming rules	Conventions	The team, for readability	Small effort to set up and check	Negotiable inside the team

Hosting stays on the list as an open question. The team asks the privacy contact for concrete rules on where health data may be stored. See Technology Architecture.

Next, the team lists the forces:

Privacy and security versus quick booking. Stronger checks protect data but may slow patients down.
Availability during morning peaks versus a small team. Extra redundancy keeps booking working when parts fail. It also adds cost and complexity that a small team must carry. See Architectural Decisions for Availability.
Integration with legacy systems versus the launch date. Every new vendor adds work, and the date does not move.
Many integrations versus a small team. The team must choose where to spend limited effort.

Finally, the team writes a short summary. The integration needs, the data protection rules and the launch date bind the design. The team is free in how it builds the web app, the mobile app and the reminder service. The launch date goes back to the sponsor as an open question.

Done when

All constraints sit in one list, grouped as technical, organizational/political and conventions. See arc42 Constraints.
Each constraint shows who wants it, why, what it costs and whether it is fixed or negotiable. See Architectural Constraint.
Organization-wide constraints are marked apart from system-specific ones. See Relationship between Enterprise Architecture and Application Architecture.
Hosting and regulatory limits appear as concrete entries, or as named open questions. See Technology Architecture.
The forces are listed as competing concerns and kept apart from the constraints. See Architectural Force.
A short statement says where the team is free and where it is bound. See Software Architecture in Its Context.