1. цілі інтеграції
2. Взаємодія інтегрованих програм
3. обмін файлами
4. Загальна база даних
5. віддалений виклик
6. Асинхронний обмін повідомленнями
7. топологія
8. Точка-точка
9. Хаб + спиці
10. Вибір засобів інтеграції
11. Поради загального плану
12. Рада конкретний
13. Окремо про Web-сервіси
14. Трохи про ESB і SOA

Питання інтеграції додатків підприємства активно обговорюються сьогодні комп'ютерним спільнотою. Однак в стороні нерідко залишається ряд моментів, що сприяють народженню перебільшених сподівань, покладених на ряд «модних» коштів і технологій інтеграції.

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

Наслідками відсутність належного вирішення проблеми інтеграції є:

• повторний ручне введення даних (довідники, дані про відвантаження, фінансові транзакції і т.п.);
• багаторазові і нескінченні «звірки та коригування" не виключають помилок;
• непомірні витрати на формування зведеної звітності;
• неприйнятні терміни і собівартість виконання навіть звичайних завдань.

Це визначає цілі інтеграції додатків підприємства.

цілі інтеграції

Загальні цілі інтеграції додатків можна сформулювати наступним чином:

• зменшити вартість експлуатації сукупності додатків підприємства;
• збільшити швидкість виконання типових задач або гарантувати терміни їх виконання;
• підняти якість виконання завдань за рахунок формалізації процесів і мінімізації людського фактора, як основного джерела помилок.

Цілями конкретних інтеграційних проектів зазвичай фігурують більш чіткі формулювання. Наприклад: «забезпечити формування фінансової звітності підприємства в термін не більше одного тижня після завершення фінансового періоду»; «Зменшити час оформлення продажу з однієї години до 15 хвилин»; «Зменшити кількість персоналу, задіяного для підтримки в актуальному стані довідників і класифікаторів, з 20 до п'яти осіб». Але зазвичай все, в кінці кінців, зводиться до загальних цілей, які можна сформулювати в ще більш загальному вигляді - зменшити операційні витрати підприємства або організації. Тому інтеграційні проекти часто виявляються у виграшному становищі з точки зору обґрунтування перед людьми, які приймають рішення про фінансування проектів: розрахунок показників повернення інвестицій для таких проектів може виглядати досить привабливим.

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

Хто повинен ініціювати і стимулювати інтеграційні проекти - бізнес або ІТ? Автор, виступаючи в якості виконавця робіт, стикався з різними варіантами «спонсорства» таких проектів. Для будь-якого ІТ-проекту чим сильніше зацікавленість в ньому з боку бізнес-підрозділу, тим краще. Однак для інтеграційних проектів така зацікавленість життєво необхідна. Справа в тому, що подобрине проекти зазвичай зачіпають інтереси багатьох підрозділів, кожне з яких бачить тільки свою частину бізнес-процесів - одні готують документацію, другі оформляють накладні, треті займаються фінансовими операціями і т.д. Узгодження і формалізація вимог різних підрозділів стає дуже важким завданням; відсутність серед «ідеологічних лідерів» проекту людини, якому підзвітні всі задіяні підрозділи, зазвичай означає провал проекту. Представники ІТ-служб в більшості випадків не володіють необхідним рівнем впливу.

Не треба забувати, що основна мета інтеграційних проектів - зниження витрат, так само як і передумови до проектів лежать в бізнес-області навіть якщо проект відноситься суто до ІТ. Наприклад, завдання розгортання систем управління і моніторингу виникає, якщо бізнес стурбований зниженням витрат на експлуатацію ІТ-інфраструктури. Мало того, інтеграційні проекти в якійсь мірі є перекладанням проблем з бізнес-підрозділів на ІТ-службу. Розглянемо, наприклад, типову ситуацію, коли формуванням звітів «в стилі Excel» для керівництва займається група в складі фінансового департаменту. Від ІТ-підрозділу при цьому потрібно лише підтримка в працездатному стані корпоративних інформаційних систем. У разі ж впровадження системи, автоматично формує цю звітність, за все - в тому числі і за помилки в даних - буде відповідати ІТ-служба. Дійсно, у міру збільшення ступеня інтегрованості і взаємозв'язку інформаційних систем зростає відповідальність, роль і статус ІТ-служби, збільшується залежність основних показників роботи всієї організації від надійності і ефективності інтегрованої інформаційної системи підприємства.

