Vysoká škola ekonomická v Praze. Možnosti využití Business Process Management BPM v SOA

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií

Student

: Pavlína Lukášová

Vedoucí bakalářské práce

: Ing. Roman Hauptvogl

Recenzent bakalářské práce

: Ing. Alena Buchalcevová, Ph.D.

TÉMA BAKALÁŘSKÉ PRÁCE

Možnosti využití Business Process Management BPM v SOA

ROK : 2008

Možnosti využití BPM v SOA

Pavlína Lukášová

Prohlášení

Prohlašuji, že jsem bakalářskou práci zpracovala samostatně a že jsem uvedla všechny použité prameny a literaturu, ze kterých jsem čerpala.

V Praze dne 30.04.2008

.......................... .......................... podpis

-ii-



Poděkování

Za podnětné konzultace, náměty a poskytnuté materiály bych ráda poděkovala svému vedoucímu bakalářské práce Ing. Romanu Hauptvoglovi.

-iii-



Abstrakt Cílem této práce je postihnout základní charakteristiky možností využití Business Process Managementu v Service-Oriented Architecture. Ačkoli tento přístup není v současnosti příliš prosazován, dnešní dynamická doba si žádá uplatňování takových přístupů, které vedou k větší flexibilitě podniku a zvýšení jeho konkurenceschopnosti. Právě spojení přístupů BPM a SOA umožňuje přistupovat k integraci podniku z několika možných pohledů. Tato práce jednotlivé přístupy představuje a identifikuje jejich hlavní přínosy a nedostatky. Tato práce si však neklade za cíl určit, který z představovaných pohledů by se dal určit za všeobecně platný. Spíše se snaží definovat situace, ve kterých je vhodné daný přístup použít. Po představení výše zmiňovaných strategií podnikové integrace se práce podrobněji zaměřuje na charakteristické rysy implementace BPM v SOA. Opomenuty nebudou ani takové rysy, které jsou považovány za typické pro technologickou doménu. V neposlední řadě práce poskytuje výčet nejdůležitějších benefitů, největších překážek a hrozeb, které plynou z neúspěšné implementace BPM v SOA prostředí, a poskytuje tak obecný přehled nejčastějších chyb. Tato práce neopomíjí ani současné trendy v oblasti integrace podniku využitím BPM a SOA přístupů a z těchto poznatků usuzuje o budoucím vývoji.

Klíčová slova Business Process Management (BPM), Service-Oriented Architecture (SOA), podniková integrace, Enterprise Service Bus (ESB), Business Oriented Architecture.

-iv-



Abstract The aim of this work is to involve basic characteristic possibilities of using Business Process Management in Service-Oriented Architecture. Though this approach is contemporaneously not too implemented, present dynamic era asks for application of those approaches that lead to higher business flexibility and increase in its competitive advantage. The interaction of BPM and SOA enables approach to business integration from several possible points of view. This work introduces these particular approaches and identifies their main benefits and failures. However, the aim of this work is not to define which one of presented approaches could be considered as the one of binding force. This work would rather identify a situation when the particular approach is appropriate. After introducing strategies of business integration that have been mentioned above, the work focuses on characteristic features of BPM implementation in SOA in a more detailed way. The features that are considered to be typical for technological domain are not omitted. This work also provides list of the most important benefits, hurdles, and threats following an unsuccessful BPM implementation in SOA environment. By means of this list the work provides general failures in this particular domain. Neither are contemporary trends in the business integration omitted. This work predicts some possible features of future development by using these trends in BPM and SOA implementation.

Keywords Business Process Management (BPM), Service-Oriented Architecture (SOA), business integration, Enterprise Service Bus (ESB), Business Oriented Architecture.

-v-



Obsah Úvod...................................................................................................................................... 1 1 BPM .............................................................................................................................. 2 1.1 Charakteristiky BPM a vybrané standardy.............................................................. 2 1.2 Historie BPM ......................................................................................................... 3 1.3 Pohled IT na BPM.................................................................................................. 4 1.4 Kdy je vhodné BPM zavést .................................................................................... 4 2 SOA............................................................................................................................... 6 2.1 Principy SOA ......................................................................................................... 6 2.2 Vznik SOA............................................................................................................. 8 2.3 SOA Maturity Model.............................................................................................. 8 3 Strategie dodání řešení podnikových systémů............................................................... 10 3.1 Fáze životního cyklu ............................................................................................ 10 4 Přístup k podnikové integraci shora dolu - Business driven .......................................... 13 4.1 Kroky strategie shora dolu kopírující životní cyklus ............................................. 14 4.2 Výhody a nevýhody přístupu shora dolu............................................................... 15 5 Přístup k podnikové integraci zdola nahoru − IT driven................................................ 17 5.1 Kroky strategie SOA kopírující životní cyklus...................................................... 18 5.2 Výhody a nevýhody přístupu zdola nahoru ........................................................... 19 6 Agilní strategie aneb Klíčová role vzájemné spolupráce BPM a SOA........................... 20 6.1 Kroky agilní strategie kopírující životní cyklus..................................................... 20 6.1.1 Následující kroky.......................................................................................... 22 6.2 Výhody a nevýhody agilní strategie...................................................................... 22 7 Charakteristické rysy BPM v prostředí SOA ................................................................ 23 7.1 Potřeba zmenšení rozdílu mezi podnikem a IT...................................................... 23 7.1.1 Časový rozdíl................................................................................................ 23 7.1.2 Rozdíl v přístupu .......................................................................................... 24 7.1.3 Prostor pro neustálé zlepšování..................................................................... 24 7.2 Návrh řešení BPM v SOA prostředí...................................................................... 25 7.2.1 Volný návrh služeb v kontextu BPM (Loose-coupling)................................. 25 7.2.2 Hrubý návrh z pohledu BPM (Coarse-grained) ............................................. 26 7.3 Řešení transakcí v BPM-SOA .............................................................................. 27 7.3.1 Transakce procesů ........................................................................................ 27 7.3.2 Transakce služeb .......................................................................................... 27 7.3.3 Desynchronizace procesu.............................................................................. 27 7.4 Výjimky a chyby procesů ..................................................................................... 28 7.5 Enterprise Service Bus (ESB)............................................................................... 29 7.5.1 Ne jen přeprava (transport) zpráv.................................................................. 29 7.5.2 Mnohonásobné logické úrovně ..................................................................... 30 8 SOA/BPM Governance ................................................................................................ 31 8.1 Enhanced Process-Driven Architecture (ePDA).................................................... 32 9 Benefity a překážky kombinace BPM-SOA.................................................................. 35 9.1 Spolupráce podniku a IT....................................................................................... 36 9.2 Spojení dvou celků ............................................................................................... 36 9.3 Potřeba nástrojů pro dynamické řízení procesů ..................................................... 37 10 Rysy, ve kterých se BPM a SOA doplňují ................................................................ 38 10.1 BPM..................................................................................................................... 38 10.2 SOA ..................................................................................................................... 38 10.3 Webové služby..................................................................................................... 39 10.4 Business Oriented Architecture ............................................................................ 39 -vi-



10.5 Technická realizace Business Oriented architektury ............................................. 40 11 Výzvy pro implementaci BPM-SOA ........................................................................ 42 11.1 Od modelu podnikových procesů k implementaci................................................. 42 11.1.1 Využití SOA................................................................................................. 43 11.1.2 Implementace modelu procesu...................................................................... 44 11.1.3 Odchytávání výjimek.................................................................................... 44 11.1.4 Současnost modelu ....................................................................................... 45 11.2 Výzvy pro organizaci ........................................................................................... 45 11.3 Technologické výzvy ........................................................................................... 45 11.3.1 Složitost........................................................................................................ 45 11.3.2 Technologický pokrok .................................................................................. 46 11.3.3 Podpora existujících nástrojů ........................................................................ 46 12 Největší hrozby pro aplikaci BPM v prostředí SOA.................................................. 47 12.1 Nejčastější chyby SOA implementace .................................................................. 49 12.1.1 Nadhodnocení kódu nižší programovací úrovně............................................ 50 12.1.2 Centralizace návrhu a vývoje ........................................................................ 50 12.1.3 Roztržení a nahrazení stávajícího software.................................................... 51 12.1.4 Pořizování software bez dostatečné podpory................................................. 51 13 Současné trendy ....................................................................................................... 52 13.1 Současné porozumění BPM a SOA ...................................................................... 52 Závěr ................................................................................................................................... 54 Použitá literatura.................................................................................................................. 55 Monografie ...................................................................................................................... 55 Internetové prameny ........................................................................................................ 57 Terminologický slovník ....................................................................................................... 58

-vii-



Úvod V dnešní době, kdy skloňujeme podnikové procesy každým pádem, nás může překvapit, jak málo je ve skutečnosti prosazováno procesní řízení. K tomu, aby bylo v organizaci skutečně zavedeno, je potřeba uvědomělého řízení celého podniku. Současná praxe však spíše ukazuje, že manažeři sice rádi mluví o podnikových procesech, avšak jejich řízení je jim relativně cizí. Cílem této práce však není analyzovat procesní řízení jako takové, ale popsat a ohodnotit jeho možnosti pro využití v servisně orientované architektuře. Servisně orientovaná architektura není ani tak architekturou v pravém slova smyslu, ale je spíše přístupem k její výstavbě. Architektura, kterou tento princip zastřešuje, by měla být vystavěna napříč celým podnikem. Měla by na jedné straně spojovat i tak odlišné pohledy jako má podnik a IT oddělení, a na straně druhé by měla na technologické úrovni jasně oddělit zodpovědnosti pomocí několika vrstev. Problém komunikace a sdíleného porozumění mezi podnikem a IT je velmi často zmiňovaným tématem a bylo o něm napsáno nemálo literatury. K překlenutí této mezery bylo navrženo a aplikováno několik metodik, mezi něž mohou být směle zařazeny metodiky zabývající se BPM i SOA. K tomu, aby podnikové procesy mohly být reprezentovány použitím vhodných služeb (ačkoli bychom neměli opominout, že není možné zaměňovat služby za aktivity, které jsou základním stavebním prvkem procesu), služby musí být navrženy tak, aby vyjadřovaly podnikovou logiku. Právě toto je část obou přístupů, které dosud nebylo zcela porozuměno a která nebyla doceněna. Protože dnešní doba je velmi dynamická a v průběhu života se setkáváme s řadou odlišných přístupů, není možné očekávat, že bychom mohli získat univerzální a dobré řešení, které by odpovídalo na mnohé naše otázky. Namísto toho získáváme spíše rady, avšak samotná implementace a provedení je záležitostí vpravdě individuální. Výjimkou by neměla být ani tato práce. Nebudeme se snažit o to poskytnout jednostranný pohled na věc a nebudeme tvrdit, že ten či onen přístup je ten správný. Namísto toho se v několika kapitolách podrobněji zaměříme na problémy výše načrtnuté, na které se pokusíme podívat z více úhlů pohledu.

-1/60-



1 BPM V dnešní době již nejsou podniková pravidla tolik procedurální, jako byla v minulosti, ale jsou spíše deklarativními1. V souvislosti s měnícím se podnikovým prostředím se objevily i nové přístupy, mezi nimiž byl i Business Process Management. V této kapitole se zaměříme na jeho základní charakteristiky a principy. Definice BPM: Strategie řízení a zlepšování výkonnosti podniku skrze neustálou optimalizaci podnikových procesů v regulačním cyklu modelování, běhu a měření procesu.2 BPM je porozuměním, zviditelněním a řízením podnikových procesů.3 Podnikové procesy představují sérii oddělených aktivit a kroků, na kterých se podílejí lidé, aplikace, události a organizace. BPM je popisem procesu a metodikou, která by měla pomoci podniku mapovat podnikové procesy a porozumět jejich užití napříč celým podnikem. Nestačí však proces pouze popsat, neboť to neumožňuje podniku proces reálně řídit. Skutečná hodnota plynoucí z BPM spočívá ve "zviditelnění" procesu, tedy v odkrytí kroků a zodpovědností v rámci celého procesu. Jednoduše řečeno, není-li proces mapován pomocí BPM, o průběhu procesu má informace jen participující organizační jednotka. Protože se v rámci BPM mapují nejen kroky, ale také zodpovědné osoby, vstupní a výstupní dokumenty či podpůrné aplikace, proces se stává otevřeným i pro ostatní organizační jednotky než jen pro ty zainteresované.

1.1 Charakteristiky BPM a vybrané standardy BPM nástroje podporují charakteristiky procesu, jako jsou efektivnost, výkonnost a agilnost. Aby mohly dosáhnout stanovených cílů, musí v sobě poskytovat takové prvky, které podporují: •

Možnost grafického modelování, která může být využita jak vlastníky procesu, tak modeláři, aby na jedné straně vytvořili workflow4 komponenty a na straně druhé dosáhli vyšší úrovně podnikových procesů. Procesy musí podporovat lidské zdroje, podnikové události a kroky aktivit systému.

•

Schopnost simulovat jeden nebo více podnikových procesů, aby mohla být zjištěna optimální váha jednotlivých kroků, optimální čas pro provedení kroků či v neposlední řadě zjištění slabých míst procesu, ve kterých je nutné se zlepšovat. V simulacích se používá testovacích, historických a ostrých dat, čímž je dosaženo získání většího množství informací a identifikace problémů v čase.

•

Umožnění tvorby vlastních uživatelských formulářů a reportů.

•

Možnost vytvářet podniková pravidla a implementovat je do procesních toků a rozhodnutí.

•

Framework pro integraci interních systémů s těmi externími, mezi něž zahrnujeme také standardy, standardizované technologie nebo systémy.

1

[25] KETABCHI, Farshid. - GORDON, John B. - GENDRE, Alain. Building a Real-Time Enterprise: Understanding SOA, BPM, and BRM. 2 [7] Extending the Business Value of SOA Through Business Process Management. BEA Whitepaper, s.5. 3 [9] Getting Started With BPM: An Introduction To Business Process Management. Lombardi Whitepaper, s.3. 4 workflow - stále se opakující sled aktivit -2/60-



•

Schopnost odesílat a přijímat zprávy o událostech ze strany podniku i ze strany systému.

•

Zabudovanou funkcionalitu k podchycení a řízení výkonu a indikátorů, které přímo ovlivňují výkonnost podnikových procesů a způsob, jakým jsou prováděny a monitorovány. Za předpokladu správného stanovení klíčových indikátorů je pro podnik mnohem snadnější své procesy úspěšně optimalizovat.

•

Schopnost poskytovat výsledky pro reporty, aby mohly být sledovány metriky procesů, a to za skutečného běhu procesu (tento přístup se nazývá BAM - Business Activity Monitoring). BAM analyzuje podnikový proces pomocí sledování aktivit probíhajících v základních IT systémech, které daný proces podporují5.

•

Zajištění sdíleného prostoru k ukládání všech procesů i položek, které se k procesu reálně vztahují. Procesy jsou dle určitého modelu umístěny v hierarchii procesní architektury. Mezi jednotky, které se k procesům vztahují, řadíme např. vstupní a výstupní dokumenty, které mohou být z nástrojů BPM zpřístupněny pomocí odkazů.

•

V neposlední řadě dodání nástrojů pro administraci serveru, na kterém je databáze podnikových procesů umístěna.

Hovoříme-li o BPM z pohledu podniku, neměli bychom opomenout standardy, jako jsou ISO 9000 nebo Six Sigma. •

Six Sigma. Cílem Six Sigma je zvýšit zisky eliminováním rozmanitosti a různorodosti, která brání zákaznické loajalitě. Six Sigma může být implementována na třech úrovních6: o Metriky. o Metodologie. o Filozofie. Six Sigma je metodologie, která poskytuje nástroje ke zlepšování podnikových procesů. Zvýšení efektivity procesů a snížení odchylek procesů vede ke zvýšení zisků, morálky zaměstnanců a kvality produktu.

•

ISO 9000. Je sérií standardů definovaných v 80. letech zeměmi západní Evropy jako základ pro obhájení přiměřenosti jakostní kontroly systémů ve společnosti7.

1.2 Historie BPM Předchůdce BPM datujeme do konce 80. let, kdy se objevil přístup Total Quality Managementu8. Hned za ním vyvstal na počátku 90. let nový přístup Business Process Reengineering9. Současně s objevením tohoto principu začalo vznikat několik publikací zabývajících se těmito tématy. Již tyto techniky tehdy usilovaly o zlepšení výkonu podniku pomocí měření, upravování, automatizace či dalších technik. To, proč byly tyto přístupy ve své době tolik populární, bylo dáno příslibem zajištění dramatických zlepšení výkonnosti podniku v relativně krátkém časovém okamžiku.

5

[19] PULIER, Eric. - TAYLOR, Hugh. Understanding Enterprise SOA, s. 90. [26] Six Sigma. 7 [24] ISO 9001. 8 TQM - strategie řízení podniku 9 BPR - přístup managementu k optimalizaci podnikových procesů 6

-3/60-



Nicméně po prvním boomu BPR ztratilo svou oblibu a posun v optimalizaci procesů se na nějakou dobu zastavil. Problémem těchto metodik bylo, že byly většinou založeny na ad hoc principech. Nemůžeme tedy říci, že by se jednalo o automatizaci v pravém slova smyslu. Někteří experti dokonce uvádí, že 60 - 70% projektů usilujících o procesní optimalizaci selhalo v dosažení předem stanovených cílů 10. Téměř po deseti letech po éře BPR se začalo znovu prosazovat řízení podnikových procesů, tentokrát pod pojmem BPM (Business Process Management). Z tohoto důvodu je BPM někdy označováno za "třetí vlnu"11. To potvrzují i Howard Smith a Peter Fingar ve své knize BPM: The Third Wave12. Budeme-li chtít porovnat BPR a BPM, zjistíme, že přístup k podnikovým procesům se od základů změnil. Zatímco BPR se snažilo procesy pro podnik navrhnout a optimalizovat zcela od začátku a víceméně ignorovalo současnou situaci, ve které se organizace nachází, BPM nahlíželo na stav organizace jako na důležitý a snažilo se optimalizovat procesy již fungující. Tento posun a změna chápání byla spojena s rozvojem a implementací ERP13 systémů, které byly samy o sobě navrhovány pro automatizaci a řízení běžných podnikových procesů. Proto tedy převažovala snaha procesy spíše automatizovat nežli optimalizovat a z tohoto důvodu také přístup BPM na počátku svého vzniku více než kdy jindy zdůrazňoval inkrementální změny.

1.3 Pohled IT na BPM Hovoříme-li o BPM, je třeba rozlišovat mezi pohledem podniku a pohledem IT. V tomto kontextu se setkáváme s problémy plynoucími z integrace aplikací či podnikových systémů. Ve většině případů jsou aplikace v organizaci (alespoň zpočátku) založeny na principu separátních oddělení. Principem BPM je tyto mezery v rámci procesu překlenout. Pokud bude integrace pomocí BPM realizována jen z pohledu podniku, potom bude podnik nucen provozovat podnikovou činnost takovým způsobem, ke kterému byly jednotlivé aplikace vyvinuty. V takovém případě tedy není možné řídit procesy způsobem, jakým byly vydefinovány. Řešením této situace je pohled na BPM ze strany IT. V této rovině hovoříme o nástrojích, jako jsou Workflow Management System nebo EAI14 (Enterprise Application Integration). Tyto nástroje umožňují datům, aby byla řízena a synchronizována napříč celou organizací. Problémem se však ukázalo být, že bylo velmi složité svázat aktivity zpět do vyšší procesní úrovně. Již z těchto problémů bylo jasné, že je třeba uvažovat v rovině BPM ze dvou úhlů pohledu, jak ze strany podniku, tak ze strany IT, a tyto dva pohledy spojit ve smyslu sdíleného porozumění aktivitám a zároveň je oddělit na technologické úrovni oddělující vrstvou.

1.4 Kdy je vhodné BPM zavést Složitost a náklady spojené se zavedením BPM nástroje nebo platformy by neměly být podceňovány. Ve skutečnosti BPM produkty patří mezi ty komplexní a vyžadují mnoho zkušených vývojářů a administrátorů, aby zajistili jejich úspěšnou instalaci, implementaci i 10

[14] KRAFZIG, Dirk. - BANKE, Karl. - SLAMA, Dirk. Enterprise SOA: Service-Oriented Architecture Best Practices, s.104. 11 [14] KRAFZIG, Dirk. - BANKE, Karl. - SLAMA, Dirk. Enterprise SOA: Service-Oriented Architecture Best Practices, s.104. 12 [21] SMITH, Howard. - FINGAR, Peter. Business Process Management: The Third Wave. 13 ERP - systém integrující datové zdroje a podnikové procesy 14 EAI - přístup integrace podnikových aplikací -4/60-



provoz a údržbu. Uvedeme zde nejdůležitější důvody, ve kterých je opodstatněné, aby byl zaveden přístup BPM: •

IT a podnik musí pracovat ruku v ruce. Jestliže je podnik připraven přijmout procesně orientovaný provoz na samotné podnikové úrovni, potom takový podnik musí mít definovány a dokumentovány klíčové procesy. Nadto je mnohem důležitější skutečnost, že v prostředí takového podniku bude BPM nástroj přijat jak na technologické, tak na podnikové úrovni. Více se k problému spolupráce podniku s IT vrátíme v kapitole 7.1.

•

Zužitkování šablon procesů. Je pozoruhodné, že velká část dodavatelů BPM staví své BPM platformy dle několika předloh procesů společných pro několik odlišných odvětví jako je bankovnictví, pojišťovnictví či výroba15. Ačkoli samotná definice procesu, jako je jednotlivý požadavek, se velmi pravděpodobně liší podle typu společnosti, použití předlohy jako výchozího bodu pro specifický proces může být v konečném důsledku velmi užitečné. Tento fakt se může stát důležitým bodem pro rozhodování, zda je vhodné v podniku zavést BPM, neboť to znamená skutečnost, že není nutné BPM koncepty navrhovat zcela "od nuly". Spíše se jedná o inkrementální změny prováděné nad existující šablonou. V neposlední řadě existence šablony nepřináší tak velká potenciální rizika, než jaká by hrozila v případě navrhování procesů od samotného začátku. Je vhodné poznamenat, že ani nutnost přizpůsobení šablony konkrétním podnikovým podmínkám není překážkou a v souvislosti s kompenzací rizik, která by vznikla při nepoužití šablony, jsou nevýhody šablony zcela zanedbatelné.

•

