Архитекторы в IT: кто чем занимается и кому это нужно

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

При этом огромное количество архитектурных решений принимают люди, у которых в должности нет слова «архитектор» вообще — senior-разработчики, tech lead-ы, DevOps-инженеры, CTO стартапов. Они делают это каждый день, часто не осознавая, что то, чем они занимаются, и есть архитектура.

Эта статья — карта: какие виды архитектуры бывают, кто ими занимается на практике, и где граница между «я просто пишу код» и «я принимаю архитектурное решение».

В статье

• Виды архитектуры: от кода до бизнеса
• Роли архитекторов: чем они отличаются
• Кто принимает архитектурные решения на самом деле
• Архитектура без архитектора: когда это работает
• Когда архитектор действительно нужен
• Чего архитектор не должен делать
• Архитектура как процесс: ADR, RFC, ревью
• Как понять, что вы уже занимаетесь архитектурой

Виды архитектуры: от кода до бизнеса

Архитектура в IT — это не одна дисциплина, а спектр. Каждый уровень отвечает на свой вопрос.

Application Architecture — как устроено приложение внутри

Слои, модули, паттерны (MVC, hexagonal, clean architecture), организация кода, зависимости между пакетами. Вопрос этого уровня: «как структурировать код, чтобы его можно было развивать и поддерживать?»

Это то, с чем сталкивается каждый разработчик. Решение «вынести бизнес-логику из контроллера в отдельный сервисный слой» — это архитектурное решение, даже если никто его так не называет.

Solution Architecture — как решить конкретную бизнес-задачу

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

Пример: компании нужна система уведомлений. Solution architect решает — использовать готовый SaaS (Firebase, OneSignal), поднять своё на RabbitMQ + worker-ы, или интегрироваться через Kafka с существующей event-шиной. Каждый вариант — свои trade-offs по стоимости, контролю, скорости разработки.

System / Infrastructure Architecture — как устроена платформа

Сети, серверы, контейнеры, оркестрация, CI/CD, мониторинг, безопасность. Вопрос: «на чём всё это работает и как это обслуживать?»

Решение «запускать сервисы в Kubernetes или в docker-compose на ВМ» — архитектурное. Оно определяет операционную сложность, стоимость, требования к команде на годы вперёд.

Enterprise Architecture — как IT соотносится с бизнесом

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

Это самый далёкий от кода уровень. Enterprise architect может вообще не писать код — он работает с roadmap-ами, бюджетами и межкомандными зависимостями.

Data Architecture — как устроены данные

Модели данных, хранилища, потоки данных, ETL/ELT, data governance. Вопрос: «где живут данные, как они перемещаются и кто за них отвечает?»

Решение «хранить аналитику в ClickHouse, а операционные данные в PostgreSQL» — архитектурное. Оно влияет на производительность, стоимость, возможности аналитики и compliance.

Security Architecture — как защищена система

Модели угроз, аутентификация/авторизация, шифрование, сетевая безопасность, compliance. Вопрос: «как обеспечить защиту данных и систем при заданном профиле угроз?»

Решение «использовать OAuth 2.0 + JWT с ротацией ключей» или «вынести весь трафик через zero-trust прокси» — это архитектура безопасности, даже если его принимает DevOps-инженер.

Роли архитекторов: чем они отличаются

Роль	Фокус	Горизонт	С кем работает
Application Architect	Структура одного приложения или сервиса	Месяцы	Разработчики
Solution Architect	Конкретное решение из нескольких компонентов	Месяцы–год	Разработчики, product, бизнес
System/Platform Architect	Инфраструктура, платформа, DevOps	Год–годы	SRE, DevOps, Security
Enterprise Architect	IT-ландшафт компании	Годы	CTO, менеджмент, все команды
Data Architect	Модели, хранилища, потоки данных	Год–годы	Аналитики, DBA, разработчики
Security Architect	Защита, compliance, модели угроз	Год–годы	Security, DevOps, compliance

На практике в компаниях до 50–100 человек эти роли часто совмещены. Solution architect принимает инфраструктурные решения. Senior-разработчик проектирует и приложение, и интеграцию. CTO стартапа — одновременно все шесть ролей.

