© 1995-2021 Компания «Инфосистемы Джет»
Сложности реализации интеграционных решений и их решения
Интеграция систем

Реализация интеграционных проектов редко обходится без сложностей. Мы рассматриваем способы их преодоления

Интеграция систем Обзор

Интеграционные проекты – работа над ошибками

07.07.2015

Посетителей: 680

Просмотров: 579

Время просмотра: 3.3 мин.

Реализация интеграционных проектов редко обходится без сложностей. Мы рассматриваем способы их преодоления

 

 

Для начала отметим, что целью интеграционных проектов является не организация передачи данных между несколькими системами, как иногда полагают. На самом деле нужно достичь оптимальной автоматизации бизнес-процессов, в ходе которых требуется осуществлять передачу данных. И это концептуальное расхождение может привести не только к увеличению сроков интеграционного проекта, но и к его полному краху. Заказчик, думая, что стоящая перед ним задача локальна, сам, без обследования определяет потоки для интеграции, а интегратору остается связать их, никак не привлекая для этого специалистов компании. Но в подходе «вот список потоков – интегрируйте» есть огромный риск: после интеграции могут быть выявлены недостающие потоки, которые блокируют автоматизацию бизнес-процессов. В этой статье мы описываем возможные проблемы, возникающие в ходе проектов, вместе с рецептами их решения.

 

Проблема № 1. Я не я и корова не моя, или Проблемы взаимодействия

 

Интеграционные проекты далеко не всегда включают в себя интеграцию 2 систем, как зачастую предполагается изначально, чаще всего «подружить» необходимо от 3 до 5 систем. В этом случае 90% риска смещения сроков обусловлены просрочкой согласования необходимых работ. Растет количество участников проекта со стороны заказчика, при этом не все из них понимают важность взаимодействия с интеграционной командой, ответственно подходят к процессу и т.д.;

  Проблема № 2. «Тише едешь – дальше будешь» не всегда работает

 

Еще один фактор, который с течением времени может сильно «раздуть» сроки проекта, – рассинхронизация действий всех его участников, в первую очередь компаний-исполнителей. Например, система, которую требуется «подружить» со смежным приложением, на начало работ по интеграции еще не внедрена и не окончательно задокументирована в части требований и процессов.

 

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

Сложность потока определяется атрибутным составом передаваемых данных и числом смежных вызовов:

  • средняя сложность – один сервис на выходе, не более 50 атрибутов данных;
  • сложный – 1–3 сервиса на выходе, более 50 атрибутов данных;
  • повышенная сложность – более 3 сервисов на выходе.

 

Решение

У этих 2 проблем общее решение. Необходимо прописать хотя бы высокоуровневый регламент взаимодействий, где будет четко определена последовательность действий на всех этапах проекта, подготовить выходные документы, согласующие число участников и сроки согласования/выдачи замечаний. Это позволит снизить риски ошибок и вероятность дальнейших разбирательств по поводу того, на чьей же стороне мяч, кто именно несет ответственность в случае неактуальности документов, описывающих системы, или неразработанных требований.

 

Далее мы рассмотрим «собирательный образ» интеграционного проекта в российском банке средней величины, созданный на основе нашего опыта. Предположим, что нам нужно «подружить» фронт- и бэк-офисную системы.

 

Проблема № 3. Цыплят по осени считают

 

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

 

После обследования бизнес-процессов число потоков возрастает более чем в полтора раза. Они «размножились» в том числе за счет того, что фронтовая система не «считает» ряд потоков общими для части банковских продуктов (кредитный договор, кредитная линия и т.д.), как предполагалось изначально. Для нее на каждый подобный продукт идет один, отдельный поток.

 

При этом 5 из указанных банком потоков – создание кредитной заявки в бэк-офисе, перевод кредитной заявки в кредитный договор и т.д. – исключаются из проекта, так как заявки в бэк-офисной системе не хранятся, в ней сразу после утверждения заявки во фронтовой системе создается кредитный договор.

 

Решение

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

 

Проблема № 4. Тили-тили тесто, или Несовместимость систем

 

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

 

В рамках процесса «создание кредитного договора» мы определяем 2 интеграционных потока для создания дополнительного договора страхования: 1-й – создание страхового договора, 2-й – его привязка к кредитному договору. Соответственно, для этих потоков во фронтовой системе реализованы 2 разных метода: 1-й – для запуска создания договора в бэк-офисной системе, 2-й – для его привязки к кредитному договору.

 

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

 

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

 

Решение

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

 

Проблема № 5. У разбитого корыта?

 

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

 

Решение

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

 

Проблема № 6. Бонни и Клайд, или Несовместимость систем 2

 

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

 

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

 

Решение

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

 

Проблема № 7. Делу время, а потехе час, или Календарный план

 

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

 

Возвращаемся к нашему проекту: при обследовании бизнес-процессов были выявлены 5 интеграционных потоков, инициаторами которых являлась бэк-офисная система. Первый относился к процессу «создание кредитного договора», а остальные – к «обслуживанию заемщика». Реализация потоков требовала доработки бэк-офисного приложения, таким образом, на начальных стадиях проекта было определено, что у первого потока приоритет выше, чем у остальных. После описания спецификаций всех 5 потоков выяснилось, что они имеют общую структуру и могут быть реализованы как единый сервис на стороне бэк-офиса. Это привело к объединению этих доработок и повышению их приоритетности.

 

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

 

Решение

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

  

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

Уведомления об обновлении тем – в вашей почте

Модернизация системы хранения данных и системы резервного копирования в ВТБ

ОАО Банк ВТБ и его дочерние банки (группа ВТБ) являются международной финансовой группой, предоставляющей широкий диапазон банковских услуг и продуктов в России, некоторых странах СНГ и отдельных странах Западной Европы, Азии и Африки

И заборы «истончились», и мошенники наловчились

Звонит мне как-то представитель одного из банков, клиентом которого я являюсь. Сперва просит полностью представиться, затем – назвать дату рождения и наконец – кодовое слово.

«Новые сервисы мы внедряем только в контейнерах»: как устроена ИТ-инфраструктура «Сбербанка» в Казахстане

Почему «Сбербанк» в Казахстане не боится землетрясений? Зачем разворачивать ML-модели в контейнерах в частном облаке? Как банк справляется с кадровым голодом?

CyberCrimeCon 2017. Угрозы формата hi-tech

В октябре компания Group-IB провела ежегодную конференцию CyberCrimeCon 2017, посвященную тенденциям развития киберпреступлений и технологиям проактивной защиты. На конференции были представлены результаты отчета Hi-Tech Crime Trends 2017

Система подготовки банковской отчетности JFRS: новый подход к решению старой проблемы

За последнее время сотрудничество нашей Компании с предприятиями финансового сектора стало более тесным, что привело к акцентированию внимания на трудностях их повседневной действительности

Заглянуть в цифровую черную дыру

При упоминании Big Data у окружающих появляется мысль о том, что речь идет о передовых технологиях, о новых невероятных возможностях для хранения, обработки и анализа данных, но так ли это на самом деле

Будущее банков. Технотренды в банковской сфере

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

«Хайп прошел, пора строить». Data Lake выпуска 2021 г.

Когда озеро данных становится болотом? Что выбрать: Open Source или вендорские решения? Почему локальные озера данных в России популярнее облачных?

Система IdM: опыт эксплуатации

Система управления правами доступа эксплуатируется в Банке Москвы уже больше двух лет. Об опыте ее использования рассказывают Евгений Горбачев, начальник Управления информационной безопасности и Андрей Петрусевич, эксперт Управления информационной безопасности Банка Москвы.

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня