Системи управління процесами і SOA

Аналітики, лідери індустрії і постачальники програмного забезпечення багато пишуть про сервіс-орієнтованої архітектури (Service Oriented Architecture, SOA) і про те, чому цей підхід став основним при проектуванні архітектури інформаційних систем підприємства. Під SOA тут мається на увазі концепція, в рамках якої додаток складається з набору готових компонентів – "цеглинок", частина з яких вже існує на підприємстві, а частина надається зовнішніми постачальниками сервісів. Основною перевагою такого підходу є типізація компонентів ІТ-рішень і можливість швидкого перестроювання додатки в разі потреби. Однак в області SOA існує декілька питань, які є центром дискусій навколо даної концепції.


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


Рис. 1. Традиційне додаток, що має монолітну структуру


При цьому є істотні вигоди від забезпечення більш повних функціональних можливостей для вбудованих у додатки процесів, але ця монолітність заважає додаткам пристосовуватися до унікальних потребам різних клієнтів. Можна порівняти монолітне додаток з бетонним будовою, яке неможливо перебудувати без руйнування. Будівля, створена з великих компонентів, у разі необхідності легко змінити, використовуючи існуючі матеріали та докупивши нові блоки – сервіси. Якщо вимоги клієнта забезпечуються функціональністю вбудованих в монолітне додаток процесів, то воно працює добре. Втім, якщо вимоги клієнта не можуть бути виконані з-за недостатньої гнучкості програми, то єдиним рішенням може стати зміна програми, що істотно в плані вартості впровадження і подальшої підтримки. В іншому випадку користувач змушений працювати відповідно до правил вбудованих у додаток процесів і відмовитися від використання тих процесів, які йому на самому дійсно потрібні. Обидва варіанти не додають ефективності підприємству, і в даному випадку на одній чаші ваг знаходиться повнофункціональне додаток з великою вартістю володіння, яке складно змінювати, а на іншій – типове додаток, що змушує користувача працювати відповідно до закладених в ньому типовими процесами. Також важливо й те, що вбудовані в додаток бізнес-процеси обмежені по функціональності і не можуть бути легко розширено, щоб застосовувати сервіси, що надаються додатками інших розробників.


Service Oriented Architecture


SOA змінює дану ситуацію, дозволяючи додаткам визначити всі свої основні сервіси як дискретні функції – "цеглинки". Наслідком цього є той факт, що процеси, які застосовують дані сервіси, можуть бути автоматизовані з використанням набору існуючих сервісів, як показано на рис. 2. У такому випадку вони легко настроюються або перебудовуються для задоволення унікальних потреб кожного клієнта. Крім того, ці процеси можуть бути легко і швидко змінені у відповідь на зміну зовнішнього середовища.


Рис. 2. Додаток, побудоване на базі SOA


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


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



Web-сервіси базуються на XML, що означає незалежність від платформи. А завдяки тому, що web-сервіси засновані на відкритих стандартах та протоколах, досягається простота їх розробки та налагодження. Нарешті, web-сервіси забезпечують вільне взаємодія між постачальником і споживачем. Це означає, що коли сервіс змінюється внаслідок застосування нової версії, заміни додатка або зміни платформи, то використовує даний сервіс додаток змінювати не потрібно.


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


Рис. 3. "Наскрізна" автоматизація


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


Business Process Management


Будь-яка організація використовує багато процесів, для підвищення ефективності яких необхідно забезпечити їх "наскрізну" автоматизацію. Управління такими процесами вимагає застосування спеціалізованої системи Business Process Management (BPM), яка дозволяє керувати процесами в протягом всього їх життєвого циклу. Системи BPM – це сукупність програм і систем класу middleware, що підтримують спеціалізовані завдання управління "наскрізними" процесами (моделювання, впровадження, оперативне управління та адміністрування, моніторинг та аналіз показників ефективності), а також взаємодія людей та інформаційних систем.


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


Можна припустити, що роль BPM-систем є центральною для проектування SOA, і правильно говорити про створення процесно-орієнтованої архітектури (Process Oriented Architecture, POA). У зв'язку з цим слід зазначити, що поняття "сервіс" і "процес" взаємозалежні і можуть застосовуватися на різних рівнях узагальнення. Невеликий процес може бути організований в якості сервісу в разі можливості його типізації, але в той же час сервіс може бути розбитий на подсервіси, що взаємодіють в рамках процесу, якщо типізація на даному рівні є неприпустимою. Сервіси існують для того, щоб бути використаними в процесах, і все більше сервісів буде створюватися централізовано для застосування безліччю компаній. У цьому випадку ключові переваги будуть досягатися за рахунок вдосконалення внутрішніх бізнес-процесів підприємства.


Ultimus BPM Suite і SOA


Підтримка SOA і web-сервісів є стандартною функціональністю системи Ultimus Adaptive BPM Suite. Вона надає повномасштабну інтеграцію з використанням web-сервісів як їх постачальника, так та його споживача за допомогою наступних компонентів:



Використовуючи дані можливості, можна розгорнути бізнес-процеси за допомогою архітектури SOA, а як інструмент застосовувати Ultimus BPM Suite (рис. 4). Крім того, "наскрізні" процеси можуть охопити безліч додатків, що використовуються на підприємстві, що є істотним чинником успішного впровадження процесного управління.


Рис. 4. Ultimus Adaptive BPM Suite в якості основи SOA


Висновок


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


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


В даний час багато BPM-системи, в тому числі Ultimus Adaptive BPM Suite, можуть надати набір інструментів, які дозволять почати застосовувати принципи SOA на практиці.


За прогнозом аналітичної компанії Gartner, до 2008 року понад 60% підприємств будуть використовувати SOA в якості основного принципу побудови корпоративної ІТ-архітектури.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*