A recent consulting engagement has involved me defining a system architecture to solve a particular business problem. While coming up with something that meets the functional and non-functional requirements can be hard in itself, you always have to bear in mind there are always alternatives. In essence, you'll probably come up with several options, regardless of whether you present them all.
The key thing that really struck me recently is that options can vary quite dramatically when you start to think about some of the additional constraints and trade-offs that can be/need to be considered. For example, your "ideal" architecture might be a distributed n-tier system but an alternative architecture might be a simple desktop application if infrastructure simply isn't available. Likewise, if time-to-market is the critical factor, you might even find yourself going down a number of different routes, some of which might be highly tactical and some might involve the use of an off-the-shelf product. Other important aspects might include existing vendor relationships, in-house skillsets, functional scope, non-functional scope, etc.
Whatever options you come up with, whoever is making the final decision needs to have as much data available in order to make the most informed decision possible. Unless you really are spoilt for choice, options represent trade-offs and sacrifices. If you know what these are, you have a much better chance of choosing the right option.