Дисклеймер: я не системный архитектор, и даже не знаю, кто конкретно должен так называться, наверное это что-то вроде технического директора.
Или у меня чрезмерно идеалистические представления о роли архитекторов в разработке?
Да, чрезмерно. Архитекторы (как вы их называете) не боги и даже не "вторые после бога".
включая "подводные камни", которые, как правило, доступны только прилично поработавшим с технологией специалистам?
Подводные камни архитектор знать может, но вовсе не обязательно он должен их сам находить. Обычно ему о них сообщают поработавшие с технологией специалисты. А если технология еще не обкатанная, то архитектору достаточно это понимать, и уметь прикидывать риски нахождения подводных камней - это умение не относится к конкретной технологии.
Опять же, отрасль очень бурная - когда успевать работать и следить за всем, что в ней происходит?
А надо уметь главное выделять. Ну к примеру, вот позавчера анонсировали докер на винде на нативных контейнерах. Что нужно знать хорошему техническому директору? Что в 2016-й винде есть контейнеры (причём двух видов, настоящие и поверх hyper-v), что докер теперь будет их использовать со всеми вытекающими. Само собой нужно представлять что такое контейнер и чем от отличается от ВМ. Вот и всё что нужно знать, ну и посматривать за отзывами первых, кто осмелится опробовать технологию в деле.
Ну или вот возьмём TypeScript. Не обязательно писать на нём или знать его досконально. Достаточно понимать, что такое статическая типизация в языке, и уже можно будет представить разницу между использованием в большом проекте ES5/ES6 и TypeScript. Достаточно принять решение опробовать его у себя (как сейчас делаем мы) на небольшом куске проекта, и сделать вывод о дальнейшем использовании.
Возьмём, наконец, базы данных. Не думаю, что хороший "архитектор" обязан знать, что в какой-нибудь Монге какие-нибудь запросы с агрегацией по двум свойствам работают в 5 раз медленнее, чем по одному свойству. Однако то, что в Монге нет атомарной записи сразу нескольких документов, знать очень полезно, я бы даже сказал, критично (иначе можно пытаться написать какой-нибудь биллинг на Монге вместо какой-нибудь реляционной базы, и сорвать пучок проблем).
Техническому директору проекта ("архитектору") гораздо важнее уметь правильно обрабатывать информацию, уметь снимать маркетинговую шелуху (вроде той, что была и есть с NoSQL от всех проблем и несчастий), спокойно реагировать на модные баззворды, и собирать библиотеку доверенных людей и информационных ресурсов. И важно знать о вещах, которые с течением времени не меняются, или меняются медленно и неохотно:
- для каких задач подходят функциональные языки, а для каких - ОО;
- что графовая СУБД как правило быстрее обрабатывает запросы на поиск с большой длиной цепочки;
- что утверждение из предыдущего пункта неплохо бы проверить на практике с конкретными СУБД;
- что веб-фреймворки бывают толстые и тонкие;
- какие сегодня есть вариации паттерна MVC;
- что сборка мусора это всегда накладные расходы и иногда не вполне предсказуемое поведение;
- что данные от пользователя нужно фильтровать, иначе в вашей системе найдут машину Тьюринга не там, где надо;
- что в информационной системе есть компоненты с разным уровнем доверия, равно как и сотрудники;
- что транзакции в СУБД придумали не для того, чтобы учебники стали толще.
Простой
