Software Architect

Кто это и зачем нужен

Software Architect выбирает подход, который решит задачу и переживёт рост. Его миссия — принять ключевые технические развилки осознанно, с пониманием blast radius (что и насколько затронет решение), нефункциональных требований и компромиссов. Архитектор думает не «как написать эту функцию», а «как устроить систему, чтобы она не развалилась через год нагрузки и изменений».

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

Что ломается без него: систему «как пошло» — она не масштабируется, разваливается под нагрузкой, переусложнена там, где не надо, и хрупка там, где критично. Решения принимаются без альтернатив и без фиксации «почему».

День из жизни

Утро. Берёт задачу с серьёзной развилкой. Формулирует нефункциональные требования (нагрузка, latency, доступность, рост). Накидывает 2–3 варианта решения — обязательно reuse-first (можно ли взять готовое). День. Сравнивает варианты по плюсам/минусам и компромиссам, оценивает blast radius каждого, выбирает и обосновывает. Рисует C4 (Context→Container), согласует с командой и продуктом ограничения. Вечер. Пишет ADR (решение + отвергнутые альтернативы + последствия) и System Design Doc, проверяет, что нефункциональные требования покрыты, фиксирует риски и открытые вопросы.

Ключевые навыки

Hard: проектирование систем, паттерны архитектуры (монолит/модульный монолит/микросервисы, событийность, CQRS и т.п. — без культа), нефункциональные требования и trade-offs, моделирование (C4/UML), данные и интеграции, безопасность и масштабирование, оценка blast radius. Soft: системное мышление, принятие решений в неопределённости, аргументация и защита компромиссов, прагматизм (reuse > изобретение), коммуникация со всеми уровнями.

Артефакты, которые пишет

• ADR — решение, альтернативы, последствия (см. карту ADR).
• C4-диаграммы — Context→Container→Component→Code (см. C4-модель).
• System Design Doc — задача, варианты, выбранный дизайн, риски (см. System Design Doc). Все три — в группе «Артефакты» базы с шаблонами. Нефункциональные требования сверяет с методологиями и спецификацией System Analyst.

Как ИИ/вайб-кодинг усиливает роль

1. Варианты решения + критика. Промт: «Ты software architect. Для задачи <…> с требованиями <нагрузка/latency/рост> предложи 3 архитектурных подхода (reuse-first), для каждого — плюсы, минусы, blast radius, когда уместен. Затем сам раскритикуй слабые места каждого.»
2. Черновик ADR. Промт: «Оформи ADR по решению <выбрали X>: контекст и ограничения, рассмотренные A/B/C, выбор и почему, последствия (включая минусы), статус.»
3. C4-описание. Промт: «Опиши систему <…> на уровнях C4 Context и Container: акторы, внешние системы, контейнеры (сервисы/БД) и связи (кто→кого, протокол).»
4. Проверка нефункциональных требований. Промт: «Вот дизайн <…>. Проверь покрытие NFR: масштабирование, отказоустойчивость, деградация, бэкапы, безопасность, наблюдаемость. Где дыры?»
5. Оценка blast radius. Промт: «Если внести изменение <…>, что в системе оно затронет, какие риски и как ограничить радиус?»

Путь развития: Junior → Middle → Senior → Lead

• Вход: из сильного Senior Engineer / Tech Lead — архитектор это глубина, а не «следующий грейд по умолчанию».
• Architect (компонент/сервис): проектирует отдельную систему/модуль, владеет NFR и trade-offs.
• Senior / Solution Architect: проектирует крупные системы и интеграции, выбирает подходы, влияет на несколько команд.
• Principal / Enterprise Architect: отвечает за архитектуру на уровне продукта/компании, tech radar, стандарты.

Частые ошибки и как избежать

• Переусложнение («сразу микросервисы и Kafka»). → Простейшее, что решает задачу; сложность — под доказанную потребность.
• Изобретение вместо reuse. → Сначала ищи готовое (reuse-first), потом строй своё.
• Решение без альтернатив и без ADR. → Всегда 2–3 варианта и фиксация «почему», иначе спор вернётся.
• Игнор нефункциональных требований. → Нагрузка/latency/отказы/рост — продумывай явно, это и есть архитектура.
• «Башня из слоновой кости». → Архитектор близок к коду и команде, а не рисует диаграммы в отрыве от реальности.

Что освоить (мини-программа)

• Концепции: системный дизайн, NFR и trade-offs, blast radius, паттерны (без культа), CAP/консистентность, масштабирование, событийная архитектура, C4.
• Инструменты: C4/PlantUML/draw.io, ADR-шаблоны, профайлеры/нагрузочное тестирование.
• Почитать: «Designing Data-Intensive Applications» М. Клеппман; «Fundamentals of Software Architecture» Ричардс/Форд; «Software Architecture: The Hard Parts»; блог martinfowler.com.

Зарплатные ориентиры (RU)

• Architect (входной): ~300–400 тыс ₽/мес.
• Senior / Solution Architect: ~400–600+ тыс ₽/мес.

  Роль senior+; зависит от масштаба систем, индустрии, города и года — проверяй актуальное.

Маппинг на агента Laskoff

Прямой mapsTo: architect. В Quest агент architect на фазе спеки/дизайна предлагает несколько вариантов решения с плюсами/минусами и их критикой (для высоких ставок — несколько независимых вариантов → критика → синтез), держит reuse-first, оценивает blast radius, фиксирует выбор в ADR и рисует C4. Ровно ядро роли архитектора, перенесённое в ИИ-конвейер.

🤖 Промт-персона

Ты — опытный Software Architect, прагматик и противник переусложнения. Помогаешь мне выбирать архитектурные подходы осознанно. Всегда сначала уточняй нефункциональные требования (нагрузка, latency, доступность, рост) и оценивай blast radius. Предлагай 2–3 варианта решения по принципу reuse-first (готовое > изобретение), честно с плюсами/минусами и компромиссами, и сам критикуй их слабые места. Выбор фиксируй в ADR с отвергнутыми альтернативами и последствиями. Рисуй C4 (Context/Container). Не усложняй раньше доказанной потребности. Оставайся близко к коду и реальности, а не в башне из слоновой кости.