Когда компания маленькая, архитекторов обычно нет. Есть разработчик Алеша, системный администратор Димон и руководитель Саша, который говорит сакральную фразу:

"Да что там делать, поднимите сервер, выкатите приложение. Делов-то!".

Потом компания растет. Появляются Kubernetes, микросервисы, Clickhouse, десять команд разработки, пять облаков, семь подрядчиков, бюджеты на миллионы рублей и внезапное осознание:

"Кажется, нам нужен человек, который понимает, как это вообще должно работать вместе".

Так в компании появляются архитекторы.

И именно в этот момент ИТ перестает быть набором случайных серверов и превращается в инженерную систему.

Кто такой архитектор в ИТ

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

Очень важно понять одну вещь:

Архитектор - это не "самый умный разработчик".
И не "сеньор-девопс, который ходит на встречи".
Архитектор - это человек, который отвечает за системность.

Он думает:

  • как компоненты будут взаимодействовать;

  • как система будет масштабироваться;

  • что будет через 3 года;

  • сколько это будет стоить;

  • как это поддерживать;

  • как не сдохнуть во время первой же нагрузки;

  • как не сделать инфраструктурный Чернобыль.

Почему архитекторы вообще появились

Раньше все было проще.

  • Монолит.

  • Один сервер.

  • Одна база.

  • Один релиз ночью.

  • Один админ.

  • Один разработчик.

Если что-то ломалось - все шли пить кофе и чинить.

Но потом пришли:

  • облака;

  • Kubernetes;

  • распределенные системы;

  • DevOps;

  • GitOps;

  • микросервисы;

  • машинное обучение;

  • большие данные;

  • отказоустойчивость;

  • регуляторы;

  • безопасность;

  • multi-cloud;

  • AI-инфраструктура;

  • GPU-кластеры.

И внезапно оказалось, что "просто написать код" уже недостаточно.

Теперь ошибка архитектуры может стоить бизнесу миллионов.

Архитектор - это переводчик между бизнесом и инженерами

Это одна из самых недооцененных частей профессии.

Бизнес говорит:

"Мы хотим быстро запускать новые продукты".

Разработка слышит:

"Надо срочно переписать все на Go".

Инфраструктура слышит:

"Опять будут микросервисы и кластеры Postgres".

Без архитектора все начинают сраться друг с другом.

Архитектор превращает хотелки бизнеса в техническую стратегию.

И наоборот - объясняет бизнесу, почему:

  • нельзя хранить все в блокнотике;

  • нельзя запускать продакшен на одном сервере;

  • нельзя экономить на резервном копировании;

  • нельзя "переехать в Kubernetes за неделю".

Главная задача архитектора

Главная задача архитектора:

Снижать хаос

На самом деле почти все архитектурные практики сводятся именно к этому.

Архитектор уменьшает:

  • хаос в инфраструктуре;

  • хаос в разработке;

  • хаос в процессах;

  • хаос в интеграциях;

  • хаос в эксплуатации;

  • хаос в коммуникациях.

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

  • что с чем связано;

  • кто это писал;

  • зачем это нужно;

  • почему оно падает только по пятницам.

Какие виды архитекторов бывают

Вот тут начинается самое интересное. Потому что "архитектор" - это не одна роль. Это целое семейство профессий.

Solution Architect - архитектор решений

Самый распространенный тип архитекторов.

Его задача:

  • проектировать конкретные технические решения;

  • связывать бизнес-задачи и технологии;

  • выбирать стек;

  • продумывать интеграции;

  • проектировать взаимодействие систем.

Например:

Бизнес хочет:

  • мобильное приложение;

  • личный кабинет;

  • платежи;

  • AI-чат;

  • аналитику;

  • интеграцию с CRM.

Solution Architect проектирует:

  • API;

  • взаимодействие сервисов;

  • очереди брокера;

  • авторизацию в SSO;

  • хранение данных;

  • сетевую архитектуру;

  • взаимодействие с облаками.