Взаємодія інтегрованих програм

Для взаємодії додатків зазвичай використовуються такі методи, як обмін файлами, загальна база даних, віддалений виклик і асинхронний обмін повідомленнями. У цьому списку немає прямого обміну даними між базами даних додатків: цей метод ближче немає інтеграції додатків, а до переміщення даних. З точки зору інтеграції додатків важлива можливість в процесі обміну даними виконувати якусь змістовну обробку (наприклад, при завантаженні накладних перераховувати товарні залишки). Прямий обмін даними, який зазвичай виконується засобами класу ETL (extract, transfer, load) або саморобними утилітами, зазвичай такої можливості не надає.

обмін файлами

Обмін файлами мабуть, найпоширеніший підхід до організації взаємодії. Це пов'язано з відносною простотою реалізації, а також існуванням стандартних (або «майже» стандартних) форматів обміну. Наприклад, велика частина корпоративних інформаційних систем дозволяє завантажувати і вивантажувати файли, наприклад, у форматі CSV (Comma-Separated Values ​​- «поля, розділені комами»). Але у цього підходу є і недоліки; якщо необхідно оперувати складними структурами, то прості формати обміну вже не придатні. Виникаючі в таких випадках спеціалізовані формати файлів повинні «розуміти» взаємодіючі системи, що веде до жорсткої залежності систем один від одного. Цей недолік зазвичай долають всілякими утилітами конвертації даних. Крім того, зазвичай обмін файлами на увазі участь людини - хтось повинен вивантажити файл, скопіювати його на інший комп'ютер, завантажити. Однак якщо інтегровані методом обміну файлами системи мають можливість автоматичного завантаження / розвантаження (наприклад, за розкладом), то даний підхід дозволяє побудувати повністю автоматизоване рішення, яке внаслідок своєї простоти має високу надійність і пропускну здатність.

Загальна база даних

Даний підхід концептуально дуже простий - кілька інформаційних систем або додатків використовують одну базу даних. Головний його недолік - зв'язок між інтегрованими програмами настільки тісний, що іноді неможливо помітити межу між ними (зазвичай так інтегруються продукти одного виробника). Прикладом такого підходу можуть служити більшість ERP-систем, де різні модулі системи використовують одну базу. Однак занадто тісний зв'язок перетворює конгломерат інтегрованих програм в моноліт, в «суперсистему», окремі частини якої практично не піддаються самостійної модернізації та заміні. З цим борються, використовуючи механізми серверів баз даних (представлення даних, проміжні таблиці і т.п.), але далеко не завжди ефективно.

віддалений виклик

Стандарти на віддалений виклик процедур виникли два десятка років тому, дозволяючи програмного коду, який виконується на одному комп'ютері, викликати код на іншому. Стандарти з'являлися, розвивалися і згасали: RPC, CORBA, DCOM, RMI ... останнім в цьому ряду став протокол SOAP, основа сучасних Web-сервісів. Власне в підході до інтеграції з використанням віддалених викликів за ці роки нічого принципово не змінилося - якщо з додатком А щось потрібно від додатка Б, то А одним з перерахованих способів викликає функцію додатка Б.

Основний недолік віддаленого виклику - вимога працездатності всіх задіяних додатків в момент взаємодії. Уявіть собі систему ведення довідників, зміни з якої щоночі поширюються в десятки корпоративних систем. Імовірність того, що, скажімо, о другій годині ночі всі корпоративні системи знаходяться в стані повної боєготовності, невелика. На цьому «погоріли» і ми, реалізувавши за допомогою технологій Web-сервісів поширення довідників з корпоративних систем; все довелося переписати.

Досвід показує, що підхід, заснований на віддаленому виклику, прийнятний тільки в тих випадках, коли взаємодія додатків ініціюється користувачем, який сам контролює результат. Для автоматичного взаємодії без участі людини даний підхід практично непридатний. В цьому немає нічого дивного: віддалені виклики спочатку були придумані не для інтеграції різних додатків, а для створення розподілених систем, коли компоненти однієї системи можуть працювати на різних комп'ютерах.

Асинхронний обмін повідомленнями

