Options
They represent trade-offs and sacrifices
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.
Re: Options
First of all I must say this is a nice post with some good advise for up growing architects like me. Still I have to ask. What do you mean by "non-functional requirements" ?
I'm not English native so perhaps that made it difficult for me to put it in right context. Could clarify it bit more please.
Re: Options
Re: Options
Re: Options
The architect might not be responsible for defining the non-functional requirements, but they're definitely responsible for fulfilling them. For example, the security policy might be determined by law or third-party requirements but it is the architect's responsibility to ensure that it is met by the system/application. Similarly, if you choose a technology that exceeds the project's budget then that's your mistake.
As for options, I think you've got to be careful about presenting "all the data". As a technical authority you should be able to make many of the decisions yourself based on knowledge of the technology, environment and technical strategy. Rather than presenting a series of options I'd consider asking a series of questions to whittle the options down first.
Re: Options
Options : In the case where you're *the* architect on a project, I agree, you should whittle down the options yourself and make sure you have enough evidence to support that decision when you are questioned about it later (which always happens in my experience!). Having said that, if you're in much more of a consultative capacity, you might not be the one that needs to make the decision, so presenting all of the data becomes necessary. It all comes down to whether you have the responsibility and the authority. In my case, I had neither.
