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