All design is tradeoff. Any relevant system will ask for a balancing of forces while making design decisions. Therefore formulation of alternative designs and evaluation based on concrete criteria helps tremendously in laying out the tradeoff in front of the stakeholders and reaching a good decision in a transparent way.
This all works well except for simple designs. We have several design philosophies making the appeal for simplicity: KISS, YAGNI, less is more etc. But the method I explained above calls for concrete arguments, and this in most cases will be missing as simplicity simply calls for exclusion of an element from the design just for simplicity’s sake, i.e. for the sake of not adding the complexity in order to keep some reserve design space for future maneuvering. However, the element in question will have a very much concrete argumentation, such as:
- We definitely need this feature for customer X
- We definitely need this flexibility in case Y is changed in the future
And on the other scale you’ll just have some design philosophy and the architect’s gut feeling, both quite abstract.
This is a difficult problem. One of the remedies is of course the trust to and the influence of the (presumably talented) architect, so that she can render her gut feeling or philosophy as important as concrete customers or NFRs. This is also an area where iteratively built systems shine, as leaving uncertain points outside of the current iteration with an easily predictable horizon also results in simpler systems. However, this is not a silver bullet, especially when market conditions require a complex feature to be built first or when the initial architecture baseline needs design elements to start the iteration.
Another aspect that helps for simplicity is a comprehensive view. When an architect has the complete view of a product or system, she can better judge the priorities. In contrast, design by committee methods with noone having the overall view or responsibility result in diverging and verbose designs. Same applies for products where multiple product managers work on the same product, which will most likely experience a significant amount of feature creep.