![Марк Аврелий](/netcat_template/template/ma_ru/images/marcus3.png)
21.05.2024
Авторы: Виктор Рудь и Марианна Танкелевич
Frameworx — группа четырех взаимосвязанных фреймворков (framework) консорциума TM FORUM. Frameworx и его дальнейшее развитие в концепции ODA (Open Digital Architecture) представляет собой группу референсных моделей (в русскоязычной литературе - референтные) для создания архитектуры цифрового провайдера услуг. Начиная с 2015/2017 года ODA ориентируется на TOGAF и язык Архимейт, что позволяет архитекторам предприятий понимать место референсных моделей в практике архитектурирования вверенным им организаций.
Каждый из четырёх фреймворков базируется на одном базовом компоненте архитектуры предприятия (см. TOGAF, Archimate) и содержит сотни экземпляров (элементов) этого компонента:
Старое название | Новое название | Базовый компонент | Агрегация/Композиция вверх | Декомпозиция вниз | Горизонтальные композиции |
---|---|---|---|---|---|
1. eTOM |
Business process |
Задача (Task) |
Функции [подразделений] |
Мини-задачи (шаги) |
Task flow - cквозные процессы |
2. SID |
Information framework |
Business Entity (BE) |
Aggregated Business Entity (ABE) |
Атрибут |
группа сильно связанных данных и собственно связи |
3. TAM |
Application framework |
Functionality (функциональность) |
Application (приложение, система) |
Функция системы (дерево декомпозиции) |
- |
4. Integration Framework |
Open API |
Interface (интерфейс) |
Service (Сервис или Cлужба) |
Сущность, ее методы и атрибуты |
Use Case |
Примечание: каждый фреймворк репрезентируется картой (с бумажной точки зрения карта - это плакат формата не менее А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), от него инстациируются следующие элементы (примечание, компонент - это тип архитектурного блока, элемент - это инстанциированный от него экземпляр):
Здесь перечислены элементы 3-го уровня (да, именно 3-го уровня). Их группировка на уровне 2 образует Resource Provisioning (см. рисунок 2), то есть Resource Provisioning - это элемент уровня 2. Элементы уровня 2 группируются в домены уровня 1.
Совокупность таких группировок образует таксономию; в просторечии — просто классификацию элементов, где ФРЕЙМ — это классификационная ячейка. Иногда классификационные ячейки приобретают некий смысл, например, совокупность task можно назвать функцией N-ского уровня, а определенная совокупность функциональности приложения может образовывать модуль приложения. Фреймы наивысшего уровня абстракции (для еTOM - это процессные элементы уровня 2) образованы пересечением горизонтальных функциональных доменов и вертикальных процессных доментов (см. на рисунке справа Frameworx Domain Area).
Интересно проследить в нашем примере на рис.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).
Группа карт ранее известных как Frameworx получила дальнейшее развитие в виде ODF. Пока сложно предсказать будет ли это дальнейшее развитие или самостоятельно развивающаяся ветка методологий, оторвавшаяся от Frameworx. Стоит полагать, что Frameworx продолжит своё развитие строго в круге традиционных операторов связи, а ODF получит распространение в круге провайдеров цифровых услуг и участников многосторонних платформ. С высокой вероятностью ряд карт, например eTOM, SID, Functional Framework будут общими как для ODF, так и для Frameworx.
На 2024 год ODF выглядит следующим образом:
Название | Базовый компонент | Агрегация/Композиция вверх | Декомпозиция вниз | Горизонтальные композиции | |
---|---|---|---|---|---|
0. | Component Map | Component | ODA Functional Block | Все декомпозиции, приведенные ниже: |
|
1. |
Business process |
Задача (Task) |
Функции [подразделений] |
Мини-задачи (шаги) |
Сквозные процессы |
2. |
Information framework |
Business Entity (BE) |
Aggregated Business Entity (ABE) |
Атрибут |
Домен сильно связанных данных |
3. |
Functional |
Functionality (функциональность) |
Application (приложение, система) |
Функция системы |
- |
4. |
Open API |
Interface (интерфейс) |
Service (Сервис или Cлужба) |
Сущность, ее методы и тарибуты |
Use Case |
Кардинальное изменение в ODF заключается в том, что данные (объекты SID) объявляются ресурсом и архитектура создается вокруг понимания этих ресурсов. У ресурса есть методы/функции, ресурс имеет API для доступа к методам и данным ресурса. Совокупность тесно связяанных ресурсов или даже один ресурс лежит в основе компонента [приложения].
Пример компонента "Bill Calculation" из ODF изображен на рисунке ниже:
Что мы видим на рисунке:
(*) Существуют исключения, которые находятся в постоянной прорабатотке TM Forum комьюнити.
Все элементы из различных карт (уместно заметить, что каждя карта - это один архитектурный слой предприятия) группируются вокруг ODA-компоненты благодаря связям. А также элементы связаны друг с другом внутри своего слоя. Схема взаимосвязи нескольких ODA-компонентов приводится в отдельном файле по ссылке >>>
Для создания модели всех компонентов Open Digital Framework в СиММА настроена вот такая метамодель:
Разбираться в картах TM FORUM, не имея репозитория (системы класса Enterprise Architect, как например СиММА) будет весьма сложно. Приведенную выше метамодель вы можете использовать для настройки собственных репозиториев, если они позволяют вам настраивать нужные метамодели.