Соглашение между потребителем и поставщиком, которое фиксирует функциональные и нефункциональные параметры взаимодействия, — применимо к любому виду сервисных отношений в метамодели TOGAF, не только к ИТ. У контракта в метамодели самый большой набор собственных атрибутов: функциональное поведение, качество сервиса, доступность, время обслуживания, управляемость, восстанавливаемость, безопасность, масштабируемость и ещё около тридцати параметров. Обратное отношение у Service Quality: своих атрибутов у неё нет, она выполняет часть или все атрибуты связанного контракта.
Контракт между отделом поддержки и бизнес-подразделением: время реакции, часы обслуживания, порядок эскалации.
Контракт, где зафиксированы сроки и качество доставки заказов клиентам.
Внутренний контракт: одно подразделение потребляет биллинговый сервис другого на оговорённых условиях.
толкование редакции: примера в стандарте нет
дословная выпискаAn agreement between a consumer and a provider that establishes functional and non-functional parameters for interaction. This applies to all types of service interactions within the metamodel.
Соглашение между потребителем и поставщиком, устанавливающее функциональные и нефункциональные параметры взаимодействия. Применимо ко всем видам сервисных взаимодействий в метамодели.
Источникhttps://pubs.opengroup.org/togaf-standard/architecture-content/chap02.html
Атрибуты этой сущности по справочнику источника.
Unique identifier for the architecture entity.
Уникальный идентификатор архитектурной сущности.
Textual description of the architecture entity.
Текстовое описание архитектурной сущности.
User-definable categorization taxonomy for each metamodel entity.
Задаваемая пользователем таксономия категорий для каждой сущности метамодели.
Location from where the information was collected.
Место, откуда были собраны сведения.
Owner of the architecture entity.
Владелец архитектурной сущности.
Functional behavior to be supported within the scope of the contract.
Функциональное поведение, которое должно поддерживаться в рамках контракта.
Consuming service.
Потребляющий сервис.
Providing service.
Предоставляющий сервис.
Non-functional behavior to be supported within the scope of the contract.
Нефункциональное поведение, которое должно поддерживаться в рамках контракта.
Degree to which something is available for use.
Степень, в которой нечто доступно для использования.
Hours during which the service must be available.
Часы, в которые сервис обязан быть доступен.
Ability to gather information about the state of something and control it.
Способность собирать сведения о состоянии объекта и управлять им.
Ability to identify problems and take corrective action, such as to repair or upgrade a component in a running system.
Способность выявить неполадку и принять меры — например, починить или обновить компонент в работающей системе.
Ability of a component to perform its tasks in an appropriate time.
Способность компонента выполнять свои задачи за приемлемое время.
Response times that the service provider must meet for particular operations.
Время отклика, которое поставщик сервиса обязан обеспечить для отдельных операций.
Resistance to failure.
Устойчивость к отказам.
Contracted requirements on accuracy and completeness of information.
Level of governance and enforcement applied to the contractual parameters for overall service.
Measures in place to ensure that each service request meets contracted criteria.
Ability to restore a system to a working state after an interruption.
Ability of a system to be found when needed.
Ability of a system to prevent unauthorized access to functions and data. (continued)
Protection of data from unauthorized access.
Ability of a system to ensure that data has not been corrupted.
Ability of a system to ensure that the service request originates from an authorized source.
Ability of a service to support localized variants for different consumer groups.
Ability of a service to support international variations in business logic and data representation (such as character set).
Ability of the service to interoperate with different technical environments, inside and outside of the organization.
Ability of the service to grow or shrink its performance or capacity appropriately to the demands of the environment in which it operates.
Of data, people, applications, and components.
Ability to accept new functionality.
Contracted capacity of the service provider to meet requests.
Required throughput capacity.
Time period needed to deliver throughput capacity.
Expected future growth rate of service request.
Time period needed to reach the expected growth rate.
Short-term profile of peak service traffic.
Long-term profile of peak service traffic.
Сколько соглашений об уровне сервиса и операционных соглашений нарушено за период. Прямая мера того, держит ли сервис обещанное.
Число нарушенных соглашений = количество SLA и OLA, по которым за период нарушены согласованные условия
Доля времени, в течение которого критичные для бизнеса системы доступны. KPI ценностного потока Detect to Correct; сам стандарт оговаривает, что управление доступностью в этом потоке ещё не представлено и будет рассмотрено в будущих редакциях (разд. 8.4.9).
Доступность = время работоспособного состояния / общее время наблюдения
Именно у контракта метамодель TOGAF держит поля уровня сервиса — пропускную способность, время отклика, характеристики доступности, — но оставляет их пустыми; эти две метрики и заполняют пустые поля числами.
An agreement between a service consumer and a service provider that establishes functional and non-functional parameters for interaction.
Архитектурная сущность TOGAF: контракт.
TOGAF Standard, Version 9.2, The Open Group, 2018, C182; гл. 30 «Content Metamodel», §30.5 «Content Metamodel Entities», табл. «Metamodel Entity | Description»
Сопоставления одного понятия в разных подходах.
Реестр процессов, архитектурное рабочее пространство, связи между системами и процессами — те самые артефакты, только про вашу организацию.
Это же в StormАрхитектура систем и интеграцийРеестр процессовКарта бизнес-способностей
