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

На сегодняшний день, наблюдается тенденция использования гибридного подхода. Предпочтение отдается следующим методикам [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

Не смотря на проработанность данной методики, 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