Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Proven Technology?
A technical architect can't simply select the latest software or hardware that appears to meet the needs of the client. In effect, using a brand new technology turns a client into a "guinea pig" for that technology. Even if it's bug-free (far from likely in a new product), there are generally many "teething" problems with new technologies:
-
Time required to train staff in the use of the new technology
-
Getting good support to deal with problems
-
Finding good documentation or books about the technology
-
Finding tips or snippets of code to help reduce development time
Because new technologies are often bug-ridden, some features may not be used effectively until the next service pack or patch is released. Thus, workarounds need to be found to get the system implemented despite these bugs (or features).
Many of the requirements mentioned in my last article (performance, scalability, security, availability, etc.), for example, are met by Windows Advanced Server. However, because this product is very new, many technical architects would shy away from choosing it.
A number of years ago, I worked with a company that was using a new ODBC driver on a project where few people had ever used ODBC. A contractor with ODBC experience was brought in to try to sort out the problems. We needed only a couple of days to pinpoint the problems with the ODBC driver—clearly, it had bugs. But it took us nearly three weeks to convince the vendor—and that actually required having the vendor come down to our offices to see the bugs in action. After that, the vendor took three more weeks to come up with a "fix"—but although the fix corrected the bugs we had found, it introduced more bugs! In the meantime, workarounds had been put into place in the code, but the main project had been held up for more than two weeks before the workarounds were implemented, and the workarounds in turn caused a lot of problems for the programmers debugging their code.
Similarly, when Java was relatively new, I had a number of problems developing Java applets for clients because the two main Web browsers at the time responded very differently to the same Java code, due to "features" in each browser's virtual machine.