Методы проектирования целевой архитектуры данных при формировании BPMS систем

Оглавление

 

Введение

Глава 1.     Анализ архитектуры данных в составе архитектуры предприятия

.1      Архитектура предприятия как инструмент управления изменениями

.2      Архитектура данных

.3      Модели данных

.3.1   Концептуальная модель данных

.3.2   Логические модели данных

.3.3   Физическая модель данных

.4      Процесс формирования архитектуры данных

.5      Методы проектирования архитектуры предприятия

1.5.1 TOGAF

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

.5.3   Gartner

.5.4   FEAF

.5.5   DoDAF

1.6    Анализ методик проектирования архитектуры данных

.7      Проектирование архитектуры данных по TOGAF

.8      Выводы по Главе 1

Глава 2.     Формирование методики проектирования целевой АД

.1      Интеграция BPM и архитектуры предприятия

.2      Проектирование целевой данных на основе модели BPMN

.2.1   Определение объекта управления

.2.2   Описание потоков данных

.2.3   Определение источников данных

.2.2   Интеграция данных

.2.3.  Преобразование данных

.2.4   Доступ к данным

.2.5   Синхронизация данных по времени

.3      Методика проектирования архитектуры данных для BPMS-систем с помощью TOGAF

.4      Выводы по Главе 2

Глава 3.     Реализация методики

.1      Описание процесса

.2      Описание концептуального уровня

.3      Описание логического уровня

.4      Описание физического уровня

.5      Выводы по Главе 3

Заключение

Библиографический список

Приложение А. Расчеты матриц с помощью МАИ

 

 

Введение

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

Существует несколько подходов к управлению информационными потоками, во-первых, функциональное управление, применяемое большинством компаний. В функциональном подходе используются информационные системы, основанные на аналитических моделях бизнес-процессов, например, системы, основанные на реляционных базах данных - ERP, или системы, использующие многомерные базы данных - BI. Однако такие системы являются отражением статичного предприятия, так как не учитывают изменения бизнес-процессов. Для отражения динамики предприятия компании внедряют процессный подход, который использует модели бизнес-процессов как основу для проектирования информационных систем. Процессный подход использует BPM (Business Process Management). BPM - это система управления бизнес-процессами. Процессный подход является более трудоемким для управления, так как модели BPM требуют постоянного мониторинга. Для решения данной проблемы разрабатываются системы, автоматизирующие BPM. Эти системы называются BPMS (Business Process Management System). Они позволяют снизить сложность разработки систем и неопределенность данных, так как модели бизнес-процессов являются исполняемыми в системах BPMS.

Переход к системе BPMS требует комплексного анализа всех элементов предприятия, от представления о текущем статусе предприятия до состояния «как должно быть». Одним из инструментов, позволяющих сформировать полноценное видение бизнеса и его структуру, является архитектура предприятия. Согласно документу «Federal Enterprise Architecture Framework», архитектура предприятия - это стратегическая информационная основа, определяющая [1]:

-       информацию, необходимую для ведения бизнеса;

-       структуру бизнеса;

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

-       процессы преобразования, необходимые для реализации новых технологий в ответ на изменение бизнес-потребностей.

Управление архитектурой предприятия осуществляется на основании следующих шагов: описание существующей (AS-IS) архитектуры, проектирование целевой (TO-BE) архитектуры, разработка плана перехода от существующей к целевой архитектуре. Целевая архитектура является идеальной моделью предприятия, в основе которой заложены [2]:

-       анализ тенденций рынка и среды деятельности организации;

-       стратегические требования к бизнес-процессам;

-       требования к ИТ-архитектуре;

-       информация о «узких местах» и способах их устранения.

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

В качестве объекта исследования определен процесс разработки архитектуры данных в контексте архитектуры предприятия.

Предметом исследования является методы проектирования целевой архитектуры данных при формировании BPMS систем.

Целью работы является разработка методики проектирования целевой архитектуры данных для формирования эффективной архитектуры BPMS.

Для достижения цели необходимо решить следующие основные задачи:

1.         Описать уровни и функции целевой архитектуры предприятия.

2.         Описать процесс формирования целевой архитектуры данных.

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

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

5.         Разобрать практический пример проектирования целевой архитектуры данных на основе ранее разработанной методики.

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

Структура работы.

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

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

Во второй главе описана интеграция архитектуры предприятия и BPMS систем. Сформированы основные этапы проектирования целевой архитектуры данных.

В третьей главе разобран пример формирования целевой архитектуры предприятия на основе методики, описанной в главе 2.

В заключении описаны значимые результаты исследования.

управление архитектура данные синхронизация

Глава 1.     Анализ архитектуры данных в составе архитектуры предприятия

В данной главе планируется рассмотреть следующие задачи:

)        изучить функции и структуру архитектуры предприятия;

)        проанализировать состав архитектуры данных;

)        описать процесс формирования архитектуры данных;

)        выполнить анализ методик проектирования данных.

1.1    Архитектура предприятия как инструмент управления изменениями

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

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

Одним из средств управления изменениями является архитектура предприятия, обеспечивающая следующие функции [3]:

-       анализ потенциальных изменений и их реализация;

-       создание основы для построения ИТ-организации в целом;

-       предоставление единого хранилища всех данных организации;

-       обеспечение поддержки принятия решений.

Архитектура предприятия - это динамическая система, которая описывает текущее состояние (AS IS), целевое состояние (TO BE) и план перехода от архитектуры AS IS к TO BE.

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

Целевая архитектура - желаемое будущее состояние компании, которое является идеальной моделью предприятия, в основе которой заложены: стратегические требования к бизнес-процессам и ИТ, информация о выявленных «узких местах» и путях их устранения, анализ технологических тенденций и среды бизнес-деятельности предприятия [4].

Целевая архитектура создается на основании миссии, видения и стратегии компании [4].

Миссия компании - это большая, труднодостижимая цель, которая заставляет двигаться вперед сотрудников компании.

Видение компании - это описание того, как компания будет выглядеть в будущем. Например, какая будет прибыль, с какими потребителями будет работать.

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

Реализация целевой архитектуры отражается в документе, который называется план перехода. Этот план содержит список и последовательность ИТ‐проектов, которые потребуется реализовать для достижения целевой архитектуры. Плана перехода является основой для планирования ресурсов и определения сроков проектов. План помогает оценить, возможна ли реализация целевой архитектуры. Если план не реализуем в эти сроки и с доступными ресурсами, то необходимо пересмотреть целевую архитектуру и скорректировать её.

Последовательность действий, направленная на создание архитектуры, называется архитектурным процессом. Эффективный архитектурный процесс обеспечивает [5]:

-       возможность постоянного сбора информации, описывающей текущую ситуацию на предприятии;

-       контроль соответствия стратегии развития предприятия современным тенденциям в отрасли;

-       быструю разработку и внедрение новых информационных систем.

Архитектурный процесс заключается в разработке следующих уровней архитектуры предприятия:

-       бизнес-архитектуры;

-       ИТ-архитектуры, или системной архитектурой (включающей архитектуру данных, архитектуру приложений и технологическую архитектуру).

Согласно исследованию Gartner «Magic Quadrant for Enterprise Architecture Consultancies» (от 24.06.2015), на разработку бизнес-архитектуры уходит 27% рабочего времени, а на системную архитектуру - 73%. При этом, меньше всего времени уделяется архитектуре данных - 14% [6]. Однако, в будущем эта цифра значительно увеличится из-за развития таких технологий как большие данные (Big Data) или интернет вещей (IoT), а значит, архитектура данных будет требовать более тщательной проработки.

1.2    Архитектура данных

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

-       принципы управления информацией;

-       модель обработки данных, описывающая связи между элементами модели данных и другими элементами архитектур (бизнес архитектуры и архитектуры приложений);

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

Модели обработки информации позволяют определить связь данных с бизнес-ролями или конкретными организационными структурами. Такие модели часто формируются в виде «CRUD» матриц. «CRUD» матрицы определяют уровень доступа к информации: создание (C), чтение (R), изменение (U), удаление (D).

Модели данных являются основой для реинжиниринга бизнес-процессов и разработки новых систем. Модели создаются на различных уровнях абстракции, так как представление о конкретном информационном объекте у руководства отличается от детального представления обычного сотрудника. В общем случае, для создания архитектуры данных применяется декомпозиция «сверху-вниз», где выделяются три уровня абстракции [2]:

-       концептуальный;

-       логический;

-       физический.

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

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

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

Особенности уровней абстракции при разработке архитектуры данных приведены в Таблице 1.1.

Таблица 1.1. Описание уровней данных

Критерий	Концептуальный уровень	Логический уровень	Физический уровень
Точка зрения	Бизнес-взгляд на ИТ	ИТ-взгляд на бизнес	ИТ-взгляд на ИТ
Предмет анализа	Связи информации с бизнес-функциями, интерфейсами, технологиями	Связи данных с другими данными	Связи данных с системами хранения
Цель	Описание информации	Описание структур данных	Описание объемов и частоты использования данных

 

1.3    Модели данных

Модель данных описывает структуры данных, ограничения целостности и операции управления данными. Так как модель данных является представлением предметной области, объекты модели и отношения между ними должны соответствовать реальной ситуации.

1.3.1 
Концептуальная модель данных

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

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

.        Сбор и анализ данных. Построение локальных представлений, отражающих представление отдельного пользователя.

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

При разработке концептуальной модели следует определить:

-       сущности;

-       атрибуты сущности;

-       связи между сущностями.

Обычно концептуальная модель разрабатывается в виде диаграммы сущностей - связей или ER-диаграммы (entity - relationship). На следующем этапе концептуальная модель данных преобразуется в логическую модель данных.

1.3.2  Логические модели данных

Логическая модель данных описывает связи между сущностями. Цель построения логической модели - графическое представление логической структуры исследуемой предметной области. Различают следующие типы логических моделей данных:

)        иерархическая;

)        сетевая;

)        реляционная;

)        многомерная;

)        гибридная;

)        объектно-ориентированная;

)        сервис-ориентированная.

Иерархическая модель представляет набор элементов, связанных между собой по определенным правилам. Графически иерархическая структура изображается в виде дерева [8].

Основным достоинством иерархической модели является удобство работы с иерархически упорядоченной информацией.

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

Сетевая модель, в отличие от иерархической модели, представляет структуру, в которой каждый элемент может быть связан с любым другим элементом. Графически сетевая структура изображается в виде произвольного графа [8].

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

К недостаткам сетевой модели относятся:

)        жесткость и сложность схемы базы данных, спроектированной на основе сетевой модели;

)        трудность обработки информации в базе данных пользователем.

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

К достоинствам реляционной модели относятся:

)        простота моделирования предметной области;

)        наличие математического аппарата;

)        удобство практической реализации базы данных.

К недостаткам реляционной модели относятся:

)        сложность описания иерархических и сетевых связей;

)        сложность применения в нетрадиционных областях.

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

