×

Карьера в IT: должность Software Architect

Данная статья — вторая из серии «Карьера в IT», в каждом выпуске которой мы рассматриваем одну из должностей в сфере разработки ПО. В этой части обсудим высшую ступеньку непосредственно программистской карьеры в IT — Software Architect.

Software Architect — это IT-специалист, принимающий решения относительно внутреннего устройства и внешних интерфейсов программного комплекса с учётом проектных требований и имеющихся ресурсов.

По статистике ДОУ, среднему украинскому архитектору 30 лет, он имеет 9-летний опыт работы и получает $4000.

Задачи и обязанности

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

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

В обязанности архитектора входит:
— Проектирование системы на основе требований заказчика;
— Определение архитектуры приложения или ее эволюции;
— Выбор технологии для каждого звена системы;
— Выбор способов взаимодействия между компонентами системы;
— Создание рабочего прототипа;
— Дизайн интерфейсов и компонентов приложения;
— Подбор или проектирование фреймворков;
— Анализ и исправление проблем производительности;
— Архитектурное ревью бизнес-требований;
— Ревью кода и дизайна при больших изменениях;
— Рефакторинг кода;
— Написание и поддержка стандартов кодирования, каталогов проектных паттернов и антипаттернов;
— Документирование всех архитектурных решений, постоянное обновление документации;
— Риск-менеджмент;
— Координирование архитектуры на протяжении последующего жизненного цикла ПО;
— Обучение и консультирование программистов.

«Архитектор ПО ничем не отличаются от других Архитекторов, которые строят мосты или дома. Приложение — это тоже строение: ему нужен правильный фундамент и сильные решения. Стоя под мостом во время проверки нагрузкой, нужно быть уверенным, что он не рухнет».

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

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

Кроме этого, от архитектора ожидается глубокое понимание предметной области бизнеса, знание основных стандартов и трендов, связанных с разрабатываемым продуктом. Или, если от противного, — незнание специалистом каких-либо бизнес-деталей, необходимых для проектирования, не может служить оправданием неспособности архитектора выполнить свою работу.

«Без знания предметной области ты остаешься на уровне сеньора. Чем больше ты понимаешь язык бизнеса, тем ты ценнее».

Еще одна особенность должности архитектора связана с необходимостью искать компромиссы. В каждом проекте фигурирует большое количество заинтересованных лиц (стейкхолдеров):
— Заказчик — заинтересован в решении проблемы, в минимизации стоимости решения, в однообразии всех технических решений, простоте их использования и поддержания;
— Топ-менеджмент — в максимизации прибыли;
— Менеджмент проекта — в своевременном и качественном выполнении проекта;
— Члены проектной команды всех ролей и специальностей — в интересной, комфортной работе, отсутствии давления, использовании удобных и современных инструментов и технологий.

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

«Умение выбрать оптимальное решение вместо лучшего — вот основная задача архитектора».

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

«Я занимаюсь не столько реализацией конкретных фич игры, сколько придумыванием того, как они должны быть реализованы вообще и каким будет их взаимодействие друг с другом. Например, при разработке игры от меня требуется выбрать технологии реализации клиента и сервера, выбрать способ коммуникации между ними, определиться, какие операции следует реализовать на клиенте, а какие — на сервере, и как все это будет храниться в базе. В мои обязанности входит работа над движком игры — как реализовать это всё, чтобы оно было легко переносимо и работало как можно быстрее. Допустим, наша новая игра дает всего лишь 4-5 FPS на первом iPad. Во всем виноват рендер, который должен отсортировать и нарисовать множество объектов. Моя задача: придумать более производительный алгоритм и реализовать его. Задача программистов: прикрутить его к конкретным проектам».

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

«Всегда нужно быть готовым к переключению между задачами — это норма для архитектора».

Достоинства и недостатки

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

«Работая архитектором, я занимаюсь тем, что люблю — решаю сложные инженерные задачи, которые делают мир технологий лучше».

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

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

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

