Блог компании Московский кредитный банк

Ремонтные работы или IT-трансформация? Как мы разработали архитектуру с нуля и создали платформу для малого и среднего бизнеса

Привет, Хабр! Мы в МКБ разработали новый диджитал-подход к обслуживанию малого и среднего бизнеса. Хотим поделиться, как нам удалось создать IT-платформу с нуля, какие технологии и решения нам помогли, с какими трудностями сталкивалась команда и как менялись наши задачи. Подробности под катом.

Ранее мы уже рассказывали о том, как внедряли Agile и как благодаря ему пересмотрели все, начиная от иерархии и заканчивая подходом к разработке продуктов. Аналогичная трансформация произошла с проектом МСБ (продукты для малого и среднего бизнеса). По заветам Agile мы решили подать материал не безлико от абстрактного корпоративного «мы», а группой соавторов-представителей ключевых направлений и команд в проекте.

В начале была идея

Виктор Жидков
директор департамента малого и среднего бизнеса
Прежде чем выстраивать сервисы, необходимо разработать фундамент. В нашем случае это непосредственно платформа для улучшения продаж. Логика ее структуры предопределяет принцип работы внедряемых сервисов. Логику мы сформулировали так: в продуктах для МСБ всегда было много проблем, связанных с историческим паттерном в общении с клиентом и организации продаж. Именно эта невозможность контролировать все точки соприкосновения и, собственно, сам контакт менеджера с клиентом должна стать отправной точкой для разработки новой системы.
Разумеется, на рынке есть готовые CRM-решения, но их универсальность не позволяет подстраиваться под уникальные клиентские сценарии и сценарии продаж. И тогда мы решили сделать платформу, которая бы объединила в себе CRM- и BPM-компоненту. В этом случае мы представили кастомизируемый процессный модуль, чтобы можно было создавать статусную модель и автоматически развивать воронку. Изначально проектировать её монолитной неправильно — микросервисная архитектура сегодня показала свой потенциал, так что мы решили развивать нашу платформу именно в этом ключе. Мы рассмотрели основные точки контроля контактов менеджеров и клиентов: продолжительность самого разговора, количество встреч, их результативность, какие каналы приносят больше конверсий и так далее. Постепенно решения этих вопросов объединялись в новую архитектуру платформы МСБ.
Алексей Карпунин
руководитель ИТ-дирекции
Перед фактическим началом работ мы должны были понять, чем малый и средний бизнес отличается от классического корпоративного бизнеса, почему их нужно разделять, почему нужен особый IT-подход и особая архитектура.
Отличия мы сформулировали следующим образом. МСБ — это бизнес, который находится в постоянном поиске, а корпоративный бизнес — это стабильные клиенты и высокая маржа, что означает очень серьезную цену ошибки и индивидуальный подход к клиенту. МСБ — это низкая маржа и доходность только за счет объема, конвейерные процессы и необходимость поиска оптимальных подходов. Мы должны были дать бизнес-заказчику возможность пробовать, изучать гипотезы, быстро реализовывать их, проверять, отсеивать неправильные и очень быстро запускать те, которые понравились. В этом вся суть отличий. Подходы, которые мы применяли к корпоративному бизнесу, не ложились на МСБ, из-за чего процессы МСБ по факту не работали.
Так мы приняли решение о необходимости новой платформы и запустили разработку. Нам предстояло очень много задач: автоматизировать существующие процессы, рассмотреть сценарии, которые могут возникнуть в будущем, спроектировать все это в виде микросервисной архитектуры и отладить на существующих кейсах.

Стек — всему голова