Агрегируемость - возможность анализа данных с разными уровнями обобщения.

Историчность обеспечивает высокий уровень статичности данных и их взаимосвязей, а также привязку данных к временным точкам.

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

Основное достоинство многомерной модели - удобство и эффективность аналитической обработки больших объемов данных, связанных с временными интервалами.

Недостаток многомерной модели - громоздкость для простейших задач оперативной обработки информации.

Гибридная модель (HOLAP) сочетает в себе принципы реляционной и многомерной моделей. Главным принципом построения HOLAP является то, что детализированные данные хранятся в реляционной структуре (ROLAP), которая хранит большие объемы данных, а агрегированные данные хранятся в многомерной структуре (MOLAP).

К достоинствам гибридной модели относятся:

)        хранение данных в реляционной структуре делает их в большей степени системно независимыми;

)        устойчивые и непротиворечивые опорные точки для многомерного хранилища;

)        обеспечение передачи актуальной и корректной информации в многомерное хранилище.

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

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

Преимущества объектно-ориентированной модели:

)        реализация сложных типов данных;

)        связь с языками программирования.

Недостатки объектно-ориентированной модели:

)        высокая понятийная сложность;

)        отсутствие развитого математического аппарата.

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

1.3.3 Физическая модель данных

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

Корпоративная Информационная Система (КИС) - это масштабируемая система, предназначенная для комплексной автоматизации всех видов хозяйственной деятельности компаний. Главная задача КИС - эффективное управление всеми ресурсами предприятия (информационными, финансовыми, материальными и кадровыми) для получения максимальной прибыли и удовлетворения материальных и профессиональных потребностей сотрудников предприятия.

Типология информационной системы зависит от двух критериев: от того чьи интересы они обслуживают, и от того на каком уровне структуры корпоративного управления они функционируют. Не существует единственной универсальной системы, которая могла бы полностью обеспечивать организацию всей необходимой информацией. Как правило, информационные системы компании охарактеризованы задачами, для решения которых они создаются. Чтобы выполнить задачу/бизнес-процесс, требуется наличие определенных ресурсов. Ресурсы подразделяют на [9]:

-       информационные (данные, файлы, документы);

-       финансовые (деньги, ценные бумаги);

-       материальные (оборудование, сырье, материалы);

-       кадровые (персонал).

Существуют классы систем, которые позволяют управлять этими ресурсами.

Наиболее известный класс информационных систем - ERP (Enterprise Resource Planning) - акцентирует внимание на управлении всегда ограниченными ресурсами предприятия: трудовыми, материальными, финансовыми. ERP системы предназначены для построения единого информационного пространства предприятия и эффективного управления всеми ресурсами компании, связанными с производством, продажами и учетом заказов. Решения класса ERP обеспечивают полную функциональность для управления всей административной и операционной деятельностью компании, объединяя в единую цепочку финансовый учет, процессы сбыта, производства, управления материальными потоками, планирования и взаимодействия с поставщиками и партнерами.

Существуют системы, направленные на управление конкретной группой ресурсов (Таблица1.2).

Таблица 1.2. Системы управления ресурсами

Процесс	Система	Описание
Управление информационными ресурсами	EDM (Electronic Document Management)	Система, обеспечивающая отслеживание и хранение электронных документов и образов бумажных документов
	ECM (Enterprise Content Management)	Система управления корпоративным контентом, который предназначен для создания единого информационного пространства предприятия
	CMS (Content Management System)	Система обеспечения и организации совместного процесса создания, редактирования и управления контентом
	MDM (Master Data Managemen)t	Система согласования данных различных информационных систем и создания целостного представления о клиентах, поставщиках, партнерах, продуктах, услугах или учетных записях
Управление финансовыми ресурсами	FMS (Financial Management System)	Система управления денежными потоками организации
Управление материальными ресурсами	MES (Manufacturing Execution System)	Система отслеживания этапов производственного цикла в режиме реального времени
	EAM (Enterprise Asset Management)	Система управления процессами эксплуатации производственных фондов предприятия
	SCM (Supply Chain Management)	Система управления цепочками поставок (управление запасами)
	PLM (Product Lifecycle Management)	Система управления жизненным циклом продукта
Управление трудовыми ресурсами	CRM (Customer Relationship Management)	Система управления клиентской базой на различных этапах взаимодействия, от реализации сделок до сбора и анализа информации о покупателях
	HRM (Human Resource Management)	Система учета персонала, его поиска, оценки, обучения, мотивации

Другой класс систем, используемых на предприятии, - системы анализа и поддержки принятия решений (Таблица1.3).

Таблица 1.3. Системы анализа и поддержки принятия решений

Процесс	Система	Описание
Анализ и поддержка принятия решений	BSC (Balanced Scorecard)	Система сбалансированных показателей, позволяющая измерить эффективность компании при помощи специально подобранных сбалансированных индикаторов
	BI-приложения	Системы бизнес-анализа и генерации отчетов
	СППР	Система интеллектуальной поддержки процессов разработки и реализации управленческих решений

Отдельный класс систем - управление процессами предприятия. Системы такого класса называются BPMS (Business Performance Management System). BPMS содержат набор мощных возможностей многомерного анализа и бизнес-планирования.

Каждому классу систем соответствует определенная логическая модель данных (Рисунок 1.1).

Рисунок 1.1. Соответствие моделей системам

1.4    Процесс формирования архитектуры данных

Процесс формирования архитектуры предприятия представляет совокупность взаимосвязанным проектов, необходимых для преобразования существующей архитектуры в целевое состояние. Выделяют 3 подхода к процессу разработки архитектуры предприятия [10]:

Традиционный подход. Основывается на сборе детальной информация о состоянии предприятия (разработка текущей архитектуры), на основе которой разрабатывают план развития (разработка целевая архитектура). Данный подход требует значительных затрат времени и ресурсов для создания архитектуры предприятия.

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

Статус-кво. Суть данного подхода в том, чтобы оставить все как есть, не внедряя архитектурный процесс на предприятии.

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

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

На первом этапе строятся концептуальные модели, описывающие информационные потоки между функциональными подразделениями организации в самом общем виде.

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

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

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

 

1.5 Методы проектирования архитектуры предприятия

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

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

-       применение популярных методологий (т.е. методологий, являющихся стандартом де-факто, например, FEAF - методология, используемая при создании архитектуры Правительства);

-       применение собственной методологии;

-       применение методологии, предложенной консалтинговой фирмой.

Согласно исследованию «Analyzing the current trends in enterprise architecture frameworks», проведенному Cameron B.H. и McMillian E. в 2013 г. [12], использование вышеуказанных подходов распределилось следующим образом (Таблица 1.4).

Таблица 1.4. Выбор подхода при разработке архитектуры предприятия

Поход	Количество фирм (% от числа опрошенных)
Применение гибридного подхода	54
Применение популярных методологий	26
Применение собственной методологии	9
Применение методологии, предложенной консалтинговой фирмой	5
Другое	6

На сегодняшний день, наблюдается тенденция использования гибридного подхода. Предпочтение отдается следующим методикам [12]:

-       TOGAF (82,2%);

-       модель Захмана (52,7%);

-       Gartner (26%);

-       FEAF (21,2%);

-       DoDAF (16,4%).

1.5.1  TOGAF

Стандарт TOGAF был разработан The Open Group в 1995г., последняя версия TOGAF 9.1 вышла 2011 г. TOGAF - концепция, описывающая комплексный подход к планированию, разработке, реализации и управлению архитектурой предприятия. TOGAF используется такими крупными консалтинговыми организациями как Oracle, Accenture, SAP, IBM, HP, Capgemini и другими компаниями. При этом TOGAF находится в свободном доступе, а значит может быть использован любой организацией бесплатно.рассматривает архитектуру предприятия как континуум архитектур, то есть набор готовых моделей, от максимально обобщенных до максимально специализированных. Особенностью TOGAF является переход от общей архитектуры к специализированной.состоит из четырёх архитектурных доменов:

-       бизнес-архитектура (описывает ключевые бизнес-процессы, стратегию развития бизнеса и принципы управления);

-       архитектура уровня данных (определяет логическую и физическую структуру данных в организации);

-       архитектура уровня приложений (описывает интерфейсы приложений и способы их применения в терминах бизнес - сервисов);

-       технологическая архитектура (определяет программную, аппаратную и сетевую инфраструктуры).

Главными составными частями TOGAF являются [17]:

-       ADM-методика (Architecture Development Method), описывающая процесс разработки архитектуры;

-       руководства и методики проектирования для ADM;

-       фреймворк архитектурного описания (Architecture Content Framework), являющийся детально проработанной моделью результатов разработки;

-       архитектурный континуум организации (Enterprise Continuum), в виде репозитория архитектурных артефактов и реализаций;

-       эталонные модели TOGAF (TOGAF Reference Models);

-       фреймворк, описывающий структуру организации, её персонал, требуемые роли и уровни ответственности (Architecture Capability Framework).

Центральным элементом TOGAF является методология внедрения архитектуры (ADM), которая совмещает в себе как элементы онтологии, то есть определение основных элементов структуры и их взаимодействие, так и элементы методологии, то есть последовательность разработки, внедрения и поддержания архитектуры в актуальном состоянии. Основные шаги TOGAF включают (см. рис. 1.2) [17]:

-       Этап 0: предварительная фаза.

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

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

-       Этап С: разработка архитектуры данных и архитектуры приложений.

-       Этап D: разработка технологической архитектуры.

-       Этап Е: проверка возможности реализации предложенных решений.

-       Этап F: планирование перехода к новой системе.

-       Этап G: формирование системы управления преобразованиями.

-       Этап Н: управление изменением архитектуры.

Рисунок 1.2. Методология внедрения архитектуры (ADM)

 предлагает собственную метамодель архитектуры (см. рис. 1.3). Метамодель отражает состав элементов, а методология показывает преобразование этих элементов в процессе разработки и внедрения архитектуры. Метамодель может дополняться отдельными артефактами, позволяющими выстроить расширенную версию на основе базовой версии, которая будет отражать не только состав элементов, но и их взаимоотношения [17].

Архитектура информационных систем состоит из 2 архитектур: данных и приложений. Архитектура данных, в свою очередь, включает:

-       объекты данных;

-       логические компоненты данных;

-       физические компоненты данных.

Рисунок 1.3. Метамодель TOGAF

Процесс разработки архитектуры данных согласно стандарту TOGAF представлен в Таблице 1.5 [17].

Таблица 1.5. Процесс разработки архитектуры данных по TOGAF