«Иногда хочется просто программировать, а не решать вопросы вселенского масштаба о взаимодействии и принимать решения по снижению зависимости между частями каких-то систем. Например, написать код, реализовать какой-то алгоритм и отладить его. Скажу по секрету, иногда удается отбить у разработчиков интересную задачу!».

«Труд архитектора иногда менее заметен пользователями и менеджерами, чем труд разработчика. Последний добавил кнопку — пользователь рад, так как давно ее ждал. Архитектор сделал рефакторинг — программисты сказали „ОК“. Меньше откликов от конечных пользователей».

Как стать архитектором и куда идти дальше?

Должность архитектора является следующим этапом развития Senior/Lead-инженера, который не хочет уходить в менеджмент и отдаляться от технических задач.

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

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

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

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

Согласно данным IASA, результаты опроса, в ходе которого архитекторов со всего мира просили оценить важность того или иного качества/умения в успешной работе, выглядят следующим образом:

Самые важные качества/навыки по категориям (по убыванию):

Human Dynamics:
— Collaboration and Negotiation
— Presentation Skill
— Leadership and Management

IT Environment:
— Platforms and Frameworks
— Application Development
— General IT Skills

Business Technology Strategy:
— Technology Strategy Development
— Requirements Discovery and Constraints Analysis
— Business Fundamentals

Design Skills:
— Architectural Description
— Design Analysis and Testing
— Decomposition and Reuse
— Design Methodologies and Processes

Quality Attributes:
— Reliability, Availability, Scalability
— Extensibility and Flexibility
— Security

«Быть архитектором — это работать, а не просто отрабатывать получаемую зп».

«Программист становится программистом не тогда, когда начинает писать работающий код, а когда начинает думать как программист. Это просто склад ума и характера — либо ты мыслишь как архитектор (или программист), либо нет».

Практические советы:

«Нужно побольше работать над своими проектами в свободное время. Единственный способ стать архитектором — начать создавать архитектуры. Со временем начнет получаться. Еще через время начнет получаться хорошо. Когда у тебя уже готово 90% проекта, а ты внезапно осознаешь, что реализация оставшихся десяти займет больше времени и породит кучу костылей, и это проще переписать заново, чем закончить, то в будущем будешь уже продумывать все наперед. Правда тут тоже стоит меру знать. Желая сделать все идеально, можно и вовсе ни одного проекта не доделать».

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

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

Перспективы карьерного развития архитектора имеют 2 ракурса: либо углубление в техническую часть и развитие «от маленьких систем к enterprise и управлению космическими кораблями в масштабах вселенной», либо переход в менеджмент на позицию СТО или VP of Engineering. Фактически архитектор — это финальный этап технического карьерного роста.

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

С точки зрения профессионального роста можно выделить следующие направления:
— Рост в размере и сложности решаемых проблем;
— Развитие в «ширину» — изучение большего количества технологий, процессов и методологий, инструментов, архитектурных подходов;
— Развитие знаний в предметной области — «Людей, которые могут кодить в мире технологических компаний — пруд пруди, и их не ценят. А те, кто может кодить в биологии, медицине, политике, социологии, физике, истории, математике — уважаемые люди, способные делать удивительные вещи для развития своих дисциплин». (Zed. A. Shaw)

«О перспективах этой профессии на рынке Украины могу сказать, что для Software Architect все только начинается. Судя по опыту предыдущих годов, еще 5 лет назад никто даже не догадывался, что такая профессия есть. Но еще 7 лет назад никто в Украине не понимал, зачем нужно платить за интернет ресурсы и их разработку — как можно заплатить за то, что нельзя пощупать? Точно так же и с архитекторами».


P.S. Отдельное спасибо за помощь в написание статьи Максиму Ковтуну и 18 другим украинским архитекторам, которые поделились с DOU таинствами своей профессии. Приведенные в статье цитаты взяты из их рассказов.



