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

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

ПРИМЕНЕНИЕ СОБЫТИЙНО-УПРАВЛЯЕМОЙ АРХИТЕКТУРЫ И МЕТОДОВ КОМПЛЕКСНОЙ ОБРАБОТКИ СОБЫТИЙ В УПРАВЛЕНИИ БИЗНЕС-ПРОЦЕССАМИ ТЕЛЕКОММУНИКАЦИОННОЙ КОМПАНИИ

Титов С.В., Попов С.С.

Национальный исследовательский ядерный университет «МИФИ»

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

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

APPLICATION OF EVENT-DRIVEN ARCHITECTURE AND METHODS OF COMPLEX EVENT PROCESSING IN THE MANAGEMENT OF BUSINESS PROCESSES OF A TELECOMMUNICATIONS COMPANY

Titov S.V., Popov S.S.

This article is devoted to consideration of approaches to transformation of a control system of business processes in the telecommunication company. The description of business process of holding an advertising campaign wheel submitted, the major factors indicating changes of approaches to management of process the need allocated. As the instrument of transformation, it wheel chosen event - the focused architecture. Shown applicability of this architecture for management of the specified business process.

Keywords: business process, information system, event-driven architecture, complex data processing, business model.

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

? возможность модернизации процессов, которые охватывают несколько приложений;

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

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

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

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

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

Одной из архитектур, предполагающих создание программного обеспечения, определяющего события и соответствующую реакцию на них, является EDA (англ. event driving architecture - событийно-управляемая архитектура).

Термин EDA был предложен Роем Шульте [2], аналитиком компании Gartner, в опубликованном 9 июля 2003 года отчете «Повышение значимости событий для интеграции приложений». Этот документ неожиданно быстро оказался в списке наиболее цитируемых работ по интеграции приложений, а его автор приобрел широкую известность среди специалистов.

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

Большинство систем, построенных на EDA, используют также и принципы архитектуры SOA, или, если быть точнее, то EDA является дополнением SOA.

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

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

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

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

Подобные типы акций широко распространены в США и странах Евросоюза, при этом их поддержка основана на SOA с применением ESB (англ. enterprise service bus - связующее программное обеспечение, обеспечивающее централизованный и унифицированный событийноориентированный обмен сообщениями между различными информационными системами на принципах сервис-ориентированной архитектуры) (см. Рисунок 1). Сервисы в них существуют для того чтобы взаимодействовать с клиентами при помощи электронной почты или иных приложений, а также для предоставления новых сервисных услуг в том числе активации счетов, оформления смартфонов и прочего.

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

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

бизнес процесс событийный телекоммуникационный

Рисунок 1 - Применение SOA

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

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

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

Рассматривая применение EDA следует также определить роль CEP в указанном бизнеспроцессе.

СЕР (англ. Complex Event Processing - комплексная обработка событий) позволяет автоматизировать реакцию системы на различные события используя графический подход. Система CEP выделяет значимые события, определяет его факторы воздействия на систему, а затем продолжает отслеживать его таким образом, чтобы можно было предпринять какие-либо действия. Такое действие может являться результатом события, о котором будет уведомлен ответственный за акцию или событие, которое запустит автоматический процесс. Если SOA автоматизирует строгие бизнес-процессы, то CEP позволяет автоматизировать принятие решений для различных людей. Следовательно, CEP необходим для реализации настоящей EDA, в силу того, что ESB воспринимает события, относящиеся к сложному и динамичному процессу, на более простом уровне.

CEP состоит из следующих частей [4]. Первая - это коннекторы, служащие для захвата и определения событий, которые находятся наверху ESB, СУБД и приложений. Захваченные события отправляются на сервер, обрабатывающий события, который предназначен для фильтрации бесполезных событий, которые коннекторы затем определяют в индексируемый формат таким образом, чтобы они могли быть отслежены.

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

Рисунок 2 - Применение СЕР

CEP предназначена для поддержки пользователя в рамках организации случайных, не связанных событий, а также определения тенденций, предсказания возможных результатов с возможностью выполнения действий для предотвращения негативных результатов [2]. В следствие чего модель системы, представленная на рисунке 1, принимает следующий вид (см. Рисунок 2).

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

Список литературы

1. Самуйлов К.Е. Бизнес-процессы и информационные технологии в управлении телекоммуникационными копаниями, М.: Альпина Паблишерз, 2009. 442 с.

2. Иртегов Д.В. Многопоточное программирование с использованием POSIX Threads [Электронный ресурс]. 2010. URL: http://www.intuit.ru/studies/courses/570/426/lecture/9700 (Дата обращения: 05.06.2017).

3. Рассел Д. Событийно-ориентированная архитектура, М.: Книга по Требованию, 2012, 52 стр.

4. Данилин А.В., Слюсаренко А.И. Архитектура [Электронный ресурс]. 2007. URL: http://www.intuit.ru/studies/courses/995/152/info (Дата обращения: 12.06.2017).

Размещено на Allbest.ru