Architectures (I)

When an IT architect designs a new architecture, it has to favor some aspects among others: performance over administration simplicity, administration simplicity over installation simplicity or etc. Depending on the situation and the architect criteria, it’s better to favor one or another. It’s a price that we have to pay, because it’s nearly impossible to get it all.
Once the design has been created, if other IT guys see it, they could think it’s not the best design because everybody has different personal criteria: some people are stability fanatics and they could choose even very old but stable releases. Other could prefer state of the art architectures, etc. And the main problem is that under their personal criteria, they all are right and the rest of the world is wrong.
At this time, I’m reading “Togaf 9: Pocket guide” which has been inspiring for me. Togaf states that there is an initial phase during the design of an IT architecture, where the principles and guidelines of the design have to be set. That means that the Architect has to discuss with the customer or the IT department, which will be the principles and guidelines that will drive the design, and the most import issue, they should be included at the beginning of the design document. By doing that, the architect is setting the rules for the architecture and giving fewer margins for personal criteria.
Many people could think that this is only valid for big architecture projects, but I think it’s not true, even if the architect delivers a sample architecture, that design should also include a chapter with the sample principles and guidelines that are behind it