Nalezení odpovídající technologie danému problému. V otázce rozhodnutí, zda je vhodné použít BPM nástroje pro podporu určitého podnikového procesu, je nutné porozumět povaze samotného procesu. Není totiž neobvyklé, že různé typy procesů vyžadují odlišný typ aplikovaných technologií. Podnikový proces můžeme charakterizovat dvěma charakteristikami. Na jedné straně se jedná o komplexnost a dynamiku a na straně druhé o dynamiku procesu a stupeň součinnosti procesu. Obecně platí, že čím vyšší je komplexnost součinnosti procesu a čím kratší je doba, po kterou proces probíhá beze změny, tím větší roli hraje zavedení BPM přístupu16.

•

Adaptace modelu vývoje. Platforma BPM poskytuje patřičné benefity také pro procesy vývoje software, neboť nabízí celkový model pro vývoj, který odděluje podnikovou logiku od kódu na nízké úrovni.

15

[14] KRAFZIG, Dirk. - BANKE, Karl. - SLAMA, Dirk. Enterprise SOA: Service-Oriented Architecture Best Practices, s.105. 16 [14] KRAFZIG, Dirk. - BANKE, Karl. - SLAMA, Dirk. Enterprise SOA: Service-Oriented Architecture Best Practices, s.106. -5/60-



2 SOA Servisně orientovaná architektura se vztahuje k návrhu nových průřezových aplikací, které v sobě shrnují služby využívané několika existujícími systémy. Mezi její hlavní principy patří volný a hrubý návrh služeb. V této podkapitole si představíme nejdůležitější principy SOA a její charakteristiky. Definice SOA: Současné SOA představuje otevřenou, flexibilní, rozšiřitelnou a sjednocenou architekturu, která sestává ze samostatných, kvalitu služeb zvyšujících, poskytovatele rozlišujících, vzájemně spolupracujících, identifikovatelných a potenciálně znovu použitelných služeb, které mohou být implementovány jako webové služby.17 SOA může vybudovat abstrakci podnikové logiky a technologie, což vede k loose coupling18 (volně vázaného, viz níže) modelu mezi těmito doménami. SOA je vývojem od předchozích platforem, přičemž jsou zachovány jejich úspěšné charakteristiky, ke kterým SOA přidává principy podporující servisně orientovaný přístup pro podporu servisně orientované organizace. V ideálním případě je SOA standardizací podniku, ale dosažení takového stavu vyžaduje plánovaný přechod a podporu vyvíjejících se technologií. SOA umožňuje samostatným jednotkám logiky existovat autonomně, avšak ne vzájemně izolovaně. Jednotky logiky se přizpůsobují sadě principů, což jim umožňuje vyvíjet se nezávisle a přitom se řídit standardy. V rámci SOA jsou těmito jednotkami služby. Popis služby ve své nejhlubší podstatě zahrnuje název a umístění služby a zároveň požadavky na výměnu dat. Způsob, jakým služby využívají popisu služeb, ústí ve vztah, který nazýváme loose coupling - volně vázaný vztah. K tomu, aby mohly služby mezi sebou komunikovat a spolupracovat, slouží výměna informací, která je realizována pomocí frameworku, který je schopen zachovat principy volné vazby. Příkladem tohoto frameworku je výměna zpráv19.

2.1 Principy SOA V této podkapitole si představíme klíčové aspekty servisně orientovaného přístupu: •

Loose coupling (volná vazba). Služby jsou udržovány ve vztahu, který minimalizuje závislosti a vyžaduje pouze, aby jednotlivé služby věděly o sobě navzájem.

•

Kontrakt služeb. Služby zachovávají takové dohody, jaké jsou definovány jedním nebo více popisy služeb a přiřazených dokumentů.

•

Autonomie. Služby mají kontrolu nad logikou, kterou zastřešují.

•

Abstrakce. Mimo to, co je uvedeno v popisu služby, služba udržuje logiku schovánu před okolním světem.

•

Znovupoužitelnost. Logika je rozdělena mezi jednotlivé služby se záměrem zabezpečit znovupoužitelnost.

•

Schopnost skládání. Kolekce služeb mohou být shromažďovány tak, aby vystavěly složené služby.

17

[6] ERL, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design, s.54. loose coupling - pružný vztah mezi dvěma či více systémy nebo organizacemi 19 [6] ERL, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design.

18

-6/60-



•

Bezstavovost. Služba minimalizuje uchování informací specifických pro každou jednotlivou aktivitu.

•

Popisnost. Služby jsou navrhovány tak, aby byly navenek popisné, a mohly tak být ohodnocovány dostupnými mechanismy.

Po popisu základních principů SOA bychom neměli zapomenout na základní charakteristiky tzv. současného SOA20, které je rozšířenou variantou servisně orientované architektury. U současného SOA jsou uvedené základní principy zachovány či rozšířeny. Současná SOA: •

Je umístěna v jádru servisně orientované platformy.

•

Zvyšuje úroveň kvality služby: o zajišťuje ochranu obsahu zprávy a přístup k jednotlivým službám o zastřešuje spolehlivý přenos zpráv a zaručuje oznámení o chybě, nepodaří-li se přenos dokončit o nabízí transakční přístup, který zabezpečuje integritu úkolu a zaručuje mechanismus odchycení výjimek v případě, že by proces selhal

•

Je autonomní. Jednotlivé služby jsou na sobě nezávislé, čehož je dosaženo již na úrovni zpráv.

•

Je založena na otevřených standardech, které jsou charakteristické především pro webové služby a podporují myšlenku, že ke komunikaci služby nepotřebují nic jiného než znalost vzájemných popisů.

•

Poskytuje zpřístupnění služeb.

•

Podporuje spojování služeb do vyšších celků.

•

Umožňuje výstavbu architektury.

•

Podporuje základní znovupoužitelnost na několika úrovních.

•

Zdůrazňuje rozšiřitelnost.

•

Podporuje paradigma servisně orientované architektury a podnikových procesů. Služby jsou navrhovány tak, aby vyjadřovaly podnikovou logiku. BPM modely, modely entit a další mohou být reprezentovány vhodným spojením služeb. Toto je část SOA, která dosud není všeobecně uznávána ani jí není dostatečně porozuměno.

•

Implementuje vrstvu abstrakce. Při správné implementaci může být této abstrakce dosaženo jak na úrovni podnikové, tak na úrovni aplikační logiky. Tato vrstva současně poskytuje zázemí pro loose coupling mezi podnikovými a aplikačními technologiemi.

•

Umožňuje podniku uplatnit agilní přístup. V organizacích pozorujeme následující dva typy změn: o Změny v podnikové logice. Tyto změny mohou ovlivnit aplikační technologii, která ji automatizuje. o Změny v aplikační technologii. Změny mohou ovlivnit podnikovou logiku touto technologií automatizovanou.

20

[6] ERL, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design. -7/60-



Čím více závislostí bude mezi těmito dvěma částmi podniku existovat, tím větší bude prostor pro narušení a tím větší budou náklady způsobené danou změnou. •

Přístup, který se stále vyvíjí a přesto je dosažitelným ideálním stavem.

2.2 Vznik SOA Myšlenka znovupoužitelnosti se objevila již v objektově orientovaném programování, kdy byla data a funkcionalita ukládána do zapouzdřených objektů. V polovině 90. let se tento princip začal používat pro distribuované systémy. V takových případech se však ukázalo, že tento přístup má silná omezení, a právě v této době se jako důsledek objevila servisně orientovaná architektura. Problém distribuovaných objektů spočíval v nízké úrovni jejich nespojitosti (nezávislosti). Tato skutečnost vedla k nízké výkonnosti. SOA tyto problémy řeší tím, že navrhuje objekty hruběji (coarse-grained21), což vyžaduje méně častou interakci mezi klientem a serverem. Druhým problémem, který se stal potenciálním ohrožením, byl fakt, že se opětné využití distribuovaných objektů stalo díky své vzájemné závislosti velmi složité. S použitím SOA učiníme krok zpět z velmi složitého, spojitého a závisle distribuovaného modelu k méně komplexnímu, relativně hrubě nespojitému, volně vázanému komponentovému rozhraní.

2.3 SOA Maturity Model SOA Maturity Model (SOAMM) vysvětluje úrovně vyspělosti SOA v organizaci. Tento model byl publikován v roce 2005 společnostmi Sonic Software Inc22., Bearingpoint23, Systinet a AmberPoint24.

Obr. č. 1 - SOAMM - SOA Maturity Model25 21

coarse grained - hrubě navržené služby. V kontextu referuje k nespojitosti (viz Terminologický slovník). <www.sonicsoftware.com> 23 <www.bearingpoint.com> 24 <www.amberpoint.com> 25 [27] SOA Maturity Model 22

-8/60-



Jak je uvedeno na obr. č. 1, SOAMM sestává z 5-ti úrovní vyspělosti. Pro každou úroveň autoři definují nejdůležitější benefity.

26

•

1. úroveň vede organizaci převážně k nové funkcionalitě. Jako příklad architektury autoři uvádí zavedení ESB26 (Enterprise Service Bus) jako prostředníka pro propojení služeb mezi odlišnými aplikacemi a rozhraními.

•

2. úrovně může být dosaženo po úspěšném zavedení nové funkcionality na úrovni předchozí. Cílem této úrovně je dosáhnout znovupoužitelnosti služeb a definovat standardy podnikového SOA. V souvislosti s rozsahem integrovaných aplikací je největším benefitem redukce nákladů na IT a jejich kontrola. Architektura je rozšířena a poskytuje možnost definování SOA Governance. Na této úrovni je využívána funkce ESB transformovat XML zprávy pomocí XSLT.

•

3. úroveň je rozdělena na strategie 3a a 3b. Zatímco 3a je zaměřena na zlepšování vnitropodnikových procesů, 3b se zaměřuje spíše na zlepšování procesů spojených s externími partnery. Hlavním zaměřením úrovně 3a je spojení mezi businessem a IT technologiemi. Již na této úrovni je patrné, že dochází ke spojení podnikové a aplikační logiky v jednu, logiku servisní. Na příkladu architektury jsou zaváděny služby k řízení dlouhodobých procesů, které spojují architekturu s BPM.

•

Úrovně 4 může být dosaženo buď přes úroveň 3a nebo přes úroveň 3b či přes obě zároveň. Na této úrovni jsou měřeny služby v reálném čase, a proto celkovým benefitem je, že podnik může být přeměněn ze stavu "schopného reagovat na změny" do podniku v pravém slova smyslu současného. V této architektuře je uvedena existence služby zodpovědné za Business Activity Monitoring (BAM), která poskytuje managementu mechanismy monitorování.

•

Úroveň 5 poskytuje skutečnou automatizaci podnikových procesů. Podnik může být automatizován reagováním a přizpůsobováním se pomocí událostmi řízené automatizace. Ukazuje se, že spojení podniku a IT je základním faktorem úspěchu při implementaci SOA.

ESB - konstrukce architektury implementována jako middleware produkt -9/60-



3 Strategie dodání řešení podnikových systémů Každý informační systém prochází svým životním cyklem. Jinak tomu není ani u vystavění služeb, ani u optimalizace podnikových procesů. V této kapitole si tyto běžně uznávané fáze životního cyklu představíme a v souvislosti s nimi se zaměříme na hlavní strategie dodání implementovaných částí do organizací v závislosti na definovaných prioritách podniku.

3.1 Fáze životního cyklu Zaměříme se nejprve na vývoj servisně orientovaných systémů. Ačkoli se zdá, že vývoj servisně orientovaných řešení je životním cyklem srovnatelný s ostatními tradičními distribuovanými aplikacemi, hlubším pohledem poznáme, že pro řádné vystavění a umístění služeb jako částí SOA je třeba tradiční životní cyklus malinko poupravit.27 •

Servisně orientovaná analýza. V této počáteční fázi se obvykle určuje potenciální rozsah SOA řešení. Jsou mapovány potřebné vrstvy služeb a v jednotlivých vrstvách dochází k definici prvotních služeb, které by mohly představovat předběžný návrh SOA.

•

Servisně orientovaný návrh. Jakmile definujeme, co je konkrétně třeba vystavět, potřebujeme definovat způsob, jakým by měla být realizace provedena. Tato fáze životního cyklu je zejména založena na standardech, o které se opírá a svým způsobem spojuje mezi sebou konvence podniku a vlastní servisně orientované principy. Tato fáze je mimo jiné určena klíčovým rozhodnutím, která definují základní logiku vyjádřenou službami. Navržené vrstvy mohou v sobě již zahrnovat vrstvu organizační, která obvykle ústí ve formální definici podnikového procesu.

•

Vývoj služeb. Po dvou úvodních fázích věnujících se analýze a návrhu pokračuje životní cyklus fází skutečné implementace. V této fázi se především rozhoduje o tom, jaká platforma bude pro vývoj řešení použita, přičemž primárně nezáleží na typu služby. Naopak výběr programovacího jazyka a vývojového prostředí určuje fyzickou podobu vyvíjených služeb. Pro servisně orientované přístupy se často využívají technologie vystavěné na platformách .NET nebo J2EE.

•

Testování. Protože služby jsou ve své podstatě navrhovány jako komponenty znovu použitelné v předem neznámých situacích, je nutné, aby služby prošly řadou testování ještě předtím, než jsou implementovány do skutečného produkčního prostředí. Uveďme zde nyní stručný přehled toho, jak by mohla vypadat skutečná testovací sada: o Jaké typy uživatelů by mohly/měly mít ke službě přístup? o Mohou všechny služby dostát svým slibům? o Jakým typům výjimek by mohla služba čelit? Jaké podmínky by musely nastat, aby k takovému výjimečnému stavu došlo? o Do jaké míry souvisí popis služby s její sémantikou? o Rozšiřují nově upravené popisy služeb jejich původní hodnotu nebo je jen nahrazují? o Jakou složitost přináší skládání/spojování služeb? o Jak jednoduše mohou být definovány popisy služeb?

27

[6] ERL, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design, s.358. -10/60-



o Je soulad s webovými službami žádoucí? o Jaké sporné otázky týkající se datových typů může vyvolat služba? o Jsou zmapovány všechny možné aktivity i kombinace služeb? o Byly všechny procesy plně testovány? o Co se stane v případech, kdy se vyskytne výjimka v procesu? o Jsou všechny nové služby přizpůsobeny již existujícím návrhovým standardům? o Představují nové služby zákaznické SOAP 28 hlavičky? Jestliže ano, jsou potom všichni potenciální uživatelé schopni těmto hlavičkám porozumět a plně jich využívat? o Představují nové služby funkční nebo jakostní požadavky, které současná architektura nepodporuje? •

Rozmístění služeb - implementace. Fáze implementace s sebou přináší potřebu instalace a konfigurace distribuovaných softwarových komponent, rozhraní služeb a s nimi spojených produktů na produkční servery. Typické otázky, které vyvstávají během této fáze, zahrnují: o Jak budou služby rozmístěny? o Je stávající infrastruktura vhodná pro zabezpečení procesních požadavků služeb? o Jak může zavedení nových služeb postihnout služby a aplikace stávající? o Jak by měly být rozmístěny služby, které jsou využívány několika řešeními? o Jak může představení požadovaných middleware (prostředníků) ovlivnit existující prostředí? o Představují tyto služby nové verze popisů služeb, kterými je třeba rozvinout popisy verze stávající? o Jaká bezpečnostní nastavení a přístupy by měly být aplikovány? o Jak mají být služby udržovány, aby vyhovovaly jak plánovaným, tak nepředvídatelným požadavkům na rozšiřitelnost? o Jak by měl být udržován a monitorován původní systém s omezeními v oblasti výkonnosti či spolehlivosti?

•

Správa služeb. Jakmile jsou služby implementovány a rozmístěny, nastává fáze, ve které je potřeba zvážit rozmístění, řízení a kontrolu standardních aplikací. Otázky, které jsou řešeny v souvislosti s touto problematikou, jsou ve své podstatě podobné případům distribuovaných či komponentových aplikací. Mezi tyto otázky obvykle zahrnujeme: o Jak bude monitorováno využívání služby? o Jaký způsob správy verzí bude použit ke správě dokumentů popisujících služby? o Jak budou zprávy mapovány a řízeny? o Jakým způsobem budou identifikována slabá místa výkonnosti?

28

SOAP - protokol pro výměnu zpráv založených na XML -11/60-



Představili jsme si fáze životního cyklu, které reprezentují jednoduchou a přímou cestu výstavby služeb. Nyní potřebujeme z těchto jednotlivých fází vybudovat proces, který by nám umožňoval: •

přizpůsobit naše preference s ohledem na typ vrstvy služeb

•

sladit dodávky služeb pro aplikace, podnik a procesy

•

podpořit přechod ke standardizovanému SOA, přičemž by byly bez prodlení uspokojovány požadavky pro každý jednotlivý projekt

Tento poslední předpoklad je pro implementaci BPM-SOA přístupu největší výzvou. Úspěch SOA uvnitř podniku většinou závisí na rozsahu, ve kterém je standardizován a rozdělen do okruhů působností v rámci podniku a aplikací. Nicméně ve většině případů je úspěch SOA projektů odvozen od rozsahu, ve kterém řešení naplní očekávané požadavky, a to v předem daném čase a do výše předem daného rozpočtu. Abychom mohli takový problém úspěšně řešit, potřebujeme definovat strategii. Tato strategie musí být založena na prioritách organizace tak, aby zajistila potřebnou úroveň rovnováhy mezi splněním dlouhodobých cílů transformace a naplněním krátkodobých požadavků. V této oblasti se objevily tři hlavní strategie, kdy každá z nich přistupuje k řešení problému odlišným způsobem. Pojďme si tyto tři vyjmenovat: •

strategie shora dolu

•

strategie zdola nahoru

•

vzájemně kombinovaná - agilní - strategie

Tyto postupy se vzájemně liší v přístupu k prioritám a ve většině praktických otázek. V následujících kapitolách se podrobně zaměříme na všechny tři přístupy.

-12/60-



4 Přístup k podnikové integraci shora dolu - Business driven Servisně orientovaná architektura poskytuje možnost zlepšovat podnikové procesy bez nutnosti sledování IT systémů, které je podporují. Podnik, který je zaměřen na procesy, využívá výhod IT architektury ke zviditelnění procesů, neboť v takovém podniku každý proces voláním služby vyžaduje IT funkcionalitu. V této podkapitole se podíváme, jak podniková integrace probíhá, je-li tlačena "shora", tedy ze strany podniku. Cílem integrace podnikových procesů z pohledu podniku je zajistit jejich flexibilitu. Tento přístup je založen na dvou pilířích: modelech, které popisují realitu pomocí procesů a softwaru, který tuto realitu zajišťuje. Popsat proces tak, jak ve skutečnosti reálně existuje, není pro business analytika lehkým úkolem. Ke své práci potřebuje technologickou podporu, která mu umožní zakreslovat diagramy, provádět simulace a udržovat popisovaný proces aktuálním. Jen díky tomu je možné měřit efektivitu podnikových procesů a na základě naměřených charakteristik proces zlepšovat. V této oblasti je otevřeno velké pole působnosti pro přístup SOA, neboť tato architektura je schopna zajistit potřebnou přizpůsobivost a rychlou reakci na změnu v rámci podnikových procesů. Tento přístup nevyžaduje pouze, aby se podnikové procesy staly servisně orientovanými, ale požaduje rovněž nové vytvoření či nové přestavění procesního modelu společnosti. Není proto náhodou, že tento přístup je úzce spojen s existující podnikovou logikou. Přístup shora-dolů je nejvýhodnějším způsobem v případech, kdy společnost zamýšlí začít s transformací organizace a posunem směrem k SOA přístupu. Nejvýhodnějším je z toho důvodu, že zajišťuje, aby jak konzultanti, tak i architekti sdíleli stejné porozumění podniku na základě provedené analýzy hodnotového řetězce. Tato analýza je prováděna jak z pohledu podniku, tak i z pohledu IT. Uvádí se, že BPM dalších generací se bude více zaměřovat na poskytování strategické technologie umožňující spojovat hodnotové řetězce uvnitř organizace29. Analýza hodnotového řetězce se skládá z těchto základních aktivit30: •

porozumět a zachytit funkční domény (okruhy působnosti) v celé jejich šíři a zaznamenat vzájemnou komunikaci, popsat vzájemné vazby a definovat jejich spolupráci

•

podrobně popsat podnikové procesy a pečlivě zvážit místa, kde dochází k předávání vstupů/výstupů na úrovni jednotlivých aktivit

•

dostatečně podrobně popsat subprocesy

•

identifikovat služby vyšších úrovní na základě procesních aktivit

•

mapovat as-is procesy na IT systémy tak, aby byly jasně určeny hranice současně existujících informačních systémů. Analýza dané podoby IT a jejich možností pro podnikové procesy a mapování aplikačního portfolia může pomoci přesněji určit, které aplikace jsou ovlivněny přístupem a architekturou SOA a které nikoli. Neměli bychom opomenout, že taková analýza přispívá rovněž lepšímu porozumění SOA projektům a jejich rozsahu.

29

[18] Next-Generation BPM: Creating the Strategic Enterprise. Workpoint, Whitepaper. [12] INAGANTI, Srikanth. - BEHARA, Gopala Krishna. Service Identification: BPM and SOA Handshake, s.1. 30

-13/60-



4.1 Kroky strategie shora dolu kopírující životní cyklus Jak již bylo uvedeno výše, přístup shora dolu je úzce spojen s podnikovou logikou. Obvykle sestává z některých či ze všech následujících kroků: •

Krok č. 1: Definice modelů podnikových procesů Forma podnikových modelů se liší s ohledem na typ organizace, neboť logicky každá organizace bude mít procesy odvozeny ze svých obchodních domén. Obecné typy podnikových enterprise procesů31 zahrnují formální ontologii32, model entit, logický datový model, standardizovanou datovou reprezentaci architektury (často realizovanou pomocí kolekce standardizovaných XML schémat) a další typy modelů většinou spojené s informační architekturou konkrétní organizace. Některé tyto modely poskytují pohled na podnik se zaměřením na obchod, což umožňuje pohled na velmi cenné zdroje pro odvozování podnikových služeb. Kupříkladu modely entit jsou přímo spojeny s následnou definicí podnikových služeb na tyto entity vázaných. Ačkoli se tento krok zdá být v rámci celého procesu samostatným, požadavky na přesnou definici enterprise podnikových procesů mohou snadno ústit v potřebu tvorby jednoho nebo více samostatných procesů, což by vyžadovalo svůj vlastní projekt a tým lidí, který by na něm pracoval. Na druhé straně, jestliže požadovaný enterprise proces již existuje, potom tento krok může být snadno nahrazen pouze jeho identifikací.

•