Чистое разделение появляется только в крупных организациях, где масштаб задач требует специализации.

Кто принимает архитектурные решения на самом деле

Формально архитектурные решения принимает архитектор. На практике — тот, кто оказался перед выбором и имел полномочия (или просто смелость) его сделать.

Но «кто решил» — это ещё не вся картина, и романтизировать «решает тот, кто смелее» не стоит. В зрелых командах решение раскладывается на роли: кто инициирует вопрос, кто консультирует, кто утверждает (approves) и кто владеет последствиями (owns). Один человек может совмещать несколько из них, но если никто явно не владеет последствиями, решения превращаются в хаотичные и неотслеживаемые. Ниже по ролям — кто чаще всего инициирует решение; но утверждение и владение последствиями — отдельный разговор, к которому вернёмся таблицей в конце раздела.

Senior-разработчик

Выбирает паттерн организации кода, решает как обрабатывать ошибки, проектирует внутреннее API между модулями. Это application architecture — каждый день, в каждом pull request.

Tech Lead

Определяет технологический стек команды, решает «пишем на Go или на Rust», выбирает между монолитом и микросервисами, проектирует API между сервисами. Это solution architecture — без должности архитектора.

DevOps / SRE

Проектирует CI/CD pipeline, выбирает между Kubernetes и docker-compose, настраивает сети и безопасность. Это system architecture — и часто именно DevOps-инженер принимает решения, которые определяют операционную реальность на годы.

CTO / VP Engineering

В стартапах и небольших компаниях — одновременно enterprise, solution и infrastructure architect. Принимает стратегические решения о платформе, облаке, ключевых технологиях.

Product Owner / Product Manager

Звучит неожиданно, но требования к product влияют на архитектуру напрямую. Решение «нам нужен real-time» может потребовать push-механизмов вроде WebSocket или SSE — а может решаться через polling, long polling, MQTT или gRPC streaming, в зависимости от задержки, масштаба и направления потока. Решение «работаем в трёх регионах» требует multi-region и data residency. Product не проектирует архитектуру, но задаёт ограничения, внутри которых она существует.

Staff / Principal Engineer

Во многих современных компаниях это прямая альтернатива титулу «архитектор»: человек без слова architect в должности, но с cross-team техническим лидерством. Он не управляет людьми, но влияет на ключевые технические решения нескольких команд, задаёт стандарты и разрешает сложные технические споры. Часто именно Staff/Principal, а не формальный архитектор, реально удерживает архитектурную целостность в инженерной организации.

Бизнес-/системный аналитик

Аналитик не выбирает технологии, но задаёт архитектурные драйверы: через problem statement, требования, NFR и доменную модель он определяет, какую форму система обязана принять. «База должна работать автономно при потере связи» — это требование аналитика, которое предопределяет архитектуру сильнее, чем выбор брокера или БД. Эту роль легко недооценить, потому что она работает до того, как появляются схемы. Подробно эта линия разобрана в серии про лунную базу: как аналитика влияет на архитектуру через требования, метрики и границы домена.

Кто инициирует, консультирует, утверждает и владеет

Чтобы решение не повисло «ничьё», полезно для каждого крупного выбора держать в голове четыре роли (RACI-light). Пример распределения — он зависит от компании, но показывает логику:

Решение	Инициирует	Консультирует	Утверждает / владеет
Выбор основной БД	Tech Lead	Data Architect, DevOps	Архитектор / Staff Eng
Публичный API для других команд	Tech Lead	потребители API, Security	Архитектор
Стратегия деплоя (k8s vs ВМ)	DevOps / SRE	разработка, эксплуатация	Platform Architect
NFR (задержка, доступность, RTO/RPO)	Аналитик	архитектор, эксплуатация	Product + Архитектор
Доменная модель и границы	Аналитик	домен-эксперты, разработка	Архитектор / Tech Lead

Главное здесь не конкретные клетки, а принцип: у каждого архитектурного решения должен быть явный владелец последствий, а не только автор.

Архитектура без архитектора: когда это работает

