Frameworx - это структура корпоративной архитектуры, ориентированная на поставщиков услуг связи .
Он разработан TM Forum .
Состав
Frameworx состоит из четырех фреймворков:
- Платформа приложений (иногда называемая картой приложений электросвязи (ТАМ))
- Структура бизнес-процессов (eTOM)
- Информационная структура (иногда называемая моделью общей информации / данных (SID) )
- Платформы интеграции (разработанные в рамках программы интеграции TM Forum (TIP))
Информационная структура
Информация Framework (формально Shared данных / Модель данных или SID) представляет собой единую ссылка модель данных обеспечивает единый набор терминов для бизнес - объектов в области телекоммуникаций . Цель состоит в том, чтобы дать возможность людям из разных отделов, компаний или географических регионов использовать одни и те же термины для описания одних и тех же объектов, практик и отношений в реальном мире. Это часть Frameworx.
Информационная структура, как информационная модель Frameworx, предоставляет справочную модель информации / данных и общий словарь информации / данных с точки зрения бизнеса, а также с точки зрения системы. Информационная структура использует унифицированный язык моделирования для формализации выражения потребностей конкретной точки зрения заинтересованных сторон.
Информационная платформа предоставляет общий язык для сообщения о проблемах четырех основных групп участников (заинтересованных сторон), представленных точками зрения Frameworx - бизнес, система, внедрение и развертывание, как определено в жизненном цикле Frameworx. Используемая в сочетании с описаниями бизнес-процессов и действий Business Process Framework (eTOM) и картой приложений Telecom, Information Framework позволяет установить мост между бизнес-группами и группами информационных технологий внутри организации, предоставляя определения, понятные для бизнеса, но также достаточно строгие, чтобы их можно было использовать при разработке программного обеспечения.
Модель Information Framework черпает вдохновение из самых разных отраслевых источников, но ее основные истоки - это общая информационная архитектура Alliance (ACIA), созданная командой под руководством Билла Брука из AT&T и BT Group, а также сети с поддержкой каталогов - следующего поколения -ng) модель, созданная Джоном Штрасснером.
Первоначально выпущенная в 2000 году, модель Information Framework хорошо охватывала сферу бизнеса (BSS), а также область управления устройствами, но была недостаточной по своей способности представлять логические сети и емкость. Эти недостатки устраняются путем пересмотра модели с включением таких понятий, как топологии, но история привела к плохому использованию модели в определенных областях телекоммуникаций, таких как управление запасами.
Принципы
Frameworx основан на этих ключевых принципах.
Отделение бизнес-процесса от реализации компонентов
Когда системы поддержки операций (OSS) связаны друг с другом, поддерживаемые ими бизнес-процессы распределяются по всему ИТ-отделу. Фактически достигается ситуация, когда процесс начинается с приложения A, которое обрабатывает некоторые данные, а затем знает, что оно должно вызвать приложение B, которое также выполняет некоторую обработку, а затем вызывает C и т. Д. В результате этого чрезвычайно сложно понять, где на самом деле находится какой-либо из этих потоков (например, если поток процесса предназначен для приема заказа клиента, это приложение 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 2 .
CCI может также предоставлять другие услуги, включая безопасность, перевод данных и т. Д.
Интерфейсы, определенные контрактом
Учитывая приведенное выше описание того, как приложения взаимодействуют с CCI, ясно, что нам нужен способ документирования этих интерфейсов, как с точки зрения используемой технологии (например, это Java / JMS или веб-службы / SOAP?), Но также и с точки зрения функциональности приложение, используемые данные, предварительные и последующие условия и т. д. Спецификация контракта Frameworx предоставляет средства для документирования этих интерфейсов, и поэтому они являются интерфейсами, определяемыми контрактом.
Контракты Frameworx можно рассматривать как расширения спецификаций интерфейса прикладного программирования (API).
Практические результаты
Модель процесса
Ет (расширенная Telecom Operations Map, выраженный й-том) является основой бизнеса - процессов Frameworx.
Информация Frameworx - это общая информация / модель данных (SID).
Модель жизненного цикла
Модель жизненного цикла Frameworx [1] направлена на определение использования и развертывания Frameworx в организации и обеспечивает основу для использования SID, eTOM и архитектуры Frameworx. Модель основана на значительном более ранние работы, в том числе Захмана , Kernighan , Иордана , и объект группы управления «s Model Driven Architecture . Жизненный цикл Frameworx делит разработку системы на 4 этапа: требования, проектирование системы, внедрение и эксплуатация.
Спецификации контракта
Как указывалось ранее, контракт Frameworx является фундаментальной единицей взаимодействия в системе Frameworx. Функциональная совместимость важна для каждого из четырех представлений, определенных жизненным циклом Frameworx. Например, Контракт используется для определения услуги, которая должна быть предоставлена, а также для указания информации и кода, реализующего услугу. Контракт также используется для мониторинга, администрирования и поддержки сервиса, а также для обеспечения выполнения любых внешних обязательств по контракту (например, из SLA (Соглашение об уровне сервиса)), а также для определения мер, которые следует предпринять, если они каким-либо образом нарушаются. .
Карта приложения Telecom
Платформа приложений (формально Telecom Application Map (TAM)) является одним из основных артефактов Frameworx. Он рассматривает роль и функциональность различных приложений, которые предоставляют возможности OSS ( система поддержки операций ) и BSS ( система поддержки бизнеса ).
При этом он позволяет составлять закупочную документацию со ссылкой на структуру, тем самым обеспечивая четкие и недвусмысленные заявления о функциональных возможностях, требуемых от любого данного приложения, и выявлять функциональные совпадения существующих приложений, тем самым облегчая рационализацию и выявляя функциональные пробелы.
Уровень функциональной декомпозиции таков, что эти преимущества могут быть реализованы, но без излишних предписаний.
В TM Forum есть четкое определение процессов и данных. Платформа приложений обеспечивает формализованный способ группировки функций и данных в признанные компоненты, которые затем будут рассматриваться как потенциально доступные как приложения или услуги. Приложение или служба (например, веб-службы) могут быть относительно крупномасштабным программным обеспечением, которое реализует функции / процессы и действует или использует данные. В повседневной жизни мы видим такие приложения, как текстовые редакторы или почтовые клиенты; в терминах OSS мы будем рассматривать приложение как что-то вроде компонента CRM, биллинговой системы или инвентарного решения - хотя мы также понимаем, что их можно до некоторой степени разложить - например, биллинговая система будет включать в себя ряд более мелких приложений, например, рейтинговый двигатель.
«Приложение» определяется как набор из одного или нескольких программных артефактов, содержащих четко определенные функции, данные, бизнес-потоки, правила и интерфейсы. Это будет включать модель данных для данных, используемых для взаимодействия с приложением и внутри него, политики для управления внешними и внутренними ресурсами приложения, модель потока для функциональности с приложением и спецификации контракта для видимых извне интерфейсов для функциональности внутри приложения.
Приложения могут быть реализованы в виде развертываемых пакетов и могут быть приобретены на системном рынке.
Платформа приложений не является частью определений Информационной платформы или структуры бизнес-процессов (eTOM), но связана с ними легко и понятно, а также обеспечивает сопоставление между ними.
Внешние ссылки
Дополнительная информация
mTOP - это программа в рамках TeleManagement Forum (TM Forum), которая охватывает определение интерфейсов управления для телекоммуникационных сетей. mTOP охватывает как управление ресурсами, так и услугами.