Krok č. 2: Tvorba SOA V případě strategie shora dolu je tento krok často považován za část analýzy, která má za cíl zajistit dodání služeb jako takových, proto není spojena s fází servisněorientovaného návrhu.

•

Krok č. 3: Definice modelů podnikových služeb Tento krok reprezentuje tvorbu specifického typu enterprise modelu známého jako enterprise model služeb33. Tato specifikace poskytuje formální dokumentaci služeb, kde je několik služeb (v některých situacích dokonce všechny služby) definováno ještě dříve, než je započata fáze dodání služeb. Enterprise model služeb implementuje vrstvy služeb definovaných v kroku č. 2, a zakládá tak standardizovaný a vrstvený pohled na portfolio služeb.

•

Krok č. 4: Servisně orientovaná analýza V tomto kroku je prováděna analýza, která definuje sadu služeb, sjednocuje je do logicky uspořádaných skupin, určuje jejich hranice, identifikuje jejich potenciál pro opětovné využití a v neposlední řadě definuje jakýkoli předběžný kompoziční model.

•

Krok č. 5: Servisně orientovaný návrh V rámci fáze servisně orientovaného návrhu jsou mimo jiné definovány potřebné vrstvy služeb. Mezi další cíle servisně orientovaného návrhu patří určení základní sady možných rozšíření architektury, definování hranic architektury, identifikace požadovaných návrhových standardů, definice rozhraní služeb, identifikace potenciálních skladeb služeb, ohodnocení možné podpory servisně-orientovaných principů či prozkoumání podpory současného SOA.

31

enterprise proces - proces vzniklý zřetězením dílčích procesů (např. účtování, vývoj produktu...) formální ontologie - ontologie poskytující nestranný a nezávislý pohled na realitu 33 [6] ERL, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design, s.365. 32

-14/60-



•

Krok č. 6: Vývoj požadovaných služeb Služby jsou vyvíjeny s ohledem na příslušné specifikace návrhu a popis služeb vytvořený v kroku č. 4.

•

Krok č. 7: Testování služeb a jejich provozu Krok testování vyžaduje, aby všechny služby podstoupily nutné kontroly zajištění kvality. Testování služeb typicky rozšiřuje rozsah testování vyžadovaného pro automatizaci logiky, neboť na znovupoužitelných službách je vyžadováno, aby byly podrobeny testování v rámci celého rozsahu řešení.

•

Krok č. 8: Rozmístění služeb V poslední fázi životního cyklu řešení jsou služby rozmísťovány do produkčního prostředí. Předtím, než může být provedena závěrečná implementace, je potřeba identifikovat budoucí znovu využití služeb. Aby byl usnadněn násobný přístup ke službám, znovupoužitelné služby obvykle mají specifické požadavky na svůj provoz, bezpečnost či přístupnost. Tyto požadavky musí být brány v potaz a mělo by jim být v prvé řadě vyhověno.

4.2 Výhody a nevýhody přístupu shora dolu V této podkapitole se ve stručnosti zaměřím na výhody, které s sebou přináší dokumentace, definice a popis podnikových procesů:

34 35

•

architektům umožňuje lépe porozumět kontextu, ve kterém se podnik nachází, díky udržování současného stavu procesních výstupů

•

přemosťuje problematickou mezeru mezi IT a podnikovými týmy

•

předběžný seznam aktivit může být převeden na list potenciálních služeb, který je využitelný pro následnou hlubší analýzu

•

identifikace závislostí mezi aktivitami a službami. Tato identifikace je prováděna na vysoké úrovni.

•

identifikace podnikových pravidel a jejich odlišení od tzv. rozhodovacích bodů. Toto odlišení pomáhá architektům a návrhářům ztvárnit nestálé části procesů.

•

vzájemné ovlivňování odlišných činitelů napříč celou organizací

•

lepší porozumění komplexnosti organizace ve smyslu výměny zpráv

•

definování a rozšiřování hranic SOA projektů

•

zvýšení produktivity zaměstnanců a snížení provozních nákladů díky automatizaci podnikových procesů

•

zvýšení podnikové agilnosti a flexibility pomocí oddělení procesní logiky od ostatních podnikových pravidel. Toto oddělení ostře kontrastuje s ostatními formami vývoje systémů, kde je procesní logika zabudována hluboko v aplikačním kódu34.

•

zajištění kontroly současného stavu procesních výstupů na základě metrik finančních, organizačních, metrik nesplnění definovaných SLA35 (Service Level Agreement) či poměru nesouladu služeb

[17] NEWCOMER, Eric. - LOMOW, Greg. Understanding SOA with Web Services, s.222. SLA - dohoda o službě, ve které je definována její úroveň -15/60-



Ve fázi analýzy a modelování procesů je nutné nejen porozumět krokům a aktivitám, které tvoří proces, ale také identifikovat jednotlivé služby, které jsou pro daný proces klíčové. Pro identifikaci služeb a jejich definování uvnitř prostředí SOA se doporučuje postup nejprve navrhnout rozhraní a teprve potom na základě definovaného rozhraní navrhovat dané služby. V návrhu a implementaci procesů je třeba zohledňovat roli člověka, která spočívá v rozhodování na základě identifikovaných informací a využití výsledků tohoto rozhodování pro vykonávání podnikových funkcí. Ačkoli základem řádného fungování společnosti a jeho efektivního provozu jsou podnikové procesy, v mnoha případech je složité tyto procesy automatizovat a kontrolovat. Překážkami automatizace může být například požadavek na vysokou flexibilitu nebo požadavky na rozhodování. Nejsou-li tyto překážky odstraněny, dochází k tomu, že jsou klíčové procesy organizace málo flexibilní, pomalé a náchylné k chybám a jiným rizikům. Organizace, které využívají některé z řešení BPM v samotném jádru jejich SOA strategie, zaznamenávají větší hodnotu z využití služeb. Zároveň jim BPM pomáhá optimalizovat užití SOA v nejdůležitějších podnikových procesech, které přímo ovlivňují nejžádanější výkony společnosti: •

zvýšení produktivity

•

rozšíření zákaznických služeb

•

získání a udržení konkurenční výhody

•

dosažení pevných finančních zdrojů

Strategie přístupu shora dolu za účelem vystavět SOA obvykle ústí ve velmi kvalitní architekturu služeb. Návrh a parametry každé služby jsou důkladně analyzovány, jejich potenciál pro znovu využitelnost je maximalizován, stejně tak jako jejich možnosti usměrněné kompozice. Všechno toto pokládá základ vzniku standardizované a federalizované organizace, kde služby na jedné straně udržují stav přizpůsobitelnosti, zatímco na straně druhé umožňují sjednocení současné různorodosti. Překážky aplikování strategie přístupu shora dolu jsou obvykle spojeny s omezeními v podobě času a peněz. Implementace vyžaduje významnou investici do projektu analýzy, a to jak z finančního hlediska, tak i z hlediska časového.

-16/60-



5 Přístup k podnikové integraci zdola nahoru − IT driven Narozdíl od integrace tlačené ze shora (tedy ze strany podniku), IT se snaží k integraci přistupovat zdola nahoru. Spouštěcím mechanismem pro tuto strategii je integrace dat a integrace aplikací. V této kapitole se na tento přístup podrobněji podíváme a představíme si jednotlivé fáze vedoucí k úspěšné integraci. Tento přístup je zejména zaměřen na odhalování, identifikaci a využití existujících informačních aktiv. Zahrnuje analýzu na úrovni aplikačního portfolia podniku, ohodnocení možnosti znovu využitelnosti, redundanci a racionalizaci. Ve skutečnosti jsou cíle pro strategii zdola nahoru typicky redundantní podnikovou logikou, násobnými kopiemi podnikových datových entit nebo implementací již implementované podnikové logiky, avšak v souvislosti s různými produkty, což ústí v potřebu licencování, provozních nákladů, nákladů na údržbu atd36. Integrace podnikových procesů chápaná z pohledu IT se snaží vystavět dílčí procesy spojením existujících aktiv. Tento postup probíhá na základě dvou mechanismů: integrace aplikace a integrace dat. Technologie pro integraci aplikace nabízí několik přístupů. Základní integrace aplikací může být lineárního rázu směřující od jedné aplikace ke druhé. Budeme-li však chtít brát v úvahu všechny možné toky, potřebujeme specifikovat mnohem komplexnější interakci. K tomu, aby podnik pokryl všechny možnosti, potřebuje platformu pro integraci aplikací. Na nejnižší úrovni platforma poskytuje konektivitu pro komunikaci s vysokým počtem aplikací, ať už se jedná o aplikace běžící na starých či nových platformách. Na úrovni této vrstvy je třeba zajistit specifikaci úkolů, větvení podmínek i odchytávání výjimek. Mimo integraci aplikací je v podniku potřebná i integrace dat, neboť v podniku není velká variabilita datových zdrojů ničím neobvyklým. Data uchovávaná v různých zdrojích se liší svým významem vzhledem k aplikaci, která datový zdroj využívá. Sémantickou odlišnost dat můžeme uvést na příkladu zákazníka, kdy jeho data jsou uchována kupříkladu jak v billingové databázi, tak v CRM37 aplikaci. S daty zákazníka jsou v úzkém kontaktu data objednávky, která mohou být uchována jak v online databázi, tak v ERP aplikaci. Právě tato data mohou být následně tříděna a filtrována podle jednotlivých požadavků uživatelů aplikace. K tomu, aby všechny aplikace měly zpřístupněna všechna potřebná data, potřebuje podnik platformu pro integraci dat. Na nejnižší úrovni umožňuje platforma analytikům datové zdroje mapovat. V dalších krocích poskytuje plánování a optimalizaci činností, které je potřeba vykonávat promptně. Od platformy se vyžaduje, aby spojovala odlišné transakce a zároveň dodržovala stanovená pravidla pro každý datový zdroj. Aby bylo dosaženo maximální flexibility, často organizace požaduje mnohonásobné vrstvy integrace jak aplikační, tak i datové. Počet vrstev závisí na existujících zdrojích, které IT vlastní. Pokud tyto zdroje nabízí dostatečnou úroveň abstrakce, je zapotřebí pouze jednoduché obalové vrstvy, která zajistí datovou a aplikační integraci. V některých případech není dokonce tato vrstva vůbec nutná. V opačném případě některé starší balíky vyžadují synchronizaci i na té nejnižší úrovni, aby bylo dosaženo konzistentního stavu. Ve většině případů se nejedná o výše zmiňované extrémní situace, ale realita je někde uprostřed tohoto rozmezí. Jen malá část dnešních balíčků je připravena pro úspěšnou a rychlou integraci stejně tak jako většina synchronizací na té nejnižší úrovni byla již v minulosti realizována. 36

[12] INAGANTI, Srikanth. - BEHARA, Gopala Krishna. Service Identification: BPM and SOA Handshake, s.3. 37 CRM - systém pro řízení vztahu se zákazníkem -17/60-



Určujícími prvky, které determinují počet vrstev, jsou modularita a závislost. Jak modularita, tak i závislost mohou překročit hranici mezi integrací aplikací a datovou integrací. Jako příklad uveďme entitu zákazníka závisejícího na činnostech prováděných ERP nebo CRM aplikacemi. Integrační architektura tedy musí působit jako úložiště na sobě položených vrstev. Výhoda přístupu SOA spočívá v tom, že dovoluje podnikům užívat stejného paradigmatu, aniž by bylo důležité, kolik vrstev je potřebných pro konkrétní podnik, aby bylo dosaženo požadovaných služeb. Přístup zdola nahoru v zásadě podněcuje tvorbu služeb jako prostředků naplnění požadavků pro architekturu zaměřenou na aplikace. Webové služby jsou vystavěné na bázi "je-li jich potřeba" a jsou modelovány tak, aby zastřešovaly aplikační logiku tak, aby to nejlépe vyhovovalo aktuálním požadavkům řešení. Integrace je primárním motivačním faktorem pro návrh zdola nahoru, kde je potřeba využít výhody otevřeného SOAP frameworku pro komunikaci služeb často spojována s připojením služeb jako obalu pro stávající systémy.

5.1 Kroky strategie SOA kopírující životní cyklus Poté, co jsme představili základní principy a charakteristiky strategie zdola nahoru, podíváme se na kroky, ze kterých typická strategie přístupu zdola nahoru sestává38: •

Krok č. 1: Modelování požadovaných služeb aplikace Tento krok ústí v definici požadavků aplikace, které mohou být naplněny díky použití webových služeb. Typické požadavky zahrnují potřebu vystavět dvoubodové integrační kanály mezi již existujícími aplikacemi a B2B39 řešeními. Další požadavky vznikly vývojem z potřeby nahradit tradiční technologii pro vzdálenou komunikaci otevřeným frameworkem SOAP pro komunikaci. Pro řešení, která zakládají na strategii zdola nahoru, je typické, aby byly aplikační služby rovněž modelovány tak, aby zahrnovaly specifickou podnikovou logiku a pravidla. V takovém případě je pravděpodobné, že se objeví dvě vrstvy aplikačních služeb, přičemž obě budou sestávat ze smíšených a prospěšných služeb. Tyto služby klasifikované jako znovupoužitelné mohou působit jako koncové body aplikací využitelné pro účely integrace nebo mohou být sestaveny rodičovskými smíšenými službami.

38 39

•

Krok č. 2: Návrh požadovaných služeb aplikace Některé z aplikačních služeb modelovaných v kroku č. 1 mohou být dodány nákupem nebo nájmem či dokonce vytvořením automaticky generovaných zástupných služeb. Tyto služby mohou poskytovat nízkou možnost pro dodatečný návrh. Uživatelské aplikační služby potřebují projít procesem návrhu, kde jsou existující návrhové standardy využity k zabezpečení úrovně konzistence. V zásadě se návrh služeb zaměřuje na pokrytí definované podnikové logiky, přizpůsobení se principům servisně orientovaného přístupu a splnění podnikových požadavků.

•

Krok č. 3: Vývoj požadovaných služeb aplikace Aplikační služby jsou vyvíjeny podle jim náležejících popisů a specifikací pro použitelný a platný návrh.

•

Krok č. 4: Testování služeb Služby, s nimi spojené prostředí a základní logika, jsou testovány za účelem zajištění předpokladu, že procesní požadavky budou splněny. Výkonnostní a zátěžové zkoušky

[6] ERL, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design, s.368. B2B - transakce mezi podniky -18/60-



jsou často využívány k určení procesních parametrů stávajících systémů odhalených při implementaci SOA přístupu. V neposlední řadě je důležitá rovněž ta část testování, která má za úkol zajistit bezpečnostní požadavky. •

Krok č. 5: Rozmístění služeb V tomto kroku jsou jak řešení, tak i samotné služby k němu příslušející rozmisťovány do skutečné produkce. Implementační předpoklady pro aplikační služby rovněž mnohdy zahrnují výkonnostní a bezpečnostní požadavky. Služby identifikované v rámci tohoto přístupu mohou být skládány za účelem vybudovat podnikový proces. Avšak stále přispění těchto služeb k celkové možnosti znovu použitelnosti je závislé na konkrétním příkladě. Mezi příklady takových služeb patří uživatelský profil, vyhledávání apod. Tyto služby jsou v návaznosti na to součástí základních služeb důležitých pro implementaci SOA, jako jsou například služby týkající se infrastruktury nebo služby technické umístěné v jednotlivých SOA vrstvách.

5.2 Výhody a nevýhody přístupu zdola nahoru Většina organizací snažících se v současnosti vybudovat webové služby usiluje o uplatnění strategie přístupu zdola nahoru. Prvotním důvodem pro tento přístup je fakt, že organizace jednoduše přidávají webové služby ke stávajícím aplikacím tak, aby zvýšili efektivitu samotné technologie webových služeb. Architektura, do které jsou webové služby přidávány, však zůstává zpravidla nepozměněná, proto jsou principy servisně-orientované architektury jen zřídkakdy brány v úvahu. Důsledkem tohoto nesouladu je skutečnost, že pojem principu "strategie zdola nahoru" se zdá být nesprávným40. Skutečně můžeme říci, že strategie zdola nahoru není vlastně vůbec strategií. Není dokonce ani všeobecně uznávaným přístupem pro dosažení současné žádané podoby SOA. Toto je poznání, které může postihnout mnoho organizací, které se rozhodly aplikovat tento přístup za účelem vybudování servisně orientovaného modelu architektury. Ačkoli návrhy zdola nahoru umožňují účinnou tvorbu webových služeb tak, aby vyhovovaly požadavkům aplikací, implementace řádné SOA může ústit v zavádění nových standardizovaných vrstev služeb umisťovaných nad nestandardizovanými službami tohoto přístupu.

40




6 Agilní strategie aneb Klíčová role vzájemné spolupráce BPM a SOA Jak strategie shora dolu, tak strategie zdola nahoru jsou často považovány za dva extrémní přístupy. Jak je tomu i v jiných odvětvích, i zde se objevil přístup "zlaté střední cesty", v kontextu nazývaný agilní strategie. Otázkou zůstává, ve kterém bodě je nevhodnější hledat tu správnou rovnováhu mezi přístupem z pohledu podniku či strategií tak, jak ji představují IT oddělení. Skutečnou výzvou je najít takovou vyváženost mezi včleněním principů servisně orientovaného návrhu do prostředí podnikové analýzy bez nutnosti čekání a integrací technologie webových služeb do technického prostředí. Není divu, že pro většinu organizací je výhodné nahlížet na oba přístupy jako na dva extrémy, a hledat tak vhodnou "střední cestu". Toho je možné dosáhnout za předpokladu definování nového procesu, což v důsledku umožní podnikové analýze existovat souběžně se servisním návrhem a vývojem. Tento přístup známý jako agilní či efektivní strategie je mnohem komplexnější v porovnání s oběma dříve jmenovanými přístupy, neboť je nutné naplnit očekávání a požadavky dvou antagonistických strategií.

6.1 Kroky agilní strategie kopírující životní cyklus Agilní strategie sestává podobně jako oba výše uvedené přístupy z několika kroků, které jsou definovány tak, aby po jejich splnění bylo možné dosáhnout příslušných cílů strategie shora dolu i přístupu zdola nahoru. •

Krok č. 1: Analýza přístupu shora dolu Krok č. 1 se mimo jiné věnuje rozvržení nejdůležitějších podnikových procesů a identifikace aktivit, které v jejich rámci probíhají. K znázornění procesů, aktivit a vazeb mezi nimi může sloužit diagram aktivit. Od strategie shora dolu se tento krok odlišuje tím, že je věnována bezprostřední pozornost oblastem, kterým je doručení služeb prioritou. I poté, co je započat krok č. 2, krok č. 1 pokračuje dále ve své snaze dosáhnout cílů typických pro jmenovaný přístup shora dolu.

•

Krok č. 2: Servisně orientovaná analýza Zatímco krok č. 1 stále probíhá, tento krok iniciuje fázi servisně orientované analýzy. V této analýze jsou především zodpovídány otázky týkající se definice služeb, které je potřeba vybudovat a do jaké míry má být podniková logika každou službou zastřešena. Mimoto je třeba popsat funkcionalitu, kterou by měla každá služba představovat. Funkcionalita nabízená aplikacemi je představována jako služby a tyto služby mohou být ve skutečnosti reprezentovány vzájemným ovlivňováním s existujícími aplikacemi. Zároveň přitom není porušena logika, že každá jednotlivá služba je umístěna v rámci architektury služeb v jisté vrstvě. Existující aktiva mohou být typicky převedena na služby několika způsoby. Uveďme si nyní ty nejběžnější a nejpoužívanější z nich: o obalení existující funkce o obalení a nahrazení existující funkce o vytvoření nástavby služeb tak, aby bylo aplikaci umožněno pracovat na úrovni služeb -20/60-



o integrace funkce Vzhledem k velikosti analýzy, kterou je potřeba provést nejen k dokončení kroku č. 2, ale i k dokončení kroku č. 1, je vhodné, aby tomuto kroku byla věnována dostatečná pozornost a byl mu vyhrazen dostatečný časový prostor. Poté, co analýza shora dolu dostatečně postoupí, je možné začít modelovat podnikové služby tak, aby co nejlépe vystihovaly podnikový model. Toto je klíčové místo procesu. Vyžaduje odborný posudek, aby bylo možné rozhodnout, zda je analýza shora dolů již dostatečně zralá na to, aby bylo možné pokračovat v další fázi tvorby modelů podnikových služeb. Tyto úvahy musí být zváženy s ohledem na důležitost a naléhavost nevyřešených projektových požadavků. •

Krok č. 3: Servisně orientovaný návrh V této fázi jsou definovány vybrané vrstvy služeb a jednotlivé služby jsou navrhovány jako součást servisně orientovaného procesu návrhu. Tento proces servisně orientovaného návrhu si předně klade za cíl určit jádro pro architektonická rozšíření, definovat hranice architektury, identifikovat požadované standardy návrhu, vymezit rozhraní služeb či nastínit potenciální kompozici služeb. Identifikované služby jsou mapovány na jednotlivé aktivity modelované v rámci podnikových procesů. Přímá korelace mezi podnikovými aktivitami a identifikovanými službami aplikace nemůže být okrajovou záležitostí. Mapování může být ve vztahu one-to-one nebo one-to-many. Jedna služba může být rovněž mapována jen na pouhou část aktivity. Není však výjimkou, že existují i takové služby, které nemohou být mapovány na žádnou z aktivit podnikového procesu. Je důležité uvážit, že v tomto kroku usilujeme pouze o vzájemnou korelaci mezi službami na úrovni aplikace a požadovanými aktivitami na úrovni podniku.

•

Krok č. 4, 5 a 6: Vývoj, testování a rozmístění služeb Krok č. 4, krok č. 5 a krok č. 6 probíhají tak, jak byly popsány v obou dílčích strategiích výše. Nejsou tedy nepodobné standardnímu vývoji služeb a jejich předání procedurám testování a rozmisťování v rámci organizace.

•

Krok č. 7: Zatímco stále probíhá analýza shora dolu, vzniká potřeba revize podnikových služeb Tento závěrečný krok agilní strategie zahrnuje provádění pravidelných revizí všech podnikových služeb, aby bylo možné porovnat jejich návrh se současným stavem v rámci podnikového modelu. V návaznosti na tuto činnost jsou zaznamenávány nesrovnalosti a ty služby, u kterých se vyskytuje největší nesoulad, jsou znovu navrhovány tak, aby odpovídaly současné situaci. To typicky vyžaduje rozšíření již existující služby tak, aby plně poskytovala rozsah vyžadované kapacity. Je-li služba znovu navržena, je potřeba, aby znovu podstoupila standardní fázi vývoje, testování a rozmístění služby v rámci organizace. K uchování integrity služeb vybudovaných v rámci tohoto přístupu slouží koncept neměnných dohod41. Přitom je nezbytné, aby tento koncept byl striktně dodržován. Poté, co je tato dohoda zveřejněna, není myslitelné, aby byla měněna či nahrazována dohodou jinou. Pokud neústí pravidelná revize služeb v nutná rozšíření, která neukládají žádná omezení na existující dohodu, není potom nutné, aby tento krok končil potřebou zveřejnění nové verze dohody a vznesením požadavku na správu verzí.

