Размещено на http://www.allbest.ru/

Оглавление

Введение

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

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

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

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

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

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

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

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

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

1.5.1 TOGAF

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

1.5.3 Gartner

1.5.4 FEAF

1.5.5 DoDAF

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 Описание процесса

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

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

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

3.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) изучить функции и структуру архитектуры предприятия;

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

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

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

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 Концептуальная модель данных

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

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

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

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

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

- сущности;

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

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

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

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

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

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

2) сетевая;

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

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

5) гибридная;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сервис-ориентированная модель является частью сервис-ориентированной архитектуры (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 является переход от общей архитектуры к специализированной.

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)



TOGAF предлагает собственную метамодель архитектуры (см. рис. 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 имеет и ряд следующих недостатков:

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.5.3 Gartner

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

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

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

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

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

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

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

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

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

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

- данные;

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

- доступ.

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

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

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

- безопасность.

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

FEAF состоит из следующих восьми компонент (см. рис. 1.6) [15]:

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

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

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

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

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

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

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

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



Рисунок 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.

Методология 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. Удобство использования методологии для проектирования целевой архитектуры данных:

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

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

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

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

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

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

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

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

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

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

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

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

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