Модернизация ИТ-системы: 6 признаков, что бизнес перерос архитектуру

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

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

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

1. Интеграции дорожают с каждым новым подключением

Часть затрат на интеграцию связана с самими партнерами. У каждого из них свои форматы данных, требования безопасности и график изменений, поэтому любое подключение требует отдельного согласования: формата обмена, дополнительных проверок и сроков на стороне партнера.

Эти согласования повторяются при каждом подключении. Остальная работа со временем должна упрощаться, потому что процесс уже выстроен и часть компонентов можно использовать повторно. Если вместо этого похожие подключения дорожают, различиями между партнерами это уже не объяснить.

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

2. Изменение в одном модуле требует правок в нескольких системах

Чем больше систем связано между собой, тем шире последствия даже небольшого изменения, в связи с чем доработка одного модуля редко остается локальной. Чаще она затрагивает смежные системы и требует дополнительного тестирования, а объем работ и риски намного превышают масштаб самой правки.

Заранее оценить сроки и стоимость такого изменения трудно, потому что часть зависимостей выясняется уже в ходе работы. Найти их до начала работ мешает и масштаб ландшафта. Например, у ВТБ в эксплуатации около 800 информационных систем.

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

3. Технический долг накапливается быстрее, чем закрывается

У технического долга в российских компаниях есть своя специфика. Вендоров меняли вынужденно и при ограниченном выборе, поэтому многие решения изначально внедрялись как временные. Теперь их приходится постоянно поддерживать, долг закрывается по остаточному принципу, а каждая новая задача добавляет к нему еще один слой. Точечными доработками с этим уже не справиться, и встает вопрос о комплексной модернизации.

4. Компоненты остаются без поддержки вендора

После ухода зарубежных вендоров не все компоненты удалось заменить, поэтому оставшиеся продолжают работать без обновлений безопасности и возможности обратиться к производителю в случае сбоя. Из-за этого уязвимости в таких компонентах накапливаются: по данным «РТК-Сервис», к 2024 году в «замороженных» версиях их набралось значительное количество.

Поскольку извне поддержки больше нет, отслеживать новые уязвимости и подбирать компенсирующие меры приходится внутренней команде информационной безопасности. Со временем эта работа становится только более ресурсозатратной, поэтому компоненты без поддержки вендора стоит включать в план модернизации заранее, не дожидаясь инцидента.

5. Архитектура не успевает за требованиями регулятора

С каждым новым требованием регулятора встает вопрос, успеет ли компания к сроку и что для этого придется изменить в системе.

Для финансовых компаний это знакомая ситуация: им предстоит перевести значимые объекты критической информационной инфраструктуры (КИИ) на российское ПО и внедрить открытые API. Сроки по обоим требованиям уже сдвигались, но готовиться к ним все равно нужно заранее.

Ответить быстро получается, когда архитектура понятна и команда сразу видит, какие компоненты затронет требование, и как они связаны с остальной системой. Если такой картины нет, ее приходится собирать заново под каждое требование. Тогда даже для оценки объема работ нужно отдельное обследование, а срок тем временем приближается.

6. Найти специалистов на текущий стек становится сложнее и дороже

Системы живут долго, так что стек, на котором их когда-то построили, со временем устаревает. Новые проекты на нем запускают все реже, а значит, и опыт работы с ним получает все меньше специалистов.

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

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

Когда признаки складываются в повод для модернизации

Один признак сам по себе еще не означает, что архитектуру пора менять. Подключение может подорожать из-за требований конкретного партнера, а изменения могут затянуться, пока в команде временно не хватает людей.

Повод для пересмотра архитектуры появляется, когда внутренние и внешние признаки накладываются друг на друга. Внутренние показывают, что систему становится все труднее менять. Внешние означают, что менять ее придется в любом случае, и не всегда тогда, когда это удобно компании.

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

Что делать, если бизнес перерос текущую ИТ-архитектуру

Если признаки сложились в повод для модернизации, работу удобно выстроить в четыре шага.

1. Провести технический аудит. Он показывает, из каких компонентов состоит система, как они связаны между собой и где риски выше всего.
2. Решить, что менять первым. Из найденных зависимостей команда выбирает те, что тормозят развитие остальных компонентов, и выстраивает порядок изменений.
3. Описать целевую архитектуру и дорожную карту. На этом шаге становится ясно, что придется заменить полностью, что можно доработать, и в какие сроки.
4. Понять, каких компетенций не хватает. Для каждого этапа дорожной карты команда оценивает, какие специалисты нужны, и кого из них пока нет.

Если нужных специалистов в команде нет, восполнить этот пробел можно несколькими способами.

Три способа восполнить нехватку специалистов

Найм в штат. Компания полностью контролирует команду, а экспертиза накапливается внутри. Однако поиск и адаптация специалистов требуют времени, а людей на редкий стек найти особенно непросто.

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

Аутстаффинг. Специалисты с нужной компетенцией подключаются к команде заказчика, но штат компании не растет. Управление задачами и архитектурными решениями при этом остается внутри. Модель хорошо работает, когда нужна узкая экспертиза на ограниченный срок, например, для миграции legacy-компонента или настройки интеграций с новыми отечественными решениями. Чем она отличается от аутсорсинга проекта, подробно разобрано в отдельной статье блога.

Какую модель выбрать, зависит от задачи. Важно, насколько остро не хватает компетенции, есть ли запас по срокам и нужно ли сохранить архитектурный контроль внутри компании.

Как устроена работа с командой Q1X по модели аутстаффинга

Часто задаваемые вопросы

Нужно ли менять всю ИТ-систему сразу, или можно модернизировать поэтапно?

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

Чем аутстаффинг отличается от аутсорсинга проекта?

При аутсорсинге за реализацию проекта отвечает подрядчик, и часть решений по организации работы переходит к нему. При аутстаффинге специалисты подключаются к команде заказчика, а задачи и архитектурные решения остаются под управлением компании.

Нужен ли для модернизации внешний аудит, или достаточно внутренней оценки?

Внутренняя команда лучше всех знает систему и накопившиеся в ней проблемы. Но после долгой работы с одной архитектурой трудно увидеть ее ограничения со стороны. Внешний аудит дает независимый взгляд на состояние системы, критичные зависимости и порядок изменений.

Какие риски возникают, если отложить модернизацию?

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

Что лучше: модернизировать существующую систему или заменить ее полностью?

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

С чего начать, если несколько признаков совпадают с ситуацией в компании?

С оценки текущей архитектуры. Она показывает, какие компоненты создают основные ограничения, какие зависимости критичны и каких компетенций не хватает. После этого можно выстроить порядок модернизации и выбрать модель реализации — собственную команду, найм или внешних специалистов.

Экспертиза Q1X в модернизации ИТ-систем

Если внутренней команде не хватает конкретной компетенции, будь то архитектура legacy-систем, интеграции или переход на отечественные решения под требования регулятора, Q1X помогает восполнить этот пробел.

Специалисты Q1X подключаются к команде заказчика на нужный срок. Это может быть миграция одного компонента или сопровождение всего перехода на новую архитектуру. Приоритеты и архитектурные решения компания при этом определяет сама.

Чтобы обсудить вашу ситуацию и понять, каких специалистов не хватает, свяжитесь с командой Q1X.