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

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

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

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

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

Программные пакеты EAI предоставляют наборы готовых так называемых адаптеров для связи между коммуникационной средой (ESB или другой коммуникационной платформой) и приложениями или между приложениями напрямую. Для приложения могут быть доступны один или несколько адаптеров в зависимости от способов получения и использования данных. Каждый адаптер преобразует данные в/из формат конкретного приложения.

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

Адаптеры для унаследованных приложений иногда называют «обертками», а саму технологию – «обертыванием» [209] Wrappers, wrapping . – Прим. пер. . Такие адаптеры могут разрабатываться на заказ для передачи информации из/в приложение или для доступа к его функциональности.

Данный раздел содержит более техническое описание SOA.

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

Результатом является библиотека сервисов – слабо связанных программных модулей, вызываемых по мере надобности. Помимо этого, SOA предусматривает уведомление потребителей сервисов об их доступности.

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

Ниже рассматриваются некоторые ключевые термины и понятия, знание которых поможет BPM-профессионалу со стороны бизнеса разговаривать с IТ-специалистами. Ключевые понятия SOA: сервис, интерфейс, протокол, поставщик, потребитель, запрос, ответ [210] Service, interface, protocol, provider, consumer, request, response . – Прим. пер. .

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

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

Вызов веб-сервиса реализуется следующим образом: программный код на стороне потребителя сервиса «упаковывает» входные данные (например, номер счета) в XML-документ и соединяется по сети с потребителем сервиса. Это делается примерно так же, как интернет-браузер соединяется с веб-сайтом, и с использованием схожих механизмов – в частности, потребитель задает адрес поставщика сервиса в Интернете или во внутренней сети предприятия. Получив запрос, программный код поставщика сервиса его «распаковывает», извлекая данные, и выполняет действия, заказанные потребителем. Результат (например, сумма остатка по счету) снова упаковывается в XML и также по сети отправляется обратно поставщику – опять-таки примерно так же, как веб-сайт отправляет веб-страницу браузеру. Обычно вызов веб-сервиса осуществляется по тому же протоколу HTTP, по которому браузер обращается к веб-сайту, но в принципе могут использоваться и другие протоколы, в частности электронная почта.

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