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

Transkript

1 Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií Student Vedoucí bakalářské práce Recenzent bakalářské práce : : Ing. Roman Hauptvogl : Ing. Alena Buchalcevová, Ph.D. TÉMA BAKALÁŘSKÉ PRÁCE Možnosti využití Business Process Management BPM v SOA ROK : 2008

2 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 podpis -ii-

3 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-

4 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-

5 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-

6 Obsah Úvod BPM Charakteristiky BPM a vybrané standardy Historie BPM Pohled IT na BPM Kdy je vhodné BPM zavést SOA Principy SOA Vznik SOA SOA Maturity Model Strategie dodání řešení podnikových systémů Fáze životního cyklu Přístup k podnikové integraci shora dolu - Business driven Kroky strategie shora dolu kopírující životní cyklus Výhody a nevýhody přístupu shora dolu Přístup k podnikové integraci zdola nahoru IT driven Kroky strategie SOA kopírující životní cyklus Výhody a nevýhody přístupu zdola nahoru Agilní strategie aneb Klíčová role vzájemné spolupráce BPM a SOA Kroky agilní strategie kopírující životní cyklus Následující kroky Výhody a nevýhody agilní strategie Charakteristické rysy BPM v prostředí SOA Potřeba zmenšení rozdílu mezi podnikem a IT Časový rozdíl Rozdíl v přístupu Prostor pro neustálé zlepšování Návrh řešení BPM v SOA prostředí Volný návrh služeb v kontextu BPM (Loose-coupling) Hrubý návrh z pohledu BPM (Coarse-grained) Řešení transakcí v BPM-SOA Transakce procesů Transakce služeb Desynchronizace procesu Výjimky a chyby procesů Enterprise Service Bus (ESB) Ne jen přeprava (transport) zpráv Mnohonásobné logické úrovně SOA/BPM Governance Enhanced Process-Driven Architecture (epda) Benefity a překážky kombinace BPM-SOA Spolupráce podniku a IT Spojení dvou celků Potřeba nástrojů pro dynamické řízení procesů Rysy, ve kterých se BPM a SOA doplňují BPM SOA Webové služby Business Oriented Architecture vi-

7 10.5 Technická realizace Business Oriented architektury Výzvy pro implementaci BPM-SOA Od modelu podnikových procesů k implementaci Využití SOA Implementace modelu procesu Odchytávání výjimek Současnost modelu Výzvy pro organizaci Technologické výzvy Složitost Technologický pokrok Podpora existujících nástrojů Největší hrozby pro aplikaci BPM v prostředí SOA Nejčastější chyby SOA implementace 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 Současné trendy Současné porozumění BPM a SOA...52 Závěr...54 Použitá literatura...55 Monografie...55 Internetové prameny...57 Terminologický slovník vii-

8 Ú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-

9 1 BPM V dnešní době již nejsou podniková pravidla tolik procedurální, jako byla v minulosti, ale jsou spíše deklarativními 1. 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 workflow 4 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-

10 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ích 6 : 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 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čnosti Historie BPM Předchůdce BPM datujeme do konce 80. let, kdy se objevil přístup Total Quality Managementu 8. Hned za ním vyvstal na počátku 90. let nový přístup Business Process Reengineering 9. 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 [26] Six Sigma. < 7 [24] ISO < 8 TQM - strategie řízení podniku 9 BPR - přístup managementu k optimalizaci podnikových procesů -3/60-

11 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 Wave 12. 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í ERP 13 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 EAI 14 (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 [14] KRAFZIG, Dirk. - BANKE, Karl. - SLAMA, Dirk. Enterprise SOA: Service-Oriented Architecture Best Practices, s [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-

12 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ýroba 15. 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řístupu 16. 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 [14] KRAFZIG, Dirk. - BANKE, Karl. - SLAMA, Dirk. Enterprise SOA: Service-Oriented Architecture Best Practices, s /60-

13 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 coupling 18 (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áv 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 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. -6/60-

14 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 SOA 20, 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-

15 Čí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-grained 21 ), 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 Inc 22., Bearingpoint 23, Systinet a AmberPoint 24. Obr. č. 1 - SOAMM - SOA Maturity Model coarse grained - hrubě navržené služby. V kontextu referuje k nespojitosti (viz Terminologický slovník). 22 < 23 < 24 < 25 [27] SOA Maturity Model < -8/60-

16 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. 1. úroveň vede organizaci převážně k nové funkcionalitě. Jako příklad architektury autoři uvádí zavedení ESB 26 (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. 26 ESB - konstrukce architektury implementována jako middleware produkt -9/60-

17 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 /60-

18 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-

19 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-

20 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ř organizace 29. Analýza hodnotového řetězce se skládá z těchto základních aktivit 30 : 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. 30 [12] INAGANTI, Srikanth. - BEHARA, Gopala Krishna. Service Identification: BPM and SOA Handshake, s /60-