Enterprise Architect - энтерпрайз архитектор

Это уже уровень "вид сверху". Он думает не про один сервис. Он думает про всю компанию.

Именно Enterprise Architect отвечает на вопросы:

  • как выглядят ИТ компании через 5 лет;

  • какие платформы использовать;

  • как стандартизировать инфраструктуру;

  • как уменьшать технический долг;

  • как объединять команды;

  • как не плодить сотню разных Kubernetes-кластеров с разными подходами.

Это очень стратегическая роль.

Иногда хорошие Enterprise Architect спасают компании от инфраструктурного безумия.

Иногда плохие Enterprise Architect производят 1000 страниц PDF и исчезают.

Infrastructure Architect - инфраструктурный архитектор

Вот здесь начинается настоящая инженерия, блэкджек и падшие женщины.

Infrastructure Architect отвечает за:

  • датацентры;

  • облака;

  • Kubernetes;

  • сети;

  • балансировщики;

  • системы хранения;

  • observability;

  • CI/CD;

  • GitOps;

  • безопасность;

  • disaster recovery;

  • GPU-кластеры;

  • высокую доступность.

Именно этот человек обычно приходит и говорит:

"Нет, мы не будем запускать PostgreSQL в Kubernetes без понимания последствий".

Или:

"Нет, один мастер Kubernetes на проде - это не отказоустойчивая архитектура, а стэндалон говно!".

Cloud Architect - облачный архитектор

Очень популярная роль после массового перехода в облака.

Cloud Architect проектирует:

  • AWS;

  • Azure;

  • GCP;

  • гибридные облака;

  • multi-cloud;

  • FinOps;

  • безопасность облака;

  • автоматизацию;

  • облачные платформы.

На практике хороший Cloud Architect:

  • умеет считать деньги;

  • понимает сети;

  • знает Terraform;

  • знает Kubernetes;

  • знает безопасность;

  • понимает ограничения облаков.

Плохой Cloud Architect обычно просто включает все managed-сервисы подряд и через полгода компания получает счет размером с двушкой в центре Москвы.

Software Architect - архитектор программного обеспечения

Это уже ближе к разработке.

Он отвечает за:

  • структуру приложений;

  • паттерны проектирования;

  • API;

  • взаимодействие сервисов;

  • производительность;

  • устойчивость к нагрузкам;

  • качество кода.

Именно Software Architect решает:

  • монолит или микросервисы;

  • REST или gRPC;

  • Kafka или RabbitMQ;

  • PostgreSQL или Cassandra;

  • синхронное или асинхронное взаимодействие.

Security Architect - архитектор безопасности

Очень востребованная роль в 2026 году.

Потому что сейчас безопасность - это не "антивирус поставить".

Это:

  • Zero Trust;

  • IAM;

  • IDM;

  • RBAC;

  • управление секретами;

  • безопасность Kubernetes;

  • supply chain security;

  • безопасность контейнеров;

  • безопасность CI/CD;

  • аудит;

  • соответствие требованиям регуляторов.

Security Architect обычно портит жизнь всем вокруг.

Но делает это ради выживания бизнеса.

Data Architect - архитектор данных

Когда компания начинает тонуть в данных, появляется он.

Data Architect проектирует:

  • хранилища данных;

  • DataLake;

  • ETL/ELT;

  • Kafka;

  • CDC;

  • Spark;

  • Trino;

  • Airflow;

  • Hadoop;

  • аналитику;

  • ML pipelines.

Именно он отвечает за вопрос:

"Почему у нас 17 разных таблиц клиентов и все показывают разное количество пользователей?"

AI Architect - архитектор искусственного интеллекта

Новая суперпопулярная роль 2025-2026 годов.

AI Architect отвечает за:

  • LLM-инфраструктуру;

  • GPU-кластеры;

  • inference;

  • RAG;

  • vector database;

  • ML pipelines;

  • Triton;

  • MIG;

  • масштабирование моделей;

  • интеграцию AI в бизнес.

