Technology selection

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. ;-)



Re: Technology selection

Surely the main reason technologies get chosen is to build a better... CV!

I've seen major purchasing decisions based on a really good golf day with a vendor (including a trip to a local 'dancing' establishment).

But my favourite reason for a technology 'choice' though was probably the time a vendor was asked for a quote. They sent the quote and then sent an invoice a few days later (without any purchase order ever being sent to them). The accounts team paid the invoice by mistake and from then on the technology was selected... I kid you not.

Re: Technology selection

Without these questions answered, it's not going to matter which technology you choose because it will probably be wrong.

Aren't pretty much all technology selections wrong, it's a matter of the extent to which they're wrong? :P

I completely agree that you need to be clear what you're looking for from a product or technology. I've seen SWOT applied to technology selection and it's ended up reading more like a high-level Gartner report than a project-specific comparison.

Re: Technology selection

In Addition to the steps you've mentioned
* 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?
You should also consider the impact of the technology chosen on the architecture you already have in place/in mind. Technology products have their own architecture and their own constraints. These have to be aligned with the architecture - either by choosing an compatible technology or by amending the architecture. I wrote about this here

Re: Technology selection

Enterprise environment (existing resources, tools, skillsets etc.) also plays a very important role in technology selection.

Add a comment Send a TrackBack