Остальные статьи цикла:
Карьера в IT: должность Team Lead
Карьера в IT: должность Project Manager
Карьера в IT: должность CTO
Карьера в IT: должность QA engineer
Карьера в IT: должность QA Automation engineer
Карьера в IT: должность Бизнес-аналитик
Карьера в IT: должность Системный администратор
Карьера в IT: должность Data Scientist / Machine Learning Engineer
Карьера в IT: должность Technical Writer
Карьера в IT: должность Delivery Manager
Карьера в IT: должность Software Product Manager

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному4
LinkedIn

Схожі статті




75 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Интересно в чем принципиальная разница в рабочем дне с СТО? Я прочитал статью про СТО — dou.ua/...​ta/articles/cto-position
Правильно ли я понял, что в основном в работе с людьми и углублении в бизнес? Но у СТО тоже написаны функции Архитекта, он как бы включает их и расширяет бизнесом и менеджментом.
Т.е. если менеджерить не хочется и все равно под какой бизнес делать решения, т.к. технологии интереснее, чем менеджмент и бизнес, то можно оставаться вечно Архитектом (он же Staff, Principal, Expert в других компаниях) и это тупик тех. равития?
А по ЗП будет сильно отставать от СТО или VP? Менеджерам обычно платят больше, или я не прав?
Надеюсь кто-то ответит.

ни слова про системную инженерию, оценки, риски, пресейлы....

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

отсюда уже и сама работа. работой архитектора является задание и удержание баланса (системы).

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

но «учебника по балансу» не существует, поэтому работа архитектора это как бы интегральная роль в айти-индустрии.

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

....ценность архитектора обратно пропорциональна количеству принимаемых им (или ею) решений... © Мартин Фаулер

т.е. ценность архитектора, не принявшего ни единого решения, абсолютна? зашибись, мнение.
не тот ли этот Мартин Фаулер, который «Архитектура enterprise приложений»?
То есть, область(архитектура) есть, а роли(ибо архитектор — нифига не очередное «звание», а именно роль) — нет?

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

в моем личном понимании архитектура — это инфраструктура(три слоя + лоад балансер + кеширование на одном сервере, чтоб ха ха ха) + стек технологий(PHP4 + MySQL4 во имя Луны) + набор спланированных наперед решений для предполагаемых ситуаций(перейдем на MySQL5, как грохнется база). впрочем, вики считает иначе, можете приобщиться
архитектура — это скорее на вопрос «почему?», а не «как?».
как конституция определяет(должна) законодательство, а product vision — конкретные требования.
не без исключений, возможно.
опять же

Одно правильное решение архитектора — позволяет ему достаточно долго откладывать другие решения об архитектуре, и неправильное — заставляет его принимать остальные не правильные
что вы понимаете под правильными и не правильными? может, соответствующие требованиям и не соответствующие? как, например, выбор sqlite на бекенде в случае, когда явно заявлено(и оплачено) 99% аптайм, как минимум 100 пользователей одновременно и возможность увеличения количества пользователей до 1К за раз.

п.с. если будете помидоры бросать, прошу, приводите аргументы.

[UPD]

Одно правильное решение архитектора — позволяет ему достаточно долго откладывать другие решения об архитектуре, и неправильное — заставляет его принимать остальные не правильные
а тру-разработчик пишет один раз, не допускает багов, читает мысли и видит будущее, муа-ха-ха :)

Евгений, я не совсем понял про му-ха-ха, но все что вы описали может принять и команда. Зачем вам нужен архитектор? Что вы от него ожидаете?

