[oosh9Shi]

I would say the two most important things are to learn to simplify and to not be a yes man (and actually, to learn to be a no man).

This is something all developers experience, of course, but it's of utmost importance when you're responsible for the architecture. For every problem your company will face, business side will come to you asking with the idea of a solution rather than with a problem. You have to extract the problem from the suggested solution, then ask yourself how you can do simpler, not to overload the architecture with adhoc solutions.

And sometimes, you have to just say "no". Business side always have tons of ideas that they will insist on being high priority, then forget about it a week later or never use the feature if you release it. A nice trick is to make them prioritize the todo list themselves, so they feel the importance of each requirement compared to the others. Just forbid they put their last idea on top of the todo list, no matter how loud they're crying for it, or it will always be the last ones that are on top. If they put it somewhere lower, they will put it to the higher position they can, then they will re-evaluate its position correctly when looking at the todo list again later.