Системна інтеграція

Ні для кого не секрет, що «вже все зроблено до нас». Залишилася всього-то трохи «зібрати фрагменти» для вирішення поставленого завдання. І тут виявляється, що інтегрувати роз'єднані частини нерідко складніше, ніж їх написати. Чому ж так відбувається? Що можна з цим зробити?

Всі програмісти люблять робити системи з нуля, коли думка може вільно собі винаходити будь-які форми і засоби, коли можна приймати рішення без оглядки на Легасі. Звичайно, сконструйована цілісно система, за умови, що її робив фахівець, завжди виглядає монолітно і радує око. Але ж реальність у нас текуча і з часом, будь-яка концептуальна ідилія порушується в ході розвитку бізнесу, зміни процесів, поглинання або злиття підприємств, впровадження нових систем, зміни апаратних або програмних платформ і навіть законодавства.

Хто підтримував і впроваджував системи, а вже тим більше, займався доопрацюванням, реінженерінгу і інтеграцією, той знає, що більше двох третин усіх зусиль в ІТ (уваги, часу і грошей) йде на «склейку» несумісного і спроби «подружити» модулі, написані різними людьми, в різний час, на різних мовах і технологіях, під різні платформи.

Фактори, що впливають на інтеграцію

• Прискорення процесів. Розвиток організації вимагає все частіше і частіше міняти структури даних, бізнес-процеси, не кажучи вже про дизайн та інтерфейс користувача, який просто постійно знаходиться в зміні. Ось, як раз в таких динамічних областях, де "мінливість" є самою суттю і природою системи, завдання інтеграції посилюється і перетворюється в серйозну проблему.
• Розподіленість. Організації стають все більшими, а можуть бути вирішені завдання все більш комплексними, з'являється логічна, організаційна та географічна розпорошеність.
• Гетерогенність. У великому проекті, майже ніколи немає можливості дотримуватися платформ та інструментів від одного виробника, тому доводиться враховувати і підтримувати особливості декількох платформ.
• Спадковість. Неможливість повністю відмовитися від легаси систем, морально застарілих технологій, старого апаратного забезпечення, які, до речі, іноді дають цілком хороші показники по надійності і продуктивності але вже аж ніяк не сприяють інтеграції.
• Хаотичність. Не завжди є можливість повністю формалізувати, уточняти і структурувати дані, і частина моделі залишається "слабо-пов'язаної", яка не піддається або слабо піддається машинній обробці, аналізу, індексації, обрахунку.
• Обумовленість. На жаль, інформаційні системи обмежені не тільки технічними рамками, а й звичками людей (яких складно переучувати), особливостями законодавства (яке просто не готове до появи таких систем), безліччю інших чинників, не залежних від розробників.
• Інтерактивність. Споживач інформації постійно підвищує свої очікування про швидкість реакції системи, швидкодії і оперативності доставки інформації. Більшість процесів прагнуть до виконання в реальному часі.
• Мобільність. Користувач систем став пересуватися швидше, а взаємодія з ним ведеться через канали зв'язку загального користування в транспорті, вдома і на вулиці, в громадських місцях і повсюдно.
• Безпека. Поки дані зберігалися на носії всередині приміщення, що охороняється, то особливо ніхто не турбувався про шифрування, але тепер мережеві пакети літають в повітрі і це не можна залишати без уваги.
• Високонавантаженнiсть. На складність інтеграції впливають: кількість користувачів в системі, інтенсивність потоку обробки даних, обсяги даних і ресурсомісткість обчислень.
• Безперервність циклу роботи. Інтеграція і апгрейд систем майже завжди повинні проводитися без зупинки їх функціонування, плавно, поступово і непомітно для організації та її клієнтів.
• Міжсистемна інтеграція. Завдання стикування не обмежені рамками організації, все частіше потрібно інтегруватися з партнерами, клієнтами, постачальниками, підрядниками та навіть державними структурами.

Параметри, що відповідають за складність інтеграції і запропонуємо варіанти мінімізації негативного впливу цих параметрів

