Обзор языка ArchiMate

1. Обзор языка ArchiMate

http://www.archimatetool.com

2. Проект создания ArchiMate

Язык ArchiMate был разработан в Нидерландах в рамках исследовательского
проекта, возглавляемого Telematica Instituut, в сотрудничестве с рядом организаций
и университетов.
В 2008 году право собственности и дальнейшего развития ArchiMate было передано
одной из ведущих организаций по разработке открытых и независимых от
поставщиков
ИТ-стандартов - консорциуму The Open Group, активно развивающего стандарт
архитектуры предприятия TOGAF.
В феврале 2009 года в качестве технического стандарта была опубликована первая
версия языка The ArchiMate 1.0 Specification.
В 2012 году вышла вторая версия The ArchiMate 2.0 Specification, а также была
введена сертификационная программа, которая включает сертификацию
специалистов, аккредитацию обучающих курсов и сертификацию программных
средств, поддерживающих стандарт языка ArchiMate.
Сейчас действует модификация второй версии стандарта The ArchiMate 2.1
Specification, опубликованная в 2013 году.
Что означает слово ArchiMate? Название языка составлено из двух частей:
ArchiMate = Archi[tecture] + [Ani]mate.
Первая часть слова – это часть слова Architecture (архитектура, конструкция,
строение). Вторая часть слова – это часть слова Animate (оживить, вдохнуть жизнь,
мультиплицировать, делать мультфильмы). В начале работы разработчики языка
думали о том, что модели на языке будут «живыми», что-то наподобие
мультипликации.

3.

Созданию языка ArchiMate предшествовала большая информационно-аналитическая работа, в ходе
которой был проведен анализ сложившейся практики разработки архитектуры предприятия и
определены потребности заинтересованных сторон в проектировании, коммуникациях и
представлении, реализации и управлении изменениями архитектуры предприятия .
В конечном итоге в ходе всестороннего анализа целей и требований удалось сформулировать
исходные положения, которых разработчики придерживались при создании языка, и основные
свойства, которыми должен обладать язык описания архитектуры общего назначения:
сервисная ориентированность языка - понятие «сервис» удобно и наглядно для представления
взаимодействий внутри системы5 или между системами. К тому же, сервисы уже используются в
разных предметных областях и понятны различным заинтересованным сторонам;
послойное строение языка - заимствование из архитектурных фреймворков точки зрения на
предприятие как на систему различных систем, образующих слои (уровни) представления
предприятия;
связность языка - введение в состав языка набора четко определенных отношений, которые
устанавливают связи и зависимости как внутри предметных областей, так и между ними;
компактность языка - ограничение набора понятий языка таким образом, чтобы, оставаясь
простым и доступным, язык был достаточным для моделирования 80 % архитектурных задач;
язык уровня предприятия - акцент на более крупный уровень детализации, чем в языках,
используемых для моделирования на более низких уровнях (например, UML - для
моделирования приложений, BPMN - моделирование бизнес-процессов);
совместимость языка - совместимость понятий языка с понятиями языков на других уровнях
моделирования, например, понятия проектного управления должны без затруднений
выражаться более общими понятиями архитектурного языка;
прагматичность - максимальное использование понятий и конструкций из других языков там, где
это возможно;
расширяемость языка - определение механизмов и средств расширения понятий, входящих в
ядро языка, для отражения специфики исследуемых предметных областей;
независимость языка от конкретных архитектурных фреймворков и методологий.

4. Позиционирование ArchiMate

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

5. Базовые понятия языка - элементы и отношения

Базовые понятия языка элементы и отношения
Элементы.
Элементы в языке различаются по трем
признакам, или аспектам (рис. 1):
структурный/поведенческий;
внешний/внутренний взгляд на систему;
индивидуальный/коллективный.

6.

Рис.1. Метамодель-основные понятия языка

7.

