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.
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. ;-)
Simon lives in Jersey (the largest of the Channel Islands) and works as an independent consultant, helping teams to build better software. His client list spans over 20 countries and includes organisations ranging from small technology startups through to global household names. Simon is an award-winning speaker and the author of Software Architecture for Developers - a developer-friendly guide to software architecture, technical leadership and the balance with agility. He still codes too. You can tweet Simon at @simonbrown.