«Меня собеседовали 6 директоров и вице-президент». Архитектор 4-го уровня EPAM про то, как разработчику вырасти до архитектора решений (+список книг)

52 комментария
«Меня собеседовали 6 директоров и вице-президент». Архитектор 4-го уровня EPAM про то, как разработчику вырасти до архитектора решений (+список книг)

Позиция Solution Architect до сих пор не слишком распространена в белорусских ИT-компаниях. dev.by пообщался с Дмитрием Гурским, архитектором решений EPAM, чтобы узнать, чем занимаются архитекторы в белорусском ИT-гиганте. 

«Долгое время не было до конца понятно, чем архитектор отличается от разработчика»

Я начинал с позиции разработчика. В своё время писал на C++, потом на Java, на C#. Прошёл, наверное, все основные ступеньки: был и тимлидом, и проектным менеджером. В паре небольших компаний в Минске занимал должность регионального CTO.

В EPAM попал странным и интересным образом. Меня собеседовали шесть разных директоров и решали, на какую позицию я подхожу. Седьмым был вице-президент, который после полуторачасового интервью сказал, что я архитектор 1-го уровня, и меня надо взять. Я тогда не понимал, что такое «1-го уровня», но все говорили, что ты архитектор, и это круто. Тогда позиция архитектора только начинала появляться.

Это был 2011 год. До десятых годов роль архитектора выполнялась командами коллегиально или тимлидом. Но чаще — группой разработчиков. Как отдельная должность она появилась лет 8-9 назад. Долгое время не было до конца понятно, чем архитектор отличается от разработчика. У нас в компании матрица с детальным описанием компетенций и навыков выкристаллизовались где-то к 2014 году.

Что такое архитектура решений на примере аэропорта «Берлин-Бранденбург»

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

Приведу пример. Существует история с аэропортом «Берлин-Бранденбург». Его должны были сдать в эксплуатацию в 2011 году, потом в 2017, теперь уже собираются сдавать в 20-м. Стоимость возросла с 2 миллиардов евро до 6 с половиной. В этой истории много всего: и коррупция, и неэффективные процессы «разработки». Но, как писали в Deutsche Welle, одна из основных причин неудачи проекта — ошибки архитекторов при проектировании системы вытяжной вентиляции, что могло бы повлечь за собой большие жертвы в случае пожара в терминалах. То есть архитектурно система была сделана так, что повлекла за собой переделку огромного количества вещей. Так же и в ИT.

Решение — это что? Например, есть организация, в которой мы хотим открыть новую ветку бизнеса. В этой организации люди выполняют определённые роли, определённые рабочие процессы: бухгалтер, продавец и т. д. В современном бизнесе любые процессы нуждаются в программном обеспечении. Решение — это тот набор ПО, который помогает организации решать конкретную бизнес-задачу. Архитектор, может предложить заказчику готовый продукт «из коробки», а возможно, будет делать всё с нуля. Например, для небольшого бизнеса по продаже цветов Ехсel может решить все проблемы. Но это другая история. У нас сейчас есть интересный проект для крупной автомобильной компании. Он связан с «интернетом машин». Очень интересная тема, где с нуля делается все кроме облачных сервисов. В обоих случаях решаются задачи для каждого конкретного бизнеса.

С какими заказчиками приходится общаться архитектору?

Это всегда разные люди. Почти каждое общение с новым заказчиком — это новый опыт. Во-первых, в разных компаниях разная культура. Во-вторых, многое зависит от тех активностей, в которые ты вовлечен. У меня был следующий кейс. Для крупной компании, занимающейся электрооборудованием, мы делали дискавери. В переговорке было 10 топ-менеджеров, архитектор с их стороны и наша команда. А в другом случае ты будешь общаться с архитектором со стороны заказчика, и только.

О 5 уровнях компетенций в EPAM и том, какими навыками должен обладать архитектор

Вторая моя роль в компании — это развитие дисциплины «Solution Architecture» в EPAM глобально. Пять лет назад наша команда начинала с того, что понятно описывала, кто такие архитекторы. Сейчас у нас несколько сотен людей, занимающих эту позицию. В компании есть 5 уровней для каждой компетенции: для архитекторов, разработчиков, аналитиков и т. д. 1-й уровень — стартовый. Критерии прописаны для каждого: чего ожидают от сотрудников в этой роли? В итоге была разработана целая платформа для профессионального роста. То есть ты можешь быть разработчиком 4-го уровня и претендовать на позицию архитектора 1-го уровня. Тебе выдаётся рекомендация, какие книги читать, какие тренинги пройти и навыки подтянуть.

Какой уровень занимаете вы в этой системе?

4-й.

Сколько в EPAM архитекторов 5-го уровня?

Наверное, человек 10. Я специально статистику не смотрел, но, как правило, это ведущие технические директора и вице-президенты по технологиям. В основном, они работают напрямую с заказчиками, с бизнесом на стороне заказчика, помогают заключать контракты, занимаются продажами, консалтингом.

