См. также
Закон Конвея
Почему оргструктура и коммуникации неизбежно отпечатываются на архитектуре и скорости изменений.
См. также
Закон Конвея
Почему оргструктура и коммуникации неизбежно отпечатываются на архитектуре и скорости изменений.
Архитектор в этой главе — не отдельная «каста», а одна из разновидностей Staff+ роли (обычно уровень Staff/Principal), которая становится важной, когда «просто писать код» уже недостаточно. Задача роли — удерживать целостное видение, снижать стоимость изменений и масштабировать технологии так, чтобы скорость не превращалась в хаос, а качество в бюрократию.
TL;DR
- Архитектор — это одна из разновидностей Staff+ про системные решения, качество и масштаб, а не «рисовать квадратики».
- Зона ответственности: принципы, решения, границы и guardrails для команд.
- Влияние чаще строится через механизмы: ADR/RFC, дизайн‑ревью, платформу, стандарты и культуру качества — а не через формальные полномочия.
- Хорошая архитектура — это та, которая делает изменения безопасными и дешевыми на длинной дистанции.
- Главные риски роли: «ivory tower», узкое горлышко решений и вечные «переписывания».
Архитектор как разновидность Staff+
Архитектор — это инженерная роль внутри IC-трека, где Staff+ инженер отвечает за целостность и эволюцию системы: где проходят границы, какие компромиссы допустимы, как снижать риски и повышать скорость изменений. Часто эта роль не равна отдельной должности: в разных компаниях ее выполняют Staff+/Principal инженеры, техлиды и иногда технические руководители.
Полезная проверка: если решения, которые вы принимаете, затрагивают несколько команд и живут годами (интерфейсы, платформы, данные, безопасность, надежность) — это уже архитектурный уровень.
| Роль | Фокус | Типичный масштаб |
|---|---|---|
| Тимлид | Поток разработки и качество в конкретной команде, delivery и инженерные практики. | Команда / 1–2 сервиса |
| Staff+ (IC‑трек) | Влияние через техлидерство без менеджмента: сложные решения, кросс‑командный scope. | Несколько команд / домен |
| Архитектор (разновидность Staff+) | Целостность архитектуры, границы, принципы, эволюция и системные компромиссы. | Домен / платформа / продукт |
| CTO / техдир | Стратегия технологий, организация людей, инвестиции, риск‑менеджмент и приоритизация. | Компания / портфель продуктов |
Ключевая идея
Архитектор отвечает не за «единственно верный дизайн», а за управляемость изменений: чтобы новые фичи, команды и интеграции не разрушали систему и не делали каждую правку экспедицией.
Зона ответственности: видение, границы и качество
В практической работе архитектор постоянно балансирует между скоростью и риском. Он держит в голове качества системы: надежность, безопасность, стоимость владения, производительность, возможность масштабировать команды и поддерживать продукт годами.
Направление и принципы: куда идем, что стандартизируем, а где оставляем свободу.
Декомпозиция на домены/сервисы, контрактные интерфейсы, правила эволюции API и данных.
НФТ (SLO, безопасность, приватность, compliance), цена ошибки и стратегии смягчения.
ADR/RFC/дизайн‑доки как механизм передачи контекста и уменьшения «переговоров с нуля».
«Золотые пути», шаблоны, CI/CD, observability, стандарты — чтобы автономия не увеличивала риск.
Согласование между командами: trade‑offs, зависимости, единый словарь и договоренности.
Как архитектор влияет без полномочий
В большинстве компаний архитектура ломается не из‑за «плохих инженеров», а из‑за локальной оптимизации: команды решают свою задачу, но общий ландшафт постепенно превращается в клубок зависимостей. Поэтому архитектору важны механизмы, которые удерживают систему целостной, не превращая его в «архитектурного полицейского».
Через артефакты
- ADR/RFC: фиксировать решение, альтернативы и причины.
- Reference architecture: «как правильно» в виде примера, а не политики.
- Технический roadmap: миграции, депрекейты, архитектурный runway.
Через ритуалы и сервис
- Дизайн‑ревью с упором на качество и риски, а не на вкусовщину.
- «Office hours»: быстрые консультации вместо долгих согласований.
- Внутренние гильдии/комьюнити: общий язык и обмен опытом.
Сигнал, что вы стали «узким горлышком»
Если решения проходят через вас «по форме», а не потому что вы добавляете качество — вы уже тормозите систему. Лечится не ускорением ревью, а стандартизацией и self‑service.
Принятие решений: компромиссы должны быть явными
Архитектура почти всегда про trade‑offs. Главная ценность архитектора — сделать компромисс явным: что выигрываем, чем платим и как контролируем риск.
- 1Сформулировать проблему и границы: что точно в scope, а что нет.
- 2Уточнить качества: надежность, безопасность, latency, стоимость, time‑to‑change.
- 3Собрать варианты: минимум два, включая «ничего не менять».
- 4Описать trade‑offs и риски: где можем ошибиться и как узнаем это быстро.
- 5Выбрать вариант и зафиксировать решение письменно (ADR/RFC).
- 6План эволюции: rollout, миграции, депрекейты, обратимость.
Долгосрочное качество: архитектура как инвестиция
Технический долг бывает полезен как ставка на скорость. Проблема начинается, когда долг превращается в архитектурный: любое изменение требует координации, затрагивает множество команд и становится опасным.
- Явные границы доменов и ownership команд.
- Контракты и совместимость: версионирование API, схем, событий.
- Стратегии миграций и депрекейтов (и время на них в roadmap).
- Платформенные стандарты и «золотые пути» (self‑service).
- Guardrails в CI/CD: проверки, шаблоны, линтеры, политики доступа.
- Обязательная наблюдаемость: метрики, трассировка, алерты, runbooks.
- Постмортемы и улучшения системы, а не поиск виноватых.
- Ревью решений по рискам и качествам, а не по вкусу.
Простой тест архитектурного решения
Если решение делает будущие изменения опаснее, дороже и медленнее без явной бизнес‑причины — скорее всего, это плохая инвестиция.
Как измерять успех Staff+ инженера в архитектурной роли
У Staff+ инженера в архитектурной роли редко есть «своя фича», поэтому важно договориться о сигналах, которые показывают пользу для системы. Метрики не должны превращаться в KPI‑театр — это инструмент обратной связи.
Про поток
- Время изменений: lead time, частота релизов, время согласований.
- Количество «переоткрытий» задач из‑за архитектурных сюрпризов.
- Доля работы, которая уходит на «обходные пути» и ручные операции.
Про качество и риск
- Инциденты/регрессии, связанные с изменениями и интеграциями.
- Наблюдаемость и готовность к инцидентам (runbooks, oncall‑процессы).
- Стабильность контрактов: совместимость API/схем/событий.
Антипаттерны роли
- Ivory tower: архитектура «в вакууме», без контекста delivery и реальных ограничений.
- Архитектура как полиция: запреты вместо guardrails и помощи командам.
- Бесконечная стандартизация: «сначала сделаем идеально», а потом продукт.
- Большие переписывания: рефакторинг без стратегии миграции и обратимости.
- Узкое горлышко: каждое решение требует «одобрения сверху».
Первые 30–60–90 дней в архитектурной роли (Staff+)
30 дней
Карта и доверие
- Собрать карту доменов, систем и зависимостей.
- Понять боли команд: где ломается поток и почему.
- Договориться о формате решений (ADR/RFC, дизайн‑ревью).
60 дней
Первые механизмы
- Сделать 1–2 reference‑решения как «пример правильного».
- Запустить office hours и короткий дизайн‑ревью цикл.
- Выделить top‑3 архитектурных риска и план снижения.
90 дней
Масштабирование
- Упаковать стандарты в guardrails (шаблоны, CI, платформу).
- Встроить миграции/депрекейты в roadmap и budgeting.
- Сформировать комьюнити практики и калибровать решения между командами.
Если вам интересно, как архитектура связана с организацией команд и потоками работы, продолжите с Team Topologies и главой про различия масштабов.