Архитектура приложений и данных. Лекция 2

1. Архитектура приложений и данных Лекция 2

Марина Аншина
Председатель Правления Российского Союза ИТ-Директоров
Член Совета по профессиональным квалификациям в области ИТ (СПК-ИТ)
Доцент Финансового Университета

2. Что было на прошлой лекции

• Системный подход:
– определения системы,
– свойства систем,
– классификация систем
• Архитектура:
– определение,
– моделирование архитектуры,
– интересы, точка зрения на архитектуру и
архитектурные представления ГОСТ Р ИСО/МЭК
57100-2016
• Простейшая слоеная архитектурная модель
• Акт Клингера-Коэна, Federal Enterprise Architecture
Framework (FEAF), Performance Reference Model (PRM)

3. О чем будем говорить

1 Модель Захмана
2 The Open Group
Architecture
Framework
Самая полная архитектурная модель
ADM – Architecture Development Method
3 Archimate
Archi

4. Модель захмана

МОДЕЛЬ ЗАХМАНА

5. Business Systems Planning

• Business System Planning (BSP) - метод анализа,
определения и проектирования информационной
архитектуры организации
• Появился в IBM в 1981 г., хотя работа над ним началась
в начале 1970 гг.
• Сначала использовался как внутренний метод IBM,
позже стал доступен для клиентов.
• В соответствии с Захманом Business Systems Planning
(BSP) и Business Information Control Study (BICS) «методология планирования создания информационных
систем, которая специальным образом применяет
методы анализа, оптимизирующие проектирование
систем и стоимость управления данными.»

6.

7. Джон Захман

• Джон Захман окончил Химический факультет Университета
Northwestern.
• Несколько лет прослужил офицером в Армии США
• Пришёл в 1964 в IBM, где занимал ряд маркетинговых позиций
в Чикаго, Нью-Йорке и Лос-Анжелесе.
• Стал заниматься методологией Strategic Information Planning в
1970 и был назначен ответственным за развитие программы
Business Systems Planning (BSP) в 1973 г.
• В 1984 начал заниматься Архитектурой информационных
систем.
• В 1989 работал в IBM как консультант в области Архитектуры и
планирования ИС
• Уволился из IBM в 1990, проработав там 26 лет.
• После с Самуэлем Холкманом Захман создал Институт
Framework Advancement, просуществовавший до 2008 г.

8. Джон Захман

Схема архитектуры позволяет концентрироваться на отдельных
аспектах системы и, в то же время, не терять ощущение общего
контекста или "холистической" перспективы (то есть взгляда на
предприятие как на целое).
Именно потеря такой перспективы, в частности, разработка
систем субподрядчиками, находящимися "вне контекста" , уже
около пятидесяти лет составляет причину появления
неинтегрируемых и не поддерживающих предприятие систем,
которые к тому же весьма дорого заменять.
John A. Zachman. A Framework for Information System Architecture. IBM
System Journal, vol. 26, no. 3, 1987.
или
"Общая схема архитектуры информационных систем"

9. Фрейворк Захмана

• Фреймворк Захмана в соответствии с Захманом (статья 2008 г.)
– это схема, представляющая собой объединение двух
исторических классификаций, которые используются тысячи
лет.
• Первая – примитивная система вопросов : Что, как, когда, кто,
где и зачем (What, How, When, Who, Where, and Why).
Интеграция ответов на эти вопросы дает полное, комплексное
описание сложных идей".
• Вторая – происходит из овеществления, трансформации
абстрактной идеи в экземпляр, который изначально
определялся греческими философами и обозначается как:
идентификация, определение, представление, спецификация,
конфигурация и конкретизация (Identification, Definition,
Representation, Specification, Configuration and Instantiation). ..."

10.

«Есть у меня шестерка слуг,
Проворных, удалых,
И все, что вижу я вокруг, Все знаю я от них.
Они по знаку моему
Являются в нужде.
Зовут их: Как и Почему,
Кто, Что, Когда и Где.»
Р. Киплинг, перевод С.Я. Маршака
Тони Брегстон Never just for a ring
https://www.youtube.com/watch?v=E75Nymhuz8o

11. Фреймворк Захмана

Фреймворк Захмана – это “теория существования структурированного
набора существенных компонентов объекта, для которых необходимо
иметь прозрачное описания для создания, функционирования и
изменения объекта (объект может быть предприятием,
департаментом, подразделением, решением, проектом, самолетом,
зданием, продуктов, профессией).»
По Захману «эта онтология произошла от аналогичных структур,
которые существуют в других дисциплинах Архитектура/Строительство
и Инжиниринг/Производство, которые классифицируют и организуют
артефакты, созданные в процессе проектирования и производства
сложных продуктов (т.е. зданий или самолетов). Они использует 2-х
размерную классификационную модель, основанную на 6 основных
вопросах (Что, Как, Где, Кто, Когда, и Зачем) и 6 разнообразных
перспективах, которые относятся к различным группам стейкхолдеров
(Стратег – планировщик, Владелец, Проектировщик, Создатель Строитель, Исполнитель – реализатор и Работник).
Ячейки пересечения соответствующей модели фреймворка, если
хорошо описаны, обеспечивают целостный взгляд на предприятие».

12.

• Захман сказал «Так же как вам нужен
архитектор, чтобы построить здание,
вам нужен кто-то, кроме инженера,
чтобы ваше предприятие могло
реализовывать изменения".

13. Архитектура информационной системы предприятия по модели Дж. Захмана 1987 года

ДАННЫЕ, ЧТО
Потребности и
внешняя среда
1. ---------2. ----------
Бизнесмодель
предприятия
ФУНКЦИИ, КАК
1. ---------2. ----------
……….
.
Представление
аналитиков --
….
….
логическая модель
Техническая
архитектура
Детальная
реализация
(субподряд)
Взгляд
пользователя
СЕТЬ, ГДЕ
INDEX
SCREEN
WIZARD
CREATE TABLE
BEGIN BLOCK
BEGIN ..
END
Меню
Ввод
Печать
C:>PING
Wait, please

14.

Архитектура предприятия по модели Дж. Захмана 1992 г.
Потребности
цели
Бизнесмодель
МОТИВЫ
ЛЮДИ
МИССИЯ
ЦЕЛИ
Парт
неры
ГРА- ДАННЫЕ ФУНФИКИ
КЦИИ
Собы
тия
1. ------2. -------
СЕТЬ
1. ------2. -------
Бизнес
-план
Логическая
модель ИУС
Бизнесправила
Техническая
архитектура ИС
Условия\
действия
Детальная
реализация
TRIGGER
ALARM
read
string
Практика
использования
!
Умения
t > t1
on event
t > t1 . .
INDEX
CREATE
TABLE
BEGIN
C:>PING
BLOCK
Меню
Wait,
please

15. Перспективы и аспекты

Мотивация
Расписание
Люди
Связи
Сущности
Процессы
Перспективы и аспекты
Стратег
1
1 – организационная диаграмма
Конструктор
Сборщик
2
2 – программа на языке С++
Субподрядчик
Функционирующее
предприятие
1 – примитивный топик, 2 – композитный топик
Аспекты
Перспективы
Руководитель

16. Перспективы

• Стратег – тот, кто определяет концепцию предприятия:
среду, границы и цель
• Руководитель – тот, кто руководит производством
продуктов и/или услуг предприятия
• Бизнес-архитектор – инженер или архитектор, который
действует как промежуточное звено между тем, что
должно производить предприятие (для потребителей) и
тем, что технически и физически достижимо
• Системный архитектор – отвечает за производство
продуктов или услуг, и отвечает за компоновку и сборку
частей для получения конечного продукта или услуги
• Субподрядчик – отвечает за производство частей для
получения конечного продукта или услуги
• Функционирующее предприятие – физическая
реализация продукта или услуги

17. Аспекты

• Сущности: списки, важные элементы,
материальные композиции, базы данных.
ЧТО
• Процессы: спецификации, трансформации и
ПО. КАК
• Связи: местоположение, взаимодействия,
сети и оборудование. ГДЕ
• Люди: потоки работ, операционные
инструкции и организации. КТО
• Расписание: жизненные циклы, события,
переходы состояний, расписания. КОГДА
• Мотивация: стратегия, желаемые результаты
и способы их достижения. ЗАЧЕМ

18. Стратег (planner)

