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

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

Главная>Интеграция систем>Интеграционные проекты – работа над ошибками
Интеграция систем Обзор

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

07.07.2015

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

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

Время просмотра: 2.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 всех выявленных потоков, таким образом сформировав общую картину. Это позволит подготовить календарный план разработки и тестирования. В нем необходимо зафиксировать конкретные даты выполнения доработок, разработки потоков и тестирования, а также всех участников процесса. В дальнейшем в плане будет отмечаться статус разработки и тестирования.

  

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

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

«Урал — не Москва»: ИТ в региональном банке с федеральной сетью

Как оформить кредит, не подписывая никаких бумаг? Сколько дней вендоры везут ИТ-оборудование на Урал? Почему СКБ-банку был нужен аудит CRM-системы?

Социальные сети на службе у мошенников

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

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

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

InfoSecurity Russia 2016: мнения участников

InfoSecurity Russia 2016 завершилась на днях в Москве, мы попросили поделиться своими впечатлениями ее участников

Сплошная фальшь, или Стоит ли доверять доверенности

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

Валюта цифровой эпохи

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

Система обработки финансовых сообщений

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

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

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

«Хотите защититься? Заведите «сейф» для мобильного банковского приложения»

Евгений Горбачев, начальник управления информационной безопасности Департамента по обеспечению безопасности Банка Москвы

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





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







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







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







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








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

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

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

            Спасибо!

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

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