Фронт-офисная биология
Задача: есть Банк с огромной линейкой банковских продуктов и сервисов по каждому из продуктов (подробнее на http://www.sberbank.ru). Необходимо автоматизировать все фронтальные сценарии по каждому из продуктов, по каждому из каналов для разных групп клиентов (да, да – разные категории клиентов могут иметь разные сценарии обслуживания по одному каналу).
Пока звучит скучно и непонятно. Однако те, кому приходилось автоматизировать финансовый сектор, могут прикинуть количество фронтальных сценариев к автоматизации и необходимое количество функциональных элементов. Простые инженерные оценки дадут приблизительно следующие показатели:
- Количество сценариев (фронтальных процессов): ~ 103
- Количество визуальных форм в сценариях: ~104
- Количество печатных форм в сценариях: ~2 ᵡ 103
Уже лучше. У нас есть какая-то фактура, но пока это какая-то замершая экосистема без динамики и без эволюции.
Однако,
- те, от кого зависит общее количество продуктов и сценариев их обслуживания, раз в квартал согласуют новый план по продажам и выпускают новые продукты и акции, требующие замены старых сценариев и селекции дополнительных «гибридных» сценариев в рамках кросс-продаж. За год весь старый функционал может быть заменен на новый.
- те, от кого зависит дизайн визуальных форм периодически склонны радикально менять или дизайн, или принципы наполнения форм, то предполагая замену всей популяции сценариев, форм, сопутствующего функционала, то требуя ее увеличения на порядок до ~105
- ЦБ РФ, как метеорит, убивший динозавров, может аффектить всех, требуя своими новыми положениями пересмотр и ревизию всего функционала целиком.
Но есть еще и факторы, благоприятно сказывающиеся на росте количества функционала:
- Ожидания бизнеса по возможности выстраивания сегмента-ориентированных или персонифицированных процессов обслуживания, что является удачной почвой для роста количества вариантов сценариев обслуживания до ~ 104
- Естественно, все сценарии нужно тестировать на эффективность либо landing page, либо на удобство рабочего места оператора, что если опять не плодит кол-во самих сценариев, то увеличивает популяцию визуальных форм до ~105-∞
- Есть и длительные тренды внутривидовой борьбы. Например, удаленное обслуживание вытесняет офисное, и фронтальный функционал по удаленным каналам растет сам по себе. При этом офис не сдается – пытается получить часть «генофонда удаленки» и создать новые сценарии омниканального (Omni channel) обслуживания — ~105-∞
Похоже, что фронтальный функционал склонен размножаться и эволюционировать как бактерии в питательной среде и любое внешнее влияние, кроме морального устаревания канала обслуживания, только загибает рост экспоненты. Бочкой Петри для фронт-офисного функционала Сбербанка должна стать Единая Фронтальная Система или сокращенно ЕФС.
Не вавилонская система
Естественно, автоматизацию такого масштаба на одной коленке не построить и не поддержать последующие изменения. Решение, выводящее общее количество коленок строителей на горизонтальную асимптоту, не столь очевидно. Кроме того, что кирпичей много и их нужно очень быстро складывать, нужно еще уметь заменять перекрытия нижних этажей, не обрушив верхние.
Поскольку вычислительная сложность целевого решения низкая и функционал в основном раскладывается на типовой, как кирпичи лего, высокую скорость стройки даст RAD.
Сам по себе RAD доступен практически во всех фронтальных отраслевых решениях. Однако он строится вокруг конфигурационного ядра либо слабо гранулированной архитектуры, что не позволяет нам решить вышеуказанную задачу с перекрытиями. Естественно с конфигурационным ядром так нельзя, извлечение или замена любой несущей конструкции приведет к обрушению, перестройки всего прикладного функционала вместе с обязательным регрессом.
Кроме того, конфигурационное ядро не позволяет нам удовлетворить ожидания экспоненциального роста количества функционала, о котором говорили ранее. RAD – это обычно быстрее для типового функционала, но RAD не позволяет «порождать» новый приклад на основе уже существующего.
Решение пришло со стороны MDD (Model Driven Development). Это только на первый взгляд «предметно-ориентированный язык» — это что-то абстрактное и заумное. Нам же никто не мешает создать «предметно-ориентированный язык» самих конфигураций при том, конфигураций разных этажей башни: архитектуры, функционала, самой банковской области могут трансформироваться друг в друга и в конце концов в исполняемый код. Мы положились на следующие преимущества MDD:
- Конечный исполняемый код можно всегда переопределить или дописать функционал, не трогая алгоритмы трансформации и получить важное частное решение
- Сами алгоритмы трансформации можно заменять и расширять, не меняя уже сгенерированный код. Как мы говорили выше, целевой срок его жизни не большой
- И самое главное. Уже готовый прикладной функционал это всего лишь один из видов модели и только потом конечный код. А значит для него можно придумать алгоритм, который перегонит его по необходимости в другую модель при замене архитектуры, требований ЦБ, необходимости автоматизации A/B-тестов, порождению специализированных сценариев обслуживания по каналам и сегментам потребителей.
Так мы дошли до понимания как делать башню, которая в какой-то момент должна начать строить саму себя.
Магический зверь и где он обитает
Собственно, именно этот магический зверь
АРМ Архитектора
АРМ Системного аналитика
АРМ Системного аналитика
Да, мы посадили наших системных аналитиков за Eclipse + Papyrus. Общая модель конфигураций пока построена на базе зарендеренного дерева UML-объектов и позволяет сейчас конфигурировать: общую декомпозицию требований, артефакты конфигураций процессов, визуальных форм, точек интеграции, сущностей, их атрибутов справочников и кучу системных объектов самой платформы ЕФС. Чуть позже здесь будет и JasperReport-редактор.
Общая целевая модель генерации приведена на схеме ниже. Первый пока отсутствующий уровень — это уровень конструкторов предметной области. Объекты модели предметной области трансформируются в объекты функциональной модели. Например, в планах реализация конструктора заявки на банковский продукт, включая статусную модель. Последняя будет иметь свою волшебную кнопку и порождать на уровне функциональной модели прототип процесса, для работы с заявкой.
Общая модель генерации кода
Второй уровень, это собственно уровень модели функциональных элементов. Он позволяет уже породить первый полезный артефакт для IT-проекта – полную спецификацию функциональных элементов.
Следующий этап генерации, это генерация компонентной модели. Как видно на первом скриншоте, модель выглядит достаточно скучно: просто оранжевые и белые квадратики. Это компоненты (в нашей терминологии – прикладные модули), которые на следующем этапе трансформируются в конечный код. Внутри каждого модуля обозначены ключевые классы с соответствующей ролью – типовым паттерном взаимодействия. Все это в конце концов и превращается в исполняемый код.
Естественно, при нажатии магической кнопки с единорогом на уровне функциональной модели весь конвейер трансформаций проходит за раз. Но наличие такой пошаговой генерации позволяет нам:
- Наконец добавить слой бизнес-конструкторов независимо от организации функционального слоя и компонентной архитектуры
- Расширять состав функциональных элементов и добавлять канало-специфичные функциональные элементы
- Управлять компонентной архитектурой независимо от функционала
- Ограничить сложность кода трансформации группы связанных конфигурационных элементов одного уровня в другой группу другого элемента объемом в 1K-2K строк кода.
- Решать задачи детально, но не глобально. Например, задачи трансформации VO->DTO->VO очень часто имеет частное решение объемом «да ладно, за эти выходные точно запилю».
- Иметь на каждом слое немножечко избыточное кол-во конфигураций, чтобы автоматизировать порождение частных случаев конфигураций и «автоматизировать автоматизацию автоматизации». Например, для канального фронтального сценария порождение множества его вариация для A/B-тестирования может быть выполнено автоматически. Ну и маппинг, маппинг, маппинг.
Как уже говорили в предыдущих двух разделах, последний пункт особенно важен. Он то и позволит 104 визуальных форм превращать в 105 для задач автоматизации A/B-тестов или вывода сценария в новый канал. При этом трудозатраты не увеличиваются и в 2 раза.
Важным элементом функциональной модели является огромное количество валидаций, так как для пользователей, не являющихся профессиональными разработчиками, причина, по которой код не компилируется, или выскакивает NPE, будет тайной. По аналогичным причинам в систему добавлен стандартный для таких решений функционал пошаговой отладки процессов фронтальных сценариев.
Любой конечный код должен иметь возможность быть исправлен и доработан вручную. Исправления такого рода, особенно если вопрос касается необходимости добавления небольшой фичи или исправления багов во время функционального/интеграционного тестирования часто проходят мимо других участников – не отражаются в спецификации или, как в нашем случае, в модели.
Для обеспечения полноты конфигураций мы разработали функционал, автоматизирующий реверс-инжиниринг (Reverse engineering). Мы строим Java Model выделенного блока функционала, соответствующего отдельному прикладному модулю (оранжевый квадратик на первом скриншоте) и пытаемся распознать паттерны кода, сравнивая их с тем что есть в компонентной модели. Пока эта магия более-менее успешно работает для прикладных сущностей, публичного API, ключевых системных объектов.
На этом пока все. А чтобы разобраться детальнее с внутренней механикой инструмента, требований к нему и архитектурой, в следующей статье мы поговорим о том, что общего у электриков и архитекторов из IT.
Комментарии (0)