Constraints are liberating as Ted Neward said. If you start a project without any constrains, it is probably because you didn’t identify them yet.
In his book (Design of Design, The: Essays from a Computer Scientist), Fredrick Brooks argued that the constraints are friends, contrary to our intuition, and make the design task easier, not harder. Indeed, the more constraints there are, the more specialized the purpose and the easier the design task should be.
In other words, we operate better with constraints.
There are different types of constraints in a project:
- Budget constraints
- Time constraints
- Skills set and skill level of the development team
- Technical constraints
Many decisions that the architect make are driven by the constraints particularly technical constraints. Our duty as architect is to identify them as some of these constraints can be implicit or even hidden.
It is important to keep a close eye on these constraints during all your projects and not only in the beginning as they may (probably they will) evolve during the life cycle of a project. A common example is a project that starts with an allocated budget but get cut later because of the change in the strategic orientations or simply because of economical reasons.