# Сервисно-ориентированная архитектура в BSS/OSS оператора

Источник: https://fw-t.ru/articles/zachem-i-kak-servisno-orientirovannaya-arkhitektura-soa-dolzhna-rabotat-na-vas
Опубликовано: 2024-06-11 · Обновлено: 2026-09-15

Что дает сервисная архитектура в контуре оператора связи: замена одного продукта без переделки остальных, переиспользование интеграций, поэтапная миграция.

**Коротко.** Сервисная архитектура в контуре оператора решает одну практическую задачу: заменить или добавить систему, не переделывая остальные. Каждый продукт публикует свои функции как сервисы с описанным интерфейсом, и связи идут через них, а не напрямую между базами. Отсюда поэтапная миграция вместо замены всего контура разом и повторное использование интеграций.

Сервисно-ориентированная архитектура в контуре оператора решает конкретную задачу: заменить или добавить систему, не переделывая остальные. Общая теория здесь вторична — важно, что происходит при первом же проекте замены.

## Что меняется на практике

| Ситуация | Прямые связи | Сервисный контур |
| --- | --- | --- |
| Замена одного продукта | Задевает все подключенные системы | Меняется реализация, интерфейс остается |
| Подключение новой системы | Интеграция с каждой из существующих | Подключение к описанным сервисам |
| Миграция | Переключение всего контура разом | Поэтапно, с параллельной сверкой |
| Изменение в одной системе | Проверка всех связей | Проверка контракта сервиса |
| Число связей | Растет квадратично с числом систем | Растет линейно |

Последняя строка — та, из-за которой ландшафт со временем становится неуправляемым. Десять систем, соединенных напрямую, дают десятки связей, каждую из которых кто-то должен помнить.

## Связь с импортозамещением

Именно эта архитектура делает замену зарубежных систем выполнимой по частям. Продукт заменяется на отечественный, пока остальной контур работает как раньше; затем следующий. Разбор такого перехода — в статье [об альтернативе иностранному ПО](/articles/alternativa-inostrannomu-po-upravlenie-riskami-smena-postavsika-i-poisk-gibkoj-sistemy).

Без сервисного слоя проект приходится делать целиком. Это другой бюджет, другой срок и риск, который не всякий оператор готов принять.

## Что это дает при миграции

Пока старая и новая системы отвечают на одни и те же вызовы, их результаты можно сверять на реальных данных и переключаться после сверки, а не до нее. В [«ВТБ Мобайл»](/cases/vtb-mobile) миграция заняла пять месяцев, услуги связи работали без перерыва. В [«Алма ТВ»](/cases/project-almatv) в один расчетный центр сводились шестнадцать филиалов с разными системами, и делалось это поэтапно.

## Цена подхода

Дисциплина описания. Интерфейс, который меняют произвольно, перестает быть интерфейсом, и контур возвращается к прямым связям под другим названием. Поэтому сервисный подход работает там, где у каждого сервиса есть владелец и регламент изменений.

Состав контура целиком разобран в статье [о BSS и OSS в телекоме](/articles/bss-oss-v-telekome) и на странице [решения для оператора](/solutions/oss-bss).

## Вопросы и ответы

**Что дает сервисная архитектура оператору связи?**

Возможность менять контур по частям. Когда системы связаны напрямую, замена одной из них задевает все, что к ней подключено, и проект превращается в замену всего контура. Когда каждая публикует свои функции как сервисы с описанным интерфейсом, заменяется реализация, а интерфейс остается — остальные системы изменения не замечают.

**Как это влияет на импортозамещение?**

Напрямую: оно становится выполнимым поэтапно. Зарубежная система заменяется отечественной по одному продукту за раз, пока остальной контур работает как работал. Без сервисного слоя такой проект приходится делать целиком, а это другой бюджет, другой срок и совсем другой риск.

**Зачем нужен интеграционный слой, если системы умеют обмениваться напрямую?**

Из-за числа связей. Прямые интеграции между n системами дают порядка n в квадрате связей, каждую из которых нужно поддерживать при изменении любой стороны. Сервисный слой сводит это к описанным интерфейсам: новая система подключается к существующим сервисам, а не к каждой системе отдельно.

**Это про микросервисы?**

Не обязательно. Сервисный подход говорит о том, как системы договариваются между собой, а размер и способ развертывания каждой из них — отдельный вопрос. Монолитный продукт с описанным сервисным интерфейсом встраивается в такой контур нормально, и в BSS-ландшафтах это распространенный случай.

**Что это дает при миграции данных?**

Возможность параллельной работы. Пока старая и новая системы отвечают на одни и те же сервисные вызовы, их результаты можно сверять на реальных данных, а переключение делать после сверки. В проекте ВТБ Мобайл миграция заняла пять месяцев, и услуги связи при этом работали без перерыва.

**В чем цена такого подхода?**

В дисциплине описания. Интерфейс, который меняют произвольно, перестает быть интерфейсом, и контур возвращается к прямым связям под другим названием. Поэтому сервисный подход работает там, где есть регламент изменений и владелец каждого сервиса. Одной технической возможности мало.