Как сохранить работу распределенной IT-системы в эпоху бизнес-перемен? Ольга Бенкен, T-Systems, CEE-SECR 2017

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

Конечным этапом этого перехода стало создание интеграционного приложения, внедрение которого положило конец “веерным” изменениям в коде компонентов в целью поддержать связность системы, а также позволило

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

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

Transcript

1. 19.10.2017 Vorstellung Problembehebung 2.0 1 October 2017, St. Petersburg Software Engineering Conference Russia Как сохранить работу распределенной IT-системы в эпоху бизнес-перемен? Ольга Бенкен, Ведущий бизнес-аналитик
2. Кто варил spaghetti?  >40 млн мобильных пользователей  >13 млн пользователей DSL  >100 систем в инфраструктуре технической поддержки  крупнейший телекоммуникационный оператор Европы  time-to-market не менее 9 месяцев  динамично развивающаяся отрасль 2 uc Use Case Model
3. Кто варил spaghetti?  >40 млн мобильных пользователей  >13 млн пользователей DSL  >100 систем в инфраструктуре технической поддержки  крупнейший телекоммуникационный оператор Европы  time-to-market не менее 9 месяцев  динамично развивающаяся отрасль 3 uc Use Case Model
4. Кто варил spaghetti?  >40 млн мобильных пользователей  >13 млн пользователей DSL  >100 систем в инфраструктуре технической поддержки  крупнейший телекоммуникационный оператор Европы  time-to-market не менее 9 месяцев  динамично развивающаяся отрасль 4 uc Use Case Model
5. 5 Переписать нельзя поддерживать Second Point Second Point Нужно предлагать новые услуги, чтобы оставаться конкурентноспособными Second Point Second Pointg Нужно поддерживать старые контракты и услуги Контракты Hardware Конкуренты Клиенты Бюджет и ресурсы Update старых систем по требованию data centers Нужно предлагать новые услуги, чтобы оставаться конкурентноспособными Сервис текоммуникационного оператора должен быть доступен 24/7 Не безграничны
6. 6 Классическая проблема point-to-point uc Use Case Model
7. 7 Классическая проблема point-to-point Зависимости делятся на  критичные  опциональные uc Use Case Model
8. 8 Что такое каскадная зависимость? Пример lass Domain Model Расчёт предложения Генерация приветсвенного письма Заполнение формы заявки Генерация договора Бронирование товаров на складе
9. Бизнес-требование Организовать работу с юридическими лицами Критичные компоненты  Заполнение формы заявки  Расчет предложения  Генерация договора Опциональные компоненты  Бронирование товаров на складе  Генерация приветственного письма 9 Что такое каскадная зависимость? Пример lass Domain Model Расчёт предложения Генерация приветсвенного письма Заполнение формы заявки Генерация договора Бронирование товаров на складе
10. 10 Сколько стоит поддержка? а  Затраты на обновление критичных и опциональных компонентов сопоставимы  Обновление опциональных компонентов практически не расширяет функциональность системы разрываем зависимости uc Use Case Model
11. 11 Сколько стоит поддержка? - Дорого! Разрыв зависимостей Проблема «стыковки» систем с разными версиями интерфейсов
12.  Обновленный компонент работает с двумя версиями зависимости  Ключ определяет версию зависимой системы 12 Разрываем зависимости. Ключи class Domain Model Генерация приветсвенного письма Activity1 Генерация приветсвенного письма Заполнение формы заявки
13.  Обновленный компонент работает с двумя версиями зависимости  Ключ определяет версию зависимой системы 13 Разрываем зависимости. Ключи class Domain Model Генерация приветсвенного письма Activity1 Генерация приветсвенного письма Заполнение формы заявки Компонент «Заполнение формы заявки» умеет посылать данные юр. лица  в форме ФИО для физического лица (старый интерфейс)  в новом объекте для юридического лица (новый интерфейс)
14.  скорость выхода новых функций на рынок  обновление зависимостей за несколько релизов  рабочее состояние системы независимо от версий  реализация ключей в коде компонентов  двойная работа по обслуживанию ключа из-за необходимости его создания и удаления 14 Разрываем зависимости. Ключи Минусы Плюсы class Domain Model Генерация приветсвенного письма Activity1 Генерация приветсвенного письма Заполнение формы заявки
15. Разрыв зависимости на уровне транспорта  Код компонентов не затронут  Тяжеловесное решение, привязанное к платформе IBM  Работает с одним видом транспорта  Изменения проходят через все фазы подготовки релиза 15 Разрываем зависимости. MQ-маршрутизатор Минусы Плюсы
16. 16 Сколько стоит развитие? – Очень дорого! а Для развития системы необходимо  Расширение числа компонентов  Новые требования к инфраструктуре  стабильность  возможность частой модификации  увеличение скорости взаимодействия uc Use Case Model
17. uc Use Case Model 17 Required: new transport а Стабильность Увеличение скорости взаимодействия Новый транспортный протокол Ограниченная поддержка старого протокола ES
18. Для старых зависимостей доступны два варианта обновления:  Платная кастомизация выходного модуля коробочного продукта  Перевод системы на новый транспортный протокол 18 Required: new transport uc Use Case Model Activity1 WS WS JDBC REST IMP WS WS MQ Old New ES
19. uc Use Case Model WS MQ JDBC WS REST IMP Требования  Поддержка разных транспортных протоколов  Трансформация на уровне конфигурации (без повторной сборки)  Отсутствие требований к формату сообщений  Нагрузка 200 000 запросов в день 19 Wanted: адаптер с поддержкой транспортов ES Wrapper
20. 20 Wrapper. Схема работы In-Out communication  Поддержка транспортных протоколов (WS, MQ, REST, DB, IMP) Transformation  Собственный DSL для  парсинга входящих и  формирования новых XML-сообщений на основе XSD  вычисления выражений act Basic Request Send Response Find OUT PS Map IN Req Map OUT Resp Communicate with OUT PS
21. 21 Wrapper. Схема работы Поддержка условий позволяет сделать процесс обработки запроса гибким и формировать разные сценарии обработки в зависимости от контекста. act Basic Request OUT PS1 Use OUT PS1 Use OUT PSn OUT PSn IN Mapping 1 OUT Mapping i IN Mapping k OUT Mapping 2 OUT Mapping 1 IN map 1 IN map k OUT PS1 communication Send Response OUT map 1 OUT map 2 OUT map i … … … …
22. Вынесение согласования интерфейсов и транспортов на уровень конфигурации позволило 22 Wrapper. Результаты внедрения First Point тдьженять системный ландшафт Second Point econd Point Second Point First PointSecond Point до 4х раз сократить время и расходы на поддержку каскадных зависимостей гибко изменять системный ландшафт удвоить число опрашиваемых компонентов ( 9 -> 18) внедрить модули статистики и анонимизации
23.  Использование в трех сегментах сети приводит к тому, что запрос может проходить через Wrapper более одного раза Wrapper влияет на работу не двух компонентов, а целой цепи 23 Wrapper. Движение к Process Engine uc Use Case Model Wrapper Wrapper Wrapper
24.  Исключение систем-агрегаторов из топологии системы 24 Wrapper. Движение к Process Engine uc Use Case Model Wrapper Wrapper Aggregator Wrapper act Basic Call OUT PS 3 Call OUT PS1 Conditon1 Call OUT PS2 Condition2 Call OUT PS4 Call OUT PS5
25.  Гибкое обновление компонентов системы, проходящее в несколько этапов 25 Wrapper. Движение к Process Engine uc Use Case Model uc Use Case Model uc Use Case Model uc Use Case Model uc Use Case Model New New New New New New
26.  Гибкое обновление компонентов системы, проходящее в несколько этапов 26 Wrapper. Движение к Process Engine uc Use Case Model uc Use Case Model uc Use Case Model New New New New New New
27. 27 Wrapper. Движение к Process Engine  Гибкое обновление компонентов системы, проходящее в несколько этапов uc Use Case Model uc Use Case Model New New New New New New
28. Основная идея следующей версии Wrapper-a – перейти от вызова одной системы к выполнению бизнес-процесса. 28 Wrapper. Process Engine act Basic Request Send Response Call OUT PS 3 Call OUT PS1 Conditon1 Call OUT PS2 Condition2 Call OUT PS4 Call OUT PS5
29. Бизнес-процесс разбит на шаги, состоящие из пары опциональных активностей  трансформация XML-сообщения  коммуникация со сторонней системой, выполнение которых происходит в случае удовлетворения заданных условий. 29 Wrapper. Process Engine act Basic optional optional optional Transformation OUT PS communication Condition
30. act Basic Request Send Response IN mapping OUT PS communication Fault OUT fault mapping Success OUT success mapping Wrapper. Process Engine Простейший сценарий обработки запроса может быть представлен в виде трех шагов. 30
31. Все варианты gateways, предусмотренные в BPMN 2.0 могут быть реализованы в Process Engine, в том числе  process Fork/Join  process Branch/Merge 31 Wrapper. Process Engine. Control flow Basic Technical step Hidden Merge Request Send Response IN map & send OUT fault mapping OUT success mapping IN forwarding OUT forwarding Fail Success
32. Поток данных проходит через каждый шаг процесса, даже если данные внутри него не изменяются. Причем,  данные каждого шага изолированы  шаги могут обмениваться данными через переменные ограниченной области видимости. 32 Wrapper. Process Engine. Data flow Variable „a“ Variable „b“ Variables „a“, „b“ act Use Case Model Step3 Step2 Step1 Step4
33. В сравнении с промышленными BPM решениями Wrapper-PE не содержит  графического редактора процессов  модуля статистики и анализа  расширенных функций модуля мониторинга 33 Wrapper. Process Engine. Optional features
34. uc Use Case Model 34 Результаты одним словом Гибкость
35. First Point тдьженять системный ландшафт Second Point Вынесение маршрутизации и согласования интерфейсов на уровень конфигурации позволяет 35 Результаты чуть более подробно econd Point Second Point First PointSecond Point уйти от жестких связей сократить time-to-market до 4х раз исключить из системы компоненты, не реализующие бизнес-функции обеспечить поэтапное внедрение новых систем в разные сегменты сети
36. Спасибо! 36
37. 37 Wrapper. Process Engine. Linkages
38. 38 Wrapper. Process Engine. Process view
39. 39 Wrapper. Process Engine. Step view
40. 40 Wrapper. Process Engine. Step statuses An executed step can be in one of the following statuses  STARTED – initial status of a step being executed  CANCELLED – condition of the step or its ancestors was not met  FINISHED – transformation and/or call of OUT PS were finished successfully  FAILED – exception occurred by execution the step or its ancestor
41. 41 Wrapper. Process Engine. Steps order Sequence 1 2 3