• Концептуальна різниця - грунтується та тому, що розробники різних систем спочатку прийняли різні рішення, припущення і допущення, які концептуально не стикуються між собою. Вирішується введенням ще одного шару абстракції, який концептуально суперечить обом підходам. При цьому, є два варіанти реалізації: (а) коли вийшла система стає централізованою, а дві і більше інтегруються системи перетворюються в підсистеми і (б) коли ми використовуємо архітектуру брокера (посередника, який не є центром), при цьому системи залишаються незалежними, а брокер забезпечує прошарок між ними.
• Технологічна різниця - коли ми маємо несумісні формати обміну даними, протоколи взаємодії та інтерфейси. Вирішується написанням конвертів, прошарків, брокерів та інших примочок, не цілком красивих, але достатньо надійних.
• Несумісність ліцензій. Детальніше зупинятися на цьому не буду, так як не фахівець я в цьому питанні, а рішення може бути в кожному випадку індивідуальне, на організаційному рівні.

Загальна задача виглядає так: необхідно інтегрувати N інформаційних систем, якi характеризуються описаними вище факторами, з мінімізацією кількості прошарків, конвертерів, брокерів і інтерфейсів між ними. Якщо вирішувати завдання в лоб, то між N системами буде N (N-1) / 2 зв'язків, тобто, при двосторонньому взаємодії N (N-1) інтерфейсів. Якщо врахувати, що під інтерфейсом ми тут можемо розуміти все що завгодно, від веб-сервісу до офлайнового процесу, що запускається, наприклад раз на добу і робить цілий ряд складних операцій по синхронізації баз (запити, обробку, експорт, закачування по FTP, передачу сигналу іншій частині системи, щоб та прийняла передані дані і виконала свою частину роботи, а потім повідомила про результати і передала необхідні дані назад). Загалом від таких варіантів ніколи не вдасться позбутися повністю, питання тільки в грамотній їх реалізації.

Арсенал засобів за рішенням поставленого завдання

• Стандартизація - потрібно і важливо використовувати якомога більше міжнародних, державних і галузевих стандартів, а якщо якихось не вистачає, а вони явно просяться, то потрібно вводити корпоративні стандарти, а часто має сенс і просувати їх у відповідних організаціях для якнайшвидшого поширення і популяризації.
• Інтеграція на рівні брокерів. Переваги: ​​універсальність - практично завжди можна створити додатковий програмний модуль, який будуть звертатися в обидві системи, ще й різними способами (наприклад, в одну через базу даних, а в іншу через RPC). Недоліки: складність, трудомісткість, а отже висока вартість розробки, впровадження та володіння.
• Інтеграція на рівні даних - то є кілька додатків можуть звертатися в одну базу даних або в кілька баз даних, пов'язаних реплікаціями. Переваги: ​​низька вартість інтеграції, а при використанні однієї СУБД це стає дуже привабливим рішенням. Недоліки: якщо база даних не екранована збереженими процедурами і не має необхідних обмежень цілісності (у вигляді вказівки каскадних операцій і тригерів), то різні додатки можуть приводити дані в суперечливі стану. Якщо ж база екранована і цілісність забезпечується, то і в цьому випадку, в паралельно працюючих з однієї БД додатках, будуть дубльовані частини коду, що виконують однакові або схожі операції. Крім того, при змінах структури бази ми будемо окремо переписувати код всіх додатків, з нею працюють.
• Інтеграція на рівні сервісів - це красива інтеграція, заснована на фіксації інтерфейсів і форматів даних з двох сторін і дозволяє налагодити швидку відпрацювання міжкорпоративної бізнес-логіки. Є й недоліки: все ж, присутня фіксація, а якщо структури або процеси змінюються, то утворюються проблеми і вузько спеціалізовані, приватні рішення.
• Інтеграція на рівні користувача - це крайній випадок, чи не автоматизована інтеграція, коли користувачі переміщують дані між системами через копіпаст, файли, пошту та інші неподобства. Ми такі методи не розглядаємо, але вони, на жаль, часто застосовуються в той період, поки програмні системи не готові, а розвиток компанії не дозволяє чекати.
• Динамічна інтерпретація метаінформації - про це ми поговоримо в окремій статті.