У кожній великій організації є «та сама стара система» — написана 15-20 років тому, на технологіях, які вже не підтримуються, але працює і виконує критичну бізнес-функцію. Замінити її страшно, ігнорувати — небезпечно. Як бути?
Чому legacy не можна просто «виключити»
Legacy-системи зазвичай містять роки накопиченої бізнес-логіки, яка ніде не задокументована. Вони обслуговують критичні процеси — облік, розрахунки, звітність. Їх замінити одномоментно — все одно що замінити двигун літака під час польоту.
Стратегія Strangler Fig Pattern
Замість повної заміни використовується поступове «обгортання» legacy-системи новими компонентами. Нова функціональність будується поруч зі старою, а інтеграційний шар поступово перемикає потоки даних з legacy на нові модулі.
Цей підхід дозволяє мігрувати поступово, без «великого вибуху», зберігаючи безперервність бізнес-процесів.
Практичні кроки інтеграції
Перший крок — побудова «антикорупційного шару» (Anti-corruption Layer). Це проміжний компонент, який транслює дані між старою та новою системами, захищаючи нову архітектуру від обмежень legacy.
Другий крок — реалізація API-обгорток для legacy. Навіть якщо стара система не має API, можна побудувати обгортку через прямий доступ до бази даних або файловий обмін.
Третій крок — паралельна робота. Обидві системи працюють одночасно, а дані синхронізуються через інтеграційний шар. Це дозволяє поступово переводити користувачів на нову систему.
Реальний кейс
В одному з наших проєктів замовник мав облікову систему на Clipper (так, 1990-х років). Замінити її одномоментно було неможливо — в ній працювало 200+ користувачів. Ми побудували REST API-обгортку, яка читала дані з Clipper-бази, підключили нову веб-систему, і протягом 8 місяців повністю мігрували без жодного дня простою.