Отдельная роль «архитектор» не обязательна. Во многих успешных командах архитектурные решения принимаются коллективно — через RFC-документы, ADR (Architecture Decision Records), design review, или просто через обсуждение в pull request.

Это работает, когда:

• Команда маленькая (до 8–12 человек). Все понимают систему целиком, контекст общий, решения принимаются быстро.
• Культура инженерной зрелости. Разработчики привыкли думать о trade-offs, а не только о фичах. Они задают вопросы «а что будет через год?» и «а какой operational cost?».
• Есть процесс фиксации решений. ADR, RFC, design docs — любой формат, который сохраняет контекст решения: что выбрали, почему, какие альтернативы рассматривали.
• Нет inter-team зависимостей. Как только системой пользуются несколько команд, нужен кто-то с cross-team видением.

Когда архитектор действительно нужен

Выделенная роль архитектора становится необходимой, когда:

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

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

Команда растёт быстро. При удвоении за полгода невозможно сохранить общий контекст неформально. Архитектор становится носителем и транслятором архитектурного видения.

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

Высокие требования к регуляторике, безопасности или безопасности жизни. В банках, медицине, работе с персональными данными или safety-critical системах роль архитектора (и архитектурного governance) может понадобиться раньше масштаба — не потому что система большая, а потому что цена ошибки и требования compliance высоки с первого дня.

Чего архитектор не должен делать

Роль легко превратить в антипаттерн. Хороший архитектор сознательно не:

• становится единственным bottleneck для всех решений — иначе команда ждёт его на каждый шаг;
• рисует схемы вместо команды — архитектура, придуманная в одиночку и спущенная вниз, не приживается;
• выбирает технологии без обратной связи разработки и эксплуатации — те, кто будет это писать и сопровождать, должны быть в разговоре;
• превращает архитектуру в комитет, где решения тонут в согласованиях;
• путает власть с ответственностью — право решать без владения последствиями быстро рождает оторванные от реальности решения.

Хорошая архитектурная роль усиливает команду, а не централизует её мышление на себе.

Архитектура как процесс: ADR, RFC, ревью

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

• ADR (Architecture Decision Records) — короткая запись: что решили, почему, какие альтернативы рассматривали и какие последствия приняли. Через год именно ADR объясняет, «почему здесь так».
• RFC / design review — обсуждение значимого решения до реализации, с явным кругом тех, кто консультирует и утверждает.
• Явное владение последствиями — у каждого крупного решения есть тот, кто отвечает за его жизнь, а не только за факт принятия.
• Пересмотр при смене контекста — решение не вечно; когда меняются требования или нагрузка, ADR пересматривается, а не молча устаревает.

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

Как понять, что вы уже занимаетесь архитектурой

Если вы:

• выбираете между SQL и NoSQL для нового сервиса;
• решаете, выносить ли логику в отдельный микросервис или оставить в монолите;
• проектируете API, которое будут использовать другие команды;
• определяете, как сервис будет деплоиться и масштабироваться;
• пишете ADR или design doc с обоснованием выбора;
• объясняете джуниору, почему «так не стоит делать, потому что через полгода…»

— вы занимаетесь архитектурой. Не важно, что написано у вас в должности.

Архитектура — это не титул и не сертификат. Это способность видеть решение шире одного тикета, думать о последствиях выбора и объяснять trade-offs команде. Чем раньше разработчик начинает это делать осознанно, тем быстрее он растёт — вне зависимости от того, захочет ли он когда-нибудь называться «архитектором».

Итог

Архитектура в IT — это не одна роль и не одна дисциплина. Это спектр от структуры кода до бизнес-стратегии. Архитектурные решения принимают на всех уровнях: даже junior сталкивается с локальными design-выборами, но их архитектурные последствия должны подсвечиваться на ревью; на другом конце спектра — CTO, который определяет платформу.

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

Документация

• Серия про лунную базу — как аналитика влияет на архитектуру через требования, метрики, доменную модель и C4
• Architecture Decision Records — формат фиксации архитектурных решений
• The C4 Model — способ визуализации архитектуры на разных уровнях абстракции
• Fundamentals of Software Architecture — Mark Richards, Neal Ford
• Design It! — Michael Keeling, практическое руководство по архитектуре