Какие навыки важны для архитектора стартовых уровней?

Во-первых, широта технического опыта и знаний. Чем шире ты, будучи разработчиком, «трогал» технологии, тем лучше. От архитектора 1-го уровня мы ожидаем, что у него будет пару технологических стеков: например, опыт работы на C#, опыт работы c front-end. На 2-м уровне специалист будет знать Microsoft Azure — первый облачный стек. На третьем — Amazon WS. Уже два облачных стека. Потом, возможно, Е-commerce. У архитектора в этом плане та же ситуация, как и у разработчика. По мере накопления опыта, разработчику в какой-то момент становится всё равно, на каком языке писать, с каким стеком работать. Есть предпочтения, конечно, но всё же. Так же и у архитектора — в какой-то момент тебе уже не так важно, в каком стеке делать дизайн. Потому что общие принципы схожи. Ты изучаешь основное в новом стеке и с помощью разработчика, который в нём специализируется, можешь построить архитектуру. Поэтому широта технического опыта — это очень важно.

Второе, что необходимо архитектору, — это развитое абстрактное мышление. Если ты разработчик, ты мыслишь абстракциями уровня кода: интерфейсами, классами, сущностями из библиотек. Если ты архитектор, то думаешь на уровне компонентов решений, которыми являются приложения, облачные сервисы, очереди, хранилища данных. Начиная с 3-го уровня, мы ожидаем, что наши специалисты будут понимать вещи из enterprise-архитектуры. Мы не делаем их enterprise-архитекторами, но хотим, чтобы они могли общаться с enterprise-архитекторами на стороне заказчика, понимали их язык, понимали бизнес-архитектуру. Это делает их более эффективными инженерами.

И в нашем понимании, архитектор должен свободно перемещаться между всеми этими уровнями вверх-вниз. Поработав с enterprise-архитектором, построить архитектуру решения, потом поработать с кодом, контролируя, что реализация идет туда, куда надо, потом опять что-то построить на уровне архитектуры, и т. д. Можно использовать следующую метафору. Когда ты работаешь с кодом — ты работаешь на поверхности планеты и видишь код в рамках тех приложений, в разработку которых ты вовлечён. Поднявшись на вертолёте над поверхностью, ты видишь не только 2-3 приложения, ты видишь все решение целиком — это архитектура решения. Если сесть в ракету и подняться ещё выше, то увидишь много квадратиков, из которых состоит ландшафт приложений всей организации, и одно решение — лишь один из квадратиков. Это — уровень enterprise-архитектуры.

Вот пример из моего опыта. Я консультировал ведущего архитектора на стороне заказчика. Это была одна из американских финансовых компаний. Они хотели сделать платформу, которая должна была стать основой для существующих продуктов этой компании: все новые продукты строились бы на ней, а все текущие должны были бы на нее мигрировать. Технически и концептуально это было очень интересно. Каждый день в течение месяца мы созванивались с архитектором по скайпу. По два часа спорили, договаривались. По сути, мы обсуждали и enterprise-архитектуру, и то, как её будет поддерживать архитектура этой самой платформы. Т.е. нам надо было в обсуждении постоянно переходить между этими двумя уровнями и согласовывать их.

Третий пункт — это навыки коммуникации. Архитектор общается с командой на стэндапах, рисует диаграммы, пишет solution architecture document с описанием решения. Он должен делать то же самое и на стороне заказчика, общаться не только с техническим специалистами (например, в рамках pre sales — активности при подготовке контракта). Начиная с уровня 4+, мы ожидаем, что наши коллеги будут играть роль CTO в компании заказчика, и у нас есть такие кейсы. Здесь уже важно, насколько эффективна твоя неформальная коммуникация с людьми, потому что CTO — это очень чувствительная позиция в любой компании. Если на эту позицию берётся человек со стороны партнёра, то ему важно выстроить доверительные отношения с владельцами бизнеса и топ-менеджерами на стороне заказчика, учитывать массу нюансов, которые существуют в этом бизнесе и т. д.

Очень важны лидерские качества. Например, я уже третий месяц выступаю в роли архитектора на одном проекте. Процентов 70 от всех активностей — это то, что я предлагаю заказчику, а не он просит сделать. Я вижу, что некоторые решения неэффективны, и предлагаю архитектору на стороне партнёра сделать какие-то вещи иначе. Здесь тоже очень важны навыки коммуникации: как донести свои идеи до коллеги так, чтобы он воспринял это конструктивно, не обиделся. Например, мы переделали подход к созданию диаграмм, перешли на подход, связанный с различными взглядами (views and view points) на архитектуру. Пересмотрели подход к enterprise-архитектуре, её развитию и документированию. То есть действия архитектора напрямую влияют на бизнес заказчика.

О свободе в выборе проектов