№	Этап процесса разработки	Результат
1.	Выбор точек зрения, эталонных моделей, инструментов
1.1	Выбор соответствующих моделей	Модели бизнес-архитектуры, архитектуры приложений, матрицы CRUD
1.2	Описание каталогов данных	Каталог данных
1.3	Разработка матриц связи данных с функциями, приложениями	Матрицы «Данные-Функции», «Данные-Бизнес службы», «Данные-Приложения»
1.4	Разработка диаграмм	Концептуальная модель, логическая модель, модель распространения данных, модель жизненного цикла данных, модель защиты данных, модель перемещения данных
1.5	Определение требований	Требования к целевой архитектуре
2.	Описание существующей архитектуры данных	Модель существующей архитектуры (Все результаты шага 1)
3.	Разработка целевой архитектуры данных	Модель целевой архитектуры (Все результаты шага 1)
4.	Проведение GAP-анализа	Результаты GAP-анализа
5.	Выбор компонентов архитектуры данных	Архитектурная дорожная карта
6.	Анализ влияния архитектуры данных на деятельность организации	Результаты анализа
7.	Анализ модели архитектуры и ее компонентов вместе с заинтересованными лицами	Результаты анализа
8.	Завершение архитектуры данных	Итоговая архитектура данных
9.	Разработка документации	Документация, включающая концептуальную модель, логическую модель, модель обработки данных, матрицу «Данные-Функции», требования к совместимости данных (например, XML схемы, политика безопасности)

Не смотря на проработанность данной методики, TOGAF имеет и ряд следующих недостатков:

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

.        TOGAF не так детализирован, как другие методологии, особенно в сфере взаимодействия бизнеса и технологий.

1.5.2  Модель Захмана

Впервые модель Захмана была опубликована в 1987 г. Модель состояла из 3 столбцов: описание данных, описание процесса, описание сетей, и 6 строк: описание области действия, модель бизнеса, модель информационной системы, технологическая модель, детальное описание, существующая система [11].

Вторая версия модели были опубликована в 1992 г. Она содержала 6 столбцов: данные, функции, сеть, люди, время, мотивы, и 6 строк: область действия, модель предприятия, модель системы, технологическая модель, детали реализации, работающее предприятие. Официально название модель получила в 1993 г., став известной всему миру как «Модель Захмана».

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

Захман позиционирует свою концепцию как онтологию или метамодель, а не методологию. Он описывает свою модель как полный набор всех элементов, которые существуют в архитектуре предприятия. Однако модель Захмана не дает рекомендаций как спроектировать архитектуру. Сама модель представлена на Рисунке 1.4.

Рисунок 1.4. Модель Захмана

За архитектуру данных отвечает первый столбец, поэтому сосредоточим наше внимание на его элементах. В столбце приводятся модели для описания этого уровня [13]:

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

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

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

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

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

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

Подход, сформулированный Захманом, помогает решать следующие задачи:

-       концентрироваться на отдельных аспектах компании или на ее конкретной системе, но при этом не терять взгляда на нее как на единое целое;

-       использовать понятную для всех концептуальную основу;

-       обеспечивать согласование бизнеса и ИТ с помощью соответствующих друг другу ячеек;

-       сохранять независимость от программного средства с его особенностями и ограничениями.

Основными минусами использования модели Захмана являются:

-       отсутствие пошаговых инструкций по разработке архитектуры;

-       отсутствие критериев оптимальности, т.е. невозможно определить является ли создаваемая архитектура лучшей из возможных;

-       отсутствие рекомендаций, необходимо ли создавать новую архитектуру.

1.5.3 Gartner

Методология Gartner является закрытой методологий, детальное описание которой не представлено в открытых источниках. По сути, она представляет собой набор практических рекомендаций по формированию архитектуры предприятия.

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

Модель Gartner - это трехмерный куб, состоящий из следующих элементов [14]:

.        Горизонтальные слои:

-       среда бизнес-взаимодействия (описывает новую модель «виртуального» бизнеса);

-       стили бизнес-процессов (описывают, как организация выполняет свои ключевые функции);

-       шаблоны (описывают модели и алгоритмы, которые могут широко использоваться для решения различных задач на предприятии);

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

.        Вертикальные домены:

-       приложения;

-       данные;

-       интеграция;

-       доступ.

.        Вертикальные элементы технической архитектуры:

-       инфраструктура;

-       системное управление;

Методология Gartner использует следующую процессную модель (Рисунок 1.5).

Рисунок 1.5. Процессная модель Gartner

1.5.4 FEAF

FEAF (Federal Enterprise Architecture Framework) - методология описания деятельности федерального правительства и государственных организаций с функциональной точки зрения, независимо от организационных структур. Первая версия была опубликована в 1999 г., в основе которой был заложен Стратегический план деятельности CIO Council, определявший направления разработки и применения Федеральной Архитектуры для получения максимальной отдачи от использования ИТ в государстве [11]. Последняя версия 2 вышла в 2013 г.

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

Процесс разработки архитектуры FEAF состоит из следующих фаз:

Фаза 1. Анализ архитектуры: формирование простого и понятного представления сегмента с привязкой к плану организации.

Фаза 2. Архитектурное определение: задание желаемого состояния сегмента, документация целевых показателей производительности, рассмотрение альтернатив и разработка архитектуры предприятия для сегмента, в том числе архитектуры бизнеса, архитектуры данных, архитектуры служб и технологической архитектуры.

Фаза 3. Стратегия инвестиций и финансирования: рассмотрение способов финансирования проекта.

Фаза 4. План управления программой и реализация проектов: создание плана управления проектом и его реализации, включающего контрольные точки и показатели производительности для оценки успешности проекта.состоит из следующих восьми компонент (см. рис. 1.6) [15]:

)        двигатели архитектуры (бизнес-стимулы, технические стимулы);

)        стратегическое направление (цели и объекты, видение, принципы);

)        текущая архитектура (архитектура «как есть»);

)        целевая архитектура (архитектура «как должно быть»);

)        переходные процессы (переход от текущей к целевой архитектуре);

)        архитектурные сегменты (отдельные области деятельности, например, области федеральных программ, общие административные системы, электронная торговля для проведения закупок);

)        архитектурные модели (бизнес и технологические модели);

)        стандарты (стандарты, руководящие принципы, передовой опыт).

Рисунок 1.6. Модель FEAF

В методике FEAF выделяют следующие домены:

-       бизнес-архитектура;

-       архитектура данных;

-       архитектура приложений;

-       технологическая архитектура.

FEAF включает следующие эталонные модели (см. рис. 1.7) [15]:

-       исполнительная модель (Performance Reference Model, PRM);

-       бизнес модель (Business Reference Model, BRM);

-       сервисная модель Компонента (Service Component Reference Model, SRM);

-       техническая Эталонная модель (Technical Reference Model, TRM);

-       эталонная модель данных (Data Reference Model, DRM).

Рисунок 1.7. Эталонные модели FEAF

Эталонная модель данных (DRM) определяет стандартные способы описания данных (Рисунок 1.8). Данная модель будет описывать на агрегативном уровне данные и информацию, которые позволяют реализоваться функциям во всех сферах ответственности федерального Правительства.

Рисунок 1.8. Эталонная модель данных (DRM)

Процесс разработки архитектуры данных в стандарте FEAF представлен в Таблице 1.6 [15].

Таблица 1.6. Процесс разработки архитектуры данных по FEAF

№	Этап процесса разработки	Результат
1.	Описание данных
1.1.	Анализ метаданных	Высокоуровневое описание данных
1.2.	Выбор методов описания данных	Выбранные методы для описания данных (примеры и описание методов приведены в стандарте FEAF)
1.3.	Описание данных	Артефакты описания данных, например, план по управлению знаниями, план качества данных, диаграмма потоков данных, матрица CRUD.
1.4.	Разработка концептуальной модели	Семантическое описание информационных объектов (их значение)
1.5.	Разработка логической модели	Логическая модель
1.6.	Разработки физической модели	Физическая модель (структура данных)
2.	Классификация данных
2.1.	Описание пользователей данных	Список лиц, работающих с данными
2.2.	Классификация данных	Каталоги данных
2.3.	Классификация данных по способу хранения	«Четыре квадрата»
3.	Описание доступа к данным
3.1.	Разработка матрицы «поставщик-потребитель»	Матрица «поставщик-потребитель»
3.2.	Описание данных, использующихся только программами	Данные, классифицированные по способу доступа к ним
3.3.	Разработка моделей обмена информацией	Модель обмена информацией

 

1.5.5 DoDAF

Стандарт DoDAF (Department of Defense Architecture Framework) разработан министерством обороны США. Изначально DoDAF назывался архитектурным фрейморком C4ISR и был разработан в начале 90-х и. Версия C4ISR 1.0 была опубликована в 1996 г. А в 2003 г. стандарт C4ISR был переработан в стандарт DoDAF 1.0 [11]. Текущая версия DoDAF 2.0.2 была выпущена в 2010 г.- методология разработки архитектурных документов, обеспечивающая принятие наиболее важных решений по развитию информационных технологий. Другими словами, DoDAF обеспечивает наглядное представление информации, получаемой из различных моделей, в том виде, в котором она будет способствовать принятию наиболее эффективных решений.не предписывает использование какого-то определенного комплекта программных средств, но предъявляет обязательное требование поддержки эталонной модели данных и спецификации обмена данными, принятых в стандарте DoDAF.

Методология DoDAF выделяет два основных вида архитектур:

-       архитектуры уровня реализации конкретной информационной системы;

-       архитектура организации.

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

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

Точки зрения и соответствующие им архитектурные представления, принятые в DoDAF, приведены на Рисунке 1.9 [16].

Рисунок 1.9. Модель DoDAF

Точка зрения «Данные и Информация» (Data and Information Viewpoint - DIV) охватывает требования к содержанию, форме представления информации и правилам взаимного обмена.

Для всех точек зрения DoDAF предлагается набор типовых моделей, каждая из которых представляет собой шаблон для сбора конкретной информации. Будучи заполненными необходимой информацией модели, относящиеся к одной точке зрения, становятся архитектурными представлениями. DoDAF не требует обязательного использования всех возможных моделей. В каждом конкретном случае решение о составе используемых моделей должно приниматься лицом, ответвленным за разработку архитектуры. Набор моделей для представления «Данные и Информация» приведен в Таблице 1.7 [16].

Таблица 1.7. Представление «Данные и информация»

DIV-1: Концептуальная модель данных	Высокоуровневое описание данных и связей между ними.
DIV-2: Логическая модель данных	Более подробная модель данных, описывающая их структуру, взаимосвязи между ними, накладываемые ограничения. Не зависит от реализации.
DIV-3: Физическая модель данных	Детальная модель данных, зависящая от конкретной реализации.

Процесс разработки архитектуры данных в стандарте DoDAF представлен в Таблице1.8.

Таблица 1.8. Процесс разработки архитектуры данных по DoDAF

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

 

1.6 Анализ методик проектирования архитектуры данных

При выборе подходящей методики проектирования необходимо учитывать критерии отбора. В рамках работы были выделены наиболее общие критерии:

-       удобство использования методологии для проектирования архитектуры данных;

-       полнота описания метамодели архитектуры данных;

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

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

-       доступность стандарта (методология находится в открытом доступе);

