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

Оглавление

Введение

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

1.1 Функциональный и процессный подходы

1.2 Анализ понятия архитектура предприятия. Определение границ системной архитектуры

1.3 Структура BPMS-системы

1.4 Существующие методики и языки построения арихитектуры BPMS

1.5 Анализ существующих методик и обоснование выбора наиболее удобной методики проектирования архитектуры приложений и ИТ-инфраструктуры

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

2.1 Основные концепции языка ArchiMate

2.2 Бизнес-архитектура

2.2.1 Активные элементы бизнес-архитектуры

2.2.2 Поведенческие концепции бизнес-архитектуры

2.2.3 Пассивные элементы бизнес-архитектуры

2.2.4 Краткое описание элементов бизнес-уровня

2.3 Архитектура приложений

2.3.1 Активные элементы архитектуры приложений

2.3.2 Поведенческие концепции архитектуры приложений

2.3.3 Пассивные элементы архитектуры приложений

2.3.4 Краткое описание элементов уровня приложений

2.4 Технологическая архитектура

2.4.1 Элементы активной структуры

2.4.2 Поведенческие концепции технологической архитектуры

2.4.3 Элементы пассивной структуры

2.4.4 Краткое описание элементов уровня технологий

2.5 Взаимосвязи между различными архитектурными слоями

2.6 Отношения

2.6.1 Структурные отношения

2.6.2 Динамические отношения

2.6.3 Другие отношения

2.6.4 Краткое описание отношений

2.7 Расширение. Мотивация

2.7.1 Мотивационные концепции

2.7.2 Краткое описание мотивационных концепций

2.8 Расширение миграция

2.8.1 Концепции расширения миграции

2.8.2 Обзор реализации и миграции Концепции

2.9 Инструменты реализации языка ArchiMate в программном средстве Archi

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

3.1 Описание алгоритма

Заключение



Введение

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

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

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

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

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

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

• Объект: автоматизация управления бизнес-процессами.

• Предмет: методика проектирования архитектуры приложений с использованием языка ArchiMate.

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

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

Задачи работы:

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

• рассмотреть архитектуру BPMS (компоненты и связи), сервис - ориентированную архитектуру и архитектуру, управляемую моделями. Определить место в архитектуре предприятия;

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

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

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

• выбрать наиболее подходящую методику для проектирования архитектуры приложений и технологической архитектуры:

• рассмотреть и описать синтаксис языка ArchiMate;

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

• описать алгоритм построения архитектурной модели на языке ArchiMate в программном средстве Archi для BPMS-системы;

• исследовать методы верификации модели.

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

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

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

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

Во второй главе представлено описание синтаксиса языка ArchiMate, описаны инструменты реализации языка ArchiMate в программном средстве Archi Описаны несколько примеров.

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

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

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



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

1.1 Функциональный и процессный подходы

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

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

Далее подробнее рассмотрим концепции как функционального подхода к управлению, так и процессного.

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

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

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

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

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

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

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

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

1.2 Анализ понятия архитектура предприятия. Определение границ системной архитектуры

На данный момент информационные технологии являются базой в управлении любым предприятием. С их помощью можно повысить эффективность каждого бизнеса, их использование позволяет автоматизировать многие сложные операции и бизнес-процессы организации, сократить время, затрачиваемое на них и снизить стоимость [22]. Но новые возможности часто вызывают новые трудности, многие из которых и связаны со сложностью разработки единой системы управления разнородной архитектурой предприятия. Часто подобные проблемы вызываются двумя аспектами: на предприятии существуют несколько информационных систем, созданных и внедренных разными компаниями, а также жизненный цикл вырабатываемого продукта и внешние изменения рынка требуют адаптации структуры предприятия к новым условиям в короткие сроки [7]. Эффективным инструментом, помогающим в решении проблем с адаптацией бизнеса к новым условиям рынка и осуществляющим организационные изменения в компаниях различных областей с использованием ИТ, и стала архитектура предприятия. Единая архитектура предприятия позволяет корректировать бизнес-процессы компании без потери времени, так, чтобы все изменения незамедлительно отражались в работе управляющей системы [6].

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

Самое простое из множества определений термина «архитектура предприятия» (АП) можно получить, применяя термин «архитектура» к системе «предприятие»: «Архитектура предприятия?-- это способ понимания всех различных элементов, из которых состоит предприятие, и того, как эти элементы взаимосвязаны. Элементы включают в себя людей, процессы, бизнес и технологии» [18].

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