Одновременно архитектор может работать над разными проектами или достаточно динамично менять их. В этом плане мне работа в EPAM очень нравится. Я могу поработать на проекте полгода, перейти на три месяца в другой, потом попасть в какую-то дискавери активность на две недели, потом на pre sales и так далее. В течение года архитектор может «потрогать» очень много разных технологий, поработать с разными клиентами. Это очень обогащает мой опыт как инженера.

Нет такого, чтобы архитектор был включён в некую жёсткую структуру. Просто существуют требования, которые регулируют твое поведение, как сотрудника. Например, определённый процент времени я работаю с заказчиком. SA 4-го уровня и выше может занимать какие-то роли, связанные с менеджментом, работать на позиции технического директора или его заместителя и так далее. Но он всё равно остаётся инженером и сочетает две эти специальности, инженера и менеджера. В моём случае, на проекте я занят как архитектор, а в CTO — офисе вместе с коллегами развиваю Solution Architecture дисциплину. Это такое организационное творчество, организационная инженерия. В компании большое и очень активное комьюнити архитекторов, в которое входят специалисты из более чем 20 стран — это очень мощный ресурс, возможность поделиться опытом или спросить совет.  

Вообще, у архитекторов в EPAM возможностей для выбора очень много, просто потому что много проектов. Эта такая система, которая сама себя раскручивает. Чем больше архитекторов становится, тем больше возникает в них потребность. Ведь каждый проект пытается иметь по крайней мере одного архитектора, иногда даже нескольких. Если кому-то интересно подольше поработать над сложным проектом, здесь нет препятствий. Если кому-то хочется интенсивно набраться опыта в разных активностях, то и такой вариант возможен. Кому-то же интересен конкретный стек, и он пытается попасть на проект, где этот стек будет. Если архитектор хочет реализовать собственную идею, которая кажется ему клёвой, то это стартует как внутренний проект. У нас есть специальная площадка, где такие вещи можно предлагать.

Когда нужно делегировать решение технических задач команде, а когда самому «становиться за станок»?

Это зависит от конкретной ситуации и от стиля работы человека. Вещи спорные мне удобней проверять «руками», глядя в код или, например, сделав PoC. Мне больше нравится стиль коллегиальной работы. Если ребята предлагают какое-то решение, и оно работает, это круто. Почему нет? У меня в команде есть коллега- разработчик, которому интересно стать архитектором. И мы с ним договорились, что я буду его ментором. Он делает какие-то архитектурные задачи на проекте, вместе их разбираем, комментируем, о чем-то спорим — это помогает попробовать новую активность, когда рядом с тобой есть кто-то, кто подскажет, подстрахует, поможет найти ошибку до того, как она приведёт к проблемам.

Крупным ИT-компаниям нельзя обойтись без архитектора решений?

Старая поговорка «У семи нянек дитя без глаза» здесь, мне кажется, работает. Должен быть человек, который отвечает за техническую сторону дела от начала и до конца. Архитектурой продукта, если он крупный и развивается, нужно постоянно управлять и делать это с командой в рамках цикла разработки. Продукт эволюционирует, появляются новые функции, и нужно уметь гармонично встроить их в архитектуру. Без выделенной должности здесь никуда. Мне кажется, что это правильно.

О дефиците архитекторов и программах их обучения

В EPAM дефицит архитекторов совершенно точно существует. Это при том, что за последние четыре с половиной года мы построили пошаговую систему обучения и развития инженеров , чтобы помогать им становиться архитекторами. У нас существует «Solution Architecture School» — программа для разработчиков, которым интересна архитектура. Это действительно уникальная школа, которая в компании создавалась с нуля, основываясь на нашем опыте и возможностях. Тренерами в ней выступают действующие архитекторы. Программа обучения постоянно обновляется, на протяжении трёх месяцев вычитываются определённые модули. Будущие архитекторы делают практические работы, связанные с профессиональными задачами, разрабатывают дизайн, пишут solution architecture document в качестве домашнего задания, защищают свою работу перед окончанием школы. Потом тренер всё проверяет и комментирует. В Минске конкурс в рамках программы — 4-5 человека на место.  

Ещё у нас есть «Университет». Это трёхуровневая программа, которая рассчитана на уже практикующих архитекторов, мы даём им возможность расти дальше, как экспертам.

То есть мы создали целую систему для людей, которые хотят развиваться в сторону архитектуры. Она даёт свои плоды: довольно большое количество инженеров переходят на должности архитекторов. Тем не менее, как говорит один из наших менеджеров, «нам надо ещё больше».

Также в EPAM есть программа менторинга. Она стартовала два-три года назад, очень классно работает, затрагивает такие дисциплины, как архитектура, менеджмент и другие. Твоим ментором может быть любой более опытный коллега: и старший разработчик, и технический директор, и даже CEO. Если ментор правильный, ты можешь узнать от него много такого, чего не найти в книжках.

Как разработчику не из EPAM вырасти до уровня архитектора?

