В крупнейших корпорациях с микросервисной архитектурой формируется новый подход: сложность IT–ландшафта больше не пытаются упростить. Ею начинают управлять как отдельной функцией.
За последние три года в передовых корпорациях сложность IT–систем выросла не в разы, а на порядки. По оценкам Gartner, крупные компании, активно использующие микросервисную архитектуру, управляют более чем 400 различными SaaS–приложениями – это в 3 раза больше, чем в 2020 году. IDC фиксирует взрывной рост числа интеграций, микросервисов и API–вызовов в сегменте enterprise. А вместе с агентным ИИ, edge–вычислениями и гибридными облаками сложность в этих компаниях достигла критической массы.
И вот что важно для этого сегмента: эта сложность никуда не денется.
Более того, согласно прогнозам McKinsey и Forrester, к 2027 году в компаниях, следующих стратегии микросервисов и cloud–native подходов, число управляемых компонентов IT–инфраструктуры вырастет ещё на 50–70%. Причём рост будет не линейным – каждый новый компонент создаёт нелинейное увеличение связей, зависимостей и точек отказа.
Раньше компании отвечали на рост сложности одинаково: упрощением, стандартизацией, консолидацией. Многие IT–директора, в том числе в крупных организациях, продолжают придерживаться этого подхода – предпочитая монолитные системы микросервисам, централизованную архитектуру распределённой, консолидацию вендоров диверсификации.
Но в авангардных корпорациях – преимущественно за рубежом, в России пока только среди крупнейших игроков – формируется другой подход. Сложность перестают воспринимать как баг, который нужно исправить. Её начинают рассматривать как новую операционную реальность, которой нужно управлять.
И здесь начинается настоящая работа.
1. Почему упростить больше не получается в микросервисной архитектуре
Классические подходы IT–архитектуры строились на принципе минимизации сложности:
- сократить число вендоров
- унифицировать платформы
- стандартизировать процессы
- централизовать управление
Это работало – и продолжает работать для многих компаний – в эпоху монолитных систем и относительно стабильных бизнес–моделей. Монолитная архитектура имеет свои преимущества: понятная структура, меньше точек отказа, более предсказуемое поведение системы.
Но компании, которые перешли на микросервисную архитектуру и cloud–native подходы, сталкиваются с принципиально другой реальностью:
Бизнес требует скорости и гибкости
Новые продукты, каналы продаж, регионы появляются за недели, а не годы. Каждое направление приносит свои системы, данные и интеграции. Унификация замедляет time–to–market – а это уже стратегический риск.
Экосистемный подход становится нормой
Компании больше не работают изолированно. Они строят партнёрские сети, платформы, marketplace. Каждый внешний партнёр – это новые системы, протоколы и зависимости. Отказаться от них – значит отказаться от роста.
Регуляторное давление растёт
Локализация данных, суверенные облака, отраслевые требования к безопасности – всё это создаёт дополнительные слои сложности, которые нельзя просто «убрать».
Технологическая гетерогенность неизбежна
On–premise, публичные облака, edge, legacy–системы, новые микросервисы – всё это сосуществует одновременно. И будет сосуществовать ещё долго.
Вывод для компаний с микросервисной архитектурой: сложность стала структурной. Её больше нельзя упростить без потери конкурентоспособности.
Важно понимать: этот вызов актуален не для всех. Для компаний, сознательно выбравших монолитную архитектуру и централизованную модель управления, классические подходы упрощения продолжают работать эффективно.
2. Управление сложностью vs борьба со сложностью
Ключевое изменение мышления, которое происходит в передовых enterprise–организациях: переход от борьбы со сложностью к управлению сложностью.
Разница принципиальная.
Борьба со сложностью – это попытка её устранить:
- отказ от новых инструментов ради упрощения
- сокращение числа вендоров любой ценой
- консолидация систем без учёта бизнес–потребностей
- жёсткие стандарты, которые тормозят инновации
Управление сложностью – это признание её неизбежности и создание механизмов контроля:
- видимость всех компонентов и связей (observability, dependency mapping)
- управление рисками и точками отказа
- прозрачность стоимости каждого элемента инфраструктуры
- автоматизация рутинных операций
- измеримые метрики управляемости (mean time to recovery, blast radius, integration debt)
По данным исследований Deloitte (преимущественно на основе опыта западных компаний), компании, которые приняли сложность как данность и начали ею управлять, демонстрируют на 30–40% более высокую операционную устойчивость по сравнению с теми, кто продолжает бороться за простоту.
В России этот опыт пока накоплен только в крупнейших компаниях – таких как Сбер, Яндекс, VK, Тинькофф – которые работают с микросервисной архитектурой в масштабах сотен сервисов.
3. Управление сложностью – это зарождающаяся функция, а не набор инструментов
Ключевая ошибка, которую совершают многие организации: они пытаются управлять сложностью инструментами, а не процессами и ролями.
Покупают APM, observability–платформы, ITSM–системы – и ожидают, что сложность «рассосётся сама». Не рассасывается.
Потому что управление сложностью – это не про технологии. Это про организационную функцию.
Аналогия с управлением рисками: никто не думает, что достаточно купить GRC–систему, и риски исчезнут. Управление рисками – это роли, процессы, методология, культура, метрики. Ровно то же самое происходит с управлением сложностью в передовых компаниях.
Что начинает входить в функцию управления сложностью:
- Complexity mapping – построение карт зависимостей систем, данных и процессов
- Impact analysis – оценка влияния изменений на связанные компоненты
- Complexity budgeting – лимитирование допустимой сложности для каждого направления
- Integration governance – контроль того, как системы связываются друг с другом
- Technical debt management – управление накопленной технической сложностью как финансовым обязательством
- Incident management through the lens of complexity – анализ инцидентов с точки зрения их первопричин, связанных с архитектурной запутанностью
Forrester прямо указывает: к 2027 году до 40% крупных компаний (в мировом масштабе, преимущественно на Западе) могут ввести выделенные роли Complexity Manager или подобные им позиции. Это пока зарождающийся тренд, но он уже проявляется в практике технологических лидеров.
4. Три практических подхода к управлению сложностью
Компании–первопроходцы, которые начали управлять сложностью системно (преимущественно крупные западные enterprise и технологические гиганты), используют несколько общих подходов:
Подход 1: Сложность как измеримая величина
Они переводят сложность из абстрактного понятия в измеримые метрики:
- Число интеграционных точек на систему
- Глубина зависимостей (сколько систем затронет отказ одной)
- Время на онбординг нового разработчика (индикатор когнитивной сложности)
- Стоимость владения на каждую систему с учётом её интеграционной нагрузки
Подход 2: Управление через ограничения
Они вводят «сложностные бюджеты»:
- Новая система может появиться только если убрана старая (complexity cap)
- Каждое новое API–взаимодействие требует обоснования бизнес–ценности
- Лимиты на число интеграций для каждого продукта
Подход 3: Прозрачность как культура
Они делают сложность видимой для всех:
- Дашборды реального времени по зависимостям систем
- Регулярные арехитектруный аудит с участием бизнеса
- Публичные метрики техдолга и архитектурных рисков
По данным McKinsey (на основе опыта западных компаний), организации с высокой зрелостью управления сложностью тратят на 25–35% меньше времени на устранение инцидентов и имеют на 40% более короткие циклы разработки новых функций.
В российской практике подобные подходы пока встречаются точечно – в крупнейших технологических компаниях и банках, работающих с распределёнными архитектурами.
5. Роль CIO эволюционирует: от упрощения к оркестровке
Традиционно CIO отвечал – и продолжает отвечать в большинстве компаний – за наведение порядка в IT. Его задача: упростить, стандартизировать, оптимизировать.
В компаниях, перешедших на микросервисную архитектуру и столкнувшихся со структурной сложностью, начинает формироваться новая роль CIO.
CIO в этих организациях становится оркестратором сложности, а не её упростителем. Его задача – не сделать ландшафт простым (это невозможно в распределённых архитектурах), а сделать его управляемым.
Это требует других компетенций:
- Видение архитектуры как живой системы, а не статичного плана
- Умение балансировать гибкость и контроль
- Способность переводить техническую сложность в бизнес–риски
- Навык работы со stakeholders, у которых разные интересы и скорости
IDC отмечает (на основе мирового опыта): CIO, которые смогли принять сложность и начали строить операционную модель вокруг её управления, демонстрируют существенно более высокие показатели бизнес–удовлетворённости IT по сравнению с теми, кто продолжает воевать за упрощение любой ценой.
Важно: это эволюция роли, а не революция. Она актуальна для сегмента корпораций с микросервисной архитектурой. Для организаций с монолитными системами классическая роль CIO как упростителя и стандартизатора остаётся эффективной.
Вывод
Сложность IT–ландшафта в компаниях с микросервисной архитектурой – это не временная проблема, которая решится в перспкетиве. Это новая операционная реальность для этого сегмента.
Компании, которые продолжают бороться со сложностью в условиях распределённых систем, тратят ресурсы впустую. Компании–первопроходцы, которые принимают её и начинают управлять – получают конкурентное преимущество.
Но это пока зарождающийся тренд. Он формируется в передовых enterprise–организациях – преимущественно на Западе, в России – только в крупнейших технологических компаниях и банках.
Управление сложностью начинает становиться такой же важной функцией, как управление рисками, качеством или финансами. Это не набор инструментов. Это роли, процессы, метрики и культура.
При этом важно понимать: далеко не все компании идут по этому пути. Многие IT–директора, в том числе в крупных организациях, сознательно выбирают монолитные архитектуры, централизованное управление и классические подходы к упрощению – и это остаётся вполне обоснованной стратегией для определённых бизнес–моделей.
Ключевой вопрос не в том, правильно ли управлять сложностью или правильно её упрощать. Вопрос в том, какая стратегия соответствует вашей архитектуре, масштабу и бизнес–целям.
Для компаний, выбравших путь микросервисов, распределённых систем и высокой скорости изменений – управление сложностью становится критичной компетенцией. Те, кто осваивает её раньше, получают фору.
Для компаний, выбравших монолитную архитектуру и стабильность – классические подходы упрощения и стандартизации остаются эффективными.
Аналитическое агентство SIZE Marketing. Мы помогаем компаниям глубже понимать потенциал ИТ–инициатив, оцениваем рыночный и потребительский контекст, и даём данные, на основе которых можно принимать обоснованные решения о развитии ИТ–продуктов и платформ.
