-
Пройти Антиплагиат ©



Главная » Управление системами связи специального назначения » 2.6 Концепция Frameworx



Концепция Frameworx

Creative Commons «Attribution» («Атрибуция») 4.0 Всемирная. Уникализировать текст 



Frameworx, ранее NGOSS (англ. NewGeneration Operations Systems and Software) — концепция телекоммуникационной отраслевой организации TM Forum, описывающая подход к разработке, внедрению и эксплуатации прикладного программного обеспечения для предприятий электросвязи.
Цель концепции — определить стандарты для бизнес-процессов операторов, форматы представления используемых в системах управления данных и интерфейсы взаимодействия со средой, в которую интегрируется решение.
Основу концепции образуют:
расширенная карта бизнес-процессов еТОМ, описывающая структуру бизнес-процессов телекоммуникационных компаний;
информационная модель SID, определяющая подход к описанию и использованию данных, задействованных в бизнес-процессах компании связи;
карта приложений TAM, описывающая типовую структуру компонентов информационной среды предприятия связи;
технологически нейтральная архитектура интеграции и договорные определения интерфейсов (англ. TechnologyNeutralArchitectureandContractInterfaceDefinitions), определяющие принципы взаимодействия и интеграции приложений, данных и бизнес-процессов в распределенной среде;
система контроля соответствия принципам (англ. compliance), позволяющая проверить компоненты на соответствие концепции.
Особенности:
1. Разделение бизнес-процессов и применяемых технических компонентов
Когда OSS-системы связаны вместе, бизнес-процессы, которые они поддерживают, распространяются на всю IT-сферу предприятия. В результате возникает ситуация, когда некий процесс стартует из приложения A, которое обрабатывает некие данные и которое «знает», что затем оно должно вызвать приложение B, которое в свою очередь также произведет обработку данных и вызовет приложение С и т.д. Как следствие, крайне тяжело определить, какой из этапов процесса является текущим в данный момент (например, при выставлении счета клиенту как можно определить, какое приложение (A, B или C) обрабатывает в данный момент информацию о счете?). И еще более сложной является задача изменения данного процесса вследствие его распределенной природы. NGOSS предполагает, что процесс должен управляться как часть централизованной инфраструктуры с использованием какого-либо механизма, обеспечивающего последовательность выполнения действий и ответственного за осуществление контроля хода бизнес-процесса от одного приложения до другого. Таким образом, данный механизм инициировал бы процесс на приложении A, которое затем бы возвращало контроль обратно. Затем данный механизм вызывал бы приложение B и так далее. В таком случае было бы всегда возможно определить, какой из этапов бизнес-процесса выполняется в данный момент времени, поскольку контроль за его ходом был бы уже централизованным. При этом изменения процесса могли бы производиться с использованием определенного инструментария упомянутого механизма. Ясно, что некоторые составляющие процесса нижнего уровня будут встроены в отдельные приложения, но это должно располагаться ниже того уровня, на котором выполняются значимые для бизнеса функции, то есть ниже того уровня, на котором функционируют применяемые стандарты и политики предприятия.
2. Распределенная система с нежёсткими связями между ее элементами
Нежёсткая связь между элементами предполагает, что каждое приложение является сравнительно независимым от других приложений в рамках общей системы. Таким образом, в окружении с нежёсткими связями в одно приложение могут быть внесены изменения без влияния на другие приложения, обычно неизбежное в подобных случаях. По крайней мере, данный принцип иногда может рассматриваться как предоставление возможности внедрять приложения по схеме «plug and play», поскольку они являются настолько независимыми по отношению друг к другу, что могут быть заменены без влияния на систему в целом. Использование «распределённой системы» еще раз подчеркивает, что NGOSS основан не на использовании телекоммуникационной компанией единого монолитного приложения для управления всеми операциями предприятия, но вместо этого предлагается использовать набор интегрированных и взаимодействующих друг с другом приложений.
3. Общая информационная модель
Интеграция OSS-систем означает, что приложения должны уметь «обмениваться» друг с другом различного рода данными. И чтобы данный процесс был эффективным, каждое приложение должно «знать», как любое другое приложение «понимает» или интерпретирует тот или иной блок переданных данных. Чтобы разобраться в этом, можно использовать пример предоставления клиенту информации о счете: приложение А принимает запрос клиента о выставленном счете и производит отправку данной информации, используя при этом приложение Б (биллинговую систему). Приложение А будет иметь сведения об адресе клиента, и необходимо, чтобы приложение Б отправило счет именно на этот адрес. Чтобы происходил обмен данными между системами, им необходимо иметь стандартный формат информации об адресе: количество строк адресной информации, количество символов в каждой строчке — все это для каждой системы должно быть одинаковым и каждое приложение знает, с каким форматом работает другое приложение. Все достаточно очевидно и просто. Но можно вообразить трудности, с которыми пришлось бы столкнуться, если приложение А работало бы с продуктами, которые состояли бы из нескольких подпродуктов (широкополосный доступ по медным линиям, модем, набор фильтров и широкополосного преобразования), и передавало бы весь спектр данных приложению Б, тогда как приложение Б ожидало получить только одну строчку данного продукта/заказа. Попытка преобразовать иерархические продукты в неиерархические, не теряя при этом информацию, была бы невозможна. Единая информационная модель для данных, которыми обмениваются приложения, обеспечивает решение этой проблемы. Решение от TMF называют Общей информационной моделью.
4. Совместно используемая инфраструктура связи
Изначально (примерно в середине 80-х годов) OSS-системы развивались как отдельные приложения. Однако вначале 90-х стало очевидно, что применение данных систем как отдельных приложений было в высшей степени неэффективно, поскольку это приводило к ситуации, когда, например, заказ принимается в одной системе, а затем некие детали из данного заказа переносятся в другую систему в целях конфигурирования соответствующего сетевого оборудования. Главный выигрыш в эффективности от объединения отдельных OSS-систем — это приобретение такой возможности, как «Flow-through provisioning» («мониторинг хода процесса»), когда заказ мог бы быть размещен онлайн и происходил бы автоматический мониторинг получаемого результата без участия персонала. Однако для крупных операторов связи с сотнями отдельных OSS-систем быстрое увеличение интерфейсов стало серьёзной проблемой. Каждое OSS должно было «говорить» со многими другими, приводя к экспоненциальному росту числа интерфейсов при увеличении числа OSS-систем. NGOSS описывает применение Совместно используемой инфраструктуры связи (Common Communications Infrastructure, CCI). В этой модели OSS-системы взаимодействуют с CCI, а не непосредственно друг с другом. CCI таким образом позволяет приложениям взаимодействовать, используя CCI для их соединения. Следовательно, каждое приложение требует только одного интерфейса (к CCI), а не многих (ко всем другим приложениям), поэтому сложность всей системы значительно снижается. Также CCI может обеспечивать другие сервисы, включая обеспечение безопасности, преобразование данных и т.д.
5. Четко установленные определенные интерфейсы
Из данного выше описания принципа взаимодействия приложений с CCI становится ясно, что необходимо иметь способ задокументировать эти интерфейсы, причем как с точки зрения применяемой технологии (например, Java/JMS или Web-сервисы/SOAP), так и с точки зрения функциональных возможностей приложения, используемых данных, начальных и конечных условий и т.д. Спецификации NGOSS обеспечивают возможность задокументировать эти интерфейсы, и, таким образом, интерфейсы становятся четко определены и установлены. Спецификации NGOSS могут рассматриваться как дополнения к спецификациям API (Application Programming Interface).
Концепция NGOSS, включающая в себя модели eTOM, SID, TAM и TNA, а также жизненный цикл решения в сочетании с методологией SANRR, представляет собой комплексную методологию разработки, внедрения, эксплуатации и развития систем OSS/BSS. С ее помощью можно интегрировать в единую архитектуру бизнес-требования и технические аспекты деятельности оператора связи, автоматизировать бизнес-процессы в гетерогенных ИТ-средах, построить единую информационную инфраструктуру, строго ориентированную на выполнение бизнес-задач телекоммуникационной компании. Использование инструментов и методологий жизненного цикла NGOSS может значительно способствовать достижению успеха в эффективном управлении компанией связи. Однако следует понимать, что сама возможность применения этих инструментов во многом зависит от готовности компании воспринимать изменения, готовности инфраструктуры к внедрению всеобъемлющей управляющей информационной системы, готовности персонала осуществлять внедрение, администрирование, а главное — использовать указанные инструменты в своей деятельности.
 