Це, мабуть, єдиний з перерахованих підходів, який створювався спеціально для інтеграції інформаційних систем. Ідея концептуально проста і нагадує роботу електронної пошти. Коли з додатком А необхідно викликати якусь дію в додатку Б, воно формує відповідне повідомлення з даними і інструкціями і відправляє його за допомогою системи доставки повідомлень. Слово «асинхронний» означає, що додаток А не повинно чекати, поки повідомлення дійде до Б, буде оброблено, сформований відповідь і т.п. Повідомлення гарантовано доставляється завдяки механізму черг повідомлень, які знімають з взаємодіючих систем турботу про надійність мережі передачі даних, працездатності взаємодіючих систем в конкретні моменти часу і т.д.

Недолік даного підходу - висока ціна. Система гарантованої доставки на основі черг повідомлень зазвичай сама по собі недешева; єдиним відомим мені винятком є ​​Microsoft Message Queue (MSMQ), компонент серверних операційних систем сімейства Windows. Правда, є і вільно поширювані безкоштовні (наприклад, ActiveMQ), які, тим не менш, потрібно розгорнути, навчити фахівців, підтримувати, написати адаптери між системою доставки та додатками і т.д.

топологія

Існує два підходи до організації маршрутів взаємодії інтегрованих системи. Перший - пряму взаємодію інтегрованих систем за принципом «кожна з кожною», або «точка-точка». Другий - взаємодія через центральний вузол; подібну звездообразную архітектуру зазвичай звану «хаб + спиці». Топологія не залежить від фізичної архітектури інформаційної системи, а визначає логічні маршрути взаємодії і передачі даних між інтегрованими системами.

Точка-точка

При цьому підході інтегровані системи взаємодіють безпосередньо. Переваги підходу - простота, прозорість і відсутність необхідності в додатковому програмному забезпеченні. Однак, є і недоліки. По-перше, інтегровані додатки повинні спілкуватися з використанням однакових методів взаємодії та форматів викликів / даних. При зміні одного з додатків (якщо воно спричинило за собою зміну інтерфейсу взаємодії цього додатка) доводиться модифікувати або як мінімум перенастроювати всі інтегровані з ним системи. По-друге, в інформаційній системі підприємства з'являється занадто багато зв'язків, кожну з яких потрібно контролювати і підтримувати в працездатному стані.

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

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

Хаб + спиці

Взаємодія по типу «точка-точка» створює в інфраструктурі підприємства занадто багато зв'язків і вимагає узгодження інтерфейсів і форматів даних між взаємодіючими додатками. Ці недоліки покликана вирішити архітектура взаємодії, в якій всі додатки безпосередньо з'єднані тільки з центральним вузлом, вирішальним наступні завдання:

• організація маршрутизації взаємодії між інтегрованими програмами;
• перетворення форматів файлів і даних;
• забезпечення взаємодії додатків з використанням різних методів і протоколів взаємодії.

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

Недоліком топології «хаб + спиці» є висока вартість придбання і складність програмного інструментарію, що грає роль хаба, а також брак фахівців, які мають досвід застосування подібних програмних засобів.

Вибір засобів інтеграції

Готових інструментів інтеграції на ринку чимало. Так, тільки корпорація IBM в розділі програмного забезпечення інтеграції додатків пропонує пару десятків груп продуктів і ще багато інтеграційних продуктів в інших категоріях. Складність вибору полягає в тому, що серед представлених засобів є і вузько орієнтовані (наприклад, IBM Message Broker), і позиціонуються як «універсальні» (скажімо, Microsoft BizTalk). Однак вибір того чи іншого інструментарію визначається не тим, що про нього говорить виробник, а конкретним складом «зоопарку» апаратно-програмних рішень в організації, які необхідно змусити працювати спільно.

Поради загального плану

Перед вибором програмних засобів інтеграції необхідно чітко визначити всі системи, які потребують координації або в обміні даними з іншими системами; документувати всі можливі протоколи взаємодії, вимоги за обсягом даних, розкладом обміну і т.д. Ключовим моментом також є необхідність участі людини в процесі взаємодії інформаційних систем. Часто це диктує вибір рішень, які не мають, на перший погляд, відношення до інтеграції.

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

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

Рада конкретний

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

Окремо про Web-сервіси

Сьогодні технологія Web-сервісів позиціонується як зручний засіб інтеграції додатків, оскільки дозволяє реалізовувати, розгортати, і забезпечити просте межплатформное взаємодія. На жаль, наш досвід говорить про практичну непридатність сучасних технологій Web-сервісів для інтеграції додатків як загального підходу. Дійсно, поки Web-сервіси виявляються непридатні для обробки великих обсягів інформації; в них відсутні кошти підтримки транзакцій; взаємодіючі системи повинні перебувати в працездатному стані на момент взаємодії.

