Тендеры и лиды
Информация
Сложный IT-ландшафт редко появляется в компании в результате одного неудачного архитектурного решения. Обычно он формируется постепенно: одна система закрывает конкретную бизнес-задачу, затем появляется интеграция с другой, рядом возникает отдельный сервис для отчётности, ещё одна система требуется для HR, следующая — для документооборота, а часть старого контура остаётся просто потому, что «он пока работает». Через несколько лет компания обнаруживает, что любое изменение в одном месте требует согласований сразу с несколькими командами, тестирования десятков интеграций и понимания того, где именно находятся данные, от которых зависит бизнес-процесс.
Именно в этот момент IT-ландшафт перестаёт быть просто набором информационных систем и становится самостоятельной управленческой проблемой. На российском рынке эта проблема сейчас особенно заметна: компании одновременно занимаются импортозамещением, развитием собственных систем, переходом на отечественные решения, интеграцией новых продуктов с legacy-контуром и попытками контролировать IT-затраты. При этом задача бизнеса уже не сводится к тому, чтобы заменить иностранную систему на российский аналог. По данным CNews Analytics, в 2026 году на первый план вышли экономическая эффективность, отказоустойчивость и устойчивость архитектуры, а крупный IT-ландшафт рассматривается как совокупность десятков и сотен систем, интеграций, данных, процессов и эксплуатационных команд.
Поэтому вопрос «не слишком ли сложный у нас IT-ландшафт?» имеет смысл задавать не тогда, когда количество систем достигло какого-то условного значения. У компании может быть несколько сотен приложений и при этом достаточно управляемая архитектура, а может быть несколько десятков систем, которые уже создают постоянное сопротивление любым изменениям. Настоящий показатель сложности находится не в количестве технологий, а в том, сколько организационных, технических и финансовых усилий требуется компании, чтобы изменить то, что ещё вчера казалось простым.
Есть довольно простой тест: если руководитель IT не может быстро ответить, какая система является источником конкретных данных, кто отвечает за неё, с какими системами она связана и что произойдёт при её отключении, архитектура уже требует внимания. Ещё более показательная ситуация возникает, когда бизнес-задача формулируется достаточно просто, но техническая команда начинает перечислять десятки зависимостей: необходимо проверить API, согласовать изменения с несколькими владельцами систем, дождаться выгрузки данных, провести регрессионное тестирование и отдельно убедиться, что изменение не нарушит какой-нибудь процесс, который формально вообще не относится к исходной задаче.
В такой компании IT начинает жить по принципу «ничего не трогать, потому что неизвестно, что сломается». На ранних этапах это воспринимается как осторожность и зрелость. В какой-то момент осторожность превращается в тормоз для бизнеса. Любое изменение становится дорогим, сроки разработки начинают зависеть не столько от сложности самой функции, сколько от количества связанных систем, а backlog растёт быстрее, чем способность команды его разбирать.
Показательно, что именно управляемую скорость сегодня называют одним из ключевых запросов крупной корпоративной разработки. Исследование LDM, проведённое среди CIO, CTO, архитекторов и руководителей разработки российских компаний, показывает, что проблема enterprise-разработки всё чаще заключается не в отсутствии людей как таковых, а в необходимости обеспечивать предсказуемый time-to-market без постоянного увеличения технического долга. В исследовании участвовали представители преимущественно финансового сектора, ритейла и промышленности, то есть отраслей, где сложность IT-ландшафта особенно высока.
Отсюда появляется важное различие между большим и сложным IT-ландшафтом. Большая архитектура может быть нормальным следствием масштаба бизнеса. Сложная архитектура — это архитектура, в которой стоимость изменения системы начинает расти быстрее, чем ценность самого изменения.
На практике это проявляется очень конкретно. Новая функция, которая должна занимать несколько недель, внезапно требует нескольких месяцев. Подключение нового подразделения становится отдельным интеграционным проектом. Миграция одной системы запускает цепочку миграций вокруг неё. Разработчики всё больше времени тратят на поддержку связей между системами, а не на развитие продукта. CTO вынужден держать в голове огромное количество исключений и исторических решений, которые невозможно объяснить единой архитектурной логикой.
И если в этот момент компания просто продолжает добавлять новые системы, проблема начинает самовоспроизводиться.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13768 тендеров
проведено за восемь лет работы нашего сайта.
Для CEO проблема сложного IT-ландшафта редко выглядит как диаграмма с сотней блоков. Она проявляется в других показателях: запуск нового продукта переносится, автоматизация бизнес-процесса занимает слишком много времени, подразделения начинают самостоятельно покупать SaaS или создавать локальные решения, потому что корпоративный IT не успевает закрывать их потребности, а стоимость поддержки растёт даже тогда, когда функциональность систем практически не меняется.
Это довольно характерная ситуация для крупных российских компаний. После 2022 года многие организации одновременно получили несколько разнонаправленных задач: необходимо было сохранить работающие иностранные системы, найти альтернативы, построить интеграции с российскими решениями, обеспечить информационную безопасность и при этом продолжать цифровизацию бизнеса. По данным Б1, объём российского рынка IT-услуг вырос с 464–465 млрд рублей в 2022 году до 638 млрд рублей в 2024-м, а поставщики IT-услуг во многом участвовали именно в адаптации IT-ландшафтов заказчиков к новым условиям.
При этом импортозамещение само по себе не упрощает архитектуру. Иногда происходит обратное: старая система продолжает работать, рядом появляется отечественный аналог, между ними создаётся обмен данными, а часть функций распределяется между двумя решениями. В результате формально компания становится менее зависимой от одного поставщика, но количество интеграционных связей и точек контроля увеличивается.
CNews в обзоре российского рынка IT-услуг прямо указывает на проблему совместимости отечественных платформ между собой и с существующей инфраструктурой. Одновременно заказчики переходят от точечной замены отдельных продуктов к формированию более устойчивого IT-периметра, где важны совместимость, безопасность, долгосрочная поддержка и возможность дальнейшего развития системы.
На мой взгляд, именно здесь находится один из главных архитектурных парадоксов российского рынка. Компания может успешно решить задачу импортозамещения на уровне отдельных систем и одновременно ухудшить управляемость всего ландшафта. Если смотреть только на результат отдельного проекта, всё будет выглядеть хорошо: система заменена, требования выполнены, пользователи получили нужный функционал. Если посмотреть на архитектуру целиком, может оказаться, что новая система добавила ещё один слой интеграций, ещё один набор справочников, ещё одну модель данных и ещё одну команду, которую теперь необходимо учитывать при каждом изменении.
Первое, что мы бы не рекомендовали делать, — начинать с масштабной «перестройки архитектуры». Это один из самых дорогих вариантов реакции на проблему. Когда компания осознаёт, что IT-ландшафт стал сложным, возникает естественное желание всё переписать, объединить или построить новую платформу. Но такая стратегия часто только увеличивает риск: старый контур ещё продолжает обслуживать бизнес, новый ещё не готов, а между ними появляется дополнительный слой интеграций.
Гораздо разумнее начать с карты зависимостей и стоимости изменений. Не обязательно сразу описывать абсолютно все системы. Важно определить критические бизнес-процессы и посмотреть, сколько систем участвует в каждом из них, где находятся источники данных, какие интеграции являются критическими, какие системы имеют несколько владельцев и какие изменения регулярно создают непропорционально большой объём работы.
После этого становится заметно, где находится настоящий архитектурный bottleneck. Иногда им оказывается конкретная legacy-система, которая используется десятками процессов. Иногда — интеграционный слой. Иногда — отсутствие единой модели данных. В отдельных случаях проблема вообще не техническая: несколько подразделений используют разные процессы и поэтому требуют разные IT-решения.
Здесь появляется ещё один важный показатель — стоимость изменения. Если две системы работают стабильно, но изменение в одной из них требует вмешательства пяти команд и нескольких месяцев тестирования, именно эта связка должна попасть в архитектурный приоритет. Не потому, что она «некрасивая», а потому, что она ограничивает скорость бизнеса.
Исследование LDM показывает, что именно связь архитектуры с time-to-market становится одним из центральных вопросов корпоративной разработки: компании пытаются перейти от хаотичной кастомизации к более платформенному подходу, при котором архитектура, CI/CD, автоматизированное тестирование и другие инженерные практики работают как единая система.
В этом смысле хороший IT-ландшафт — это не тот, в котором мало систем. Это тот, в котором понятно, зачем существует каждая существенная система, где находятся данные, кто отвечает за изменения и сколько стоит развитие каждого критического бизнес-процесса.
Если бизнес спрашивает: «Почему мы не можем сделать это за две недели?», а ответ каждый раз звучит как перечень технических ограничений, компания уже должна смотреть на архитектуру не как на внутреннюю техническую тему, а как на фактор своей конкурентоспособности.
Российский рынок в 2026 году как раз движется в эту сторону. Период, когда главным KPI было просто заменить иностранное решение или внедрить новую систему, постепенно заканчивается. CNews отмечает, что компании теперь гораздо больше внимания уделяют экономической эффективности и устойчивости архитектуры, а не только скорости миграции. Причём для крупных предприятий сложность особенно высока именно потому, что десятилетиями вокруг отдельных платформ формировались процессы, интеграции, отчётность и эксплуатационные практики.
Поэтому вопрос «слишком ли сложен наш IT-ландшафт?» мы бы переформулировали иначе: сколько стоит бизнесу следующий шаг развития из-за текущей архитектуры?
Если новый продукт запускается медленнее конкурентов, автоматизация требует слишком много ресурсов, интеграции становятся отдельными проектами, а IT-команда тратит всё больше времени на поддержание связей между системами, проблема уже существует независимо от того, насколько аккуратно выглядит архитектурная документация.
Именно с такой точки зрения IT-компания GreenCore может быть полезна крупному бизнесу: не просто как разработчик очередной системы, а как технологический партнёр, способный посмотреть на конкретную задачу в контексте существующего IT-контура, определить архитектурные ограничения и построить решение так, чтобы оно не стало ещё одним изолированным элементом корпоративного ландшафта.
Потому что самая дорогая система в enterprise — далеко не всегда самая большая или самая старая. Иногда это система, которую компания уже не может изменить без того, чтобы сначала изменить ещё десять систем вокруг неё.