Согласно стандарту ISO 15704 «архитектура предприятия должна включать роль людей, описание процессов (функции и поведение) и представление всех вспомогательных технологий на протяжении всего жизненного цикла предприятия» [21].

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

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

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

* технологии и программные средства, применяемые для поддержания и реализации бизнес-процессов компании;

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

Наиболее часто архитектуру предприятия изображают в виде нескольких слоев. Верхний слой - бизнесы-процессы организации, следующий слой - сервисы, данные/информация, прикладные системы, инфраструктура и связь [26]. Достаточно часто выделяют три следующих слоя: миссия и стратегия организации, бизнес-архитектура (которая разделяется на ресурсы, бизнес-процессы и корпоративные стандарты) и ИТ-архитектура (которая состоит из программных систем, данных и инфраструктуры) [15].

В американской федеральной модели FEA выделяются пять моделей-уровней: справочная модель оценки результативности (Performance Reference Model, PRM), справочная модель бизнеса (Business Reference Model, BRM), справочная модель сервисных компонентов (Service Component Reference Model, SRM), справочная модель данных (Data Reference Model, DRM), техническая справочная модель (Technical Reference Model, TRM)[27,28,31]. Однако довольно быстро определилось, что связь между слоями не иерархическая и строение архитектуры должно быть усложнено. Так появились: матрица Захмана, пирамида CIO Council, параллелограмм GERAM (Generalized Enterprise Reference Architecture and Methodology) и девятицветник TOGAF (The Open Group Architecture Framework).

На рисунке 1.1 представлена структура архитектуры предприятия.

Как видно из рисунка, архитектура предприятия чаще всего включает в себя следующие компоненты:

· миссия и стратегия организации;

· ее цели и задачи;

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

· системная архитектура [15,16].

Далее немного подробнее рассмотрим каждый компонент архитектуры.

Корпоративные миссия и стратегия описывают основные направления будущего развития предприятия и ставят цели и задачи на долгосрочный период.

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

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

Архитектура приложений включает в себя:

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

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

• средства и методы разработки и сопровождения приложений[5].

Архитектура данных включает:

· базы данных и хранилища данных;

· различные системы управления базами данных или хранилищами данных;

· правила и средства доступа к данным [10].

Техническая архитектура состоит из сетевой архитектуры и архитектуры платформ. Сетевая архитектура состоит из [5]:

* локальных и территориальных вычислительных сетей;

* коммуникационных протоколов, различных сервисов и системы адресации;

* аварийныех планов по обеспечению бесперебойной работы сетей в условиях чрезвычайных обстоятельств.

Архитектура платформ включает:

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

* операционные и управляющие системы, утилиты и офисные программные системы;

* аварийные планы по обеспечению бесперебойной работы аппаратуры (главным образом - серверов) и баз данных в условиях чрезвычайных обстоятельств [15,16].

1.3 Структура BPMS-системы

Организации, которые хотят получить наибольшую выгоду от процессного подхода, применяют специальные технические средства управления бизнес-процессом, называемые системами для управления бизнес-процессами (Business Process Management Systems). Этот термин обозначает информационную технологию, обеспечивающую генерацию исполняемой модели процесса непосредственно из графической модели бизнес-процесса. Системы управления бизнес-процессами относятся к классу процессно-ориентрированных систем [19].

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

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

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

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

Составные части BPMS-системы:

• Веб-сервис (внешний).

• Портал организации.

• Бизнес-сервера.

• Персонал (ресурсы).

• Модели бизнес-процессов.

• Редактор описания модели бизнес-процессов (редактор веб-страниц).

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

Дадим определение исполнимого бизнес-процесса, основу которого составляют идеи С. Яблонского и С. Бусcлера. Исполнимый бизнес-процесс определяется при помощи задания следующих перспектив:

• перспектива управления потоком (схема бизнес-процесса);

• перспектива ресурсов (исполнители, стоимость работ, длительность…);

• перспектива данных (внутренние переменные бизнес-процесса);

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

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

Рассмотрим более подробно уровни определения исполнимого бизнес-процесса.

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

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

Перспективе ресурсов бизнес-процесса соответствует набор исполнителей, которые могут выполнять его узлы-действия. Исполнителями могут быть как сотрудники предприятия, так и информационные системы или специализированные устройства [7].

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

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

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

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

