Коллектив авторов - Свод знаний по управлению бизнес-процессами - BPM CBOK 3.0

• Регулирование – полный жизненный цикл сервисов.

• Определение сервисов, которые будут реализованы в прототипе SOA, и требований к прототипу, включая отчет по результатам и его анализ.

• Определение типов сервисов, которые будут реализованы.

• Приобретение компетенций в области SOA: подготовка и тестирование персонала, выбор и внедрение ПО.

• Как будут разрабатываться, тестироваться и внедряться элементы SOA – сервисы, EAI адаптеры и т. д.

• Как будет внедряться и использоваться ESB, включая переделку существующих механизмов коммуникаций.

Примечание:приведенный список содержит ключевые вопросы, но не является исчерпывающим.

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

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

К компонентам BPM, следующим подходу SOA, относятся:

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

• EAI-адаптеры, реализованные в виде сервисов SOA;

• бизнес-аналитика (BI) – операционная статистика, аудит и т. п.;

• управление правилами – описание и исполнение;

• управление процессом – мониторинг и контроль действий и работ;

• управление эффективностью – получение данных из приложений BPMS, унаследованных и других приложений, использующих протоколы SOA.

Сервисная шина предприятия (ESB) – это сочетание архитектуры программного обеспечения, программных средств и коммуникационной среды, управляющих передачей данных между компьютерами. Коммуникационная среда ESB в передаче сообщений выполняет функцию посредника: прикладные системы подключаются к ней для обмена информацией друг с другом. Программное обеспечение ESB получает сообщение от приложения посредством адаптера для того протокола, который данное приложение использует. Адаптер преобразует полученные данные к стандартному внутреннему формату ESB. Затем ESB определяет получателя сообщения, сверяясь с загруженным в него набором правил маршрутизации. Передача данных также осуществляется через адаптер, при этом происходит еще одно преобразование данных – на этот раз из внутреннего формата к формату протокола, поддерживаемого приложением-получателем. Еще одна важная функция ESB, помимо гибкой маршрутизации и преобразования протоколов, – обеспечение гарантированной доставки. ESB сохраняет сообщения во внутренней очереди и в случае временной недоступности приложения-получателя повторяет попытки доставки.

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

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

Упрощение интерфейсов и сокращение их числа снижают риски и затраты и позволяют быстро вносить в приложения изменения.

ESB отлично дополняет BPMS, а в некоторых случаях (как, например, IBM WebSphere и TIBCO) они фактически являются одним целым.

Репозиторий BPMS хранит бо́льшую часть данных о процессах компании. Однако обычно в нем не хранятся все данные транзакций, совершаемых в ходе выполнения процесса. Ввиду большого объема такой информации для ее хранения часто используется внешняя СУБД. Решение о том, какие данные будут храниться в репозитории BPMS, а какие вовне, часто принимается исходя из их использования. Например, информация, необходимая для управления процессом, – исполнители задач, маршруты потоков работ, экранные формы – обычно хранится в BPMS. Любой проект внедрения BPMS требует участия специалистов по СУБД для определения, где что будет храниться и какие базы данных будут использоваться для хранения транзакционных данных.