Четвёртый год корпоративный архитектор инфраструктуры Сбера работает с ландшафтом, где сходятся аппаратное обеспечение, виртуализация, операционные системы, серверы приложений, шлюзы безопасности и Wi‑Fi. Из этого опыта вырос простой, но болезненно точный вывод: корпоративный архитектор нужен не для красивых схем, а для управления сложностью, которая в большой компании растёт быстрее любого бэклога.
Об этом сообщает Habr / Карьера в колонке архитектора Артёма, который до Сбера успел пройти довольно нетипичный маршрут: мультимедиа и ВКС, сети, серверная инфраструктура, пользовательские устройства, прикладное ПО, BI- и аналитические системы в контуре ИБ, а затем роль главного инженера по слаботочным сетям в крупной строительной компании. Такой бэкграунд важен не как красивая биография, а как объяснение позиции автора: он смотрит на архитектуру не изнутри одной продуктовой команды, а с уровня, где одинаково чувствительны и «железо», и регуляторика, и сроки, и последствия неверных решений после внедрения.
Главная мысль текста в том, что переход от просто архитектора к корпоративному архитектору происходит не в тот момент, когда человек получает новый титул в оргструктуре. Порог проходит там, где архитектор перестаёт быть догоняющим оформителем уже принятых решений и начинает влиять на правила игры: на требования к продукту, порядок изменений, принципы проектирования и саму управляемость среды. В формулировке Артёма обычный архитектор делает комплексные проекты и адаптирует их под спущенные сверху требования. Корпоративный архитектор меняет сами принципы, по которым эти требования возникают и исполняются. Для русскоязычной IT-аудитории это звучит знакомо: во многих компаниях архитектурная функция до сих пор работает как обязательный этап согласования, а не как механизм снижения будущих затрат и рисков.
Отсюда и жёсткая, но точная метафора из статьи: если архитектор лишь фиксирует решения, которые уже приняли бизнес и продуктовая команда, то он превращается в технического писателя. В больших организациях это почти стандартный сценарий. Бизнес торопит релизы и KPI, продукт живёт в собственном темпе, разработка закрывает горящие задачи, а архитектура приходит в конце и пытается задним числом придать происходящему вид порядка. Автор прямо пишет, что такую позицию нужно ломать: команда должна видеть в архитекторе полезного участника жизненного цикла, а не человека, который приходит с чек-листом после того, как всё уже поехало в прод. И это, пожалуй, самая практичная часть материала. Роль архитектора здесь описана не как «визионер на башне», а как специалист, который помогает легализовать серые зоны, заранее подсветить ограничения и снять часть лишней турбулентности до того, как она станет инцидентом.
Архитектура как способ не утонуть в масштабе
В тексте Сбера корпоративная архитектура подаётся как практика проектирования, планирования и управления общей структурой организации или выделенной области. Важнее другое: её базовая задача — не рисовать эталонное будущее, а держать под контролем сложность. Автор не уходит в абстракции и перечисляет вполне приземлённые факторы, из которых эта сложность складывается: ролевые модели, масштабирование, резервирование, целостность системы, технологическая платформа, импортозамещение, статистика простоев, дефицит тестировщиков, перегрузка функциональностью, несоответствие внутренней нормативке, слабые интеграции и спрятанные legacy-компоненты. Набор знакомый почти любой крупной IT-организации. Разница лишь в том, кто всё это замечает заранее и кто потом разгребает последствия.
Именно поэтому у автора появляется ещё один важный тезис: прогнозирование в архитектуре — не магия и не «чуйка синьора». Это дисциплина, собранная из анализа фактов и смежных рисков, которым команды часто не уделяют внимания, пока ситуация не становится критической. По сути, речь о том, что корпоративный архитектор должен смотреть дальше ближайшего релиза и даже дальше квартала. Артём прямо говорит о горизонте в один-два квартала и до конца года. Для компаний, где архитектурные решения по-прежнему принимаются под дедлайны «к дню рождения высокого начальника», это звучит почти как антикризисный манифест. Но для бизнеса здесь есть очень прикладной смысл: чем раньше выявлены конфликтующие требования, нехватка ресурсов или несостыковки в нормативке, тем дешевле обходится изменение курса.
Материал интересен ещё и тем, что не романтизирует корпоративную архитектуру. Автор показывает, как она упирается в тяжёлую реальность крупных структур: внутренние нормативные документы, стандарты, методики, индексы качества, длинные циклы изменений и привычку организаций наращивать новые слои правил поверх старых. В этой части текст можно читать как диагноз многим enterprise-командам. Когда нормативка живёт автономно, а её авторы оторваны от актуальной практики проектирования, она превращается не в инструмент качества, а в дополнительный источник сложности. Для разработчиков это знакомо как бесконечные согласования и требования, логика которых потерялась где-то между аудитом, безопасностью и процессами. Для менеджмента это менее очевидно, потому что на уровне отчёта всё выглядит как контроль, стандартизация и зрелость.
Почему это важно не только архитекторам
Сильная сторона колонки в том, что она описывает карьерный рост архитектора не через повышение статуса, а через смену типа ответственности. Артём раскладывает роль на несколько состояний: «решала» для продуктовых команд, «строитель» целевого видения, «бульдозер» для разбора завалов, «управляющий» правилами и принципами описания ландшафта и, наконец, «создатель» элементов стратегических изменений. Формулировки местами нарочито грубые, но в этом и ценность: за ними видны реальные функции, которые в компаниях обычно размазаны между архитекторами, техлидами, PM и внутренними методологами. Для рынка это важный сигнал. Архитектор в 2026 году — особенно в большой инфраструктуре — всё меньше похож на автора диаграмм и всё больше на человека, который связывает разработку, эксплуатацию, безопасность, процессы и интересы бизнеса в одну систему ограничений.
Для разработчиков вывод простой: если архитектурная функция появляется только на этапе запрета, значит, она встроена слишком поздно. Для продуктовых и IT-руководителей вывод неприятнее: корпоративный архитектор начинает приносить максимальную пользу не тогда, когда подписывает документы, а когда способен менять порядок обсуждения задач и убирать заведомо дорогие ошибки ещё до их реализации. Для HR и фаундеров здесь тоже есть сигнал: искать архитектора только по стеку уже недостаточно. Нужен человек, который умеет работать с конфликтом интересов, нормативкой, legacy и горизонтом планирования, а не только с набором технологий.
На фоне рынка, где многие компании снова считают деньги, режут лишнюю сложность и пытаются навести порядок в наследии, такая трактовка роли выглядит своевременно. Вопрос теперь не в том, нужен ли корпоративный архитектор как должность. Вопрос в другом: сколько организаций действительно готовы пустить его туда, где определяется не форма документа, а будущая сложность всей системы.