FAQ 4.03 What should the architecture be based on, the problem being
The problem domain.
One of the primary goals of the software architect is to build a system that will survive changes in requirements and that can be
The specification of a single problem that is to be solved is unstable, since it depends on the whims of the customer and therefore is unsuitable as the basis for the system architecture. The problem domain is much more stable, because it is an artifact of the world in which the customer lives.
For example, every order entry system must deal with orders, customers, prices,
However, each particular order entry system has different parameters that reflect the customer's current requirements based on the current business situation, including different placement of fields on the screen, different colors for different fields, different currencies for multinational applications, and so on. Furthermore, some order entry systems are implemented as PC applications, others are implemented as Web-based applications, while others are implemented as Interactive Voice Response systems.
The moral for the software architect is that the system architecture should be based on the problem domain because the needs of customers change more
FAQ 4.04 Should the software architecture be based on the policy of the problem?
No—that would be totally insane.
The policy of any single problem is unstable. Software systems based on the least stable element (the problem) are
Software should be written so that changing the requirements doesn't break the architecture. Basing the architecture on the most stable element, the problem domain, accomplishes this objective.
Note that software can survive problem changes only within the confines of the problem domain. It's unreasonable to expect a system that was originally designed for the problem domain of compilers to work for cellular telephones, since this would be changing the problem domain rather than just the problem.
From an architectural standpoint, the message is to usually
FAQ 4.05 Do customers ever change their requirements?
Ha, ha, ha! The only customers who don't change their requirements are dead customers. In all of recorded history, no customer has ever changed his/her mind less than twice (and the poor customer who only made two sets of changes was hit by a meteorite on the way to sending in the third set of changes). While it is true that some requirement changes can be avoided with foresight, it is also true that most requirement changes occur for
The message here is that changing requirements are a fact of life and the wise team plans for them rather than complaining about them.