Непридатність до обробки великих обсягів - вроджена вада, який пов'язаний з XML-природою Web-сервісів. Всі дані і параметри викликів Web-сервісів перетворюються в формат XML, що у багато разів збільшує обсяг даних з усіма витікаючими з цього наслідками у вигляді зростаючої потреби в оперативній пам'яті і навантаження на процесори. На жаль, мова йде не про гигабайтах переданої інформації: Web-сервіси «захлинаються», коли за одне взаємодія між інтегрованими системами потрібно передавати вже сотню кілобайт. (Правда, існує стандарт WS-Attachments, що описує механізм приєднання до викликів Web-сервісів будь-яких даних без перекодування в XML, однак провідні постачальники цей стандарт не підтримують.)

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

Попередній стандарт WS-Transactions, покликаний вирішити дану проблему, існує, але відсутні його повноцінні реалізації. Так, корпорація IBM заявила про підтримку цього стандарту в своїх інтеграційних продуктах, заснованих на WebSphere Application Server, але з масою обмежень; найголовніше з яких - все взаємодіючі Web-сервіси повинні працювати під управлінням WebSphere Application Server. Аналогічна ситуація і у Microsoft в .Net 3.0, що вихолощує сенс Web-сервісів - простоту межплатформного взаємодії.

Але найсумніше в ситуації з Web-сервісами - не відсутність реалізацій стандартів, які стримують їх застосування для інтеграції додатків. Погано те, що після реалізації всіх необхідних стандартів Web-сервіси ризикують втратити те, завдяки чому вони стали настільки популярні, - простоту створення, розгортання, підтримки. Підтримка WS-Transactions, WS-Attachments і інших стандартів, що розширюють можливості Web-сервісів, може різко ускладнити їх створення, налагодження та розгортання.

Трохи про ESB і SOA

Повернемося тепер на п'ять років назад, коли основною платформою інтеграції додатків були транспорти на основі черг повідомлень і програмне забезпечення проміжного шару, орієнтоване на обробку повідомлень, яке відігравало роль «хаба» в розглянутої раніше архітектурі «хаб + спиці».

Подібний інструментарій проміжного шару коштував занадто дорого, а фахівці з нього - ще дорожче. Коли з'явився новий метод межплатформного взаємодії, Web-сервіси, народився і новий підхід до організації основи для інтеграції - сервісна шина підприємства (Enterprise Service Bus, ESB). Реальним відмінністю ESB від шини повідомлень підприємства стала підтримка додаткових методів взаємодії між додатками і хабом, перш за все, протоколу SOAP. Заснований на ESB підхід подавався як більш дешева, проста в реалізації альтернатива попередньої концепції.

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

Навколо архітектури, орієнтованої на сервіси (Service-Oriented Architecture, SOA), також дуже багато маркетингової галасу. На мій погляд, SOA - це не конкретні продукти і навіть не технологія, а лише концепція побудови інформаційних систем шляхом подання їх у вигляді сервісів, доступних для «зовнішнього» використання, в тому числі шляхом їх інтеграції з іншими додатками. Це означає, що для користувачів нічого не зміниться, поки провідні постачальники програмного забезпечення (і перш за все, виробники бізнес-додатків на зразок ERP, CRM, EAM і т.д.) не модифікують свої системи відповідно до SOA. Тільки тоді можна отримати реальний виграш; поки ж популярні бізнес-додатки - це замкнуті системи з дуже «вузьким» зовнішнім інтерфейсом.

Однак провідним постачальникам програмного забезпечення це не так вже й потрібно - хоча б з тієї причини, що SOA дасть теоретичну можливість клієнтам вибирати компоненти від різних постачальників за принципом «кращий в класі» і об'єднувати їх в інформаційну систему підприємства. При цьому виробникам, швидше за все, буде потрібно переписати свої системи. Разом з тим, в даний час підтримка SOA є одним з тих небагатьох «гачків», які можуть спонукати наявних клієнтів переходити на нові версії бізнес-систем, а також сприяти правильної - з точки зору постачальника - орієнтації нових клієнтів. Так чи інакше, наступні кілька років покажуть, наскільки життєздатна концепція SOA.

Олексій Добровольський ( [email protected] ) - директор з розробки програмного забезпечення компанії КРОК (Москва).