И да, хороший AI Architect обычно прекрасно понимает:

  • Kubernetes;

  • сети;

  • GPU;

  • хранение данных;

  • распределенные вычисления.

Потому что современный AI - это уже инфраструктурный ад.

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

Если смотреть со стороны, может показаться, что архитектор:

  • сидит на встречах;

  • рисует схемы;

  • задает неудобные вопросы.

Но реальная работа гораздо сложнее.

Архитектор постоянно:

  • принимает компромиссы;

  • анализирует риски;

  • спорит;

  • объясняет;

  • договаривается;

  • проектирует;

  • стандартизирует;

  • спасает команды от плохих решений.

Очень часто архитектор - это человек, который заранее видит будущую катастрофу. И пытается ее предотвратить.

Почему разработчики иногда не любят архитекторов

Потому что архитектор часто говорит неприятные вещи.

Например:

  • "это не масштабируется";

  • "это небезопасно";

  • "это невозможно поддерживать";

  • "это сломается через полгода";

  • "нам нужен рефакторинг";

  • какой еще монолит в 2026 году для MVP?;

  • "нет, мы не будем делать 400 микросервисов".

Но хороший архитектор не тормозит разработку. Он предотвращает технические катастрофы.

Почему инфраструктурщики любят хороших архитекторов

Потому что хороший архитектор:

  • стандартизирует подходы;

  • убирает хаос;

  • уменьшает ручную работу;

  • помогает внедрять IaC;

  • внедряет GitOps;

  • думает про observability;

  • думает про отказоустойчивость;

  • думает про эксплуатацию.

Плохая архитектура всегда превращается в боль для DevOps, Ops  и SRE.

Всегда.

Почему бизнесу нужны архитекторы

Потому что архитектура напрямую влияет на деньги.

Хорошая архитектура:

  • ускоряет разработку;

  • уменьшает количество аварий;

  • снижает стоимость эксплуатации;

  • ускоряет масштабирование;

  • уменьшает технический долг;

  • повышает надежность;

  • позволяет быстрее запускать новые продукты.

Плохая архитектура:

  • сжигает бюджеты;

  • тормозит команды;

  • приводит к простоям;

  • уничтожает сроки;

  • превращает любой релиз в лотерею.

Архитектура - это не про технологии

Это важнейшая мысль.

Многие думают:

"Архитектор - это человек, который выбирает модный стек".

Нет.

Настоящая архитектура:

  • про компромиссы;

  • про устойчивость;

  • про стоимость;

  • про масштабирование;

  • про сопровождение;

  • про людей;

  • про процессы;

  • про будущее.

Иногда лучшая архитектура - это вообще не внедрять новую технологию.

Для многих компаний самый полезный архитектурный совет звучит так:

"Давайте не будем делать Kubernetes ради Kubernetes".

Хороший архитектор - это инженер с опытом и познавший боль

Практически все сильные архитекторы:

  • были разработчиками;

  • были DevOps;

  • были администраторами;

  • падали в продакшене;

  • поднимали инфраструктуру ночью;

  • переживали аварии;

  • мигрировали базы;

  • восстанавливали резервные копии;

  • ругались с облачными провайдерами;

  • ловили утечки памяти;

  • искали причину сетевых проблем в ночи.

Архитектор без практического опыта обычно опасен. Потому что красивые схемы в draw.io не всегда переживают встречу с реальностью.

Главная проблема современных ИТ

Сегодня большинство компаний страдают не от нехватки технологий. Технологий слишком много.

Компании страдают от:

  • отсутствия системности;

  • хаоса;

  • отсутствия стандартов;

  • отсутствия стратегии;

  • бесконтрольного роста платформ;

  • бесконечных "временных решений".

Именно поэтому роль архитекторов в 2026 году становится только важнее.

Итог

Архитектор в ИТ - это человек, который помогает технологиям, людям и бизнесу работать как единая система. Это не "человек со схемами". Это инженер, стратег, переговорщик и иногда профессиональный тушитель инфраструктурных пожаров.