41




Závěrečný krok by měl zjemnit definici procesního modelu tak, aby zahrnoval více subprocesů za účelem dosažení jednoznačného zobrazení vztahu mezi procesem a službou. Na druhou stranu je rovněž žádoucím dosáhnout mapování několika rozložených aktivit na jednu službu za účelem maximalizovat znovu použitelnost komponent. Nové služby mají být vytvořeny v místech, kde je podnikový proces postrádá. Konečné mapování služeb by mělo v ideálním případě znamenat one-to-one mapování mezi obchodními aktivitami a službami uloženými v aplikační vrstvě s ohledem na snížení režijních nákladů.

6.1.1 Následující kroky Poté, co je ukončena analýza a jsou identifikovány všechny služby pro prvotní přehled, na řadu přichází další výzva, která spočívá v určení rozsahu zodpovědností pro každou službu jednotlivě. Každá služba by měla mít vymezené hranice, které by popisovaly složitost a subjektivnost každé z nich, přičemž by byl brán ohled na vztah k podnikovým a IT elementům jako jsou podnikové procesy, subsystémy a případy užití. Rozhodujeme-li se o nespojitosti služeb, některé z následujících bodů bychom měli dobře zvážit: •

znovupoužitelnost •

kompromis mezi jemně strukturovanými a hrubě strukturovanými službami

•

flexibilní a znovu komponovatelné služby v jiných funkcích či doménách

•

významnost podnikové hodnoty

•

náklady na provoz služby by neměly být tak vysoké, aby ovlivňovaly výkon, efektivnost a celkové náklady na provoz sítě

6.2 Výhody a nevýhody agilní strategie Tato strategie v sobě aplikuje to nejlepší z obou dvou samostatných přístupů, neboť tyto dvě odlišné techniky kombinuje tak, aby vytvořila přístup vhodný pro realizaci SOA, která je schopna naplnit současné požadavky bez zbytečného ohrožení integrity podnikového modelu organizace i samotné servisně orientované architektury. Zatímco tato strategie naplňuje jak krátkodobé, tak i dlouhodobé potřeby, důsledek plynoucí ze zavedení tohoto přístupu zvyšuje nutně vynaložené úsilí na dodání každé jednotlivé služby. Skutečnost, že každá služba potřebuje pravidelnou revizi, opětovný návrh, vývoj a konečně i rozmístění, proporcionálně navyšuje počet služeb. Nespornou výhodou tohoto přístupu je zajištění, že tento přístup ukládá úkoly pro udržení architektury v tom smyslu, že vyžaduje zabezpečení souladu mezi existujícími službami a revidovaným procesním modelem. Dodržení tohoto postupu je nezbytné, neboť i v případě probíhajícího procesu zajišťujícího revidování služeb je organizace vystavena neustálému riziku vychýlení služeb od stávajícího modelu.

-22/60-



7 Charakteristické rysy BPM v prostředí SOA V této kapitole si představíme charakteristické rysy BPM v prostředí SOA. Zejména se zaměříme na hlavní cíle BPM, které je možné naplnit pouze v prostředí SOA, a dále zde uvedeme, jak je možné v kontextu BPM realizovat základní principy a charakteristiky architektury SOA.

7.1 Potřeba zmenšení rozdílu mezi podnikem a IT Ve své podstatě se BPM snaží o zmenšení rozdílu mezi podnikovými potřebami a schopnostmi dodávky IT. Na tento rozdíl může být pohlíženo z několika úhlů pohledu. Ve většině případů je tento rozdíl vnímán jako časové zpoždění mezi momentem definování podnikové potřeby a schopností IT zajistit takové řešení, které dané potřeby uspokojí. V jiném kontextu může být na rozdíl nahlíženo jako na rozdílné vnímání obou konceptů. V takových případech potom posuzujeme, zda jsou potřeby podniku přesně a spolehlivě převáděny do IT řešení. V neposlední řadě může být rozdíl vnímán jako prostor pro zlepšení, kdy je IT schopno monitorovat, zlepšit a zjednodušit podnikové řešení poté, co bylo prvně spuštěno.

7.1.1 Časový rozdíl Pojďme se nejprve zaměřit na časový rozdíl obou přístupů. Zatímco podnikové služby (z pohledu konceptu SOA) se mění velmi pomalu, podnikové procesy (přístup BPM) se mění velmi rychle. Hovořme jen o výběru podnikových procesů, které se mění opravdu rychle, řádově v horizontu týdnů či měsíců. Za vděčné podnikové procesy se často uvádí procesy spojené se zákazníkem, neboť tyto procesy jsou lehce aplikovatelné na většinu podniků a jsou snadno pochopitelné čtenářům. My se od tohoto postupu neodchýlíme především proto, že se na systémech sloužících pro podporu správy zákaznických dat demonstruje přístup SOA lépe než na jiných systémech. Nyní uvedeme příklad toho, jak se liší rychlost změny služby podniku od změny procesu. Vezmeme-li proces objednávky, řekněme, že v podniku bude vždy potřeba zadávat příkazy k dodání produktu/služby nebo potřeba vydávat smlouvy. Potřeba změny takovýchto služeb bude nízká a služby jako takové proto nejsou zdaleka tak flexibilní. Není to ani potřeba. Flexibilní naopak musí být podnikové procesy, které zajišťují "střet" zákazníka s produktem/službou, takovýto proces nazvěme například proces zajištění služby. Tento základní rozdíl mezi službami a podnikovými procesy přináší důsledky pro obě strany. Služby by měly být poskytovány bez ohledu na to, zda jsou v souladu s procesy a procesy by se měly zaměřit na podniková pravidla a nedávat takový význam službám. Pokud by byl tento přístup dodržován, časový rozdíl by se mohl zmenšit v několika ohledech. BPM se v průběhu času stalo páteří, která zajišťuje průběh neslučitelných služeb a opírá se o pravidla podniku. Je-li například zaveden nový produkt, nový proces může být sestaven za použití stávajících služeb a podnikových pravidel, podle kterých se tento proces bude řídit. V případech, kdy se části procesu nebo podniková pravidla mění, nástroje BPM zajistí flexibilní aktualizaci procesu a jeho znovu nastavení (nové definování). Mnoho rysů existujících nástrojů BPM je vhodných pro integraci funkcí, které by se jinak musely zákazníkům dodávat zvlášť. V současné době není problémem přidat workflow řešení do integrovaného řešení BPM. Většina BPM nástrojů rovněž umožňuje kvalifikaci pravidel tak, aby bylo usnadněno jejich opětné použití v různých modelech.

-23/60-



7.1.2 Rozdíl v přístupu Kromě časového rozdílu pozorujeme v podniku také rozdíl v přístupu či v rozdílném chápání stávající situace. BPM produkty nabízejí širokou škálu možností jak lépe spolupracovat v rámci týmu a jak pracovat s klienty. Všechny BPM produkty nabízejí možnosti pro modelování procesů tak, aby bylo dosaženo jasného grafického zobrazení a popisu procesu. Mnohé z těchto produktů dokazují, že sami uživatelé jsou schopni navrhnout a konfigurovat proces pomocí nástroje BPM. Rozdílnosti v přístupu k popisu procesů mohou být eliminovány tím, že je uživatelům umožněno, aby sami konfigurovali a nastavovali své vlastní procesy. Jedině však možnost modelovat a navrhovat procesy v rámci jednoho týmu může tyto rozdíly zcela odstranit. BPM však není čistě jen o vizuálním modelování procesů. Za touto slupkou se skrývá množství možností, které je některými BPM nástroji zpřístupněno vývojářům a jejich klientům. Způsob zpřístupnění je zajištěn pomocí rozšíření, která jsou zabudována do BPM nástrojů. Mezi takováto rozšíření se řadí různá prostředí pro definici podnikových pravidel, úložiště meta-dat, skriptovací prostředí a další. Pomocí rozšíření je možné ověřovat správnost implementovaných procesů v porovnání s požadavky na jejich průběh. Tyto nástroje jsou rovněž používány k testování správného výkonu služeb v procesech, zejména těch, které zabezpečují integritu mapování portů a správnost formátů dat mezi integrovanými SOA a BPM řešeními. BPM přináší ještě další výhody, které bychom neměli opominout: rysy workflow postavené na propracovaných organizačních modelech. Nástroje BPM jsou navrženy za tím účelem, aby podporovaly workflow požadavky BPM řešení a aby umožnily modeláři navrhnout alokaci manuálních úkolů napříč jednotkami organizace. To vytváří velkou přidanou hodnotu při pokusech snížit rozdíl v přístupu. Vývojáři i týmy modelářů mohou používat společnou základnu pravidel pro modelování. Mimoto se takto mohou návrháři vyhnout nebezpečí, že navrhnou komplexní, avšak většinou neúplné a málo flexibilní zákaznické řešení.

7.1.3 Prostor pro neustálé zlepšování Jako třetí v pořadí po rozdílu časovém a rozdílu v přístupu zde uvedeme prostor pro neustálé zlepšování. Nástroje BPM nabízejí možnosti, jak zajistit zpětnou vazbu z jednotlivých podnikových procesů, a neustále tak zlepšovat modely za účelem zajištění optimální implementace jak podnikových procesů, tak podnikových služeb. Na této úrovni hraje BPM hlavní roli jako platforma implementace zajišťující monitorování a měření kapacit, které by byly jinak neobsazené, kdyby se uvažovalo čistě jen v rovině služeb podniku. Tato role platformy řešení BPM umožňuje množství zásadních výhod. Nástroje BPM byly první, kdo jako první přišel s dostatečně silnými nástroji pro monitorování a řízení jak užití procesů, tak užití služeb. Monitorování je možné provádět na základě ad hoc a může být spojeno se SLA a rovněž může být napojeno na zpětný mechanismus směřující do BAM nástrojů (viz kapitola 1.1). Na úrovni platformy je také dobře zajištěna její rozšiřitelnost. Mnoho nástrojů BPM obsahuje v sobě zabudované prvky pro uvolnění kapacit, v případě nutnosti dokonce na několika dostupných místech. BPM řešení obsahují také účinné nástroje pro simulaci a optimalizaci, která by bez toho jinak byla jen obtížně realizovatelná. BPM zde umožňují konfigurovat úrovně zátěže, reakční časy a pravděpodobnosti, která místa by se mohla ukázat být nejužším hrdlem procesu nebo služby. Úrovně zátěže, které jsou pozorovatelné v produkci jen v době krize a ne za běžných okolností, mohou být simulovány a definovány lépe tak, aby bylo dosaženo vhodnějšího řešení pro dosažení vrcholné zátěže. Jak jsou jednou odhalena slabá místa systému, nástroje

-24/60-



BPM se dají nakonfigurovat tak, aby bylo zajištěno přidělení potřebného množství zdrojů k uspokojení těch nejnutnějších potřeb. Kromě spojování, rozdělování či novému definování procesů poskytují současné nástroje a metodologie sloužící k definici BPM nejrůznější návody, rady, podporu a přidanou hodnotu pro strategii SOA. Některé organizace již vytvořily centrální procesní týmy pro integraci procesů, které mají za úkol koordinovat strategii procesní prioritizace, automatizace a optimalizace. Stejně tak jako řídí úspěšnou implementaci BPM řešení, hrají velkou roli ve výběru a řízení SOA. Jedna z nejdůležitějších rolí procesního týmu je analýza příležitostí. Hlavní a nejdůležitější IT aktiva (např. informace o zákazníkovi, informace o stavu skladu atd.) se stávají oblastí, na kterou se zaměřuje každý tým zabývající se architekturou procesů nebo informačních systémů. Klíčovým přínosem je bezesporu procesně orientovaný pohled na analýzu zajišťovaný procesním týmem. Tento přístup způsobuje vysokou poptávku po klíčových procesech a službách a soustřeďuje se na jejich následný společný vývoj. Tímto způsobem jsou tedy příležitosti služeb identifikovány a jejich soulad s podnikovou architekturou je dopředu strategicky plánován. V návaznosti na to procesní tým řídí veškerou komunikaci týkající se vývoje služeb a jejich dostupnosti. Podnik a IT organizace by měly být informovány o současném stavu dostupných služeb a hodnotě, kterou vytváří. Kromě toho, že procesní tým řídí interní plánování služeb, musí také mít přehled o externích dodavatelích, ať už se jedná o poskytovatele služeb či jiné organizace. Jestliže zaměříme systém pro správu objednávek na verifikaci zákazníkovy důvěryhodnosti, nebudeme tuto činnost a zajištění dat přenechávat vývojářům, ale budeme velmi pravděpodobně hledat dostupné služby dodavatelů. Obdobně budeme postupovat v případech, kdy budeme chtít implementovat přepravní kvótu v systému pro správu objednávek. V tomto případě bude centrální procesní tým usilovat o nalezení rozhraní pro určení podnikové kvóty a uznávané standardy, dle kterých bude následně řídit návrh služeb pomocí nástrojů BPM. Neměli bychom opomenout fakt, že centrální procesní tým bude mít zájem na definici standardů a prototypů jak pro implementovaná řešení BPM, tak pro služby, které tyto nástroje vyvolávají. Takové výhody znamenají mnoho pro prevenci neporozumění mezi implementacemi SOA a BPM, které by je měly podporovat.

7.2 Návrh řešení BPM v SOA prostředí Návrh řešení BPM v SOA prostředí musí být vytvořen se stejnou obezřetností jako ostatní softwarové platformy. Abychom mohli vést analýzu korektně, musíme brát v úvahu všechna omezení a priority, které BPM zohledňuje. Z těchto omezení a určených priorit můžeme vyvodit hlavní rysy odpovídajícího návrhu služeb. Nad těmito omezeními leží však dvě implicitní omezení, které jsou adresné: potřeba volně spojeného návrhu v rámci BPM (loosecoupling services) a potřeba hrubého návrhu služeb (coarse-grained services)42.

7.2.1 Volný návrh služeb v kontextu BPM (Loose-coupling) V ideálních případech se volného spojování dosahuje pomocí maximálního užití open standardů jako je např. WSDL43, XML a SOAP v případě webových služeb. To je možné použít také v prostředí BPM, i když se většinou jedná o intranetová řešení, a proto se zde může často vyskytnout tendence podceňovat potřebu používat open standardy. Například i s nejlepšími záměry může být jednoduchá služba pro ověřování zákazníka nechtěně zapojena 42 43

[23] WOODLEY, Thomas. - GAGNON, Stephane. BPM and SOA: Synergies and Challenges, s.683. WSDL - jazyk popisující webové služby -25/60-



do prostředí vyžadujícího rozsáhlou bázi sdílených znalostí mezi klientem a službou. Brzy potom může dojít až k tomu, že každý podnikový proces bude mít svou vlastní vestavěnou službu pro ověřování zákazníka. Bohužel může nastat situace, kdy si budeme myslet, že se jedná o volné spojení, ve skutečnosti však půjde o vysoký stupeň propojení, který byl do prostředí implementován. Jak jsme již uvedli výše, návrháři se na design webové služby dívají celkem ze tří pohledů. Jedním z nich je pohled shora dolu, který klade větší důraz na procesy a BPM, druhým z nich je pohled zdola nahoru, který upřednostňuje služby a posledním je přístup agilní kombinující obě předchozí strategie. V dnešní době je považován za nejpoužívanější právě pohled zdola nahoru44, který se zaměřuje na mechanismus implementace a nabízí pohled na to, jak je služba připravena k použití v rámci SOA architektury. V případě strategie zdola nahoru je implementace služeb obvykle spjata s informačními aktivy. K tomu dochází zejména v případech, kdy vývojář zamění komponentu za službu a svou práci dokončí definicí třídy, spíše by se však mělo jednat o rozhraní. Tyto chyby vznikají v případech, kdy se návrháři slepě spoléhají na automatizované nástroje pro návrh služeb. Nejlepší řešení pro volně spojované služby v BPM vzniká za užití webových služeb založených na dokumentech. V těchto řešeních obsahují SOAP zprávy XML dokumenty. Primární funkce WSDL je zabalit XML zprávy. XML Schema popisuje zprávy z hlediska potřeb uživatele a minimalizuje přímé spojení mezi rozhraním služby a její implementací. Toto řešení webových služeb nabízí mnohé výhody pro BPM jako je např. snadnější asynchronní implementace nebo způsobilost přenášet ve zprávách kontext. Zatímco webové služby vystavěné nad dokumenty jsou komplexnější než jejich RPC45 (Remote Procedure Call) protějšky, je důležité poznamenat, že jejich komplexnost leží v infrastruktuře vhodné pro posílání zpráv, a není tak přímo začleněna do funkcionality služby. Je-li jednou vystavěna infrastruktura pro výměnu zpráv, klesají dodatečné náklady nutné na implementaci přírůstků vystavění webových služeb založených na dokumentech. Několik prostředí může nabídnout SOA založené na open standardech. BPM řešení jsou často spojena s patentovanými a/nebo zákaznickými řešeními. Nicméně, je-li to možné, počet dat, které vyžadují být sdíleny mezi BPM klientem a službou, by měl být minimalizovaný. V opačném případě hrozí opětovné použití a dlouhověkost v rámci BPM.

7.2.2 Hrubý návrh z pohledu BPM (Coarse-grained) Termín hrubého návrhu (coarse-grained) je velmi často používán k popisu SOA a její nejčastější implementace, webových služeb. BPM více než jiné technologie vyžaduje právě tento popis podnikových procesů. V rámci BPM se prosazuje přístup, že nejlepší rozhraní služeb reprezentuje celkovou funkci podniku, a není proto nutné, aby vzájemná interakce mezi klientem a službou byla více podrobná. U příkladu rezervace v typickém objednávkovém procesu by tento přístup byl aplikovatelný a realizovatelný tak, že by služba ověřovala nejen dostupnost požadovaného zboží, ale rezervaci by provedla pro každou položku, a to vše v rámci jednoho kroku. V případě, že by tomu tak nebylo, docházelo by k rozdělení procesu do několika oddělených kroků, které by zvlášť ověřovaly a poté rezervovaly, a to každou jednotlivou položku zvlášť, což by znamenalo přílišnou rozdrobenost pro robustního klienta BPM.

44 45

[23] WOODLEY, Thomas. - GAGNON, Stephane. BPM and SOA: Synergies and Challenges, s.684. RPC - vzdálené volání procedur (tzn. z jiného místa než je jejich úložiště) -26/60-



Je obvykle doporučováno, aby služby byly navrhovány bezstavově, tedy aby všechny informace byly přenášeny v rámci jednoho volání služby. To umožňuje lepší vyvážení zátěže a jednodušší překlenutí krizových míst. Je složité představit si, že by existovalo mnoho služeb, které by bylo možné synchronně implementovat. Skutečně by bylo složité nalézt takového prostředníka, který by byl schopen vyřešit nevyužitý časový prostor v rámci verifikace, rezervace a následné objednávky položek ze skladu. Pokud budou hrubě navržené služby klíčovým momentem pro realizaci asynchronní implementace, pak nebude nutné, aby docházelo ke špatné implementaci pro klienta BPM. Nicméně, asynchronní návrh musí být pečlivě zvážen a definován tak, aby jeho aplikací byla v prostředí BPM zabezpečena dostatečná spolehlivost výměny zpráv bez obtíží při jejich rozšiřitelnosti.

7.3 Řešení transakcí v BPM-SOA Transakce jsou výzvou pro procesy s dlouhým průběhem, ať už se jedná o délku z hlediska běhu procesu nebo z hlediska času. Standardy pro transakční chování služeb a pro automatizované procesy jsou buď u zrodu služeb, nebo neexistují vůbec. Přístup BPM i nadále spočívá na starších službách, které byly vystavěny dříve s cílem budoucí akceptace standardů. Pro efektivní implementaci je typická nutná potřeba a složitost poskytování spolehlivé a bezpečné podpory transakcí v automatizovaných podnikových procesech a v podporovaných službách. V případech, kdy standardy nejsou dostupné, je potřeba přistoupit k alternativnímu řešení - takovému, které je schopno zachytit všechny výjimečné stavy a zajistit včasné dokončení end-to-end procesů. To nevyhnutelně ukládá břímě na design služby i na BPM. Nicméně jestliže již byl jednou návrh služby proveden, je mnohem vhodnější ho nyní použít než vytvářet snadno desynchronizovatelný podnikový proces. Ještě předtím, než se zaměříme na diskuzi o nových technologiích návrhů služeb a procesů, měli bychom objasnit, co se rozumí pod klíčovými pojmy, jako jsou transakce procesů, transakce služeb či desynchronizace procesu.

7.3.1 Transakce procesů Transakce procesů nabízí příležitosti pro dokončení nebo vrácení kroků automatizovaného podnikového procesu založeného na end-to-end prvcích. Jestliže kupříkladu transakce začne procesem pro řízení objednávek a následně nebude smlouva o objednávce schválena v procesu schvalování smlouvy, potom může být snadno transakce prvotní rezervace navrácena zpět tak, aby se zboží, které bylo původně plánováno pro objednávku, stalo opět dostupným.

7.3.2 Transakce služeb Způsobilost organizace provozovat servisně orientované transakce spočívá v tom, že klient může snadno dokončit nebo naopak navrátit výsledek probíhající služby. K tomu, aby mohly procesy podporovat transakce, je nezbytně nutné, aby transakce podporovaly služby, jež jsou na procesy úzce navázány. Ve výše uvedeném příkladě podpory transakcí by měla služba pro rezervaci položky zboží požadovat podporu transakcí: tedy možnost dokončení transakce nebo její vrácení zpět.

7.3.3 Desynchronizace procesu Bez podpory transakcí je možné proces a služby, které ho podporují, desynchronizovat, což může mít nedozírné následky. Předpokládejme, že systém pro zadávání objednávek je v některých místech slabý a že objednávka, která do něj byla zadána, se vztahuje na položku, která již není na skladě. Proces řízení objednávky je již v plném proudu, zákazník očekává, že zboží, které si objednal, mu bude zanedlouho doručeno, avšak ze skladu dorazí zpráva o -27/60-



zamítnutí požadavku. Instance procesu se v tomto případě dostala do stavu desynchronizace s jednou z podpůrných služeb.