Один из путей — прийти в EPAM (Смеётся). Я могу посоветовать ресурсы, которые могут помочь в обучении. Но путь, который я рекомендую — это обязательно «трогать» как можно больше технологических стеков. Например, американский научно-исследовательский институт — Software Engineering Institute — их тренинги мы активно используем для нашего университета. Есть глобальная ассоциация архитекторов IASA, с которой мы сотрудничаем, у них можно пройти полезные сертификации.

Об уровне белорусских разработчиков

Мне очень комфортно работать с нашими ребятами. Был опыт сотрудничества с разработчиками из Витебска, Бреста, Гомеля — никогда не было никаких проблем. Приятно, что в сравнении с архитекторами на стороне заказчика, наши специалисты, как мне кажется, часто более подготовлены.

Думаю, причина, с одной стороны, в хорошем инженерном образовании, которое у нас традиционно достаточно сильное. С другой стороны, культура накладывает определенный отпечаток. Где-то это трудолюбие, где-то здравость суждений.

Я вижу, что из наших вузов выходят неплохие инженеры. Понятно, что люди бывают разные, но в целом уровень их готовности работать, интереса к технологиям и способности разбираться в них — хороший. Конечно, есть разрыв между знаниями, получаемыми в вузе, и технической реальностью. Но это существует везде в мире. Этот разрыв отчасти нивелируется, благодаря тому, что существуют лаборатории, которые открывает в том числе и EPAM в вузах, есть спецкурсы, которые читают наши инженеры и рассказывают вещи, которые происходят в индустрии прямо сейчас.

О любви к Минску 

Покатавшись по множеству стран (за последние пять лет я побывал много где) я не считаю, что в Беларуси плохо живётся. Мне много раз предлагали работу в других странах, у архитекторов в компании есть возможности для релокации, но мне не хочется уезжать. Уже нет такого контраста между Беларусью и заграницей, как это было, например, в 2001 году, когда я впервые попал в Штаты. Во-первых, я люблю Минск. Я в нем родился, и мне он искренне нравится. Во-вторых, культура, люди, друзья, дети — все это вместе для меня очень важно. Мне нравится кататься в командировки, но я стараюсь не путать туризм с эмиграцией.

О том, как всё успевать

Я фанат тайм-менеджмента. Это помогает. У меня в телефоне два календаря, личный и рабочий, которые я расписываю на неделю вперёд. Есть такой товарищ — Глеб Архангельский. У него есть целая серия книг на тему учёта времени. Когда-то я набрал оттуда какие-то полезные для себя штуки, которые мне помогают.

Что можно посоветовать из хороших практик? Каждый выстраивает свою жизнь исходя из личных предпочтений, топ-3 того, что подходит мне:

  1. Календарь для того, чтобы видеть все личные и рабочие дела — это очень удобно, потому что визуализирует свободное и занятое время, а если дел много — то ты ничего не забудешь.
  2. Я следую практике «пустого почтового ящика» — все пришедшие письма или превращаются в задачи в календаре, или их содержимое сохраняется для использования позже (полезная презентация, например), или ты на них отвечаешь. После чего все они удаляются или перемещаются в папки для разных категорий писем. Это приводит к тому, что коммуникация с тобой есть всегда и она «живая» — коллеги оперативно получают ответы на свои вопросы. Плюс, ты реально планируешь и делаешь что-то на основе писем. И не тонешь в них.
  3. Если есть проблема — всегда важно найти её настоящие причины и запланировать дела, которые эти причины будут устранять. Тогда жить становится гораздо проще — ведь проблем будет меньше.

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

Наверное, самая запоминающаяся командировка была в Штаты. Просто там собралась очень хорошая компания. Там был архитектор из Харькова, архитектор из Бреста, бизнес-аналитик из Киева. Мы замечательно проводили вечера на диване в лобби отеля в городе Сент-Клауд в Миннесоте.

​Книги по теме «Архитектура решений» от Дмитрия Гурского

Хотите сообщить важную новость?

Пишите в наш Телеграм

Читайте также

В Беларуси почти 65 тысяч выявленных случаев заболевания коронавирусом
В Беларуси почти 65 тысяч выявленных случаев заболевания коронавирусом

В Беларуси почти 65 тысяч выявленных случаев заболевания коронавирусом

«Высказывайтесь от своего лица, а не компании». EPAM написал письмо по поводу выборов
«Высказывайтесь от своего лица, а не компании». EPAM написал письмо по поводу выборов

«Высказывайтесь от своего лица, а не компании». EPAM написал письмо по поводу выборов

38 комментариев
Минздрав подтвердил 64,7 тысячи случаев коронавируса
Минздрав подтвердил 64,7 тысячи случаев коронавируса

Минздрав подтвердил 64,7 тысячи случаев коронавируса

Число выявленных случаев коронавируса в Беларуси выросло до 64,6 тысячи
Число выявленных случаев коронавируса в Беларуси выросло до 64,6 тысячи

Число выявленных случаев коронавируса в Беларуси выросло до 64,6 тысячи

1 комментарий

Обсуждение

sup
sup
22

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

0

Всё так :)

7

