Кратко о Frameworx и ODA от TM Forum

21.05.2024

Авторы: Виктор Рудь и Марианна Танкелевич

Frameworx — группа четырех взаимосвязанных фреймворков (framework) консорциума TM FORUM. Frameworx и его дальнейшее развитие в концепции ODA (Open Digital Architecture) представляет собой группу референсных моделей (в русскоязычной литературе - референтные) для создания архитектуры цифрового провайдера услуг. Начиная с 2015/2017 года ODA ориентируется на TOGAF и язык Архимейт, что позволяет архитекторам предприятий понимать место референсных моделей в практике архитектурирования вверенным им организаций.

---

Каждый из четырёх фреймворков базируется на одном базовом компоненте архитектуры предприятия (см. TOGAF, Archimate) и содержит сотни экземпляров (элементов) этого компонента:

1. eTOM (process framework). Базовый компонент фреймворка — business task (задача). Задача есть процессный элемент или бизнес-функция. Совокупность отдельных задач объединяется в поток процесса (process flow). В Архимейт в качестве задачи следует использовать специализацию компонента ПРОЦЕСС.
2. SID (information framework). Базовый компонент фреймворка — logical/business entity (информационный объект). В Архимейт это Business Object и Data Object.
3. TAM (application framework). Базовый компонент фреймворка — functionality (функциональность) — минимально выделенная единица поведения приложения. Минимально выделенная не означает, что это элементарная функция системы. В Архимейт это Application function. Совокупность или группа нескольких функциональностей образует Приложение (в Архимейт это application component). Конкретная информационная система (system) есть пример реализации такого приложения. 
4. Integration Framework. Базовый компонент фреймворка — сервис (и "контракт" на его использование). Сервис следует понимать, как совокупность функций и информационных объектов, выставленных системой (приложением или набором приложений) наружу с целью взаимодействия этого приложения с окружающей средой или, более точно, окружающей среды (ИТ-ландшафта предприятия) с приложением. Можно сказать, что сервис — это декларация приложения о своих функциональных возможностях в окружающее пространство, сервис — это то, что о приложении должны знать другие приложения. С 2017 года базовый элемент интеграционного фреймворка приобрел однозначный смысл API-метода (в Архимейт это application interface).

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

Четыре приведенных выше фреймворка - это не всё, что развивает TM FORUM, а лишь некое ядро, служащее целям сопряжения IT и Бизнеса. См. рисунок 1.

Рисунок 1. Ядро Frameworx.

Периодически TM FORUM расширяет список фреймворков, расширяя ядро. Так например, с 2006 года развивался и всё ещё периодически пересматривается фреймворк метрик (Business Metrics). После 2020 года добавился еще Capability framework - таксономия способностей предприятия. Эта таксономия дает возможность менеджменту компании упорядочить или спланировать организацию в направлении сверху вниз (точнее, от общего к частному), что часто востребовано при планировании трансформации предприятия.

Движение большинства предприятий в сторону цифровой трансформации, к созданию экосистем или интеграции с экосистемами привело к пересмотру Frameworx и примерно с 2015 года TM FORUM развивает свои карты в архитектурном подходе под названием ODA - Open Digital Architecture. Переосмысление карт в рамках ODA привело к созданию ODF - Open Digital Framework. Основной тренд переосмысления карт в рамках ODA привел к исключению из Frameworx телекоммуникационной специфики, а ориентация на TOGAF сделала ODF универсальной методологией архитектурирования для любого оператора цифровых услуг.

Что же такое ФРЕЙМ в слове "фреймворк"? — это любая группировка (агрегации) элементов, инстанциированных от базового компонента. Но это также может быть группировка группировок (то есть фрейм состоит из других фреймов).

Приведем пример: см. рисунок 2.

Рисунок №2: Фреймы 1-2-3 уровня для eTOM.

Базовый компонент eTOM - это Задача (Task), от него инстациируются следующие элементы (примечание, компонент - это тип архитектурного блока, элемент - это инстанциированный от него экземпляр):

• Allocate & Deliver Resource
• Configure & Allocate Resource
• Test Resource
• Collect, Update & Report Resource Configuration Data