Лекция, реферат. Концепция Frameworx - понятие и виды. Классификация, сущность и особенности. 2021.

Оглавление книги открыть закрыть

1. Определения и сокращения, используемые в тексте
2. Концепции управления системами связи
2.1 Причины появлениясистем управления сетями связи
2.2 Концепция TMN
2.3 Концепции TOM и eTOM
2.4 Расширенная схема eTOM
2.5 - Потоки процессов
2.6 Концепция Frameworx
3. Концепция программно-конфигурируемых сетей (SDN)
3.1 Протокол управления процессом обработки данных OpenFlow
4. Концепция и управление сетями следующего поколения NGN
5. Организация управления сетями связи
5.1 Взаимодействие систем связи
5.2 Управление в модели открытых систем
6. Уровни управления сетями связи
6.1 Управление в глобальной информационной инфраструктуре
6.2 Функции и логические интерфейсы управления в GII
6.3 Управление сетями связи в Российской Федерации
6.4 Организация управления сетями связи МВД России
7. Протоколы управления в сетях связи
7.1 Протокол SNMP
7.2 Протокол CMIP
7.3 Общеканальная сигнализация №7
7.4 Протоколы SIGTRAN
8. Средства анализа и оптимизации локальных сетей
9. Управление ресурсами сетей связи
9.1 Динамическое управление ресурсами сети
9.2 Основные задачи динамического управления потоками
9.3 Принципы организации и методы динамического управления потоками
9.4 Управление маршрутизацией
10. Динамическое управление в сетях с различным видом коммутации
10.1 Динамическое управление ресурсами в сетях с коммутацией каналов
10.2 Динамическое управление ресурсами в сетях с коммутацией пакетов
11. Управление коммутируемыми компьютерными сетями
11.1 Классификация коммутаторов по возможности управления
11.2 Функции повышения надежности и производительности
11.3 Виртуальные локальные сети
12. Математическое моделирование сети и разработка приложений
13. Построение математических моделей
13.1 Специализированные системы имитационного моделирования вычислительных сетей




