Кратко о frameworx от TM Forum

21.01.2016

Автор: Виктор Рудь

Frameworx — набор из 4-х фреймворков (framework). Каждый из четырёх фреймворков базируется на одном базовом элементе и содержит сотни экземпляров этих базовых элементов:

  1. eTOM (process framework). Базовый элемент — business task (задача). Задача не есть процесс, задача может быть процессным элементом, когда, например, совокупность отдельных задач объединяется в некий flow.
  2. SID (information framework). Базовый элемент — logical/business entity (информационный объект).
  3. TAM (application framework). Базовый элемент — functionality (функциональность) — некий набор функций, образующий минимально возможную функциональную единицу (но не одну функцию). Совокупность одной или нескольких функциональностей образует application (приложение). Конкретная информационная система (system) есть пример реализации такого приложения.
  4. Integration Framework. Базовый элемент — сервис/контракт. Сервис следует понимать, как совокупность функций и информационных объектов, выставленных системой (приложением или набором приложений) наружу с целью взаимодействия с окружающей средой. Можно сказать, что сервис — это декларация приложения о себе в окружающее пространство, сервис — это то, что о приложении должны знать другие приложения. С 2017 года базовый элемент интеграционного фрейморка приобрел однозначный смысл API-метода.
Старое название Новое название Базовый элемент Агрегация вверх Декомпозиция вниз

1. eTOM
(карта процессов)

process framework

Задача

Процессы, функции [подразделений]

Мини-задачи (шаги)
Микро-задачи (операции)

2. SID
(карта данных)

information framework

BE

ABE

Атрибут

3. TAM
(карта приложений)

application framework

Functionality (функциональность)

Application

Функция системы

4. Integration Framework

Integration Framework

Interface (интерфейс)

API
Service (Сервис или Cлужба)

Use Case
Сущность и метод

Что же такое ФРЕЙМ в слове Фреймворк? — это любая группировка базовых элементов (агрегации базовых элементов). Все это вместе образует таксономию;  в просторечии — просто классификация базовых элементов, где ФРЕЙМ — это классификационная ячейка. Иногда классификационные ячейки приобретают некий смысл, например, совокупность task можно назвать функцией или процессом N-ского уровня. Кому как нравится (примечание: даже сам TM Forum меняет названия в этой области раз в 2 года).

Более интересно деление базовых элементов на более мелкие элементы. Такое деление есть всегда декомпозиция базового элемента (декомпозиция — от понятия ’композиция’, а в итоге - мерономия). Но декомпозиция не строгая, то есть вся совокупность более мелких элементов не всегда эквивалента исходному более крупному элементу. То есть если business task (задачу) разделить на более мелкие элементы — шаги (в терминологии еТОМ) — то совокупность всех выделенных из задачи шагов не образует эту задачу. Получается так, что при выделении шагов мы используем декомпозицию, как метод, но сборка шагов обратно в задачу получается не иначе как их агрегация. Это заставляет рассматривать ЗАДАЧУ в еТОМ не как базовый элемент, а как фрейм 3-го уровня.

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



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