Первый аспект разделяет элементы языка на три типа:
активный структурный элемент, пассивный структурный
элемент и элемент поведения.
Активный структурный элемент (active structure
element) определяется как некая сущность, которая
способна выполнять определенные действия. Это могут
быть бизнес-исполнители, компоненты приложений или
устройства, которые реально исполняют те или иные
действия.
Пассивный структурный элемент (passive structure
element) определяется как некоторый объект, на
котором выполняются действия. Обычно это
информационные объекты или объекты данных, также
они могут быть использованы для представления
физических объектов, над которыми выполняются те или
иные действия.
Элемент поведения (behavior element) определяется как
некоторая единица действия, выполняемая одним или
несколькими активными структурными элементами.

8.

Элементами поведения являются процессы,
функционалы (функции), сервисы и события.
Они назначаются активным структурным
элементам, чтобы показать, кто или что
производит те или иные действия.
Следует отметить, что разделение элементов
по аспекту «структурный/поведенческий»
похоже на структуру человеческих языков, в
которых в состав предложений входят
существительное-подлежащее
(в ArchiMate - активный структурный элемент,
то есть субъект поведения), глагол-сказуемое
(элемент поведения, то есть выполнение
поведения) и существительное-дополнение
(пассивный структурный элемент, то есть
объект, на котором выполняется поведение).

9. Пример 1. 

Пример 1.
Использование элементов «бизнес-исполнитель»,
«бизнес-роль», «бизнес-процесс» и «бизнес-сервис».
В модели показана страховая компания, которая
представляется как бизнес-исполнитель. В ее состав
входят два отдела - отдел страхования багажа и отдел
страхования поездок (рис. 2).
Отделу страхования поездок назначена бизнес-роль
по продаже соответствующих страховок - «Продавец
страховок на поездки». В этой роли отдел страхования
поездок выполняет бизнес-процесс по выписыванию
страхового полиса - «Выписать страховку на поездку».
Данный бизнес-процесс реализует бизнес-сервис
страхования поездок, который предоставляется
потребителю.

10.

Рис.2. Пример использования элементов «бизнесисполнитель», «бизнес-роль», «бизнес-процесс» и
«бизнес-сервис».

11.

Второй аспект различает внешний и внутренний взгляды
на систему, и на этой основе вводятся понятия «сервис» и
«интерфейс» (рис. 1.)
Сервис определяется как единица функциональности,
которую система предоставляет своему окружению,
скрывая при этом внутренние операции. Можно сказать,
что сервис представляет собой внешне видимое
поведение системы с точки зрения внешних систем,
которые используют этот сервис. Для внешних систем
сервис предоставляет определенную ценность, что и
является мотивацией его существования. Для внешних
систем значимы только раскрытая (внешняя)
функциональность и ценность сервиса (которую могут
обеспечивать и нефункциональные характеристики,
например, качество сервиса, стоимость). Доступ к
сервисам осуществляется через интерфейсы.
Интерфейс определяется как точка доступа, в которой
сервис становится доступным внешнему окружению.
Интерфейс относится к активным структурным
элементам.

12.

Сервисы являются основными связующими звеньями между
различными слоями. Например, приложение обеспечивает сервисы
для слоя бизнес-процессов и, в свою очередь, использует сервисы
инфраструктурного слоя.
Исходя из этого, различают внутренние и внешние сервисы.
Внутренние сервисы - это сервисы, доступные внутри данного слоя;
внешние сервисы - это сервисы слоя, доступные извне данного слоя.
В таблице 1 суммируется разделение элементов на
структурные/поведенческие и на внешние/внутренние, которое
играет центральную роль в языке.
Таблица 1. Распределение элементов языка по аспектам
структурный/поведенческий и внешний/внутренний.

13. Пример 2.

