SID - модель данных для цифрового провайдера

11.05.2013

Автор: Виктор Рудь

SID — модель данных, разработанная TM FORUM для цифровых сервисных компаний (провайдеров цифровых услуг). SID-модель — Shared information & Data Model.

Модель данных SID построена в объектной парадигме и представляет собой множество взаимосвязанных классов. Эти классы можно использовать «как есть», а можно считать их абстракциями и порождать от них что-то специфичное под собственные нужды. SID демонстрирует как высокий стиль объектного моделирования, так и ширину охвата всей деятельности цифрового оператора.

Поскольку SID технологически нейтральна, а также создан в независимой от реализации манере, то можно считать его концептуальной моделью данных в ландшафте цифрового провайдера. Слово «концептуальный» здесь следует понимать, как указание на обобщение ряда логических моделей данных отдельных приложений.

Адаптация модели SID — постоянная услуга компании «Марк Аврелий». При этом чаще всего приходится заниматься не столько мапированием логической модели данных SID на логические или физические структуры данных заказчика, сколько адаптацией понятийной модели заказчика (терминология, глоссарии) к терминологии SID. Истоки такого понятийного расхождения лежат в русле проблематики DDD (Domain Driven Design).

Какие основные трудности вызывает работа с моделью SID?

Трудность № 1. Непонимание различий между КЛИЕНТ-АБОНЕНТ-Лицевой счет. Слово «абонент» приходится тщательно выкорчевывать из российского менталитета, но оно там плотно засело, как абонементы в бассейн. При этом не каждый телеком-спец может объяснить значение и этимологию слова АБОНИРОВАТЬ.

Трудность № 2. Непонимание различий между INTERACTION и REQUEST. Если бы эти два слова сохранились (перекочевали в русский язык) в своей англоязычной форме, то проблем бы не было совсем. Однако в русский язык плотно вошло, что INTERACTION — это обращение и всё, что в компании происходит с обращениями клиентов — это всё «управление обращениями». Обращениями можно управлять днями, неделями и месяцами... При этом REQUEST и ORDER существуют строго в параллельном мире российского связиста и он не знает точно, как их с обращениями подружить. Подобная же судьба у физической сущности CASE, которая может быть чем угодно в зависимости от кастомизации. CASE может быть и претензией и запросом в тех.поддержку и даже заявкой на продажу услуги.

Трудность № 3. Чем отличается продукт от услуги? Многие пытаются нагрузить это своими собственными, уникальными смыслами, придуманными прямо по ходу совещания. Молодцы! — только жаль, что воз и ныне там. К дилемме продукт-услуга подмешивается еще и СЕРВИС, непонятно откуда взявшийся перевод слова УСЛУГА, который оторвался от «услуги» и стал жить в русском языке самостоятельной жизнью.

Трудность № 4. Чем отличается продуктовое предложение от продукта, спецификации продукта и тарифного плана. Почему во всем мире продают «предложения», а в России — тарифные планы? Рассуждать на эту тему вообще нельзя, так как это не понятия — а информационные объекты, понимание которых возможно только с позиций объектно-ориентированного программирования и проектирования.

Трудность № 5. Продукт-каталог. Некоторые думают, что это такой вид программного обеспечения, который подарен маркеталогам для наведния порядка в их голове. Совершенно нет! Это конструктор объектов, причем самых любых объектов самой различной природы. В продукт-каталоге действительно можно сконструировать объекты продажи такие, например, как продукты. Но это всего лишь одно из многочисленных частных применений технологии каталогизации, которую следует более правильно называть «информационное конструирование».

Методическое замечание: хотя объектные модели обычно представляют собой модели данных, тем не менее следует рассматривать каждый объект не столько как концентратор данных, а как объекты поведения — набор методов, сгруппированных вокруг данных. Сами методы следует искать в еТОМ: в настоящее время официальное название еТОМ — Business Process Framework от TM FORUM.



Список статей