Подготовить общие требования
Спланировать мощности
Подготовить общую концепцию
Определить местоположение
Данные: определяется список важных понятий и объектов.
Функции: список основных бизнес-процессов.
Место: территориальное расположение производственных подразделений.
Люди: список ключевых бизнес подразделений организации.
Время: важнейшие события, календарный план.
Мотивация: бизнес-цели и стратегии предприятия.

19. Руководитель (owner)

• Обеспечить производство и доставку
продуктов и услуг
• Управлять затратами на производство и
доставку продуктов и услуг
• Обеспечить существование предприятия
Данные: концептуальная модель данных.
Функции: модель ключевых и вспомогательных бизнес-процессов.
Место: логистика процессов.
Люди: модель потока работ (workflow).
Время: мастер – план реализации.
Мотивация: бизнес-план.

20. Бизнес-аналитик

• Обнаружить и записать требования и
ограничения, которые вытекают из
бизнес-правил
– Бизнес-правила определяются владельцем
Данные: логические модели данных.
Функции: архитектура приложений.
Место: модель распределенной архитектуры.
Люди: архитектура интерфейса пользователя.
Время: структура процессов.
Мотивация: роли и модели бизнес-правил

21. Системный аналитик, сборщик

• Предвидеть и аккумулировать все о среде реализации и
топографии
• Определить спецификации
• Проверить, что продукт используется в ожидаемых условиях
• Соединять бизнес-аналитика и субподрядчика
• Определить ресурсы и контролировать их расход
Данные: физическая модель данных.
Функции: архитектура информационных систем.
Место: технологическая архитектура.
Люди: архитектура представления.
Время: структура управления.
Мотивация: описание правил бизнес - логики.

22. Программист

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

23. Пользователь

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

24. Основные достоинства модели Захмана

• Простота понимания
• Целостность в отношении предприятия
• Возможность применения для
планирования
• Использование нетехнических понятий
• Независимость от различных
инструментов описания отдельных
топиков

25.

26. Модель Захмана

Данные
ЧТО
Функции Размещение, сеть
КАК
ГДЕ
Оргструктура,
роли в
процессах,
внешние
стороны
Мастер-план
Бизнес-план
Модель
предприятия
Логическая
ролевая
модель
процессов
Расписания
Бизнесправила
Логическая
модель
программной
системы
Роли в
программной
систем и их
права
Циклы,
ожидания,
временные
параметры
Физическая
модель
правил
Техническая
модель
программной
системы
Интерфейсы
Авторизация,
аутентифика
ция
Программиро
вание и
настройка
циклов
Реализация
бизнеслогики
Программная
система
Способы
доступа к
программной
системе
Логин,
пароль
Время
ожидания
Территориал
ьное
размещение
организации
Топ-менеджер
Концептуаль
ная модель
данных
Концептуаль
ная модель
бизнеспроцессов
Схема
логистики
Бизнес-аналитик
Логическая
модель
данных
Логическая
модель
бизнеспроцессов
Физическая
модель
данных
Технический
проект
Архитектура
ИТ
База данных
Программны
й код,
готовые
компоненты
Разработчик,
программист
Пользователь
Ввод и вывод
данных в
нужном виде
Работающая
программная
система
Мотивация
ЗАЧЕМ
Важнейшие
события
Список
основных
бизнеспроцессов
Системный
аналитик,
проектировщик
Время
КОГДА
Ключевые
заинтересован
ные стороны:
партнеры,
клиенты
Основные
компоненты
организации
Владелец
Люди
КТО
Архитектура
предприятия
Бизнес-цели
и стратегия
Улучшение
производите
льности,
удобство
Сфера действия
Контекст
Пользователь,
работающее
предприятие

27. Основные достоинства модели Захмана

• Простота понимания
• Целостность в отношении предприятия
• Возможность применения для
планирования
• Использование нетехнических понятий
• Независимость от различных
инструментов

28. Togaf – the open group architecture framework

TOGAF – THE OPEN GROUP
ARCHITECTURE FRAMEWORK

29. Open Group

