Как не сорвать сроки, когда в проекте больше 6 команд и 50 человек? Кейс IT-интеграции для банка

В прошлом году один банк обратился к нам, чтобы сократить time-to-market и выстроить единую IT-архитектуру в проекте, где одновременно участвует куча людей. В статье рассказываю, почему Scaled Agile Framework — это сложно и долго, и как нам удалось разработать и внедрить Единую интеграционную среду всего за два месяца.

Кто не знает, Я — Константин Могилевкин, основатель Satori — IT-лаборатории, интегратора цифровых решений для банков, страховых и fintech-компаний. Эта статья будет полезна всем, кто в теме финтеха или банкинга — мы расскажем про решения для быстрого развития экосистемы.

Часто крупные компании внедряют методологию SAFe (scaled agile framework), а чтобы все системы работали слаженно, создают единую интеграционную среду (ЕИС). На разработку и внедрение ЕИС обычно нужны долгие месяцы и большая команда.

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

Для развития IT-ландшафта и бизнес-продуктов наняли больше 4 подрядчиков по разным направлениям (ДБО, АБС, OPEN API и т.д.) и больше 20 сотрудников в IT и бизнес-направления.

Нас, SATORI, наняли как IT-интегратор для решения таких задач:

Сроки сжатые, планы грандиозные.

Поэтому мы начали с разработки концепции ЕИС

Концепция ЕИС — это набор организационных и технических правил, политик, стандартов и ограничении, которые должны применяться при выстраивании взаимодеиствии между IT-системами предприятия.

В область применения концепции ЕИС не входит взаимодеиствие компонентов системы. Такие взаимодеиствия прописывают в частных ТЗ.

В концепции фиксируют, например, как объединить между собой микросервисы и как они взаимодействуют: синхронно или асинхронно, через шину или напрямую, через API или, не дай бог, прямыми запросами к базе данных.

Концепция ЕИС:

Концепция нужна не всем. Но без нее не обойтись, если в подразделении больше трех команд. При таком количестве исполнителей уже повышается риск недопонимания и теряется контроль. Особенно концепция нужна, если хочется единую IT-архитектуру, которая не «разъедется» хотя бы 3 года.

SAFe — это слоеный пирог из различных методик Agile. Его часто применяют IT-интеграторы.

Что входит в этот «пирог»:

Это сложная концепция, поэтому мы на нее забили. Вместо этого ограничились одним документом, обучением по нему и несколькими архитекторами, которые удерживают весь IT-ландшафт и IT-архитектуру у себя в голове.

А дальше мы пошли по алгоритму:

0. Оценили, какие команды и подрядчики будут работать над проектом

На этапе обсуждения задачи мы выявили, что будем внедрять несколько IT-систем. Каждая система будет выполнять свою роль в этой цепочке, и разработкой этих систем займутся разные команды с разным уровнем оперативности и включенности в проект.

Чтобы запустить один банковский продукт, всегда нужно запустить в прод больше, чем одну систему:

В случае с банками обычно бывает так: банк давно развивается, выстраивает системы, а новые технические директора тащат из прежних мест подрядчиков, которые делают управляемое качество. Поэтому обычно в банках много коробочных решений, интегрированных между собой. Бывает, что интегрированы плохо.

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

Хорошо, что в данном случае сотрудники банка сами понимали, что нужно регламентировать взаимодействие между командами. В идеальном мире прямо до того, как переходить непосредственно к разработке.

1. Провели технологическое ревью

На момент написания Концепции ЕИС у нас была на 70% готовая IT-архитектура в части розничного бизнеса (но большую часть работ составлял еще корпоративный блок, где пока не было готовой IT-архитектуры).

Из IT-архитектуры было понятно, что для запуска двух продуктов, на которые выделялись основные бюджеты, нужно было изменить или довнедрить 6 IT-систем: 3 текущих и 3 новых. И всё это интегрировать между собой.

Каких-то регламентов, примеров документов для описания интеграций между системами не было — для каждой интеграции требовались «ручные» договоренности. И мы хотели поменять этот ручной привод на автоматические правила и инструменты в соответствии с концепцией ЕИС.

2. Провели точечное исследование каждой системы

На этом этапе мы изучили, что из себя представляла каждая из систем для внедрения. Примерили, как они будут взаимодействовать с другими системами в целевой картинке.

Этот этап особенно важен для специфических продуктов и предметных областей.

Например, в телекоме есть телекоммуникационные форматы протокола взаимодействия — по ним звонят и отправляют SMS (например SMPP). Типовой протокол HTTP для них не подходит. Или, например, особые протоколы нужны для датчиков на нефтяных скважинах.

Для банка неклассических интеграций не требовалось, стандартный стек TCP/IP (Transmission Control Protocol/Internet Protocol, протокол управления передачей/протокол интернета), здравый смысл и много-много требований к безопасности.

3. Привели правила взаимодействия под понятный формат

После анализа каждой системы нужно было понять, как они будут взаимодействовать между собой, выработать правила и форматы.

Для этого мы оценили системы по критериям:

Например, есть система, которая обрабатывает кредитные заявки. В процессе обработки нужно выполнять проверки клиента. Для проверок нужно передать данные клиента из заявки в единый сервис проверок, который использует внутренние и внешние системы банка. Например, получает выписку из Бюро кредитных историй. И нам как раз нужно было организовать взаимодействие между кредитным конвейером и единым сервисом проверок.

Схема, как это взаимодействие происходит:

4. Проработали детали

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

Мы ссылались на общепринятые нормы и форматы относительно того, как называть методы, элементы в этих методах — использовали стандарт BIAN (Banking Industry Architecture Network).

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

Это самая трудоемкая часть.

5. Выбрали инструменты

До нашего сотрудничества в банке не было стандартов: где создавать документы, ставить задачи, формировать пользовательскую и административную документацию.

Мы выбрали инструмент swagger для описания контрактов взаимодействия между системами. Swagger позволяет делать минимум телодвижений, получать из кода документацию и обновлять ее при изменении кода. То есть, не нужно специальное форматирование.

Теперь у банка есть документ, который можно транслировать на других подрядчиков. Документ фокусировался только на том, как встроиться в IT-ландшафт. То есть, он не затрагивает детали — языки программирования, например. Банк сам принимает решение, какой язык выбрать для каких ИТ-систем.

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

В данном случае мы пока сами отвечаем за актуализацию документа. Такой вариант — делегировать актуализацию подрядчикам — подходит тем, кто пока не готов нанимать свою команду или только готовится к этому. Нанимать команду намного дольше и дороже, чем делегировать все подрядчикам.

Как мы дорабатываем документ:

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

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

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

***

Ещё больше кейсов и IT-решений для финтеха ищите в нашем ТГ-канале.