Коллектив авторов - Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0
• взаимодействуют подразделения;
• принимаются решения и назначается ответственность;
• меняется процесс;
• проверяются процедуры;
• применяются способы и методы.
В настоящее время существует множество тесно связанных с SOA программных продуктов, к которым относятся сервисные каталоги и репозитории[214], ESB, системы комплексной обработки событий (CEP)[215], BPMS и т. д. Достичь успеха и реализовать преимущества SOA может компания любого масштаба. Но много и тех, кто потерпел неудачу. Перечисленные продукты предоставляют стандартную платформу для реализации SOA на предприятии, но без систематического рассмотрения и утверждения необходимой стратегии, стандартов, методов регулирования и программ подготовки персонала программное обеспечение просто не даст ожидаемого эффекта. Поэтому любой организации, серьезно рассматривающей переход на SOA, расширение области применения SOA или испытывающей проблемы с внедрением SOA, необходимо решить эти вопросы как можно раньше.
10.3.7.4. Переход на SOA
При переходе на SOA следует обратить внимание на следующее.
• Концепция, стратегическое планирование, одобрение со стороны высшего руководства, выделение бюджета и управление ожиданиями.
• Стратегия оценки эффективности бизнеса – от стратегических целей до операционной эффективности сервиса.
• Оценка готовности к переходу на SOA – текущая технологическая среда и архитектура.
• Описание стратегии SOA – включая описание способов применения и перспективный план реализации[216].
• Описание архитектуры – использование или неиспользование ESB, статическое или динамическое создание экземпляров сервисов, статическое или динамическое связывание сервисов, требования SLA и качества сервиса, эксплуатационные характеристики (доступность, надежность, отказоустойчивость и т. д.), использование репозитория для поддержки жизненного цикла сервисов.
• Регулирование – полный жизненный цикл сервисов.
• Определение сервисов, которые будут реализованы в прототипе SOA, и требований к прототипу, включая отчет по результатам и его анализ.
• Определение типов сервисов, которые будут реализованы.
• Приобретение компетенций в области SOA: подготовка и тестирование персонала, выбор и внедрение ПО.
• Как будут разрабатываться, тестироваться и внедряться элементы SOA – сервисы, EAI адаптеры и т. д.
• Как будет внедряться и использоваться ESB, включая переделку существующих механизмов коммуникаций.
Примечание: приведенный список содержит ключевые вопросы, но не является исчерпывающим.
10.3.7.5. Применение SOA
В рамках SOA компания определяет интерфейсы к разнообразным унаследованным и/или вновь разрабатываемым приложениям, специфицируя их функциональность и используемые протоколы. Это делает возможным обращение к одной и той же функциональности из разных приложений, поддерживающих протоколы SOA. Взаимодействие по схеме «точка-точка» уходит в прошлое, взаимодействие между системами и между бизнес-подразделениями упрощается и становится более эффективным. Одновременно, однако, еще более критичными становятся вопросы целостности данных.
Подход SOA предлагает новый способ разработки программных модулей, основанный на стандартизированных сервисах и интерфейсах, который можно использовать для внешних по отношению к BPMS приложений. Но и приложения, созданные в среде BPMS, концептуально соответствуют SOA – они выполняют одну функцию, они стандартизированы и могут использоваться повторно.
К компонентам BPM, следующим подходу SOA, относятся:
• процессный движок – доступ через SOA к данным, необходимым для выполнения очередной задачи;
• EAI-адаптеры, реализованные в виде сервисов SOA;
• бизнес-аналитика (BI) – операционная статистика, аудит и т. п.;
• управление правилами – описание и исполнение;
• управление процессом – мониторинг и контроль действий и работ;
• управление эффективностью – получение данных из приложений BPMS, унаследованных и других приложений, использующих протоколы SOA.
10.3.8. Сервисная шина предприятия (ESB)
Сервисная шина предприятия (ESB) – это сочетание архитектуры программного обеспечения, программных средств и коммуникационной среды, управляющих передачей данных между компьютерами. Коммуникационная среда ESB в передаче сообщений выполняет функцию посредника: прикладные системы подключаются к ней для обмена информацией друг с другом. Программное обеспечение ESB получает сообщение от приложения посредством адаптера для того протокола, который данное приложение использует. Адаптер преобразует полученные данные к стандартному внутреннему формату ESB. Затем ESB определяет получателя сообщения, сверяясь с загруженным в него набором правил маршрутизации. Передача данных также осуществляется через адаптер, при этом происходит еще одно преобразование данных – на этот раз из внутреннего формата к формату протокола, поддерживаемого приложением-получателем. Еще одна важная функция ESB, помимо гибкой маршрутизации и преобразования протоколов, – обеспечение гарантированной доставки. ESB сохраняет сообщения во внутренней очереди и в случае временной недоступности приложения-получателя повторяет попытки доставки.
Таким образом, программное обеспечение ESB располагается между приложениями и работает через адаптеры EAI, давая любым приложениям возможность взаимодействовать друг с другом через стандартный формат сообщений ESB.
Использование единого внутреннего формата означает, что достаточно разработать один адаптер, подключающий приложение к ESB, чтобы оно было готово к взаимодействию с любым другим приложением. Это большое преимущество по сравнению со встречающейся сегодня схемой коммуникаций «точка-точка», в которой программируется взаимодействие между каждой парой систем.
Упрощение интерфейсов и сокращение их числа снижают риски и затраты и позволяют быстро вносить в приложения изменения.
ESB отлично дополняет BPMS, а в некоторых случаях (как, например, IBM WebSphere и TIBCO) они фактически являются одним целым.
10.3.9. Репозиторий BPMS и хранение транзакционных данных
Репозиторий BPMS хранит бо́льшую часть данных о процессах компании. Однако обычно в нем не хранятся все данные транзакций, совершаемых в ходе выполнения процесса. Ввиду большого объема такой информации для ее хранения часто используется внешняя СУБД. Решение о том, какие данные будут храниться в репозитории BPMS, а какие вовне, часто принимается исходя из их использования. Например, информация, необходимая для управления процессом, – исполнители задач, маршруты потоков работ, экранные формы – обычно хранится в BPMS. Любой проект внедрения BPMS требует участия специалистов по СУБД для определения, где что будет храниться и какие базы данных будут использоваться для хранения транзакционных данных.
Процессный репозиторий может хранить следующую информацию о процессах и потоках работ.
Примечание: процесс по своей природе является кросс-функциональным, проходя сквозь подразделения организации. Поток работ – это часть процесса, выполняемая внутри одного подразделения или функции.
• Кто является владельцем процесса.
• Что процесс делает.
• Какие действия выполняются, и как они связаны друг с другом.
• Какие технологии используются.
• Какие триггеры или события инициируют процесс.
• Каковы ожидаемые результаты.
• Какие проблемы может вызывать каждое действие.
• Когда процесс был инициирован.
• Где процесс выполняется.
• Как процесс взаимодействует или связан с другими процессами.
• Как процесс взаимодействует с процессами других бизнес-единиц и других предприятий.
• Какова интенсивность и продолжительность процесса.
• Как передаются результаты.
• Зачем процесс нужен, и насколько он соответствует стратегическим целям.
• SLA, KPI, целевые значения и т. п.
• Метрики процессов, такие как время выполнения, количество необходимых ресурсов, минимальное и максимальное количество одновременно исполняющихся экземпляров, прямые и косвенные затраты и т. п.
• Бизнес-правила.
• Тип и источник данных, связанных с процессом.
• Нормативные требования.
• Расчетное время, особенности и формы возможных результатов.
• Результаты, которые становятся триггерами для других процессов.