-       наличие шаблонов для описания архитектуры данных (шаблоны матриц, таблиц, диаграмм);

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

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

-       описание критериев для определения эффективности целевой архитектуры данных (способы оценки корректности целевой архитектуры).

.        Полнота описания метамодели архитектуры данных:

-       наличие модели обработки информации;

-       полнота плана перехода от архитектуры «Как есть» к архитектуре «Как должно быть»;

-       полнота модели данных (разделение модели данных на три основных уровня: концептуальный, логический, физический).

.        Полнота описания процесса разработки архитектуры данных:

-       описание этапа разработки модели обработки данных;

-       описание этапа разработки архитектуры «Как должно быть»;

-       описание этапа разработки плана перехода;

-       описание этапа разработки концептуальной модели данных;

-       описание этапа разработки логической модели данных;

-       описание этапа разработки физической модели данных.

Сформированные требования к архитектуре данных были представлены в виде иерархии (см. рис. 1.10).

Рисунок 1.10. Иерархия выбора методики проектирования архитектуры данных

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

Суть метода заключается в составлении матриц парных сравнений, с помощью которых оцениваются критерии и альтернативы. Чтобы сравнить степень проявления признака в методологии, используются следующие оценки: 1 - равноценность, 3 - умеренное превосходство, 5 - сильное превосходство, 7 - очень сильное превосходство, 9 - высшее превосходство. Для определения промежуточных степеней используются также чётные числа. Веса критериев и оценки по субъективным критериям не назначаются прямым волевым методом, а рассчитываются с помощью формул, поэтому такой анализ позволяет получить достаточно обоснованные результаты.

Чтобы посчитать приоритеты критериев верхнего уровня, строится матрица 3×3. На первой шаге необходимо сравнить между собой альтернативы (строчку и столбец). На втором шаге - рассчитать среднее геометрическое для каждого критерия (среднее геометрическое по строке). Третий этап - рассчитать приоритеты, разделив значение среднего геометрического (для строки) на сумму средних геометрических всех критериев. Результаты расчетов для критериев 1 уровня представлены в Таблице 1.9. Полная матрица приведена в Приложении А (см. табл. А.1).

Таблица 1.9. Приоритеты критериев 1 уровня

Критерий	Приоритет
Удобство использования	60%
Полнота метамодели	20%
Полнота процесса разработки	20%

Для расчета приоритетов 2 уровня учитывались рассчитанные ранее приоритеты 1 уровня, т.е. сумма приоритетов 2 уровня дает значение приоритета критерия на 1 уровне. Матрицы оценки критериев 2 уровня приведены в Приложении А (см. табл. А.2, табл. А.3, табл. А4). Результаты расчета приоритетов критериев 2 уровня указаны в табл. 1.10, 1.11, 1.12.

Таблица 1.10. Приоритеты 2 уровня критерия «Удобство использования»

Критерий	Приоритет
Доступность	30%
Наличие шаблонов	15%
Рекомендации по построению моделей данных	6%
Методы формирования АД	6%
Критерии эффективности	3%

Таблица 1.11. Приоритеты 2 уровня критерия «Полнота метамодели»

КритерийПриоритет
Полнота модели обработки информации	2%
Полнота плана перехода	9%
Полнота модели данных	9%

Таблица 1.12. Приоритеты 2 уровня критерия «Полнота процесса разработки»

Критерий	Приоритет
Полнота описания разработки модели обработки данных	1%
Полнота описания разработки архитектуры TO BE	4%
Полнота описания разработки плана перехода	2%
Полнота описания разработки концептуальной модели данных	4%
Полнота описания разработки логической модели данных	4%
Полнота описания разработки физической модели данных	4%

В итоговой таблице представлены результаты сравнительного анализа основных методик проектирования архитектуры данных (Таблица 1.13.) на базе выделенных ранее критериев. Были построены 14 матриц размером 5×5. Все матрицы приведены в Приложении А (см. табл. А.13-А18), итоговая матрица в таблице А.19.

Таблица 1.13. Итоговые результаты

Методика	Приоритет
TOGAF	36%
Модель Захмана	10%
Gartner	5%
FEAF	30%
DoDAF	19%

Таким образом, метод анализа иерархий позволил определить наиболее эффективную методику проектирования целевой архитектуры данных - стандарт TOGAF. Далее возьмем TOGAF как основу для формирования собственной методологии проектирования целевой архитектуры данных.

1.7    Проектирование архитектуры данных по TOGAF

Рассмотрим более детально процесс формирования архитектуры данных в стандарте TOGAF. Согласно TOGAF, архитектура данных объединена с архитектурой приложений в одну стадию: стадию «C. Архитектура информационных систем». Процесс разработки архитектуры данных указан в части 2 «ADM», раздел 10 «Phase C: Information Systems Architectures - Data Architecture».

Цели процесса разработки архитектуры данных:

.        Разработка целевой архитектуры данных, основывающейся на бизнес-архитектуре и архитектурном видении.

.        Определение компонентов архитектурной дорожной карты, основывающейся на разрывах между существующей и целевой архитектурой.предлагает использовать для описания заданный набор артефактов (Таблица .1.14) [17]:

Таблица 1.14. Документация по описанию архитектуры данных TOGAF

Класс артефакта	Артефакты архитектуры данных
Каталог	Перечень используемых данных (Data Entity/Data Component Catalog)
Матрицы	Матрица Данные/Функции (Data Entity/Business Function Matrix)
	Матрица Приложения/Данные (Application/Data Matrix)
Основные диаграммы	Концептуальная модель данных (Conceptual Data Diagram)
	Логическая модель данных (Logical Data Diagram)
	Диаграмма передачи данных (Data Dissemination Diagram)
Дополнительные диаграммы	Диаграммы защиты данных (Data Security Diagram)
	Диаграммы перемещения данных (Data Migration Diagram)
	Диаграммы жизненного цикла данных (Data Lifecycle Diagram)

Указанные в таблице классы артефактов используются не только для описания архитектуры данные, но и для остальных архитектур:

-       Каталоги - списки строительных блоков.

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

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

Также на официальном сайте выложены некоторые шаблоны указанных выше документов [17].

.        Матрица «Данные/Функции» - таблица, отображающая связь между сущностями данных и бизнес-функциями. Матрица является соединительным слоем с бизнес-архитектурой.

.        Матрица «Приложения/Данные» - таблица, отображающая связь между приложениями и сущностями данных, которые используются этими приложениями. Данная матрица является слоем между архитектурой данных и приложений.

.        Концептуальная модель данных - модель отношений между критическими сущностями данных в рамках предприятия. Эта диаграмма отражает понятия, доступные для понимая заинтересованным сторонам. Модель имеет вид ERD-диаграммы или диаграммы классов (UML class diagrams).

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

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

.        Диаграмма защиты данных - модель доступа к данным. Доступ к информации определяется 4 категориями действий: создание (C), чтение (R), изменение (U), удаление (D). Диаграммы защиты данных может быть также представлена CRUD-матрицей. Основной акцент делается на акторе, поэтому рекомендуется строить диаграммы защиты данных отдельно для каждого актора.

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

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

2      

1.8    Выводы по Главе 1

Архитектура предприятия является одним из средств управления изменениями в организации. Архитектура предприятия состоит из 4 уровней: бизнес архитектура, архитектура данных, архитектура приложений, технологическая архитектура. Именно уровень данных отвечает за связь бизнеса и ИТ. Однако, на практике разработке архитектуры данных уделяется меньше всего времени относительно других архитектур.

Архитектура данных состоит из модели обработки данных и модели данных, которая формируется на 3 уровнях: концептуальный, логический, физический.

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

Наиболее применяемый подходом при разработке архитектуры является гибридный подход, то есть сочетание нескольких методик. Самые используемые методики, на сегодняшний день, - TOGAF, Модель Захмана, Gartner, FEAF, DoDAF. Данные методики были выбраны для дальнейшего анализа, согласно сформированным критериям. Для анализа использовался метод анализа иерархий (МАИ), позволяющий математически обосновать выбор методики. Согласно МАИ, наиболее эффективной методикой является стандарт TOGAF. Однако стандарт TOGAF не полностью удовлетворяет всем обозначенным выше критериям. Далее будут предложены рекомендации по улучшению данной методики.

Глава 2.     Формирование методики проектирования целевой АД

В данной главе планируется рассмотреть следующие задачи:

)        проанализировать взаимосвязь архитектуры данных и BPMS;

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

2.1    Интеграция BPM и архитектуры предприятия

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

Поставленной задаче наиболее соответствует структура BPM-систем. BPMS интегрирует три основы архитектуры - бизнес, данные и приложения - в единое управляемое целое. Ценность BPMS заключается в возможности определять, проектировать, внедрять, оптимизировать и влиять на сложный бизнес-процесс, включающий в себя множество участников. BPM позволяет использовать бизнес-знания для инициации, анализа и оценки ИТ-программ и проектов.

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

Однако данные, используемые приложениями, не всегда развиваются строго организованными и контролируемыми. Часто приложения представляют одни и те же данные множеством способов, в ходе чего может появляться избыточная или несогласованная информация. Для оптимизации многократного использования информации компании внедряют сервис-ориентированную архитектуру (Service-Oriented Architecture, SOA).

Согласно IBM: «Сервис-ориентированная архитектура - это ИТ-архитектура уровня предприятия, предназначенная для установления связи с ресурсами по требованию. Эти ресурсы представлены в виде ориентированных на задачи бизнеса сервисов, которые могут быть включены в пул ресурсов предприятия или направления бизнеса и модифицированы для удовлетворения соответствующих бизнес-потребностей» [18].

Идеи SOA и BPMS дополняют друг друга: реализация SOA превращает корпоративные системы в функции, доступные извне, а BPMS является потребителем этих функций, использующим их для построения бизнес-процессов.

Одна из задач внедрения и реализации SOA - идентификация сервисов и их разработка. Эти сервисы предоставляют доступ к данным с правами на «создание, чтение, обновление, удаление». Также они обеспечивают возможности обработки информации, такие как очистка, анализ и оценка данных. Сервисы могут использоваться многими потребителями как внутри организации, так и за ее пределами. В этом случае, сервисам приходится извлекать данные из широкого диапазона несопоставимых систем, каждая из которых содержит какой-либо фрагмент необходимой информации [19]. Например, большинство компаний не хранит информацию о клиентах в одном месте. Если ясно не определено, какие системы хранят самую актуальную и точную информацию, и как ее можно получить, это становится существенной проблемой. Не имея таких сведений, невозможно разработать сервис, который будет возвращать непротиворечивый набор информации о клиентах. Поэтому требуется грамотно разработанная целевая архитектура данных, которая будет описывать необходимый набор данных и принципы работы с информацией.

2.2 Проектирование целевой данных на основе модели BPMN

 

.2.1 Определение объекта управления

