Who is a Software Architect?

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

Мое сегодняшнее понимание далеко от финала, и вообще я сомневаюсь, что такое понимание в принципе достижимо. Когда все разложено по полочкам, когда все ясно и понятно, когда есть четкие методики и инструкции… Это точно не про программную разработку) Но двигаться в этом направлении определённо стоит.

А еще это возможность сформулировать для себя ориентиры в профессиональном развитии. Чем занимается программист и куда ему расти, я за 20 лет программной разработки более-менее разобрался, а вот с архитектором пока ещё не очень понятно.

Если начинать с определения, то пусть будет такое:

A software architect is a software development expert who makes high-level design choices and tries to enforce technical standards, including software coding standards, tools, and platforms*.

https://en.wikipedia.org/wiki/Software_architect

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

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

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

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

Роль архитектора является комплексной и состоит из нескольких взаимодополняющих субролей.

1. Разработчик

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

Почему так? Потому, что архитектор предлагает решения разработчикам, объясняет, что и как им делать. Как он может это делать, не понимая специфику программной разработки? Да его просто слушать не будут. Варианты типа «ну язык-то я освоил, примерно я понимаю, что они там делают» – работают плохо. В разработке есть масса нюансов, связанных с спецификой бэкенда, фронтенда, фреймворками, языками программирования и т.д. Не испытав их на себе, не пропустив через себя, вы будете для программистов чужаком, самозванцем. Вам могут не сказать это в лицо, но думать так будут обязательно.

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

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

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

2. Стратег

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

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

Я не буду здесь углубляться в эту тему, она весьма обширна и многозначна. Могу порекомендовать свои разработки: «Принципы стратегии», Сунь-Цзы и стратагемы (там же), а также Strateg.org

3. Аналитик

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

Есть такая забавная картинка про программистов:

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

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

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

Есть хорошая методика оценки типов мышления (в том числе и на предрасположенность к аналитическому стилю), рекомендую: Алексеев А.А., Громова Л.А. «Поймите меня правильно».

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

4. Дипломат

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

В основе дипломатии чуткость, терпение и выдержка. Еще это про ЧСВ (чувство собственной важности), а точнее про его отсутствие. Я думаю, что больше всего проблем в общении людей из-за лишней фиксации на себе, но это тема отдельного разговора, и сейчас это обсуждать мы не будем.

У себя на старом сайте выкладывал две хорошие книги по психологии общения: «Гроссмейстер общения» и «Язык разговора», их можно найти здесь: https://chugreev.ru/s-literature.html, может быть, пригодятся.

***

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

Молодой еврейский паренек записывается в еврейскую же армию. Комиссия задает вопрос:

— Представьте, вы в поле. Впереди вас араб. Ваши действия?

— Хватаю автомат и убиваю араба.

— Правильно. Следующая ситуация: вы в поле, впереди вас араб, слева и справа тоже по арабу. Ваши действия?

— Хватаю автомат и убиваю всех.

— Правильно. Такая ситуация: вы в поле, перед вами три араба, сзади тоже три араба, справа/слева опять же по три араба и, еще танк едет. Ваши действия?

— Хватаю автомат и убиваю арабов. Потом бросаю гранату и подрываю танк.

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

— А можно вопрос?

— Можно.

— Я один в еврейской армии???

Архитектор – это не супергерой, который может все. Это человек, который решает ряд специфичных задач, но решает он их не один. Те же самые лидерские и организационные способности вполне могут быть у архитектора, но все-таки это не его профильные скилы. Проще и надежнее обратиться за этим к тимлиду, бизнес-руководителю, скрам-мастеру и т.д.

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

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

Валерий Чугреев, 12.03.2021

Подписаться
Уведомить о
guest
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии