Limit Design Options with Constraints
A constraint is an unchangeable design decision you are given or choose to give yourself. Most software systems have only a handful of constraints. All constraints limit choice, but well-chosen constraints simplify the problem and can make it easier to design a satisficing architecture. Sometimes constraints create a living hell for architects by limiting options so severely we are unable to satisfy other requirements.
Constraints can influence technical or business concerns. Business constraints limit decisions about people, process, costs, and schedule. Technical constraints limit decisions about the technology we may use in the software system. Here are some examples of each:
Technical Constraints | Business Constraints |
|---|---|
|
Programming Language Choice Anything that runs on the JVM. |
Team Composition and Makeup Team X will build the XYZ component. |
|
Operating System or Platform It must run on Windows, Linux, and BeOS. |
Schedule or Budget It must be ready in time for the Big Trade Show and cost less than $800,000. |
|
Use of Components or Technology We own DB2 so that’s your database. |
Legal Restrictions There is a 5 GB daily limit in our license. |
Capture Constraints as Simple Statements
To capture a constraint, describe the decision and its origin in a brief statement. There are some constraints for the Project Lionheart system in the table, introduced.
Constraint | Origin | Type | Context |
|---|---|---|---|
Must be developed as open source software. | Mayor van Damme | Business | The City has an Open Data policy and citizens must have access to source code. |
Must build a browser-based web application. | Mayor van Damme | Technical | Decreases concerns about software delivery and maintenance. |
Must ship by the end of Q3. | Mayor van Damme | Business | Avoids end of fiscal year budget issues. |
Must support latest Firefox web browser. | City IT | Technical | Officially supported browser. |
Must be served from a Linux server. | City IT | Technical | City uses Linux and open source where possible. |
Constraints, once decided, are 100 percent non-negotiable. Be conservative in accepting constraints. There is a huge difference between this must be done or you will fail and this should be done unless you have a good reason not to do it.
As the software system emerges, design decisions can become constraint-like. Distinguishing between the constraints we created and the ones we were given becomes more difficult as the system grows. Like barnacles on a ship, software slowly gains cruft and becomes less nimble, less clean, less malleable. Eventually, it may become so difficult to amend the architecture that those early design choices become constraints for future designers.
As constraints emerge, be careful to distinguish the constraints chosen for you from the constraints you give yourself. Though it may be difficult, you always have the option of changing a constraining design decision.