С чего же начинать разрабатывать архитектуру данных? Прежде чем начать разрабатывать сложные схемы, нужно обратить внимание на объект управления в исполняемой модели BPMS системы. Объект управления - это объект данных, который изменяется в ходе выполнения процесса, то есть каждая операция вносит изменения в объект. Возьмем, например, процесс формирования заявки. Один пользователь индицирует процесс, далее другие пользователи корректируют данные, заявка согласуется и утверждается.

По сути, объектом управления является результат выполнения процесса. Результат процесса всегда заранее определен, так как процесс всегда направлен на выполнение конкретной цели. Поэтому проблем с определением объекта управления процесса не возникает. Приведем пример выделения объекта управления из процесса (Таблица 2.1).

Таблица 2.1. Пример выделения объекта управления

Процесс	Объект управления
Закупка материалов	Заявка на закупку
Монтажные работы	Акт приемки-передачи
Проведение тендеров	Заявка на участие в тендере
Продажи	Заказ
Прием на работу	Трудовой договор

С определением объекта управления на исполняемой модели могут возникнуть сложности, так как на модели много объектов данных с разными наименованиями. Рассмотрим на примере процесса «Обработка заказа» (Рисунок 2.1).

На модели есть три объекта данных: Заказ, Заказ на производство, График заказов. Несмотря на то, что документ называется по-разному, это один и тот же объект, но меняющий свой статус. Объктом управления является заказ на проихводство.

Рисунок 2.1. Обработка заказа

Так как объект управления можно определить однозначно, он будет основой для формирования потоков данных.

Хотелось бы отметить, что на модели объект управления отображается как цельный объект, однако он состоит из набора атрибутов (полей). Это будет следующим шагом в построении архитектуры. Требуется определить атрибуты объектов и то, откуда приходят данные для их заполнения. Рассмотрим на примере заказа на производство (Рисунок 2.2).

Рисунок 2.2. Атрибуты объекта

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

Вернемся к примеру с заказом на производство. Разберем все объекты данных на составляющие. Для удобства проведения анализа на модели можно оставить только объекты данных и операции (Рисунок 2.3).

Рисунок 2.3. Выделение атрибутов

Важно обратить внимание на объекты, которые выпадают из цепочки процесса. Например, если бы была такая ситуация (Рисунок 2.4).

Рисунок 2.4. Выпадающие объекты

Здесь необходимо ответить на следующие вопросы:

.        Нужен ли этот объект для процесса?

.        Если он нужен, то должен ли он передаваться дальше по процессу или он должен сохраниться в хранилище?

Таким образом, выделение атрибутов позволит понять не только как связанные данные с операциями, но и определить источники их хранения.

2.2.2 Описание потоков данных

Далее выясним, как данные связаны между собой. В нотации BPMN данные могут быть представлены любым из следующих элементов:

.        Объект данных:

-       входные данные;

-       выходные данные.

.        Набор данных.

.        Сообщение.

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

Входные данные - исходные товарно-материальные ценности или информация для выполнения действий.

Выходные данные - результат выполнения действий.

Набор данных - коллекция или массив однотипных данных: множества, списки, массивы.

Сообщение используется для отображения взаимодействия между двумя участниками бизнес-процессов. Сообщения используются в межпроцессном взаимодействии.

Для описания потоков данных стандарт TOGAF предлагает применять диаграмму перемещения данных (Data Migration Diagram). Данная диаграмма может отражать как общую картину перемещения данных, так и максимально детализированную информацию, например, отражать перемещения не только сущностей, но и отдельных атрибутов. Нотация диаграммы перемещения данных приведена в Таблице 2.2.

Таблица 2.2. Нотация диаграммы перемещения данных

Графическое представление	Тип объекта	Описание
	Сущность	Конкретный или абстрактный объект в рассматриваемой предметной области
	Сущность (детализированная до атрибутов)	Конкретный или абстрактный объект, в рассматриваемой предметной области, детализированный до атрибутов
	Перемещение	Перемещение данных между сущностями

Пример диаграммы представлен на Рисунке 2.5.

Рисунок 2.5. Диаграмма перемещения данных

Учитывая, что на модели BPMN данные могут быть представлены 3 способами, внесем доработки в нотацию TOGAF (Таблица 2.3).

Таблица 2.3. Нотация диаграммы перемещения данных

Графическое представление	Тип объекта	Описание
	Объект данных	Товарно-материальные ценности или информация
	Набор данных	Коллекция или массив однотипных данных
	Сообщение	Информация, передаваемая между участниками 2 процессов
	Объект / Набор данных (детализированный до атрибутов)	Конкретный объект, в рассматриваемой предметной области, детализированный до атрибутов
	Перемещение	Перемещение данных между сущностями

Эту диаграмму можно считать логическим уровнем архитектуры данных.

2.2.3 Определение источников данных

После установления связей между данными, можно перейти к описанию источников хранения этих данных. Источник данных - это хранилище набора данных, необходимых для выполнения задачи. По отношению к системе BPMS, выделяют внешние и внутренние источники данных. Внешние источники данных включают:

.        Корпоративное хранилище данных.

.        Учетные системы.

.        Аналитические системы.

.        Системы ERP.

.        Web-источники.

.        Файлы.

.        Бумажные документы.

К внутренним источникам данных относятся:

.        База данных системы.

.        Внутренние переменные.

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

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

Описание источников позволяет не только определить, где хранятся данные, но в дальнейшем провести анализ, насколько целесообразен такой способ хранения.

Вначале определим все источники. Для более удобного визуального восприятия, эту информацию можно представить в виде матрицы «Приложения/Данные» (Таблица 2.4).

Таблица 2.4. Матрица Приложения/Данные

	Система 1	…	Система N
Задача 1	+
Задача 2	+	+
…
Задача N				+

2.2.4 Интеграция данных

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

Интеграция данных включает объединение данных, находящихся в различных источниках и предоставление данных пользователям в унифицированном виде. Роль интеграции данных возрастает, когда увеличивается объём и необходимость совместного использования данных.

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

Проблема интеграции данных чрезвычайно многоаспектна и многообразна. Сложность и характер используемых методов ее решения существенным образом зависят от уровня интеграции, который необходимо обеспечить, свойств отдельных источников данных и всего множества источников в целом, требуемых способов интеграции. Системы интеграции данных могут обеспечивать интеграцию данных на физическом, логическом и семантическом уровне [20]. Интеграция данных на физическом уровне с теоретической точки зрения является наиболее простой задачей и сводится к конверсии данных из различных источников в требуемый единый формат их физического представления. Интеграция данных на логическом уровне предусматривает возможность доступа к данным, содержащимся в различных источниках, в терминах единой глобальной схемы, которая описывает их совместное представление с учетом структурных и, возможно, поведенческих свойств данных. Поддержку единого представления данных с учетом их семантических свойств в контексте единой онтологии предметной области обеспечивает интеграция данных на семантическом уровне [21].

Для отображения интеграции данных между системами, сервисами, приложениями TOGAF предлагает использовать диаграмму передачи данных (Data Dissemination Diagram). Цель диаграммы передачи данных - показать связь между сущностями данных, бизнес-службами и компонентами приложений. Диаграмма отображает, как логические сущности физически реализованы программными компонентами, что в дальнейшем позволит измерить необходимый размер памяти приложений и рассчитать их мощность. Нотация диаграммы передачи данных приведена в Таблице 2.5.

Таблица 2.5. Нотация диаграммы передачи данных

Графическое представление	Тип объекта	Описание
	Сущность	Конкретный или абстрактный объект в рассматриваемой предметной области
	Компонент сущности	Компонент приложения, обеспечивающий доступ к сущностям и сохраняющий их целостность
	Компонент взаимодействия	Компонент приложения, отвечающий за обеспечение графического интерфейса пользователя, например, веб-интерфейс
	База данных	Хранилище

Пример диаграммы передачи данных представлен на Рисунке 2.6.

Рисунок 2.6. Диаграмма передачи данных

2.2.5 Преобразование данных

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

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

По степени структурированности выделяют следующие формы представления данных [22]:

-       неструктурированные (данные, произвольные по форме, включающие тексты и графику, мультимедиа (видео, речь, аудио);

-       структурированные (базы данных, списки, графы, структуры);

-       слабоструктурированные (публикации, RDF, XML).

Все структурированные данные делятся на пять типов:

-       целый (количество товара, код товара и т. п.);

-       вещественный (цена, скидка и т. п.);

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

-       логический;

-       дата/время.

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

Можно выделить несколько источников для входных преобразований:

.        Неэлектронный документ. В этом случае происходит распознавание в том или ином виде: распознавание текста отсканированных бумажных документов, распознавание речи, введенной с микрофона и т.д.

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

.        Структурированный документ. Здесь необходимо преобразование данных из одного формата в другой, например, из DBF в XML.

2.2.6 Доступ к данным

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

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

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

Таким образом, на данном этапе требуется определить, во-первых, какие операции будут выполняться над данным, во-вторых, необходимо распределить права между пользователями.

TOGAF использует диаграммы защиты данных для описания доступа к данным. Цель диаграммы защиты данных - отобразить, какой актор может иметь доступ к данным. Доступ к информации определяется 4 категориями действий: создание (C), чтение (R), изменение (U), удаление (D). Основной акцент делается на акторе, поэтому рекомендуется строить диаграммы защиты данных отдельно для каждого актора.

Диаграмма защиты данных может быть также представлена CRUD-матрицей. Нотация диаграммы защиты данных указана в Таблице 2.6.

Таблица 2.6. Нотация диаграммы защиты данных

Графическое представление	Тип объекта	Описание
	Сущность	Конкретный или абстрактный объект в рассматриваемой предметной области
	Внешний актор	Актор, не принадлежащий организационной структуре организации
	Внутренний актор	Актор, принадлежащий организационной структуре организации
	Поток данных	Доступ и права на данные сущности

Пример диаграммы защиты данных приведен на Рисунке 2.7.

Рисунок 2.7. Диаграмма защиты данных

2.2.7 Синхронизация данных по времени

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

Синхронизация на модели визуально отображается с помощью шлюзов и событий.

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

-       эксклюзивные условия и объединения. Могут быть исключающими и основываться на событиях. Данный тип Шлюзов может отображаться как с маркером «X», так и без него;

-       шлюзы, основанные на событиях, и параллельные шлюзы, основанные на событиях, инициируют появление нового экземпляра процесса;

-       шлюзы, включающие условия и объединения;

-       комплексные шлюзы, представляющие собой сложные условия и ситуации;

-       параллельные шлюзы, представляющие собой раздвоение и слияние.

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

-       стартовое событие указывает на то, в какой точке берет начало тот или иной процесс;

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

-       конечное событие указывает на то, в какой точке завершится тот или иной процесс.

Помочь в анализе синхронизации может матрица зависимости «Данные/Функции» (Таблица 2.7).

Таблица 2.7. Матрица Данные/Функции

	Задача 1	Задача 2	…	Задача N
Задача 1	Набор данных	-		Набор данных
Задача 2	-	Набор данных		-
…
Задача N	Набор данных	-		Набор данных

2.3    Методика проектирования архитектуры данных для BPMS-систем с помощью TOGAF

Соберем все этапы проектирования целевой архитектуры данных. Как было ранее определено, архитектура имеет три уровня: концептуальный, логический и физический.

.        Этап формирования концептуального уровня:

.1.     Определение объекта управления.

-       Что является результатом выполнения процесса?

-       Как связаны данные с операциями?

-       Из каких составляющих состоит объект управления?

.2.     Описание потоков данных.

-       Как связаны данные между собой?

.        Этап формирования логического уровня:

.1.     Определение источников данных.

-       Какие используются источники данных?

-       Как связаны данные с источниками?

.2.     Интеграция данных.

-       Как передаются данные между системами, приложениями, сервисами?

.        Этап формирования физического уровня:

.1.     Преобразование данных.

-       Какие трансформации данных требуются при переносе их из одного источника в другой?

.2.     Доступ к данным.

-       Какие операции выполняются над данными?

-       Кто выполняет операции над данными?

.3.     Синхронизация данных по времени.

-       Где должна быть задержка выполнения операции?

Инструменты описания, применяемые для проектирования архитектуры, представлены в Таблице 2.8.

Таблица 2.8. Набор артефактов АД

Этап	Инструмент описания
Концептуальный уровень
Определение объекта управления	Модель BPMN
Описание потоков данных	Диаграмма перемещения данных
Логический уровень
Определение источников данных	Матрица Приложения/Данные
Интеграция данных	Диаграмма передачи данных
Физический уровень
Преобразование данных	Табличное описание
Доступ к данным	Диаграмма защиты данных
Синхронизация данных по времени	Матрица Данные/Функции

 

2.4    Выводы по Главе 2

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

Данная методика определяет семь этапов проектирования целевой архитектуры данных, включающих следующие шаги:

)        определение объекта управления;

)        описание потоков данных;

)        определение источников данных;

)        интеграция данных;

)        преобразование данных;

)        доступ к данным;

)        синхронизация данных по времени.

