NGOSS

NGOSS

NGOSS (New Generation Operation System and Software) — созданный в рамках TMF подход к разработке, внедрению и использованию систем поддержки операционной деятельности для компаний операторов связи, разработчиков OSS/BSS, системных интеграторов и поставщиков информационных сервисов. Основная идея подхода — предоставить телекоммуникационому сообществу инcтрументы для построения и обеспечения ключевых сквозных бизнес процессов.

Принципы

NGOSS базируется на пяти ключевых принципах:

• Разделение бизнес-процессов и применяемых технических компонентов;

• Распределенная система с нежёсткими связями между ее элементами;

• Общая информационная модель;

• Совместно используемая инфраструктура связи;

• Четко установленные определенные интерфейсы.

Разделение бизнес-процессов и применяемых технических компонентов

Когда OSS системы связаны вместе, бизнес-процессы, которые они поддерживают, распространяются на всю IT сферу предприятия. В результате возникает ситуация, когда некий процесс стартует из приложения A, которое обрабатывает некие данные и которое в «знает», что затем оно должно вызвать приложение B, которое в свою очередь также произведет обработку данных и вызовет приложение С и т.д. Как следствие, крайне тяжело определить какой из этапов процесса является текущим в данный момент (например, при выставлении счета клиенту, как в можно определить какое приложение (A, B или C) обрабатывает в данный момент информацию о счете?). И еще более является задача изменить данный процесс, вследствие его распределенной природы. NGOSS предполагает, что процесс должен управляться как часть централизованной инфраструктуры с использованием какого-либо механизма, обеспечивающего последовательность выполнения действий и ответственного за осуществление контроля хода бизнес-процесса от одного приложения до другого. Таким образом, данный механизм инициировал бы процесс на приложении A, которое затем бы возвращало контроль обратно. Затем данный механизм вызывал бы приложение B и так далее. В таком случае, было бы всегда возможно определить какой из этапов бизнес-процесса выполняется в данный момент времени, поскольку контроль за его ходом был бы уже централизованным. При этом изменения процесса могли бы производиться с использованием определенного инструментария упомянутого механизма. Ясно, что некоторые составляющие процесса нижнего уровня будут встроены в отдельные приложения, но это должно располагаться ниже того уровня, на котором выполняются значимые для бизнеса функции, то есть ниже того уровня на котором функционируют применяемые стандарты и политики предприятия.

Распределенная система с нежёсткими связями между ее элементами

Нежёсткая связь между элементами предполагает, что каждое приложение является сравнительно независимым от других приложений в рамках общей системы. Таким образом, в окружении с нежёсткими связями, в одно приложение могут быть внесены изменения без влияния на другие приложения, обычно неизбежное в подобных случаях. По крайней мере, данный принцип иногда может рассматриваться, как предоставление возможности внедрять приложения по схеме «plug and play», поскольку они являются настолько независимыми по отношению друг к другу, что могут быть заменены без влияния на систему в целом. Использование «распределённой системы» еще раз подчеркивает, что NGOSS основан не на использовании телекоммуникационной компанией единого монолитного приложения для управления всеми операциями предприятия, но, вместо этого, предлагается использовать набор интегрированных и взаимодействующих друг с другом приложений.

Общая информационная модель

Интеграция OSS систем означает, что приложения должны «уметь «обмениваться друг с другом различного рода данными. И чтобы данный процесс был эффективным, каждое приложение, должно «знать» как любое другое приложение «понимает» или интерпретирует тот или иной блок переданных данных. Чтобы разобраться в этом, можно использовать пример предоставления клиенту информации о счете: приложение А принимает запрос клиента о выставленном счете и производит отправку данной информации, используя при этом приложение Б (биллинговую систему). Приложение А будет иметь сведения об адресе клиента и необходимо чтобы приложение Б отправило счет именно на этот адрес. Чтобы происходил обмен данными между системами им необходимо иметь стандартный формат информации об адресе: количество строк адресной информации, количество символов в каждой строчке – все это для каждой системы должно быть одинаковым и каждое приложение знает с каким форматом работает другое приложение . Все достаточно очевидно и просто. Но можно вообразить трудности с которыми пришлось бы столкнуться, если приложение А работало бы с продуктами, которые состоят бы из нескольких подпродуктов (широкополосный доступ по медным линиям, модем, набор фильтров и широкополосного преобразования) и передавало бы весь спектр данных приложению Б, тогда как приложение Б ожидало получить только одну строчку данного продукта/заказа. Попытка преобразовать иерархические продукты в неиерархические, не теряя при этом информацию, была бы невозможна. Единая информационная модель для данных, которыми обмениваются приложения , обеспечивает решение этой проблемы. Решение от TMF называют Общей информационной моделью.

Совместно используемая инфраструктура связи

Изначально (примерно в середине 80-х годов) OSS-системы развивались как отдельные приложения. Однако, вначале 90-х, стало очевидно, что применение данных систем как отдельных приложений было в высшей степени неэффективно, поскольку это приводило к ситуации, когда, например, заказ принимается в одной системе, а затем некие детали из данного заказа переносятся в другую систему в целях конфигурирования соответствующего сетевого оборудования. Главный выигрыш в эффективности от объединения отдельных OSS-систем – это приобретение такой возможности как «Flow-through provisioning» ( «мониторинг хода процесса»), когда заказ мог бы быть размещен он-лайн и происходил бы автоматический мониторинг получаемого результата без участия персонала. Однако, для крупных операторов связи с сотнями отдельных OSS-систем, быстрое увеличение интерфейсов стало серьёзной проблемой. Каждое OSS должно было "говорить" со многими другими, приводя к экспоненциальному росту числа интерфейсов при увеличении числа OSS-систем. NGOSS описывает использование Совместно используемой инфраструктуры связи (Common Communications Infrastructure , CCI). В этой модели OSS-системы взаимодействуют с CCI, а не непосредственно друг с другом. CCI таким образом позволяет приложениям взаимодействовать, используя CCI, для их соединения. Таким образом, каждое приложение требует только одного интерфейса (к CCI), а не многих (ко всем другим приложениям). Таким образом, значительно снижена сложность всей системы. Также CCI может обеспечивать другие сервисы, включая обеспечение безопасности, преобразование данных и т.д.

Четко установленные определенные интерфейсы.

Давая выше описание принципа взаимодействия приложений с CCI, становится ясно, что необходимо иметь способ задокументировать эти интерфейсы, причем как с точки зрения применяемой технологии (например, Java/JMS или Web-сервисы/SOAP), так и с точки зрения функциональных возможностей приложения, используемых данных, начальных и конечных условий и т.д. Спецификации NGOSS обеспечивают возможность задокументировать эти интерфейсы и, таким образом, интерфейсы становятся четко определены и установлены. Спецификации NGOSS могут рассматриваться как дополнения к спецификациям API (Application Programming Interface).