"Долгое время не было до конца понятно, чем архитектор отличается от разработчика. У нас в компании матрица с детальным описанием компетенций и навыков выкристаллизовались где-то к 2014 году."

Круг компетенций и задач архитектора был четко обозначен как минимум в 2003 в Rational Unified Process. (Позже многократно закреплен вендорами (тот же SUN, IBM и тп) в различных программах по сертификации архитекторов разного рода. Процессы ЕПАМа, насколько мне известно, строились на базе RUP еще с начала 2000х.
Тот факт, что в рамках конкретной компании из роли сделали должность, придав понятию архитектора свою коннотацию, вряд ли можно считать прорывом.

alex-poklonsky
alex-poklonsky Director, Technology Solutions в EPAM
-3

>>Круг компетенций и задач архитектора был четко обозначен как минимум в 2003 в Rational Unified Process.

какого именно архитектора? Software Architect? System Architect? IT Architect? вы хоть сами понимаете насколько индустрия двинулась вперед после 2003 года? то, что раньше было обозначено, как вы говорите "четко" теперь имеет множество контекстов и трактовок в зависимости от модели бизнеса, контекста итд.

>>в различных программах по сертификации архитекторов разного рода
вы и сами прекрасно знаете что в большинстве случаев практическая польза от этих "программ сертификации" - ноль целых, фиг десятых.

>>Процессы ЕПАМа, насколько мне известно, строились на базе RUP еще с начала 2000х
нет. достоверно вам говорю что это не правда. в каком-то узком контексте, и на небольшом отрезке времени в далеком прошлом - может быть.

>>Тот факт, что в рамках конкретной компании из роли сделали должность
вы начинаете бесконечных холивар "роль" против "должность" при этом сами прекрасно понимаете что единственно верного мнения (а вы свое мнение подаете как единственно верное) - не может быть. то же самое касается должностей Scrum Master, Dev Ops Engineer итд.

9

хм... я просто мимо проходил, но вот это "вы и сами прекрасно понимаете" - это какая-то джеди-техника нлп, которой в ипаме обучают?
Не по себе как-то, когда пишут/говорят, что я и сам прекрасно понимаю и дальше дописывают, что именно:)

alex-poklonsky
alex-poklonsky Director, Technology Solutions в EPAM
-2

>>это какая-то джеди-техника нлп, которой в ипаме обучают?
не обучают, а зомбируют! вы же прекрасно это сами понимаете!!11 :)

1

> какого именно архитектора?
- Укрупненно цели и задачи у любого архитектора одни и те же. Вариации появляются в зависимости от масштаба/сложности/специфики задачи.
А тот факт, что в этой должности сейчас связали части ролей PM, Sales, BA, Software/System Architect может даже UX, - частный случай реорганизации внутренних процессов.

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

> нет. достоверно вам говорю что это не правда.
- Даже все шаблоны документов были на базе RUPовских - уточните у старожилов. (И это не укол. А совсем наоборот - в то время компания была эталоном для *всех* участников бел. рынка как минимум в плане построения процессов.)

Я не за холивар. Просто мне показалось, что весь текст - ПР чистой воды с попыткой придать эзотеричность и новый смысл давно известным понятиям.

alex-poklonsky
alex-poklonsky Director, Technology Solutions в EPAM
-1

вы так говорите как будто другого какого-то мнения быть не может. особенно что касается частных или общих случаев. на западе во многих местах роль и должность Solution Architect вполне понятна и определена. это не какое-то нововведение/прорыв компании EPAM, как вы тут пытались показать.
RUP Крючтена в свое время был неплохой методологией, которая давала определенную целостную точку зрения на разработку софта. Но ответов на все вопросы она не давала. А на те, на которые давала - были и другие точки зрения. И почему-то RUP сегодня мало где используется, хотя ее элементы (например сама итеративность, которая заложена в базу) успешно работают на практике и присутствуют в других методологиях.
по программам сертификации и связи со стимулом к изучению - спорно. связь со стимулом к изучению есть только тогда, когда новый работодатель требует сертификат. связь со стандартизацией отрасли есть, согласен.
>> Даже все шаблоны документов были на базе RUPовских - уточните у старожилов.
да что мне уточнять, я все это прекрасно знаю и помню. но
1) даже когда эти документы были ими почти никто не пользовался
2) от них очень давно ушли. уж поверьте. очень. давно. (конкретный срок называть не буду а то еще нарушу какие NDA)
так что не стоит выпячивать свое мнение как единственно верное т.к. очевидно что точек зрения на такой вопрос больше одной а некоторые сведения предоставленные вами недостоверны.
никакого пиара. при чем тут это.

2

Похоже, мы потеряли нить разговора или уж точно сместили акценты.
Изначально я взял цитату, в которой меня позабавило, что долгое время не было понятно (чуть ли не до 10х годов), кто такой архитектор и чем он отличается от разработчика, и уж тем более, что архитектуру пилили "всем аулом" ибо не было такой роли-должности-компетенции.
Я высказался на сей счет, тк тоже посчитал сведения героя статьи недостоверными. Ну и решил вот выпятить свое мнение, чтобы обозначить существование плюрализма.