Для всех этапов приведены инструменты проектирования, среди которых диаграммы и матрицы. В качестве основы для формирования этапов использовался стандарт TOGAF. Например, матрица «Приложения/Данные» для определения источников данных и матрица «Данные/Функции» для описания синхронизации данных по времени. Из диаграмм использовались:

-       диаграмма передачи данных для описания потоков данных;

-       диаграмма защиты данных для описания доступа к данным.

Некоторые элементы были доработаны с учетом специфики модели BPMS. Так нотация диаграммы перемещения данных была расширена за счет объектов нотации BPMN.

Глава 3.     Реализация методики

 

.1 Описание процесса

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

Описание процесса «Как должно быть» приведено в таблице ниже (Таблица ).

Таблица 3.1. Описание процесса

Функция	Входы функции (документы/ данные)	Выходы функции документы /данные	Исполнитель	ИС, участвующая при выполнении
Формирование заявки	Набор документов	Заявка	Студент	ЛМС
Проверка заявки	Заявка		Стипендиальная комиссия структурного подразделения	ЛМС
Оценка заявки	Заявка	Список претендентов	Стипендиальная комиссия структурного подразделения
Формирование общеуниверситетского рейтинга студентов	Список претендентов	Список претендентов	ЦСиБП
Рассмотрение	Список претендентов		Общеуниверситетская комиссия
Утверждение	Список претендентов	Список победителей	Общеуниверситетская комиссия
Подготовка проекта приказа	Список победителей	Приказ (проект)	ЦСиБП	СЭД
Подписание приказа	Приказ (проект)	Приказ	Ректор

Модель процесса сформирована в нотации BPMN и представлена на Рисунке 3.1.

Приступим к формированию целевой архитектуры данных. Для этого нужно описать 3 уровня архитектуры: концептуальный, логический и физический. Для описания будет применяться методика, сформированная в Главе 2.

Рисунок 3.1. Назначение повышенной государственной стипендии

3.1.  

3.2    Описание концептуального уровня

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

Далее проследим, как передаются данные между операциями (Рисунок 3.2).

Рисунок 3.2. Поток данных

На модели видно, что объекты данных не передаются между следующими операциями:

-       «Проверка заявки» и «Оценка заявки»;

-       «Рассмотрение» и «Утверждение».

Проверка заявка заявки - автоматическая функция, поэтому объект на входе этой функции передается дальше на вход следующей функции.

Рассмотрение и утверждение - функции, по факту, дублируют друг друга, поэтому оставим только функцию «Утверждение» (Рисунок 3.3). Так мы получим непрерывный поток данных.

Рисунок 3.3. Поток данных

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

Таблица 3.2. Описание атрибутов объекта управления

Атрибут	Описание
№	Номер по порядку
ФИО	Фамилия Имя Отчество
Курс	1/2/3/4
Степень	Специалитет/ Бакалавриат/ Магистратура
Факультет	Факультет, на котором обучается студент
Филиал	Москва/ Пермь/ Санкт-Петербург/ Нижний Новгород
Область	Область, в которой будет назначена стипендия
Количество баллов	Количество набранных баллов
Уровень стипендии	1/2/3/4

А также разберем, из каких составляющих состоит заявка и приказ (Таблица 3.3 и Таблица 3.4).

Таблица 3.3. Описание атрибутов заявки

Атрибут	Описание
ФИО	Фамилия Имя Отчество
Курс	1/2/3/4
Степень	Специалитет/ Бакалавриат/ Магистратура
Факультет	Факультет, на котором обучается студент
Филиал	Москва/ Пермь/ Санкт-Петербург/ Нижний Новгород
Область	Область, в которой будет назначена стипендия
Файл	Набор файлов, прикрепленных студентом

Таблица 3.4. Описание атрибутов заявки

АтрибутОписание
ФИО	Фамилия Имя Отчество
Курс	1/2/3/4
Степень	Специалитет/ Бакалавриат/ Магистратура
Факультет	Факультет, на котором обучается студент
Филиал	Москва/ Пермь/ Санкт-Петербург/ Нижний Новгород
Область	Область, в которой будет назначена стипендия
Файл	Набор файлов, прикрепленных студентом
Период выплаты стипендии	Период выплаты стипендии
Месячный размер стипендии	Размер стипендии в месяц, руб.
Общий размер стипендии	Общая сумма выплат, руб.

Перейдем к описанию потоков данных (Рисунок 3.4).

Рисунок 3.4. Перемещение данных

3.3    Описание логического уровня

Далее перейдем к описанию интеграции данных с внешними источниками данных. Согласно модели список внешних источников включает:

-       систему LMS;

-       СЭД.

А также базу данных по заявкам. Составим матрицу Приложения/Данные (Таблица 3.5).

Таблица 3.5. Матрица Приложения/Данные

Задачи	ЛМС	СЭД	БД
Формирование заявки	+
Проверка заявки
Оценка заявки
Формирование общеуниверситетского рейтинга студентов			+
Утверждение
Подготовка проекта приказа		+
Подписание приказа

В ЛМС происходит формирование заявки, далее эта заявка поступает в систему BPMS. Все заявки попадают в базу данных, из которой формируется общеуниверситетский рейтинг. В СЭД выполняется формирование приказа и его согласование.

Представим перемещение данных между системами с помощью модели передачи данных (Рисунок 3.5).

Рисунок 3.5. Передача данных

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

3.4    Описание физического уровня

Рассмотрим, как происходят преобразования объектов данных. Обратимся к диаграмме перемещения данных (Рисунок 3.4). На модели видно, что данные полностью передаются из одного объекта в другой, не требуя преобразования форматов. Особое внимание обратим на пункт «Файлы». Файлы здесь представляют собой набор разноформатных документов (это могут быть файлы формата docx, pdf, png, jpeg). Однако эти файлы оцениваются вручную пользователем, после чего дальше они не фигурируют.

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

Рисунок 3.6. Диаграмма защиты данных

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

Создадим матрицу Данные/Функции, где на пересечении функций (операций), проставим данные, через которые они связаны (Таблица 3.6).

Таблица 3.6. Матрица Данные/Функции

	1	2	3	4	5	6	7
1.Формирование заявки	-	заявка	-	-	-	-	-
2.Проверка заявки	заявка	-	заявка	-	-	-	-
3.Оценка заявки	-	заявка	-	список претендентов	-	-	-
4.Формирование общеуниверситетского рейтинга студентов	-	-	список претендентов	список претендентов	-	-
5.Утверждение	-	-	-	список претендентов	-	список победителей	-
6.Подготовка проекта приказа	-	-	-	-	список победителей	-	приказ
7.Подписание приказа	-	-	-	-	-	приказ	-

 

3.5    Выводы по Главе 3

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

На основе методики, описанной в главе 2, сформирована целевая архитектура данных. Архитектура данных формировалась по 3 уровням: концептуальный, логический, физический.

На концептуальном уровне определен основной объект управления, описаны потоки данных между процессами, перемещение атрибутов между данных.

На логическом уровне описаны источники данных, а также интеграция данных между источниками и основной системой.

Физический уровень описывает доступ к данным и способы синхронизации данных по времени.

Таким образом, создано 5 таблиц, включая 2 матрицы, и 5 рисунков, включая диаграммы.

 

Заключение

В главе 1 был проанализирован понятийный аппарат архитектуры данных, описана структура архитектуры, включающая в себя 3 уровня: концептуальный, логический, физический. Выполнен анализ моделей данных, применяемых на каждом уровне архитектуры данных. Данный анализ показал, что модели BPMS-систем не имеют четкой логической структуры. Учитывая данную проблему были сформированы критерии для проектирования архитектуры данных. Для анализа было выбрано 5 стандартов: TOGAF, модель Захмана, Gartner, FEAF, DoDAF, так как они являются наиболее востребованными на рынке. Был проведен сравнительный анализ выбранных методик с применением метода анализа иерархий. Анализ выполнялся по 14 сформированным критериям. Таким образом, было сформировано 19 матриц парных сравнений, которые показали, что наиболее полно требованиям удовлетворяет методология TOGAF. Однако стандарт TOGAF не полностью удовлетворяет всем обозначенным выше критериям. В частности, он не дает четкой последовательности шагов процесса проектирования, а также не определяет, для какого уровня модели формируются артефакты архитектуры данных.

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

В главе 3 в качестве примера был выбран процесс «Назначение повышенной стипендии». Были выполнены основные шаги проектирования архитектуры данных, для описания применялась методика, сформированная в Главе 2. На концептуальном уровне определен основной объект управления, описаны потоки данных между процессами, перемещение атрибутов между данных.

На логическом уровне описаны источники данных, а также интеграция данных между источниками и основной системой.

Физический уровень описывает доступ к данным и способы синхронизации данных по времени.

Таким образом, разработаны артефакты архитектуры, а именно, создано 5 таблиц и 5 диаграмм.

Результаты работы представлены в следующих публикациях [23, 24]:

