Like projects, you've got to have *some* requirements
Technology selection is generally seen as one of the most fun parts of the software architect role because you get to sit down, download something new and learn how it works. And it is fun, but my view of it has changed over the last couple of years.
As an architect, if I'm going to be held responsible for the success of a software project, I want to make sure that the technology I choose will contribute to that success rather than hinder it. Where I used to look at technologies from a development perspective, I now look at them *additionally* from an architecture perspective. This means that questions such as "what is the API like?" and "will this integrate with our other frameworks?" are supplemented with questions such as "will this meet our performance requirements?" and "what are the security implications of using this?".
One of the hardest things about technology selection is that for every problem there are several solutions and a mass of information available about them. How you decide which one to pick is probably the subject for another blog entry, but it's sufficient to say that there are some basic questions that will help you along your way.
- What are the functional requirements that this technology needs to satisfy?
- What are the non-functional requirements that this technology needs to satisfy?
- What are the selection criteria?
Without these questions answered, it's not going to matter which technology you choose because it will probably be wrong. Technology selection can range from putting together small proofs of concept through to a full scale analysis exercise where you apply weighted scores to the criteria that you're judging against. However you do it, you need to be sure that the technology you choose is going to meet your needs; both now and in the future. Failing that, you better be able to justify exactly why you chose it. ;-)