Всем привет. Меня зовут Александр Виноградов, я главный архитектор Ви.Tech – ИТ-дочки ВсеИнструменты.ру. Последние 9 лет занимаюсь ИТ-архитектурой и менеджментом в архитектуре, и сегодня бы хотел поделиться с вами своим топом заблуждений про эту самую архитектуру из серии: «если бы мне каждый раз давали рубль, когда я слышу...». 

Кому будет полезна эта статья:

• Тимлидам и РП, которые смогут чуть лучше понять, почему архитектор так долго возится со своими картинками.

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

• Разработчикам, которые считают, что архитекторы занимаются исключительно рисованием квадратиков и стрелочек.

• Самим архитекторам, чтобы почерпнуть дополнительные аргументы для дискуссий с коллегами.

Вы узнаете, что:

• Не существует «правильных» технологий (и postgres не лучше mysql).

• Архитектор не должен писать код (и почему).

• Что покупка коробочных решений не избавляет от проблем.  

Миф 1, или «Ты ж архитектор» 

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

Обсудим сначала первое. К примеру, ваш собеседник может думать, что любой человек с должностью/ролью, в которой есть «архитектор», обязан ответить на очень широкий спектр вопросов. И это будут вопросы от «как построить ИТ‑стратегию» и «как сделать метамодель» до «как настроить вакуум в постгре под какой‑то специфический сценарий».

Но очень важно понимать, что видов архитекторов в разных таксономиях много (обычно 4–7).

Кратко:

• Enterprise Architect (EA, Архитектор предприятия) — работает на уровне стратегии компании, связывает бизнес‑процессы и ИТ.

• Solution Architect — проектирует конкретные решения под задачи бизнеса.

• System/Software Architect — отвечает за проектирование реализации новых и переработки существующих решений. Обычно с фокусом внутрь (команды, приложения, бд) и с фокусом на неФТ.

• Data Architect — проектирует модели данных, потоки данных, гавернанс данных...

А ещё есть:

• Бизнес‑архитекторы — проектируют процессы компании.

• Инфраструктурные архитекторы — отвечают за сети, стойки, облака, отказоустойчивость.

• Security‑архитекторы — проектируют защиту данных.

Резюмируем: важно уточнить, какой набор вопросов хочет решить собеседник и какие компетенции требуются/есть у вас.

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

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

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

И чуть не забыл, в таком раскладе архитектор обязательно становится басфактором==1, что добавляет веселья в общую вакханалию))

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

Миф 2, или «Не трогайте фундамент»

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

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

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

Еще пример: «Это основа архитектуры проекта, его «несущие стены». Их нельзя менять на ходу». Часто — можно) Например, вы строили решение на условном keycloack, а потом решили поменять IAM. Если вы не расширяли кастомом тот же oauth2, то это, как правило, вполне решаемая задача.

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

Миф 3, или «Работает — не трогай»

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

То, что сайт работает на jquery уже 10 лет, совсем не значит, что надо продолжать его развивать на нем же. В этом случае важно учесть, как минимум, два момента.

Во-первых, на экзотические языки/фреймворки/инструменты вы фиг найдете спеца. Например, как-то несколько лет назад одна компания искала перл-разработчика на легаси. Знаете, сколько подходящих резюме они нашли? Два. Нет, лучше так: ДВА!!! И даже если вы кого-то убедите делать именно то, что вам нужно, вы надолго станете заложниками этогоспециалиста. Ведь не факт, что вы найдете второго. А если найдете, то, скорее всего, и стоить он будет в несколько раз дороже современного стека

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

Миф 4, или «И без архитектора справимся»

Есть даже крупные компании, СТО/CIO которых придерживаются такой позиции. Если меня спросят, можно ли так работать, то я отвечу, что, конечно, можно. Эффективно ли это? Не всегда (читай, почти никогда). Проектировщик решений это full‑time job в крупных компаниях. Да, можно совмещать это с пипл менеджментом и деливери менеджментом. И я даже знаю несколько талантливых ребят, которые делают это эффективно. Но на масштабе, когда команд/стримов/трайбов много, обычно получаются такие морские свинки — не имеют отношения ни к морю, ни к свиньям )

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

Мы все почему-то понимаем, что, если ты просишь учителя химии заменить математичку, не факт, что в итоге все ученики сдадут ЕГЭ по математике на хороший балл, а школа получит высокий рейтинг.

В случае с ИТ-архитекторами речь примерно о том же: требуете с аналитика выполнения чужих компетенций? Будьте готовы к тому, что придется переделывать. А к чему это приводит? Правильно. К тому, что ваш проект будет стоить дороже.

Миф 5, или «Технология N лучше технологии M»

Постгрес лучше mysql, го лучше явы, вью лучше реакта и т.п. Часто аргументы в таких спорах не выдерживают никакой критики: «на моей прошлой работе...», «я читал статью/смотрел доклад/был на митапе и там рассказывали...». Вы работаете в конкретной компании, делаете решение для конкретной задачи. Это значит, что помимо значений синтетических тестов, вы должны учесть сразу несколько важных пунктов.

Что будем учитывать:

• Ваши неФТ. Если у вас один рпс в пике, спорить просто неэффективно, берите стандарт компании и юзайте.

• Часто забывают, что ТСО, совокупная стоимость владения, складывается из стоимости создания/внедрения и стоимости поддержки. Если вы хотите расширить техрадар компании новым инструментом, подумайте, какие затраты в сопровождении это принесет. Возможно вам нужно будет нанять DBA, да еще и чтоб бас фактор был >=2. В общем, это может быть дорого.

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

Миф 6, или «Архитектор должен писать код»

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

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

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

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

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

И на десерт то, с чем сталкивался любой архитектор в корп ландшафте:

Миф 7, или «Мы купим проверенное решение и все наши проблемы исчезнут»

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

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

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

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

Итак, вы дочитали этот текст до конца. Теперь давайте подведем итоги.

1. Архитектура — это не про бетон и кирпичи.  В ИТ фундамент можно переложить, и часто это дешевле, чем жить в кривом «здании».

2. Архитектор — это не LLM. Не ждите, что он знает всё: от стратегии компании до настройки вакуума в PostgreSQL. Уточните, какой именно архитектор вам нужен (Enterprise? Solution? Data?)

3. «Работает — не трогай» — часто плохой совет. Если ваш код держится на Perl и jQuery, а единственный специалист по нему уже на пенсии — у вас проблема. Будущее наступит, хотите вы того или нет.

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

5. Нет «лучшей» технологии. Есть «лучшая для вашей задачи». Если команда 10 лет пишет на Java, а вы внедряете Go «потому что быстрее» — готовьтесь к долгому и болезненному переходу и срыву сроков.

6. Архитектору не обязательно кодить. Главное понимать trade-offs, уметь договариваться и не быть социопатом.

7. Купить софт ≠ решить проблему. Если процессы кривые, автоматизированная фигня останется фигнёй, просто теперь она будет еще и в условном SAPе.

Так что в следующий раз, когда вам скажут:

«Да ладно, архитектура — это просто квадратики на доске»,

«Мы же купили CRM, теперь всё будет работать»,

    «Зачем нам архитектор? Пусть тимлид рисует»

просто дайте им ссылку на эту статью.

И, конечно, это далеко не полный список мифов. Когда я готовил эту статью, я их сформулировал более 20. Так что если хотите обсудить эти мифы или те, что не попали в мой топ-7, велкам в комменты )