-       Вотинцева В. О., Сахипова М. С. Выбор эффективной методики проектирования архитектуры данных в рамках архитектуры предприятия // В кн.: Технологии разработки информационных систем - ТРИС-2016: материалы VII Международной научно-технической конференции. Том 2 Т. 2. Таганрог: Издательство ЮФУ, 2016. С. 32-36.

-       Вотинцева В. О., Сахипова М. С., Дерябин А. И. Применение метода анализа иерархий для выбора методик проектирования системной архитектуры предприятия // В кн.: Математика и междисциплинарные исследования - 2016. Пермь: Пермский государственный национальный исследовательский университет, 2016. С. 201-207.

 

Библиографический список

1.      Лекция 1: Тенденции развития информационных технологий. Архитектурный подход как основа управления развитием информационных систем [Электронный ресурс] // Национальный открытый университет «ИНТУИТ» - Режим доступа: <http://www.intuit.ru/studies/courses/532/388/lecture/9001?page=4&keyword_content=architecture> [Проверено: 19.05.2017].

.        Олейник А. И. ИТ-инфраструктура: учеб.-метод. пособие / А. В. Сизов. Нац.-исслед. ун-т «Высшая школа экономики». - М.: Изд. дом Высшей школы экономики, 2012. - 134 с.

.        Лекция 10: Процесс разработки архитектур: цели и задачи, общая схема. Архитектура предприятия [Электронный ресурс] // Национальный открытый университет «ИНТУИТ» - Режим доступа: <http://www.intuit.ru/studies/courses/995/152/lecture/4240> [Проверено: 19.05.2017].

.        Коротков А. Архитектура Предприятия. Как заставить ИТ работать на вашу компанию / А. Коротков. - 2013. - 96 с.

.        Коптелов А. Принципы управления архитектурой предприятия [Электронный ресурс] / А. Коптелов // Проблемы теории и практики управления. - 2010. - №1. - Режим доступа: <http://bpm.ucoz.ru/publ/upravlenie_arkhitekturoj_predprijatija/principy_upravlenija_arkhitekturoj_predprijatija/30-1-0-31> [Проверено: 19.05.2017].

6.      Brand S. (2015, June) Magic Quadrant for Enterprise Architecture Consultancies.

7.      Зиндер Е.З. Архитектура предприятия в контексте бизнес-реинжиниринга [Электронный ресурс] / Е.З. Зиндер // Intelligent Enterprise. - 2008. - №4. - Режим доступа: <http://www.iemag.ru/master-class/detail.php?ID=15745.html> [Проверено: 19.05.2017].

.        Лекция 1: Информационные системы с базами данных. Основы проектирования реляционных баз данных [Электронный ресурс] // Национальный открытый университет «ИНТУИТ» - Режим доступа: <http://www.intuit.ru/studies/courses/1095/191/lecture/4967?page=4> [Проверено: 19.05.2017].

.        Лекция 5: Первая стадия концептуального проектирования базы данных (концептуальное моделирование). Академия Microsoft: Базы данных [Электронный ресурс] // Национальный открытый университет «ИНТУИТ» - Режим доступа:<http://www.intuit.ru/studies/courses/508/364/lecture/8647?page=2> [Проверено: 19.05.2017].

.        Башкатова Ю.И. Виды информационных систем и технологий в системе наращения качества управленческих решений и конкурентоспособности организаций // Экономика и современный менеджмент: теория и практика: сб. ст. по матер. XXXVI междунар. науч.-практ. конф. № 4(36). Часть II. - Новосибирск: СибАК, 2014.

11.    Schekkerman J. How to Survive in the Jungle of Enterprise Architecture Framework: Creating or Choosing an Enterprise Architecture Framework. Trafford, 2006. p. 224.

.        Cameron B.H., McMillian E. (2013, February). Analyzing the current trends in enterprise architecture frameworks. Journal of Enterprise Architecture [Электронный ресурс]. Режим доступа: <http://ea.ist.psu.edu/documents/journal_feb2013_cameron_2.pdf> [Проверено: 19.05.2017].

.        Zachman J.P. (2009, April). The Zachman Framework Evolution [Электронный ресурс] Режим доступа: https://www.cob.unt.edu/itds/faculty/becker/BCIS5520/Readings/The%20Zachman%20Framework%E2%84%A2%20Evolution.pdf [Проверено: 19.05.2017].

14.    Bittler R.S., Kreizman G. (2005, October). Gartner Enterprise Architecture Process: Evolution. Gartner [Электронный ресурс] Режим доступа: <http://www.idi.ntnu.no/emner/tdt4175/pdfs/GartnerEA.pdf> [Проверено: 19.05.2017].

15.    Federal Enterprise Architecture Framework, Version 2 (2013). [Электронный ресурс] Режим доступа: <https://www.whitehouse.gov/sites/default/files/omb/assets/egov_docs/fea_v2.pdf> [Проверено: 19.05.2017].

16.    The DoDAF Architecture Framework, Version 2 (2011, February). [Электронный ресурс] Режим доступа: <http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_v2-02_web.pdf> [Проверено: 19.05.2017].

17.    TOGAF, Version 9.1 (2011) [Электронный ресурс] Режим доступа: <http://pubs.opengroup.org/architecture/togaf9-doc/arch/> [Проверено: 19.05.2017].

.        Калянов Г.Н. Построение архитектуры предприятия [Электронный ресурс] / Г.Н. Калянов // Корпоративные системы. - 2005. - №3. - Режим доступа: <http://cde.osu.ru/demoversion/course158/glava1_2.html> [Проверено: 19.05.2017].

.        Амсден Д. Моделирование SOA: Часть 2. Спецификация сервиса [Электронный ресурс] / Д. Амсден // IBM developerWorks Россия - 2008. - Режим доступа: <https://www.ibm.com/developerworks/ru/library/1009_amsden/> [Проверено: 19.05.2017].

.        Зауфер Г. Шаблоны для информационного сервиса: Часть 1. Шаблоны интеграции данных [Электронный ресурс] / М. Сельваж, Э. Лейн, Б. Мэтьюс // IBM developerWorks Россия - 2007. - Режим доступа: <https://www.ibm.com/developerworks/ru/library/ws-soa-infoserv1/> [Проверено: 19.05.2017].

.        Зауфер Г. Шаблоны информационных сервисов: Часть 2. Шаблон консолидации данных [Электронный ресурс] / Б. Мэтьюс, М. Сельваж, Э. Остик // IBM developerWorks Россия - 2008. - Режим доступа: <https://www.ibm.com/developerworks/ru/library/ws-soa-infoserv2/> [Проверено: 19.05.2017].

.        Энгельс В. Методы работы с моделью мастер-данных в SOA-проектах [Электронный ресурс] / В. Энгельс // Interface.ru - 2009. - Режим доступа: <http://www.interface.ru/home.asp?artId=21057> [Проверено: 19.05.2017].

.        Вотинцева В. О. Выбор эффективной методики проектирования архитектуры данных в рамках архитектуры предприятия/ М. С. Сахипова // В кн.: Технологии разработки информационных систем - ТРИС-2016: материалы VII Международной научно-технической конференции. Том 2 Т. 2. Таганрог: Издательство ЮФУ, 2016. С. 32-36.

.        Вотинцева В. О., Сахипова М. С., Дерябин А. И. Применение метода анализа иерархий для выбора методик проектирования системной архитектуры предприятия // В кн.: Математика и междисциплинарные исследования - 2016. Пермь: Пермский государственный национальный исследовательский университет, 2016. С. 201-207.

 

Приложение А. Расчеты матриц с помощью МАИ

Таблица А.1. Сравнение критериев 1 уровня

	Удобство использования	Полнота метамодели	Полнота процесса разработки	Ср.геом	Приоритеты	Сумма
Удобство использования	1	3	3	2,08	60%	1 2/3
Полнота метамодели	1/3	1	1	0,69	20%	5
Полнота процесса разработки	1/3	1	1	0,69	20%	5
			ИТОГО	3,47	100%

Таблица А.2. Сравнение критериев 2 уровня «Удобство использования»

	Доступность	Наличие шаблонов	Рекомендации по построению моделей данных	Методы формирования АД	Критерии эффективности	Ср.геом	Локальные Приоритеты	Сумма	Глобальные приоритеты
Доступность	1	3	5	5	7	3,50	50%	1 7/8	30%
Наличие шаблонов	1/3	1	3	3	5	1,72	25%	4 6/7	15%
Рекомендации по построению моделей данных	1/5	1/3	1	1	3	0,72	10%	10 1/3	6%
Методы формирования АД	1/5	1/3	1	1	3	0,72	10%	10 1/3	6%
Критерии эффективности	1/7	0,2	1/3	1/3	1	0,32	5%	19	3%
				ИТОГО		6,98	100%		60%

Таблица А.3. Сравнение критериев 2 уровня «Полнота метамодели»

	Полнота модели обработки информации	Полнота плана перехода	Полнота модели данных	Ср.геом	Локальные Приоритеты	Сумма	Глобальные приоритеты
Полнота модели обработки информации	1	1/5	1/5	0,34	9%	11	2%
Полнота плана перехода	5	1	1	1,71	45%	2 1/5	9%
Полнота модели данных	5	1	1	1,71	45%	2 1/5	9%
		ИТОГО		3,76	100%		20%

Таблица А.4. Сравнение критериев 2 уровня «Полнота процесса разработки»

	Полнота описания разработки модели обработки данных	Полнота описания разработки архитектуры TO BE	Полнота описания разработки плана перехода	Полнота описания разработки концептуальной модели данных	Полнота описания разработки логической модели данных	Полнота описания разработки физической модели данных	Ср.геом	Локальные Приоритеты	Сумма	Глобальные приоритеты
Полнота описания разработки модели обработки данных	1	1/3	1/3	1/5	1/5	1/3	0,34	5%	20	1%
Полнота описания разработки архитектуры TO BE	3	1	5	1	1	1	1,57	22%	4 1/2	4%
Полнота описания разработки плана перехода	3	1/5	1	1/3	1/3	1/3	0,53	8%	15 1/3	2%
Полнота описания разработки концептуальной модели данных	5	1	3	1	1	1	1,57	22%	4 1/2	4%
Полнота описания разработки логической модели данных	5	1	3	1	1	1	1,57	22%	4 1/2	4%
Полнота описания разработки физической модели данных	3	1	3	1	1	1	1,44	21%	4 2/3	4%
					ИТОГО		7,02	100%		20%

Таблица А.5. Сравнение альтернатив по критерию «Доступность»

	TOGAF	Модель Захмана	Gartner	FEAF	DoDAF	Ср.геом	Локальные Приоритеты	Сумма	Глобальные приоритеты
