Why? As the IT architect, you are 100% responsible for the technical success of the solution. If the solution doesn't work, it's your fault - not the users, not the project managers, not the programmers, just you. Pack your things; you're done.
This is why your mentor said "NO" to your idea of using the newest and hottest technology. IT architects just can't go with an unknown quantity as a key component of their solution. The consequences of failure are just too great; causing great harm to many. Here are some guidelines on how to apply this best practice:
1. Construct your solution with proven products:
- Make sure each product serves a well-known product space (i.e. a relational database)
- Play products to their core strengths - don't use them in strange ways
- Look for products with healthy development activity - new versions on the way
- Look for products with strong support communities
- Look for products with great documentation
- Avoid new products - v1.0's are deadly
- Avoid products dying on the vine (i.e. ownership changes, deprecation, etc.)
2. If no proven product exists to fill the role you carved-out for it:
- Rework your solution - try to simplify it
- Don't build your own, rework your solution - no platypuses!
- When forced to consider an unproven product, don't buy or commit to it - prototype it quickly with your best and brightest, put it under realistic operational scenarios, then decide if you can live with it
Lesson Learned: To minimize risk and accelerate delivery, construct solutions using current, well-known, and proven products with strong support communities.
BTW: I think platypuses are way cool. Not to be confused with the clumsy metaphor above.
