Обертывание устаревшей системы и ее модернизация решают разные задачи, и именно отношение к ним как к взаимозаменяемым процессам тормозит большинство интеграционных усилий. Настоящий вопрос не в том, «можем ли мы предоставить доступ к этим данным» — это почти всегда решается с помощью интеграционного уровня.
Более сложный вопрос заключается в том, может ли система под ним еще меняться и является ли интеграционный уровень способом выиграть время для этих изменений или он просто тихо подменяет необходимость в них. Если ошибиться в этом разграничении, то сам интеграционный уровень станет следующей устаревшей системой, которую придется распутывать. Это руководство предлагает логику выбора шаблона и сигналы к выходу, чтобы избежать подобного сценария.
TL;DR: Обернуть или заменить?
Устаревшая система, которая не может предоставить данные, — это не то же самое, что система, которая не может меняться. Смешение этих двух проблем — причина, по которой интеграционные проекты превращаются в бесконечную работу по поддержке. Если ваша ERP-система уже может ответить на вопрос (заказы, инвентаризация, флаги клиентов), вам нужен интеграционный уровень, а не переписывание кода.
Если она не может ответить на вопрос, потому что сама логика неверна, никакой фасад это не исправит; такая устаревшая система нуждается в модернизации, а не в обертывании.
В ходе работы над интеграцией ERP и основных систем мы неоднократно наблюдали, как концепции устаревших моделей данных (статусы заказов, флаги клиентов, поля единиц измерения) без изменений переносились в код новых сервисов во время проверки.
Этот шаблон — сигнал того, что тонкой обертки недостаточно и устаревшей системе нужен антикоррупционный слой между ней и любым современным сервисом, а не просто API поверх нее.
Быстрое решение: прежде чем выбирать шаблон, запишите, какая из двух проблем у вас на самом деле есть. Каждый последующий вариант (API-фасад, CDC, iPaaS) зависит от этого ответа, а выбор одного из них до того, как вы ответите на вопрос, — это путь к тому, как мост незаметно превращается в следующую устаревшую систему, которой никто не планировал владеть.
В этой статье рассматриваются шаблоны в том порядке, в котором команды обычно их оценивают, стоимость их эксплуатации (а не только разработки), а также сигналы, указывающие на то, что обертывание перестало быть временным решением.
Невозможность предоставить данные против невозможности изменений: две разные проблемы
Устаревшая система, которая не может предоставить данные, нуждается в интеграционном уровне. Устаревшая система, которая не может меняться, нуждается в модернизации. Путаница между ними — причина, по которой проекты по созданию «мостов» превращаются в постоянную работу по поддержке, на которую никто не подписывался.
Первый случай встречается чаще, чем признают большинство интеграционных аудитов.
ERP-система уже знает состояние заказа, флаг клиента, конвертацию единиц измерения: логика верна, данные надежны, и единственная реальная проблема заключается в том, что никто вне устаревшей системы не может получить к ним доступ, не пройдя через экран десятилетней давности.
Это проблема обмена данными, с которой сталкиваются многие организации при интеграции систем между отделами. Интеграционный уровень решает ее чисто, потому что внутри нет ничего, что нужно исправлять.
Второй случай иной, и у поставщиков услуг по модернизации есть стимул стирать эту грань. Если бизнес-логика в устаревшей системе неверна, машина состояний заказа больше не соответствует тому, как бизнес работает на самом деле, или поле единиц измерения означает три разные вещи в зависимости от того, какая команда его заполнила, — никакой фасад, как бы хорошо он ни был построен, этого не исправит.
Обертывание просто переносит связность на уровень выше и добавляет технический долг новой платформе вместо старой.
Шаблон «фикус-душитель» (strangler fig pattern), названный Мартином Фаулером, описывает замену возможностей устаревшей системы по частям, в то время как исходная платформа продолжает работать, а переключение происходит только после проверки каждой части. Это стратегия модернизации, а не интеграции, и о ней стоит знать, прежде чем инвестировать в интеграционный уровень для решения проблемы, для которой он никогда не предназначался.
Прямой доступ к базе данных: ловушка, которая кажется самой дешевой
Прямой доступ к базе данных — самый дешевый в реализации интеграционный шаблон и самый дорогой в устранении. Новый сервис подключается напрямую к устаревшей базе данных, минуя любой промежуточный слой.
Это кажется самым дешевым, потому что не нужно ничего проектировать. Ни фасада, ни брокера сообщений, ни контракта для версионирования. Разработчик открывает соединение, делает запрос к таблице заказов ERP и выпускает код. Счет приходит в тот момент, когда структура этой таблицы меняется под новым кодом.
Это дрейф схемы: внутренняя структура устаревшей базы данных меняется, столбец переименовывается, код статуса перепрофилируется, внешний ключ удаляется, и каждый потребитель, обращающийся к нему напрямую, ломается в один и тот же момент, без возможности отката к версии и без предупреждения.
Прямой доступ создает жесткую связь между системами, которые никогда не предназначались для совместного использования интерфейса. Новое приложение наследует внутреннюю модель данных устаревшей системы так, как если бы это был опубликованный контракт, но никто никогда не соглашался поддерживать его как таковой, а команда, создавшая схему, редко владеет ею в настоящее время.
Мы анализировали интеграционные уровни в ERP-проектах, где этот шаблон накапливался годами: полдюжины сервисов запрашивали одну и ту же таблицу заказов, основываясь на разных, недокументированных предположениях о том, что означает данный код статуса.
Прямой доступ к базе данных оправдан только в одном узком случае: короткий отчетный запрос к системе, которая уже запланирована к выводу из эксплуатации, где ничто ниже по потоку не зависит от долгосрочной стабильности.
Во всех остальных случаях он превращает недокументированную устаревшую схему в еще одну скрытую поверхность API, которую никто не выбирал поддерживать, а современные приложения, построенные поверх нее, наследуют этот риск, даже не видя его.
Когда API-фасад — правильный следующий шаг
API-фасад оправдывает свою стоимость, когда устаревшая система уже может ответить на вопрос, но не может сделать это в формате, который хочет использовать современная система.
Это переосмысление, над которым стоит задуматься: система, которая не может предоставить данные, и система, которая не может меняться, — это разные диагнозы, и только вторая нуждается в программе модернизации. Большинство ERP-систем попадают в первую категорию: данные есть, просто схема устарела на десятилетия.
API-фасад — это тонкий сервис, который вы создаете и поддерживаете сами; он находится перед устаревшей системой и переводит ее интерфейс в нечто, что может вызвать новое приложение, не зная о существовании устаревшей схемы. Он не затрагивает устаревший код, сохраняя безопасность и стабильность ваших существующих систем. Он обертывает их.
Не путайте это с API-шлюзом (API gateway), который использует другие базовые технологии для маршрутизации и управления запросами. Шлюз — это инфраструктура: маршрутизация, аутентификация, ограничение скорости, логирование запросов, находящиеся перед одним или несколькими бэкендами, включая фасад. Фасад — это логика трансляции; шлюз — это уровень трафика вокруг него.
Команды, которые пропускают фасад и ставят «голый» шлюз перед необработанными эндпоинтами ERP, получают лишь прямой доступ к базе данных с улучшенным логированием.
Стоимость разработки умеренная: один сервис, одна команда, определенный контракт. Стоимость эксплуатации — это то, что контент поставщиков интеграционных решений обычно опускает: кто-то должен владеть фасадом, когда поставщик ERP выпускает изменение схемы, и эта ответственность имеет тенденцию размываться, как только первоначальные разработчики уходят.
Фасад API — это неверное решение, если проблема заключается в самой модели устаревших данных: когда состояния заказов, флаги и поля единиц измерения в противном случае просочились бы прямо в код новых сервисов. Это задача уровня защиты от коррупции (anti-corruption layer), а не фасада.
Что такое уровень защиты от коррупции и когда он нужен?
Уровень защиты от коррупции — это граница трансляции, которая не позволяет модели данных устаревшей системы проникнуть в новый код. Он преобразует устаревшие концепции в доменную модель, соответствующую тому, что вы строите. В блоге Мартина Фаулера это определяется так: уровень, который выполняет трансляцию между двумя доменными моделями, чтобы изменения с одной стороны не просачивались на другую.
Устаревшая система не обязательно должна быть плохо спроектирована, чтобы оправдать его использование. Достаточно того, что ее модель данных не соответствует структуре, требуемой вашим новым сервисам.
ERP-системы — самый наглядный пример: состояния заказов, флаги клиентов и поля единиц измерения несут в себе десятилетия бизнес-правил, зашифрованных в непонятных кодах, и ничему из этого не место в чистой доменной модели.
Сигнал о том, что вам нужен уровень защиты от коррупции, появляется при проверке кода, а не на архитектурных диаграммах. Когда имя устаревшего поля или код статуса начинают появляться в коде нового сервиса без изменений, и рецензенту приходится спрашивать, что это значит, — это незваная связанность. Если оставить это без внимания, каждый последующий потребитель будет декодировать одни и те же устаревшие причуды независимо друг от друга.
Создание этого уровня требует реальных инженерных затрат: набор классов трансляции, тесты, фиксирующие маппинг, и место для бизнес-логики, которая раньше неявно существовала в старой схеме. Выгода заключается в том, что изменения в устаревшей системе остаются локализованными. Когда поставщик ERP переименовывает код статуса или добавляет значение, один уровень трансляции поглощает это изменение вместо того, чтобы оно затронуло всех потребителей.
Откажитесь от этого уровня, и вы получите фасад API в маскарадном костюме: он выглядит как слабосвязанный, но каждый потребитель все равно говорит на диалекте устаревшей системы, и цена этой связанности проявится позже, в самый неподходящий момент.
Когда потоковая передача событий или CDC лучше, чем фасад API
Потоковая передача событий и CDC (извлечение измененных данных) лучше фасада API, когда потребителям нужны данные постоянно, а не по запросу. Второй триггер — нагрузка: опрос устаревшей системы создает давление, на которое она не была рассчитана.
CDC считывает журнал транзакций устаревшей базы данных и превращает каждое изменение строки в событие, вообще не затрагивая код устаревшего приложения. Затем уровень потоковой передачи событий отправляет эти события в очередь сообщений или брокер, чтобы любое количество новых сервисов могло потреблять одно и то же изменение, не запрашивая ничего напрямую у устаревшей системы.
Грегор Хоппе и Бобби Вулф в книге «Enterprise Integration» описывают это как отделение производителей от потребителей через промежуточный канал, что является именно тем свойством, которое делает этот подход подходящим здесь: устаревшую систему перестают опрашивать и начинают наблюдать за ней.
Стоимость создания умеренная: CDC-коннектор к журналу транзакций, схема событий и контрактные тесты, которые громко сообщают об ошибке, если устаревшая схема меняется под ними.
Стоимость эксплуатации — это то, о чем умалчивают поставщики: инфраструктура брокера, мониторинг задержек потребителей и управление эволюцией схемы, которая растет вместе с количеством потребителей, а не количеством конечных точек. Перед тем как принять решение, стоит прочитать руководство AWS по событийно-ориентированной архитектуре, так как именно на гарантиях порядка и доставки команды часто обжигаются.
Режим отказа: столбец в устаревшей системе переименовывается или перепрофилируется, а коннектор продолжает работать, молча выдавая мусор, пока потребитель не заметит это.
Этот шаблон неверен, если у вас есть один потребитель, которому нужен синхронный ответ (фасад API там проще и дешевле), или если устаревшая база данных не предоставляет никакого полезного журнала, и в этом случае запланированный пакетный экспорт — это честный запасной вариант, а не настоящая потоковая передача.
Когда полноценная iPaaS действительно окупает свою лицензию
Платформа iPaaS окупает свою лицензию примерно при наличии дюжины систем, обменивающихся данными в разных форматах, ритмах и протоколах. Она не окупает себя, когда нужно связать первые две системы. При меньшем количестве фасад API или конвейер CDC строить и эксплуатировать дешевле.
Экономика меняется, потому что платформы iPaaS берут плату за коннекторы и объем данных, а не за сложность решаемой задачи. Ниже этого порога вы платите за оркестрацию, которая вам не нужна. Выше него создание вручную интеграций «точка-точка» между дюжиной систем порождает именно ту путаницу, для предотвращения которой и существует iPaaS: n² соединений, каждое из которых является потенциальным источником сбоев.
Здесь также стоит вспомнить историю сервисной шины предприятия (ESB). Шаблон ESB, описанный в книге Грегора Хоппе и Бобби Вулфа «Enterprise Integration», обещал одну шину сообщений для всего межсистемного трафика и на практике часто становился второй устаревшей системой, которой никто не хотел владеть.
Современные платформы iPaaS наследуют этот риск в новой форме: привязка к поставщику через проприетарные коннекторы, логика трансформации, зарытая в собственный DSL платформы, и счет, который растет вместе с количеством конечных точек независимо от реального использования. Этот шаблон мы постоянно видим в компаниях с большим количеством ERP, где цена за коннектор продолжает расти после того, как сама интеграция перестала меняться.
IPaaS — правильный выбор для системы, действительно состоящей из множества компонентов: ERP, CRM, управление складом и несколько SaaS-инструментов, обменивающихся данными по разным графикам. Это неверный выбор в качестве первого шага по умолчанию и неверный выбор для покупки до того, как количество конечных точек оправдает лицензию.
Во что обходится эксплуатация уровня интеграции
Стоимость эксплуатации уровня интеграции редко учитывается в бизнес-кейсе, который привел к его одобрению.
Стоимость создания — это проект с датой начала и окончания. Стоимость эксплуатации — это вычислительные мощности, лицензирование и тот единственный инженер, который еще помнит, почему уровень маппинга делает что-то странное с полями единиц измерения, и эта стоимость накапливается по-разному для каждого из описанных выше шаблонов.
IPaaS — самый наглядный пример. Лицензирование масштабируется в зависимости от количества коннекторов и конечных точек, а не от объема транзакций или использования. Добавьте пятую систему, и счет вырастет, независимо от того, передает ли эта система десять записей в день или десять миллионов. Мы видели, как бюджеты на интеграцию растут каждый год, хотя бизнес не получает от этого существенно больше данных, просто потому, что кто-то подключил еще одну конечную точку.
У прямого доступа к базе данных или фасада API такой проблемы нет: их эксплуатация почти ничего не стоит до того дня, пока под ними не изменится устаревшая схема, и в этот момент стоимость превращается в простой вместо счета.
Более глубокая стоимость эксплуатации — организационная, требующая инвестиций в инфраструктуру автоматизации и перепроектирование процессов. Уровни интеграции обычно переживают команды, которые их создали. Пять лет спустя никто из сотрудников не может объяснить логику повторных попыток или почему поток событий отбрасывает дубликаты сообщений о состоянии заказа, и каждое изменение в устаревшей системе с другой стороны становится гаданием, а не диагностикой.
Это технический долг особой формы: не запутанный код, а система, к которой никто не может безопасно прикоснуться. Платформы iPaaS обычно взимают плату за каждый коннектор, а не за каждый вызов, поэтому стоимость лицензии растет вместе с количеством систем, которые вы подключаете, а не с объемом трафика, который фактически проходит между ними.
Как не дать уровню интеграции превратиться в очередную устаревшую систему
Уровень интеграции становится очередной устаревшей системой, когда одновременно выполняются три условия: у него нет владельца, его никто не тестирует на соответствие системе, которую он оборачивает, и никто не зафиксировал, когда он должен быть выведен из эксплуатации. Все три проблемы решаемы на этапе сборки и стоят почти ничего по сравнению с ценой их обнаружения в будущем.
Контрактное тестирование — это первая линия защиты, и оно должно выполняться по отношению к самой устаревшей системе, а не только к предположениям новой службы о ней. Устаревшие системы меняются незаметно: исправленный модуль ERP, переименованный код статуса, состояние заказа, добавленное обновлением поставщика без уведомления кого-либо.
Набор контрактных тестов, привязанный к маппингу уровня предотвращения коррупции (anti-corruption layer), обнаруживает такие изменения в тот же день, а не через неделю, когда клиент замечает скрытое несоответствие данных в продакшене.
Во-вторых, назначьте владельца для уровня интеграции, который будет отличаться от владельца устаревшей системы и владельца новой платформы. Именно бесхозные уровни интеграции переживают инженеров, которые понимали их режимы отказа при проверках интеграции ERP и основных систем.
В-третьих, пропишите условие вывода из эксплуатации в проектной документации, а не в бэклоге. «Демонтировать после завершения миграции ERP» или «демонтировать, когда потребители начнут считывать данные напрямую из потока событий» — это реальные условия. Отсутствие условий означает, что вы построили постоянную систему под временным названием, а шаблон «душитель» Фаулера не дает никаких указаний по удалению строительных лесов, которые никто не решил убирать.
Сигнал к выходу, на который стоит обратить внимание: уровень интеграции развивает собственный цикл выпуска, отдаляясь от обеих систем, которые он соединяет, а логика маппинга растет с каждым кварталом, вместо того чтобы сокращаться. В этот момент вопрос о модернизации снова становится актуальным.
Сигналы к выходу: когда обертка перестает быть мостом
Обертка перестает работать, когда лежащая в ее основе система переходит из состояния «не может предоставить данные» в состояние «не может измениться». Это проблема, для решения которой обертка никогда не создавалась. Четыре сигнала говорят нам о том, что этот сдвиг произошел.
Первый: правила трансляции уровня предотвращения коррупции растут быстрее, чем реальная бизнес-логика устаревшей системы, что означает, что команда теперь поддерживает две модели данных вместо одной. Второй: никто в текущей команде не может объяснить режимы отказа устаревшей системы, только режимы отказа обертки: первоначальный владелец ушел, а технический долг внутри основной системы теперь невидим по умолчанию, а не по замыслу.
Третий: поставщик устаревшей системы перестал выпускать для нее патчи, поэтому каждая новая точка интеграции расширяет поверхность атаки, не получающую исправлений, вместо того чтобы изолировать ее. Четвертый: эксплуатационные расходы на уровень интеграции, нагрузка на дежурных инженеров, поддержка контрактных тестов, лицензия iPaaS теперь превышают стоимость реплатформинга, амортизированную за три года.
В совокупности эти сигналы часто проявляются в ходе более масштабных усилий по разработке корпоративного программного обеспечения, где ограничения устаревших систем должны сопоставляться с новой архитектурой и требованиями соответствия нормативным требованиям.
Любой из этих сигналов по отдельности управляем. Два или более вместе означают, что обертка незаметно стала устаревшей системой, и честным решением будет пересмотреть вопрос о модернизации, а не добавлять пятый шаблон поверх существующего. Наша концепция «7 R» — это правильная отправная точка для этого разговора, как только обертка перестает окупаться.
Если рассматриваемая устаревшая система — это платформа электронной коммерции, наше руководство по модернизации устаревшей платформы электронной коммерции подробно описывает стратегию, дорожную карту и компромиссы в отношении рисков.
Что такое интеграция устаревших систем?
Интеграция устаревших систем соединяет старую систему, например платформу ERP, с более новыми приложениями без переписывания самой системы. Она опирается на такие шаблоны, как фасад API, уровень предотвращения коррупции или потоковая передача событий, чтобы предоставлять данные и бизнес-логику на условиях самой устаревшей системы. Если выбрать неправильный шаблон, каждое новое приложение в конечном итоге окажется привязанным к старой схеме. Эти же шаблоны интеграции становятся еще важнее, когда в игру вступает ИИ, поскольку интеграция ИИ в такую среду требует такого же тщательного обращения с устаревшими данными и бизнес-логикой.
Как работает интеграция устаревших систем?
Интеграция устаревших систем работает путем вставки уровня между устаревшей системой и современными потребителями, который транслирует форматы данных, протоколы или тайминги, чтобы ни одной из сторон не приходилось меняться. Распространенные механизмы включают захват измененных данных (CDC) при чтении журналов базы данных или фасад API, оборачивающий вызовы устаревшей системы в современный контракт. Будущие изменения поглощает этот уровень, а не устаревшая система. Для команд, оценивающих, достаточно ли одной интеграции, более широкая концепция модернизации может помочь определить, когда обертывание должно уступить место более глубокой трансформации.
Как интегрировать устаревшую систему с API?
Создайте фасад API, который оборачивает существующие интерфейсы устаревшей системы в современный контракт REST или GraphQL, транслируя запросы и ответы на границе. Контрактные тесты, выполняемые по отношению к самой устаревшей системе, а не только к фасаду, обнаруживают поломки в тот момент, когда базовая система меняется. Это работает только в том случае, если устаревшая система уже может предоставлять поля, необходимые новому приложению.
Что такое уровень предотвращения коррупции (anti-corruption layer)?
Уровень предотвращения коррупции — это граница трансляции, которая предотвращает проникновение модели данных устаревшей системы в новый код. Термин взят из книги Эрика Эванса «Предметно-ориентированное проектирование» (Domain-Driven Design). Он отображает устаревшие концепции на чистую доменную модель на новой стороне. Создавайте такой уровень в тот момент, когда устаревшие поля начинают появляться без изменений в комментариях к проверке кода.
Стоит ли интегрировать или заменять устаревшую систему?
Интегрируйте, когда проблема устаревшей системы заключается в том, что она не может предоставить данные; заменяйте или модернизируйте, когда проблема в том, что она не может измениться. Обертка чисто решает первую задачу, но оставляет хрупкую логику, ограничения масштабирования и устаревшие платформы нетронутыми внутри. Наше руководство по «7 R» модернизации устаревших систем подробно рассматривает решение о замене. Если ограничением является сама базовая платформа, наши услуги по реплатформингу и модернизации помогут вам спланировать переход без нарушения бизнес-процессов.
Сколько стоит эксплуатация интеграции устаревших систем?
Эксплуатационные расходы — это то, что пропускает большинство материалов по интеграции. Уровень предотвращения коррупции или фасад API нуждается в назначенном владельце, мониторинге и контрактных тестах, поддерживаемых для каждого релиза устаревшей системы. Лицензии iPaaS обычно масштабируются в зависимости от количества конечных точек, а не от фактического использования, поэтому стоимость растет, даже если трафик в интегрированных системах остается неизменным. Планируйте бюджет на текущее обслуживание с первого дня, а не только на первоначальную сборку.
Как определить, стоит ли оборачивать или заменять
Большинству организаций нужно и то, и другое. Вопрос в том, какие системы получат уровень интеграции, который даст им годы жизни, а какие должны измениться изнутри — и для ответа на него нужна карта зависимостей, прежде чем понадобится дорожная карта.
Наша команда оценивает этот анализ применительно к системам, которые вы фактически используете, а затем выстраивает последовательность работ так, чтобы ничего не переписывалось раньше времени. Поговорите с нами о вашей инфраструктуре, прежде чем выделять бюджет на любой из этих путей.