7.4 Výjimky a chyby procesů Existuje řada příčin výjimek procesů, stejně jako existuje řada nástrojů, jak tyto výjimky účinně řešit nebo jim předcházet. Jestliže návrháři již implementovali spolehlivý systém vzájemného posílání zpráv, potom chybami, které mohou nastat, mohou být jednoduše podnikové výjimky, např. selhání ověření zákazníka (zákazník není solventní). V takovém případě by mělo BPM řešení obsahovat změny a aktivity, které ukončují proces řízení objednávek. Nejedná-li se to takovýto případ, potom je podnikový proces špatně navržen. V jiných případech by mohl sporný bod vzniknout tam, kde služba vrací výjimku, která není určitá, označili bychom ji například jako výjimku jiného typu. To by nám zpočátku mělo napovědět, že s řízením výjimek služeb není něco v pořádku. Nicméně BPM řešení by mělo poskytovat mechanismus, který by umožňoval vyvarovat se takovýmto nežádoucím ukončením procesů. To by mohlo být provedeno například převedením výjimky do workflow pro manuální zpracování. Manuálním zpracováním jsme poté schopni zajistit možnost pro nové zpracování procesu a jeho opětné nastartování. V neposlední řadě se v systému může objevit chyba, která je systémová. Jsou to například výpadky webové vrstvy nebo nedostupnost serveru pro vzájemné posílání zpráv apod. Ovšem i takovýmto chybám je možné se vyhnout a takový mechanismus, který by toto zajišťoval, by mělo poskytovat právě BPM. Je-li například na skladě zaznamenána objednávka, ale proces řízení objednávky je předčasně ukončen z důvodu systémové chyby, podnik je vystaven riziku, že bude na skladě evidovat objednávku na zboží, které nebude nikdy odesláno zákazníkovi. Jak bylo zmíněno výše, existuje důvod, proč se vyhnout přerušení automatizovaných procesů uprostřed jejich průběhu, a to jak z hlediska podnikových procesů, tak z pohledu podpůrných služeb. Uvážíme-li složitost implementace transakčního chování, existuje několik možností, jak dovést proces do jeho řádného konce. Ať bude dokončení jakékoli, mělo by uspokojit požadavky transakčního prostředí na konzistenci a zároveň by mělo zachovat BPM a podpůrné procesy synchronizované. V některých případech se užívá techniky tzv. vyrovnávacích transakcí. Například BPMN46 (Business Process Management Notation) samotné v sobě takovýto přístup obsahuje. Stručně řečeno, protože podpora transakcí ve službách není příliš známá a obvyklá, model BPM může být navržen tak, aby vyvolával službu, která by vracela výsledek některého předchozího kroku. Ve své podstatě se jedná o "natvrdo napsaný" rollback. V příkladu řízení objednávek můžeme uvažovat stav, kdy je na skladě zaznamenána objednávka, ale tato objednávka samotná nemůže být dokončena. V takové situaci by mělo řešení BPM umožňovat, aby mohlo být provedeno opětovné vyvolání služby. Je možné, aby řešení BPM bylo navrženo tak, aby potlačovalo chyby provozních zaměstnanců a aby tyto chyby byly posouzeny a řešeny manuálně spíše než automaticky. Toto je však řešení, které se implementuje až v poslední řadě. Mnohdy je vhodnější ukončit end-toend proces, zanechat IT zdroje v nekonzistentním stavu a spustit proces řešení výjimečných stavů. Přeci jenom přenechání problémů k manuálnímu řešení není vždy tou nejlepší volbou. Pracovníci oddělení provozu potřebují ke své práci nástroje, kterými by danou manuální práci mohli provádět. Vedle těchto nástrojů to může být dále také přístup k datům, které se vztahují 46

BPMN - grafická notace pro popis podnikových procesů -28/60-



k procesu, na jejichž základě mohou vývojáři aktualizovat proces za jeho běhu nebo vyvolat službu, s jejíž pomocí by mohli znovu provést synchronizaci procesu.

7.5 Enterprise Service Bus (ESB) Potřeba oddělit přístup podniku od přístupu IT na technologické úrovni může být realizována aplikací ESB, který poskytuje jak konceptuální, tak technický základ pro BPM-SOA integraci. Konstrukce ESB je typicky implementována technologiemi kategorie middleware produktů, které jsou většinou založeny na uznávaných standardech. ESB ve své podstatě poskytuje abstraktní vrstvu vystavěnou nad systémem pro předávání zpráv v podniku. V dnešní době se setkáváme s tím, že většina poskytovatelů ESB řešení vyvíjí ESB tak, aby bylo možné včlenit do něj principy SOA. K tomuto účelu využívají principy BPM. ESB jako takové je chápáno jako zprostředkovatel zpráv mezi jednotlivými službami. Neboť agilní strategie může být stejně tak nazvána jako strategií posílání zpráv mezi službami, měli bychom na tomto místě věnovat pozornost právě implementaci ESB. Jak bylo uvedeno výše, ESB poskytuje jak konceptuální, tak technický základ pro podnikovou integraci založenou na BPM-SOA základech. Zároveň zastřešuje každou vrstvu SOA architektury, a chrání ji tak od nežádoucího narušení, které by mohlo být způsobeno změnami v jiných vrstvách. Z koncepčního pohledu podnik, resp. BPM určuje, které podnikové služby potřebují toto zajištění a IT zabezpečuje jejich přesun pod ESB. Ve skutečnosti ESB provádí mnohem více než je jen přeprava zpráv, ESB aktivně zprostředkovává komunikaci mezi službami tak, aby jejich spolupráce byla efektivní. ESB ve své podstatě představuje prostředníka, který současně nabízí spolehlivé, flexibilní spojení služeb a efektivní oddělení od změn v implementaci služeb. ESB nezprostředkovává komunikaci jen pro základní podnikové služby, ale zajišťuje ji na několika úrovních tak, že každá logická jednotka, počínaje základními funkcemi a pokročilými podnikovými aktivitami konče, může z tohoto zprostředkování získat výhody. Ve skutečnosti ESB nenahrazuje potřebu podnikových procesů nebo nástrojů pro integraci aplikací. Je vhodné využívat sadu best practices, které nás snáze navedou, kdy použít ESB přímo a kdy je lepší využít jeden z dalších nástrojů za účelem vzniku nové služby, která bude napojena na ESB.

7.5.1 Ne jen přeprava (transport) zpráv Vzájemná spolupráce mezi službami nevyžaduje jen komunikační kanál k výměně zpráv. Ve skutečnosti umožnění výměny zpráv je druhotnou funkcí. Primárním úkolem ESB je zajišťovat spolupráci. Základním principem je vytvořit takovou vrstvu, která bude jednoduše oddělovat zadavatele služeb od jejich poskytovatelů. Bez této izolace by každý zadavatel věděl příliš mnoho o možném poskytovateli, že by se vzájemná spolupráce služeb brzy stala rigidní. Namísto toho ESB zprostředkovává spolehlivou a hladkou spolupráci mezi službami. Díky tomu, že ESB je zprostředkovatelem, je možné definovat pro přepravu vlastní protokol. Jestliže zadavatel používá ke komunikaci JMS47 (Java Message Service) a poskytovatel HTTP protokol, ani jeden z nich by neměl zaznamenat rozdílnost těchto protokolů, bude-li mezi nimi vystavěn ESB se svým komunikačním protokolem. Bude-li tento protokol k dispozici, pak může služba využívat takových typů přepravy zpráv jako je MQ (Message Queuing) nebo dokonce emailové protokoly. Skutečností zůstává, že doručování zpráv tvoří pouze špičku ledovce. Co se stane v případě, kdy zadavatel a poskytovatel použijí odlišné verze formátu zprávy nebo formátů odlišných standardů? V takovém případě je ESB schopen automaticky 47

JMS, MQ - technologie pro výměnu zpráv v rámci procesu nebo vlákna -29/60-



transformovat zprávy i v průběhu jejich přenosu. Ze strany ESB je spolupráce zajištěna a od tohoto bodu záleží na službách samotných, zda porozumí sémantice rovnocenných zpráv. Další oblastí, ve které by mohlo docházet ke komplikacím v rámci spolupráce služeb, je oblast bezpečnosti. Každá služba může využívat jiný bezpečnostní model a řídit se odlišnými bezpečnostními standardy, jako je například aplikování ochrany integrity. Zatímco jedna služba bude zajišťovat integritu na úrovni transportu zpráv pomocí protokolu HTTPS, služba druhá bude využívat technologii podpisů na úrovni zpráv. ESB může využívat své pozice k tomu, aby zajistila rovnocennou ochranu napříč těmito omezeními stejně tak, jako může předávat vzájemnou identitu služeb tak, že každá z nich může definovat své vlastní kontroly přístupu. V návaznosti na to může ESB implementovat bezpečnostní politiku společnosti. Směrování založené na obsahu dovoluje podniku přímo směrovat zprávy od zadavatelů k poskytovatelům a opírat se přitom o charakteristiky, jako je zákazníkova zeměpisná poloha, riziko transakce nebo hodnota objednávky. Centralizované zaznamenávání činností, výstražných oznámení a odchytávání výjimek, které poskytuje ESB, dává podniku kompletní povědomí o spolupráci služeb.

7.5.2 Mnohonásobné logické úrovně Základní atomické podnikové služby jsou jen jednou z mnoha logických vrstev, do kterých ESB přináší přidanou hodnotu. V předchozím textu jsme diskutovali o tom, jak podnik této hodnoty dosahuje pomocí rozpadu podnikových procesů a jak hodnoty dosahuje IT prostřednictvím shromažďování technických služeb. Jak vyšší procesní úrovně, tak i nižší technické úrovně mohou získat výhody ze zavedení ESB. Nad úrovní atomických služeb podniku poskytuje ESB flexibilitu podnikovým procesům. Prvotní dekompozice procesu nám poskytne znovu použitelné jednotky, které jsou všechny spojeny pomocí ESB. V případě, kdy nastane nutnost změny v procesu nebo je potřeba ho inovovat, analytik tuto změnu snadno zaznamená pomocí nového návrhu modelu procesu. ESB následně usnadní nové vazby mezi znovu použitelnými jednotkami. Tato schopnost přizpůsobit se přináší do podniku flexibilitu, otevřenost vůči změnám a možnost řídit podnik pomocí procesů efektivně. Pod úrovní atomických služeb poskytuje ESB podniku flexibilitu technickou. Hledání alternativních IT zdrojů, přidávání nové logiky i zvyšování integrace, to všechno se stává jednodušší s použitím ESB. Protože ESB dokáže směrovat požadavky k odpovídajícím verzím služby, vývojáři mohou vytvořit nové kapacity bez přerušení stávajících spojení, což usnadňuje správu verzí a podporu přecházení na vyšší verze. Stejné směrování kapacit umožňuje hladce vkládat nové služby před služby stávající, a dosahovat tak výrazné přidané hodnoty. Lepší transakční a bezpečnostní integrace i integrace výjimek může být zajištěna pod vrstvou bez přerušení spolupráce služeb. Zatímco jako koncept je ESB páteří flexibility podnikové integrace, ve skutečnosti se jedná o jedinečnou pomůcku dostupnou napříč vrstvami.

-30/60-



8 SOA/BPM Governance S vývojem obou přístupů a rostoucí oblibou implementace BPM v SOA prostředí vyvstala i potřeba definovat určitá pravidla pro řízení této architektury. Tato definovaná pravidla tvoří celou metodologii, kterou nazýváme Governance. Tak jako jiná řešení, i SOA/BPM vyžaduje, aby byl řízen metodologií zabývající se otázkami, jak jsou aplikace a další IT aktiva vybudována, rozmisťována a řízena s ohledem na zpřístupnění služeb. Potřeba governance je pro SOA/BPM přístup nezbytná a obecně platí, že čím robustnější je implementované řešení, tím komplexnější musí být role a mechanismus governance. Navrhnout a zavést governance opatření není jednoduché, ani není otázkou krátkého období. Mimoto samotné prosazení governance se ukázalo být velmi obtížným, avšak i tyto překážky zcela vyvažují riziko, které s sebou přináší SOA/BPM přístup bez uplatňování governance. Ačkoli neexistuje žádná všeobecně uznávaná definice SOA/BPM Governance (kontroly), můžeme ji definovat následovně: SOA/BPM Governance upřesňuje práva pro rozhodování a přehled zodpovědností, aby podnítila žádoucí chování v kontextu SOA a BPM. To se skládá z vedení, organizační struktury a procesů, které řídí a kontrolují organizaci za cílem udržet a rozšířit její strategii a cíle. Toho dosahuje právě využitím metodologie a nástrojů SOA a BPM48. SOA/BPM Governance v zásadě odpovídá na tři klíčové otázky: 1. Kdo rozhoduje a zadává 2. které SOA a BPM záležitosti jsou důležité 3. podle kterých rozhodnutí a procesů? V této definici je brán ohled jak na čas návrhu (tedy čas rozhodování), tak i čas běhu (výkon procesu). Adaptace řádného modelu governance by měla brát v úvahu fakt, že přístup kombinace BPMSOA by měl podporovat myšlenku sblížení podniku a IT. Proto úspěšné implementace vyžadují soulad mezi návrhem procesu, IT architekturou a aplikacemi. Ve stejném okamžiku je důležité definovat podnikovou entitu, která by měla vlastnit a zodpovídat za řešení BPMSOA49. Důvodem, proč je uplatňována adaptace modelu BPM-SOA governance, je mimo jiné předejití hrozbě, aby nedocházelo k duplicitě služeb v rámci několika projektů. S aplikováním governance je řízen životní cyklus služeb v rámci organizace a zajišťuje jednak zmiňovanou eliminaci vzniku duplicit, a rovněž zajišťuje dlouhou životnost služeb. Jestliže budeme předpokládat, že služby budou znovu využívány a implementovány v řádu desetiletí a ne let, je nevyhnutelné, aby řádný management služeb sledoval, zda tyto služby stále přináší podniku přidanou hodnotu. Do struktury governance by měly být zahrnuty následující důležité prvky50:

48

[22] STRNADL, Christoph F. Bridging Architectural Boundaries Design and Implementation of a Semantic BPM and SOA Governance Tool, s.2. 49 [13] KAMOUN, Faouzi. A Roadmap towards the Convergence of Business Process Management and Service Oriented Architecture, s.5. 50 [12] INAGANTI, Srikanth. - BEHARA, Gopala Krishna. Service Identification: BPM and SOA Handshake, s.8. -31/60-



•

identifikace a popis jednotlivých artefaktů (služeb, podnikových procesů, aktivit, zdrojů, rolí atd.)

•

zapojení výkonné moci podniku do definování zodpovědností služeb a jejich poskytování a dostupnost v rámci podniku

•

definování, spojování a řízení služeb

•

podporování o organizace musí mít nástroje pro SDLC51 (Systems Development Life Cycle) o místo pro uložení artefaktů spojených se službami

•

prostředky pro dynamické volání služeb

•

možnosti měření a hodnocení služeb (např. zda jsou zachovány definované standardy a podmínky)

•

mechanismy pro reporting (výkaznictví) a analýzy, které podporují proces neustálého zlepšování a procesní optimalizaci

•

skupina zodpovědná za podnikovou architekturu by měla ověřovat, zda každý projektový požadavek je ohodnocen pro znovu využití příležitostí ve fázi vývoje či zrodu myšlenky: o v užití existujících služeb o k identifikaci potenciálních budoucích služeb o k poskytování pravidel pro aplikace v obou předchozích bodech

Má-li organizace výše uvedenou podporu podniku i IT, potom může využívat výhod agilní strategie pomocí znovu využití napříč projekty. Bez výše zmiňované podpory není SOA schopna dosáhnout agilní úrovně, a to bez ohledu na kvalitu vlastních služeb či metodologii jejich identifikace.

8.1 Enhanced Process-Driven Architecture (ePDA) Rozšířením modelu PDA52 - modelu procesně řízené architektury - dosáhneme zachycení všech důležitých vrstev architektury, a dostaneme tak tzv. rozšířený model ePDA (Enhanced Process-Driven Architecture). Jak uvádí Ch. F. Strnadl, původní PDA model spočíval na povrchní vrstvě postačující k přemostění podniku a IT53. Musíme připustit, že bylo nutné přidat dodatečnou vrstvu ke zlepšení IT kontroly. Nad vrstvou existujících IT systémů a infrastruktury rozeznává ePDA čtyři koncepčně nezávislé vrstvy zdůrazňující odlišné elementy zralé architektury SOA zahrnující implementaci BPM, která užívá jak BPMS (Business Process Management Systems), tak WfMS (Workflow Management Systems). Vedle těchto nezávislých vrstev zobrazených horizontálně, pozorujeme také vrstvu vertikální, která zmiňované nezávislé vrstvy spojuje. Jedná se o "kontrolní/řídící vrstvu" (Governance Tier). Tento diagram zachycuje dva podstatné rysy SOA/BPM Governance, kterými jsou:

51

SDLC - proces vývoje software, informačního systému PDA, ePDA - architektura nahrazující podnikovou logiku logikou procesní 53 [22] STRNADL, Christoph F.: Bridging Architectural Boundaries Design and Implementation of a Semantic BPM and SOA Governance Tool, s.3. 52

-32/60-



•

které činnosti jsou umístěny na dané vrstvě, ať už se jedná o činnosti v průběhu návrhu nebo za běhu procesu

•

jak jsou odlišné činnosti propojeny mezi sebou, a to nejen v rámci jedné vrstvy, ale i napříč celou architekturou

Obr. č. 2 - Rozšířený model procesně řízené architektury (ePDA)54

Na základě definice a modelu ePDA definuje SOA/BPM implementace následující požadavky pro zavedení holistického přístupu SOA/BPM Governance. Tyto požadavky se vztahují jak k času návrhu, tak i k času běhu procesů. •

identifikace a soupis prvků (např. služeb, podnikových procesů, činností, zdrojů, rolí atd.)

•

hledání a lokalizace kapacit (za běhu toto rovněž zahrnuje detekci volných zdrojů a nevyužitých služeb)

•

zpřístupňování služeb, jejich navazování a řízení procesů do jejich konce

•

podpora služeb SOA architektury a životního cyklu procesu

•

prostředky dynamického volání služeb

•

rozšiřitelný datový model (tj. možnost přidávat nové uživatelem definované typy prvků do stávajícího modelu)

•

klasifikace prvků v rámci uživatelem definovaného názvosloví

54

[22] STRNADL, Christoph F. Bridging Architectural Boundaries Design and Implementation of a Semantic BPM and SOA Governance Tool, s.3. -33/60-



•

vazby mezi prvky z jedné vrstvy architektury na prvky ve vrstvě jiné

•

možnosti skladování (ve smyslu poskytování datových úložišť)

•

mechanismus upozorňování pracovníků participujících na SOA/BPM Governance

•

možnosti ověřování (např. dodržování definovaných standardů a politik)

•

definování politik, monitorovací a měřící mechanismus

•

obecná administrativní hlediska zahrnující evidenci nebo monitorování SLA (Service Level Agreement)

•

reportování a analýza podporující průběžné zlepšování a optimalizaci procesů

-34/60-


9


Benefity a překážky kombinace BPM-SOA

Pro to, aby se prosadil jakýkoli koncept, je potřeba, aby byly známy jeho výhody a nevýhody. V případě, kdy je prosazována kombinace dvou odlišných přístupů ve vzájemné součinnosti, to platí dvojnásob. Proto se v této kapitole zaměříme na nejdůležitější benefity a překážky plynoucí z implementace BPM do SOA prostředí. V posledních letech bylo na BPM a SOA nahlíženo jako na nástroje umožňující vývoj podniku. Tyto nástroje by organizaci umožňovaly stát se lépe přizpůsobivou změnám díky větší flexibilitě a znovupoužitelnosti, což by následně vedlo ke snížení nákladů a zvýšení efektivnosti.55 Kdybychom vycházeli čistě z těchto předpokladů, mohli bychom uvažovat, že v případě, kdy bychom zkombinovali oba přístupy, BPM a SOA by měly potenciál umožňující podniku automatizovat a optimalizovat podnikové procesy a zároveň by umožňovaly IT vyvíjet a řídit flexibilní systémy a aplikace stojící na složitých a různorodých technologiích. Naneštěstí jsou však BPM a SOA dva odlišné přístupy. Jednou z překážek, která stojí v cestě dosažení požadované flexibility, je problém specifikace přesné úrovně spojitosti služeb. Na jedné straně SOA služby s malou nespojitostí znesnadňují návrhářům vybudovat účelné aplikace. Na druhé straně služby s vysokou nespojitostí jsou lépe ovladatelné, neboť mohou být lokalizovány a znovu použity vhodně pomocí přiřazených metadat. Nicméně vysoká nespojitost snižuje stupeň flexibility výsledné aplikace. Je tedy důležité, aby vývojáři SOA v aplikacích navrhli takovou úroveň spojitosti služeb, která by nejlépe vyhovovala potřebám komponent na podnikové úrovni. BPM je převážně záležitostí managementu, kde uplatňuje podnikovou strategii a podporuje myšlenku, že můžeme modelovat podnikové procesy ve smyslu end-to-end procesů. Na druhé straně SOA je přístup k vývoji systémů, který staví a dodává znovu použitelné služby tak, aby je mohly rozdílné aplikace sdílet ve smyslu loose couplingu a vzájemné spolupráce. Zároveň se SOA snaží o lepší uspořádání podnikových procesů a jejich napojení na protokoly služeb, související aplikace a softwarové komponenty. Zatímco na BPM je nahlíženo jako na přístup řízený podnikem, SOA koncept je poháněn IT zdroji a existujícími aktivy. BPM pohlíží na procesy odshora dolů a snaží se znovu využívat existující procesní model společnosti. V přístupu BPM je rovněž podstatná orientace na řízení projektů a měření efektivnosti procesů pomocí naměřených hodnot metrik KPI56 (Key Performance Indicator). Na druhé straně SOA přistupuje k architektuře od spodu nahoru a ve svém přístupu využívá znovu použitelných již implementovaných služeb. Úspěšnost aplikovaného přístupu měří pomocí metrik, jako jsou logická konzistence, snadnost integrace nebo výše nákladů nutných na změnu. Navzdory výše zmiňovaným rozdílům je implementace BPM v SOA součinným a účinným nástrojem pro vypořádání se s výzvami, které přináší měnící se podnikové prostředí a potřeba snižovat náklady při současném zvyšování efektivity. SOA usnadňuje rozšíření BPM, pomáhá mu dosahovat flexibility pomocí loose coupling infrastruktury. Potom mohou být procesy modelované BPM nástroji snadno a rychle implementovány architekturou SOA. Na druhé straně BPM poskytuje SOA silné obchodní případy a usnadňuje bližší spojení mezi podnikem a IT. Když kombinujeme tyto dva přístupy dohromady, BPM a SOA požadují, aby podnik implementoval podnikové procesy jako služby a BPM nástroje jako servisně orientované aplikace. Tyto BPM nástroje budou poskytovat výstupy v podobě servisně orientovaných 55