Вот Вы уже согласились, что все же были шаблоны, а мгновение назад говорили, что это неправда :)

Ну а почему ПР - тк субъективно в заметке - 0 новой полезной информации или опыта, который можно было бы перенять, зато много всего остального.

alex-poklonsky
alex-poklonsky Director, Technology Solutions в EPAM
0

>>Вот Вы уже согласились, что все же были шаблоны, а мгновение назад говорили, что это неправда :)
нет. я говорил другое. не переворачивайте. и вообще "процессы ЕПАМа", как они выглядят сегодня и как они строились и на основе чего - это отдельная обширная тема которую вы подали в крайне узком, вырванном из контекста аспекте. лично мне вообще не кажется что RUP сыграл сколь либо значимую роль в тех разухабистых и высоко детализированных процессах компании, которые мы можем наблюдать сегодня и которые формировались очень долгое вермя. Могу лишь повторить что было сказано мной ранее:

">>Процессы ЕПАМа, насколько мне известно, строились на базе RUP еще с начала 2000х
нет. достоверно вам говорю что это не правда. в каком-то узком контексте, и на небольшом отрезке времени в далеком прошлом - может быть."
про ПР я воспринял на свой счет. ок, ошибся, извините. Раунд :)

2

Дабы поставить точку над "и". -

Я не обсуждаю процессы ЕПАМа в принципе.
Мысль была в том, что понятие архитектора было определено еще в 2000х, как минимум RUPом, который широко применялся в организации. Что противоречит цитате героя статьи.

Ок. Принято. И спасибо за диалог.

1

Я сам официально кличусь архитектором, но до сих пор не понимаю разницы между Software, System, IT, Solution и т.д. Вроде же всё в реальной жизни просто, архитектор и архитектор.

ade
ade
20

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

itch
itch Process Manager в EPAM
-10

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

7

Штаны то надеюсь у этих уровней разного цвета? А то ведь : "Когда у общества нет цветовой дифференциации штанов, то нет цели! А когда нет цели — нет будущего!" )))

14

Скоро будет так: "Петя, Эльф 40 уровня в EPAM"
Или по примеру SMM: "Вася, Бриллиантовый Амбассадор в Wargaming"

3

Шутки шутками, а в Microsoft разработчики начинают с Level 59 - жаль нет префикса "эльф". https://www.levels.fyi/?compare=Microsoft,Facebook,Google&track=Software%20Engineer по ссылке кстати понятно что многоступенчатая схема - это норма для всех больших компаний).

0

А ведь ещё ж есть Chief Software Engineer (в чем отличие от SA?) и Delivery Manager (не путать с Project Manager!)
Чтоб скучно не было

Dzmitry Martavoi
Dzmitry Martavoi Lead Software Engineer в IDT Belarus
17

> От архитектора 1-го уровня мы ожидаем, что у него будет пару технологических стеков: например, опыт работы на C#, опыт работы c front-end. На 2-м уровне специалист будет знать Microsoft Azure — первый облачный стек. На третьем — Amazon WS. Уже два облачных стека.

А на последнем уровне архитектор будет знаком с Terraform и Jenkins для развертывания своих поделок. Итого получился более-менее опытный Senior в любой продуктовой компании / стартапе.

Александр Флахбарт
Александр Флахбарт программист в BELHARD
2

Какой-то эникей-архитектор получается на выходе - и пресейл и демонстратор-коммуникатор и пиэм и ещё в код потом посмотреть.

Anonymous
Anonymous
0

Широкий профиль. Гуд.

3

После прочтения статьи я только сильнее убедился во мнении, что технические чуваки в Епаме делятся на две основные категории:
- те, кому вообще все пофиг, лишь бы погонщик не бил, и ипотеку удавалось выплачивать;
- те, кто искренне восхищается энтерпрайзом.

agentcooper
agentcooper PM в SK hynix memory solutions Eastern Europe
6

"Меня собеседовали 6 директоров и вице-президент"
Собеседование архитектора в ЕПАМе:
http://lozhki.net/matrix/other/gluk/m2/stuns.jpg

5

хм, ожидал другую картинку увидеть

2

Главное что не вице-президент земли собесил а так бы не прошел.

4

Ничего против ЭПАМа не имею (сам там не работал). Но судя по таким статьям и рассказам людей, несёт чудовищной бюрократией.

alex-poklonsky
alex-poklonsky Director, Technology Solutions в EPAM
2

вот по-честноку - а что вы ожидали? да, бюрократия, можно и так назвать. а как иначе в компании с 30 тыс сотрудников и кучей офисов в куче стран? плоская структура и легковесные процессы вида "сходи к CEO спроси"? дану бросьте, снимите розовые очки. скажу по-секрету, у меня вот N лет назад была стойкая аллергия на "нужные процессы", "матрицы-шматрицы", "левелы" и проч. но как-то со временем пришло принятие того, что иначе контора бы просто разломалась под собственным весом, был бы бардачище и хаос "я тут местный князёк в своей песочнице, сижу что хочу то и ворочу". все не так уж плохо.
за, как вы тут выразились, чудовищной бюрократией вэлкам в банки, госучреждения, проекты на милитари сектор итд.