но все что вы описали может принять и команда
нет. не команда. прямая демократия не работает: в итоге будет выбрана наиболее популярная технология, с которой «комфортно» всем участникам. наиболее простая архитектура. и прогнозы развития сведутся до «а че, потом памяти добавим, если будет тормозить».
отвечать за эту штуку должен один человек. обсуждать можно и вместе. но один человек принимает решение и отвечает за него. «отвечают все — отвечает никто».
потому роль должна быть отдельная. точно так же, как очень важно наличие человека — техлида, чей голос в споре будет решающим.
еще раз — я говорю про роли. активный разработчик команды вполне может взять на себя роль архитектора. и даже вместе с ролью техлида. правда, тогда будет слишком много завязок на одного человека. но, в любом случае, это всего лишь роль.
можно же организовать под архитектора отдельную должность. просто потому что у человека с большим техническим опытом решения будут взвешеннее, а прогнозы — сбывающимися. в таком случае, если у нас есть такой себе технический гуру, распылять его на какой-то багофикс попросту стрелять из пушки по воробьям.
потому архитектор может быть отдельной должностью, под ответственностью которого будет ведение нескольких субпроектов и ответственностью будет сугубо архитектура, без написания кода, продумывания UI и тестирования

PS ну, и полотно же получилось.

, с которой «комфортно» всем участникам. наиболее простая архитектура.
А разве не эта цель нормальной архитектуры — или сложная, никому не известная технология, с которой всем будет сложно работать сделать вашу разработку лучше, команду счастливей, а Вас лично более лояльным к проекту ?
и прогнозы развития сведутся до «а че, потом памяти добавим, если будет тормозить».
Если вы может маштабировать (scalability) просто добавляя планку памяти — считайте, что у вас очень хорошая архитектура.
можно же организовать под архитектора отдельную должность. просто потому что у человека с большим техническим опытом решения будут взвешеннее, а прогнозы — сбывающимися. в таком случае, если у нас есть такой себе технический гуру, распылять его на какой-то багофикс попросту стрелять из пушки по воробьям.
Есть очень хороший курс на PluralSight по архитекторам — я не совсем согласен, но есть разные уровни архитектуры — Application, Solution and Enterprise и на каждом уроне может быть свои требования. То, что вы сейчас описали по сути является ролько Decision Maker — но в данном случае выслушать команду и принять оптимальное решение может и TL, а на уровене Enterprise и PM. Так что отдельная роль архитектора не нужна, а часто бывает и опасна. Потому что архитекторы могут часто жить в каком-то отвлеченном мире, но при этом оказывают реальное влияние не проект, затраты, расходы, сложность итд.
А разве не эта цель нормальной архитектуры
цель архитектуры — соответствовать задаче, её ограничениям и планируемому пути развития.
если
никому не известная технология, с которой всем будет сложно работать
то либо искать нужных специалистов, или менять задачу. делать танк из фанеры только потому что «ребята ж умеют лобзиком работать» — абзац, согласны?
Если вы может маштабировать (scalability) просто добавляя планку памяти
речь о прогнозировании, что «расширим, добавляя планку памяти». как вы могли догадаться, в реальном мире практически никогда не сработает.
То, что вы сейчас описали по сути является ролько Decision Maker — но в данном случае выслушать команду и принять оптимальное решение может и TL, а на уровене Enterprise и PM.
ну, ок. мое понимание терминологии расходится с вашим. и со мнением pluralsight. однако, я свое понимание терминов описал до начала дискуссии. в отличие от.

[UPD] раз разный смысл вкладываем в термины, дискуссию прекращаю — это бессмысленный разговор.

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

На начальной стадии проект задача по построение архитектуры в соответвии с требованиями нужна, но она должна быть настолько простой насколько это возможно — не «нужно планировать метро, если вам просто нужно проложить трубу» верно ? Так и здесь. Архитектура должна быть простой и соответствовать требованиям.

Прогнозирование и планирование также должны подчиняться требованиям, если ваша система работает с одим пользователем и завтра возможно придут 10 и воткнуть планку памяти будет решением, и я бы не заморачивался пока не поступят требования на 100, 1000 пользователей. Не верите, посмотрите как работает StackOverflow — nickcraver.com/...stack-overflow — все базы в оперативной памяти, SSD. И да, это тоже архитектура....

Are You a Software Architect?

