Міфи і парадигми інтеграції додатків
Рекомендовані статті
В даний час інформаційна безпека є цілком самостійне потужне напрямок корпоративної автоматизації. Природно, що в таких умовах напрямок це все тісніше пов'язується з питаннями прикладної інформаційної ...
На сьогоднішній день забезпечення безпеки корпоративних ресурсів є однією з найбільш пріоритетних цілей для будь-якої компанії незалежно від масштабів і сфери діяльності. Ринок інформаційної безпеки розвивається, а це значить, що і ...
Туристичний бізнес, за рахунок розвитку якого якість життя населення має підвищуватися, добре вписується в концепцію «розумного міста». До того ж рівень використання інформаційних технологій в даній галузі за останні п'ятнадцять-двадцять років ...
Приводом для написання цього блогу стала вже друга протягом року масова вірусна епідемія. І це стало дуже неприємним прецедентом. Адже таких масштабних заражень не було вже дуже давно. Втім, дана ситуація була очікуваною. Епідемію викликали ...
Світ інтеграції додатків розвивається. Інтеграція додатків - це жорстка робота, яка вимагає скрупульозного розуміння завдань, технологій і сфер їх застосування. І найголовніше обмеження, яке заважає інтегрувати корпоративні додатки на рівні бізнес-процесів, - це різні моделі реалізації бізнес-процесів в цих додатках. "Запрягти" їх разом практично не вдається.
Одна з найскладніших проблем ІТ криється в традиційному підході до інфраструктури ПО, що підтримує бізнес-процеси підприємства. Коли організація у міру зростання поступово набуває нових корпоративні програми, - це розумний і природний шлях. На сьогодні немає єдиної системи, яка б покрила всі функціональні потреби. Очевидно, що в результаті такого підходу утворюється не єдиний континент ІТ-середовища, а архіпелаг, що складається з різних острівців автоматизації. Деякі з них, зауважимо, можуть бути надто великими, наприклад острівець R / 3, проте в цілому - це саме архіпелаг. Певну негативну роль тут зіграв і принцип "best of breed", коли компанія намагається вибрати "кращий в своєму класі" продукт, в результаті інформаційна система має найкращі в своїх класах, тобто найзручніші острівці.
Природне бажання - зв'язати ці острівці разом - і породжує завдання інтеграції додатків. Однак досвід показує, що, незважаючи на запевнення постачальників, змусити різні додатки працювати спільно вельми і вельми проблематично. Справа в тому, що острівці додатків дуже істотно відрізняються один від одного. Вони відрізняються моделлю даних, закладених в їх основу, технологічним стеком, на якому вони побудовані, і т. Д. Але найсуттєвіше - вони відрізняються моделлю реалізації процесів. Внаслідок усього цього інтегрувати їх, в тому сенсі в якому ми б хотіли, так би мовити, повністю, поки не вдається. Факт полягає в тому, що інтеграція додатків, для всіх організацій, крім самих маленьких і простих, важка і складна. Як правило, інтеграція додатків вимагає поглибленого визначення завдань і складних технологій. За результатами деяких досліджень, до 60% коштів, виділених на ІТ-проекти компанії витрачають на інтеграцію. Це дуже багато і в якомусь сенсі це результат підходу "best of breed". Звичайно ж така стратегія має право на існування, але при цьому потрібно розуміти, що обов'язково виникнуть витрати на подальшій інтеграції.
Міф про стандартну технології
Іронія ситуації полягає в тому, що сьогодні безліч компаній підходять до інтеграції додатків, як до якоїсь досить стандартною технологією. Безліч ІТ-директорів все ще сподіваються на чарівну паличку, яка вирішить всі їхні потреби в інтеграції. При цьому абсолютно не віддаючи собі звіту в тому, що інтеграція додатків - це скоріше маркетинговий термін, ніж стандартна технологія.
Якщо трохи задуматися, то це очевидно - додатки, інтерфейси і більшість бізнес-задач дуже відрізняються від підприємства до підприємства. У той час як логістична компанія націлена на інформаційно-орієнтовану інтеграцію і їй необхідні рішення на основі XML і EDI, компанія, що надає фінансові послуги, більше зацікавлена в сервісно-орієнтованої інтеграції. Далі, врахуйте різні групи в межах підприємства, які можуть мати різні вимоги і обмеження інтерфейсів. І хоча деякі інтерфейси додатків забезпечують доступ до сервісів (наприклад, веб-служби), більшість з них виробляють і споживають тільки просту інформацію. Тому, навіть в результаті рішення на веб-сервісах, інтеграція не принесе відчутної користі.
Міф про універсальність веб-сервісів
Це типовий приклад міфологізації веб-сервісів і не перший випадок в історії, коли успішна в якихось проектах технологія починає абсолютизувати. Спочатку веб-сервіси призначалися для використання в територіально розподілених рішеннях, що і визначило їх асинхронний характер. Але ось теза про те, що асинхронність набагато зручніша для бізнес-процесів - це дуже велика натяжка. Нижче ми ще повернемося до обговорення меж застосування веб-сервісів, а зараз відзначимо, що міф про єдиний підхід або технологічне рішення, будь це веб-сервіси або монітори транзакцій, приносить тільки неприємності.
Три види інтеграції
Щоб більш осмислено підійти до проблеми вибору інтеграційного рішення, треба чітко визначити свої бізнес-завдання, а також розуміти загальні принципи і підходи інтеграції. В цілому підходи до інтеграції діляться на три основних види інтеграції: інформаційно-орієнтована, сервісно-орієнтована і процесно-орієнтована, так само як гібриди цих підходів.
Інформаційно-орієнтована інтеграція
Інформаційно-орієнтована інтеграція використовується в тих випадках, коли необхідно тільки реплицировать інформацію між двома або більше системами. Досвід проектів, які мені довелося спостерігати, показує, що рішення бізнес-задач більшості підприємств лежить саме в цій площині. Інформаційно-орієнтована інтеграція менш дорога і складна, ніж інші види інтеграції, тому що інформація просто витягується з вихідної системи, перетворюється, щоб зняти семантичні відмінності, і передається в потрібну систему. Технологія інформаційно-орієнтованої інтеграції включає брокери повідомлень (SeeBeyond і WebMethods), ПО middleware (IBM MQSeries), сервери реплікації баз даних та інші технології, які мають справу з поширенням інформації між двома або більше системами. Багато в чому завдяки успіху продуктів, створених на основі реляційних баз даних і супутніх стандартів (таких, як SQL і ODBC), інтеграція на рівні даних продовжує панувати в якості способу оптимізації взаємозв'язків між різними системами.
Саме така інтеграція в основному мається на увазі, коли йдеться про традиційні технології Enterprise Application Integration (EAI). Сьогодні технології EAI - це зрілі, усталені технології, і їх зручно використовувати. Однак вони страждають серйозними обмеженнями. Типовою внутрішньої архітектурою в цьому випадку є підхід, званий hub and spoke. По суті, він призначений для того, щоб перекидати великі обсяги даних з однієї системи в іншу, причому робити це з використанням перетворень з моделі конкретного додатка в загальне уявлення (common view), потім - в уявлення конкретного додатка. Таким чином можна перекидати дані з CRM в ERP-систему і назад.
Сервісно-орієнтована інтеграція
Сервісно-орієнтована інтеграція потрібна для тих завдань, які повинні спільно використовувати і функції додатків, і інформацію. Цей підхід вже дозволяє додаткам отримувати доступ до функцій інших додатків. Ідея полягає в тому, щоб використовувати прикладні сервіси, які вже існують, а не створювати їх щоразу заново. Замість спеціалізованих інтерфейсів між окремими додатками ПЗ, що реалізує цей підхід, покладається на сполучну середу з можливістю багаторазового використання, яка грає роль універсального програмного ядра, що з'єднує всі додатки.
В цілому, варто сказати, що технологічні основи сервісно-орієнтованої інтеграції поки що не настільки розвинені. Так, веб-сервіси використовуються в ряді проектів, до них придивляються компанії, але проектів, в яких інтеграція додатків цілком була б побудована на них, в світі дуже мало. Довіряти цій технології ще поки досить складно. Тим більше що застосування веб-сервісів для інтеграції успадкованих додатків, які в основному і встановлені в компаніях, пов'язане з вкрай трудомісткою роботою зреінжинірингу цих систем і створенню для них необхідних інтерфейсів. Зовсім недавно на ринку з'явилася нова, дуже цікава технологія, що отримала назву Enterprise Servise Bus (ESB), яка спирається на SOA і веб-сервіси. Однак вона ще дуже молода, і продукти на основі ESB поки знаходяться в стадії розробки та апробації.
Реалізований належним чином, підхід сервісно-орієнтованої інтеграції може зменшити вартість обслуговування системи і зробити результат проекту інтеграції набагато ціннішим. Правда, з одним "але" - якщо така інтеграція потрібна. Якщо немає, то такий підхід лише додасть суттєву і непотрібну вартість до проекту по інтеграції.
Процесно-орієнтована інтеграція
Процесно-орієнтована інтеграція надає можливість приєднатися до внутрішніх прикладних процесів кожної програми, причому таким чином, щоб не просто використовувати його функції, а створити новий або мета-процес, який і зв'яже додатки. Наприклад, у компанії є система, яка автоматизує процес, пов'язаний зі створенням вироби, система, яка автоматизує продажу вироби, і система підтримки логістики і доставки вироби замовнику. Процесно-орієнтована інтеграція повинна зв'язати ці процеси, автоматизуючи роботу системи в цілому, при цьому створюючи головний процес, який охоплює багато систем. Різниця між цим підходом і інформаційно-орієнтованої інтеграцією в тому, що інтеграція відбувається саме шляхом створення нового спільного бізнес-процесу, тоді як інформаційно-орієнтований підхід підключає додатки через ряд інформаційних потоків. По суті, це перенесення логіки інтеграції ще на один рівень абстракції вгору. Технологія процесно-орієнтованої інтеграції забезпечує інший рівень абстракції (інший спосіб представити інформаційні потоки або запити про надання сервісів), керуючи тим, як системи спільно використовують і інформацію, і сервіси.
Технологія процесно-орієнтованої інтеграції існує в двох формах: технологія процессной інтеграції від традиційних EAI-гравців (Mercator і WebMethods) і стоїть осібно технологія процессной інтеграції від Metastorm і Versata. Технологія від EAI-постачальників більш обща і законченна, тоді як технологія Metastorm вимагає значно більш детального дослідження додатків, які інтегруються, і більшою доопрацювання.
Як і технологія сервісно-орієнтованої інтеграції, процесно-орієнтована інтеграція повинна застосовуватися тільки тоді, коли вона необхідна. Як правило, технологія процесно-орієнтованої інтеграції необхідна, коли задача складна (наприклад, більше 10 систем), і стоїть завдання істотно змінити існуючі в додатках процеси. Або тоді, коли в організації є композитне додаток, що дозволяє створювати інтеграційне рішення такого класу (що поки практично не зустрічається). В цілому, чим більше систем, які потрібно інтегрувати і чим менше автоматизовані процеси, які існують між додатками, тим більше необхідна процесно-орієнтована інтеграція.
Спочатку - завдання
У реальності, процесно-орієнтована, сервісно-орієнтована і інформаційно-орієнтована інтеграція часто співіснують один з одним. По всій видимості, більшість підприємств в кінці кінців прийдуть до необхідності змішування і об'єднання технологій, щоб вирішити свої бізнес-завдання. І тут немає і не може бути універсального рішення. Якщо ви чуєте, що продавець каже про "універсальне рішення" для всіх ваших потреб інтеграції або що всім процесом повинні управляти веб-служби, знайте, що це просто балаканина.
Необхідно почати з бізнес-завдань і потім шукати технологію, яка відповідає цим вимогам. Можливо, ви вже вирішили, який тип інтеграції вам підійде, але не поспішайте. Помилки тут траплялися дуже часто. Досвід показує, що занадто багато організацій застосовують рішення на веб-сервісах, там, де вони не потрібні. За оцінками експертів, лише в 20% проектів інтеграції потрібно використовувати сервісно-орієнтовану інтеграцію. В інших випадках відбувається лише обмін даними. Веб-послуги це всього лише частина технологій, вони виконують свою роботу, однак це не єдиний спосіб інтеграції додатків. У загальному і цілому веб-сервіси і традиційні EAI-технології є сторонами єдиної інтеграційної середовища. Традиційні EAI-підходи часто виявляються більш конкретними, Сільносвязанная рішеннями, а веб-сервіси представляють узагальнений слабо зв'язаної підхід до проблем інтеграції. "Спеціалізовані рішення вимагають великих зусиль розробників і підтримки, в той час як узагальнені рішення, як правило, виявляються менш ефективними, - вважає Чарльз Голдфарб, творець XML-технології. - Ви обмінюєте загальне зниження ресурсів організації - ресурси, необхідні для розробки конкретного рішення, - на зниження ресурсів комп'ютерів, які можуть працювати не так ефективно ". "Якщо ви працюєте з великими обсягами і ваші цілі чітко визначені, то, можливо, вам має сенс оптимізувати робочий цикл, створивши Сільносвязанная спеціалізоване рішення, - продовжує Голдфарб. Однак якщо вам потрібна гнучкість, то підхід використання веб-сервісів може виявитися більш цінним" .
Предінтегрірованние і композитні додатки
Крім описаних варіантів інтеграції додатків, пов'язаних з впровадженням тих чи інших спеціалізованих систем, існують і кілька інших способів вирішення проблем інтеграції.
Перша - це орієнтація на предінтегрірованние продукти одного постачальника. Якщо порівняти додатки з автомобілем, то підхід "best of breed" означає, що підприємство вибирає кращі в світі шасі, двигун, кузов. Але це ще не означає, що в результаті вийде кращий автомобіль, так як автомобілі виготовляються в умовах фабричного виробництва, а не прямо на шосе. Тому думка про те, що корпоративні додатки теж повинні збиратися в умовах фабричного виробництва, здається розумною.
Одним з найактивніших прихильників такого підходу є Oracle, як правило, спирається на ідею створення єдиної бази даних для різних додатків і інтеграції на її основі. Частина фахівців вважає, що рух до предінтегрірованним програмним коплекс - це шлях, який дозволяє вирішити багато зі складностей інформаційної інфраструктури. Однак замовники аж ніяк не поспішають скористатися такою можливістю, розуміючи, що тим самим вони виявляються міцно прив'язаними до одного постачальника програмного забезпечення. Крім того, ще не один програмний комплекс не покривав всього спектра завдань підприємства. І швидше за все - ніколи не покриє.
Зрозуміло, що створювати предінтегрірованние програми не так легко. Тому подальше обговорення питання, чи готові корпоративні додатки до повноцінної інтеграції, призвело до нового витка їх розвитку - концепції композитних додатків. По суті, композитні додатки - це ті ж самі прикладні програмні системи, які однак мають можливість через уніфіковані інтерфейси звертатися до успадкованого базисного функціоналу корпопратівних додатків. В цьому випадку, наприклад, система управління логістичними ланцюжками може будуватися саме як композитне додаток: воно звертається до ERP-системі, CRM-системи, іншим системам, які є в компанії, вибудовуючи тим самим новий наскрізний бізнес-процес. У цьому сенсі композитні додатки є технологічним розвитком ідей процесно-орієнтованої інтеграції. Але на новому етапі - добре розроблені і каталогізовані програмні інтерфейси дозволяють на основі відокремлених острівців композитних додатків побудувати деяку єдину систему, тобто, вирішити задачу інтеграції.
Однак це аж ніяк не справжнє, і таких додатків ще практично немає. Тут також в лідерах Oracle. Якщо раніше до E-Business Suite можна було звертатися через інтерфейсні таблиці, XML-шлюзи, то буквально недавно Oracle заявив, що фактично відкриває прикладні програмні інтерфейси. Це перетворює E-Business Suite в так званий integration ready продукт, який в майбутньому може бути використаний для розробки нових композитних додатків. У цю ж сторону рухається і SAP з xApps. В якості технологічної основи композитних додатків більшість фахівців бачить веб-сервіси.
В цілому, нам дуже пощастило - ніхто з великих постачальників корпоративних додатків - ні SAP, ні Oracle, ні MBS - не зміг стати монополістом. Це і визначило їх рух в сторону надання можливостей взаємодії різних додатків. У них просто немає вибору - спроба і далі просувати політику покупки всіх додатків з одних рук і закритих інтерфейсів, очевидно, привела б до проблем для цього постачальника. В першу чергу це, а аж ніяк не деклароване прагнення до стандартизації, рухає ними. Але для замовників це, очевидно, вигідно.