Промышленный консорциум, созданный для создания и
продвижения вендоро-независимых открытых технологических
стандартов в области ИТ.
Сформировался при объединении X/Open с Open Software
Foundation в 1996 году.
The Open Group наиболее известен как сертифицирующий орган
для торговой марки UNIX.
Автор Single UNIX Specification, расширяющей стандарты POSIX и
являющейся официальным определением UNIX.
В число более 350 членов консорциума входят покупатели и
производители из отрасли информационных технологий, а также
правительственные агентства, например, Capgemini, Fujitsu, Sun
Microsystems, Hitachi, Hewlett-Packard, IBM, NEC, US Department of
Defense, NASA и другие.
Считает своей задачей обеспечить достижение целей бизнеса с
помощью ИТ-стандартов.
Девиз - «Безграничный поток информации»

30. Стандарты Open Group

• The Open Group – некоммерческий консорциум,
созданный для того, чтобы добиться большей
эффективности бизнеса путем сведения вместе
покупателей и поставщиков информационных
систем.
• Это должно позволить снизить барьеры интеграции
новых технологий
• Эта цель реализует видение «Информация без
границ»

31. Определение предприятия Open Group

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

32. Определение архитектуры TOGAF (The Open Group Architecture Framework)

• Фундаментальная организация системы, выраженная в её
компонентах, их взаимосвязях и среде их функционирования, а
также принципах, управляющих их проектированием и развитием.
• ‘‘The fundamental organization of a system, embodied in its components,
their relationships to each other and the environment, and the principles
governing its design
• and evolution.’’
«У термина «Архитектура» может быть одно из двух значений в
зависимости от контекста применения:
Формальное описание системы или детальный план системы на
уровне компонентов для руководства воплощением системы
Структура компонентов, их взаимосвязи, а также принципы и
руководящие материалы, определяющие руководство их
конструированием и развитием во времени».

33. TOGAF – The Open Group Architecture Framework

• TOGAF – это архитектурный
фреймворк, созданный для разработки
различных ИТ-архитектур.
• Он позволяет организациям
разрабатывать, развивать и строить
правильную архитектуру
• Основой TOGAF является ADM
(Architecture Development Method) –
метод разработки ИТ-архитектуры

34. Framework

• «логическая структура», «рамочная
модель» или «каркас»
• логическая структуру для
классификации и организации
информации о сложной системе

35. Что такое логическая структура (фреймвок)

• Набор методов и средств для развития
широкого спектра различных ИТ архитектур.
• Разработан для проектирования, развития и
построения правильной архитектуры для
организации и сокращения стоимости
планирования, проектирования и внедрения
архитектур, основанных на стандартах
открытых систем.
– TOGAF Architecture Development Method (ADM)
– The TOGAF Enterprise Continuum.
– The TOGAF Resource Base
Нейтральность к конкретным инструментам

36. 4 домена TOGAF

• Business Architecture определяет стратегию бизнеса,
управление организацию и ключевые бизнес-процессы
• Data Architecture dописывает структуру организационных
логических и физических наборов данных и ресурсов
управления данными.
• Application Architecture обеспечивает концепцию инсталляции
и взаимодействия прикладных систем, а также их
взаимодействие с ключевыми бизнес-процессами организации.
• Technology Architecture описывает мощности software и
hardware, которые требуются для поддержки бизнеса, данных и
прикладных сервисов. Она включает инфраструктуру,
middleware, сети, коммуникации, способы обработки, стандарты,
и т.д.

37. TOGAF

Предварительно:
Принципы и
шаблоны
Видение
Управление
изменениями
Управление
реализацией
Бизнесархитектура
Требования
Архитектура
ИС
Технологическая
архитектура
Планирование
трансформации
Возможности и
решения

38. Уровни TOGAF

39. ADM

• ADM – итеративный процесс, состоящий из 9 фаз. На
каждой итерации должны быть выбраны следующие
решения:
–
–
–
–
Широта охвата предприятия
Уровень детализации
Временной горизонт
Архитектурные активы организации, включая:
• то, что было создано на предыдущих итерациях
• активы доступные на других предприятиях отрасли (другие
фреймворки, системные модели)
• Эти решения должны быть сделаны на основе
практического анализа ресурсов и доступных
компетенций и выгод, которые ожидаются от такого
архитектурного описания

40. ADM фазы 1-4

