Когда компания маленькая, архитекторов обычно нет. Есть разработчик Алеша, системный администратор Димон и руководитель Саша, который говорит сакральную фразу:
"Да что там делать, поднимите сервер, выкатите приложение. Делов-то!".
Потом компания растет. Появляются 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)

Dhwtj
28.05.2026 05:20потом пришли:
облака;
Kubernetes;
распределенные системы;
DevOps;
GitOps;
микросервисы;
Они же не сами пришли. Кто-то их привел. Кто этот негодяй? И зачем?
Архитектор должен стоять на страже и не дать запороть продукт таким дебилизмом.
Задача архитектора обеспечить систему важными для неё архитектурными свойствами.
Всё. Больше он ничего не должен, остальное детали и следствия.

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

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

grfree
28.05.2026 05:20Когда арх (да или кто-нибудь) говорит бизнесу - "нельзя" - обычно он почти сразу идет нахер.
Сколько раз пытался подстелить соломки, предупредить, ... тебя просто не слышат.
hren_sobachiy
28.05.2026 05:20Тут тоже надо понимать, может цель этого бизнеса освоить и распилить выделенные бабки, а вы тут со своим "как правильно". И прямо это конечно же никто не скажет. Поэтому такой архитектор в первую очередь должен иметь очень развитый EQ чтобы без слов понимать что от него на самом деле хотят.

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

XelaVopelk
28.05.2026 05:20Как по мне, основная проблема роли архитектора, что он не является владельцем “ресурса”. Трудового в первую очередь. Поэтому у него есть большой риск скатиться в рисователя воздушных замков, “весёлые картинки” которого либо складываются в стопку в чулане. Второй вариант они просто рисуются по факту реализации и он чисто техпис. Держать архитектора в тонусе/контексте очень сложно, потому что его руководитель зачастую сам не в контексте и действует реактивно.
Поэтому во многих даже крупных компаниях стараются не использовать эту роль.
hren_sobachiy
Тут очень важно пояснить до какого размера компания должна вырасти чтобы весь этот зоопарк стал мало-мальски оправдан. А то чаще все эти игры в Кубернетесы и хайлоад начинают играть просто чтобы в них играть с важным видом (ну и в резюме записать).
https://habr.com/ru/articles/1017146/
Inecs Автор
Тут, мне кажется, никто не даст точного ответа - когда компания выросла и пора внедрять. Тут, скорее, нужен грамотный ИТ-управленец в бизнесе, который будет готов взять на себя ответственность и сказать - "Пора!"
У меня есть дополнительные пример - бизнес думает, что сейчас это модно и трендово внедрить Kubernetes и AI подходы, а у самих 3 сервера на Collocation и непонятные перспективы.
И да, очень много людей/безнеса делает Kubernetes ради Kubernetes. Согласен. Но сейчас уже меньше.