The line between software development and software architecture is a tricky one. Some people will tell you that it doesn’t exist and that architecture is simply an extension of the design process undertaken by developers. Others will make out it’s a massive gaping chasm that can only be crossed by lofty developers who believe you must always abstract your abstractions and not get bogged down by those pesky implementation details. As always, there’s a pragmatic balance somewhere in the middle, but it does raise the interesting question of how you move from one to the other.

Some of the key factors that are often used to differentiate software architecture from software design and development include an increase in scale, an increase in the level of abstraction and an increase in the significance of making the right design decisions. Software architecture is all about having a holistic view and seeing the bigger picture to understand how the software system works as a whole. While this may help to differentiate software development and software architecture, it doesn’t necessarily help to understand how somebody moves from development into architecture. Furthermore, it also doesn’t help in identifying who will make a good software architect, how you go about finding them if you’re hiring and whether you are a software architect.

www.infoq.com/...tware-architect
Які проекти, програмні комплекси створені за участі українських архітекторів software?
P.S. бо читаючи статті про 23 річних сеньйорів та 30 річних SA мимоволі задаєш питання: “Чому ІТ в Україні в такій ж...?”
Чим відрізняється Systems Architect та Software Architect?

.

Коментар порушує правила спільноти і видалений модераторами.

Тут довольно немного, но толково про архитекторов написано martinfowler.com/...dsArchitect.pdf

Есть и другой способ получать 4000$ — сокращать количество звеньев в пищевой цепи.

— Созданием рабочего прототипа — занимаются разработчики
— Дизайном интерфейсов — занимается (не поверите) дизайнер интерфейсов :-)
— Ревью кода и Рефакторингом — занимается либо тимлид, либо Senior programer.

— Дизайном интерфейсов — занимается (не поверите) дизайнер интерфейсов :-)
Какой-то вы не догадливый архитектор :) Имелся ввиду не дизайн GUI, а дизайн программных интерфейсов (между модулями, например)

Но там же без уточнения было :-)

Ну как сказать... :)

— Дизайн интерфейсов и компонентов приложения
Дизайн интерфейсов (приложения) и компонентов приложения.

Вы, видимо, переутомились на работе :)

Существует как минимум три категории архитекторов, у которых довольно-таки разные уровни полета, разные обязанности и разный маштаб трагедий.
Как вы считаете, должен-ли кодировать архитектор? Если позволите личный вопрос — когда последний раз вы кодировали, писали тесты?

Давно это было :-) как минимум около двух лет назад. Но написанием кода я занимаюсь с 1988 года :-). Так что написал его достаточное количество, уж поверьте :-) и не на 1 языке :-)

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

+1
Архитект в стиле Agile — держит руку на пульсе, и не просто следит за соблюдением архитектуры (architecture enforcing), сколько отслеживает изменения в архитектуре по мере исполнения проекта.

Фаулер и Бек пишут код. И начали они писать раньше 1988. Так что не аргумент.

Статья конечно хорошая, но есть несколько непонятных мест:
Откуда вдруг выяснилось, что архитектор занимается:


— Создание рабочего прототипа;
— Дизайн интерфейсов.....;
— Ревью кода.......;
— Рефакторинг кода;
Вопрос к авторам статьи :-)

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

Всё правильно.

— Создание рабочего прототипа
Самый интимный момент проекта, этап зачатия и рождения. Потом всё — банально.
— Дизайн интерфейсов
Имеются в виду не GUI, а взаимосвязи между составными частями системы, и это — чуть ли не самая важная часть архитектуры.
— Ревью кода
Если архитект не участвует в ревю — то это именно тот самый Ivory Tower Architect, нехороший человек. ;)
— Рефакторинг кода
Архитект, как никто другой, если он конечно вообще знает что делает, понимает важность рифакторинга, потому что правильная архитектура — это здоровье проекта в общем.
Целью статьи было создать наиболее близкий к реальности обобщенный портрет. :)
Получился портрет архитекта из идеального мира... :)

Продолжу роль адвоката автора... :)