15

> Senior Solution Architect в EPAM
У вас уровень в подписи не стоит, непонятно - круче вы архитектора 4лвла или нет :\

alex-poklonsky
alex-poklonsky Director, Technology Solutions в EPAM
-3

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

1

Среди не-senior архитекторов есть мнение что в бесконечном цикле stack overflow не случится, разве что в бесконечной рекурсии :p

14

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

1

Solution Architecture School - сюда можно попасть только будучи сотрудником EPAM? Или людей с "улицы" тоже берете? Что используется для описания (документирования) архитектуры? 4+1 views?

0

Для описания архитектуры используется в первую очередь моск. Даже в епаме.
А так можете хоть камушками на стекле выкладывать.

Чем более "mature" нотацию выберете - тем хуже. Вас будут меньше понимать разработчики, и вы будете больше увлекаться своей должностью, а не тем что приносит пользу окружающим вас людям (Архитектор это все таки servant роль)

2

Спасибо за статью!

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

Должность Solutions Architect чаще всего вводится в компаниях, где разрабатывается свой технический продукт, который требует навыков при внедрении. Солюшн архитект чаще всего приписан к сейлз департменту и работает с клиентами - консультирует и помогает внедрить продукт. Также много солюшн архитектов в консультационных и аутсорсинг компаниях, где они фактически отвечают за техническую часть проекта. Иногда эта роль включает в себя пресейл общение с кастомерам, но также бывают роли пресейл инженеров, а солюшн архитект вводится на этапе имплементации.

Максим  Гулевич
Максим Гулевич Дизайнер в EPAM
2

"Пойду кипяточка заварю", — хочется ответить мне, Design Management Level 4 - специалисту.

Михаил Дубаков
Михаил Дубаков Writer в Fibery
2

В иерархии не хватает тайтла Junior Solution Architect

1

Видимо не только вам пришла в голову такая мысль :)
Я работал в компании где была позиция Junior Software Architect.
А в еще одной был Junior Project Manager.

1

Вы удивитесь, но позицию Junior Project Manager сейчас вижу всё чаще. Берут вообще без опыта в IT.

Kickey Kohen
Kickey Kohen epamovec в EPAM
-1

не знаю даже кому из вас троих ответить...Junior SA , А ЧТО В ЭТОМ ТАКОГО ???

1

в крупных компаниях роль архитектора выполняют сеньоры и принципалы - они помогают девелоперам дотягивать дизайны до уровня. Такая должность как архитектор, есть только в бодишопах - там где пишут девелоперам опыт 5 лет, а в действительности там и 0.5 нет. Вот и приходится выдавать таким девелоперам сверху готовый дизайн на блюдечке. Иначе будет полный fail

Kickey Kohen
Kickey Kohen epamovec в EPAM
1

