Перехід на Open Digital Architecture (ODA) стає критичним кроком для телеком-операторів. Монолітні BSS/OSS системи більше не здатні підтримувати динаміку сучасного ринку, блокуючи швидке впровадження інновацій, таких як AI-агенти та cloud-native сервіси. Проте повна заміна застарілого ядра (legacy) за принципом «big bang» несе колосальні ризики: від зупинки критичних бізнес-процесів до збоїв у роботі мережі. Операторам потрібна стратегія поступової, безпечної модернізації, яка дозволяє оновлювати ІТ-ландшафт частинами, зберігаючи стабільність надання послуг.
Чому монолітні BSS/OSS стали бар'єром для AI та нових тарифів
Телеком-індустрія тривалий час будувалася на монолітних рішеннях, де CRM, білінг, продуктовий каталог та системи управління мережею (OSS) були тісно інтегровані на рівні баз даних та пропрієтарного коду. Будь-яка зміна в тарифікації або спроба вивести на ринок новий конвергентний продукт вимагала місяців розробки та тестування.
Сьогодні стандартизація 3GPP забезпечує сумісність обладнання, а архітектура 5G core (service-based architecture) наближає телеком до cloud-native принципів. На цьому тлі застарілі BSS/OSS системи залишаються головним вузьким місцем. За оцінками, до 53.7% бюджетів на інтеграцію в телекомі може витрачатися на підтримку заплутаних зв'язків типу «точка-точка» між legacy-системами. Це унеможливлює швидке підключення зовнішніх партнерів. Наприклад, спроба інтегрувати сучасного AI-агента для обслуговування клієнтів безпосередньо в монолітний CRM часто призводить до деградації продуктивності бази даних та створює серйозні архітектурні ризики.
Анатомія ODA: як стандарти TM Forum змінюють підхід до телеком-архітектури
Open Digital Architecture (ODA), розроблена консорціумом TM Forum, пропонує референсну модульну архітектуру. Вона замінює моноліти на компонентовану, API-first структуру для автономних операцій. Замість єдиного «чорного ящика» ODA розділяє ІТ-ландшафт оператора на чітко визначені функціональні домени:
- Engagement (взаємодія з клієнтами та партнерами);
- Party (управління інформацією про суб'єктів);
- Core Commerce (каталоги, замовлення, білінг);
- Production (управління ресурсами та послугами);
- Intelligence (аналітика та ШІ-сервіси).
Кожен домен складається з окремих ODA-компонентів, які взаємодіють виключно через стандартизовані TM Forum Open APIs. Це дозволяє операторам замінювати окремі модулі від різних постачальників без переписування всієї системи. Проте безпечний перехід на таку архітектуру потребує правильної стратегії.
Стратегія Strangler Fig: поетапна заміна legacy без зупинки білінгу
Для мінімізації ризиків використовується паттерн проектування Strangler Fig («фікус-душитель»). Його суть полягає в тому, що стара монолітна система поступово огортається новими мікросервісами та API-шлюзами, які перехоплюють виклики. З часом функції переносяться в нові компоненти, а моноліт виводиться з експлуатації.
Реальні сценарії застосування цієї стратегії включають:
- Поступову заміну модуля білінгу на cloud-native компонент при збереженні старого CRM через інтеграційний шар.
- Використання low-code платформи для створення API-шлюзу, який об'єднує дані зі старих баз даних та нових мікросервісів.
- Впровадження AI-агента для підтримки клієнтів, який звертається до даних через стандартизовані Open API, не зачіпаючи ядро legacy-системи.
Модульність ODA дозволяє оновлювати окремі компоненти за тижні, а не місяці. Застосування стратегії Strangler Fig знижує ризики простою системи з критичних до керованих.
Low-code як інтеграційний міст: поєднання UnityBase зі старим ядром
Ключовим елементом реалізації паттерну Strangler Fig є створення гнучкого інтеграційного шару. Він має не просто перенаправляти трафік, а трансформувати моделі даних legacy-систем у стандартизовані структури.
Як технологічний фундамент для таких завдань телеком-практика Intecracy Group використовує low-code платформу UnityBase (спільна розробка компаній альянсу; ключовий розробник — компанія InBase). Завдяки концепції Domain metadata (єдиній моделі даних, інтерфейсу та API) та DBMS-agnostic ORM, платформа дозволяє автоматично генерувати REST API та швидко зв'язати legacy BSS/OSS із новими ODA-компонентами.
Наприклад, для операторських VoIP-рішень, таких як DooxSwitch, подібний архітектурний підхід спрощує обмін даними CDR та інтеграцію білінгу з іншими системами. Для mission-critical середовищ UnityBase підтримує рольовий доступ (RBAC), розмежування на рівні записів (RLS) та детальний аудит (audit trail). Для проектів із високим навантаженням або підвищеними вимогами до безпеки офіційно рекомендується використовувати комерційні редакції Enterprise або Defence, що забезпечують розширені інструменти шифрування та інтеграцію з Active Directory.
Підготовка до AI Act та впровадження AI-агентів через стандартизовані Open API
Коли AI-агент намагається отримати доступ до даних клієнта, він не повинен звертатися до legacy-таблиць напряму. Замість цього він має взаємодіяти через ODA-сумісні Open API. Це забезпечує прозорість, керованість та контроль даних — ключові вимоги сучасних регуляцій, таких як AI Act.
Варто зазначити, що перехід на ODA не вирішує автоматично всі проблеми кібербезпеки, а лише створює надійну архітектурну базу для управління доступом. Також не слід очікувати миттєвого усунення технічного боргу. Близько 27.7% витрат на підтримку legacy-компонентів можуть зберігатися на проміжних етапах міграції, проте це виправдана ціна за збереження безперервності бізнесу під час масштабної трансформації.
Покроковий алгоритм міграції BSS/OSS на ODA за стратегією Strangler Fig
- Крок 1: Аудит та мапування поточних legacy-інтерфейсів на ODA-компоненти (TM Forum Open API).
- Крок 2: Розгортання інтеграційного шару (наприклад, на базі low-code платформи UnityBase) для створення єдиної моделі даних.
- Крок 3: Виділення першого критичного модуля (наприклад, self-service порталу) та створення для нього API-шлюзу.
- Крок 4: Запуск нового cloud-native компонента паралельно з legacy-модулем та поступове переспрямування трафіку.
- Крок 5: Повне відключення старого модуля після стабілізації роботи та перехід до наступного компонента (білінг, CRM).
Поширені питання
Як почати перехід на ODA, якщо бюджет обмежений і немає можливості замінити весь BSS/OSS?
Найефективніший шлях — використання патерну Strangler Fig. Замість повної заміни системи, створюється проміжний інтеграційний шар. Це дозволяє виділяти та замінювати окремі модулі (наприклад, кабінет користувача) поступово, не порушуючи роботу основного ядра.
Чи забезпечує ODA сумісність із 5G core архітектурою та стандартами 3GPP?
Так. Архітектура 5G core (стандарти 3GPP) побудована на принципах service-based architecture, що повністю збігається з ідеологією ODA від TM Forum. Обидва підходи базуються на cloud-native принципах та API-first взаємодії.
Яка роль low-code платформ у модернізації телеком-систем за стандартами TM Forum?
Low-code платформи, такі як UnityBase, виступають інтеграційним мостом. Вони дозволяють трансформувати legacy-дані у стандартизовані структури, генерувати REST API та керувати доступом (через RBAC/RLS), що значно прискорює розгортання ODA-сумісних компонентів.
Джерела даних
- TM Forum: Open Digital Architecture (ODA)
- 3GPP — Mobile Standards
- medium.com: Open Digital Architecture (ODA): A Cloud-Native Blueprint for Modern Telco Platforms | by Adheesha Gamage | ADL Blog | Medium
- fiercenetwork.com: Was TM Forum ahead of its time with its Open Digital Architecture? - Fierce Network