— Создание рабочего прототипа;
«Создание» — это не обязательно кодирование. Редко когда архитектор не принимает участия в решении о том, что войдет в протоип и дизайне прототипа (программный дизайн :))
— Дизайн интерфейсов
Это уже выяснили — программные интерфейсы.
— Ревью кода
90% архитекторов ревьюируют код, причем много кода. Возможно вы не входите в эти 90%.
— Рефакторинг кода;
Как и с прототипом — не обязательно, конечно архитектор будет кодировать, но решение о необходимости рефакторинга и о том что же и как мы рефакторим, не должно проходить мимо архитектора. Это его обязанность.

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

По-моему, этим занимается синьор.

Классная статья! Про какую профессию следующая статья? Можно про PM или QA?

Спасибо.)
По плану PM, потом СТО, потом QA.

Буду ждать СТО — самая неоднозначная роль. Предвкушаю массу комментариев

Отличная статья. Некогда что-то подобное, только менее систематизированное, проскакивало в голове, когда думал расти в Test Automation Architect

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

P.S. Писать код по ночам это очевидный ответ, но вот даже у архитекторов есть личная жизнь.

А зачем архитектору

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

Я понимаю. Но если ты перестал писать код, а только клепаешь UML и максимум пишешь интерфейсы классов — легко превратится в теоретика, который витает в облаках и не видит насущных проблем кода.

Как архитектор, не держащий руку на пульсе, может прийти на чужой легаси-проект и начать его разруливать? Не все же проекты приходится писать с нуля.

Скажу по секрету, иногда удается отбить у разработчиков интересную задачу!".
— как раз для вас:)

А что такое «практические навыки написания кода»? Понимается ли под «написанием кода» решение задачи или получив на руки готовое решение набрать соответствующий код для его имплементации? Это знание подходов к решению задач, к анализу и построению аглоритмов, методов и паттернов проектирования и т.п. или скорость набора текста и знания названия классов и методов в Nном количестве фреймворков?
Если все-таки это решение задачи — то разве можно потерять этот навык? :) Это как умение ездить на велосипеде. К тому же архитектор не перестает решать задачи.

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

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

Люблю кодировать и пару лет назад тоже рьяно считал, что архитектор, не пишущий код, — совершенно бесполезный персонаж. Реальность же оказалась немного другая.
Когда у тебя есть достаточно полномочий, чтобы распределять свое время между задачами разного плана, регулярно встает вопрос, написать это самому или отдать другим. Если думаешь написать самому, возникает другой вопрос: а не могу ли я потратить время с большей пользой? В 99% случаях почему-то оказывается, что есть много задач, где от меня пользы больше, чем от кого-либо другого. Архитектор, имхо, это не «самый крутой программист», а человек с широким системным видением.
Работа в Штатах с архитекторами продуктовых компаний только укрепила меня в этом мнении. И да, архитектор архитектору рознь — везде понимание немного разное и во многом определяется личностью.

Как архитекторы в Штатах и вы лично расширяете кругозор? Чтения о новых технологиях и чужом опыте достаточно? А если приходится годами вариться в одной и той же архитектуре — откуда получать новый опыт? (Имеется в виду опыт построения архитектур, а не кодирования)

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

Трудно сказать, хорошо то или плохо другое. Так есть — это разные подходы и по сути разные миры.

Ну не по ночам, а по субботам.
Знаю лично одного партнера (директора-соучредителя) в одной очень крутой консалтинговой компании, который по субботам пишет библиотеку для quantitative finance, причем это не просто хобби, библиотека нехило продается.

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

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

Все, расти некуда, пора на пенсию :)

Ну так же

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

Рост внутри одной роли — это уже старость :)

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

p.s. Что самое неприятное в ведении своего бизнеса?

В этом случае я пошутил, конечно.
Ну а самое неприятное, как и в любом бизнесе — иметь дело с государством...

взаємодія бізнесу та держави — велике і багатогранне питання, яке варто висвітлити у статті як мінімум

