После 2022 года российский бизнес сфокусировался на вопросах импортозамещения, замены оборудования и миграции на отечественные платформы. Однако все еще остаются критически важные информационные системы, которые продолжают функционировать, но лишились официальной поддержки вендоров.
Во многих организациях до сих пор эксплуатируются решения, внедренные 10–20 лет назад. Зачастую исходный код утерян, актуальная документация отсутствует, а компетенции по сопровождению покинули компанию вместе с первоначальной командой разработчиков. Пока система работает без сбоев, бизнес обычно предпочитает не трогать ее. Но при необходимости масштабирования, интеграции новых модулей или обновления интерфейса ИТ-подразделения сталкиваются с серьезными трудностями.
Перед руководством встает стратегический выбор: провести реверс-инжиниринг существующей системы для сохранения накопленного функционала или инициировать разработку нового решения с нуля. Какой же сценарий выбрать — рассказывает эксперт, руководитель отдела разработки ICL Services Ибрагим Габидуллин.
Реверс-инжиниринг в бизнесе
Обычно при слове «реверс» представляют хакера, ломающего систему. В корпоративной разработке это скорее ИТ-археология. Команде предстоит восстановить бизнес-процессы, понять логику работы баз данных, изучить забытые протоколы обмена и заново задокументировать то, как система вообще функционирует в реальности, а не на бумаге.
По сути, задача реверс-инжиниринга – сначала понять, как система реально устроена сегодня, а уже затем принимать решения о ее развитии.
Когда реверс-инжиниринг целесообразнее разработки с нуля
Глубокая интеграция с промышленным оборудованием
На предприятиях программное обеспечение часто взаимодействует со станками с ЧПУ, производственными контроллерами и системами мониторинга через закрытые протоколы. Также встают вопросы по модернизации MES, SCADA систем, интегрированных с «железом». Замена ПО без понимания протоколов может потребовать замены самого оборудования, что влечет колоссальные капитальные вложения. В таких проектах реверс-инжиниринг часто становится единственным способом сохранить существующий парк оборудования и избежать дорогостоящей модернизации производственной инфраструктуры.
Систему нужно срочно брать на поддержку
Иногда система достается в наследство в виде «черного ящика». Известно лишь, что она работает и критически важна для бизнеса. При этом может быть потерян исходный код (частично или полностью), отсутствует документация, разработчики недоступны. В этом случае реверс становится просто первым шагом к наведению порядка. Если не разобраться, что внутри, говорить о глобальной модернизации бессмысленно.
Сохранение сложной бизнес-логики
Многие производственные MES-системы, логистические и энергетические платформы, содержат тысячи бизнес-правил, которые накопились за годы работы. Разработка такого ПО с нуля несет высокий риск потери критически важных нюансов операционной деятельности. Реверс-инжиниринг позволяет бережно сохранить накопленный опыт и избежать дорогостоящих ошибок при проектировании.
Практический опыт ICL Services
Команда ICL Services регулярно сталкиваются с необходимостью спасать ИТ-инфраструктуру заказчиков в условиях отсутствия исходных данных.
Кейс 1. Сохранение непрерывности на автомобильном производстве
В рамках работы с автомобильным заводом мы реализовали систему управления производством для ПСМА Рус. Специалисты ICL Services провели глубокий реверс-инжиниринг предыдущей ИС предприятия. На основе извлеченных и структурированных данных была спроектирована и разработана новая, современная система на стеке Java и Angular с интеграцией PLC и интеграцией с сохранившейся системой контроля качества.
Заказчик получил технологически актуальную систему с полной интеграцией с текущим оборудованием, полностью сохранив привычные и отлаженные производственные процессы без риска остановки конвейера.
Кейс 2. Экстренный перехват управления у ушедшего вендора
Другой показательный пример — реверс-инжиниринг и поддержка системы управления производством для крупной табачной компании. Предыдущий интегратор прекратил поддержку критически важного ПО. Команда ICL Services взяла систему на сопровождение в состоянии «черного ящика».
Эксперты оперативно провели реверс-инжиниринг архитектуры и интеграционных потоков — изучили текущую инфраструктуру, оставшиеся от вендора документы, разобрали ПО на базе .NET и MS SQL. Таким образом поняв, как система устроена, смогли взять ее в поддержку, решили критические инциденты, а затем еще и успешно модернизировали ее. Предприятие избежало простоя и получило надежного ИТ-партнера для дальнейшего развития системы.
В каких случаях целесообразна разработка с нуля
Несмотря на эффективность реверс-инжиниринга, существуют ситуации, когда попытки сохранить устаревшее наследие экономически нецелесообразны:
- Устаревшая архитектура. Если система базируется на монолитной архитектуре прошлого десятилетия, не имеет API и не поддается горизонтальному масштабированию, ее выгоднее использовать исключительно как источник требований для нового продукта.
- Высокая стоимость восстановления. Когда код имеет крайне низкое качество из-за множественных хаотичных доработок разными подрядчиками, а стоимость аудита приближается к бюджету нового проекта, бизнес выбирает создание решения с нуля.
- Кардинальное изменение требований. Если бизнес-модель компании существенно изменилась и для соответствия новым реалиям (облачная инфраструктура, строгие требования ИБ, мобильность) требуется переписать более половины функционала.
Во всех перечисленных выше случаях также можно использовать реверс-инжиниринг, для того, чтобы извлечь все возможные данные, а также бизнес-логику, которая накопилась в этих системах, но в дальнейшем предпочтительно уже разработать новую систему, используя полученные данные.
Хитрость, которая работает: обновляем интерфейс, а не всю систему
На практике все чаще применяется «лайфхак». Во многих компаниях серверное ядро системы функционирует надежно, однако пользовательский опыт сильно страдает из-за устаревшего дизайна и сложной навигации.
В таких случаях нет необходимости переписывать всю систему. Более эффективный путь – провести реверс-инжиниринг существующей логики, выделить необходимые API, сохранить проверенное ядро и разработать новый современный интерфейс. Это позволяет бизнесу получить визуально и функционально новый продукт без многолетнего проекта полной миграции.
С чего начать?
Оптимальное решение практически всегда рождается на этапе технического аудита (включая реверс-инжиниринг), который проводят опытные архитекторы, аналитики и разработчики. Именно комплексная оценка существующей системы позволяет понять, где находится реальная ценность бизнеса и что выгоднее: сохранить ее, модернизировать или построить заново.