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.
… trust to and the influence of the (presumably talented) architect… IMHO, this should be an agreed expectation between architects and other stakeholders. (Technical)decision taking is a part of the job description of any architect. In my opinion KISS, YAGNI, etc are overly rated principles anyway. Based on my experiences, confronting an architect with these principles is most of the time naïve and superficial.
Thanks for the feedback, Kaan. I agree that the initial understanding among the architect and stakeholders should be there about architect’s capabilities and responsibilities. However, I saw cases in practice where this wasn’t established fully; and in any case this understanding doesn’t free the architect from the job of establishing and reinforcing his/her informal influence in the organization.
You’re also correct to point out that the opposite case where the architect is arguing to extend the design at the expense of simplicity may occur, as well. And again, lacking a hard argument for simplicity carries the discussion from the basis of facts to a more abstract level making the discussion more difficult. So it comes ultimately down to gut feeling and negotiation/persuasion skills.