Concept: 34.5. Сущности метамодели содержания
Main Description

Следующая таблица перечисляет и описывает сущности в пределах метамодели содержания.

Сущностьметамодели

Описание

Актор (Actor)

Человек, организация или система, у которой есть роль, которая инициализирует или взаимодействует с операциями; например, коммерческий представитель, который посещает клиентов. Акторы могут быть внутренними или внешними для организации. Для организации –производителя  автомобилей изготовитель оригинального оборудования является актором, который взаимодействует с организацией путем выполнения операций цепочки поставок.

Передположение (Assumption)

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

Бизнес-сервис (Business Service)

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

Возможность (Capability)

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

Ограничение (Constraint)

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

Контракт (Contract)

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

Управление (Control)

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

Сущность данных (Data Entity)

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

Двигатель (Driver)

Внешнее или внутреннее условие, которое мотивирует организацию определять свои цели. Пример внешнего двигателя – изменение в регулировании или правилах согласования, которые, например, требуют изменить способ действий организации.

Событие (Event)

Изменение организационного состояния, которое запускает события обработки; может произойти внутри или снаружи организации и может быть разрешено внутри или снаружи организации.

Функция (Function)

Поставляет бизнес-возможность, непосредственно встроенную в организацию, но не обязательно явно управляемую организацией. Альтернативное название – "бизнес-функция''.

Расхождение (Gap)

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

Примечание: анализ расхождений описан в части III, главе 27.

Цель (Goal)

Высокоуровневая формулировка намерения или директива для организации. Обычно используется для измерения успеха организации.

Сервис ИС (IS Service)

Автоматизированные элементы бизнес-сервиса. Сервис информационный системы может поставлять или поддерживать часть или полностью один или более бизнес-сервисов.

Местоположение (Location)

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

Логический компонент приложения (Logical Application Component)

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

Логический компонент данных (Logical Data Component)

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

Логический компонент технологии (Logical Technology Component)

Инкапсуляция инфраструктуры технологии, которая независима от специфического продукта. Класс технологического продукта; например, программное обеспечение управления цепочками поставок как часть набора программ Enterprise Resource Planning (ERP) или Commercial Off-The-Shelf (COTS).

Метрика (Measure)

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

Стремление (Objective)

Ограниченная во времени веха для организации использовала демонстрировать прогресс к цели; например, "Увеличить использование мощностей на 30 % к концу 2009, чтобы поддержать запланированное увеличение доли на рынке".

Организационный модуль (Organization Unit)

Автономный модуль ресурсов с ответственностью за линиейное управление целями, стремлениями и мерами. Организации могут включать внешние стороны и организации бизнес-партнеры.

Физический компонент приложения (Physical Application Component)

Приложение, модуль приложения, сервис прикложения или другой разворачиваемый компонент функциональности. Например, сконфигурированный и развернутый экземпляр приложения управления цепочками поставок Commercial Off-The-Shelf (COTS) Enterprise Resource Planning (ERP).

Физический компонент данных (Physical Data Component)

Ограниченная зона, которая формирует связанные информационные объекты для формирования физического местоположения, которое будет владеть данными. Например, бизнес-объект заказа на закупку, включая заголовок заказа и позиции заказа.

Физический компонент технологии (Physical Technology Component)

Определенный продукт инфраструктуры технологии или экземпляр продукта инфраструктуры технологии. Например, специфическая версия продукта  из решения Commercial Off-The-Shelf (COTS), или определенная марка и версия сервера.

Сервис платформы (Platform Service)

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

Принцип (Principle)

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

Примечание: Пример набора архитектурных принципов определен в части III, главе 23.

Процесс (Process)

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

Продукт (Product)

Результат, произведенный бизнесом. Продукт выполнения бизнес-процесса.

Требование (Requirement)

Количественная формулировка бизнес-потребности, которая должна быть удовлетворена определенной архитектурой или пакетом работ.

Роль (Role)

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

Качество сервиса (Service Quality)

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

Пакет работ (Work Package)

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