Здесь перечислены элементы 3-го уровня (да, именно 3-го уровня). Их группировка на уровне 2 образует Resource Provisioning (см. рисунок 2), то есть Resource Provisioning - это элемент уровня 2. Элементы уровня 2 группируются в домены уровня 1.

Совокупность таких группировок образует таксономию;  в просторечии — просто классификацию элементов, где ФРЕЙМ — это классификационная ячейка. Иногда классификационные ячейки приобретают некий смысл, например, совокупность task можно назвать функцией N-ского уровня, а определенная совокупность функциональности приложения может образовывать модуль приложения. Фреймы наивысшего уровня абстракции (для еTOM - это процессные элементы уровня 2) образованы пересечением горизонтальных  функциональных доменов и вертикальных процессных доментов (см. на рисунке справа Frameworx Domain Area).

• Примечание 1: данное рассуждение применимо для большинства карт, но не для всех, могут быть исключения.
• Примечание 2: для еТОМ процессы уровня 2 очевидно "тянут" на макрофункции. Но их часто называются на процессный манер Core Processes. 

Интересно проследить в нашем примере на рис.2, верно ли выполнено обьединение элементов уровня L3 в элемент уровня L2?   Обычно, да.  Но если идти сверху вниз (что происходит чаще всего), то является ли десагрегация уровня 2 на элементы уровня 3 полной? То есть образуют ли все элементы уровня L3 (фреймы уровня 3 выделены оранжевым цветом) полный состав того, что должно входить в L2? - не факт! Такие нестыковки в еТОМ наблюдаются весьма часто и не стоит их относить к недостаткам еТОМ; скорее это относится к текущему уровню проработки отдельного (!) рассматриваемого фрейма. Следует заметить, что эта проработка ведется постоянно в каждом отдельном фрейме независимо и параллельно (почти всегда асинхронно), что позволяет развивать еТОМ независимо фрейм от фрейма. В этом, кстати, проявляется методическая сила фреймворка, позволяющая развивать его независимыми группами авторов. Дополнительно о фреймировании читать здесь >>>

Более интересно деление базовых элементов фреймворка (элементы уровня L3 или Задачи/Task для еТОМ) на более мелкие элементы уровня L4 (процессые шаги в терминологии еТОМ). Такое деление (деление базового элемента) есть всегда декомпозиция (декомпозиция — от понятия ’композиция’, а в итоге - мерономия). Такая декомпозиция, как правило, весьма строгая, то есть вся совокупность более мелких элементов эквивалентна исходному более крупному элементу. То есть декомпозиция и композиция весьма безупречны (симметричны) по качеству, так как базовые элементы - это не агрегаты (не абстрактные фреймы), а точные цифровые двойники реальности.  

Если же разделение task/задачи L3 на шаги L4 выполнено таким образом, что совокупность всех выделенных из задачи шагов не образует исходную задачу, то есть сборка L4 в L3 больше похожа на агрегацию, то это заставляет рассматривать ЗАДАЧУ в еТОМ не как базовый элемент, а как фрейм 3-го уровня. А сам базовый элемент, следовательно, находится, как минимум, на уровне 4. Такие случаи в еТОМ имеют место быть.

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

Аналогичные рассуждения по SID приводят к более строгой методической картинке, но в целом надо признать, что все фреймворки выглядят по-разному в зависимости от направления их анализа или построения: сверху вниз или снизу вверх. А именно: при движении сверху вниз мы идем от классификационных ячеек (фреймов) более высокого уровня к классификационным ячейкам (фреймам) более низкого уровня. Стараемся при этом использовать методы дезагрегации или декомпозиции, применяя их сначала к ячейкам (дезагрегация), а затем и к базовым элементам (декомпозиция), наполняющим эти ячейки. Но когда мы движемся снизу вверх, то методы сборки элементов низлежащего уровня в элементы более высокого уровня скорее похожи на методы агрегации. Это и путает аналитиков. В результате к любому элементу любого фреймворка относятся скорее как к классификационной ячейке, чем к конструктивному блоку (блоку, входящему в целевую конструкцию предприятия).