[13] KAMOUN, Faouzi. A Roadmap towards the Convergence of Business Process Management and Service Oriented Architecture, s.1. 56 KPI - metrika pro měření splnění cílů organizace -35/60-



metadat, které budou následně přímo zpracovávána architekturou SOA jako servisně orientované aplikace. Ve svém základu umožňuje spolupráce BPM a SOA podniku stát se přizpůsobivějším ke změnám, a to díky flexibilní architektuře SOA. Klíčovým konceptem stojícím za SOA je myšlenka udržování služeb a aplikací tak, aby byly snadno znovu použitelné či snadno upravitelné. Není pochyb, že výhody BPM a SOA mohou být využívány oběma přístupy vzájemně, a to nezávisle na sobě. Ve skutečnosti může být BPM efektivně aplikováno bez přispění SOA v případě, kdy by se spoléhalo na vlastní infrastrukturu. Jak však organizace a její podpůrná IT infrastruktura roste, časté změny týkající se služeb a procesů se stávají nezbytností. To je právě místo, kde SOA a s ním spojené standardy ulehčují koordinaci a problémy integrace, a umožňuje tak, aby BPM řešení mohlo zůstat v dynamickém prostředí organizace. To je možné díky technické schopnosti integrační SOA platformy poskytnout BPM volnou vazbu mezi podnikovými aplikacemi a integračními systémy, a odstraňuje tak vazbu mezi návrhem procesů a implementací služeb. Tato nezávislost umožňuje zanést změny do aplikací a procesů, aniž by se narušila integrační technologie, což snižuje provozní náklady a urychluje tvorbu procesů a jejich modifikaci. Z výše uvedených důvodů tedy dává smysl využívat kombinace BPM a SOA jako holistického konceptu na úrovni celé organizace. Oba tyto přístupy zohledňují a umožňují znovupoužití a mohou být potenciálně přizpůsobeny dynamickým potřebám konkurenčního prostředí. Kombinace BPM a SOA pomůže při tvorbě služeb, které se stávají znovupoužitelnými napříč celou organizací a které jsou dostupné pomocí web technologií. Oba přístupy rovněž podporují loose coupling šířením interních a externích aplikací napříč distribuovanou technologickou platformou. Toto usnadnění by mohlo redukovat náklady na vývoj a provoz aplikací, zatímco by se zvyšoval čas pro obchod. Podle výše zmiňovaných výhod by se dalo uvažovat, že vzájemná spolupráce BPM a SOA je jen otázkou času. Ve skutečnosti tomu tak zcela není a cesta pro spolupráci není nikterak hladká a stále čeká na další vylepšení, která by ji usnadnila. V návaznosti na to identifikujeme a analyzujeme hlavní překážky zabraňující růstu integrovaného BPM-SOA řešení na trhu.

9.1

Spolupráce podniku a IT

BPM představuje posun v podnikové agilnosti, čehož dosahuje pomocí zaměření na zlepšování procesů, k čemuž využívá sdílenou sadu nástrojů. BPM podporuje hlubší spolupráci mezi business analytiky, kteří identifikují a definují procesy, a vývojáři IT, kteří implementují integrované procesy a služby. Toto propojení však vyžaduje uvědomělý management, který by prosazoval uplatňování moderních technik BPM. Ačkoli implementace BPM v prostředí SOA na jednu stranu podnik a IT sbližuje, po technologické stránce umožňuje jejich čisté oddělení pomocí oddělující vrstvy. Jedním z největších benefitů SOA je, že umožňuje nahrazení funkcí, které jsou nyní vykonávány interně službami, které jsou vykonávány obchodními partnery. Nejedná se zpravidla o end-to-end procesy, ale o izolované služby, které mohou být provozovány méně nákladně. BPM v prostředí SOA takové míchání služeb v rámci procesů umožňuje.

9.2

Spojení dvou celků

BPM a SOA byly tradičně nabízeny odlišnými poskytovateli řešení. Se vzrůstající součinností obou metodologií, poskytovatelé BPM identifikovali potřebu přijmout SOA služby, aby mohli

-36/60-



poskytovat více standardizovaný a modelově řízený přístup k BPM. Na druhé straně poskytovatelé SOA našli v BPM silný hnací motor, který je příslibem sblížení podniku a IT. Rostoucí zájem o BPM-SOA řešení dal podnět vzniku širokému spektru protokolů a nástrojů, které bohužel nejsou vždy vzájemně kompatibilní. Jako usnadňující prostředek pro BPMSOA konvergenci se stalo přijetí technologických standardů, které: •

umožňují architektuře být přenositelnou a nezávislou na jednotlivých poskytovatelích nebo technologiích (např. hardware, operační systém nebo softwarové prostředí)

•

umožňují hladkou integraci kompatibilních nástrojů a procesů v reálném čase, a to mezi heterogenními vývojovými prostředími

Pojďme se nyní zaměřit na standardy SOA. Bez základních standardů SOA (jako jsou např. ESB, BPEL nebo XML) by nebylo možné vyvíjet na základě modelů v nástrojích BPM, a BPM samotné by se tak stalo pomalým, nákladným a neefektivním. Zajistit spolupráci mezi standardy podnikových procesů (např. BPMN a BPEL) je pro dnešní vývojáře velkou výzvou, neboť oba tyto standardy původně nebyly navrženy tak, aby vzájemně kooperovaly. Tento zásadní problém zpomaluje konvergenci BPM-SOA, neboť absence spolupráce zanechává některé nedostatky, které je třeba řešit ještě před modelováním procesu či jeho optimalizací. Očekává se, že spolupráce se bude do budoucna zlepšovat a standardy budou více a lépe přijímány a implementovány za účelem vyvinout jednotné prostředí. Tato výzva počítá s relativní složitostí BPM/SOA standardů. Pravdou však zůstává, že první společnosti, které přicházejí s implementací BPM/SOA řešení čelí nárůstu nákladů na implementaci rozdílných standardů.

9.3

Potřeba nástrojů pro dynamické řízení procesů

Při modelování reality pomocí monitorování podnikových procesů nestačí pouze spoléhat se na nástroje orientované na dobu návrhu tak, jak tomu je u většiny BPM produktů.57 Pro úspěšné zavedení BPM-SOA řešení je nutné poskytnout nástroje, s jejichž pomocí je možné upravovat proces za jeho běhu, kdy je zachycena jeho skutečná podoba. Takové nástroje umožňují jak automatické provedení změn v aplikacích na základě změny v reálném procesu, tak i změnu v procesu na základě aplikační či kompoziční změny.

57 [13] KAMOUN, Faouzi. A Roadmap towards the Convergence of Business Process Management and Service Oriented Architecture, s.5.

-37/60-



10 Rysy, ve kterých se BPM a SOA doplňují V této kapitole si uvedeme charakteristické rysy, které přináší kombinace BPM-SOA přístupu. Protože je tento přístup často spojován s implementací webových služeb, nevynecháme zde ani je a uvedeme, jak všechny tyto tři technologie zlepšily nedostatky dřívějších přístupů.

10.1 BPM •

Zatímco první aplikace BPM inklinovala k zaměření se pouze na jednu oblast (ať už se jednalo o modelování, EAI, správu dokumentů nebo další), pozdějším vývojem BPM systémů bylo již dosaženo širší funkcionality, kterou je možno využít v širokém spektru aplikací.

•

Dnešní BPM systémy již nemusí poskytovat technologii pro integraci tak, jako tomu bylo zpočátku. Tyto technologie jako je integrace na úrovni databáze, systémů či aplikací vyžadovaly mnoho dodatečného kódování, což způsobovalo křehkost a zranitelnost BPM systémů. Dnes jsou technologie zapouzdřeny díky SOA, která poskytuje dodatečnou vrstvu abstrakce, jež odděluje aplikační a technologickou vrstvu od BPM systému.

•

Dřívější BPM systémy definovaly své vlastní formáty a techniky reprezentace podnikových procesů. V současnosti WS-BPEL58 poskytuje standard pro kompozici služeb a provoz služeb.

•

Stejně jako BPM systémy definovaly své vlastní formáty pro reprezentaci procesů, tak také poskytovaly formáty pro reprezentaci dat na úrovni procesů a techniky pro jejich manipulaci, mezi nimiž byla například pravidla pro validaci a jejich transformaci. Dnes jsou tyto formáty nahrazeny široce uznávaným standardem XML pro definici podnikových dokumentů a pro výměnu informací. Široká obliba XML je dokazatelná také množstvím technologií, které ho podporují, jako je například XPath, XSLT, XQuery59 nebo XHTML.

10.2 SOA •

Původní technologie využívané pro účely SOA architektury (např. CORBA60, J2EE, WebSphere MQ61) byly svázány s technologickou platformou a bylo složité vystavět architekturu na platformě nezávislou. Služby implementované užitím webových služeb jsou nezávislé na platformě, což znamená i jejich nezávislost na operačním systému, na aplikační platformě a dalších zprostředkovatelských technologiích.

•

Dřívější technologie současně neposkytovaly dostatečně silnou podporu pro modelování dat na úrovni služeb a podporu pro manipulaci s daty (např. aplikace validačních pravidel a transformace). Tento nedostatek je dnes kompenzován rovněž technologií XML, která je bohatším a výraznějším přístupem k modelování dat.

•

Výše zmiňované technologie rovněž neposkytovaly podporu pro kompozici služeb, jejich provoz a výkon. Tuto nedostatečnou funkcionalitu dnes poskytuje WS-BPEL. Na technologické úrovni je patrna souvislost mezi WS-BPEL, WSDL a SOAP, neboť

58

WS-BPEL - jazyk pro specifikaci procesu založený na webových službách XPath, XQuery - dotazovací jazyky založené na XML 60 <www.corba.org> 61 <www-306.ibm.com/software/integration/wmq> 59

-38/60-



v minulosti nebylo možné, aby se proces spoléhal na tyto standardy odděleně, a proto byly vzájemně propojeny pro blízkou spolupráci. •

V neposlední řadě tyto původní standardy neposkytovaly dostatečnou rozšiřitelnost pro podporu alternativních transportů či alternativních datových systémů. Tyto nedostatky jsou opět kompenzovány již jmenovanými standardy WSDL, SOAP a WSBPEL.

10.3 Webové služby •

Pro webové služby nebyly dosud vystavěny žádné pevné základy pro architekturu. To kontrastuje s faktem, že uživatelé webových služeb získávají výhody ze silného zaměření na architekturu, které je charakteristickým rysem SOA.

•

Nesrovnalosti napříč specifikacemi vedou k velkým problémům na úrovni samotného provozu. Tento častý fakt je řešen rozšiřující se profilací specifikace webových služeb tak, aby byla vylepšena slabá místa, jako je provoz a aby byl snížen počet nesrovnalostí a nejednoznačností.

•

Základní standardy pro webové služby (SOAP, WSDL) nejsou schopny v plné míře zajistit kompletní platformu, což je dnes řešeno rozšířeními standardů, které jsou schopny poskytnout všechny klíčové nástroje pro usnadnění vytvoření jednotné a kompletní platformy webových služeb.

10.4 Business Oriented Architecture V otázce, jak zlepšit podnikový proces, mají jak podnikové (business) týmy, tak IT týmy mnoho otázek, které je nejprve potřeba zodpovědět. Mezi tyto otázky zahrnujeme otázky z obou zmiňovaných oblastí (z pohledu podniku i z pohledu IT) a jsou to otázky například: Jak vypadá podnikový proces dnes? Jaké jsou cílové výkonnostní požadavky pro jeho zlepšení? Kdo představuje kterou aktivitu? Kde v procesu jsou slabá místa? Jaké změny v současném procesu by znamenaly zvýšení efektivnosti? Jaké možnosti potřebují podnikoví manažeři pro skutečné řízení procesu? Jaké informace jsou od existujících systémů vyžadovány? Jaké události proces ovlivňují? Jaké informace potřebuje proces vnést do současných systémů? Je pochopitelné, že všechny tyto otázky je třeba zodpovědět předtím, než je možné dodat uspokojivé řešení. Na obrázku č. 3 je ukázáno, jak taková architektura může ve skutečnosti vypadat. Komponenty ve spodní části obrázku označené jako IT komponenty jsou ve své podstatě elementy SOA architektury. Současně s pohledem na obrázek uveďme, čím SOA přispívá do společné architektury: •

SOA poskytuje architekturu IT skupinám, což umožňuje klasifikaci dat napříč datovými skladišti

•

SOA poskytuje vrstvu abstrakce, která odděluje služby specifické pro systém. Tyto služby jsou poté mnohem snadněji použitelné a znovu použitelné.

•

SOA poskytuje silný technický základ pro zlepšování procesů.

•

SOA poskytuje nástroje, které mohou technické týmy využít pro výstavbu takových služeb, které implementují podnikový proces.

V tomto bodě však technické týmy potřebují definovat vstup od svých podnikových protějšků. Mezi tyto vstupy patří informace ohledně toho, která událost je začleněna, kdo potřebuje a užívá specifickou službu a kdy. Ve stručnosti je potřeba určit, jak jsou tyto služby -39/60-



organizovány a používány k řízení zlepšování procesů, a to je vstup, který je očekávaný od BPM.

Obr. č. 3 - Business Oriented Architecture62

Podívejme se nyní na tu část architektury označenou jako podnikové komponenty. Nástroje v této vrstvě musí být navrženy tak, aby byly využitelné těmi uživateli, kteří jsou poté schopni definovat, co je potřeba udělat pro to, aby daný podnikový proces byl zlepšován. Dále se od BPM nástrojů očekává, že umožní uživatelům posun přímo a hladce od návrhu procesu ke skutečnému procesnímu řízení a nakonec až k analýze, která by měla vést k následné optimalizaci procesu. Nejlepší BPM nástroje umožňují přechod mezi analýzou, návrhem a řízením bez ztráty kontextu. K definici aktivit uvnitř procesů využívají uživatelé BPM nástrojů reálných produkčních dat, a mohou tak přímo řídit instance procesu, simulovat průběh procesu, měřit jeho výkon a zaznamenávat nejslabší místa. Co je však důležité a neměli bychom opomenout, je fakt, že v okamžiku implementace změny BPM poskytuje takový model procesu, který je využitelný oběma stranami. Tento srozumitelný model je základním kamenem komunikace a porozumění potřebnému pro skutečné a úspěšné zlepšení procesu.

10.5 Technická realizace Business Oriented architektury Pro realizaci podnikově orientované architektury využíváme v podstatě tří základních typů architektur, které popíšeme v této podkapitole. •

Vrstvená architektura. Vrstvená architektura je vystavěna ze softwarových elementů podobných podlaží budovy. Každá tato vrstva představuje komponentu nabízející odlišnou funkcionalitu a podílí se na celkovém výkonu systému. Tato architektura je tedy strukturou, která zapouzdřuje odlišné úrovně systémové abstrakce. Ve vrstvené architektuře je podstatná obousměrná interakce mezi vrchními a spodními vrstvami.

•

Distribuovaná architektura. Distribuovaná architektura zastává princip oddělení funkcionality do odlišných softwarových komponent a jejich rozptýlení v rámci celé sítě. Jak jsou tyto autonomní komponenty provozovány současně, poskytují

62 [10] GILBERT, Phil. A Business Oriented Architecture: Combining BPM and SOA for Competitive Advantage, s.4.

-40/60-



dosažitelné řešení organizačních problémů. Existuje mnoho důvodů, proč je vhodné rozdělit softwarovou logiku do menších částí. Hlavním důvodem je umožnit vyšší stupeň znovupoužitelnosti komponenty či služby. •

Infrastruktura a architektura prostředníka. Aby bylo možné distribuovat zprávy, a přispívat tak k transformaci dat a protokolů, odkazují se podniky na infrastrukturu a na princip architektury prostředníka. Tradiční servisně orientované přístupy poskytují mechanismus pro transport, transformaci, distribuci a komunikaci mezi spotřebitelem a službou. Tyto čtyři principy se staly základními kameny této architektury63. Mezi nejznámější mechanismy patří prostředníci principu SOA, kteří zajišťují bezpečný přenos zpráv či transformaci dat a protokolů. Další známou technologií je například ESB (Enterprise Service Bus, viz kapitola 7.5) nabízející asynchronní metody pro doručení zpráv.

63

[4] BELL, Michael. Service-Oriented Modeling: Service Analysis, Design, and Architecture, s.181. -41/60-



11 Výzvy pro implementaci BPM-SOA Chceme-li do organizace implementovat jakýkoli strategický přístup, potom musíme vědět, jaké výzvy bude tato implementace přinášet. Jinými slovy potřebujeme vědět, jak bude implementace náročná, a vyplatí-li se nám to. Ve své podstatě podporuje BPM-SOA strategie opakovaný přístup neustálého zlepšování, kde jsou procesy a základní služby vylaďovány pro optimalizaci výkonu. Pro dosažení větší rozšiřitelnosti jsou služby a procesy rozmnožovány, a to jak co do počtu, tak co do verzí. Jestliže převládající BPM a SOA nástroje nenapomáhají naplnit požadavky na rozšiřitelnost, potom se stane řízení velikosti podnikových procesů a služeb zmateným. Největší výzvy v implementaci přístupu BPM-SOA směřují na IT oddělení. Tou největší výzvou je jistě cesta od BPM modelu podnikového procesu v současném stavu k implementaci v informačním systému.

11.1 Od modelu podnikových procesů k implementaci Vezmeme-li běžný model podnikového procesu, představuje nám sled odlišných po sobě jdoucích kroků a zároveň zobrazuje mezi těmito kroky vazby a popisuje jejich typ. Na takovém modelu jsou vyznačeny vstupy a výstupy, kterých produktů a služeb se to týká, a v jakém pořadí. Dříve než je model předán IT specialistovi, musí být odsouhlasen business analytikem a vlastníkem procesu či jiným uživatelem, který se na procesu podílí. Nebývá výjimkou, že modelovaný proces není hned zpočátku úplný. Když se model předá vývojáři, začíná fáze implementace z pohledu podnikových procesů a fáze návrhu z pohledu informačních technologií. Může nastat situace, kdy se zjistí, že model reálně obsahuje pouze některé větvě průběhu procesu a že některé větve v modelu zkrátka zohledněny nejsou, neboť není jednoduché do procesu zaznamenat všechny výjimečné a speciální stavy. V takovém případě nezbývá nic jiného než celý proces vzít a znovu společně definovat tak, aby odpovídal i všem výjimkám, které mohou v jeho průběhu nastat. Pro automatizaci procesů je totiž nezbytné, aby byly modelovány všechny možné stavy, neboť není možné, aby automatizovaný proces reagoval na dané podněty, nebude-li mít nastalou situaci předem definovánu. Mimo skutečnost, že model procesu často nezohledňuje všechny přípustné stavy, se může vývojář setkat i se situací, kdy informace poskytované modelem jsou neúplné či zcela chybějící. Budeme-li chtít kategorizovat typy chybějících či neúplných informací, můžeme je zhruba rozdělit do tří skupin64:

64

•

Aktivity procesu nejsou v dostatečném stupni rozpadu. Takovou aktivitou rozumíme aktivitu, která je procesně nadřízena několika aktivitám podřízeným, které podrobněji specifikují možné stavy, ve kterých se proces nachází. Samotná nadřízená aktivita nenese takovou informaci o specifikaci podmínek, a proto je nutné této aktivitě přiřadit ještě odpovídající nižší vrstvy. Jako příklad uveďme aktivitu, kterou pracovně nazveme "vytvoření požadavku". Nebudeme-li však specifikovat, o který požadavek se konkrétně jedná či do které skupiny požadavků spadá, není to pro implementaci dostatečně úplná informace.

•

Posloupnost souvisejících a na sobě závislých aktivit. Některé aktivity procesu na sobě vzájemně závisí. Není nic neobvyklého, je-li možno jednu aktivitu provádět pouze za předpokladu úspěšného dokončení aktivity předchozí apod. Pokud nejsou závislosti v

[5] BRAHE, Steen. BPM on Top of SOA: Experiences from the Financial Industry, s.7. -42/60-



modelu popsány explicitně, není možné implementovat tok procesu v kontrolovatelné podobě. •

Chybějící informace. Ve své podstatě se dá říci, že se není možné vyhnout nebezpečí, kdy některé podstatné informace budou přehlídnuty jak business analytikem, tak i informačním architektem. Architekt nezvažuje data, která jsou nutná pro volání služby či aktivity spojené s uživatelským rozhraním. Oba tyto typy aktivit vyžadují data, která nemusí být nutně přítomna a která je nejprve nutné získat z jiných zdrojů. Na chybu se obvykle přichází až v okamžiku, kdy vývojář zjistí, že není možné volat danou službu, neboť jí chybějí vstupní data. Dalšími často chybějícími informacemi jsou informace o vstupních datech nutných v rozhodovacích bodech procesu. Pro potřeby implementace nestačí, aby architekt popsal prostým textem pouze to, o čem rozhodovací bod je, ale je nezbytné znát popis a uložení dat nutných na vstupu.

Společným důsledkem všech výše zmiňovaných nedostatků modelů procesů je skutečnost, že implementace automatizace procesu nemůže pokračovat do té doby, než dojde k řádnému přepracování modelu procesu a novému definování jeho toku. V neposlední řadě tyto komplikace zvyšují nejen náklady na implementaci, ale rovněž prodlužují dobu, po kterou vývoj probíhá.

11.1.1 Využití SOA V návaznosti na problémy plynoucí z definování věrného obrazu reality v modelu procesu musí vývojář čelit rovněž možným komplikacím z pohledu systémové integrace. V mnoha případech proces spojuje systémy z jednotlivých oddělení, přičemž tyto systémy nejsou zdaleka vzájemně kompatibilní. Mimoto je klíčové správně navrhnout všechny nové softwarové komponenty a koncipovat je jako služby, aby byly dostupné ze všech systémů. Podobně jako u problematiky BPM i zde můžeme definovat tři základní charakteristiky toho, ve kterých případech může během implementace dojít k problémům65:

65

•

