Реалізація інтеграційних проектів рідко обходиться без складнощів. Ми розглядаємо способи їх подолання
Для початку зазначимо, що метою інтеграційних проектів є не організація передачі даних між декількома системами, як іноді вважають. Насправді потрібно досягти оптимальної автоматизації бізнес-процесів, в ході яких потрібно здійснювати передачу даних. І це концептуальне розходження може привести не тільки до збільшення термінів інтеграційного проекту. але і до його повного краху. Замовник, думаючи, що стоїть перед ним завдання локальна, сам, без обстеження визначає потоки для інтеграції. а інтегратора залишається зв'язати їх, ніяк не привертаючи для цього фахівців компанії. Але в підході «ось список потоків - інтегруйте» є величезний ризик: після інтеграції можуть бути виявлені відсутні потоки, які блокують автоматизацію бізнес-процесів. У цій статті ми описуємо можливі проблеми, що виникають в ході проектів, разом з рецептами їх вирішення.
Проблема № 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 всіх виявлених потоків, таким чином сформувавши загальну картину. Це дозволить підготувати календарний план розробки та тестування. У ньому необхідно зафіксувати конкретні дати виконання доробок, розробки потоків і тестування, а також всіх учасників процесу. Надалі в плані відзначатиметься статус розробки і тестування.
Цілком очевидно, що проблеми можуть виникнути на будь-якому етапі реалізації інтеграційного проекту. Сподіваємося, що описані нами «рецепти» проведення інтеграції допоможуть вам їх уникнути.