В таблице 1.1. представлено соответствие различных перспектив составным частям BPMS-системы [8].

Таблица 1.1. Соответствие перспектив и составных частей BPMS-системы

Перспектива	Часть BPMS-системы
Перспектива управления	Бизнес-сервера, модели бизнес-процессов
Перспектива ресурсов	Персонал
Перспектива данных	Данные
Перспектива операций	Портал, веб-сервис, редакторы

1.4 Существующие методики и языки построения арихитектуры BPMS

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

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

BPMN (графическая нотация и модель бизнес-процессов, Business Process Modeling Notation) - индустриальный стандарт визуального описания исполняемых моделей процессов, ориентированных на интерактивное взаимодействие с участниками. Используется в большинстве систем BPMS в качестве основного средства для графического моделирования, имеет техническую реализацию, то есть модель может быть интерпретирована в исполняемый программный код. Спецификация BPMN описывает условные обозначения для отображения бизнес-процессов в виде диаграмм бизнес-процессов. BPMN ориентирована как на технических специалистов, так и на бизнес-пользователей. Для этого язык использует базовый набор интуитивно понятных элементов, которые позволяют определять сложные семантические конструкции. Основная цель BPMN - создание стандартного набора условных обозначений, понятных всем бизнес-пользователям. Бизнес-пользователи включают в себя бизнес-аналитиков, создающих и улучшающих процессы, технических разработчиков, ответственных за реализацию процессов и менеджеров, следящих за процессами и управляющих ими. BPMN является связующим звеном между фазой дизайна бизнес-процесса и фазой его реализации.

EPC (ориентированная на событие цепочка процессов, Event-driven Process Chains) - проприетамрная нотация описания бизнес-процессов. Широко используется для документирования рабочих процессов.

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

WSDL (язык описания веб-служб и доступа к ним, основанный на языке XML, Web Services Description Language) служит для описания интерфейсов веб-служб, используется для моделирования доступных операций, включая адреса их вызова.

XPDL (Process Definition Language, язык описания процессов) - язык, предназначенный для описания определений и реализаций процессов. Является техническим стандартом, используемым для хранения, исполнения и переноса моделей бизнес-процесса между различными BPMS средствами. XPDL предназначен для обмена определениями процессов между различными информационными системами, как в графическом так и в семантическом виде.

XSD (язык описания структуры XML-документа, XML Schema Definition) -стандарт описания данных, которыми пользуются и обмениваются бизнес-процессы и веб-службы. Такая система состоит из спецификации новых элементов XML, их атрибутов, а также их производных элементов.

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

1.5 Анализ существующих методик и обоснование выбора наиболее удобной методики проектирования архитектуры приложений и ИТ-инфраструктуры

В литературе широко описаны следующие методологии построения архитектуры предприятия:

· модель Захмана [11,12,13];

· TOGAF [18];

· методология Gartner [4,8];

· FEA;

· DoDAF и т.д.

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

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

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

· детальное и полное построение модели;

· понятность и простота создания модели;

· ориентированность на эталонные модели;

· эффективность использования и адаптация;

· ориентировка на снижение затрат в организации;

· структурная и функциональная декомпозиция предприятия;

· независимость от рынка поставщиков услуг;

· доступность информации о методологии;

· окупаемость;

· стоимость проектирования [14].

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

«Понятность и простота создания модели» показывает, полноту описания действий в методологии при создании архитектуры предприятия по шагам. На этом сосредоточена методология TOGAF, а именно представленная методика (ADM).

«Ориентированность на эталонные модели» выражает степень полезности методологии в создании набора эталонных моделей.

«Эффективность использования и адаптация» определяет уровень воплощения представления об архитектуре предприятия. На этом сосредоточена методология Gartner.

«Ориентированность на снижение затрат организации» демонстрирует, ориентирована ли методология на бизнес-цели.

«Структурная и функциональная декомпозиция» показывает полезность методологии в эффективном разбиении предприятия на отделы.

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

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

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

«Стоимость проектирования» определяет стоимость процесса проектирования архитектуры предприятия.

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

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



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

Таблица 1.2. Шкала оценки Саати

1	- равноценность
3	- умеренное превосходство
5	- сильное превосходство
7	- очень сильное превосходство
9	- высшее (крайнее) превосходство

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

Таблица 1.3. Приоритеты критериев

Критерий	Приоритет
Полнота модели	12,18%
Простота создания модели	9,15%
Эталонные модели	2,24%
Эффективность использования и адаптация	6,91%
Ориентировка на снижение затрат в организации	17,29%
Разбиение предприятия на отделы	3,34%
Нет привязки к поставщику услуг	3,07%
Доступность информации о методологии	3,20%
Окупаемость	20,17%
Стоимость проектирования	22,45%

Далее приведены таблицы сравнения альтернатив по каждому критерию (см.таблица 1.5).

Таблица 1.4. Расчет оценки согласованности матрицы парных сравнений для критериев

L=	11,32
ИС=	0,15
ОС=	9,87%
n=	10
ИС случ=	1,49

Далее проводя сравнение 4 выбранных методик по каждому критерию, получим 10 матриц парных сравнений (см. таблицы 1.6 - 1.25).

Для каждой матрицы посчитаем оценку согласованности матриц, чтобы уменьшить ошибки в матрице и избежать рассогласованности оценок. Согласованности матриц колеблются от 0,08% до 7,04% . В МАИ считается, что нормальный процент ошибки в матрицапх парных сравнений от 1 до 10%, от 11 до 20% - приемлемый. Если же процент ошибки больше 20%, то лучше перепроверить результаты [22].

Таблица 1.5. Сравнение критериев для выбора методики проектирования

Выбор методики проектирования	Полнота модели	Простота создания модели	Эталонные модели	Эффективность использования и адаптация	Ориентировка на снижение затрат в организации	Структурная и функциональная декомпозиция	Независимость от рынка поставщиков услуг	Доступность информации о методологии	Окупаемость	Стоимость проектирования	Среднее геометрическое	Приоритеты
Полнота модели	1	2	3	4	1/2	3	6	9	1/3	1/4	1,66	0,12
Простота создания модели	1/2	1	4	2	1/3	5	4	7	1/4	1/5	1,25	0,09
Эталонные модели	1/3	1/4	1	1/3	1/5	1/2	1/2	1/4	1/7	1/7	0,31	0,02
Эффективность использования и адаптация	1/4	1/2	3	1	1/2	3	2	3	1/2	1/3	0,94	0,07
Ориентировка на снижение затрат в организации	2	3	5	2	1	6	5	3	2	1/2	2,36	0,17
Структурная и функциональная декомпозиция	1/3	1/5	2	1/3	1/6	1	4	1/3	1/5	1/5	0,46	0,03
Независимость от рынка поставщиков услуг	1/6	1/4	2	1/2	1/5	1/4	1	2	1/5	1/5	0,42	0,03
Доступность информации о методологии	1/9	1/7	4	1/3	1/3	3	1/2	1	1/6	1/7	0,44	0,03
Окупаемость	3	4	7	2	1/2	5	5	6	1	2	2,76	0,20
Стоимость проектирования	4	5	7	3	2	5	5	7	1/2	1	3,07	0,22
Сумма	11 2/3	16 1/3	38	15 1/2	5 3/4	31 3/4	33	38 4/7	5 2/7	5

Таблица 1.6. Матрица парных сравнений альтернатив для критерия «Полнота модели»

Полнота модели
	Модель Захмана	TOGAF	FEA	Gartner	среднее геометрическое	приоритеты
Модель Захмана	1	3	7	9	3,71	0,59
TOGAF	1/3	1	4	7	1,75	0,28
FEA	1/7	1/4	1	2	0,52	0,08
Gartner	1/9	1/7	1/2	1	0,30	0,05
сумма	1,59	4,39	12,50	19,00
				итого	6,27	1

Таблица 1.7. Расчет оценки согласованности матрицы парных сравнений для критерия «Полнота модели»

L=	4,10
ИС=	0,03
ОС=	3,62%
n=	4
ИС случ=	0,9

Таблица 1.8. Матрица парных сравнений альтернатив для критерия «Простота создания модели»

Простота создания модели
	Модель Захмана	TOGAF	FEA	Gartner	среднее геометрическое	приоритеты
Модель Захмана	1	1/5	3	2	1,05	0,17
TOGAF	5	1	8	6	3,94	0,65
FEA	1/3	1/8	1	1/4	0,32	0,05
Gartner	1/2	1/6	4	1	0,76	0,13
сумма	6,83	1,49	16,00	9,25
				итого	6,06	1,00

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

L=	4,15
ИС=	0,05
ОС=	5,59%
n=	4
ИС случ=	0,9

Таблица 1.10. Матрица парных сравнений альтернатив для критерия «Эталонные модели»

Эталонные модели
	Модель Захмана	TOGAF	FEA	Gartner	среднее геометрическое	приоритеты
Модель Захмана	1	1/3	1/8	2	0,54	0,09
TOGAF	3	1	1/4	5	1,39	0,23
FEA	8	4	1	6	3,72	0,62
Gartner	1/2	1/5	1/6	1	0,36	0,06
сумма	12,50	5,53	1,54	14,00
				итого	6,01	1,00

Таблица 1.11. Расчет оценки согласованности матрицы парных сравнений для критерия «Эталонные модели»

L=	4,19
ИС=	0,06
ОС=	7,04%
n=	4
ИС случ=	0,9

Таблица 1.12. Матрица парных сравнений альтернатив для критерия «Эффективность использования и адаптация»

Эффективность использования и адаптация
	Модель Захмана	TOGAF	FEA	Gartner	среднее геометрическое	приоритеты
Модель Захмана	1	1/2	1/8	1/2	0,42	0,07
TOGAF	2	1	1/5	2	0,95	0,16
FEA	8	5	1	5	3,76	0,65
Gartner	2	1/2	1/5	1	0,67	0,12
сумма	13,00	7,00	1,53	8,50
				итого	5,80	1,00

Таблица 1.13. Расчет оценки согласованности матрицы парных сравнений для критерия «Эффективность использования и адаптация»

L=	4,06
ИС=	0,02
ОС=	2,06%
n=	4
ИС случ=	0,9

Таблица 1.14. Матрица парных сравнений альтернатив для критерия «Ориентировка на снижение затрат в организации»

Ориентировка на снижение затрат в организации
	Модель Захмана	TOGAF	FEA	Gartner	среднее геометрическое	приоритеты
Модель Захмана	1	1/7	1	1/8	0,37	0,06
TOGAF	7	1	7	1/3	2,01	0,31
FEA	1	1/7	1	1/8	0,37	0,06
Gartner	8	3	8	1	3,72	0,58
сумма	17,00	4,29	17,00	1,58
				итого	6,46	1,00

Таблица 1.15. Расчет оценки согласованности матрицы парных сравнений для критерия «Ориентировка на снижение затрат в организации»

L=	4,17
ИС=	0,06
ОС=	6,2%
n=	4
ИС случ=	0,9

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

Структурная и функциональная декомпозиция
	Модель Захмана	TOGAF	FEA	Gartner	среднее геометрическое	приоритеты
Модель Захмана	1	1/5	1/8	1/5	0,27	0,05
TOGAF	5	1	1/3	1	1,14	0,21
FEA	8	3	1	3	2,91	0,53
Gartner	5	1	1/3	1	1,14	0,21
сумма	19,00	5,20	1,79	5,20
				итого	5,45	1,00

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

L=	4,05
ИС=	0,02
ОС=	1,92%
n=	4
ИС случ=	0,9

Таблица 1.18. Матрица парных сравнений альтернатив для критерия «Независимость от поставщика услуг»

Независимость от поставщика услуг
	Модель Захмана	TOGAF	FEA	Gartner	среднее геометрическое	приоритеты
Модель Захмана	1	1/4	1	2	0,84	0,15
TOGAF	4	1	4	8	3,36	0,61
FEA	1	1/4	1	3	0,93	0,17
Gartner	1/2	1/8	1/3	1	0,38	0,07
сумма	6,50	1,63	6,33	14,00
				итого	5,52	1,00

Таблица 1.19. Расчет оценки согласованности матрицы парных сравнений для критерия «Независимость от поставщика услуг»

L=	4,02
ИС=	0,01
ОС=	0,57%
n=	4
ИС случ=	0,9



Таблица 1.20. Матрица парных сравнений альтернатив для критерия «Доступность информации о методологии»

Доступность информации о методологии
	Модель Захмана	TOGAF	FEA	Gartner	среднее геометрическое	приоритеты
Модель Захмана	1	1/6	1	3	0,84	0,14
TOGAF	6	1	6	8	4,12	0,68
FEA	1	1/6	1	2	0,76	0,12
Gartner	1/3	1/8	1/2	1	0,38	0,06
сумма	8,33	1,46	8,50	14,00
				итого	6,10	1,00

Таблица 1.21. Расчет оценки согласованности матрицы парных сравнений для критерия «Доступность информации о методологии»