Umístění služeb a dokumentace. V podniku probíhají tisíce a tisíce různých operací a je vcelku obtížné identifikovat přesnou lokaci jedné konkrétní služby. Tento problém pramení mimo jiné z absence dokumentace, která buď není dostatečně podrobná, nebo v některých případech zcela chybí. Jedním z možných řešení pro podnik by bylo založit jakousi společnou bázi informací o službách a rovněž by tato báze byla úložištěm veškeré dokumentace, která je ke službám vztažena.

•

Standardy služeb. Většina služeb, které jsou integrovány v rámci jednoho workflow, jsou pojmenovávány a následně identifikovány na základě jmenných konvencí a dalších pravidel definovaných poskytovatelem služeb. Namísto pojmenovávání služeb dle jejich funkcionality se většinou dává přednost pojmenování systémovým jménem. Tento způsob pojmenování samozřejmě vede k tomu, že není možné službu identifikovat a správně ji zařadit jen dle jejího názvu, který o ničem nevypovídá.

•

Nespojitost služeb a jejich znovupoužitelnost. V některých případech může dojít k situaci, kdy služby, které je potřeba vyvolat, jsou buď příliš obecné, nebo příliš specifické, že je nelze v danou situaci použít. Nespojitost je třeba řešit definováním služby jiné, přesnější, která je schopna shromáždit všechna potřebná data a následně vyvolat výše jmenovanou službu obecnější. Takováto služba musí být definována oddělením, které je za její vykonávání odpovědné.

[5] BRAHE, Steen. BPM on Top of SOA: Experiences from the Financial Industry, s.8. -43/60-



11.1.2 Implementace modelu procesu Idea dosažení MDD66 (Model Driven Development) je docílit toho, aby bylo možné transformovat modely přímo do kódu, ale současné komerční nástroje pro modelování i vývoj aplikací neposkytují dostatečnou flexibilitu, která by umožňovala tyto transformace přizpůsobovat. Během implementování modelu procesu jako workflow tedy hraje významnou roli sám vývojář, který model čte, interpretuje a ručně transformuje do zdrojového kódu. Jedná se o stále se opakující a dlouhotrvající proces, který skýtá velkou náchylnost k chybám. Nejprve vývojář zakresluje každý úkol v procesním modelu do modelu implementace. Často jeden procesní krok odpovídá vyvolání služby, pracovnímu úkolu vykonávanému buď manuálně, nebo automatizovaně. Následuje definování organizačních standardů pro vývoj aplikací a implementaci workflow s ohledem na monitorování provozu a odchytávání výjimek. Určitý mechanismus pro monitorování provozu může být skrze worklow využit všemi systémy k logování informací o stavu a výkonu. Pro každé vyvolání služby nebo úkolu je implementován jiný mechanismus, který musí obstarat možná systémová i podniková selhání. Během implementace vyvolávání služeb či úkolů je vykonávána opakovaně stále stejná práce. Protože se jedná o stejné vzorce, stejné postupy i stejné typy informace, nejedná se o práci složitou, za to však časově náročnou a náchylnou k chybám. V neposlední řadě bychom neměli pominout nebezpečí, že se vývojáři nebudou do detailu držet podnikových standardů, což ústí ve snížení kvality implementace.

11.1.3 Odchytávání výjimek Tak jako je tomu u tradičního programování, i podnikové procesy musí brát v úvahu mechanismus odchytávání výjimek. Výjimky, které mohou nastat, rozdělujeme logicky do dvou hlavních kategorií: výjimky podnikové a výjimky technické. Jako první se podívejme na výjimky podniku. Takové výjimky nastanou v případech, kdy volaná služba skončí chybou. Důvodem takto vzniklé výjimky bývá chyba ve vstupních datech, nesplnění vstupních podmínek a další vnitřní podmínky způsobující nesprávný běh služby. Tyto typy chyb jsou rozpoznány v procesech, které vrací specifické návratové hodnoty z volané služby. Tyto návratové hodnoty musí být známy vývojářem, který následně započne chybu řešit. Druhým typem chyb jsou chyby technické, které se mohou objevovat hned na několika místech procesu. K chybě může dojít kupříkladu již při přiřazování dat z jedné proměnné do proměnné druhé, což se provádí ještě před voláním služby. Potřebná data pro přiřazení do proměnných jsou brána z databáze. Ačkoli je tato funkcionalita poháněna samotným procesem, spojení s databází může být přerušeno z důvodu pádu systému, což následně způsobí vznik výjimky, která musí být ošetřena procesem. Ošetření výjimek je klíčové pro návrh systému, neboť nebylo-li by toto zajištěno, hrozilo by nebezpečí, že by se instance procesu mohla dostat do neplatných, nedefinovaných a neidentifikovatelných stavů. Říká se, že na psaní jakéhokoli programu nejdéle trvá, než se odchytí a ošetří všechny možné výjimky. Stejně tak jako je nebezpečné neošetřit výjimky u každé aplikace, je tomu tak i u procesů, které mohou skončit v neplatném stavu, ze kterého se v nejhorším případě nemohou snadno dostat a je třeba hlubšího systémového zásahu.

66

MDD - využívání modelů jako základních artefaktů -44/60-



11.1.4 Současnost modelu Během první fáze životního cyklu workflow spolupracují vývojář a architekt na synchronizaci modelu a kódu. Mnoho informací o výsledné podobě musí být definováno na obou stranách. Avšak v jistém okamžiku se změny začnou implementovat jen na straně kódu bez úpravy modelu a některé technické dokumentace jsou vytvářeny mimo proces. Původní model se začne více a více odchylovat od současné implementace, až se stane v podstatě neužitečným a je chápán jako návrh jakéhosi fiktivního či ideálního stavu. Mnoho problémů popsaných výše je typických pro vývoj všech softwarových řešení a netýká se jen přístupu BPM-SOA. Jak již bylo uvedeno, chybějící a nepřesné informace jsou problémem ve všech modelech vytvořených nejen pro účely vývoje informačního systému. Rovněž ošetřování výjimek bylo vždy složitým a časově náročným úkolem. To, co zůstává specifické pro přístup BPM-SOA je nespojitost služeb a problém jejich znovupoužitelnosti. Služby musí být vyvíjeny tak, aby byly znovu použitelné napříč celou organizací, a to jak v současnosti, tak i v budoucnosti. To vyžaduje adekvátní úroveň spojitosti, dokumentaci a respektování standardů.

11.2 Výzvy pro organizaci Některé z výše zmiňovaných výzev jsou spojeny přímo s organizačními záležitostmi. Bývá obvyklé, že zapojené části podniku, které se mají podílet na implementaci přístupu BPM v SOA, jsou v dané oblasti nováčky. Protože jak modelově řízený, tak servisně orientovaný přístup návrhu a vývoje systémů je relativně nový, musí se kromě organizace jako takové přizpůsobovat i samotní vývojáři. Z tohoto důvodu potom ve vývoji hraje důležitou roli existence vzdělávání, best practices a kontrola ze strany podnikové, procesní i systémové architektury. Hlavní výzvy plynoucí pro organizaci z implementace BPM v SOA prostředí jsou: •

Definovat a zhodnotit služby, zajistit jejich znovupoužitelnost a alokovat náklady.

•

Přizpůsobit přístup SOA pro metodologie vývoje software používaných v rámci organizace.

•

Navrhnout základní infrastrukturu a vybrat technologie, které podporují SOA architekturu.

•

Zajistit shromáždění služeb a jejich zapojení do podnikových procesů.

•

Vypořádat se s nedostatky zkušeností s implementací SOA.

11.3 Technologické výzvy Velkou část možných problémů plynoucích z aplikovaných přístupů tvoří technologické výzvy. V této kapitole se zaměříme na nejčastější z nich.

11.3.1 Složitost K tomu, aby byla vyvinuta efektivní a úspěšná implementace, je nutné znát mnoho technologií. Mezi tyto technologie a standardy patří například WSDL, XML, XPath, BPEL, nebo Java. Mimoto je třeba mít znalost o složitých konceptech jako je například řízení transakcí a je nutné znát způsob, jakým jsou tyto koncepty využívány ve workflow. Jak jsme již uvedli výše, je nezbytné mít přehled o principech ošetřování výjimek, logování aplikace, specifických organizačních vzorcích a standardech.

-45/60-



11.3.2 Technologický pokrok Technologie, které si kladou za cíl podporovat SOA a BPM jsou ještě stále v rané fázi vývoje. Kupříkladu BPM, které je chápáno velkou změnou v technologii, je však technologií ne příliš dozrálou. Více se problematikám spojeným s technologickým pokrokem budeme věnovat v kapitole 13 (Současné trendy).

11.3.3 Podpora existujících nástrojů Stále existuje značná mezera mezi modelem podnikového procesu a skutečnou implementací v podobě workflow. Komerční nástroje, které se v této oblasti používají, nejsou schopny tuto mezeru mezi modelem a implementací přemostit, neboť nejsou dostatečně rozšiřitelné, aby mohly dovolit podporu podnikových standardů. Vývojář musí interpretovat model a provést transformaci ručně sám na základě znalostí svého okruhu působnosti. Proto musí být ty stejné implementace prováděny opakovaně podle stejných vzorců a pravidel. V případech, kdy je potřeba změnit model i jeho implementaci tak, aby odpovídal současnému stavu, není tato změna synchronně zaznamenána na obou místech. Efektivní modelovací nástroje dokáží postihnout alespoň následující čtyři záležitosti: •

umožnit podniku specifikovat modelovací standardy a transformace

•

zabezpečit, aby byly požadované informace představovány v modelech ve své aktuální podobě a byly nyní i do budoucna platné

•

zpřístupnit udržení konzistence procesního modelu a zdrojového kódu

•

zajistit takovou funkcionalitu, aby bylo možné i relativně malé změny zanést do řešení pomocí automaticky generovaného kódu

-46/60-



12 Největší hrozby pro aplikaci BPM v prostředí SOA Současně s benefity vyplývajícími z určité strategie se organizace zajímá rovněž o hrozby či chyby, kterých by se měla vyvarovat. V této kapitole se proto na tyto chyby zaměříme a uvedeme zde, "jak by implementace neměla vypadat". Abychom byli schopni vytvořit business case67 pro projekt implementace BPM, musíme nejprve kategorizovat potenciální hrozby pro podnik, identifikovat nejdůležitější možné problémy a kalkulovat náklady, které by firma měla i nadále, pokud by se vůbec nepouštěla do implementace BPM. V této fázi nacházíme a identifikujeme problémy a snažíme se naznačit jejich dopad na stávající organizaci. V mnoha organizacích jsou jak současné problémy, tak i potenciální hrozby těžko identifikovatelné a měřitelné, a to i tehdy, kdy je většina manažerů přesvědčena o tom, že je schopna definovat úroveň významnosti a důležitosti každého faktoru. Podle Upside Research Business Impact Statement68 rozeznáváme při tvorbě business case pro implementaci BPM sedm základních problémů, u kterých by měl nejprve každý manažer posoudit, zda se organizace některý z problémů týká či který problém je pro organizaci tím nejkritičtějším. Teprve potom na základě identifikovaných problémů by měl být schopen určit úroveň jejich důležitosti a/nebo jejich potenciální dopad na provoz podniku. Uveďme nyní tyto nejčastější problémy: •

Nedostatečně výkonné procesy. V organizaci se na každou dodatečnou hodinu potřebnou k dokončení procesu vztahují vysoké náklady. Tyto náklady jsou spojeny jak s rostoucí pracovní dobou zaměstnanců, tak i se ztrátami plynoucími ze snížení podnikové výkonnosti a produktivity. Současně velkou roli hrají rovněž oportunní náklady, neboť i zde je velké potenciální riziko, že z důvodu neefektivnosti procesu a jeho dlouhého trvání, ztrácí podnik příležitosti získávat nové zakázky a zaznamenává sníženou interní produktivitu. Z tohoto důvodu je nutné, aby organizace začala některé klíčové oblasti měřit a identifikovat jejich slabá místa, která mají negativní dopad na výkonnost podniku. Potenciální náklady z důvodu nedostatečné výkonnosti jsou: o neschopnost dokončit proces včas o ztráta produktivity zaměstnanců spojená se ztrátou jejich pracovního času využitelného pro věnování se činnosti, která bude přinášet přidanou hodnotu o ztráta oportunních zisků a zaznamenání oportunních nákladů o neefektivní plýtvání lidskými zdroji

• Nízká odezva podniku na změny. V dnešním konkurenčním prostředí hraje schopnost rychle reagovat na organizační změny velikou roli. Schopnost umět rychle a efektivně reagovat na změny podmínek na měnícím se trhu s sebou přináší možnost získávat nové zakázky či rozšiřovat se na trhu. Proto můžeme tvrdit, že společnost, která nedisponuje efektivními, výkonnými a změnám otevřenými podnikovými procesy, selhává na poli potenciálních příležitostí. Co je ještě důležitější, je fakt, že společnosti, které spoléhají na dodavatelské sítě a partnery, kteří nejsou schopni reagovat příliš hbitě, mohou rovněž z tohoto důvodu zaznamenat ztráty. Potenciální náklady plynoucí z nízké odezvy podniku na změny zahrnují: 67

business case - zachycení důvodů pro inicializaci projektu nebo úkolu [2] ASHTON, Heather. - KELLY, David. The Business Impact of BPM with SOA: Building a Business Case for BPM with SOA ROI. Upside Research, s.8. 68

-47/60-



o ztrátu již existujících obchodů o ztrátu možnosti získat nové obchodní příležitosti o neschopnost udržet krok s konkurencí • Nákladné chyby podniku. Protože podnikové procesy leží z hlediska logiky v samotném srdci organizace, každý pád procesu nebo jeho ukončení chybou má negativní dopad na organizaci jako takovou. Mnoho podnikových procesů zahrnuje manuální komponenty, které nenesou žádnou přidanou hodnotu a hrozí potenciálním nebezpečím snadného vzniku lidských chyb. Potenciální náklady spojené s chybami podniku jsou následující: o ztráta již existujících obchodů o náklady spojené s řešením chyb o negativní dopad na pověst organizace • Rozdělená organizace. Jedna z dnešních nejméně efektivních organizačních struktur je taková struktura, která má v sobě vystavěné hranice mezi jednotlivými odděleními a pracovními skupinami tak, že tyto podnikové jednotky mezi sebou vzájemně nesdílí ani informace, ani podnikové procesy. Jak organizace roste, rostou s ní i tyto pomyslné hranice, a informace a procesy se tak stávají navzájem oddělenými a uloženými jen v rámci daného oddělení. To způsobuje téměř nemožnost vytvořit usměrněný tok podnikových procesů, neboť jeho jednotlivé složky jsou vzájemně skryty a uloženy v daných odděleních. To s sebou přináší hrozbu nedostatku porozumění, vnitřního pohledu na věc, nedostatek sdílených informací napříč celou organizací a celkově pak nedostatek soudržnosti podnikových procesů. Potenciální náklady plynoucí z takovéto organizační struktury jsou: o nedostatek záznamů a chyby v řízení zákazníků o neschopnost provázat oddělení napříč procesy o snížená hbitost a reakce na změny o nedostatečně výkonné podnikové procesy o vyšší celkové provozní náklady a TCO69 (Total Cost of Ownership) • Ztráta možnosti proniknout do podstaty věci. Jakmile jednou organizace započne vytvářet nové automatizované podnikové procesy, pochopí pravý význam a pozná benefity spojené s organizovanými procesy a schopností nalézt nové oblasti, které je potřeba optimalizovat. Nicméně pokud společnost postrádá schopnost monitorovat, řídit a optimalizovat své procesy, znamená to pro společnost velké oportunní ztráty. Bez této schopnosti monitorovat a optimalizovat nemůže společnost očekávat žádné přínosy z automatizace procesů, neboť v takovém případě není definován způsob, jak rozpoznat, zda výkonnost procesu je taková, jaká byla očekávána, či nikoli. V návaznosti na to každý proces musí být flexibilní a rychle odpovídat na měnící se podmínky. Jestliže však zde není možnost náhledu na jeho výkonnost ani možnost optimalizace, podnik ztrácí jakékoli benefity plynoucí z automatizace. Potenciální náklady vážící se na nedostatek vnitřního pohledu na věc mohou být: o oportunní náklady 69

TCO - přímé a nepřímé náklady spojené s hardware a software -48/60-



o procesy jsou neefektivní a není možné je reálně optimalizovat o nemožnost zjistit soulad procesů o nedostatek kontroly • Spolupráce a splnění cíle. Většina dnešních organizací požaduje nějaký typ splnění cílů, což je často prosazováno vyšším managementem, který zároveň tyto požadavky řídí v souladu se strategickými cíli organizace. Nemá-li organizace žádné procesy, na kterých by mohla uplatňovat politiku splnění cílů, potom je těžké vlastních cílů dosáhnout. V některých případech to může být i nemožné. Rizika plynoucí z této hrozby ústí neschopností dodržovat termíny až ztrátou certifikace. Potenciální náklady plynoucí se z neschopnosti plnit cíle zahrnují: o pokuty ze strany řízení podniku, vlády či regulačních autorit o selhání v otázce dodržování důležitých termínů o ztráta certifikace o poškození podnikové pověsti o ztráta současných obchodů s ekonomickým dopadem • Neexistence vývoje založeného na službách. SOA je přístupem podniku, který se snaží maximalizovat návraty z vývoje aplikací. Organizace, které používají tradiční metody pro vývoj aplikací, čelí významným nákladům a riziku, že se jim nepodaří vyvinout takovou komponentu, která by mohla být v budoucnu znovu použitelná. Tato problematika je obzvlášť viditelná při automatizaci procesů, neboť mnoho stejných elementů je využito v několika procesech napříč organizací. Neexistence SOA a BPM přístupu v podniku znamená poměrně významnou pravděpodobnost ztrát. Potenciální náklady plynoucí z této problematiky jsou: o zvýšené náklady na vývoj o nedostatek schopnosti reagovat na podněty a nedostatek hbitosti o ztráta příležitostí pro podnik

12.1 Nejčastější chyby SOA implementace Budeme-li chtít identifikovat nejčastější chyby, které se vyskytují u implementace SOA, najdeme čtyři nejčastější z nich, kterými jsou70: •

nadhodnocení kódu nižší programovací úrovně

•

centralizace návrhu a vývoje

•

roztržení a nahrazení stávajícího software

•

pořizování software bez dostatečné podpory

Organizace dojde k těmto nejčastějším chybám typicky důsledkem potřeby zavedení nejnovější technologie bez vyrovnání reklamních preferencí s praktickou bází znalostí a zkušenostmi. K tomu, aby byla SOA integrace úspěšná, organizace musí brát v úvahu prospěšnost architektury z dlouhodobého hlediska, i v případech implementace krátkodobých řešení. 70

[20] SENOR, John. Worst Practices in SOA Implementation: Why Service-Oriented Architectures Fail, s.7. -49/60-



Pojďme se nyní ve stručnosti podívat, co tyto nejčastější chyby pro podnik znamenají a jaké možnosti existují pro to, aby se jim úspěšně předešlo.

12.1.1 Nadhodnocení kódu nižší programovací úrovně Některé SOA integrace probíhají tím způsobem, že společnost pomocí integračního nástroje provede integraci, a dojde tak k automatizaci podnikových procesů. Po nějaké době je však třeba daný podnikový proces změnit a vývojáři jsou nuceni změnit kód. Tyto změny procesu mohou mít původ ve změně na úrovni celé organizace jako je například spojení s jinou společností, nebo mohou mít původ v něčem relativně menším jako je změna dodavatele, avšak stále se bude jednat o zásah do kódu. V případě, že je tento kód nadhodnocován, dochází pak k tomu, že systém se stává křehkým, pomalým a méně přístupný změnám. Tento přístup má kořeny v EAI (Enterprise Application Integration) a nedovoluje organizaci vytvořit otevřenou a znovupoužitelnou architekturu. Řešením tohoto problému by mohl být větší důraz a zaměření na služby na podnikové úrovni. Zjednodušeně řečeno, bude-li upřednostněn přístup tvorby procesu jako znovupoužitelné služby před přístupem kódování procesního workflow, potom bude nutné služby kódovat pouze jednou a v budoucnosti budou snadno použitelnými znovu jakoukoli jinou činností, která právě informace obsažené v dané službě potřebuje. Pro to, aby byla implementace SOA úspěšná, je nutné, aby organizace upustila od EAI paradigmatu. Jakmile se podnikový proces stane příliš komplexním, množství kódu, který musí vývojáři napsat, exponenciálně vzroste. Z tohoto důvodu by tedy každý vzorec integrace měl být vyvíjen jako znovupoužitelná služba.

12.1.2 Centralizace návrhu a vývoje Organizace, které k návrhu a vývoji služeb a servisně orientované architektury jako takové využili centralizovanou skupinu lidí, zaznamenaly několik problémů s tím spojených. Na jednu stranu docházelo k situacím, kdy služby byly navrhovány a vyvíjeny lidmi, kteří přicházeli se službami do kontaktu na dennodenní bázi. Není pochyb, že by nebyli schopni kódovat služby kvalitně, ba naopak. Problémy vyvstaly v okamžiku, kdy některý vývojář ze skupiny odešel, a ostatní netušili, jak byla určitá část SOA aplikace vystavěna. Na druhou stranu centralizace návrhu a vývoje služeb zapříčiňuje jejich izolaci, což velmi znatelně podrývá základy architektury SOA. V centralizovaném týmu docházelo k velkým problémům, kdy bylo třeba kódovat služby pro aplikaci, se kterou nebyli v dennodenním kontaktu, a proto ji dostatečně neznali. Z uvedených důvodů by služby měly být navrhovány, vyvíjeny a udržovány na decentralizované lokální bázi. Jedině v rámci takového modelu je možné přistupovat ke službám na vyšší úrovni, aniž by byli vývojáři nuceni udržovat informační aktiva, která leží pod nimi. Pro tento model rovněž hovoří fakt, že každé informační aktivum se neustále mění v důsledku nových verzí, aktualizací či oprav. Jsou-li týmy návrhářů a vývojářů decentralizovány, mohou lokální správci i vývojáři měnit základní služby bez ovlivnění systému jako celku. Decentralizací je dosaženo toho, že služby jsou vyvíjeny v blízkosti informačních aktiv, a je tedy realizovatelné, aby lidé bezprostředně pracující s aplikací, věděli, jaké jsou vstupy a výstupy, a nesli zodpovědnost za provedení jakékoli změny služby.

-50/60-