TOGAF	1	1	9	1	1	1,55	24%	4 1/9	7%
Модель Захмана	1	1	9	1	1	1,55	24%	4 1/9	7%
Gartner	1/9	1/9	1	1/9	1/9	0,17	3%	37	1%
FEAF	1	1	9	1	1	1,55	24%	4 1/9	7%
DoDAF	1	1	9	1	1	1,55	24%	4 1/9	7%
				ИТОГО		6,38	100%		30%

Таблица А.6. Сравнение альтернатив по критерию «Наличие шаблонов»

	TOGAF	Модель Захмана	Gartner	FEAF	DoDAF	Ср.геом	Локальные Приоритеты	Глобальные приоритеты
TOGAF	1	9	9	5	5	4,58	55%	1 5/8	8%
Модель Захмана	1/9	1	1	1/7	1/7	0,30	4%	25	1%
Gartner	1/9	1	1	1/7	1/7	0,30	4%	25	1%
FEAF	1/5	7	7	1	1	1,58	19%	7 2/7	3%
DoDAF	1/5	7	7	1	1	1,58	19%	7 2/7	3%
				ИТОГО		8,33	100%		15%

Таблица А.7. Сравнение альтернатив по критерию «Рекомендации по построению моделей данных»

	TOGAF	Модель Захмана	Gartner	FEAF	DoDAF	Ср.геом	Локальные Приоритеты	Сумма	Глобальные приоритеты
TOGAF	1	5	5	3	3	2,95	44%	2	3%
Модель Захмана	1/5	1	1	1/5	1/3	0,42	6%	15	0%
Gartner	1/5	1	1	1/5	1/3	0,42	6%	15	0%
FEAF	1/3	5	5	1	3	1,90	28%	4 3/4	2%
DoDAF	1/3	3	3	1/3	1	1,00	15%	7 2/3	1%
				ИТОГО		6,70	100%		6%

Таблица А.8. Сравнение альтернатив по критерию «Методы формирования АД»

	TOGAF	Модель Захмана	Gartner	FEAF	DoDAF	Ср.геом	Локальные Приоритеты	Сумма	Глобальные приоритеты
TOGAF	1	5	5	1/5	3	1,72	21%	6 3/4	1%
Модель Захмана	1/5	1	1	1/9	1/7	0,32	4%	23	0%
Gartner	1/5	1	1	1/9	1/7	0,32	4%	23	0%
FEAF	5	9	9	1	5	4,58	56%	1 5/8	3%
DoDAF	1/3	7	7	1/5	1	1,27	15%	9 2/7	1%
				ИТОГО		8,20	100%		6%

Таблица А.9. Сравнение альтернатив по критерию «Критерии эффективности»

	TOGAF	Модель Захмана	Gartner	FEAF	DoDAF	Ср.геом	Локальные Приоритеты	Сумма	Глобальные приоритеты
TOGAF	1	1	1	1/9	1	0,64	8%	13	0%
Модель Захмана	1	1	1	1/9	1	0,64	8%	13	0%
Gartner	1	1	1	1/9	1	0,64	8%	13	0%
FEAF	9	9	9	1	9	5,80	69%	1 4/9	2%
DoDAF	1	1	1	1/9	1	0,64	8%	13	0%
				ИТОГО		8,38	100%		3%

Таблица А.10. Сравнение альтернатив по критерию «Полнота модели обработки информации»

	TOGAF	Модель Захмана	Gartner	FEAF	DoDAF	Ср.геом	Локальные Приоритеты	Сумма	Глобальные приоритеты
TOGAF	1	9	7	1	1	2,29	31%	3 1/4	1%
Модель Захмана	1/9	1	1/6	1/9	1/9	0,19	2%	34	0%
Gartner	1/7	6	1	1/7	1/7	0,45	6%	22 1/6	0%
FEAF	1	9	7	1	1	2,29	31%	3 1/4	1%
DoDAF	1	9	7	1	1	2,29	31%	3 1/4	1%
				ИТОГО		7,50	100%		2%

Таблица А.11. Сравнение альтернатив по критерию «Полнота плана перехода»

	TOGAF	Модель Захмана	Gartner	FEAF	DoDAF	Ср.геом	Локальные Приоритеты	Сумма	Глобальные приоритеты
TOGAF	1	9	7	1	9	3,55	42%	2 3/8	4%
Модель Захмана	1/9	1	1/3	1/9	1	0,33	4%	23	0%
Gartner	1/7	3	1	1/7	3	0,71	8%	15 2/3
FEAF	1	9	7	1	9	3,55	42%	2 3/8	4%
DoDAF	1/9	1	1/3	1/9	1	0,33	4%	23	0%
				ИТОГО		8,49	100%		9%

Таблица А.12. Сравнение альтернатив по критерию «Полнота модели данных»

	TOGAF	Модель Захмана	Gartner	FEAF	DoDAF	Ср.геом	Локальные Приоритеты	Сумма	Глобальные приоритеты
TOGAF	1	7	9	3	5	3,94	50%	1 4/5	5%
Модель Захмана	1/7	1	1/3	1/7	1/5	0,27	3%	23	0%
Gartner	1/9	3	1	1/7	1/5	0,39	5%	22 1/3	0%
FEAF	1/3	7	7	1	3	2,18	28%	4 5/8	3%
DoDAF	1/5	5	5	1/3	1	1,11	14%	9 2/5	1%
				ИТОГО		7,88	100%		9%

Таблица А.13. Сравнение альтернатив по критерию «Полнота описания разработки модели обработки данных»

	TOGAF	Модель Захмана	Gartner	FEAF	DoDAF	Ср.геом	Локальные Приоритеты	Сумма	Глобальные приоритеты
TOGAF	1	7	7	1	7	3,21	41%	2 3/7	0%
Модель Захмана	1/7	1	1	1/7	1	0,46	6%	17	0%
Gartner	1/7	1	1	1/7	1	0,46	6%	17	0%
FEAF	1	7	7	1	7	3,21	41%	2 3/7	0%
DoDAF	1/7	1	1	1/7	1	0,46	6%	17	0%
				ИТОГО		7,81	100%		1%

Таблица А.14. Сравнение альтернатив по критерию «Полнота описания разработки архитектуры TO BE»

	TOGAF	Модель Захмана	Gartner	FEAF	DoDAF	Ср.геом	Локальные Приоритеты	Сумма	Глобальные приоритеты
TOGAF	1	9	9	5	5	4,58	57%	1 5/8	3%
Модель Захмана	1/9	1	1	1/5	1/5	0,34	4%	21	0%
Gartner	1/9	1	1	1/5	1/5	0,34	4%	21	0%
FEAF	1/5	5	5	1	1	1,38	17%	7 2/5	1%
DoDAF	1/5	5	5	1	1	1,38	17%	7 2/5	1%
				ИТОГО		8,02	100%		4%

Таблица А.15. Сравнение альтернатив по критерию «Полнота описания разработки плана перехода»

	TOGAF	Модель Захмана	Gartner	FEAF	DoDAF	Ср.геом	Локальные Приоритеты	Сумма	Глобальные приоритеты
TOGAF	1	9	9	3	9	4,66	54%	1 2/3	1%
Модель Захмана	1/9	1	1	1/7	1	0,44	5%	19	0%
Gartner	1/9	1	1	1/7	1	0,44	5%	19	0%
FEAF	1/3	7	7	1	7	2,58	30%	4 3/7	0%
DoDAF	1/9	1	1	1/7	1	0,44	5%	19	0%
				ИТОГО		8,55	100%		2%

Таблица А.16. Сравнение альтернатив по критерию «Полнота описания разработки концептуальной модели данных»

	TOGAF	Модель Захмана	Gartner	FEAF	DoDAF	Ср.геом	Локальные Приоритеты	Сумма	Глобальные приоритеты
TOGAF	1	9	5	1	1	2,14	30%	3 1/3	1%
Модель Захмана	1/9	1	1/7	1/9	1/9	0,18	3%	35	0%
Gartner	1/5	7	1	1/5	1/5	0,56	8%	16 1/7	0%
FEAF	1	9	5	1	1	2,14	30%	3 1/3	1%
DoDAF	1	9	5	1	1	2,14	30%	3 1/3	1%
				ИТОГО		7,17	100%		4%

Таблица А.17. Сравнение альтернатив по критерию «Полнота описания разработки логической модели данных»

	TOGAF	Модель Захмана	Gartner	FEAF	DoDAF	Локальные Приоритеты	Сумма	Глобальные приоритеты
TOGAF	1	9	5	1	1	2,14	30%	3 1/3	1%
Модель Захмана	1/9	1	1/7	1/9	1/9	0,18	3%	35	0%
Gartner	1/5	7	1	1/5	1/5	0,56	8%	16 1/7	0%
FEAF	1	9	5	1	1	2,14	30%	3 1/3	1%
DoDAF	1	9	5	1	1	2,14	30%	3 1/3	1%
				ИТОГО		7,17	100%		4%

Таблица А.18. Сравнение альтернатив по критерию «Полнота описания разработки физической модели данных»

	TOGAF	Модель Захмана	Gartner	FEAF	DoDAF	Ср.геом	Локальные Приоритеты	Сумма	Глобальные приоритеты
TOGAF	1	9	5	1	1	2,14	30%	3 1/3	1%
Модель Захмана	1/9	1	1/7	1/9	1/9	0,18	3%	35	0%
Gartner	1/5	7	1	1/5	1/5	0,56	8%	16 1/7	0%
FEAF	1	9	5	1	1	2,14	30%	3 1/3	1%
DoDAF	1	9	5	1	1	2,14	30%	3 1/3	1%
				ИТОГО		7,17	100%		4%

Таблица А.19. Итоговая таблица

	Приоритет критерия	TOGAF	Модель Захмана	Gartner	FEAF	DoDAF
Доступность	0,3	0,24	0,24	0,03	0,24	0,24
Наличие шаблонов	0,15	0,55	0,04	0,04	0,19	0,19
Рекомендации по построению моделей данных	0,06	0,44	0,06	0,06	0,28	0,15
Методы формирования АД	0,06	0,21	0,04	0,04	0,56	0,15
Критерии эффективности	0,03	0,08	0,08	0,08	0,69	0,08
Полнота модели обработки информации	0,02	0,31	0,02	0,06	0,31	0,31
Полнота плана перехода	0,09	0,42	0,04	0,08	0,42	0,04
Полнота модели данных	0,09	0,5	0,03	0,05	0,28	0,14
Полнота описания разработки модели обработки данных	0,01	0,41	0,06	0,06	0,41	0,06
Полнота описания разработки архитектуры TO BE	0,04	0,57	0,04	0,04	0,17	0,17
Полнота описания разработки плана перехода	0,02	0,54	0,05	0,05	0,3	0,05
Полнота описания разработки концептуальной модели данных	0,04	0,3	0,03	0,08	0,3	0,3
Полнота описания разработки логической модели данных	0,04	0,3	0,03	0,08	0,3	0,3
Полнота описания разработки физической модели данных	0,04	0,3	0,03	0,08	0,3	0,3
ИТОГО		36%	10%	5%	30%	19%