Как выбрать подход и технологии для модернизации корпоративного ПО
На совещании по модернизации корпоративного ПО первым обычно звучит вопрос «на чем будем писать» — Java или .NET, React или Angular. Однако на самом деле задавать этот вопрос еще рано.
Прежде чем выбирать стек, важно понять, какую роль играет система и какие задачи она решает. Речь идет о создании ценности или просто о сопровождении работы компании? Что на первом месте — быстрое обновление или стабильность при нагрузках? Все это влияет на стратегию модернизации.
В этой статье разберем, как подойти к модернизации различных процессов, от чего зависит выбор технологий и какие вопросы необходимо решить до старта проекта.
Почему модернизация начинается с оценки процессов
Подход к модернизации кардинально различается для основных и вспомогательных систем.
Основные системы автоматизируют ключевые процессы бизнеса: обработку транзакций в банке, выполнение заказов в ритейле, урегулирование убытков в страховании, построение маршрутов в логистике. Все эти операции критически важны и очень чувствительны к простоям или потере данных. Часто основные системы построены вокруг корпоративных ноу-хау, например, уникальных алгоритмов распределения заказов или собственных методологий скоринга. За счет этого компания обеспечивает доходность бизнеса и ценность для клиентов. Поэтому для основных систем обычно используются либо готовые продукты с глубокой кастомизацией, либо решения, разработанные на заказ.
Вспомогательные системы обеспечивают работу компании, но сами по себе не дают конкурентного преимущества. Среди процессов, которые они автоматизируют: бухгалтерия, документооборот, отчетность по комплаенсу, кадровый учет, расчет зарплат. Эти процессы во многих компаниях похожи, поэтому оптимальный вариант — использовать готовые продукты. Покупка лицензий часто выгоднее, чем разработка с нуля. Придется пожертвовать гибкостью, но зато вопросы поддержки и соответствия SLA возьмет на себя вендор.
Что будет, если выбрать неправильный подход к модернизации? Типичная ситуация — компания выбрала для автоматизации основных процессов готовый продукт и пытается добиться от него гибкости, которая просто не заложена производителем. Как следствие, проект затягивается, но результат неудовлетворительный. Другой пример — компания по инерции держится за самописную систему документооборота, тратит много денег на поддержку и разработку. Тогда как переход на готовый продукт мог бы существенно сэкономить бюджет.
Далее мы подробнее остановимся на модернизации основных систем, ведь именно они требуют наиболее активного участия заказчика.
Как выбрать технологии для модернизации ПО
По сути, проект модернизации корпоративной системы представляет собой реализацию нового решения на современном стеке технологий и с современной архитектурой.
Одна из самых распространенных ошибок — выбор технологий исключительно исходя из предпочтений команды. Вместо того, чтобы искать «лучший язык программирования» или «идеальную платформу», необходимо оценить ожидаемую нагрузку, операционные ограничения и риски конкретной области. То, что будет жизненно важным для клиентских порталов, для внутренних систем окажется избыточным.
Общие рекомендации по выбору технологий в зависимости от области системы
| Область системы | Особенности и задачи | Рекомендации | Обоснование выбора |
|---|---|---|---|
| Клиентские порталы | Большое количество пользователей, неравномерная нагрузка, гибкость UX | React, Angular, Vue.js | UI со слабой связностью, быстрые итерации, масштабируемая stateless-поставка |
| API и интеграционный слой | Оркестрация процессов, интеграция систем, валидация контрактов | Java (Spring), .NET, Node.js | Сильная экосистема, зрелые инструменты, стабильность при нагрузках |
| Основные бизнес-сервисы | Логика транзакций, логика предметной области, консистентность | Java, C#, Kotlin | Предсказуемая производительность, строгая типизация, поддержка в долгосрочной перспективе |
| Обработка и анализ данных | Пакетная обработка данных, ETL-процессы, отчетность, ML-конвейеры | Python, Java | Обширные экосистемы данных, гибкость при развитии моделей |
| Событийно-ориентированные и асинхронные процессы | Обмен сообщениями, потоковая обработка данных, слабо связанные процессы | Java, Go | Высокая пропускная способность, поддержка многопоточности, надежность при эксплуатации |
| Внутренние инструменты и системы автоматизации | Инструменты администрирования, скрипты, операционные процессы | Python, Node.js | Быстрая разработка, простота сопровождения |
| Компоненты с высокими требованиями к производительности | Обработка с минимальными задержками, ресурсоемкая логика | Go, Rust | Предсказуемая производительность, эффективное использование ресурсов |
Как переносить процессы при модернизации основных систем
При модернизации корпоративных систем важно понимать, какие процессы должны быть перенесены точь-в-точь, а какие можно переосмыслить. Так, логику транзакций или расчета стоимости услуг необходимо воспроизвести максимально точно. Процесс согласования, напротив, можно очистить от бюрократии, сократить количество проверок там, где речь идет о небольших суммах.
Если речь идет о масштабных системах, которые включают десятки модулей и интеграций, то нельзя провести замену одномоментно. Это касается как разработки, так и запуска в эксплуатацию. В отдельной статье мы рассказывали, в чем заключаются основные вызовы таких проектов, какие существуют методологии замены и когда их лучше использовать. Здесь же ограничимся коротким выводом: для масштабных и критически важных систем лучше разделить проект на этапы, для каждого этапа сначала разработать прототип, по готовности запустить новую систему в эксплуатацию параллельно со старой и дорабатывать функциональность спринтами в рамках запросов на изменения.
Во время переходного периода необходимо особенно внимательно отнестись к миграции данных, так как ошибки при работе с ними часто необратимы — в отличие от ошибок в коде. В чем заключаются основные вызовы при миграции данных мы разбирали в отдельной статье.
Как платформа Jmix помогает при модернизации корпоративных систем
Jmix — open source Java платформа с ИИ-инструментами для быстрой разработки корпоративных систем, от решений для внутренней автоматизации до SaaS-продуктов. Она хорошо подходит для проектов модернизации корпоративных систем.
- Предметно-ориентированная архитектура позволяет точно воспроизводить и развивать бизнес-логику устаревших систем.
- Четкое разделение функциональности на модули, реализованное на уровне архитектуры, упрощает взаимодействие с устаревшими системами во время параллельной работы.
- Продвинутые инструменты для проектирования модели данных и хранения их состояний обеспечивают безусловную согласованность и отслеживаемость данных.
- Корпоративный уровень безопасности, аудита и контроля доступа обеспечивает соответствие нормативным требованиям и комплаенсу.
- Поддержка в долгосрочной перспективе и совместимость старых и новых версий снижают риск появления нового технического долга.
- Готовность к использованию ИИ позволяет как внедрить ИИ-инструменты в разработку, так и реализовать агентные сценарии автоматизации в корпоративных приложениях.
- Возможность использования вместе с Camunda-ориентированными BPM-движками позволяет при необходимости выделить отдельный процессный слой, способный выдерживать высокую нагрузку и взять на себя межсистемную оркестрацию.
В основе платформы Jmix лежит Java-стек технологий. Таким образом, она подходит для разработки основных бизнес-сервисов, приложений для обработки и анализа данных, событийно-ориентированных и асинхронных процессов, а также API и интеграционного слоя.
Jmix — это не только платформа, но и команда, которая накопила опыт модернизации сложных, критически важных для бизнеса систем. Этот опыт охватывает различные корпоративные сценарии, включая Parallel Running с синхронизацией данных, поэтапный запуск новой функциональности и вывод из эксплуатации устаревших решений, а также построения композитных систем.
Заключение: какие вопросы нужно решить до старта модернизации
Перед тем, как утвердить план модернизации корпоративных систем, важно, чтобы бизнес вместе с ИТ-командой ответили на ряд вопросов.
- Какие из процессов основные, а какие вспомогательные — и какой подход выбран к их автоматизации? Не переплачивает ли компания за уникальное решение там, где достаточно готового продукта? И наоборот, не пытается ли она добиться гибкости от готового продукта, хотя было бы проще разработать уникальное решение с нуля?
- Соответствует ли предлагаемый стек ожидаемой нагрузке и рискам конкретной области? Какие критерии учитывались при выборе и насколько предпочтения команды влияют на решение?
- Достаточно ли внимания уделено этапу миграции? Приняты ли меры для обеспечения непрерывности процессов и сохранности данных?
Правильный выбор подхода к модернизации и стека технологий снимают половину рисков. Вторую половину помогает исключить тщательное планирование перехода, особенно в части работы с данными. Все это в комбинации помогает выполнить сложный проект без непредсказуемого роста издержек и смещения сроков.