Accept Constraints
In Limit Design Options with Constraints you learned that constraints are predetermined design decisions that cannot be changed. Recall there are two types of constraints: technical and business. Technical constraints limit your technical options whereas business constraints focus on people, process, cost, and schedule.
We have no choice but to embrace technical constraints and incorporate them into the architecture. If we agree that the system must be written in .NET, then there is no point lamenting over the loss of your favorite Java framework.
Business constraints are a bit more nuanced. You also have to accept these, but their impact on the architecture is not always evident. For example, say you’ve agreed to a business constraint that the system must be ready in time for a trade show at the end of July. You might consider several architectural decisions to satisfy this constraint:
- Choose a pattern that promotes concurrent development effort.
- Choose a pattern that promotes incremental delivery.
- Choose technologies the team is familiar with to reduce risks.
- Choose technologies that support automation and development speed.
- Choose to skip planning, accept technical debt, and build a ball of mud.
- Choose combinations of all these ideas.
Business constraints can also be satisfied outside the architecture—for example, by emphasizing craftsmanship and early testing, or by using a subcontractor with lower hourly rates.
Remember that early design decisions can become constraining, but they are not constraints. Like the load-bearing walls of a house, these early design decisions hold everything else in place. Moving a load-bearing wall in a house might be costly and challenging, but it is technically possible. Always distinguish between the constraints you are given and the constraints you give yourself.
While constraints strongly influence the architecture, most of our design decisions (and trade-offs) in the architecture will focus on promoting desired quality attributes.