Фреймворкс

Frameworx — это платформа корпоративной архитектуры, ориентированная на поставщиков услуг связи .

Структура

Frameworx состоит из четырех фреймворков:

Структура приложений (иногда называемая Картой приложений телекоммуникаций (TAM))
Business Process Framework (eTOM)
Информационная структура (иногда называемая моделью общей информации/данных (SID) )
Интеграционные структуры (разработанные в рамках программы интеграции TM Forum (TIP))

Информационная структура

Информационная структура (формально общая модель информации/данных или SID) представляет собой унифицированную справочную модель данных, обеспечивающую единый набор терминов для бизнес-объектов в сфере телекоммуникаций . Цель состоит в том, чтобы дать возможность людям в разных отделах, компаниях или географических точках использовать одни и те же термины для описания одних и тех же объектов, практик и отношений реального мира. Это часть Frameworx.

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

Информационная структура обеспечивает общий язык для передачи проблем четырех основных групп участников (заинтересованных сторон), представленных точками зрения Frameworx: бизнес, система, внедрение и развертывание, как это определено в жизненном цикле Frameworx. Используемая в сочетании с Business Process Framework (eTOM) описаниями бизнес-процессов и действий и картой телекоммуникационных приложений, информационная структура позволяет объединить бизнес-группы и группы информационных технологий внутри организации, предоставляя определения, которые понятны бизнесу, но также достаточно строги, чтобы их можно было использовать при разработке программного обеспечения.

Модель информационной структуры черпает вдохновение из самых разных отраслевых источников, но ее основным источником является Общая информационная архитектура Альянса (ACIA), созданная командой под руководством Билла Брука из AT&T и BT Group, и Сети с поддержкой каталогов - следующее поколение (DEN). -ng) модель, созданная Джоном Страсснером.

Первоначально выпущенная в 2000 году, модель Information Framework хорошо охватывала сферу бизнеса (BSS), а также область управления устройствами, но была недостаточной в своей способности представлять логические сети и емкость. Эти недостатки устраняются путем пересмотра модели с включением таких концепций, как топологии, но история привела к плохому использованию модели в некоторых областях телекоммуникаций, таких как управление запасами.

Принципы

Frameworx основан на этих ключевых принципах.

Отделение бизнес-процесса от реализации компонентов

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

Frameworx предлагает управлять процессом как частью централизованной инфраструктуры с использованием механизма рабочего процесса, который отвечает за управление потоком бизнес-процессов между приложениями. Таким образом, механизм рабочего процесса инициирует процесс в приложении A, который затем возвращает управление механизму рабочего процесса, который затем вызывает приложение B и так далее. Таким образом, всегда можно узнать, где находится отдельный поток процесса, поскольку он контролируется центральным механизмом рабочего процесса, а модификации процесса можно вносить с помощью инструментов определения процесса этого механизма. Очевидно, что некоторые потоки процессов более низкого уровня будут встроены в отдельные приложения, но это должно быть ниже уровня значимой для бизнеса обработки (т. е. ниже уровня, на котором реализуются бизнес-политика и правила). Методологии сертификации Frameworx помогают нам работать с диапазоном предпочтений, которые не распределены линейно, что дает возможность улучшить принятый клиентом, несомненно, подходящий метод.

Слабосвязанная распределенная система

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

«Распределенная система» подчеркивает, что Frameworx не основан на поставщике услуг связи (CSP), использующем одно монолитное приложение для управления всеми своими действиями, а вместо этого использует набор интегрированных и взаимодействующих приложений.

Модель общей информации

Интеграция OSS означает, что данные должны совместно использоваться приложениями. Чтобы это было эффективно, либо каждое приложение должно понимать, как каждое другое приложение понимает/интерпретирует ту часть общих данных, либо должна существовать общая модель общих данных. Чтобы понять это, рассмотрим приложение обработки заказов, которое прошло процесс ввода заказа клиента и теперь ему необходимо отправить счет с помощью приложения B (система выставления счетов). Приложение A будет иметь запись об адресе клиента, и поэтому ему необходимо убедиться, что приложение B отправляет счет на этот адрес. Для передачи этих данных между системами просто требуется общий формат адресной информации — каждая система должна ожидать одинаковое количество адресных строк, причем каждая строка будет одинаковой длины. Это довольно просто. Но представьте себе, какие трудности возникли бы, если бы приложение для заказа работало с продуктами, состоящими из пакетов подпродуктов (например, продукт широкополосного доступа, состоящий из медной линии, модема, набора фильтров и широкополосного преобразователя), тогда как приложение для выставления счетов приложение ожидало только отдельные строки продукта/заказа. Попытка преобразовать иерархические продукты в неиерархические без потери информации будет невозможна. Единая информационная модель для данных, которые таким образом совместно используются приложениями, обеспечивает решение этой проблемы. Решение TMF для этой проблемы называется Общая информация/модель данных (SID).

