Продолжаем рассказывать про технические особенности реализации проекта по выпуску и обслуживанию банковских карт «МегаФона». В предыдущих постах мы говорили о карте как о финансовом продукте, о ее возможностях и об устройстве программного обеспечения, которое обеспечивает работу системы. В этом посте мы затронем вопросы, связанные с интеграцией  IT-систем «банка Раунд» — партнера «МегаФона» по проекту — с IT-системами оператора. Технологическим партнером по созданию интеграционного решения, объединяющего IT-системы банка и «МегаФона», стала компания «Неофлекс» — системный интегратор с более чем двенадцатилетним опытом работы на IT-рынке.
Проект проходил в несколько этапов: 
  • Команда «Неофлекс» изучила бизнес-процессы, спроектированные на стороне МегаФона.
  • Совместно с ИТ-архитекторами банка мы предложили решение, которое позволило положить эти процессы в основу SOA-архитектуры, с учетом обеспечения стабильности и устойчивости системы. 
  • Затем были сформулированы требования к будущему интеграционному решению, которое также было разработано «Неофлекс». 
  • Следующий этап — разработка и тестирование, его делали итерационно, разбивая функциональность на логические блоки.
Мы понимали, что важно не ошибиться при проектировании дизайна потоков данных. Возможно, это звучит банально, но для данного проекта этот аспект был критическим, поскольку интеграция затронула IT-ландшафты двух разных индустрий. И телеком, и банкинг имеют свои правила и исторически сложившиеся особенности, которые необходимо было учесть и «бесшовно» объединить в единый процесс по обмену данными. Мы предпочли взять паузу на старте проекта и совместно с архитекторами банка и оператора разработать дизайн по интеграции, выявить необходимые сервисы, проанализировать бизнес-процессы, внести в них изменения, чтобы затем переложить их на концепцию SOA. Дизайн действительно удалось проработать качественно, изменения конечно были, но они были минорные и не влияли потом на архитектуру интеграционного решения.

Одним из самых сложных аспектов проекта еще на этапе планирования работ являлось наличие большого количества поставщиков и подрядчиков. Выполнение такого проекта классическим водопадом привело бы нас к увеличению сроков, что было недопустимо. Из-за того, что работы выполнялись в динамическом режиме, фиксировать scope на начальном этапе было практически нереально. Работать классическим scrum мы тоже не могли, так как многие контрольные точки зависели от поставщиков других систем. Мы применили спиральный подход: совместно с банком мы проанализировали приоритеты других поставщиков, общие задачи проекта и выделили блоки функциональности. Эта модель и определила для нас состав итераций по разработке проекта. Как результат, когда прошла половина срока на выполнение всего проекта, мы начинали аналитику по сервисам для IVR и личного кабинета клиента, при этом на тестовом окружении уже стояло интеграционное решение, обеспечивающее процесс выпуска карт. Это позволяло на ранней стадии определить, какие изменения и улучшения внести в процесс, а команды АБС и фронта по выпуску карт могли проводить сквозное тестирование новой функциональности.

Полный материал доступен на портале Хабрахабр

Источник: Портал Хабрахабр


Поделиться

Вернуться к списку публикаций