Все это приводит к тому, что архитектуру предприятия на базе референсных элементов, входящих в карты от TM FORUM, можно построить на разных уровнях абстрактности/детальности. Используя более абстрактные building blocks (уровни 1-2-3), мы получаем более верхнеуровневые архитектуры ограниченной полезности. Используя более детальные building blocks (уровни 4-6-7) мы получаем "конструкторские ИТ-чертежи" или модели, по которым уже можно создавать приложения, ориентируясь на подход MDD (Model Driven Design). 

---

---

Метамодель Open Digital Framework (ODF)

Группа карт ранее известных как Frameworx получила дальнейшее развитие в виде ODF. Пока сложно предсказать будет ли это дальнейшее развитие или самостоятельно развивающаяся ветка методологий, оторвавшаяся от Frameworx. Стоит полагать, что Frameworx продолжит своё развитие строго в круге традиционных операторов связи, а ODF получит распространение в круге провайдеров цифровых услуг и участников многосторонних платформ. С высокой вероятностью ряд карт, например eTOM, SID, Functional Framework будут общими как для ODF, так и для Frameworx.

На 2024 год ODF выглядит следующим образом:

Кардинальное изменение в ODF заключается в том, что данные (объекты SID) объявляются ресурсом и архитектура создается вокруг понимания этих ресурсов. У ресурса есть методы/функции, ресурс имеет API для доступа к методам и данным ресурса. Совокупность тесно связяанных ресурсов или даже один ресурс лежит в основе компонента [приложения]. 

Пример компонента "Bill Calculation" из ODF изображен на рисунке ниже:

Что мы видим на рисунке:

• интеграционные методы из каталога API - элементы из слоя API (напр. Customer Bill Management API, Party Management API):
  - выставленные компонентом API, через которые осуществляется взаимодействие с этим компонентом (exposed APIs),
  - используемые компонентом API других компонентов (consumed или dependent API).
  Exposed API одного ODA Component является consumed API у других компонентов. Для API указывается обязательность. Каждый API выставляется единственным компонентом (*). 
   
• информационные объекты SID - элементы из слоя данных (напр. Applied Customer Billing Rate):
  - агрегированные объекты данных (ABE), которыми управляет компонент. Компонент предоставляет доступ к своим объектам данных через выставленные API,
  - как правило ABE целиком находится под контролем одного ODA Component, в противном случае указаны дочерние ABE или даже конкретные BE, находящиеся в ведомости компонента. 
   
• функции Functional Framework - элементы из слоя функций (напр. Billing Event Processing Guiding, Customer Bill Usage and Charges Viewing):
  - функциональность, реализованная в компоненте и доступная через выставленные компонентом API. Раньше, мы это называли функциональным описанием системы. Для того чтобы в ИТ-ландшафте не было дублирования функций, каждая функция из Functional Framework должна быть однозначно закреплена за одним компонентом (*).
   
• процессы eTOM - элементы из слоя процессов (напр. Customer Bill Invoice Management: Produce & Distribute Customer Bill): 
  - процессы, использующие функциональность ODA Component'а. Для каждого ODA Component перечислены eTOM Process Elements (ПЭ) на различных уровнях вложенности для максимального уточнения процессных элементов, реализуемых с помощью компонента. Сквозной процесс или агрегированный процессный блок непременно требует коллаборации нескольких ODA-компонентов.

(*) Существуют исключения, которые находятся в постоянной прорабатотке TM Forum комьюнити.

Все элементы из различных карт (уместно заметить, что каждя карта - это один архитектурный слой предприятия) группируются вокруг ODA-компоненты благодаря связям. А также элементы связаны друг с другом внутри своего слоя. Схема взаимосвязи нескольких ODA-компонентов приводится в отдельном файле по ссылке >>>

---

Для создания модели всех компонентов Open Digital Framework в СиММА настроена вот такая метамодель:

Разбираться в картах TM FORUM, не имея репозитория (системы класса Enterprise Architect, как например СиММА) будет весьма сложно. Приведенную выше метамодель вы можете использовать для настройки собственных репозиториев, если они позволяют вам настраивать нужные метамодели.

Список статей