Организации, которые хотели бы использовать технологию управления бизнес-процессами в SOA, традиционно применяли один из двух подходов, каждый из которых имел свои недостатки. Первый подход подразумевал автоматизацию бизнес-процессов, но с ограничением их взаимодействия. Второй - интеграцию корпоративных приложений, но с ограничением участия в процессе человеческого фактора. В этой статье мы поговорим о преимуществах третьего подхода к решению этой непростой задачи - создании объединенной архитектуры BMP и SOA, не имеющей вышеуказанных ограничений. Эффективность применения объединенного подхода можно описать при помощи одной и той же модели на двух независимых друг от друга уровнях: процесса и сервиса. Эта так называемая “модель процесса” представлена в виде двусторонней медали. Это значит, что объединенный подход позволяет преобразовывать процессы, не затрагивая при этом ни управляющие ими сервисы, ни вызывающие их бизнес-приложения. Таким же образом изменяются технические составляющие сервиса, не влияя на сервисы, которые вызываются в рамках выполнения бизнес-процесса. Так как модель процесса - это коллективно используемая модель, то все изменения, сделанные на одной из ее «сторон», обязательно фиксируются на другой, хотя пользователи могут и не заметить этого. Такой гибкий, модельно-ориентированный подход значительно повышает оперативность процессов, локализует действие изменений и объединяет усилия бизнес-аналитиков и ИТ-разработчиков.

Цель: прийти к взаимодействию уровня процессов и уровня сервисов.

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

Особенность SOA как архитектуры заключается в том, что она декомпозирует приложения и данные до уровня дискретных, независимых компонентов, или “сервисов”, которые могут быть распределены в разных частях инфраструктуры и обладают способностью к повторному использованию. С появлением SOА на предприятии, ИТ-отделы, знающие характеристики гибкости, могут повторно использовать сервисы. Это позволяет сократить время, проходящее от разработки до ввода в эксплуатацию, и расходы на разработку, тем самым, повышая гибкость бизнеса.

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

Традиционные подходы к использованию BPM требуют серьезной доработки.

Поставщики BPM, которые традиционно занимались автоматизацией бизнес-процессов и документооборотом, то есть разработкой только BPM-систем в чистом виде, в последнее время переключились на процессные разработки и процессное управление, проектирование, моделирование, управление очередями работ, разработку пользовательских интерфейсов, активный мониторинг деятельности компании, аналитику и обработку интеракций с пользователями. То есть их работа направлена на то, чтобы все разрабатываемые процессы решали определенные задачи бизнеса. Разработка BPM систем в отрыве от сервис-ориентированной архитектуры устарела и имеет большое количество недостатков. Современные стандарты ведения бизнеса требуют подчинения бизнес-процессов изменяющейся конъюнктуре рынка. Раньше взаимосвязь между бизнес-процессами и интегрированными сервисами рассматривалась как нечто второстепенное и осуществлялась либо с помощью слабого системного интегратора, либо с помощью основных интеграционных адаптеров. Такой подход имеет два основных недостатка: во-первых, число процессов сокращается. Остаются только те, которыми управляет BPM, то есть те, которые незначительно связаны или не связаны совсем ни с приложениями, ни с другими системами. Во-вторых, между системами и процессами существует жесткая связь, которая не позволит совершенствовать эту модель в будущем.
С другой стороны, разработчики систем BPM на основе интеграции корпоративных приложений (EAI) столкнулись с проблемой другого рода: каким образом лучше осуществить взаимодействие продуктов SAP с продуктами Oracle и предоставить информацию об этом взаимодействии базовому приложению и хранилищу данных. Для решения этих задач потребуется применение высокоточного инструментария, а значит, ответственным лицом при такой разработке становится не бизнес-аналитик, а разработчик. Недостаток этого подхода заключается в том, что он ограничивает вовлечение человеческого фактора в процесс.

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

Выбор любого из этих двух подходов вынуждает вас идти на определенный компромисс:

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

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

Следующий раздел посвящен тому, каким образом можно добиться объединения BPM и SOA, и какие преимущества вы при этом можете получить.

Усиление роли сервисов для улучшения разработки процессов

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

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

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

Объединение BPM и SOA помогает взглянуть на процесс формирования бизнес-процессов с двух сторон. При этом бизнес-аналитики и ИТ-разработчики работают параллельно, но в сотрудничестве друг с другом.

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

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

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

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

Объединение BPM и SOA совершенствует технологии мониторинга процессов

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

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

Выполнение и мониторинг процесса

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

Заключение

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

по материалам сайта www.ebizq.net

Комментарии