Frameworx

Frameworx, ранее NGOSS (англ. New Generation Operations Support System) — концепция телекоммуникационной отраслевой организации TM Forum, описывающая подход к разработке, внедрению и эксплуатации прикладного программного обеспечения для предприятий электросвязи. Цель концепции — определить стандарты для бизнес-процессов операторов, форматы предоставления используемых в системах управления данных и интерфейсы взаимодействия со средой, в которую интегрируется решение.

Состав концепции

Основу концепции образуют:

• расширенная карта бизнес-процессов еТОМ, описывающая структуру бизнес-процессов телекоммуникационных компаний;
• информационная модель SID, определяющая подход к описанию и использованию данных, задействованных в бизнес-процессах компании связи;
• карта приложений ТАМ, описывающая типовую структуру компонентов информационной среды предприятия связи;
• технологически нейтральная архитектура интеграции и договорные определения интерфейсов (англ. Technology Neutral Architecture and Contract Interface Definitions), определяющие принципы взаимодействия и интеграции приложений, данных и бизнес-процессов в распределенной среде;
• система контроля соответствия принципам (англ. compliance), позволяющая проверить компоненты на соответствие концепции.

Особенности

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

Когда 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).

Применение

Концепция NGOSS, включающая в себя модели eTOM, SID, ТАМ и TNA, а также жизненный цикл решения в сочетании с методологией SANRR, представляет собой комплексную методологию разработки, внедрения, эксплуатации и развития систем OSS/BSS. С ее помощью можно интегрировать в единую архитектуру бизнес-требования и технические аспекты деятельности оператора связи, автоматизировать бизнес-процессы в гетерогенных ИТ-средах, построить единую информационную инфраструктуру, строго ориентированную на выполнение бизнес-задач телекоммуникационной компании. Использование инструментов и методологий жизненного цикла NGOSS может значительно способствовать достижению успеха в эффективном управлении компанией связи. Однако следует понимать, что сама возможность применения этих инструментов во многом зависит от готовности компании воспринимать изменения, готовности инфраструктуры к внедрению всеобъемлющей управляющей информационной системы, готовности персонала осуществлять внедрение, администрирование, а главное — использовать указанные инструменты в своей деятельности.

Литература

1.Джон Райли, Мартин Кринер «NGOSS: Построение эффективных систем поддержки и эксплуатации сетей для операторов связи».

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