Спасибо за статью! Отлично все разложено по полочкам :)

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

который не может уволится
Уволиться то он может... Правда после чего и выясняется, кто таки был таки архитектором.
По моему небольшому опыту архитектурой так или иначе занимается вся команда, и каждый немного архитектор.
По моему большому опыту — это рецепт эпик фейла: Все знают по немногу свой огород, а систему в целом не знает никто. И с этого момента система начинает строится на костылях, хаках и воркараундах — «Я что-то сделал, не знаю что, но оно работает!». :)

А что тогда скажите на счет колективного владения кодом которое предполагается в рамках ХР ?

Коллективное владение помогает снизить этот риск, но одного его мало — чтобы работал подход

архитектурой так или иначе занимается вся команда

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

Это называется job safe programming. Наворачиваешь такого, что потом никто, кроме тебя, не понимает :)

Это один из вариантов, но есть ньюанс: программирование — техническая дисциплина, несмотря на скам и агиле. И «навернуть что-то, противоречащее технической реальности» — чисто технически невозможно. А если возможно: противоречащее существующему уровню тех.реальности, но между тем таки работающее — это уже уровень гуру и это уже совсем другая история.

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

На самом же деле при разумном и рациональном и грамотном управлении даже со стороны полностью технически неграмотного управляющего, но грамотного именно в управлении и построении самоподдерживающихся процессов — в таком окружении «наворотить такого, чтобы никто» уже чисто технически с точки зрения процесса невозможно. И это уже заслуга таки руководителя. Но в реальности — маемо тэ, що маемо, и вместо «руководителя» на руководящие роли по тем или иным причинам выбиваются «насяльника». Причем это одинаково работает что со стороны компании или отдела разработки, что со стороны заказчика или отдела внутри корпорации, для которого ведется эта разработка.

«Умение выбрать оптимальное решение вместо лучшего — вот основная задача архитектора».
— жуткое словоблудие. Оптимальное это и есть лучшее.

Википедия подтверждает: «Оптимальное (от лат. optimus — наилучшее) решение — решение, которое по тем или иным признакам предпочтительнее других.»

Кажется тут уместнее была бы такая формулировка.

Умение выбрать отпимальное решение вместо идеального.

В любом случае никогда не понимал чему конкретно учат подобные фразы

Чтобы окончательно запутать, приведу еще одну общую фразу из той же оперы.

Лучшее — враг хорошего.

Конкретно эта учит прагматизму :)

Это я понимаю. Как и то, что человек, путающий слова «лучшее» и «идеальное», не может ни претендовать на должность software architect, ни пытаться писать о том, что такое software architect.

Умение ясно формулировать свои мысли к сожалению на удивление редко встречается... В том числе у людей занимающих должности, для которых это умение жизненно необходимо.

не может ни претендовать на должность software architect, ни пытаться писать о том, что такое software architect
Если коротко — может.
По существу: ошибка, конечно, досадная — не всем дано писать быстро и правильно. Надо было перечитать сообщение перед отправлением, но приходить к твоим выводам -это преждевременно.

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

Да, согласна, «идеальное» тут уместней, чем «лучшее», но я думаю, большинство читателей поняло, что имелось в виду.

вовремя остановиться
Это как раз глупо. Но характерно.

Есть еще и другой вариант — идеальное решение подразумевает использование нетривиальных / немэйнстримовых технологий, которые в команде никто не знает, а учить некогда

Если понимать «идеальный» как «соответствующий идеалу, безупречный», то можно посмотреть и с такой точки зрения.

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

Тогда это означает что выйдет слишком дорого, есть риск сорвать сроки, ради сомнительной выгоды. Имхо тут надо взвесить все с точки зрения соотношения риск/выгода с одной стороны и затраты/выгода с другой.

Именно! К сожалению, не все новоиспеченные архитекторы это понимают: радость от того, что теперь можно «порулить» и поиграться в любимые технологические игрушки, затмевает способность прагматично мыслить

Підписатись на коментарі