1.
Подготовительная фаза: подготовительная деятельность,
направленная на выявление бизнес-требований для целевой архитектуры
предприятия («как должно быть»), включая основные принципы,
адаптацию методики под особенности предприятия и выбор средств
описания архитектуры.
2.
Фаза A: Архитектурное видение -- начальная фаза цикла
разработки архитектуры. Здесь описываются рамки процесса разработки
архитектуры, определяются стейкхолдеры (заинтересованные лица),
формируется видение того, какой должна быть архитектура предприятия,
и утверждение видения и плана работ.
3.
Фаза B: Архитектура Бизнеса -- разработка бизнес-архитектуры
предприятия, основанная на согласованном на предыдущем шаге,
видении архитектуры. Описание существующей бизнес-архитектуры и
формирование целевой.
4.
Фаза C: Архитектура информационных систем -- разработка
архитектуры данных и архитектуры приложений. Описание существующих
архитектур данных и приложений и формирование целевых.

41. ADM фазы 5-9

5.
Фаза D: Технологическая Архитектура -- описание существующей
технологической архитектуры и формирование целевой.
6.
Фаза E: Проверка возможностей реализации решений, предложенных для
построения целевой архитектуры предприятия. Это база для начального
планирования реализации и выявления двигателей (стимулов) процесса
построения целевой архитектуры, определенной на предыдущих фазах,
выраженная в возможностях ее реализации и решении основных вопросов.
7.
Фаза F: Планирование перехода к целевой архитектуре -- формирование
последовательности подробных переходных архитектур и разработка плана
миграции.
8.
Фаза G: Управление построением целевой архитектуры и ее контроль –
формирование системы руководства преобразованием архитектуры предприятия
(Implementation governance), которая предполагает создание «Совета по
архитектуре» и стратегии соответствия архитектуре, которая, в свою очередь,
определяет правила оценки и проектов в части соответствия целевой архитектуре.
9.
Фаза H: Управление изменениями -- процедуры для управления
изменениями новой архитектуры.

42. TOGAF 9

• Модульная структура, которая позволяет выделить отдельные
части стандарта и внедрять их независимо, исходя из
потребностей предприятия
• Новый модуль – Структура содержания (Content Framework),
который представляет собой подробную модель результатов
архитектурного процесса
• Существенно расширился набор концепций и руководств для
поддержки интегрированной иерархии архитектурных слоев,
которые обычно развиваются внутри организации. В частности
появились понятия:
– Разбиение (Partioning): техники и средства выделения
отдельных архитектурных слоев;
– Репозиторий (Architecture Repository): логическая
информационная модель для Архитектурного Репозитория,
который может использоваться как общее хранилище всех
результатов, созданных архитектурным процессом ADM
– Структура возможностей (Capability Framework):
структурированное определение организации,
квалификации, ролей и ответственности сотрудников,
необходимых для управления эффективным предприятием.

43. TOGAF 9

• Архитектурные стили
– TOGAF и SOA
– TOGAF и безопасность
– Итеративное внедрение
• Новые стадии:
– Предварительная стадия, расширяющая
управление определением архитектурной
структуры и планированием развития архитектуры
предприятия
– Стадия планирования возможностей, решений и
миграции, в которой определяются более точно и
ясно методы для определения и планирования
трансформации предприятия на основе принципов
управления мощностями.

44. ARCHIMATE

45. ArchiMate

• язык архитектурного описания
корпоративных и инженерных систем
(моделирования архитектуры
предприятия), предназначенный для
высокоуровневого моделирования и
анализа различных областей
предприятия и взаимосвязей между
ними.

46. 3 аспекта языка

• Структурный / поведенческий
– Активный структурный элемент,
– Пассивный структурный элемент,
– Элемент поведения.
• Внешний / внутренний по отношению к
окружению (взгляд на систему);
• Индивидуальный / коллективный.

47. Активные и пассивные элементы

48. «Расщепление» активного структурного элемента

отделили поведение, которое выполняет структурный элемент, от самого
этого элемента, и превратили поведение в отдельный элемент

49. Три элемента системы: активный структурный элемент, элемент поведения и пассивный структурный элемент

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

50. Сопоставление с естественным языком

В языке ArchiMate:
существительное-подлежащее – это активный структурный элемент, то есть
субъект поведения;
глагол-сказуемое – это элемент поведения или действие, то есть
выполнение поведения;
существительное-дополнение - пассивный структурный элемент, то есть
объект, на котором или с которым выполняется поведение.

51. Отделение частей, обращенных к внешнему окружению

52. Понятие сервиса

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

53. Понятие интерфейса

• Интерфейс – это точка доступа, в
которой сервис становится доступным
внешнему окружению.

54. Элементы языка

55. Обобщенная метамодель

56. Слоеная модель АП

Бизнес
Приложения
Технологии

57. Метамодель Archimate

58. Archi – реализация нотации ArchiMate

http://www.archimatetool.com
http://ekonomika.snauka.ru/2014/11/6308 - обзор ARCHI 3

59. Что такое Archi

Archi – это свободно распространяемый межплатформенный инструмент с открытым кодом
для моделирования на всех уровнях архитектуры предприятия в терминах языка ArchiMate
Archi разработан и является зарегистрированной торговой маркой Филиппа Бовуара (Phillip
Beauvoir).
Программный продукт Archi создан на основе фреймворка Eclipse Rich Client Platform
(RCP) с использованием интегрированной среды разработки Eclipse IDE.
Текущая версия программного продукта Archi 3 выпущена 29.09.2014 и доступна для
скачивания с сайта производителя http://www.archimatetool.com
В Archi 3 встроены два демонстрационных примера моделей архитектуры предприятия.
После установки программного продукта они размещаются в папке Examples.
Основа инструмента Archi – это ArchiMate.
ArchiMate – стандарт языка моделирования архитектуры предприятия с открытым
исходным кодом, разрабатываемый консорциумом Open Group.
Язык ArchiMate поддерживается инструментальными средствами различных вендоров и
активно применяется консалтинговыми компаниями
Он полностью согласован с моделью архитектуры предприятия TOGAF, также
поддерживаемой консорциумом Open Group
ArchiMate поддерживает описание, анализ и визуализацию архитектуры предприятия.

60. Уровни Archi

• Согласно требованиям языка ArchiMate модель архитектуры
предприятия в Archi определена для трех основных уровней: уровня
бизнеса (Business layer), уровня приложения (Application layer) и
уровня технологий (Technology layer), и двух дополнительных уровнях,
называемых расширениями.
• Уровень бизнеса показывает продукты и услуги, создаваемые
участниками бизнеса в ходе бизнес-процессов и предоставляемые
внешним клиентам. Уровень бизнеса архитекторы предприятия в Archi
может быть представлен 16 элементами.
• Уровень приложения поддерживает уровень бизнеса с помощью
прикладных сервисов, которые реализуются программными
приложениями. Уровень приложения в Archi может быть представлен 7
элементами.
• Уровень технологий представляет инфраструктуру (серверы, узлы,
сети и т.д.), необходимую для работы приложений. Уровень
технологий в Archi может быть представлен 9 элементами.

61. Пример элемента «Бизнес-процесс»

Бизнес-процесс «Выписать страховку» состоит из трех подпроцессов. Каждый
подпроцесс запускает следующий по порядку подпроцесс.
Бизнес-событие «Запрос на страховку получен» запускает первый подпроцесс
«Получить запрос».
Для выполнения требуемой работы назначена бизнес-роль «Продавец страховок».
Бизнес-процесс «Выписать страховку» реализует бизнес-сервис «Сервис
оформления страховок». Бизнес-сервис предоставляется посредством 2-х
интерфейсов: по телефону и через вэб-форму.

62. Business Event

Бизнес-событие определяется как что-то, что случается (внутри или вне) и влияет
на поведение (бизнес-процесс, бизнес-функционал, бизнес-взаимодействие)

63. Пример Бизнес-сервиса

64. Пример элемента «Бизнес-интерфейс»

Пример элемента «Бизнесинтерфейс»

65. Пример Бизнес-объекта

66. Бизнес-функционал (Business function)

Бизнес-функционал определяется как элемент поведения, который
группирует поведение на основе выбранного набора критериев (обычно это
требуемые бизнес-ресурсы и/или компетенции)
Как и бизнес-процесс, бизнес-функционал описывает внутреннее поведение,
выполняемое бизнес-ролью.
Однако, если поведение бизнес-процесса основывается на последовательности
или потоке действий, необходимых для реализации продукта или услуги, то
бизнес-функционал обычно группирует поведение в соответствии с требуемыми
ресурсами, навыками, компетенциями, знаниями и т.п.

67. Пример элемента «Бизнес-функционал»

Пример элемента «Бизнесфункционал»

68.

69.

?
ВОПРОСЫ