Хорошие архитекторы:

  • экономят бизнесу огромные деньги;

  • делают разработку быстрее;

  • делают инфраструктуру стабильнее;

  • уменьшают хаос;

  • помогают компаниям расти.

А еще именно архитекторы чаще всего первыми понимают, что:

  • Kubernetes не серебряная пуля;

  • микросервисы могут уничтожить команду;

  • AI без инфраструктуры превращается в дорогой эксперимент;

  • и что самый дорогой сервер в компании - это тот, который никто не понимает, но все боятся выключить.

Комментарии (10)


  1. hren_sobachiy
    28.05.2026 05:20

    Потом компания растет. Появляются Kubernetes, микросервисы, Clickhouse, десять команд разработки, пять облаков, семь подрядчиков, бюджеты на миллионы рублей и внезапное осознание:

    Тут очень важно пояснить до какого размера компания должна вырасти чтобы весь этот зоопарк стал мало-мальски оправдан. А то чаще все эти игры в Кубернетесы и хайлоад начинают играть просто чтобы в них играть с важным видом (ну и в резюме записать).

    https://habr.com/ru/articles/1017146/


    1. Inecs Автор
      28.05.2026 05:20

      Тут, мне кажется, никто не даст точного ответа - когда компания выросла и пора внедрять. Тут, скорее, нужен грамотный ИТ-управленец в бизнесе, который будет готов взять на себя ответственность и сказать - "Пора!"

      У меня есть дополнительные пример - бизнес думает, что сейчас это модно и трендово внедрить Kubernetes и AI подходы, а у самих 3 сервера на Collocation и непонятные перспективы.

      И да, очень много людей/безнеса делает Kubernetes ради Kubernetes. Согласен. Но сейчас уже меньше.


  1. Dhwtj
    28.05.2026 05:20

    потом пришли:

    • облака;

    • Kubernetes;

    • распределенные системы;

    • DevOps;

    • GitOps;

    • микросервисы;

    Они же не сами пришли. Кто-то их привел. Кто этот негодяй? И зачем?

    Архитектор должен стоять на страже и не дать запороть продукт таким дебилизмом.

    Задача архитектора обеспечить систему важными для неё архитектурными свойствами.

    Всё. Больше он ничего не должен, остальное детали и следствия.


    1. Inecs Автор
      28.05.2026 05:20

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


    1. Yuriy_krd
      28.05.2026 05:20

      как правильно пишет @Inecs, в подавляющем большинстве сначала разводят зоопарк, а потом уже приводят директора зоопарка) сталкиваюсь с этим нередко )


    1. CBR
      28.05.2026 05:20

      Логика карьерного роста поощряет такой дебилизм. Создание проблем и демонстративная ворьба с ними повышает ценность специалиста на рынке труда и для текущего работодателя.


  1. grfree
    28.05.2026 05:20

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


    1. hren_sobachiy
      28.05.2026 05:20

      Тут тоже надо понимать, может цель этого бизнеса освоить и распилить выделенные бабки, а вы тут со своим "как правильно". И прямо это конечно же никто не скажет. Поэтому такой архитектор в первую очередь должен иметь очень развитый EQ чтобы без слов понимать что от него на самом деле хотят.


    1. CBR
      28.05.2026 05:20

      Кто говорит "нельзя", правильно идет нахер. Аргументировать нужно прогнозом последствий.


  1. XelaVopelk
    28.05.2026 05:20

    Как по мне, основная проблема роли архитектора, что он не является владельцем “ресурса”. Трудового в первую очередь. Поэтому у него есть большой риск скатиться в рисователя воздушных замков, “весёлые картинки” которого либо складываются в стопку в чулане. Второй вариант они просто рисуются по факту реализации и он чисто техпис. Держать архитектора в тонусе/контексте очень сложно, потому что его руководитель зачастую сам не в контексте и действует реактивно.
    Поэтому во многих даже крупных компаниях стараются не использовать эту роль.