Общая инфраструктура связи

В середине 1980-х годов компьютерные OSS разрабатывались как автономные приложения. Однако в начале 1990-х годов стало очевидно, что использовать их как чисто изолированные приложения было крайне неэффективно, поскольку это приводило к ситуации, когда, например, заказы принимались в одной системе, а детали затем приходилось повторно вводить в систему. другой для настройки соответствующего сетевого оборудования. Было показано, что значительный прирост эффективности достигается за счет объединения автономных OSS вместе, что позволяет использовать такие функции, как «сквозное обеспечение», когда заказ может быть размещен онлайн и автоматически приводит к предоставлению оборудования без какого-либо вмешательства человека.

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

Frameworx описывает использование общей коммуникационной инфраструктуры (CCI). В этой модели OSS взаимодействуют с CCI, а не напрямую друг с другом. Таким образом, CCI позволяет приложениям работать вместе, используя CCI для их связи. Таким образом, каждому приложению требуется только один интерфейс (к CCI), а не множество (к другим приложениям). Таким образом, сложность снижается до порядка n, а не n. ².

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

Определенные контрактом интерфейсы

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

Контракты Frameworx можно рассматривать как расширения спецификаций интерфейса прикладного программирования (API).

Результаты

Модель процесса

eTOM (расширенная карта телекоммуникационных операций, произносится как ee-tom) — это структура бизнес-процессов Frameworx.

Модель общей информации

Информация Frameworx — это модель общей информации/данных (SID).

Модель жизненного цикла

Модель жизненного цикла Frameworx направлена на определение использования и развертывания Frameworx в организации и обеспечивает основу для использования SID, eTOM и архитектуры Frameworx. Модель основана на значительных более ранних работах, включая Zachman Framework , Kernighan , Yourdon и Object Management Group от Model Driven Architecture . Жизненный цикл Frameworx делит разработку систем на 4 этапа: требования, проектирование системы, внедрение и эксплуатация.

Спецификации контракта

Как говорилось ранее, контракт Frameworx является фундаментальной единицей взаимодействия в системе Frameworx. Функциональная совместимость важна для каждого из четырех представлений, определенных жизненным циклом Frameworx. Например, контракт используется для определения предоставляемой услуги, а также для указания информации и кода, реализующих услугу. Контракт также используется для мониторинга, администрирования и обслуживания услуги, а также для обеспечения выполнения любых внешних обязательств по контракту (например, из SLA (Соглашение об уровне обслуживания)) и для определения мер, которые необходимо предпринять, если они каким-либо образом нарушаются. .

Карта телекоммуникационных приложений

Платформа приложений (формально Карта приложений телекоммуникаций (TAM)) является одним из основных артефактов Frameworx. В нем рассматриваются роль и функциональность различных приложений, обеспечивающих возможности OSS ( системы поддержки операций ) и BSS ( системы поддержки бизнеса ).

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

Уровень функциональной декомпозиции таков, что эти преимущества могут быть реализованы, но без чрезмерного предписания.

В рамках TM Forum существует четкое определение процессов и данных. Applications Framework обеспечивает формализованный способ группировки функций и данных в признанные компоненты, которые затем будут рассматриваться как потенциально доступные для приобретения как приложения или услуги. Приложение или служба (например, веб-службы) могут представлять собой относительно крупнозернистое программное обеспечение, которое реализует функции/процессы и воздействует на данные или использует их. В повседневной жизни мы видим такие приложения, как текстовые процессоры или почтовые клиенты; с точки зрения OSS мы будем рассматривать приложение как что-то вроде компонента CRM, биллинговой системы или решения для инвентаризации – хотя мы также понимаем, что их можно в некоторой степени разложить – например, биллинговая система будет включать в себя ряд более мелких приложений, например, рейтинговый механизм.

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

Приложения реализуются в виде развертываемых пакетов и их можно приобрести на системном рынке.

Платформа приложений не является частью определений информационной платформы или структуры бизнес-процессов (eTOM), но легко и понятно связывает их с обоими, а также обеспечивает сопоставление между ними.

Внешние ссылки

См. также