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

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. Представление «Данные и информация»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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