Использование элементов «функционал приложений»,
«сервис приложений» и «интерфейс приложений».
В модели показано, что сервис приложений «Сервис
обработки транзакций» реализуется функционалом
приложений «Учет» и доступен другим компонентам через
интерфейс приложений «API обработки транзакций» (рис. 3).
Функционал приложений «Учет» выполняется компонентом
приложений «Компонент учета». Сервис приложений
«Обработка транзакций» используется функционалом
приложений «Биллинг», который выполняется компонентом
приложений «Компонент биллинга».
Функционал приложений «Биллинг» предлагает сервис
приложений «Сервис создания накладной», который может
быть использован для поддержки бизнес-процессов. Данный
сервис доступен через интерфейс приложений «Экран
биллинга».

14.

Рис. 3. Использование элементов «функционал приложений»,
«сервис приложений» и «интерфейс приложений».

15. Пример 3.

Продукт, состоящий из нескольких бизнес-сервисов.
В модели показан продукт «Телебанкинг»,
предлагаемый клиентам (рис. 4).
Открытие счета и поддержка приложений (например,
helpdesk и т. п.) осуществляется соответствующими
бизнес-сервисами, которые реализуются бизнесисполнителем «Клиентский отдел».
Как часть продукта потребитель может также
использовать банковский сервис, который предлагает
такие сервисы приложений, как электронный денежный
перевод и предоставление статуса счета.
Сервисы приложений реализуются компонентом
приложений «Телебанкинг».

16.

Рис. 4. Продукт, состоящий из нескольких бизнес-сервисов.

17.

Третий аспект учитывает то, что определенное
действие (поведение) может выполняться одним
структурным элементом и коллективом, то есть
совместно несколькими структурными
элементами (например коллективом
сотрудников). Соответственно выделяют
активный структурный элемент «совместная
бизнес-деятельность» и элемент поведения
членов этого коллектива - «взаимодействие».
Совместная деятельность (collaboration)
определяется как группировка (или объединение)
- возможно, временная - двух или более
структурных элементов для выполнения
некоторого совместного поведения.
Взаимодействие (interaction) определяется как
единица поведения, выполняемая в рамках
совместной деятельности двух или более
структурных элементов.

18. Пример 4. 

Пример 4.
Использование элемента «совместная
бизнес-деятельность».
В продаже страховок задействованы
отдел продаж, выполняющий роль по
поддержке продаж, и отдел,
специализирующийся на определенном
типе страхования, выполняющий роль
продавца страховок (рис. 5).
В примере также показано, что одна роль
может участвовать в более чем одной
совместной бизнес-деятельности.

19.

Рис. 5. Использование элемента «совместная бизнес-деятельность».

20. Отношения.

Отношения в языке - это различного рода соединения,
связывающие элементы и определяющие свойства этих
соединений (например, физические/логические, между
структурными элементами и элементами поведения).
Отношения в языке разделяются на три группы: структурные,
динамические и другие.
Структурные отношения - это отношения, которые
моделируют структурные зависимости между элементами
одного или разных типов.
Динамические отношения - это отношения, которые
используют для моделирования зависимостей между
элементами поведения (действиями).
В группу «другие» относят отношения, которые не входят в
первые две группы. Многие из отношений были заимствованы
из существующих стандартов: например, композиция
(composition), объединение (aggregation), ассоциация
(association) и специализация (specialization) взяты из UML 2.0,
а запуск (triggering) используется во многих языках
моделирования бизнес-процессов.

21.

1. Структурные отношения
Всего имеется 7 типов структурных отношений:
композиция, объединение, назначение, реализация,
использование, доступ и ассоциация.
1.1. Отношение «композиция» показывает, что объект
состоит из одного или более других объектов
Объект может быть частью только одной композиции (в отличие от
отношения «объединение») .

22. Пример отношения «композиция»

Альтернативные способы изображения

23.

1.2. Отношение «объединение» показывает, что элемент
образует группу из ряда других объектов
Отношение «объединение» всегда возможно между двумя
экземплярами элементов одного типа.
Говорят, что отношение «композиция» – это сильное владение. Это
отношение «целое – часть».
В этом смысле отношение «объединение» является слабым
владением.

24. Пример отношения «объединение»

В примере показаны два способа отображения того факта, что
продукт «Страхование Авто» объединяет Полис (элемент
«Контракт») и два бизнес- сервиса

25.

1.3. Отношение «назначение» связывает активные
элементы с единицами поведения, которые
выполняются этими элементами, или бизнесисполнителей с бизнес-ролями, которые выполняются
исполнителями.
Отношение «назначение» может соединять:
Бизнес-исполнителя с бизнес-ролью,
Бизнес-роль с бизнес-процессом или функционалом,
Совместную бизнес-деятельность с бизнесвзаимодействием,
Бизнес-интерфейс с бизнес-сервисом,
Компонент приложений с функционалом приложений,
Совместную работу приложений с взаимодействием
приложений,
Интерфейс приложений с сервисом приложений,
Площадку с бизнес-объектом, представлением или
бизнес-исполнителем.

26.

Обозначение отношения «назначение»
Пример отношения «назначение»
Функционал приложений «Платежи» назначается компоненту
приложений «Финансовое приложение» (способ вложения) и
сервис приложений «Сервис платежей» назначается интерфейсу
приложений «Интерфейс платежей» (явное связывание).

27.

1.4. Отношение «реализация» связывает логическую
сущность с более конкретной сущностью, которая ее
реализует.
Элемент, соприкасающийся со стрелкой, - это элемент,
создаваемый элементом на другом конце соединения.
Отношение «реализация» показывает, как логические (более
абстрактные) сущности, такие, как сервисы, реализуются
средствами более конкретных (реальных) сущностей.
Например, процесс/функционал реализует сервис, объект данных
реализует бизнес-объект или артефакт реализует компонент
приложений.

28. Пример отношения «реализация»

Компонент приложений «Финансы» реализует сервис приложений
«Сервис биллинга», а объект данных «Данные биллинга» реализует
бизнес-объект «Накладная».

29.

1.5. Отношение «использование» моделирует
использование сервисов процессами, функционалами
или взаимодействиями, а также доступ к интерфейсам
ролями, компонентами или совместными
деятельностями/работами.
Элемент, соприкасающийся со стрелкой, использует
элемент на другом конце соединения.
Отношение «использование» применяется как между
структурными элементами, так и между элементами
поведения.

30. Пример отношения «использование»

Применение отношения «использование»: интерфейс приложений (в
данном случае интерфейс CRM-системы) используется служащим
фронт-офиса, в то время как, сервис приложений «Сервис изменения
информации по клиенту» используется бизнес-процессом «Изменить
адрес».

31.

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

32. Пример отношения «доступ»

Процесс «Создать накладную» пишет/создает бизнесобъект «Накладная», а процесс «Направить
накладную» читает бизнес-объект «Накладная».

33.

1.7. Отношение «ассоциация» моделирует отношение
между объектами, которое не охватывается другим,
более характерным отношением .
Если необходимо связать два элемента, но точно
неизвестно каким образом, то можно применить данное
отношение.
В основном оно используется для моделирования
отношений между бизнес- объектами или объектами
данных, которые не моделируются отношениями
«объединение», «композиция» или «специализация».
Также используется для связывания пассивных
структурных элементов с другими элементами: бизнесобъект с образом объекта, образ объекта со смысловым
значением, бизнес-сервис с ценностью.

34. Пример отношения «ассоциация»

35. 2. Динамические отношения

Динамические отношения - это отношения, которые
используют для моделирования зависимостей между
элементами поведения. Всего имеется два типа
динамических отношений: запуск и передача.
2.1. Отношение «запуск» описывает временные или
причинные отношения между процессами,
функционалами, взаимодействиями и событиями.
Отношение «запуск» используется для моделирования
причинных отношений между элементами поведения в
процессе.

36. Пример отношения «запуск»

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

37.

2.2. Отношение «передача» описывает обмен или
передачу, например, информации или ценности между
процессами, функционалами, взаимодействиями и
событиями.
Отношение «передача» используется для
моделирования передачи (потока), например,
информации между элементами поведения в
процессе.
Отношение «передача» не подразумевает
причинной или временной зависимости.

38. Пример отношения «передача»

В примере бизнес-функционал «Оценка претензий» направляет решения о
претензиях бизнес-функционалу «Урегулирование претензий» .
Для того, чтобы принять решение о порядке урегулирования претензии,
бизнес- функционал «Оценка претензий» использует данные о платежах,
полученные от бизнес-функционала «Планирование».

39. 3. Другие отношения

Другие отношения - отношения, которые не входят в
первые две группы. Всего имеется три типа других
отношений: группирование, связывание- разветвление,
специализация.
3.1. Отношение «группирование» обозначает объекты
одного или разных типов, которые объединяются на
основе некоторого общего признака.

40.

В отличие от отношений «объединение» или
«композиция» у отношения «группирование»
нет «общего» объекта, в отношении которого
сгруппированные объекты формируют часть.
Отношение «группирование» используется
только для того, чтобы показать графически,
что у элементов модели имеется что-то общее.
Это способ сделать представление более ясным
для пользователя. Внешне выглядит как
элемент, но это отношение.
Элементы модели могут принадлежать
различным (перекрывающимся) группам.

41. Пример отношения «группирование»

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

42.

3.2. Отношение «связывание-разветвление»
используется для связывания динамических отношений
одного типа .
Отношение «связывание-разветвление»
используется в ряде ситуаций для связывания
динамических отношений одного типа (запуск
или передача).
Например, для обозначения разветвлений или
соединений.

43. Пример отношения «связывание-развертывание»

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

44.

3.3. Отношение «специализация» показывает, что
объект является специализацией другого объекта.
Данное отношение занимает особое положение. Оно
говорит, что элемент является разновидностью
(конкретизацией) другого элемента.
Отношение «специализация» может соотносить любой
экземпляр элемента с другим экземпляром элемента того
же типа.
Отношение «специализация» всегда возможно между
экземплярами одного типа.

45. Пример отношения «специализация»

Пример иллюстрирует использование отношения
«специализация» для понятия «бизнес-процесс».
Экземпляр процесса «Оформить страховку на поездку» и
экземпляр процесса «Оформить страховку на багаж»
являются специализацией более общего экземпляра
процесса «Оформить страховку».

46. 4. Производные отношения

4.1. Производные структурные отношения.
Структурные отношения формируют важную
категорию отношений для описания общей
связности.
На рисунке структурные отношения приведены в
порядке возрастания их «силы»:
ассоциация – слабейшее структурное
отношение;
композиция – сильнейшее структурное
отношение.

47. Сила структурных отношений

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

48.

Если два структурных отношения r:R и s:S разрешены
между элементами a,b и с таким образом, что r(a,b) и
s(b,c), то структурное отношение t:T t(a,c) также
разрешено и тип T равен слабейшему из R и S.
Транзитивное применение этого свойства позволяет
заменить цепочку структурных отношений (с
промежуточными элементами модели) слабейшим
структурным отношением в цепочке.
Используя правило объединения и замены отношений,
становится возможным определять производные
(косвенные) отношения, которые существуют между
элементами модели, что может быть полезно для
проведения определенных видов анализа .

49. Пример производных структурных отношений

50.

Например, каким будет воздействие на клиента при
отказе работы CRM-системы?
От элемента «CRM-система (Компонент приложений)» к
элементу «Клиент (Бизнес-исполнитель)» может быть
выведено производное отношение «использование»
(красная стрелка слева) из цепочки отношений
назначение – использование - реализация –
использование – реализация, выделенных синим цветом.
Таким образом, использование клиентом сервиса
«Сервис регистрации претензий» станет невозможным
при отказе CRM-системы. А, например, использование
сервиса «Сервис оплаты претензий» останется
возможным, поскольку не существует производного
структурного отношения между CRM- системой и
сервисом «Сервис оплата претензий».

51.

4.2. Производные динамические отношения.
Для двух динамических отношений «запуск» и
«передача» применимы следующие :
начальная и/или конечная точка отношений «запуск»
или «передача» между элементами поведения
(например, процессами или функционалами) может
быть перенесена к активным структурным элементам
(например, бизнес- исполнителям или компонентам
приложений), которые назначены (приписаны) к ним;
начальная и/или конечная точка отношений «запуск»
или «передача» между элементами поведения может
быть перенесена к сервисам, которые они реализуют.

52. Пример производных динамических отношений

53. Слои языка

Обычно архитектурные описания делают для различных
областей, или так называемых «слоев» организации.
Эти области называют слоями в том смысле, что более
нижние слои обеспечивают функциональность более
высоким.
В этом контексте для описания предприятия в языке
определяются три основных слоя: бизнес-слой, слой
приложений и технологический слой
Они хорошо соотносятся с фазами TOGAF и с
соответствующими архитектурами - B (Бизнесархитектура), C (Архитектура информационных систем)
и D (Технологическая архитектура).
В каждом слое используется общая концепция
элементов языка (с их аспектами) и отношений. Это
позволяет выделить в слоях несколько доменов,
описывающих различные предметные области в рамках
слоя. Соотношение слоев, элементов и отношений языка
и архитектурных доменов показано на рисунке 6.

54.

Рис. 6. Соотношение слоев и аспектов языка и архитектурных доменов.

55.

Каждый из слоев определяет свои, специфические для слоя,
элементы, которые представляют специализацию базовых
понятий, то есть их конкретизацию применительно к рамкам
того или иного слоя. В каждом слое есть свои исполнители
работ, свои работы и свои объекты работ:
бизнес-слой описывает деятельность и развитие
предприятия, а также его окружение. Описываются продукты
и услуги для внешних потребителей, основные бизнеспроцессы и сервисы, бизнес-исполнители и бизнес-роли,
выполняющие эти процессы, а также используемая
информация (бизнес-объекты);
слой приложений описывает приложения, их
функциональность и отношения между приложениями. Также
описываются сервисы приложений, оказывающие поддержку
бизнес-слою, и основные объекты данных, используемые
приложениями;
технологический слой описывает устройства
(вычислительное и коммуникационное оборудование) и
системное программное обеспечение, на которых
выполняются приложения, артефакты, которые формируют
физическую реализацию компонентов приложений или
объектов данных, и инфраструктурные сервисы (например,
обработку, хранение, коммуникации), необходимые для
выполнения приложений.

56.

Общая структура моделей внутри разных слоев похожа,
поскольку используются те же типы элементов и отношений
(эта общая метамодель показана на рис. 1).
Однако природа элементов и степень их детализации
различны и определяются потребностями каждого слоя.
Кроме того, могут использоваться некоторые дополнительные
понятия. Например, в бизнес-слое используются понятия
продукта и связанного с ним контракта, смыслового значения
бизнес-объекта и ценности продукта/услуги.
Взаимосвязи между слоями формируются отношениями
«использование» и «реализация»:
отношение типа «использование» показывает, как более
высокий слой использует сервисы более низкого слоя;
отношение типа «реализация» показывает, как элементы
более низких слоев могут реализовывать сопоставимые
элементы более высоких слоев.
Например, элемент «объект данных» в слое приложений может
реализовывать элемент «бизнес-объект» в бизнес-слое. А
элемент «артефакт» в технологическом слое может
реализовывать элемент «объект данных» или элемент
«компонент приложений» в слое приложений.

57. Пример 5.

Многослойное представление
архитектуры предприятия.
В модели показан многослойный
способ представления, показывающий
несколько слоев и аспектов
архитектуры предприятия на одной
диаграмме (рис. 7).

58.

Рис. 7. Многослойное представление архитектуры предприятия.

59.

Сервисы являются связующими
звеньями между различными слоями

60.

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

61. Фреймворк языка

Объединение трех слоев и трех типов
элементов языка образует таблицу,
состоящую из 9 ячеек.
Эту таблицу называют фреймворком языка.

62. Механизмы расширения языка

Язык используется для специальных целей, например,
поддержки специальных типов анализа, или для
отражения особенностей определенных доменов
(функциональных/предметных областей) предприятия
(например, финансовый домен организации). В этих
случаях понятий, входящих в ядро языка, может
оказаться недостаточно.
Язык предоставляет средства по расширению множества
понятий, входящих в его ядро. Эти дополнительные
понятия отражают специфику исследуемых доменов и
используется только в этих целях. Тем самым ядро не
перегружается новыми понятиями и обозначениями,
которые не будут применяться другими пользователями
языка.
Расширение ядра языка осуществляется двумя способами:
через добавление дополнительных атрибутов к
существующим понятиям (механизм профилирования);
через определение новых понятий на основе уже
существующих (механизм специализации).

63.

Начиная с версии 2.0 в язык включены два расширения его
ядра: расширение, связанное с мотивационными факторами, и
расширение, связанное с реализацией и переходом.
Первое расширение необходимо для поддержки фаз A
(Видение архитектуры) и H (Управление изменениями
архитектуры) метода разработки архитектуры TOGAF, а также
предварительной фазы и фазы управления требованиями. Для
этого ядро языка было расширено элементами и
отношениями, связанными с мотивационными факторами:
«заинтересованная сторона», «драйвер», «требования» и т. д.
Перечень элементов и отношений, связанных с
мотивационными факторами, дан в приложении 4.
Второе расширение предназначено для поддержки фаз E
(Возможности и решения), F (Планирование перехода) и G
(Руководство реализацией) метода разработки архитектуры
TOGAF. Для этого ядро языка было расширено элементами и
отношениями, связанными с реализацией и переходом: «пакет
работ», «поставляемый результат», «разрыв» и т. д. Перечень
элементов и отношений, связанных с реализацией и
переходом, приводится в приложении 5.

64. Способы представления

Полная модель архитектуры предприятия достаточно сложна и
объемна. Более того, заинтересованные стороны часто самостоятельно
определяют требуемые им представления общей архитектуры
предприятия. Для этого язык вводит понятие «представление» (view)
архитектуры и обеспечивает гибкий подход к работе с архитектурными
представлениями.
Представление архитектуры - это часть общего архитектурного
описания, которая исследует заданный перечень вопросов и
адресована определенному кругу заинтересованных сторон.
Представления задаются способами представления (точками зрения,
viewpoints), которые используются для показа определенных
аспектов архитектуры по отдельности или в связке.
Способ представления - это спецификация по конструированию и
использованию представления, в которой описываются
используемые понятия, модели, способы анализа и визуализации,
поддерживающие представление.
Можно сказать, что представление - это то, что мы видим, а способ
представления - это точка зрения, с которой мы смотрим . Способ
представления позволяет фокусировать внимание на определенных
аспектах архитектуры, которые определяются интересами
заинтересованных сторон. Именно они в конечном итоге
определяют, какие элементы и отношения будут включены в
представление.

65.

Способы представления классифицируются в языке по двум
измерениям: по назначению и по содержанию. В свою очередь каждое
из измерений разбивается соответственно на 3 типа и 3 уровня:
по назначению - для проектирования, для принятия решений, для
информирования;
по содержанию - детальный уровень, уровень согласованности и
обзорный уровень.
Следует подчеркнуть, что данная классификация носит условный
характер, то есть необязательно, чтобы каждый способ представления
попадал только в одну категорию. Например, представление
архитектуры, предназначенное для принятия решений, может
использоваться и в информационных целях.
Язык предоставляет набор стандартных способов представления, в
который входят 18 способов. Описание каждого стандартного способа
представления включает целевую аудиторию (перечень
заинтересованных сторон), общие указания по использованию,
назначение, уровни содержания и включенные в него элементы и
отношения. Кроме того, для привлечения внимания к определенным
аспектам архитектурной модели могут использоваться цвета.
Использование цвета оставлено на усмотрение пользователей языка.
Например, в спецификации языка цвета применяются для выделения
слоев: желтый цвет используется для бизнес-слоя, синий - для слоя
приложений и зеленый - для технологического слоя

66. TOGAF и ArchiMate

TOGAFи ArchiMate являются стандартами The Open
Group, которые непосредственно относятся к разработке
архитектуры предприятия. С одной стороны, у TOGAF и
ArchiMate имеются свои спецификации, и они могут
использоваться по отдельности, независимо друг от
друга, или вместе с другими стандартами. С другой
стороны, существуют значительные преимущества при
совместном использовании TOGAF и ArchiMate.
Основная цель языка в контексте методологии TOGAF представление архитектурных моделей. ArchiMate
дополняет TOGAF, обеспечивая необходимый набор
понятий и обозначений. Язык позволяет создавать как
отдельные модели, в том числе соответствующие
представлениям TOGAF, так и модели, объединяющие
различные домены архитектуры. С включением двух
расширений язык полностью покрывает все фазы метода
разработки архитектуры TOGAF (таблица 2).

67.

Таблица 2. Использование понятий языка на различных фазах метода
разработки архитектуры TOGAF.
В рамках консорциума The Open Group продолжаются работы по
развитию ArchiMate, сближению его спецификации со спецификацией
TOGAF. В частности, рассматривается разработка новых расширений
языка, которые будут включать понятия для моделирования бизнесполитик и процессов принятия решений .

68. Пример модели архитектуры «Как есть»

Архитектура банка «как есть» описана с трех точек зрения для
сегмента, выбранного из карты бизнес-процессов «Предоставление
услуг»:
Диаграмма 7 представляет бизнес-уровень указанного сегмента.
Связь с актерами осуществляется через сервисы. Внутренние
бизнес-процессы разделены на работу с физическими и
юридическими лицами. Основную деятельность банка
поддерживает группа вспомогательных процессов.
На Диаграмме 8 изображен уровень приложений архитектуры банка.
Связь back и front офисов осуществляется через корпоративную
шину. Пользователь использует приложения через сервисы.
Технологическая структура, представленная на Диаграмме 9
отображает ИТ-инфраструктуру банка. Существует основный ЦОД
1 и резервный ЦОД 2, в которых установлены мэйнфреймы.
Взаимодействие между ЦОДами осуществляется через выделенный
канал связи. Обмен данными с сервисами осуществляется через LAN.

69.

70.

71.

72. Целевая архитектура «Как будет»

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

73.

Пример модели архитектуры
«Как будет»
Как видно из Диаграммы 10 в слое сервисов
добавился сервис «Банк документов»,
реализующий добавленные функции.
На уровне вспомогательных процессов добавлен
процесс «Администрирование» приложения «Банк
документов»».
На Диаграмме 11, изображающей слой приложений,
добавлен компонент приложения в front офисе, а
также сервис, связывающий его с
конечным пользователем.
На Диаграмме 12 видно, что ИТ-инфраструктура
при инжиниринге предприятия не изменилась.

74.

75.

76.

77. Модель приложения «Банк документов»

78. Высокоуровневое описание торгово-розничного предприятия

79. Цель изменения архитектуры

80.

81. Целевая Бизнес-модель

82. План перехода к целевой архитектуре