Constraint Thinking
Designing within the real limits — budget, skills, timeline, existing estate, organisational politics — rather than for the abstractly best answer.
The best architecture for a problem in the abstract is usually the wrong architecture for the organisation that has to build and run it. Constraint thinking is the discipline of designing for the situation rather than for the textbook.
The constraints that most often decide the answer and least often appear in documents. Team capability: a design requiring expertise the team does not have and cannot hire is not a design, it is a hiring plan with a diagram. Operational capacity: who runs this at 3 AM, and do they have the knowledge? Existing estate: the new system must integrate with what exists, and that shapes more than any greenfield preference. Timeline: a correct architecture delivered after the commercial window has closed has failed. Organisational structure: Conway's law is a constraint, and a design that cuts across the org chart will be fought continuously.
The professional move is to make constraints explicit and negotiable rather than silent. Stating "this design assumes we can hire two engineers with this skill; if we cannot, the answer changes" is architecture. Designing as though the constraint does not exist and letting delivery discover it is not.
And some constraints are worth challenging — but challenge them openly, with the cost of removing them quantified, rather than designing past them and hoping.