12.1.3 Roztržení a nahrazení stávajícího software Ani v případě aktualizace IT infrastruktury není vždy pravdou a správným řešením, aby všechny stávající systémy byly nahrazeny novou technologií. Ve smyslu SOA integrace jsou stávající systémy důležité z důvodu udržení dat, které jsou v nich uchovány. Odhaduje se, že v těchto základních systémech se nachází 70% světových dat71. Z tohoto důvodu a z důvodu špatných výsledků při přecházení do nového prostředí se obvykle doporučuje neopravovat základní systémy, dokud fungují. Namísto jejich nahrazení je možno vystavět nad takovými systémy řešení, které bude založeno na všeobecně uznávaných protokolech. To umožňuje integraci několika prostředí bez nutnosti změny aplikací, které jsou pod nimi. Udržování systémů, které jsou klíčové pro organizaci, je logicky zásadní záležitostí, neboť tyto systémy obsahují data a podnikové procesy, které odlišují organizaci od svých konkurentů, a představují tak velmi hodnotné aktivum. Z fiskálního či strategického hlediska je proto dobré upřednostňovat výše zmiňovanou alternativu, pokud je to možné.

12.1.4 Pořizování software bez dostatečné podpory Nákup software je pouze jedním krokem. Před jeho pořízením je důležité rozhodnout, jak může být daný software využitelný z hlediska implementace a znovupoužitelnosti servisně orientované architektury, tj. jakou podporu pro SOA bude software poskytovat. Dva největší problémy, které plynou z nedostatečné znalosti jak provozovat SOA software, jsou budování příliš komplexního systému a nevyužití správných nástrojů. Příliš komplexní systémy jsou budovány v případech, kdy organizace plně nerozezná odlišnost SOA implementace od EAI architektury. Na samém počátku je třeba si uvědomit, co službou je a jak je potřeba ji agregovat do vyšších úrovní. Druhým dopadem nedostatečné podpory je nevyužívání správných nástrojů. Protože podniková integrace zahrnuje mnoho různých aplikací, datových zdrojů a podnikových procesů, neexistuje žádný jediný produkt, který by byl využitelný ke splnění všech úkolů.

71

[20] SENOR, John. Worst Practices in SOA Implementation: Why Service-Oriented Architectures Fail, s.10. -51/60-



13 Současné trendy Ačkoli se nepředpokládá, že by BPM a SOA byly plně dozrálými technologiemi do roku 2010, již nyní se považují za vedoucí přístupy, což dokazuje mimo jiné fakt, že většina organizací zavádí do svého interního řízení model procesní architektury. Z panelového výzkumu provedeného firmou Gartner z konce roku 2006 vyplývá, že význam BPM-SOA řešení v podnikovém povědomí stoupá. Průzkum byl zaměřen na otázku, jakou důležitost organizace přisuzují využití BPM v SOA řešeních. Většina dotazovaných, tedy 64% odpovědělo, že považují využití BPM za důležitý. Téměř třetina (28%) dokonce ohodnotila význam zavedení BPM za velmi důležitý. Pouhá 4% všech dotazovaných uvedla, že tento přístup není důležitý a další 4% vypověděla, že na danou problematiku nemají názor72. Z kombinace BPM a SOA se v současné době vypočítává rovněž tzv. kombinovaný ROI73 (Return on Investment). Při určování kombinovaného ROI vycházíme z předpokladu, že strategie BPM a SOA si vzájemně zvyšují jednotlivá ROI. Jakmile se jednou proces stane automatizovaným, stane se rovněž znovupoužitelnou službou. Zatímco tedy SOA umožňuje rychlejší rozmístění BPM a jeho znovupoužitelnost, BPM poskytuje ovládání, řízení a governance SOA infrastruktury. To znamená, že BPM umožňuje pohled na služby jednak jako na oddělené entity a zároveň jako na entity spojené v logických procesech.

13.1 Současné porozumění BPM a SOA Z průzkumu provedeného v červnu roku 2007 společností Business Process Trends74 vyplývá, že zájem o přístupy BPM a SOA mají především business analytici (37%) a architekti IT systémů (23%)75. Největší zájem o BPM a SOA mají organizace poskytující software či jiné informatické služby (25%), dále pak sektor finanční a sektor pojišťovnictví (19%) a podniky zabývající se poradenstvím (17%). Aby bylo dosaženo čistších dat reprezentujících organizace přímo vyvíjející či nakupující systémy pro zajištění základních podnikových funkcí, byla vypuštěna data od informatických firem a firem poradenských. Po takové filtraci získaly sektor finanční a sektor pojišťovnictví 41% a do popředí se dostala odvětví: vláda, armáda (13%) a telekomunikace (13%). Dle mého hlediska je pro organizace důležitá jejich velikost. V souladu s vyspělostí podniku byly i výsledky výzkumu, kde 50% tvořily velké společnosti, střední podniky 31% a malé podniky měly pouhé 19-ti % zastoupení. Tyto výsledky potvrzují fakt, že aplikace BPM přístupu v SOA prostředí není nutná pro všechny podniky bez ohledu na jejich velikost. Zajímavé změny ve výsledcích bylo dosaženo opětovnou filtrací výpočetních společností a poradenských služeb. V tomto případě se počet velkých organizací zajímajících se o problematiku BPM a SOA zvýšil na 61% a procento zastoupení malých podniků pokleslo na pouhých 9%. Z těchto výsledků usuzujeme, že většina respondentů pracujících pro výpočetní či poradenské společnosti pracuje v malých a středních podnicích.

72

[8] FISCHER, Layna. 2007 BPM and Workflow Handbook, s.48. ROI - poměr částky získané/ztracené ku částce investované 74 <www.businessprocesstrends.com> 75 [11] HARMON, Paul. - WOLF, Celia. Business Process Management and Service Oriented Architecture, s.4. 73

-52/60-



Obr. č. 4 - Velikost organizací zajímajících se o problematiku BPM a SOA76

V rámci průzkumu byly respondenti dotazováni, jak vidí roli IT v otázce procesního řízení. Největší část (34%) odpověděla, že IT má rozhodující roli a že tuto roli úspěšně plní. Dalších 25% dotazovaných odpovědělo, že IT má sice rozhodující roli, ale priority, čas a náklady omezují IT v plnění svých cílů tak úspěšně, jak by mohly. Poslední významné zastoupení (17%) se shodlo na tom, že IT brání v plnění své role nedostatek nástrojů, technologie a infrastruktury. V otázkách zaměřených na SOA governance v souvislosti s BPM odpovědělo 55% dotazovaných, že enterprise architekti mají největší zodpovědnost za tvorbu pravidel pro SOA governance. 28% respondentů identifikovalo roli governance specialisty a 25% připisuje tuto roli business analytikům. Na otázku, jak společnosti vnímají vztah BPM a SOA, odpověděla necelá polovina (40%), že BPM je úspěšnější a přináší více výhod pouze, je-li implementován v SOA prostředí. Problematiku z druhé strany chápe 34% respondentů, totiž že SOA je úspěšnější a má větší podnikový význam, je-li svázáno s principy BPM. Pouhých 7% vidí SOA jako základní požadavek pro BPM, zatímco 19% usuzuje, že BPM je základním předpokladem pro úspěšnou implementaci SOA. Tyto rozdílné přístupy pravděpodobně odrážejí relativní neznalost spojení BPM se SOA. Ze současných trendů se dá usuzovat o trendech budoucích. Budeme-li se držet současných dat, potom můžeme tvrdit, že nějakou dobu potrvá, než se v podnicích prosadí využití BPM v prostředí SOA, neboť doposud není plně porozuměno, v čem se mohou tyto přístupy doplňovat a jak toho lze využít. Na trhu uživatelů software se bude jednat o velké organizace, zatímco na straně poskytovatelů software můžeme očekávat penetraci trhu malých a středních podniků. Co se vývoje samotného BPM přístupu týče, existují prameny, které hovoří o tzv. BPM další generace, které by mimo jiné mělo poskytovat základ pro implementaci v rámci SOA77. Na základě toho můžeme usuzovat o jakémsi filozofickém posunu, kdy by měly být koncepty BPM a SOA chápány jako vzájemně se doplňující a umožňující podniku být efektivnějším a zároveň konkurenceschopnějším.

76 77

[11] HARMON, Paul. - WOLF, Celia. Business Process Management and Service Oriented Architecture, s.8. [18] Next-Generation BPM: Creating the Strategic Enterprise. Workpoint, Whitepaper, s.4. -53/60-



Závěr Ačkoli jsme zde několikrát uvedli, že BPM a IT jsou dva odlišné (můžeme říci protichůdné) přístupy k podnikové integraci, byla by škoda nevyužít jejich odlišných pohledů k vzájemné interakci. Už jen z toho důvodu, že jsou strategie BPM a SOA považovány za jedny z nejdůležitějších a za vůdčí principy budoucího vývoje v oblasti integrace podniku. Po přečtení této práce bychom neměli nabýt dojmu, že BPM je "jen" o grafické reprezentaci procesů, nýbrž že se z konceptuálního hlediska jedná o skutečnou strategii, která dokáže podporovat základní principy servisně orientované architektury, jako je volná vazba či hrubá nespojitost služeb. BPM dokonce poskytuje dostatečnou kapacitu pro řešení výjimek, neboť ty nejsou v procesu ničím neobvyklým, a podporuje transakční přístup, který je nezbytný k udržení integrity nejen v aplikačních datech, ale rovněž v datech podnikových. To, že BPM překlenuje mezeru mezi podnikem a IT jednotkami je pravda z logické podstaty věci, na technologické úrovni je však třeba tyto dva pohledy oddělit. Není žádoucí, aby se musel přestavět podnikový proces jen z důvodu výměny datového úložiště. Stejně tak podnikové integraci neprospěje, budou-li změnou podnikového procesu ovlivněny aplikace, které jsou pod ním. V jednotlivých kapitolách jsme uvedli několik postupů, jak lze tyto zodpovědnosti oddělit na technologické úrovni. Zároveň bychom však neměli opominout potřebu existence pravidel governance, které tyto zodpovědnosti formálně vymezí a rovněž postihnou jejich nedodržení. Odrazovým můstkem této práce byl pohled na podnikovou integraci ze dvou různých úhlů pohledu. Ukazuje se, že ani integrace tlačená čistě podnikem, ani integrace ze strany IT, nejsou ideálními případy, proto se s oblibou aplikuje agilní přístup, tedy kombinace obou předchozích strategií. Žádný z těchto přístupů však není přesně definovaným postupem "jak na to", proto organizace, které se rozhodly uplatnit využití BPM v SOA, čelí mnoha výzvám a potenciálním hrozbám. Jak jsme uvedli v kapitolách k tomu určených, příležitosti a hrozby jsou rozmístěny napříč celým podnikem, a není proto pro organizaci jednoduché postihnout důležitost využití přístupů v plném rozsahu. Z tohoto důvodu a také z důvodu komplexnosti BPM a SOA se často setkáváme se situacemi, kdy těmto přístupům není plně porozuměno. Zatímco jedni upřednostňují přístup z pohledu IT a považují ho za základ integrace, druzí nahlížejí na problematiku přesně opačně. Proto si troufám tvrdit, že největší výzvou pro nadcházející roky je porozumění možnosti součinnosti principů Business Process Managementu a Service-Oriented Architecture a šíření tohoto porozumění napříč celou organizací. Stanou-li se tyto strategie přístupnějšími a nebudou-li pouze marketingovými pojmy, bude pro organizaci snazší úspěšně je implementovat.

-54/60-



Použitá literatura Monografie [1] Applying a BPM and SOA Approach to Achieve Agile Business Integration. BEA Systems, Whitepaper. c2007. Dostupný z WWW: . [2] ASHTON, Heather. - KELLY, David. The Business Impact of BPM with SOA: Building a Business Case for BPM with SOA ROI. Upside Research. c2006. Dostupný z WWW: . [3] BEHARA, Gopala Krishna. BPM and SOA: A Strategic Alliance. c2006. Dostupný z WWW:. [4] BELL, Michael. Service-Oriented Modeling: Service Analysis, Design, and Architecture. First printing. Hoboken, New Yersey: John Wiley & Sons, Inc., 2008. 366s. ISBN: 978-0470-14111-3. [5] BRAHE, Steen. Business Process Management. First printing. Heidelberg: Springer Berlin, 2007. ISBN 978-3-540-75182-3. BPM on Top of SOA: Experiences from the Financial Industry, s. 96-111. Dostupný z WWW: . [6] ERL, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design. Fifth printing. Crawfordsville, Indiana: R.R. Donnelley, 2006. 760s. ISBN 0-13-185858-0. [7] Extending the Business Value of SOA Through Business Process Management. BEA Systems, Whitepaper. c2006. Dostupný z WWW: . [8] FISCHER, Layna. 2007 BPM and Workflow Handbook. First printing. Lighthouse Point, USA: Future Strategies Inc., Book Division, 2007. ISBN 978-0-9777527-1-3. [9] Getting Started With BPM: An Introduction To Business Process Management. Lombardi, Whitepaper. c2008. Dostupný z WWW: . [10] GILBERT, Phil. A Business Oriented Architecture: Combining BPM and SOA for Competitive Advantage. Lombardi, Whitepaper. c2008. Dostupný z WWW: . [11] HARMON, Paul. - WOLF, Celia. Business Process Management and Service Oriented Architecture. BPTrends, Survey. c2007. Dostupný z WWW: .

-55/60-



[12] INAGANTI, Srikanth. - BEHARA, Gopala Krishna. Service Identification: BPM and SOA Handshake. c2007. Dostupný z WWW: . [13] KAMOUN, Faouzi. A Roadmap towards the Convergence of Business Process Management and Service Oriented Architecture. c2007. Dostupný z WWW: <www.acm.org/ubiquity/views/pf/v8i24_bmpsoa.pdf>. [14] KRAFZIG, Dirk. - BANKE, Karl. - SLAMA, Dirk. Enterprise SOA: Service-Oriented Architecture Best Practices. First printing. Hagerstown, Maryland: Phoenix BookTech, 2004. ISBN 0-13-146575-9. [15] MEIER, Fabian. Service Oriented Architecture Maturity Models: A guide to SOA Adoption? Skövde, 2006. Diplomová práce na Högskolan Skövde, School of Humanities and Informatics. Vedoucí diplomové práce Eva Söderström. Dostupný z WWW: . [16] NEUBAUER, Bruce J. Introducing SOA and Workflow Modeling to Non-technical Students. Tampa, Florida: Consortium for Computing Sciences in Colleges, 2007. Dostupný z WWW: . [17] NEWCOMER, Eric. - LOMOW, Greg. Understanding SOA with Web Services. 1st Edition. Addison Wesley Professional, 2004. 480s. ISBN: 0321180860. [18] Next-Generation BPM: Creating the Strategic Enterprise. Workpoint, Whitepaper. c2007. Dostupný z WWW: . [19] PULIER, Eric. - TAYLOR, Hugh. Understanding Enterprise SOA. First printing. Greenwich, USA: Manning Publications Co., 2006. 242s. ISBN: 1-932394-59-1. [20] SENOR, John. Worst Practices in SOA Implementation: Why Service-Oriented Architectures Fail. Information Builders Inc., Whitepaper. c2007. Dostupný z WWW: . [21] SMITH, Howard. - FINGAR, Peter. Business Process Management: The Third Wave. First printing. Tampa: Meghan-Kiffer Press, 2002. ISBN: 0-929652-33-9. [22] STRNADL, Christoph F. Service-Oriented Computing - ICSOC 2007. First printing. Heidelberg: Springer Berlin, 2007. ISBN 978-3-540-74973-8. Bridging Architectural Boundaries Design and Implementation of a Semantic BPM and SOA Governance Tool, s. 518-529. Dostupný z WWW: . [23] WOODLEY, Thomas. - GAGNON, Stephane. Web Information Systems Engineering WISE 2005. First printing. Heidelberg: Springer Berlin, 2005. ISBN 978-3-540-300175. BPM and SOA: Synergies and Challenges, s. 679-688. Dostupný z WWW: . -56/60-



Internetové prameny [24] ISO 9000. c2002. [cit.2008-04-13]. Dostupný z WWW: . [25] KETABCHI, Farshid. - GORDON, John B. - GENDRE, Alain. Building a Real-Time Enterprise: Understanding SOA, BPM, and BRM. United Business Media, Webinar. c2007. Dostupný z WWW: . [26] Six Sigma. c2003. [cit.2008-04-13]. Dostupný z WWW: . [27] SOA Maturity Model. Progress Software Corporation. [cit.2008-04-13]. Dostupný z WWW: . [28] Wikipedia, the Free Encyclopedia. Wikimedia Foundation, Inc. c2008. [cit.2008-04-16]. Dostupný z WWW:.

-57/60-



Terminologický slovník .NET Framework

- platforma pro serverové aplikace vyvíjené na platformě .NET. Framework je vyvíjen společností Microsoft.

BAM

- Business Activity Monitoring. Software umožňující monitorování podnikových aktivit, které jsou implementovány v informačních systémech. Monitorování probíhá na bázi skutečného času.

BPDM

- Business Process Definition Metamodel. Metamodel založený na XML. Je určen pro podnikové procesy a byl vyvinut Object Management Group (OMG).

BPEL

- Business Process Execution Language. Jazyk pro specifikaci podnikového procesu založený na webových službách.

BPM

- Business Process Management. Holistický přístup managementu k podnikovým procesům, který poskytuje podnikovou efektivnost a výkonnost pomocí inovace, flexibility a integračních technologií.

BPML

- Business Process Modeling Language. Meta jazyk pro modelování podnikových procesů.

BPMN

- Business Process Modeling Notation. Standardizovaná grafická notace pro modelování podnikových procesů ve workflow.

BPMS

- Business Process Management Systems. Systém zastřešující logiku BPM a představující nástroje pro modelování a řízení procesů.

BPR

- Business Process Reengineering. Přístup managementu usilující o zlepšování pomocí zvyšování efektivnosti a výkonnosti podnikových procesů.

business case

- zachycuje důvody pro inicializaci projektu nebo úkolu. Většinou je prezentován formou dokumentu.

EAI

- Enterprise Application Integration. Využití software a principů informačních systémů k integraci několika podnikových aplikací.

end-to-end proces

- proces, který má jasně definovaný počáteční bod a bod koncový. V kontextu organizace se jedná o menší podnikové procesy.

enterprise proces

- proces vzniklý zřetězením procesů, které jsou prováděny jednotlivými odděleními. Modely takových procesů je možné aplikovat v jakékoli organizaci (např. účtování, zajištění služeb, strategie a vývoj produktu apod.)

entita

- část reality, která je natolik rozlišitelná od ostatních entit, že je možné/třeba ji definovat.

ePDA

- Enhanced Process Driven Architecture. Rozšířený model PDA, viz PDA.

ERP

- Enterprise Resource Planning. Systém integrující několik datových zdrojů a podnikových procesů organizace do jednotného systému.

ESB

- Enterprise Service Bus. Konstrukce softwarové architektury. Implementována jako middleware produkt.

-58/60-



formální ontologie

- ontologie uspořádaná na základě axiomů (tvrzení, která se nedokazují, ale jsou považována za všeobecná). Cílem formální ontologie je poskytnout nestranný pohled na realitu.

J2EE

- Java Platform Enterprise Edition. Platforma pro serverové aplikace vyvíjené v Javě.

JMS

- Java Message Service. Middleware zaměřený na odesílání a přijímání zpráv.

KPI

- Key Performance Indicator. Metrika k definování a měření splnění definovaných cílů organizace.

loose coupling

- popisuje pružný vztah mezi dvěma nebo více systémy či organizacemi. Zahrnuje v sobě určitou podporu výměny informací.

MDD

- Model Driven Development. Systematické využívání modelů jako primárních artefaktů napříč životním cyklem.

metadata

- data o datech.

middleware

- software spojující softwarové komponenty nebo aplikace.

MQ

- Message Queuing. Softwarová komponenta používaná ke komunikaci v rámci procesu nebo vlákna.

nespojitost

- měřítko velikosti komponenty nebo jejího popisu. Je relativní velikostí, rozsahem a úrovní detailu charakterizující objekt nebo aktivitu.

PDA

- Process Driven Architecture. Architektura, podnikovou logiku logikou procesní.

protokol

- standard, který kontroluje nebo umožňuje spojení, komunikaci a datový přenos mezi dvěma koncovými body.

ROI

- Return on Investment. Poměr částky peněz získaných/ztracených z investice ku částce investované.

RPC

- Remote Procedure Call. Technologie umožňující programům zavolat podproces nebo proceduru, která má být vykonávána mimo její úložiště.

SDLC

- Systems Development Life Cycle. Proces vývoje software, informačního systému apod.

SLA

- Service Level Agreement. Část dohody o službě, ve které je definována úroveň služby.

SOA

- Service Oriented Architecture. Přístup k architektuře využívající podnikových procesů k definování služeb. Poskytuje prostředí pro výměnu dat mezi různými aplikacemi.

SOAP

- Simple Object Access Protocol. Protokol pro výměnu zpráv založených na XML v rámci počítačové sítě.

TCO

- Total Cost of Ownership. Metoda umožňující ohodnotit přímé a nepřímé náklady spojené se software a hardware.

-59/60-

která

nahrazuje



transakce

- dohoda, komunikace nebo pohyb mezi entitami nebo objekty. Transakce musí zajišťovat integritu a musí být umožněno ji v případě potřeby vrátit do původního stavu.

TQM

- Total Quality Management. Strategie řízení podniku snažící se o aplikaci uvědomění kvality do každého podnikového procesu.

XHTML

- Extensible Hypertext Markup Language. Značkovací jazyk. Je rozšířením jazyka HTML podporujícím XML syntaxi.

XML

- Extensible Markup Language. Specifikace pro vytváření značkovacích jazyků. Umožňuje uživatelům definovat své vlastní elementy.

XML Schema

- jeden z jazyků pro tvorbu xml schémat (souboru pravidel, která musí být dodržována přiřazeným XML dokumentem).

XPath

- XML Path Language. Jazyk určený pro vybírání uzlů XML dokumentu.

XQuery

- dotazovací jazyk pro získávání kolekcí XML dat. Semanticky je podobný jazyku SQL.

XSLT

- Extensible Stylesheet Language Transformations. Jazyk pro transformaci XML dokumentů do jiných typů dokumentů.

WfMS

- Workflow Management Systems. Systém pro řízení workflow, viz workflow.

workflow

- spolehlivě se opakující sled aktivit, který je umožněn systematickou organizací zdrojů, definovaných rolí a toku informací.

WS-BPEL

- Web Services Business Process Execution Language. Plný název pro BPEL viz BPEL.

WSDL

- Web Services Description Language. Jazyk poskytující model pro popis webových služeb.

-60/60-

Vysoká škola ekonomická v Praze. Možnosti využití Business Process Management BPM v SOA

Recommend Documents