Как обуздать энтропию методами ИТ

Технологии
150434
0
Анатолий Шилов, руководитель проекта RS-Retail V.6 Департамента банковского ПО RS-Bank, R-Style Softlab


Неизбежность хаоса


Всем известно, что любая сложная программная (да и не только) система, развивающаяся в процессе эксплуатации, со временем рискует столкнуться с проблемой неуправляемого хаоса: пользователи постоянно требуют все новых «фич», которые не всегда гармонично укладываются в изначальную архитектуру, как бы хорошо ни была она продумана. Кроме того, используемые в системе технологии и инфраструктурные средства либо тоже развиваются, либо устаревают, и тогда на их место приходят новые. Совместить «апгрейд» технологической базы с экстенсивным наращиванием функциональности получается далеко не всегда, и  программный продукт  неизбежно устаревает. Рано или поздно наступает критический момент, когда систему необходимо «привести в порядок», в противном случае развивать ее прежними темпами станет попросту невозможно. И при этом еще надо как-то избежать пресловутого «эффекта второй системы», отказавшись от соблазна переписать все заново.
В этом смысле весьма показательна история системы автоматизации розничного банковского обслуживания RS-Retail из состава линейки RS-Bank V.6. Компания R-Style Softlab развивает этот продукт уже более  18 лет,  и всё это время система быстро растет «вширь»: рынок  постоянно требует реализации новых видов услуг для физических лиц, расширения функциональности существующих продуктов и сервисов. Разумеется, по мере разрастания кода и, что не менее важно, увеличения количества не всегда логично организованных настроек стоимость развития, внедрения и сопровождения системы неуклонно повышалась. Да и самим разработчикам становилось все сложнее справляться со своим творением. Перемены назревали давно и ждали лишь подходящего момента.
И вот, наконец, такой момент настал: компания приступила к созданию модуля «Единое окно обслуживания физлиц» с веб-интерфейсом (подробности в статье Н. Сперанской «Путеводитель по единому окну»). В рамках этого проекта мы решили убить сразу трех зайцев:
1.    Разработать принципиально новый, современный и удобный пользовательский интерфейс для  фронт-офисной части RS-Retail.
2.    Осуществить технологический «апгрейд» системы, подразумевающий перевод на новые рельсы верхнего подуровня бизнес-логики операций. (Этой теме как раз посвящена наша статья.)
3.    Внедрить  модульную организацию среднего и нижнего подуровней бизнес-логики операций.
Второй и третий пункты должны, по нашим расчетам, позволить нам обуздать энтропию в том слое системы, где она (энтропия) неизменно до сих пор показывала безудержный и плохо поддающийся контролю рост.


Цель и требования


Конечную цель нашей работы можно сформулировать так: уменьшение стоимости разработки, внедрения и сопровождения системы за счет создания в RS-Retail современного универсального, гибкого и при этом простого и наглядного механизма настройки и исполнения бизнес-процессов.
Именно этой цели соответствуют сформулированные нами требования к новому механизму:
•    Соответствие современным стандартам в области управления бизнес-процессами, таким как использование графических нотаций и SOA.
•    Универсальность. На новый механизм со временем должны быть переведены все операции и нетривиальные процедуры RS-Retail.
•    Наглядность настройки бизнес-процессов. Создание, модификация, изучение принципов работы операций должны быть доступны сотруднику банка, не являющемуся профессиональным программистом.
•    Возможность распределения действий по ролям пользователей. Многие операции нашей системы требуют участия нескольких пользователей, выполняющих разные роли (классический пример – операции с наличностью, когда документы оформляет операционист, а рассчитывается с клиентом кассир). Новый механизм должен позволять создавать такие операции.
•    Высокое быстродействие и поддержка массовых процедур. Специфика RS-Retail  такова, что в этой системе имеется большое количество сложно устроенных объектов, таких как счета, вклады и карты, а также существенный объем операций. Во фронт-офисных АРМ системы одновременно множество операционистов могут непрерывно обслуживать клиентов. Бэк-офис ежедневно запускает групповые процедуры, обрабатывающие от сотен до сотен тысяч счетов, транзакций, документов. Быстродействие для RS-Retail – критически важная характеристика. Поэтому необходимо, чтобы новый механизм не оказывал негативного влияния на производительность системы и поддерживал массовую обработку прикладных объектов.
Вышеперечисленные требования,  описывающим целевые характеристики самого нового механизма, мы дополнили еще одним, не менее значимым, — отсутствие необходимости серьезных доработок в низкоуровневой части прикладной бизнес-логики при переводе операций на новый механизм. Несоблюдение этого условия неизбежно привело бы к «эффекту второй системы» и краху всего проекта.


Стандарты


Мы потратили некоторое время на изучение современных тенденций в области управления бизнес-процессами и пришли к выводу, что из существующих графических нотаций, предназначенных для описания бизнес-процессов, наиболее подходящей для нас является BPMN (Business Process Model and Notation).
•    Она очень широко распространена, поддерживается практически в любом промышленном ПО для управления бизнес-процессами, часто используется в аналитической документации, описании протоколов взаимодействия между системами и т.п.
•    Она достаточно наглядна: BPMN-диаграмма представляет собой расширенный вариант всем известной блок-схемы.

 
Диаграмма.png
Рис. 1. Пример BPMN-диаграммы

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


Дорожки.png
Рис. 2.
«Плавательные дорожки»

Для хранения BPMN-диаграмм в репозитории системы и передачи их между инсталляциями мы выбрали формат XPDL (XML Process Definition Language). Этот формат, как и следует из его названия, основан на XML и полностью совместим с BPMN.


Особенности реализации


Опираясь на изложенные выше требования, мы реализовали новый механизм управления бизнес-процессами вместе с необходимой инфраструктурой и перевели на них часть операций по обслуживанию вкладов физических лиц. В настоящее время мы ведем работу по переводу оставшихся операций.
Новый механизм поставляется в составе дистрибутива RS-Bank V.6 вместе с модулем «Единое окно обслуживания физлиц», начиная с версии 6.20.31.24. основными компонентами механизма являются:
1.    Визуальный редактор BPMN-диаграмм, интегрированный в АРМ бухгалтера.
2.    Компилятор XPDL.
3.    Исполняющая подсистема, являющаяся частью ядра системы RS-Retail и доступная во всех ее модулях, включая АРМ с EasyWin-интерфейсом.
Пользователи системы создают диаграммы операций в визуальном редакторе. Затем логически связанный набор диаграмм (в терминах BPMN он называется пакетом) сохраняется в расположенном на сервере приложений репозитории бизнес-процессов в формате XPDL. Для того чтобы новые операции можно было выполнять, пакет диаграмм необходимо импортировать в систему (для этого служит специальный пункт меню в АРМ «Сервис розничных услуг»). При этом система компилирует XPDL в исполняемый код, который при выполнении операции работает под управлением встроенной в RS-Bank Java-машины. Таким образом, исполнение бизнес-процесса сводится просто к исполнению кода, сгенерированного на основе XPDL. Механизму операций не требуется обращаться ни к БД, ни к репозиторию XPDL для того, чтобы узнать, в каком порядке и при каких условиях должны выполняться составляющие бизнес-процесс действия. В результате сам механизм практически не оказывает влияния на производительность операций и создаваемую ими нагрузку на серверы приложений и баз данных.
Сами действия представляют собой обычные функции на языках Java, Scala или C++ (через Java/Scala-переходники можно вызывать также макросы на встроенном в RS-Bank языке RSL, хранимые процедуры на PL/SQL, обращаться к веб-сервисам и COM-объектам и т.п.). Сгенерированный на основе диаграммы код непосредственно вызывает эти функции, передавая им и получая от них значения переменных процесса или пакета, которые в коде становятся обычными переменными.
Отдельно следует остановиться на том, как реализована «передача» процесса от одного пользователя к другому. Пользователи работают каждый на своем рабочем месте, причем выполняемые ими этапы операции могут быть разнесены во времени. Поэтому, когда бизнес-процесс «обнаруживает», что работающий с ним в данный момент пользователь не имеет права выполнять очередное действие, он сохраняет свое состояние (значения переменных и идентификатор текущего действия) в базе данных и приостанавливается. В дальнейшем другой пользователь может продолжить выполнение данного бизнес-процесса, при этом его состояние будет в точности тем же, что и непосредственно перед остановкой.
Механизм операций является частью инфраструктуры RS-Bank V.6. Вместе со всей системой он работает под управлением RS Application Server. Его возможности доступны в любом модуле RS Bank. Операции, реализованные на основе нового механизма, благодаря использованию общей с остальной системой серверной инфраструктуры могут свободно обращаться к любой прикладной функциональности. При этом механизм операций и презентационный слой системы полностью отделены друг от друга; их взаимодействие основано на несложном протоколе, едином для всех бизнес-процессов и их экранных форм. Такое разделение позволяет без копирования и модификации диаграммы запускать одну и ту же операцию в АРМ с различными интерфейсами пользователя  — как в веб- и EasyWin-модулях RS-Bank, так и, например, в веб-приложениях сторонних производителей.


Настройка контекстно-зависимых параметров операций


В реальной жизни многие параметры операций (например, тарифы комиссий, допустимые валюты, схемы бухгалтерского учета) могут зависеть от контекста их выполнения – банковского продукта, подразделения, даты операционного дня и т.п. Такие параметры настраиваются при помощи бизнес-правил. Механизм бизнес-правил RS-Retail, разработанный нами специально для совместного использования с новым механизмом операций, основан на таблицах принятия решений (decision tables). Он поддерживает как встроенные системные, так и пользовательские правила. Для каждого бизнес-правила может быть определена своя структура таблицы принятия решений, позволяющая описать специфические для этого правила критерии выбора целевых параметров в зависимости от информации о контексте выполнения операции.

 

Бизнес-правило.PNG
Рис. 3.
Пример таблицы принятия решений – определение тарифа комиссии за операцию по вкладу в зависимости от вида вклада, вида и даты операции и валюты счета


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


Данная статья была бы неполной, не коснись мы еще одной важной темы – процесса создания пользовательских операций. Новый механизм предоставляет разработчику практически ничем не ограниченную свободу для самореализации, поэтому, чтобы операции выполнялись надежно и предсказуемо,  необходимо иметь упорядоченную технологию их разработки. Мы предлагаем рассматривать создание новой или доработку существующей операции как итерационный процесс, каждый «проход» которого может быть разделен на следующие этапы:
1.    Разработка требований и написание ТЗ. Аналитик или технолог пишет техническое задание, в котором указывает:
•    что должна делать операция с точки зрения предметной области;
•    из каких элементарных действий состоит операция, в каком порядке и при каких условиях они выполняются;
•    какие исходные данные нужны для работы операции;
•    как операция изменяет состояние бизнес-объектов системы.
На этом этапе мы рекомендуем создать эскизную BPMN-диаграмму операции и приложить ее к техническому заданию. Также в ТЗ можно включить набор контрольных примеров для отладки.
2.    Разработка BPMN-приложений (сервисов, выполняющих отдельные действия). Сотрудники ИТ-службы создают новые и дорабатывают существующие процедуры в соответствии с требованиями технического задания и добавляют их в реестр BPMN-приложений. Этот этап может отсутствовать, если новую операцию можно целиком «собрать» из уже имеющихся компонентов.
3.    Создание или доработка окончательной диаграммы бизнес-процесса.  Данный этап может выполняться совместно технологом и программистом. Первый «рисует» собственно диаграмму, второй указывает BPMN-приложение для каждого действия и обеспечивает корректную передачу параметров.
4.    Отладка на тестовом стенде. Новый BPMN-пакет и библиотеки с новыми и доработанными BPMN-приложениями развертываются на тестовом стенде, после чего производится отладка с использованием контрольных примеров из ТЗ. Поскольку механизм операций отделен от слоя пользовательского интерфейса, последний может быть легко заменен на  «заглушки». Это дает возможность использовать для тестирования бизнес-процессов фреймворки типа JUnit.
5.    Развертывание пакета на основной инсталляции и ввод новой функциональности в эксплуатацию.
 

Процесс создания операции.png
Рис. 4. Процесс создания операции


Планы на будущее


Уже в текущей версии системы механизм операций работоспособен, стабилен, используется в дистрибутивных операциях и может применяться в пользовательских доработках системы. Однако мы не собираемся останавливаться на достигнутом. Вот краткий список доработок, которые мы запланировали для реализации в будущих версиях системы:
•    Сбор статистики о времени выполнения операций и отдельных действий с целью оптимизации бизнес-процессов.
•    Интеграция с системами расчета KPI сотрудников банка.
•    Интеграция с подсистемой расчета показателей для программ лояльности клиентов.
•    Визуальный отладчик BPMN-диаграмм.


Вместо послесловия


За все время существования RS-Retail технологии в сфере ИТ изменились до неузнаваемости. Java стала стандартом де-факто в пресловутом enterprise; на смену монолитным программным продуктам пришли гетерогенные комплексы, компоненты которых интегрируются в единое целое при помощи сервисной шины; получили широкое распространение графические нотации для описания бизнес-процессов и основанные на них BPM-«движки». Наша система тоже не стояла на месте: нами был реализован огромный объем функциональности, предназначенной как непосредственно для обслуживания клиентов, так и для выполнения сопутствующих действий — настройки продуктов и услуг, осуществления регламентных процедур, выпуска отчетов,  выгрузки бухгалтерских документов в учетную систему.
Переход на новый механизм операций позволил нам соединить вместе современные технологии и обширную прикладную функциональность системы. Мы надеемся, что это позволит сделать RS-Retail еще более удобной, надежной, гибкой и простой в сопровождении системой, и при этом настраивать ее в соответствии с потребностями конкретных клиентов станет намного легче.


Все статьи

Комментарии



Подписка на рассылку
Сортировать
Теги:
Все теги
Выберите интересующий Вас продукт компании
Любой продукт
Сортировать по году:
2015 2016 2017 2018 2019 2020