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



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

Чем именно архитектор занимается? Какими навыками должен обладать? Да и как им вообще можно стать?

На наш взгляд, развитие IT-специалиста можно сравнить с классическим мифическим путем героя: победил дракона — стал лидом.

Чтобы узнать, как этот «путь» выглядит в архитектуре ПО, мы пообщались с Анной Мелеховой (AnnaTref), Software Architect & Software Development Group Manager в KasperskyOS — собственной микроядерной операционной системе «Лаборатории Касперского». Мы пройдем путь героя вместе: посмотрим на основные карьерные треки, выявим их особенности и выясним, каких драконов надо победить. Поехали!



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

Подготовка: Choose your fighter

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

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

Сильные стороны:

• Задел авторитета среди других тимлидов, проджектов и прочих decision maker-ов.
• Сильные хард-скилы.
• Базовое понимание процессов компании.

Слабые стороны:

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

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

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

Сильные стороны:

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

Слабые стороны:

• Возможен недостаток опыта в коммуникации со всей командой.
• Нехватка опыта общения с бизнесом.
• Фрагментарные знания процессов.
• Незнание архитектурных фреймворков.

Менее распространенный вариант — рост с позиции джуниор-архитектора.

В основном речь идет об условном мидле, который внезапно осознал, что кодинг его не особо вдохновляет, — ему гораздо более интересно понимать, как все эти процессы друг с другом взаимодействуют. В то же время этот мидл понимает, что по хард-скилам на классического архитектора он пока не тянет. Тогда вместо хрестоматийного пути (мидл — сениор — [тимлид] — архитектор) он может сразу встать на позицию junior architect.

Сильные стороны:

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

Слабые стороны:

• Отсутствие задела уважения и репутации в команде.
• Из-за слабого технического бэкграунда собрать цельную картину будет совсем сложно.
• Незнание некоторых процессов в компании потребует больше времени на их изучение.

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

Итак, герой выбран — теперь в игру, Ватсон, в игру!

Уровень 1. Копим ману

Что ж, персонаж выбран, самое время выбрать, какую ману ему копить. Но что выбирать, чтобы вырасти максимально быстро — и не прибегнуть при этом к читам и донатам (ибо и осуждаем, и едва ли такое возможно в реальной жизни :))?

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

Не менее важно понимать типичные operations твоей системы, работать с такими функциями, как rollback, бэкап, переконфигурация и другие.

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

Важно уметь декомпозировать задачи, разделять их на конкретные и понятные для команды отрезки. Архитектор должен знать, что такое data- и control-flow-системы, и понимать, как выстраивать их между компонентами.

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

Но как ни странно, значительную часть скилов архитектора составляют «софты»:

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

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

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

● Дзен-гармоничность. Чем дольше ты проектируешь, тем яснее понимаешь, что вообще-то решить одну и ту же задачу можно разными способами. Но приняв одно решение, ты потеряешь другое.

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

Уровень 2. Сhoose your destiny

Ура, скилсет сформирован! Теперь – самое время выбрать тип архитектора, c которым ты и будешь проходить игру.



Quality Attribute architect (security architect, performance architect, availability engineer) Это человек, который отвечает за конкретные качества системы. Например, вы всем коллективом строите кузницу и заботитесь о том, чтобы она была построена в заданный срок. Но должен быть и человек, который отвечает за то, что она в принципе пожаробезопасна. И в его KPI не должно быть мыслей о сроках, он думает только о том, что не должно случиться пожара.

Больше всего подойдет для игроков с прокачанными скиллами: коммуникация, hard skills, знание системы

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

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

Enterprise architect. Этот герой практически не сталкивается с технической работой, но это и не нужно: его основная задача – построение бизнес-стратегий и глобальное планирование. В отличие от, например, quality attribute архитекторов, такой человек редко появляется на каких-то публичных конференциях и митапах – это те самые “серьезные дяди”, которые активно коммуницируют с бизнесом и принимают основные решения. Из-за специфики позиции такие архитекторы не сильно разбираются в технических кишочках (хотя, конечно, бывают исключения). Потому что тут вполне достаточно абстрактного понимания проекта и минимальной опоры на конкретные инструменты.

Больше всего подойдет для игроков с прокачанными навыками: коммуникация, архитектурные фреймворки, дзен-гармоничность
Харизма = + 100 очков к прокачке персонажа

Уровень 3: Дракон неминуем!

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



Фантомная голова, или Голова несостоявшегося проекта
Любому архитектору часто приходится “думать в воздух”. Допустим, тебя просят оценить проект; ты в деталях продумываешь архитектуру, выкатываешь оценку – а оказывается, что заказчик говорит, что готов заплатить вдвое меньше. И…потрачено! Архитектор вложил нервы время и интеллект, но самого результата нет – и уже не будет.

Расфокусированная голова, или Голова-тумблер
Если разработчик в течение года может работать параллельно над двумя-тремя проектами, то архитектору приходится переключаться между таким количеством буквально на протяжении одного созвона.

К тебе может прийти одновременно 15 заказчиков, и при общении с каждым ты должен уметь менять контекст и погружаться в каждый кейс одинаково глубоко. Только что тебе пришла задача по интеграции условного продукта в Amazon cloud, а следом приходит разработчик и начинает спрашивать тебя про flow диаграммы – и все это нужно держать в уме.

Тревожная голова, или Голова-перфекционист
Еще одна большая трагедия для каждого архитектора – тотальная неидеальность.
Полностью подходящего решения не существует. Каждая написанная строка кода, добавление библиотеки, любое изменение конфигурации решает одну проблему, но создает следующую. “Лучшее – враг хорошего”.

Уровень 4: Game Over?!

Вот и все: занавес, фанфары, “directed by”! Но остался бонусный этап – ваше будущее. Надо выбрать, какую игру проходить дальше. И здесь есть несколько вариантов:



Principal Architect. У некоторых больших компаний есть целая иерархия архитекторов, покорению которой можно посвятить целую карьеру! Но даже если такой опции нет, можно просто сменить домен – и вперед!

TechLead/CTO. Ведь архитектор – это еще и про процессы. Так, в security-направлениях есть SDL, в performance ты выбираешь, каким измерениям доверять, а каким нет (то есть тоже строишь процесс). И так далее. Короче говоря, архитектор это всегда методолог, и с таким бэкграундом – стоит только погрузиться в бизнес-часть и пипл-менеджмент – уже можно идти на позицию технического менеджера.

Однако, как говорят истинные ценители хорошего геймдева, по-настоящему понять и прочувствовать игру можно только если ты ее хотя бы раз перепрошел. В общем, нет времени объяснять, жмите кнопку play у нас в “Лаборатории Касперского” :)