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

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

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

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

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