L=	4,06
ИС=	0,02
ОС=	2,38%
n=	4
ИС случ=	0,9

Таблица 1.22. Матрица парных сравнений альтернатив для критерия «Окупаемость»

Окупаемость
	Модель Захмана	TOGAF	FEA	Gartner	среднее геометрическое	приоритеты
Модель Захмана	1	1/8	1	1/8	0,35	0,06
TOGAF	8	1	8	1	2,83	0,45
FEA	1	1/8	1	1/7	0,37	0,06
Gartner	8	1	7	1	2,74	0,44
сумма	18,00	2,25	17,00	2,27
				итого	6,28	1,00

Таблица 1.23. Расчет оценки согласованности матрицы парных сравнений для критерия «Окупаемость»

L=	4,00
ИС=	0,00
ОС=	0,08%
n=	4
ИС случ=	0,9

Таблица 1.24. Матрица парных сравнений альтернатив для критерия «Стоимость проектирования»

Стоимость проектирования
	Модель Захмана	TOGAF	FEA	Gartner	среднее геометрическое	приоритеты
Модель Захмана	1	1/2	3	4	1,57	0,32
TOGAF	2	1	4	3	2,21	0,45
FEA	1/3	1/4	1	1/2	0,45	0,09
Gartner	1/4	1/3	2	1	0,64	0,13
сумма	3,58	2,08	10,00	8,50
				итого	4,87	1,00

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

L=	4,14
ИС=	0,05
ОС=	5,26%
n=	4
ИС случ=	0,9

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

В таблице 1.26 представлен сравнительный анализ основных наиболее популярных методик проектирования архитектуры предприятия на основе выделенных ранее критериев [23]. Данные в таблице берутся из матриц парных сравнений для каждого критерия. Приоритет за каждый критерий выставляется из соответственной матрицы парных сравнений. Итоговая оценка выставляется путем сложения произведений оценки по критерию и значимостью критерия.

Таким образом, колонка итог показывает, какой приоритет имеет каждая методология. Так как наибольшее значение у методики TOGAF, то она и будет выбрана для дальнейшей работы [26,27,28,29].

Таблица 1.26. Итоговая таблица анализа методик

	Полнота модели	Простота создания модели	Эталонные модели	Эффективность использования и адаптация	Ориентировка на снижение затрат в организации	Деокмпозиция	Независимость от рынка поставщиков услуг	Доступность информации о методологии	Окупаемость	Стоимость проектирования	ИТОГО
	0,12	0,09	0,02	0,07	0,17	0,03	0,03	0,03	0,20	0,22
Модель Захмана	0,59	0,17	0,09	0,07	0,06	0,05	0,15	0,14	0,06	0,32	0,199
TOGAF	0,28	0,65	0,23	0,16	0,31	0,21	0,61	0,68	0,45	0,45	0,404
FEA	0,08	0,05	0,62	0,65	0,06	0,53	0,17	0,12	0,06	0,09	0,143
Gartner	0,05	0,13	0,06	0,12	0,58	0,21	0,07	0,06	0,44	0,13	0,255

Как видно из таблицы, максимальный приоритет имеет методика TOGAF, 40 %, наименьшая методика- Fea 14%.

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

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

Для дальнейшей работы был выбран язык ArchiMate, разработанный специально для проектирования архитектуры, основанной на методологии TOGAF [24].



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

2.1 Основные концепции языка ArchiMate

Архитектура предприятия обычно разрабатывается, для того чтобы «ключевые» люди в организации смогли рассмотреть проблемы бизнеса и ИТ-систем в компании. Таких людей, как правило, называют «заинтересованными сторонами» в системе. Роль архитектора в процессе построения заключается в решении проблем путем уточнения требований «заинтересованных лиц». Чтобы отобразить различные точки зрения разных «заинтересованных сторон» используются «виды» архитектуры, на которых отражаются требования и видение архитектуры каждой конкретной стороны. Основная задача архитектора найти компромиссные решения, чтобы удовлетворить требования различных сторон и их взгляды на проблемы в компании [25].

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

Он предлагает комплексный подход к проектированию архитектуры предприятия визуализируя различный виды архитектур (бизнес-архитектуру, архитектуру приложений и технологическую архитектуру), а также их отношения и зависимости. Он предлагает комплексный подход к архитектуре, которая описывает и визуализирует различную область архитектуры и их глубинные отношения и зависимость [30,31,32].