Интересный опыт. У меня была похожая история на одном из проектов. Насколько охотно вообще инженеры соглашаются быть «дежурными»?

У нас это не так, большинство Solution Architects остаются hands on, делают прототипы и POC, постоянно ресерчат и пробуют новые технологии. Конечно это может быть по другому в других компаниях.

Вот эта история мне намного больше нравиться, спасибо :)

Спасибо за вопросы и коментарии, значит не зря статься вышла :).

Я думаю история таки не полная. Потом приходит тимлид на рабочее место, зовет джуна и говорит ему какие архитекторы таки идиоты, и как он умно и по правильному он все придумал. Джун понимает где-то 10% из того, что ему тимлид расказывает, но работой своей дорожит, поэтому бесстрашно идет в гугл и на стековерфлоу, и делает код, который ну точно работает.

На мой взгляд, во всей истории не в архитектуре дело, а в том, что люди на проекте не знают как правильно делать свою работу. Это можно и нужно исправлять.

Ребят, вижу темы технолгий, архитектуры и технической карьеры многих интересуют. Напшите о чем еще было бы интересно почитать в этом разрезе. Если я что-то знаю по этому поводу, то поделюсь.

Бывают нетехнические. Если они не идиоты, то скорее всего, не верят просто наслово нашим мидлам. Вообще, если Вам кажется, что вам удалось заказчику повесить на уши лапшу, срочно проверьте свои собственные уши. Но это, конечно, субъективный опыт :)

Виктор, у нас огромное количество проектов, где это может быть организовано по разному. В целом может быть вариант, когда есть «пресейл архитектор», который учавствует в самых первых фазах энгейджмента и рисует архитекруту будущего решения на очень абстрактном, концептуальном уровне (тут хадуп, тут кафка, тут микросервисы). Далее такое понимание архитекртуры уходит в деливери, где есть группа архитекторов, котоыре это делатизируют и приземляют на конкретные требования и реалии проекта.

Как правило пресейл архитектор, делает транзишин того, что было продано, команде деливери и после транзишн фазы может больше в проекте не учавствовать т.к. его функция закончена. Деливери команда архитекторов может оставаться на проекте либо до конца, либо до того момента, когда девелопмент стал на рельсы и изменений в архитектуре не предвидятся.

Это один из вариантов.

Да, СА занимается пресейлом, иногда он может полностью заниматься только этим. Но давайте будем честными про мидлов: лапшу мидл может навешать только такому же мидлу на стороне кастомера ;).

Мидл не сможет, т.к. архитектор должен валидировать технические решения лидов команд или направлений базируясь на своем опыте и понимании общей архитектуры. Найдете мидла, который это может делать, дайте контакты.

Да, там речь идет о возможности для кандидатов, которые не работают в ЕПАМ. Поэтому есть конкретные входные требования. Внутри САС проходят без привязки к стеку.

Критерий нормальный и частенько применяется в разработчке софта :). В итоге для них это оказалось удачным решением?

Полностью поддреживаю, эти роли дополняют друг друга и описанная схема взаимодействия вполне рабочая.

у нас начиная с СА3 архитекторы учавсвуют в программах Enterprise уровня и мы их обсучаем TOGAF и похожим фреймворкам. Так что можно считать, что СА3 это уже Enterprise Architect.

У нас переход на эти ступени СА4 и СА5 обычно предполагает ключевую роль и зону отвественности человека на уровне страны, большого клинета или на глобальном уровне (cross-country).

Конкретный подоход сильно зависит от компании. У нас проектов много и как правило они довольно большие, поэтому на проекте бывает и Solution Architect, который больше занимается общей архитектурой и несколько техлидов, работу которых супервайзит SA.

Пользу для проекта я определяю довольно просто: если цели проекта понятны, то все что мне помогает их добиться — является полезным, а все что замедляет мой прогресс по отношению к целям — вредным или бесполезным.

Я не согласен, что бизнесу пофигу. Бизнес чувствует плохую архитектуру и плохое внутренее качетсво продукта по времени нужному на внесение простых изменений, по количеству рандомных дефектов, по ужасной производительности и неудовлетворенности конечных пользователей системы. Просто он не может вам сказать, что у вас плохая архитектура или плохой дизайн, он говорит в своих терминах — мы это не может продавать ...

В каком то виде в IT архитектор тоже знает свойства технологий (материалов), которые он применяет в решении и в идеале имеет опыт работы с этими технологиями. Да частенько, бывает, что архитектор может не знать никаких свойств, а просто берет решение из последней статьи, которую прочитал в интернете и тогда происходит потеря времени, денег, репутации...

В IT создать можно все что угодно

 — да можно, но стоит прикидывать и реальную стоимоть, реалестичность и обоснованность такого строительства для проекта.

Обычно все эти роли работают с заказчиком, чтобы определить видение конечного продукта и имеют много общего в навыках, техниках и подходах. Все же разница есть — БА\ПО отвечают за более детальную проработку продуктовой и функциональной части, архитектор отвечает за проработку технической стороны.

Читать стоит. В отношении подходов Роба Мартина — будте прагматичны, стоит попробовать и оставить то, что дейсвтительно приности пользу проекту.

В SAS обучаются аритекторы из разных стеков, никакого фокуса в обучении на Java нет. Скорее всего речь идет о попаднии в САС при турдоустройстве и это дополнительное условие диктуется конктеным демандом.