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