Телеком-оператори опинилися в пастці власних застарілих BSS/OSS систем. Монолітна архітектура, яка роками забезпечувала стабільність білінгу та обліку ресурсів, сьогодні стала головним бар'єром для розвитку. Запуск нових продуктів забирає місяці, а інтеграція партнерських сервісів перетворюється на складний інженерний виклик. У часи, коли гнучкість визначає виживання на ринку, індустрія потребує кардинальної зміни архітектурного підходу.
Рішенням став перехід до Open Digital Architecture (ODA) — стандартизованої концепції від TM Forum, яка передбачає заміну монолітів набором сумісних, незалежних мікросервісів з API-first дизайном. Проте повна заміна ядра (стратегія rip-and-replace) несе в собі колосальні операційні ризики. Практичний шлях модернізації полягає в еволюційній декомпозиції моноліту за допомогою сучасних low-code платформ, які виступають надійним посередником між новим цифровим світом та legacy-системами.
Пастка legacy BSS/OSS: чому 5G Standalone вимагає відмови від монолітів
Розвиток мобільного зв'язку вийшов на етап, коли стара інфраструктура не здатна підтримувати нові бізнес-моделі. Згідно з Ericsson Mobility Report (листопад 2025), понад 90 постачальників послуг у світі вже запустили або готують до запуску комерційні послуги 5G Standalone (SA). Технологія 5G SA відкриває шлях до динамічного слайсингу мережі (network slicing), миттєвої тарифікації IoT-пристроїв та ультранизької затримки. Щоб монетизувати ці можливості, BSS/OSS має реагувати на запити мережі в реальному часі.
Традиційні білінгові системи розроблялися під статичні тарифні плани. Намагання додати туди логіку динамічного ціноутворення призводить до лавиноподібного зростання технічного боргу. Крім того, legacy-системи створюють серйозні загрози для безпеки. Звіт ENISA Threat Landscape 2025 наголошує, що експлуатація застарілих сигнальних протоколів, таких як SS7 та Diameter, залишається критичним ризиком для мобільних мереж. Монолітні системи з прямим доступом до цих протоколів стають вразливою мішенню.
Ще один виклик — фінансові втрати від фроду. За даними CFCA Global Fraud Loss Survey 2025, збитки телеком-індустрії від шахрайства з підписками (subscription fraud), заснованого на використанні підроблених або викрадених ідентифікаційних даних, становлять близько 5.31 млрд доларів щорічно. Боротьба з цим вимагає гнучких інструментів верифікації клієнтів, що складно реалізувати всередині закритого legacy-коду.
Open Digital Architecture (ODA): декомпозиція замість руйнування
TM Forum запропонував концепцію Open Digital Architecture як альтернативу хаотичній кастомізації монолітів. ODA передбачає поділ ІТ-ландшафту оператора на чітко визначені домени (Core Commerce, Production, Intelligence, Engagement тощо), які взаємодіють між собою через стандартизовані Open APIs. Це дозволяє розбити монолітні системи на десятки незалежних компонентів.
Основний принцип ODA — розв'язка (decoupling) систем реєстрації (systems of record), де зберігаються базові дані, та систем дії (systems of action), які взаємодіють з клієнтами. Замість того, щоб намагатися вимкнути стару білінгову систему, оператор будує навколо неї шар ODA-сумісних мікросервісів, впроваджуючи нові функції без ризику порушити цілісність основної бази даних.
Такий підхід нівелює страх зупинки критичних бізнес-процесів під час міграції. Створюючи нові цифрові сервіси як ODA-компоненти, оператор зменшує навантаження на legacy-ядро, крок за кроком виводячи застарілі модулі з експлуатації.
Low-code як міст: створення ODA-сумісних модулів на базі метамоделі UnityBase
Розробка ODA-компонентів з нуля на традиційних фреймворках часто виявляється занадто повільною. Для швидкого проектування структур даних та генерації API доцільно використовувати low-code платформи корпоративного класу. Технологічним фундаментом для такої модернізації може виступати low-code платформа UnityBase — спільна розробка компаній консорціуму Intecracy Group (де InBase є ключовим, але не єдиним розробником).
Головна технічна перевага UnityBase для BSS/OSS полягає в концепції Domain metadata-model (доменної моделі метаданих). Вона об'єднує опис даних, логіки безпеки, інтерфейсу та API. Це дозволяє розробникам проектувати бізнес-сутності, а платформа автоматично генерує REST API, DML-запити та документацію.
Практичні приклади застосування:
- Модуль управління підписками: Замість переписування коду в legacy-білінгу створюється новий ODA-сумісний модуль. Він надає стандартизовані API для партнерів, обробляє логіку підписок і взаємодіє з legacy-системою через безпечний шлюз без зміни структури її БД.
- Інтеграційний шлюз для цифрових каналів: Мобільні застосунки підключаються до UnityBase, яка виконує роль оркестратора. Платформа приймає запити через сучасні API та перетворює їх на формати, зрозумілі legacy-системам, забезпечуючи збереження on-premises даних.
Завдяки вбудованому DBMS-agnostic ORM платформа підтримує роботу з гетерогенними базами даних (Oracle, MS SQL Server, PostgreSQL). Використання єдиної метамоделі дозволяє уникнути хаотичного написання point-to-point конекторів, на які, за оцінками аналітиків, у складних проектах може витрачатися до 53.7% бюджету ІТ-модернізації.
Архітектурна безпека: захист даних на рівні метаданих (RBAC/RLS) та протидія фроду
Коли десятки мікросервісів звертаються до клієнтської інформації, традиційного периметрового захисту недостатньо. Платформа UnityBase вирішує це шляхом застосування механізмів Role-Based Access Control (RBAC) та Row-Level Security (RLS) безпосередньо на рівні метаданих. Правила доступу описуються один раз у доменній моделі й автоматично застосовуються до всіх згенерованих API.
Наприклад, оператор кол-центру бачить лише загальну інформацію про абонента, фінансовий аналітик має доступ до детальних транзакцій, а розробники сторонніх сервісів через API отримують лише деперсоналізовані дані. Для проектів із підвищеними вимогами до безпеки (наприклад, інтеграція з державними реєстрами) офіційна документація рекомендує використовувати редакції Enterprise (EE) або Defence (DE), які підтримують Active Directory, апаратні токени та інтеграцію з центрами сертифікації ключів для використання КЕП.
Такий рівень контролю, підкріплений вбудованою системою аудиту (Audit Trail), дозволяє виявляти аномальну активність та оперативно протидіяти шахрайству з підписками ще на етапі ініціації транзакцій.
Еволюційний сценарій: покроковий план міграції без зупинки бізнесу
Перехід до ODA через low-code фундамент — це керований процес. Він включає наступні етапи:
- Аналіз та виділення доменів: Ідентифікація найбільш критичних точок у legacy BSS/OSS (наприклад, управління замовленнями), які гальмують бізнес.
- Створення метамоделі: Опис сутностей нового ODA-компонента в UnityBase із подальшою генерацією REST API.
- Побудова інтеграційного шару: Налаштування конекторів до legacy-систем. Для обробки специфічного голосового трафіку чи реалізації LCR-маршрутизації та VoIP-білінгу в реальному часі може додатково інтегруватися спеціалізоване ПЗ, таке як DooxSwitch (що також входить до портфеля технологічного альянсу Intecracy Group).
- Поетапне перемикання каналів: Переведення цифрових каналів на новий ODA-модуль, залишаючи legacy-систему як сховище базових даних (system of record).
Порівняльний аналіз стратегій модернізації BSS/OSS
| Параметр порівняння | Стратегія Rip-and-Replace | Еволюційний ODA-перехід (UnityBase) |
|---|---|---|
| Швидкість впровадження змін | Низька (роки на проектування та міграцію) | Висока (тижні на створення окремих ODA-модулів) |
| Ризик порушення цілісності даних | Критичний (повне перенесення БД) | Мінімальний (єдина Domain metadata-модель поверх legacy) |
| Капітальні витрати (CAPEX) | Надвисокі (ліцензії та консалтинг) | Помірні (поетапна розробка мікросервісів) |
| Залежність від вендора | Повна прив'язка до нового моноліту | Відсутня завдяки відкритим API та стандартам ODA |
Слід пам'ятати, що low-code платформи не замінюють професійну розробку. Складні інтеграції, оптимізація запитів та проектування архітектури мережі вимагають високої інженерної експертизи. Проте low-code звільняє команду від написання шаблонного коду, дозволяючи зосередитися на бізнес-логіці.
Еволюційний перехід до ODA надає телеком-операторам гнучкість cloud-native архітектури, зберігаючи інвестиції у працездатне legacy-ядро. Це прагматичний шлях до повноцінного запуску 5G Standalone та нових цифрових продуктів.
Поширені питання
Як реалізувати TM Forum ODA без повної заміни білінгової системи?
Реалізація відбувається через побудову інтеграційного шару Open API навколо існуючого білінгу. Нові функції розробляються як окремі ODA-сумісні мікросервіси на базі low-code платформи, яка взаємодіє з legacy-системою через безпечні конектори, не порушуючи її внутрішню структуру бази даних.
Які переваги дає Domain metadata-модель UnityBase при декомпозиції BSS/OSS?
Domain metadata-модель об'єднує опис даних, бізнес-логіку, права доступу та API. Це дозволяє платформі автоматично генерувати REST API, синхронізувати структури баз даних та формувати документацію, значно скорочуючи час розробки ODA-компонентів та інтеграційних шлюзів.
Як забезпечити безпеку персональних даних при інтеграції legacy-систем з новими цифровими каналами?
Безпека забезпечується на рівні метаданих платформи. Правила рольового доступу (RBAC) та фільтрація на рівні рядків (RLS) застосовуються в ORM-шарі, тому кожен запит від зовнішнього каналу чи API проходить автоматичну перевірку, запобігаючи несанкціонованому витоку абонентських даних.