Артём Забава
ИТ-бизнес-партнер
Для разработки архитектуры платформы МСБ мы в первую очередь хотели выстроить единый стек технологий, чтобы вся команда разработчиков была «на одной волне». Это сильно упростило бы разработку конкретных продуктов: при создании приоритетного продукта можно перебросить на него ребят из других команд. Также это бы очень упростило процесс онбординга и подготовки разработчиков. Фокусируемся на одном процессе обучения-становления, и нет необходимости искать разработчиков конкретного стека для каждого продукта. За основу взяли Javascript и Spring Boot.
Также нам было важно сделать прозрачный процесс деплоя CI/CD, сделать так, чтобы все сервисы разворачивались по общим правилам через TeamCity, и сделать путь универсальным. Кроме того, сформировать правильный процесс оркестрации. Решили, что выстраивать общий процесс, общаться с различными системами и отвечать за их взаимодействие должна Camunda BPM.
В процессе разработки каждое решение проходит в команде два звена. Первое — наши разработчики со своим взглядом на реализацию задач бизнеса и встраивания решений в IT-архитектуру. Другим звеном выступает отдел IT-архитектуры банка, и уже последние полтора года все действия мы согласуем вместе. Если вопрос оказывается довольно сложным и так сразу его не решить, собирается архитектурный комитет, на котором мы выходим с презентацией и обоснованием каждого решения.
На данный момент в направлении МСБ разрабатываются сервисы для автоматизации выдачи экспресс-гарантий и регулярно улучшаются существующие инструменты. Так, например, ровно год назад мы начали разрабатывать новое решение АРМ МСБ — автоматизированное рабочее место малого и среднего бизнеса, центральная система этого направления. В ней осуществляется продажа продуктов, присутствует инструмент для совершения звонков, а также есть возможность автоматизировать процесс, собирать метрики для формирования отчетов и воронки продаж. Тем самым АРМ позволяет увеличивать продажи на основе обработанной информации.
Кроме того, мы создали личный кабинет для агентов, который помогает открывать счета клиентов МСБ. Планов у нас очень много. Например, завести телеграм-ботов, которые помогут отправлять предложения, собирать статистику и общаться с клиентами.
Конечно же, в рабочем процессе мы опираемся на методологию Agile. Но это лишь небольшой процент от общего успеха. Как карбоновый велосипед — помогает выиграть 5–6 секунд, но не определяет победу во всей гонке. Многое решают кадры.
Вадим Тухватуллин
ведущий разработчик центра компетенций общебанковских бэк-офисных систем
В выборе технологий для разработки сервисов платформы МСБ мы ориентируемся на популярные open-source решения:
  • Spring Framework — фреймворк для создания веб-приложений;
  • RabbitMQ — для межсистемного взаимодействия;
  • Camunda BPM — платформа для автоматизации бизнес-процессов.
Нам важно, чтобы архитектура решения позволяла максимально быстро получать качественный результат в условиях сильных ограничений по срокам и бюджету. Стек технологий определяется из целевой архитектуры банка, учитываются количество необходимых кадров на рынке и горизонты окупаемости решения.
Мы используем концепцию цифровой трансформации: создаем для банка новые продуктовые решения со своими компонентами и сервисами согласно концепциям микросервисной архитектуры. Таким образом мы можем осуществлять доработки, не боясь нарушения общей целостности.
Сам процесс разработки похож на scrum-методологию: первым делом берем задачи из бэклога и даем оценки по инициативам заказчика. Разработчики участвуют в проработке требований. Далее устанавливаем реализованные задачи на тестовый стенд, разработчики проводят демо-показ и, если все хорошо, ставим на бой. Потом проводим ретроспективу, разбираем проблемы и сложности, с которыми столкнулась команда.

Пробы пера и первые штрихи


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

Алексей Карпунин
При реализации практик Scrum очень важно понимать — демо важен не как статус, на котором обсуждают, что сделала команда за две недели, а именно как апробация того решения, которое мы разработали вместе с заказчиком, чтобы понять: оно работает или нет, мы двигаемся в правильном направлении или ошибаемся, и скорректировать разработанное решение на ранней стадии. Мы обеспечили инфраструктуру для проведения демо в условиях реальной практики, от настройки серверов и тестовых контуров до завёртывания стенда, чтобы понимать, что еще нужно и что получается.

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

Что сделано и что дальше


Виктор Жидков
Мы показали, что бизнес может сотрудничать с IT на другом уровне, а также что в непростое время «ресурсного голода» можно не только сберечь, но и привлечь еще большие ресурсы для развития. Разработка архитектуры платформы МСБ с нуля дает толчок повторить опыт с другими направлениями банка к переводу бизнес-процессов на микросервисную архитектуру. Помимо этого, удалось отказаться от легаси, сформировать единый технологический стек и внедрить процессы разработки согласно Agile.
У нас очень много планов на будущее. Это и речевая аналитика, и многоканальность: будут доступны видео-каналы общения со всеми контрольными точками. Достаточно сложно сформулировать ближайшие пару лет, но на полгода бэклог у нас есть и по продажам можно понять, что нас ждет, спланировать бизнес-процессы. Мы включим туда все возможное, что хотим внедрить: финансовые подсказки, динамические лендинги, подсказки для наиболее эффективных клиентов, направление активности продаж на определенную когорту клиентов. Разделение платформы по элементам, каждый из которых можно будет улучшать и вместе с тем увеличивать продажи до космических размеров.