почему у всех горит от 5 левелов я не понимаю ааааа ... ну неужели 10 балльная система в образовании хуже 5тибальной. я вообще хейчу всех старпёров которые ныли что 10 баллов это "что-то непонятное" , вот было у нас в СССР оценка уд, неуд, хорошо, отлично .. и жили прекрасно ...
Так вот вы сейчас точно также ноете... Чего плохого в идентификации кого-либо хоть на 5, хоть на 80 уровней, если они все чётко прописаны что где требуется... ( ладно они нечётко прописаны в ерам по моему мнению, потому что невозможно нормально классифицировать любыми метриками владение aws или azure`ом например, но эта система хоть и не идеальна но лучше работает чем "ничего" в этих ваших обычных компаниях где всё тоже самое но называют не 3ий уровень а сеньёр... другое дело что 3ий уровень епама не всегда соответствует любому сеньёру не из епама, но это только потому что в епаме все более детально дифференцировано, нежели в компании без этих особенностей,
мне кажется 5 левелов это всегда WIN-WIN для компании и для человек когда у него нету сильно завышенного мнения о себе, когда он адекватно оценивает свои умения а не "сеньёр в 23"

0

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

0

А где заявленный в заголовке список книг?

0

Насколько я помню, книги рекомендованные епамом:
Software Architecture in Practice
Documenting Software Architectures: Views and Beyond

Имхо, устаревший подход оторванный от реальности. Но помогает пройти интервью/ получить промоушен на епаме.

А вот это толковая книга: 12 Essential Skills for Software Architects.
Не техническая, больше про expected behavior and soft skills.

Dmitriy  Gurskiy
Dmitriy Gurskiy Lead Solution Architect в EPAM
0

Список книг добавили в конце статьи:
1. Software Architecture in Practice (3rd Edition)
2. Designing Software Architectures: A Practical Approach (SEI Series in Software Engineering) 1st Edition
3. Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspective
4. DevOps: A Software Architect’s Perspective (SEI Series in Software Engineering)
5. Implementing Domain-Driven Design

1

Как бывший епамовский solution architect ныне проживающий в Сан Франциско не могу не вставить 5 копеек.
1. В инженерных компаниях (Google, Facebook, Amazon etc) в инженерных отделах НЕТ solution architects. А есть они в Sales!
2. В enterprise компаниях есть не Solution, но Enterprise Architects. На епаме такой позиции 2 года назад не было, что конечно в моем случае вызывало путаницу и отказ в промоушене.
3. Наличие Solution Architect в резюме мне ПОМЕШАЛО искать инженерную (не sales) позицию после расставания с епамом.
4. Имхо, тому чему учат в Solution Architect School/University в епаме очень сильно оторвано от реальности (вроде именно Дима и задизайнил программы обучения). Они помешаны на quality attributes. Ну честно, ну не используют в силиконовой долине этот термин. И заказчики не понимают. Книга, на основе которой было построено обучение была выпущена в 1997году!

Dmitriy  Gurskiy
Dmitriy Gurskiy Lead Solution Architect в EPAM
0

:) Прокомментирую по порядку:

>>1. В инженерных компаниях (Google, Facebook, Amazon etc) в инженерных
>>отделах НЕТ solution architects. А есть они в Sales!

Мы когда формулировали для себя кто такой архитектор, изучали как крупные компании описывают эту роль.
Вот мнение IBM: http://www.ibm.com/developerworks/rational/library/mar06/eeles/index.html
Вот мнение Microsoft: https://docs.microsoft.com/en-us/previous-versions/cc505968(v=msdn.10)#architect-roles

Прочтите эти ссылки. Они описывают вполне правильного hands-on инженера, расширяя требования к его навыкам и умениям в сторону понимания бизнеса. :) Так что, с вашим утверждением сложно согласиться. Solution Architect есть много где. Где-то эту роль используют и в помощь Sales/Account Manager'ам, что правильно. Продавать надо выверенное техническое решение.

>>2. В enterprise компаниях есть не Solution, но Enterprise Architects. На епаме
>> такой позиции 2 года назад не было, что
>>конечно в моем случае вызывало путаницу и отказ в промоушене.

Не очень понятно, что такое "enterprise компания". Касательно EPAM - у нас есть должность Enterprise Architect, есть к ней описание требований, есть community. Страницы в нашем Confluence, описывающие все что касается этой должности, были созданы как я вижу, в еще в мае 2015-го года, 4 года назад. Так что, даже не знаю как прокомментировать ваше утверждение. :)

>>3. Наличие Solution Architect в резюме мне ПОМЕШАЛО искать инженерную
>> (не sales) позицию после расставания с епамом.

Могу лишь выразить сожаление. Для примера скажу, что бельгийская компания-заказчик на моем текущем проекте, ищет как раз себе в один из отделов именно Solution Architect'а (привлекая нас к собеседованиям кандидатов), и это ни разу не Sales. И несколько их архитекторов в штате также официально называются Solution Architect и это такие же hands-on ребята как и в EPAM.

>>4. Имхо, тому чему учат в Solution Architect School/University в епаме
>> очень сильно оторвано от реальности (вроде именно Дима и задизайнил
>> программы обучения). Они помешаны на quality attributes. Ну честно, ну не
>> используют в силиконовой долине этот термин. И заказчики не понимают.
>>Книга, на основе которой было построено обучение была выпущена в 1997году!

В Solution Architecture University у нас 2 трека, по три курса в каждом (все они основаны на очень разных книгах и курсах). В первом курсе первого трека мы действительно делаем акцент на материалах от Software Engineering Institute. И там системное управление качеством решений действительно в основе одного из тренингов. И это очень правильно - проектировать решение, выбирать библиотеки/фреймворки/и т.д., выполнять развертывание, выстроить CI/CD с правильными quality gates можно тольно точно понимая, какие quality attributes критичны для вашего решения и каковы конкретные метрики для них. Американский Chief Architect на стороны WoltersKluwer на моем прошлом проекте, для примера, как и архитекторы заказчика на моем текущем бельгийском проекте, прекрасно знакомы с концепцией quality attributes и активно их используют.

Что касается книги (а речь идет о "Software Architecture in Practice, 3rd edition" - https://www.amazon.com/Software-Architecture-Practice-Edition-Engineering/dp/0321815734 ), то у вас неверная информация. Ее первое издание действительно имело место быть в 1997 году. Мы же опираемся на 3-е издание (вышло в свет в 2012-м), которое от 2-го издания отличается очень сильно (не говоря уже о первом, на которое указываете вы).

С уважением, Дмитрий.

0

И ноль упоминаний про разницу зарплат по уровням, наверное все работают за идею?

0

Блаблабла... сколько платят в баксах?

0

Мало, но что-то там про акции было :/

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже