Примеры видов ArchiMate: Полная галерея – Мотивация, стратегия, бизнес, приложения, технологии и миграция

Вид фреймворка

Вид фреймворка.

Этот вид представляет собой фреймворк для построения всех аспектов разработки и связанных диаграмм. Вид можно изменить в зависимости от ситуации. Поэтому этот вид можно использовать для навигации между диаграммами. Эта версия вида применяется из фреймворка ArchiMate (3). Мотивация здесь представлена как «уровень», а не как «аспект».

Точка зрения мотивации

Точка зрения мотивации

Точка зрения мотивации.

Этот вид можно использовать для анализа мотиваций или факторов, которые направляют организацию и её проектирование или изменение архитектуры предприятия. Анализ мотиваций является отправной точкой для всех мероприятий по изменению или трансформации бизнеса в организации. Этот вид отражает видение работы по разработке — охватывает ли оно всю организацию или её часть (например, бизнес-линию) или отдельную программу или проект (уровень решения). Примечание: к элементу, например, результату (или любому другому элементу ArchiMate), можно добавить значение, чтобы показать реальную добавленную стоимость!

Элементы мотивации основаны на модели бизнес-мотивации (BMM) [спецификация версия 1.3, 2015, OMG].

Вид миссии – видения – ценностей

Миссия – Видение – Ценности.

Этот вид можно использовать для представления миссии, видения и основных ценностей организации. Миссия, например, выражает: «Какова цель организации, что она на самом деле делает или намерена делать, и какова основная причина её существования?» Видение — это будущее состояние, к которому организация стремится. Основные ценности поддерживают видение, формируют культуру и отражают ценности организации. Для реализации видения организации необходимо достичь стратегических целей.

Источник: Aldea, A. – Iacob, M.-E. – Hillegersberg, J. – Quartel, D. – Franken, H. (2015) Моделирование стратегии с использованием ArchiMate.

Вид стратегической карты стоимости

Карта стоимости – Вид стратегической карты.

Этот вид можно использовать для визуализации стратегии организации. Вид содержит элементы стратегической стоимости, и все мероприятия по разработке должны быть выведены — напрямую или косвенно — из элементов стратегической стоимости. Визуализируя стратегическую стоимость, можно отслеживать все другие элементы, связанные с реальной реализацией стратегии. С помощью этого вида стратегия становится осязаемой: визуализируется, передаётся и связывается с реальностью.

Вид анализа заинтересованных сторон

Вид анализа заинтересованных сторон.

Этот вид можно использовать для анализа заинтересованных сторон в контексте развития бизнеса: какие факторы вызывают изменения? Сначала определяются соответствующие заинтересованные стороны, затем выявляются факторы изменений, соответствующие их интересам. Понятие «Оценка» можно использовать для более детального анализа факторов, например, по методу SWOT (сильные и слабые стороны, возможности и угрозы). Обычно можно создать различные виды заинтересованных сторон с разных точек зрения. Другая причина разделения крупной картины на более мелкие — сохранить диаграммы компактными и читаемыми — для простоты.

Точка зрения заинтересованных сторон

Точка зрения заинтересованных сторон.

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

Вид принципов

Вид принципов.

Вид рисков и безопасности

Вид рисков и безопасности. Сопоставление концепций рисков и безопасности с ArchiMate. Вопросы безопасности и защиты данных являются частью управления рисками. Этот подход к моделированию охватывает оба аспекта.

Источники:

• Как моделировать управление рисками предприятия и безопасностью с помощью языка ArchiMate®, The Open Group, документ № W172, 2017.
• Моделирование управления корпоративными рисками и безопасностью с использованием языка ArchiMate®, The Open Group, 2015.

Вид анализа SWOT

Вид анализа SWOT.

Вид целей

Вид целей (с элементом ценности).

Цели и ключевые результаты

Шаблон OKR.

OKR — это популярная стратегия управления, предназначенная для определения целей и отслеживания результатов. Она помогает обеспечить согласованность и вовлеченность вокруг измеримых целей. OKR состоит из двух важных частей: цели, которую вы хотите достичь, и ключевых результатов, которые показывают, как измеряется достижение цели.

Цель:

• Запоминающееся качественное описание того, что вы хотите достичь. Цели должны быть краткими, вдохновляющими и захватывающими. Цель должна мотивировать и бросать вызов команде.

Ключевые результаты:

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

Ниже показан другой вариант OKR.

Шаблон OKR (2).

Позиция стратегии

Вид слоя стратегии

Вид стратегии

Вид стратегии.

Версия ArchiMate 3 теперь поддерживает концепции, связанные со стратегией бизнеса, такие как «Путь действий», «Способность» и «Ресурс», которые могут использоваться для моделирования бизнес-стратегии организации. Ценность и важность этого вида заключаются в том, что цели организации могут быть связаны со стратегией, а также в том, как они связаны с корпоративной архитектурой через способности. Этот вид может использоваться для применения «стратегического моделирования на основе целей» (Azevedo et al. 2015), при котором цели образуют иерархию, так что высшие цели могут быть разложены на более низкие.

Вид бизнес-стратегии

Бизнес-стратегия.

Вид модели бизнес-мотивации (BMM)

Вид модели бизнес-мотивации (BMM).

Вид требований

Вид требований.

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

Вид стратегии к способности

Вид стратегии к способности.

Этот вид можно использовать, например, для целей планирования на основе способностей (CBP), а также для других концепций ArchiMate, таких как «Драйвер» и «Цель», как показано на рисунке ниже. Этот вид может использоваться для поддержки целей стратегического планирования (и исполнения). Таким образом, этот вид может использоваться на этапе «стратегия — способность», который может быть включен в «стратегия — портфель» по IT4IT.

Вид карты способностей

Вид карты возможностей.

Этот вид можно использовать для обзора возможностей организации: что организация делает или может делать.

Вид планирования возможностей

Вид планирования возможностей.

Этот вид можно использовать, например, для целей планирования на основе возможностей (CBP), то есть «связь между стратегией и корпоративной архитектурой». Этот вид можно использовать, например, для сопоставления стратегии с необходимыми возможностями, а также возможностей с ресурсами и другими элементами архитектуры.

Вид реализации возможностей

Вид реализации возможностей.

Вид реализации возможностей 2

Другой вид, определяющий, как возможности реализуются с помощью каких элементов…

Вид реализации возможностей 2.

Вид потока стоимости

Вид потока стоимости (шаблон).

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

Вид перекрестного сопоставления потока стоимости и возможностей

Ниже приведен простой пример цепочки доставки стоимости. Цепочки стоимости, сети стоимости и потоки стоимости можно моделировать с помощью элемента ArchiMate «Поток стоимости», включенного в версию ArchiMate 3.1.

Пример цепочки стоимости от идеи до производства.

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

Этот вид включен в справочную реализацию рамочного подхода Lean EA (LEAF) (ссылка). Перейдите к разделам «Потоки стоимости», «Цепочка доставки стоимости».

Вид бизнес-модели

Вид бизнес-модели.

Это базовая форма бизнес-модели А. ОстервальдераБизнес-модель (BMC), но его можно адаптировать в зависимости от ситуации. Существуют также версионированные подходы, такие как «модель сервиса» или «Lean Canvas». BMC можно использовать, например, для проектирования бизнес-модели и инноваций.

Моделирование BMC с помощью ArchiMate «помогает отслеживать требования от бизнес-потребностей до спецификаций проектирования. Это помогает выявить влияние изменений бизнес-модели на архитектурное проектирование». [LO Meertens et al.]

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

Если BMC моделируется в инструменте моделирования, преимуществом этого подхода является то, что все элементы BMC могут использоваться в других видах в одном и том же репозитории моделей. При изменении бизнес-модели все изменения немедленно становятся видимыми. Моделисты бизнеса могут создавать новые элементы (например, услуги) или использовать все существующие элементы в репозитории (например, организационные единицы или ресурсы).

Вид концептуального полотна

Концептуальное полотно. BMC может иметь различные варианты, как показано на приведенном ниже рисунке. Макет этого концептуального полотна соответствует многоуровневому подходу ArchiMate.

Бизнес-точка зрения

Вид слоя бизнес-архитектуры.

Вид карты бизнес-услуг

Вид бизнес-услуг.

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

Вид карты бизнес-процессов

Вид бизнес-процессов.

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

Вид кооперации бизнес-процессов

Вид кооперации бизнес-процессов.

Этот вид может использоваться, например, для моделирования операционных моделей.

Вид карты бизнес-акторов

Вид бизнес-акторов.

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

Вид кооперации бизнес-акторов

Вид кооперации бизнес-акторов.

Два случая использования следующие:

1. Внутренний вид предприятия: точка зрения кооперации бизнес-акторов, описывающая, как внутренние бизнес-акторы взаимодействуют и обмениваются информацией.
2. Межорганизационный вид: точка зрения экосистемы, иллюстрирующая среду функционирования организации. Экосистема — это сеть организаций и деловых партнеров, которые сотрудничают через совместные взаимодействия. Сюда входят поставщики, субподрядчики и другие B2B-партнеры, клиенты и т.д.

Вид бизнес-процессов

Вид бизнес-процессов.

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

Ниже показан общий вид процесса. Он основан на операционной модели, полученной из бизнес-модели, как показано на диаграмме потока стоимости выше.

Процесс от идеи к производству.

SIPOC (поставщики, входы, процесс, выходы, клиенты)

SIPOC.

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

Вид бизнес-процессов с бизнес-ролями как «плавными полосами» процесса — многоуровневый подход

Вид бизнес-процессов по «плавным полосам» (шаблон) 2.0.

«Бизнес-роль А» представляет клиента, а верхняя «плавная полоса» представляет путь клиента.

Примечание! Шаги процесса (деятельность) вложены внутри бизнес-ролей (визуализируются как «плавные полосы»), что означает: эти бизнес-роли назначены этим бизнес-процессам/шагам процесса. Следовательно, этот вид представляет собой комбинацию вида бизнес-процессов и многоуровневого вида.

Версия ниже иллюстрирует потоки информации и данных (связи потоков). Верхняя «плавная полоса» представляет путь клиента (деятельность, связанная связями запуска).

Вид бизнес-процессов по «плавным полосам» (шаблон) 2.0 (поток информации).

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

Вид бизнес-процессов по «плавным полосам» (шаблон) 2.0 (сервисы).

Многоуровневый вид бизнес-процессов

Многоуровневый вид процессов.

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

Вид карты пути клиента

При анализе пути клиента на высоком уровне эта версия создается с использованием элементов мотивации и стратегии.

Карта пути клиента (на высоком уровне).

При более детальном анализе путей обслуживания клиентов эта версия создается с использованием элементов бизнес-слоя и слоя приложений (основных).

Вид пути клиента (пример) 1.0.

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

Вид сервисного чертежа

Вид сервисного чертежа 1 (сервисы и потоки)

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

Этот вид имеет несколько вариантов. Приведенный выше пример фокусируется на потоках информации между уровнями и элементами.

Вид пользовательской истории

Вид пользовательской истории.

Этот вид можно использовать для визуализации пользовательских историй.

Вид моделей облачных сервисов

Вид моделей облачных сервисов.

Вид информации

Вид информации.

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

Вид концептуальной модели данных

Вид концептуальной модели данных.

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

Концепция «Услуга»

Концепция услуги.

Концепция услуги часто вызывает сложности и может трактоваться по-разному. Чтобы четко различать типы услуг, рекомендуется использовать префикс: бизнес-услуга, прикладная услуга или технологическая услуга. Согласно ITIL, ИТ-услуги связаны с производственными услугами. Именно так. ИТ-услуги наиболее близко соответствуют прикладным услугам.

Услуга против продукта

Вид продукта.

Концепция продукта может использоваться в качестве составного элемента для группировки услуг. Согласно спецификации ArchiMate:

«Продукт представляет собой совокупность согласованных услуг и/или пассивных элементов структуры, сопровождаемых набором контрактов/соглашений, предлагаемых целиком (внутренним или внешним) клиентам.»

«Продукт может агрегировать или компоновать бизнес-услуги, прикладные услуги и технологические услуги, бизнес-объекты, объекты данных и технологические объекты, а также контракты. Таким образом, продукт может агрегировать или компоновать элементы из слоев, отличных от бизнес-слоя.»

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

Позиция приложения

Вид архитектурного слоя приложения.

Вид карты прикладных услуг

Вид прикладных услуг.

Вид карты приложений

Вид карты приложений.

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

Вид взаимодействия приложений (потоки данных)

Вид взаимодействия приложений.

Вид интеграции приложений (динамические связи)

Несколько альтернативных способов моделирования обмена данными между приложениями показаны в приведенном ниже примере (1–10).

• «Приложение A» владеет объектом данных «A-1», запрошенным «Приложением B».
• Данные поступают от «Приложения A» к «Приложению B».
• «Приложение A» реализует услугу «A-1», используемую «Приложением B».
• На практике «Приложение B» запрашивает интерфейс приложения «A-1» и получает ответ…

Вид интеграции приложений.

Вид структуры приложения

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

Вид структуры приложения.

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

Вид структуры приложения 2.

Вид архитектуры приложения

Этот вид сочетает подходы уровня EA и уровня решения, поскольку как приложения, так и модули приложений существуют в одном и том же виде.

Архитектура приложения.

Модель компонентов приложения (CM)

Модель компонентов приложения 0-n — это метод моделирования архитектуры приложения, состоящий из диаграмм на различных уровнях абстракции, следующим образом:

• На уровне CM-0 диаграмма описывает, как целевое приложение взаимодействует со своей средой и какие взаимодействия существуют с соседними приложениями и пользователями. Целевое приложение описывается как черный ящик.
• На уровне CM-1 целевое приложение разбивается на модули (основные компоненты), и указываются, какие сервисы приложения (или интерфейсы приложения) эти модули предоставляют и требуют. Целевое приложение описывается как белый ящик.
• На уровне CM-2 модули разбиваются на подкомпоненты. (Количество необходимых уровней зависит от ситуации.)

Диаграмма модели компонентов приложения (CM) ниже состоит из компонентов приложения и сервисов приложения. В качестве альтернативы вместо сервисов приложения могут использоваться интерфейсы приложения, в зависимости от ситуации. Как всегда, важно использовать модельный стиль, соответствующий цели, и моделировать только те элементы, которые обеспечивают достаточную информацию и добавляют ценность. Это зависит от моделировщика — предпочитает ли он акцентировать внимание на функциональных аспектах или быть более конкретным и моделировать, например, фактические интерфейсы с точными именами.

Диаграмма модели компонентов ниже состоит из компонентов приложения и сервисов приложения. В качестве альтернативы вместо сервисов приложения могут использоваться интерфейсы приложения.

Модель компонентов приложения – 0 (CM-0)

Модель компонентов приложения – 0.

Уровень модели компонентов – 0 (CM-0) (выше) иллюстрирует взаимодействие между целевым приложением и соседними приложениями. Вводятся все соответствующие сервисы приложения (или интерфейсы приложения). Диаграмма уровня 0 состоит из компонентов слоя архитектуры предприятия и их сервисов, с целевым приложением посередине.

Модель компонентов приложения – 1 (CM-1)

Модель компонентов приложения – 1.

Уровень модели компонентов – 1 (CM-1) (выше) иллюстрирует, как целевое приложение разбивается на модули (или основные компоненты), и какие сервисы приложения (или интерфейсы приложения) реализует каждый модуль. Обратите внимание! Внешние приложения могут быть исключены на этом уровне, но их сервисы (или интерфейсы) отображаются. При отображении более низкоуровневых элементов можно/должны опустить более высокие уровни — для простоты: сохраняйте читаемость диаграммы.

Модель компонентов приложения – 2 (CM-2)

Модель компонентов приложения – 2.

Уровень модели компонентов – 2 (CM-2) (выше) иллюстрирует, как модули целевого приложения состоят из подкомпонентов и как они взаимодействуют.

Вид функций приложения

Разбиение функций приложения: какие функции содержит система и какие сервисы приложения она предоставляет?

Вид функций приложения.

Вид процессов приложения

Вид процессов приложения.

Вид процессов приложения – вложенность.

Вид процессов приложения – внутренняя структура.

Вид диаграммы последовательности компонентов приложения

Диаграммы последовательностей не полностью входят в область применения ArchiMate, но входят в область применения UML. Однако мы можем моделировать, например, последовательность действий, выполняемых компонентами приложения, с использованием ArchiMate, как показано ниже.

Вид последовательности приложения.

Динамические связи «Запуск» и «Поток» могут использоваться для моделирования динамики между компонентами приложения. Макет этого вида может напоминать позиционирование диаграммы последовательности UML.

Вид диаграммы последовательности компонентов приложения 2

Эта версия (ниже) иллюстрирует, как ArchiMate может использоваться для моделирования последовательности действий, выполняемых внутренними частями компонентов приложения. Внутренние части, например, a) поведенческие процессы или функции и b) структурные подкомпоненты. Они моделируются с помощью элементов Application Process, Application Function и Application Component. Здесь они показаны только как альтернативы.

Вид последовательности приложения (2).

Поток операций на этой диаграмме последовательности (выше):

1. Подпроцесс «X» компонента приложения «A» отправляет запрос с параметром «A» приложению B.
2. Подпроцесс «B-1» компонента приложения «B» получает входящий запрос, а затем (синхронно) вызывает компонент приложения C, где функция приложения «Y» получает запрос, выполняет некоторые операции и отвечает.
3. Другой подпроцесс «B-2» компонента приложения «B» отправляет сообщение с параметрами в компонент приложения D и получает подтверждение. Компонент приложения «D» содержит подкомпоненты, выполняющие обработку.
4. Компонент приложения «A» получает сообщение с ответом от компонента приложения B.

Как показано здесь, мы можем моделировать довольно сложные случаи интеграции, комбинируя эти элементы (компоненты приложения, процессы приложения и функции приложения, а также связи (Запуск, Поток)). Диаграммы последовательностей UML имеют свою специализированную область применения в проектировании программного обеспечения, но ArchiMate может использоваться для многих целей моделирования — в том числе и для проектирования приложений.

Интеграция приложений является одной из наиболее важных частей архитектуры предприятия (EA). Именно поэтому полезно моделировать более подробно, как приложения обмениваются данными и какие механизмы взаимодействия используются. Хорошим источником для глубокого понимания паттернов интеграции является книга «Enterprise Integration Patterns», вот ссылка на неёссылка.

Последовательность действий конечного пользователя, добавленная (ниже), следует той же идее использования динамических связей ArchiMate «Запуск» и «Поток», которые могут использоваться для моделирования синхронных и асинхронных паттернов обмена сообщениями (запрос-ответ, обратный вызов, а также публикация-подписка и т.д.).

Вид паттерна последовательности.

Вид процесса ETL

Вид процесса ETL.

Вид EAI / ESB

Вид паттерна EAI – ESB.

Вид многоуровневой структуры

Вид многоуровневой структуры.

Многоуровневый вид может использоваться в качестве обзорной диаграммы контекста целевой области. Основное преимущество этого вида — иллюстрация использования приложений в бизнес-процессах и предоставляемых ими услугах. На приведённой выше фигуре используется элемент группировки ArchiMate для моделирования различных уровней, а на нижней фигуре используется визуальный элемент группы, предоставляемый инструментом (Archi).

В ArchiMate, как правило, три (3) уровня: 1) бизнес-уровень, 2) уровень приложений и 3) технологический уровень. Их цвета обычно следующие: бизнес-уровень — жёлтый, уровень приложений — бирюзовый, технологический уровень — зелёный (см. Архитектурная основа ArchiMate, ссылка).

Вид многоуровневой структуры.

Представление приложений и баз данных

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

Рассмотрение вопросов моделирования баз данных.

База данных как компонент приложения.

Уровни абстракции баз данных.

Представление модели данных.

Представление случаев использования

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

Представление случаев использования (шаблон 1).

Случаи использования можно разделить на: a) бизнес-случаи использования и b) системные случаи использования (также известные как системные случаи использования). На приведенном ниже рисунке показано, как «основные случаи использования» моделируются как бизнес-сервисы, а последующие системные случаи — как сервисы приложений.

Представление случаев использования (пример).

Когда случаи использования идентифицируются как сервисы приложений, они могут быть дополнительно использованы как функциональные элементы целевых приложений в других диаграммах (например, в многоуровневых представлениях). Другими словами: сервисы приложений представляют поведение (функциональность) приложений. Для получения более подробной информации об анализе случаев использования см. ArchiMate Cookbook,ссылка.

Технологическая точка зрения

Представление слоя технологической архитектуры.

Представление инфраструктуры

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

Представление инфраструктуры.

Представление инфраструктуры (вложенное).

Представление слоя реализации и миграции / слоя переходной архитектуры

Представление дорожной карты реализации

Представление дорожной карты реализации.

Представление доски Kanban

Доска Kanban (EA).

Kanban может использоваться для визуализации работы и рабочего процесса. Kanban показывает, например, как требования к разработке, эпизоды, пользовательские истории и т.д. проходят от бэклога до состояния готовности (выполнено). Kanban может применяться для различных целей в зависимости от масштаба и охвата разработки. Например, «эпизоды» могут использоваться на уровне EA, а «пользовательские истории» или «требования» — на уровне проекта. Гранулярность рабочих элементов может варьироваться в зависимости от ситуации.

Общее представление

Общее представление.

Это упрощенное представление может использоваться, например, в качестве диаграммы контекста для конкретного сервиса, программы или проекта.

Дополнительные функции

Обзор контекста — Карта Млечного Пути

Это подход к визуализации максимально возможного количества информации в одном представлении. Для получения дополнительных сведений см. Карта Млечного Пути для ArchiMate,ссылка.

FM Карта Млечного Пути (уровень 2). (Примечание! Эта цветовая схема использует цвета по умолчанию ArchiMate. Другие цвета могут использоваться по мере необходимости.)

Вид сотрудничества

Слои могут быть объединены, как показано в примере диаграммы потока данных ниже.

Вид сотрудничества приложений (расширенный).

Метамодель

Метамодель.