«Архитектор» в программном проекте — понятие расплывчатое. В одних командах это отдельный человек, в других — тимлид по совместительству, в третьих — старший разработчик, которому «вдобавок» дали эту роль. Но за словом стоит конкретный набор обязанностей, которые в любом случае кто-то несёт.
Путаницы добавляет и то, что архитекторы бывают разных видов. Архитектор решения (solution architect) отвечает за одну систему или продукт: как она устроена внутри и с чем связана снаружи. Архитектор предприятия (enterprise architect) смотрит выше — на весь ландшафт компании и на то, как системы стыкуются друг с другом. Архитектор домена отвечает за одну предметную область в крупном ландшафте. Дальше речь только про первого — про человека, который отвечает за устройство одной системы в продуктовой команде; его же обычно и называют software architect.
Разберём обязанности по одной — что это такое, зачем нужно, и что бывает, когда этого нет.
Держать карту системы
Представьте компанию с десятью микросервисами. Через год никто не может с уверенностью ответить: «Кто владеет таблицей пользователей? Какой сервис публикует событие об оплате? Можно ли изменить это поле, не сломав ничего?»
Это значит, что карта системы потеряна. Карта — это не обязательно красивая схема, это ответы на вопросы: кто за что отвечает, кто с кем общается, какие данные где живут.
У такой карты есть устоявшееся имя — context map из предметно-ориентированного проектирования. На ней рисуют не сервисы, а ограниченные контексты (bounded context): участки системы, внутри каждого из которых у слов ровно одно значение и действуют свои правила. И главное на карте — не сами контексты, а связи между ними: кто чьей моделью пользуется, кто кому обязан не ломать контракт, а где стороны сознательно договорились переводить понятия друг друга.
Архитектор отвечает за то, чтобы карта существовала и не устаревала. Без неё каждое следующее решение принимается вслепую.
Принимать архитектурные решения — и записывать их
Монолит или отдельный сервис? Хранить данные в реляционной базе или аналитическом хранилище? Синхронный вызов или очередь? Это развилки, в которых нет универсально правильного ответа — только «правильный для нашей ситуации».
Обязанность архитектора — не «знать ответ», а провести решение по критериям: какой объём данных ожидается, сколько пользователей, какая команда, каков горизонт. Взвесить, выбрать и записать.
Запись называется ADR (Architecture Decision Record). Это короткий документ: контекст, само решение, альтернативы и причины отказа от них. Через год, когда придёт новый человек и спросит «а почему мы так сделали?» — ответ будет в ADR, а не только в голове одного человека.
Когда решения не записывают, они переоткрываются заново. Команда проводит дискуссию, которую уже проводила год назад, и нередко приходит к другому выводу — не потому что изменилось что-то важное, а потому что никто не помнит, почему выбрали именно тот путь.
Проектировать границы сервисов
Один из самых болезненных вопросов в распределённых системах: где заканчивается один сервис и начинается другой?
Если граница проведена неверно, это расползается во всё: лишние вызовы между сервисами, общие базы данных (что делает сервисы зависимыми), путаница в терминах (в одном сервисе это «клиент», в другом — «покупатель», и никто не уверен, одно ли это и то же).
Архитектор решает, где провести границу, и одного критерия тут мало — смотрят сразу на четыре:
- Что меняется вместе. Данные и процессы, которые правятся одним изменением, должны остаться по одну сторону границы. Если каждая доработка требует синхронного релиза двух сервисов — граница проведена не там.
- Единый язык. Внутри границы у слова «заказ» ровно одно значение. Как только выясняется, что в одной части системы «заказ» — это корзина покупателя, а в другой — задание для склада, граница проходит ровно между ними.
- Владение данными. У каждой сущности один хозяин, который её меняет; остальные читают копию или спрашивают у хозяина. Два владельца одного поля — верный признак неверной границы.
- Организация. Границу, которая режет пополам зону ответственности одной команды, будут постоянно перешагивать. У куска системы должна быть команда-владелец.
Это одна из самых дорогих ошибок: неправильная граница обнаруживается поздно и переделывается долго.
Видеть сквозные процессы
Один сервис отвечает за оформление заказа, другой — за склад, третий — за доставку, четвёртый — за уведомления. Но кто отвечает за весь процесс «от нажатия кнопки до посылки у двери»?
Это задача архитектора — видеть процессы, которые пересекают несколько сервисов: где они начинаются, кто что делает на каждом шаге, что происходит при сбое. Если этого нет, каждый сервис знает только про свой кусок, и никто не знает про целое.
Такие процессы нужно описывать явно: кто оркестрирует, как компенсировать ошибку на третьем шаге, когда уведомить пользователя. Без этого сбои становятся неожиданностью.
За этими словами стоят готовые механизмы, и архитектор обязан их различать, потому что выбор между ними — архитектурное решение: сага с компенсирующими действиями вместо распределённой транзакции, оркестрация против координации участниками, таблица исходящих сообщений для надёжной публикации события вместе с изменением данных, идемпотентность получателей, чтобы повтор не создавал дубликат. Разбор каждого — в статье про распределённые паттерны, сравнение подходов к согласованности — в статье про согласованность и консенсус.
Практическая форма описания сквозного процесса, которая работает: одна страница на процесс с таблицей шагов (кто делает, что меняет, что публикует, что делать при отказе этого шага) и одной схемой. Такие страницы лежат там же, где карта, и их первым делом открывают при разборе аварии — потому что авария почти всегда происходит между сервисами, а не внутри.
Оценивать последствия изменений
«Поменяем формат события об оплате» — кого это затронет? Ответ «вроде никого» — начало инцидента.
Архитектор отвечает за то, чтобы такие вопросы имели проверяемый ответ. Для этого нужна та самая карта: зная, кто потребляет событие, можно заранее оценить последствия и принять решение — внести изменение, сделать версионирование или не трогать вовсе.
Без этого изменения выкатываются в продакшн и ломают что-то, о чём никто не подумал. Не потому что разработчики невнимательны — просто без карты невозможно держать в голове все связи большой системы.
Следить за согласованностью
Системы накапливают несоответствия медленно. Один сервис начал называть сущность иначе. Два сервиса объявили себя владельцами одного поля. Спецификации устарели и не соответствуют коду.
По одному случаю это мелочи. Накопившись, они делают карту бесполезной и усложняют работу.
Архитектор периодически проверяет согласованность: терминология единая, владение данными не пересекается, описания актуальны. Это черновая работа, для которой редко находится время, — и поэтому она обычно и не делается, пока не становится слишком больно.
Превращать решения в стандарты
Архитектурное решение, которое нигде не закреплено, живёт два спринта. Договорились, что синхронные вызовы между сервисами — только через отдельный шлюз. Через месяц это правило нарушается, потому что новый разработчик о нём не знал, а старые забыли.
Обязанность архитектора — превращать решения в проверяемые правила: стандарты, соглашения, шаблоны. Правило, которое проверяется при каждом ревью, живёт; правило, которое просто «договорились», нет.
Как устроить такую проверку — отдельная тема: исполняемые инженерные стандарты.
Признаки, что обязанность уже провалена
Все обязанности выше описаны как «надо делать». Полезнее обратный список: по каким наблюдаемым признакам видно, что их не делают. Это то, что можно проверить за час, не будучи архитектором.
| Признак | Какая обязанность провалена |
|---|---|
| На вопрос «кто владеет этой таблицей» разные люди отвечают по-разному | Карта системы |
| Два отчёта о том же показателе расходятся, и никто не знает, какой верный | Владение данными |
| Одно понятие называется по-разному в трёх сервисах («клиент», «покупатель», «пользователь» — про одно и то же) | Согласованность |
| У события нет владельца: непонятно, кто может менять его формат | Владение и контракты |
| На вопрос «кого затронет это изменение» отвечают «вроде никого» | Оценка последствий |
| Решение, принятое полгода назад, нарушается в новом коде, и никто этого не замечает | Превращение решений в правила |
| Сквозной процесс никто не может описать целиком, каждый знает свой кусок | Сквозные процессы |
| На вопрос «почему здесь так» отвечают «исторически» | Записанные решения |
| Один и тот же спор («брать ли этот брокер») возникает третий раз | Записанные решения |
| Новый человек выходит на продуктивность больше месяца | Карта и описания |
| Два сервиса независимо решают одну задачу (два своих способа отправки писем) | Карта и согласованность |
| Авария, где причина — несовместимое изменение контракта | Оценка последствий |
Как этим пользоваться: пройти список раз в квартал и отметить, что верно. Три и больше отметок — работа не делается, и не потому, что люди плохие: обычно потому, что обязанность не закреплена ни за кем. Это же список для разговора с руководством, потому что он состоит из наблюдаемых фактов, а не из слов «нам нужен архитектор».
И обратная проверка, ради честности: признак хорошо идущей работы — новое изменение затрагивает один сервис и не требует созвона трёх команд, а вопрос «кого это затронет» получает ответ за десять минут по реестру, а не за два дня опросом.
Как не стать узким местом
Главная профессиональная опасность роли не названа ни в одном списке обязанностей: архитектор, через которого проходит каждое решение, останавливает работу. Симптомы узнаваемы: задачи ждут его согласования, команды стоят в очереди, любое ревью назначается на послезавтра, а в отпуске всё замирает. Это провал роли, даже если каждое отдельное решение принято правильно.
Причина в том, что обязанностей у роли много, а рук двое. Выход один: не принимать решения за команды, а делать так, чтобы команды принимали их правильно. Механизмы, по возрастанию зрелости:
Решает тот, кто владеет. Развилка внутри одного сервиса — решение команды, даже если архитектор сделал бы иначе. Его вход — не право вето, а контекст: «учтите, что этим событием пользуется вот кто». Право вето остаётся у того, что касается контрактов и границ, — и этот список должен быть коротким и написанным, иначе он разрастается до всего.
Письменный процесс развилок вместо согласования. Команда, столкнувшаяся с архитектурной развилкой, пишет предложение (это может быть запись решения со статусом «предложено»), рассылает, собирает возражения за названный срок и принимает решение. Архитектор — один из ревьюеров, а не ворота. Его отсутствие замедляет процесс, но не останавливает.
Правила вместо участия. Каждый раз, когда архитектор объясняет одно и то же третий раз, это сигнал: объяснение должно стать написанным правилом с проверкой в сборке. Тогда четвёртый раз объясняет сборка. Это тот же переход от решения к проверке, о котором раздел выше, и он же — единственный способ масштабировать себя.
Архитектурное ревью в командах. В каждой команде есть человек, который смотрит на изменения с архитектурной стороны и знает, когда звать архитектора. Их собирают вместе раз в неделю-две на полчаса — обсудить, что происходит в системе. Это не совещание, а способ распределить внимание: карта становится общим знанием, а не знанием одного.
Время на общую работу защищено. Из перечня обязанностей половина — работа, которую никто не просит (сверка согласованности, обновление карты, разбор расхождений). Если её не запланировать, она не делается. Обычная форма — фиксированная доля времени в неделю и включение таких задач в общий план, а не «в свободное время».
Проверка, что вы не узкое место: сколько решений за месяц команды приняли сами и сколько задач ждало вас. Если второе число не ноль и растёт, надо не работать быстрее, а раздавать больше.
Архитектор vs тимлид vs разработчик
Разница между тремя ролями не в квалификации, а в том, за что человек отвечает и на какой срок вперёд смотрит.
Старший разработчик отвечает за то, как устроен код в его зоне: структура модуля, выбор библиотеки, качество конкретного решения. Горизонт — текущая задача и её окрестности.
Тимлид отвечает за людей и за поток работы: кто чем занят, успевает ли команда, растут ли люди, как договариваться с соседними командами. Горизонт — команда и ближайший квартал.
Архитектор отвечает за то, что переживёт и задачу, и квартал: границы между сервисами, контракты между командами, владение данными, сквозные процессы. Горизонт — система целиком и годы.
Отсюда простой признак, чья это развилка: если решение можно переделать внутри одного сервиса за спринт и никого не предупреждать — зона разработчика. Если оно меняет контракт или требует договориться с другой командой — архитектурная.
В маленьких командах один человек совмещает несколько ролей. Важно понимать, что обязанности архитектора при этом никуда не деваются — они просто ложатся на кого-то конкретного.
Если в команде нет выделенного архитектора, полезно явно договориться: кто ведёт карту системы, кто документирует решения, кто следит за согласованностью. Когда этого нет, обязанности не выполняются — и со временем накапливаются невидимые проблемы.
Главная характеристика архитектурной работы: её результаты не видны немедленно. Хорошая архитектура не заметна — система просто работает и меняется без боли. Плохая становится видна через год, когда любое изменение требует недели, а не часов.
Глубже: чем карта является физическирасширенное
«Не обязательно красивая схема» оставляет вопрос: а что тогда? Ответ — набор файлов в репозитории, и он небольшой. Вот полный список артефактов роли, из которых складывается карта:
Реестр сервисов. По одной записи на сервис: имя, что делает одной строкой, команда-владелец, репозиторий, куда писать при проблеме, статус (живой, выводится, заморожен). Простейшая форма — один файл с таблицей или каталог по файлу на сервис. Это самый недооценённый артефакт: без него на вопрос «а этот сервис ещё нужен?» никто не отвечает годами.
Реестр интеграций. По одной записи на связь: кто вызывает кого или кто публикует и кто читает, синхронно или через брокер, что происходит при отказе. Это и есть карта связей, и она отвечает на вопрос «кого затронет изменение».
Владение данными. По одной строке на сущность: кто источник правды, кто читает копию, где лежит. Именно этот список закрывает спор «два сервиса объявили себя владельцами поля» — до того, как он случился.
Схемы C4 (контекст и контейнеры) — картинка поверх реестров, для людей. Без реестров она врёт, потому что картинку никто не обновляет; с реестрами — генерируется или проверяется по ним.
Записи решений — ADR, про которые следующий раздел.
Дорожная карта технического развития. Список того, что планируется изменить в устройстве системы в ближайший год: что выносим, что объединяем, от чего уходим, что заменяем. Обычно это одна страница, и она — единственный способ обсуждать техническую работу с бизнесом не в момент аварии.
Ключевое свойство всех шести: они живут в репозитории и меняются пул-реквестом. Карта в презентации или на онлайн-доске устаревает через месяц, потому что её правка не входит ни в одну задачу. Карта, которая лежит рядом с кодом и правится в том же изменении, где появился новый сервис или новая связь, — устаревает медленно, и это разница между работающим артефактом и красивым.
И минимум, с которого начинают, если нет ничего: реестр сервисов и владение данными. Две таблицы, один день работы, и большая часть вопросов «кто за это отвечает» получает ответ.
Глубже: пишет ли архитектор кодрасширенное
Вопрос, который задаёт каждый разработчик, читающий такую статью, и ответ на него практический, а не философский: да, и вот сколько.
Почему код нужен. Архитектор, который перестал прикасаться к системе, теряет две вещи. Первая — чувство цены: решение, которое на схеме выглядит аккуратным, в коде может означать неделю работы и десять правок в непонятных местах, и это видно только тому, кто там был. Вторая — доверие команды: советы человека, который год не собирал проект локально, слушают из вежливости. Симптом потери — фраза «ну там просто добавить поле» про задачу, которая занимает три дня.
Сколько кода. Ориентир, который называют команды: 15–30 % времени. Не «полноценный участник спринта» (тогда обязанности роли не делаются, а сроки задач срываются, потому что архитектора постоянно отвлекают) и не ноль. Что именно писать — важнее объёма:
- Первый срез нового решения. Архитектор делает каркас — тот самый вертикальный срез, который показывает, как это работает, — и отдаёт команде. Это и проверка решения на реальность, и самый быстрый способ передать замысел.
- Сквозные вещи: общая библиотека, шаблон нового сервиса, проверка в конвейере, инструмент миграции. То, что касается всех и не принадлежит никому.
- Прототип развилки. Два варианта на выбор быстрее сравнить на прототипе, чем в споре.
- Разбор трудных аварий. Место, где карта проверяется реальностью.
Чего лучше не брать: задачи с продуктовыми сроками на критическом пути. Архитектора выдернут на развилку, задача встанет, и виноват будет он же.
Что делать, если код ушёл совсем. Это случается, и лечится минимальным набором: собирать проект локально и проходить путь нового разработчика раз в квартал (заодно проверяется, что описания живые), читать чужие пул-реквесты в тех местах, где приняли архитектурное решение, брать одну маленькую задачу в спринт. Не для производства кода, а чтобы не потерять то самое чувство цены.
Глубже: как объяснить эту работу бизнесурасширенное
Финал статьи честно признаёт: результаты архитектурной работы не видны немедленно. Из этого следует практическая беда — на такую работу не дают времени. Поэтому её приходится защищать, и делается это не словами «нам нужна хорошая архитектура».
Говорить о рисках в деньгах и сроках, а не о качестве. Не «карта системы устарела», а «на вопрос, кого затронет изменение формата оплаты, у нас нет ответа; в прошлый раз это стоило двух часов простоя и трёх дней разбора». Не «терминология разъехалась», а «два отчёта о выручке расходятся на 4 %, и мы не знаем, какой верный». Риск, названный через прошлое событие и его цену, звучит для бизнеса совершенно иначе, чем риск, названный через качество.
Мерить то, что бизнес и так замечает. Четыре показателя, которые архитектурная работа двигает и которые не надо специально объяснять: время вывода изменения в прод (падает, когда границы сервисов разумны), доля неудачных выкатов (падает, когда контракты и совместимость под контролем), время восстановления (падает, когда есть карта и описания процессов), время выхода нового человека на продуктивность (падает, когда есть карта и записанные решения). Про первые три — в статье про принципы конвейера; важно, что это не метрики архитектора, а метрики команды, и именно поэтому им верят.
Привязывать общую работу к продуктовой. Самый надёжный способ получить время: не просить отдельный квартал на «улучшение архитектуры», а включать шаг в задачу, которая и так нужна бизнесу. Делаем новую функциональность в области платежей — в той же задаче наводим порядок в границах и обновляем карту этого участка. Работа идёт непрерывно и не требует отдельного разговора.
Показывать результат в форме, которую можно посмотреть. Обновлённая карта, список решений за квартал, снятые риски из списка признаков выше. Работа, у которой нет артефактов, для бизнеса не существует — а артефакты у этой роли есть, и они перечислены в начале статьи.
И последнее, самое неприятное: половину времени эту работу защищают ссылкой на последнюю аварию. Это нормально и работает, но есть способ лучше — держать список признаков из раздела выше открытым и показывать его до аварии, а не после. Тогда разговор идёт про предотвращённое, а не про случившееся.
Коротко
- Архитектор — это набор обязанностей, а не обязательно должность: в небольших командах их берёт тимлид или старший разработчик. Карта системы — основа: кто чем владеет, кто с кем общается, где живут данные. Без неё решения принимаются вслепую.
- Архитектурные решения нужно записывать — иначе они переоткрываются заново. Для этого есть ADR. Границы сервисов — одна из самых дорогих ошибок проектирования: неверная граница расползается в контракты, данные и организацию.
- Сквозные процессы никто не видит, кроме архитектора — каждый сервис знает только про свой кусок. Оценка последствий изменений требует карты: без неё «вроде никого не затронет» — начало инцидента.
- Стандарты работают, только когда они проверяются, а не просто «договорились».
- Карта физически — шесть файлов в репозитории: реестр сервисов, реестр интеграций, владение данными, схемы C4, записи решений, дорожная карта развития; начинают с первого и третьего.
- Провал обязанностей виден по наблюдаемым признакам: расходящиеся отчёты, разные имена одного понятия, событие без владельца, «вроде никого» на вопрос о последствиях, «исторически» вместо ответа.
- Главная опасность роли — стать узким местом: решает тот, кто владеет; короткий письменный список того, где есть право вето; письменный процесс развилок; правила вместо третьего объяснения; ревьюеры в командах.
- Код архитектор пишет — 15–30 % времени, и именно каркасы, сквозные вещи, прототипы развилок и разбор аварий, но не задачи с продуктовыми сроками на критическом пути.
- Бизнесу работу объясняют риском в деньгах через прошлое событие и метриками команды (время до прода, доля неудачных выкатов, время восстановления, выход нового человека), а общую работу включают в продуктовые задачи.
Что почитать дальше
- ADR — как оформлять и хранить архитектурные решения.
- Синхронная и асинхронная коммуникация — одна из типичных развилок, которые решает архитектор.
- Модель C4 — язык диаграмм для карты системы.
- Исполняемые инженерные стандарты — как превратить решения в правила, которые проверяются автоматически.