« назад Оглавление вперед »
2.5 - Потоки процессов « | » 3. Концепция программно-конфигурируемых сетей (SDN)






 

Учебники по данной дисциплине

Административно-правовое регулирование государственной службы
Как написать диссертацию
Финансовый контроль в зарубежных странах: США, ЕС, СНГ
Современные правовые семьи
Краткое содержание и сравнительная характеристика персонажей произведений Пушкина и Шекспира
Административно-правовые основы государственной правоохранительной службы
Публичное право
Правила написания рефератов, курсовых и дипломных работ
Кадровое делопроизводство
Защита вещных прав
Социология - методические указания и тесты
Психолого-педагогические аспекты работы в органах ФСИН
Антиинфляционная политика и денежно-кредитное регулирование
История и философия экономической науки
История и методология экономической науки
Прямое и косвенное регулирование мирового финансового рынка
Специальные и общие инструменты регулирования мирового финансового рынка
Факторинговые и трастовые операции коммерческих банков
Инфляционные процессы
Управление компетенциями
Характеристика логистических систем
Стратегические изменения в организации
Реструктуризация деятельности организации
Реинжиниринг бизнес-процессов
Управление персоналом в условиях организационных изменений
Развитие персональной системы ценностей как педагогическая проблема
Подготовка полицейских кадров в Германии, Франции, Великобритании и США
Манипулятивный стиль поведения пациентов с множественными суицидальными попытками
Анафилаксия: диагностика и лечение
Коллективные формы предпринимательской деятельности
Психология лидерства
Антология русской правовой мысли
Компетенции
Психология управления кадрами в бизнесе