О систематизации задач
структурного анализа архитектуры КИС
В.П. Разбегин,
с.н.с., Valent@ipu.rssi.ru,
А.В. Габалин,
н.с. , Gabalina@bk.ru,
ИПУ РАН, г. Москва
Введение
Работа посвящена систематизации задач структурного
анализа архитектурных моделей предприятий, состоящего в идентификации и анализе
взаимосвязей ее составляющих.
Цель структурного анализа – дать возможность аналитику выявлять и
«препарировать» информацию о структуре взаимосвязей между архитектурными
составляющими предприятия для выявления возможностей улучшения его организационной структуры и
деятельности.
Его сущность заключается в возможности прослеживании структурной
зависимости между элементами архитектуры в масштабах предприятия как по операционной цепочке продукт-операция-ресурсы, так и по целевой структуре: от целей верхнего
уровня до терминальных элементов KPI.
В настоящее время известны различные виды задач
структурного анализа бинарных, тернарных и других взаимоотношений элементов как
внутри архитектурных доменов, так и между доменами, например, задачи
Парето-анализа, агрегационно/дезагрегационного
анализа, анализа рынка, анализа соотношений мощностей участвующих множеств
и прикладного смысла
их решений, позволяющие строить разнообразные схемы прослеживания
структурных зависимостей между архитектурными ,
элементами. Классификация таких задач, определение роли и места в архитектурном
процессе, формализация постановок,
разработка методик их применения,
представляются актуальными
вопросами для исследования.
Основой архитектурного метода является
архитектурное моделирование, обеспечивающее в идеале заинтересованным лицам
предприятия возможности эффективно планировать, разрабатывать, документировать
и согласовывать вопросы информационных технологий и хозяйственной деятельности
предприятия в режиме поддержки принятия решений. И эта поддержка не должна сводиться только к непосредственной
демонстрации графовой структуры взаимосвязей
элементов ИТ-архитектуры и бизнес-архитектуры, а должна выявлять «скрытые» связи, позволяющие судить,
например, о том, какие ИТ-компоненты необходимо
изменять или удалять. Другое необходимое свойство этой поддержки связано с
иерархическим агрегированием информации о схожих свойствах подмножеств
архитектурных элементов, позволяющим компактным образом представлять структуру сложной системы.
1. Современная структура архитектурного
метода на примере методологии Archimate
Рассмотрим основные понятия архитектуры предприятия
с точки зрения задач структурного анализа в процессах подготовки и принятия
архитектурных решений. За основу понятийного аппарата возьмем нотацию
графического языка ArchiMate 2.0.
В описании архитектуры предприятия на этом языке
выделяют 3 части: ядро (Core), расширение мотивации (Motivation Extension) и
расширение миграции (Migration Extension).
В архитектурных
моделях используется двенадцать базовых типов связей, близких по смыслу и
обозначению к используемым в UML: ассоциация, доступ, реализация,
специализация, присваивание, агрегация, композиция, группировка, переключение
(переход), поток, соединение.
1.1. Общая
структура метода
Общая номенклатура участников архитектурного
процесса, видов, уровней обобщения и
назначения их действий, иллюстрируемых примерами, приведена в таблице
1[1].
Выполняемые действия из трех категорий, включая проектирование,
принятие решений и информирование, по
уровням обобщения разбиваются на 1) подробные, т.е. наиболее детальные (внутрикомпонентные, выражаемые в терминах диаграмм классов
UML и событийных диаграмм процессов BPMN);
2) связные, т.е. на уровне архитектурных компонент связанных
отношениями использования, реализации и назначения; 3) обзорные, т.е.на уровне максимальной общности.
В наибольшей степени задачи структурного анализа
востребованы в процессах подготовки и принятия архитектурных
решений из категории принятия решений.
Таблица 1
Классы
заинтересованных лиц, виды выполняемых действий, их назначение и уровень
обобщения
|
|
Заинтересованные лица |
Цели, виды действий |
Примеры |
Назначение |
Проектирование |
Архитектор, разработчик ИС, разработчик бизнес-процессов |
Навигация,поддержка проектных решений, сравнение проектных
альтернатив |
UML-, BPMN-, ER- диаграммы, блок-схемы |
Принятие
решений |
Менеджер, CIO, CEO |
Разработка решений |
Перекрестные
таблицы, ландшафтные карты, списка, отчеты |
|
Информирование |
Персонал, клиенты, другие |
Объяснять,
убеждать, получать подтверждение |
Анимации,
презентации, демонстрации процессов, диаграммы |
|
Уровень обобщения |
Подробный |
Разработчик ПО, владелец
процесса |
Проектирование,
управление |
Диаграмма классов UML, Диаграмма процессов BPMN |
Связный |
Менеджер операций |
Анализ
зависимостей, влияния изменений |
Диаграммы со
связями типа «use», «realize», «assign» |
|
Обзорный |
Архитектор предприятия, CIO,
CEO |
Управление
изменениями |
Ландшафтные карты |
1.2. Структура
архитектурного ядра
Архитектурное ядро
описывает состояния статических структур предприятия в терминах уровней и
аспектов. Определены три уровня описания ядра архитектуры: бизнес, приложения и
технологии.
На каждом уровне описание
ядра разделяется на три аспекта (домена):
· Пассивная структура (Passive structure) из объектов
обработки процессами и функциями.
· Деятельность (Behavior) из процессов, функций, событий и сервисов.
· Активная структура (Active structure) из субъектов
деятельности (исполнители, роли, приложения, оборудование).
Ядро моделирует объект
архитектурного анализа и преобразования. В рассматриваемой методологии
архитектурная модель предприятия рассматривается с разных точек зрения,
соответствующих предметным областям заинтересованных лиц предприятия.
В табл.2 представлен
фрагмент описания стандартного набора из
восемнадцати точек зрения. Здесь также. как и в предыдущей таблице просматриваются различные уровни
общности в представлении предметных областей.
Таблица 2
Фрагмент описания точек зрения архитектурного ядра
№ |
Точка зрения |
Описание |
1 |
Introductory |
Объяснение сути архитектурной модели для не архитекторов |
2 |
Organization |
Определение оргструктуры компании, отдела,
сети, компаний или другой организационной единицы |
3 |
Actor Co-operation |
Моделирование отношений исполнителей друг с другом и их окружением, и
описание того, как несколько взаимодействующих бизнес-
исполнителей и/или компонентов приложений вместе реализуют бизнес-процесс |
4 |
Business Function |
Моделирование главных бизнес-функций организации и структуры потоков информации, ценностей или продуктов
между ними, протекающих по их взаимосвязям |
5 |
Business Process |
Моделирование главных бизнес-процессов организации и потоков
управления, информации, ценностей или продуктов между ними |
6 |
Business Process Co-operation |
Исследование отношений
одного или более бизнес- процессов друг с другом и/или с их окружением |
7 |
Product |
Анализ ценности, которую продукты предлагают потребителям, и анализ
построения одного или более продуктов с точки зрения составляющих сервисов
(бизнес- или
приложений) и связанных с ними контрактов или других соглашений |
1.3. Структура
расширений архитектурного ядра
Расширение мотивации
включает элементы: требования, цели, ограничения, оценки, заинтересованные лица
и дополнительный тип связей – связи влияния, что позволяет моделировать целевые
структуры.
Расширение миграции
содержит средства описания диаграмм анализа разрывов между исходным и целевым
состоянием архитектурного ядра и средства описания миграции – перехода от
исходного и целевому состоянию архитектурного ядра.
Содержание обоих расширений
иллюстрирует описание точек зрения, представленное в табл.3.
Таблица 3
Описание точек зрения расширений архитектурного ядра
№ |
Точка зрения |
Тип |
Описание назначения
точки зрения и ЗЛ |
1 |
Stakeholder (ЗЛ) |
Motivation Extension |
Позволяет аналитику
моделировать ЗЛ, внутренние и внешние драйверы изменений, и оценки (в
терминах сил, слабостей, возможностей и угроз) этих драйверов |
2 |
Goal Realization |
Motivation Extension |
Позволяет
проектировщику моделировать детализацию (высокоуровневых) целей в более
конкретные цели, и детализацию этих конкретных целей в требования или
ограничения, которые требуются для описания свойств, необходимых для
реализации этих целей |
3 |
Goal Contribution |
Motivation Extension |
Позволяет
проектировщику или аналитику моделировать связи взаимовлияния между целями и
требованиями |
4 |
Principles |
Motivation Extension |
Позволяет
проектировщику или аналитику моделировать принципы, подходящие для текущих
проблем разработки, включающих цели, инициирующие эти принципы |
5 |
Requirements Realization |
Motivation Extension |
Позволяет проектировщику моделировать реализацию
требований элементами ядра (архитектуры) типа business actors, business services, business processes, application services, application components,
и т.д. |
6 |
Motivation |
Motivation Extension |
Позволяет
проектировщику или аналитику моделировать аспекты мотивации без концентрации
на конкретных элементах внутри аспекта |
7 |
Project |
Implementation & Migration Extension |
Используется для
моделирования управления архитектурными изменениями |
8 |
Migration |
Implementation & Migration Extension |
Содержит модели и
концепты, описывающие переход от существующей к
желаемой архитектуре |
9 |
Implementation & Migration |
Implementation & Migration Extension |
Используется для
сопоставления программ и проектов частям архитектуры, которые ими реализуются
|
2. Оценка уровня
аналитической поддержки принятия решений современными архитектурными системами
Основой архитектурного
метода является архитектурное моделирование, обеспечивающее в идеале
заинтересованным лицам предприятия возможности эффективно планировать,
разрабатывать, документировать и согласовывать вопросы информационных
технологий и хозяйственной деятельности предприятия в режиме поддержки принятия
решений. И эта поддержка не должна сводиться только к непосредственной
демонстрации графовой структуры взаимосвязей
элементов ИТ-архитектуры и бизнес-архитектуры, а должна выявлять «скрытые» связи, позволяющие судить,
например, о том, какие ИТ-компоненты необходимо
изменять или удалять. Другое необходимое свойство этой поддержки связано с
иерархическим агрегированием информации о схожих свойствах подмножеств
архитектурных элементов, позволяющим компактным образом представлять структуру сложной системы.
Для предприятий, интенсивно
использующих информационные технологии все более актуальна задача управления сложным
комплексом взаимосвязанных архитектурных компонент. Сейчас в этом направлении
исследуются различные подходы.
Например, в работе [2]
описываются методы визуализации и измерения статуса архитектуры с
использованием средств абстрагирования и агрегирования на базе формирования и
анализа матриц смежности графа взаимосвязей архитектурных
элементов. Подход включает эмпирический метод глобальной структуризации
архитектурного пространства.
Другой пример
демонстрируется в работах, связанных с управлением портфелем приложений в
методологии Аrchimate [3],
где подход также включает свой метод глобальной структуризации архитектурного
пространства.
Третий пример приведен в
работе [4]. Он также включает визуализацию и измерения и
свой эмпирический метод глобальной
структуризации архитектурного пространства, основанный на предлагаемой
трактовке операций итерации и декомпозиции вместо традиционных рекурсии и
детализации.
Общий характер современных
работ характеризуется поиском критериев и метрик анализа архитектур, подходов к
глобальной структуризации архитектурных моделей, позволяющих более эффективно
бороться со сложностью архитектурных объектов.
Заключение
Современные исследования в
области архитектурного анализа
характеризуется поисковыми работами
в части критериев и метрик анализа архитектур, подходов к глобальной
структуризации архитектурных моделей, позволяющих более эффективно бороться со
сложностью архитектурных объектов.
Классификация аналитических
задач, в особенности задач структурного анализа, определение роли и места в
архитектурном процессе, формализация постановок, разработка методик их применения, являются
актуальными вопросами для исследования.
Литература
1. ArchiMate2.0 Specification, Open Group Standard, 2011.
2. Lagerstrom,
Robert, Carliss Baldwin, Alan MacCormack,
and David Dreifus. “Visualizing and Measuring
Enterprise Architecture: An Exploratory BioPharma
Case” Harward Business School Working Paper, No.
13-105, June 2013.
3. Marc Lakhorst, Dick A.C. Quartel,
Maarten W.A. Steen . Architecture-Based IT Portfolio
Valuation/ Practice-Driven Research on Enterprise Transformation Volume 69 of the series Lecture Notes in Business Information Processing pp
78-106.
4. Роджер Сешнс. Оптимальный
путь к корпоративным архитектурам. Открытые системы, No.4, 2006.