Итак, нам удалось:
  • создать рабочую платформу, которая автоматизирует процессы МСБ и помогает увеличивать продажи, используя agile-подход;
  • на основе микросервисной архитектуры объединить CRM- и BPM-компоненту;
  • ориентируясь на динамику малого и среднего бизнеса, выработать адаптивное решение на едином стеке технологии Java Script и Spring Boot;
  • подготовить АРМ-систему для МСБ;
  • оптимизировать рабочий процесс за счет open source-решений RabbitMQ и Camunda BPM;
  • провести диджитал-трансформацию бизнес-процессов, регулярно отслеживая прогресс и интеграцию в создаваемую архитектуру на этапе демо.
Однако говорить, что это конец диджитал-трансформации, очень рано. Это скорее один из тысячи шагов по улучшению сервисов МКБ в целом.
Всем спасибо, что прочли. Мы развиваемся как IT-компания и находимся в постоянном поиске свежих идей. Пишите с вопросами, советами и мнениями в комментариях, мы открыты для общения и сотрудничества.

Комментарии 17

    +1

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


    • Orchestration Systems: Kubernetes, OpenShift, Nomad, Docker Swarm, Rancher, Apache Mesos, Cloudify...
    • Load Balancers / Edge Routers: Nginx, HAProxy, Envoy, Traefik, ALB...
    • Messaging Systems: NATS, RabbitMQ, Apache Kafka, Synapse, NSQ, Pulsar...
    • Database Management: MS SQL Server, Oracle, MySQL, MariaDB, Postgress, Cassandra, Scylla, MongoDB, Redis, Amazon DynamoDB...
    • Monitoring: Zabbix, Grafana, Prometheus, Graphite...
    • Logging: Zipkin, Logstash, Splunk, Graylog...

    Из того, что перечислено в статье, понятно, что Вы используете RabbitMQ в качестве Messaging System. Интересно было бы узнать типы остальных элементов системы и как они соединены...

      +1
      Добрый день!
      Все приложения упаковываются в docker образы, но до инструментов оркестрации ещё не дошли, активно изучаем и смотрим в сторону Kubernetes, OpenShift. Так же есть не совсем удачный опыт работы с docker swarm в нашей команде(ошибки по которым тикеты долго не закрываются, проблемы с настройкой нетворков, итд)
      Балансировщиком выступает Nginx, коллеги использует HAProxy для банк апи.
      Messaging Systems: RabbitMQ
      Database: Активно используем Postgres для реляционных баз, коллеги в ряде проектов успешно использовали MongoDB(чатботы, сервисные приложения)
      Monitoring: Zabbix(healthcheck, наличие ресурсов на машине) с уведомлениями на рабочую группу
      Logging: Используем Graylog для анализа логов, в ней консолидируются сообщения от всех сервисов, настраиваются алерты. Так же смотрим в сторону Grafana
        +1
        но до инструментов оркестрации ещё не дошли, активно изучаем и смотрим в сторону Kubernetes

        А почему не дошли еще, интересно, нехватка ресурсов или нет надобности?


        Как в вашей архитектуре обеспечивается отказоустойчивость? Допустим, некий сервис считает остатки по товару и весь сервер, где этот сервис работает, выходит из строя. Кто подхватывает упавшее знамя?

          +1
          При построении закладываем ряд принципов: балансировка нагрузки(идеально для stateless сервисов), изоляция инфраструктуры, использование очередей/external tasks, мониторинг нагрузки/доступности. Если падает одна нода с сервисом, поступающие запросы идут на другую ноду.

          Насчет инструментов оркестрации: на текущий момент поддерживаем не такое большое количество сервисов/серверов. Но с их планируемым ростом и тиражированием, непременно будут увеличиваться и время/затраты на их развертку/поддержку.
            +1

            А как выполняются задачи по расписанию? Если выделен какой-то сервер, то что происходит, если он выходит из строя?

              +1
              На деле используем два способа запуска задач по расписанию: Использование стандартного механизма TaskScheduler фреймворка Spring и использование собственного механизма выполнения назначенных заданий(даёт возможность конфигурирования заданий во время работы приложения без остановки сервера, координация выполнения заданий в кластере с защитой от одновременного выполнения и возможностью привязки заданий к серверам).
        +4

        Круть, воды как в диссертации о научном коммунизме.


        Вот этим списком можно было начать и закончить.
        Spring Framework — фреймворк для создания веб-приложений;
        RabbitMQ — для межсистемного взаимодействия;
        Camunda BPM — платформа для автоматизации бизнес-процессов.

          0
          Так какой продукт сделали-то? Скрестили CRM с BPM и что получилось? Как это поможет мне, как бизнесмену? Я не умею красиво «квадратики» процессов двигать, значит двигать будет кто-то, кому я должен заплатить. Есть интеграция с IP-АТС, 1С?
          И про какой МСБ Вы говорите? Пивной бар? Кофейня? Розничный магазин? Производство окон? Пошив одежды, обуви? Дизайнеры? Строители?
            0
            Статья об опыте Московского кредитного банка (МКБ). В банке клиенты из самых разных сфер)
            • НЛО прилетело и опубликовало эту надпись здесь
              0
              VadimTukhvatullin
              Далее устанавливаем реализованные задачи на тестовый стенд, разработчики проводят демо-показ и, если все хорошо, ставим на бой.

              Я правильно понял — разработчики проводят демо-показ и это считается проведенным тестированием, достаточным для внедрения?
              Крайний раз, когда такое было, потом на бою случился краевой сценарий, о котором ни разработчик, ни технолог, ни тем более бизнес-заказчик не подумали. Недовольство клиентов, перерасчеты и всё такое.
              Заведите уже нормальных тестировщиков. Хоть это и не по скраму, но это работает.
                0
                В МКБ есть центр тестирования, практически все задачи на разработку проходят тестирование QA перед установкой на боевую среду.
                Демо проводим для получения обратной связи от команды/заказчиков.
                0
                По сути, вы выполнили такие технологические внедрения как:
                — CI/DI
                — демостенды (которые позволяют выполнять проверенную приёмку заказчиком)
                — разделение на микросервисы
                — замена Legacy монолита на адаптацию Spring+Comunda

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

                Вы выполнили рациональные внедрения и получили ожидаемый результат. Сами по себе идеи не новы. Поздравляю вас. Хорошо было бы узнать как вы сдавали релизы заказчику без демостанедов ранее и как ваша жизнь изменилась после.

                И интересно узнать более подробно, как вам удалось обосновать подобные внедрения? Ведь контакт менеджера с клиентом можно было бы реализовать в виде набора костылей на скорую руку, как это чаще всего происходит в российском ИТ :)
                  +1
                  Могу высказать мнение, как разработчика, что процессы МСБ, во многом ближе к розничным объёмам, здесь важен не проектный/функциональный подход, а именно процессный: нужно понять и построить, в терминах BPMS, «Happy Path», путь клиента. Следующим шагом идёт оптимизация процесса(увеличение скорости, повышение качества, уменьшение стоимости) прохождения каждого этапа. И в конце приходим к адаптивным процессам. Преимущества процессного подхода очевидны и для бизнеса и для ИТ, и, как вы написали, не требуют существенных обоснований.
                  К тому же, значительную часть доработок занимает автоматизация взаимодействия с партнерами/агентами банка, работа с «сетью», это опять же, большое количество информационных потоков, которыми необходимо управлять, анализировать, выстраивать их правильно, с точки зрения архитектуры с возможностью её тиражирования.

                  Реализация в виде набора костылей на скорую руку, скорее всего, уже через год скажутся на качестве работы и будут вылезать разные болячки в виде проблем масштабирования, изолированности, сложности анализа, и итд.
                  0
                  Спасибо! с жадностью прочитал статью, понравилось!
                  Я увидел, что разработчики участвуют в проработке требований? они у вас бизнес-ориентированные универсалы, получается? просто обычно этим занимаются или бизнес-аналитики, или системные аналитики. Пусть даже в паре с разработчиком/архитектором.

                  И еще просьба — могли бы вы в следующий раз показать реализованную архитектуру «на картинках»? хотя бы в укрупненном презентативном виде? было бы полезно очень.
                  Еще раз спасибо!
                    0
                    Fsergeyev
                    Разработчики, как правило, работают с функциональными требованиями(включает состав доработок: описание форм, интеграция, бизнес-правила, требования к аудиту, итд), которые составляют системные аналитики на основе бизнес-требований от заказчиков.

                    Так, я бы выделил две активности, которые мы проводим:
                    1. Заказчики могут обратиться с конкретной «болью»/юзерстори к нам, мы собираемся вместе с аналитиками/разработчиками, проводим «мозговой штурм», продумываем варианты решения с точки зрения пользовательского опыта, затрагиваемого скоупа доработок, возможные сценарии, которые нужно предусмотреть.

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

                    В целом, стремимся к тому, чтобы быть как можно ближе к предметной области заказчика. Можно сказать, что практикуем принципы Domain-driven design(DDD).

                    Насчет просьбы, полностью за! Изображения всегда нагляднее и интереснее)
                      0
                      Ничего не понял, чего сделали то? Как можно потрогать?

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.