Proč a jak zavádět architekturu SOA

Transkript

1 Prč a jak zavádět architekturu SOA Jedním z hlavních imperativů sučasných kmplexních pdniků je akceschpnst při změnách tržních pdmínek a pdnikatelskéh prstředí. Ztráta akceschpnsti je plíživá a bývá přím úměrná slžitsti pdnikvých činnstí. I ty nejlépe plánvané IT infrastruktury pak čelí významným prblémům plynucím ze spjení pdniků, akvizic a rychléh růstu splečnstí. Aby během nich rganizace neztratily nic ze své výknnsti, musí zamezit překrývání funkcí a zdvjvání prcesů. Servisně rientvaná architektura SOA umžňuje přebudvat IT infrastrukturu, dstranit redundance a zrychlit prjekty. Dsahuje th knslidací a pakvaným pužitím aplikačních služeb. Díky SOA se pdnikvé IT může rychleji přizpůsbvat měnícím se pdnikvým ptřebám, rychleji a s menšími náklady realizvat nvé IT prjekty a výrazně mezvat průběžné výdaje na administrativu. V architektuře SOA nejsu aplikace vystavěny jak samstatné mnlitické útvary (sila). Míst th se zcela nvě, neb na základě existujících aplikací vytvářejí služby (zákaznické, bjednávkvé, skladvé apd.) dpvídající ptřebám pdniku. Pté je nad těmit službami vybudvána v ddělené architektnické vrstvě aplikační lgika dpvídající danému prcesu. Takvé sladění IT s pdnikvými prcesy pak přináší následující výhdy: Vytvřené služby se mhu pužít v mnha různých prjektech. Omezuje se jejich redundance a v nvých prjektech není nutné přepracvávat funkcinalitu. Tak lze urychlit prjekty a snižvat průběžné náklady. Oddělení aplikační lgiky specifické pr daný prjekt d služeb přináší větší flexibilitu tat aplikační lgika se může snadn měnit, aktualizvat neb dknce zcela nahradit tak, aby dpvídala změněným ptřebám pdnikání. Umžňuje také vytvářet různé kmbinace služeb bez th, aby se měnily neb přepisvaly. Výsledkem je větší akceschpnst pdniku a také následné snížení nákladů. Krmě těcht přesvědčivých přínsů může být SOA užitečná i tím, že mění celu dynamiku IT, prtže prjekty, aplikace a celé IT týmy prpjuje vzájemnými závislstmi a vazbami. Dřívější autnmie týmů mezila jejich externí interakce, zvýšila jejich dpvědnst a usnadnila správu rizik. Naprti tmu výhdy SOA jsu v mnha směrech zalženy právě na externích interakcích (realizvaných například využitím služeb vytvřených jinými týmy). Oba tyt světy musíme nyní spjit dhrmady, aniž bychm spadli d pastí, které u bu přístupů existují. Na jedné straně jde křehké, nesplehlivé a těžk udržvatelné prpletence vzájemných prpjení mezi aplikacemi, které se mhu bjevit v případě, že pnecháme týmy, aby budvaly a využívaly služby bez dpvídajícíh řízení. Na druhé straně existuje nebezpečí, že vytvříme tuhu centrální rganizaci, která sice umžní dbře prpjvat aplikace, ale stane se 1

2 brzdu práce prjektvých týmů, mezí jejich dpvědnst a zvýší rizik neúspěchu celéh prjektu. Vzhledem k tmu, jaké změny se d SOA čekávají a jaká nebezpečí mhu při jejím nasazvání číhat, je velmi důležité začít ještě před zahájením přechdu k ní pečlivě plánvat. Přechd k SOA je bvykle pstupný. Nezastupitelnu rli přitm hrají existující aplikace, které během budvání nvých aplikací a služeb dále vytvářejí pdniku hdnty. Tak se pstupně vytváří kmplexní hetergenní prstředí, v němž se nvé služby vyvíjejí puze tehdy, pkud se bjeví nvá pdnikatelská příležitst neb pkud existující řešení nepřinášejí pžadvané výsledky. Důležité tázky před zahájením plánvání Před samtným zahájením plánvání byste si měli zdpvědět následující tázky. Odpvědi se stanu základním vdítkem na cestě k implementaci SOA: Jak v rámci stávajícíh IT prstředí zahájíme a úspěšně uřídíme přechd na SOA? Jak v rámci SOA využijeme stávající IT infrastrukturu a investice? Jaké prcedury musíme zavést neb pzměnit? Kde budu umístěny plitiky a zabezpečení? Jak vysvětlíme statním pdnikvým úsekům přínsy SOA a bhájíme finanční náklady? Jaký bude mít přechd d samstatných sftwarvých útvarů k SOA vliv na naši schpnst rzpznávat a řešit prblémy? Kd vlastní sdílené aplikace a služby a jak máme alkvat náklady a rzpčty na tyt služby? C ptřebujeme pr zajištění úspěšnéh přechdu naší SOA z piltní d prdukční fáze? Pkud budete důsledně plánvat dpředu, bude přechd na SOA efektivní a přinese celému pdniku věřitelné výhdy. Prč zavádět architekturu SOA? Před celpdnikvým zaváděním SOA je také důležité definvat celkvé záměry a przumět jim. Nasazvání SOA bude v každém pdniku řízen dpvídajícími pdnikvými a technickými cíli ať už krátkdbými, tak dluhdbými. Pkud si je ihned zpčátku ujasníte, budete na jejich základě schpni vybrat správné prjekty a zajistit úspěch prvních implementací. Mezi další důležité tázky, které je nutné zdpvědět ještě před zahájením prjektů zavádění SOA, prt patří: Jaké jsu vaše prvtní důvdy pr pužití SOA? (Snížení nákladů? Lepší flexibilita? Mžnst rychlejšíh zavádění? Zlepšení uživatelskéh djmu?) 2

3 Jak budete využívat SOA z krátkdbéh hlediska? (Připjení vašich hlavních aplikací? Integrace s partnery? Získání byznys metrik s výstupy v reálném čase? Sulad s legislativu?) Jaký je dluhdbý ptenciál SOA ve vaší rganizaci? (Rychlejší uvádění prduktů? Flexibilní utsurcing? Flexibilita pdnikvých prcesů? Přísnější gvernance? Něc jinéh?) Vyjmenujme nyní hlavní přínsy, kvůli nimž se SOA v pdnicích čast využívá. Z hlediska prvzní výknnsti t jsu: mezení nákladů na infrastrukturu a správu, lepší přehled, zabezpečení a/neb kntrla celkvých (end-t-end) pdnikvých prcesů, zjedndušení analýzy základních příčin prblémů a autmatizace určvání pririt. Z hlediska efektivity pdnikání jde : zrychlení dby nutné pr uvedení prduktů a služeb realizvaných kritickými pdnikvými aplikacemi a prcesy na trh, jedndušší dsažení suladu s plitikami (bezpečnstními, byznysvými či regulačními) ze všech funkčních blastí, udržvání kntinuity pdnikání v celém pdniku včasnu reakcí na snížení bezpečnsti, výknnsti neb dstupnsti služeb, sledvání byznys metrik v reálném čase. Z hlediska efektivity vývje t jsu: zvýšení pakvané pužitelnsti služeb a mezení nákladů na vývj, zkrácení dby ptřebné pr vývj nvých služeb. Z hlediska účinnsti integrace jde : mezení nákladů na integraci a její slžitsti využitím brvých standardů, bezprblémvu spluprací s klíčvými infrastrukturními řešeními třetích stran, jak jsu systémy pr správu identit, adresářvé služby, systémy pr správu pdniku, a využití jejich mžnstí. P vypracvání precizníh přehledu cílů celpdnikvé SOA mhu dpvědné týmy efektivněji vybírat správné prjekty, řídit je (tj. vyhnut se neřízenému růstu jejich rzsahu) a průběžně zjišťvat, zda celkvé výsledky dpvídají čekávání pdnikvých úseků, kterým budu vytvřené systémy služit. Strategie zavádění SOA Ptenciální výhdy SOA si začíná uvědmvat více a více rganizací, které se stále častěji zajímají přechd d knceptu k realitě d idevé fáze k zahájení skutečnéh piltníh prjektu SOA. A mnhá IT ddělení se nyní začínají zabývat strategiemi a prstředky ptřebnými pr jeh úspěšnu implementaci. 3

4 Pr knečný úspěch piltníh prjektu SOA je důležité ještě před jeh zapčetím vytvřit kherentní strategii zavádění SOA. Zanedbání fáze strategické rzvahy vede ke zvýšení rizika selhání piltníh prjektu. I když piltní prjekt SOA pstupuje kupředu, neadekvátní plánvání může způsbit, že zavedení SOA se mezí na půvdní aplikační útvary (sila) a architektura se v buducnu plšně nerzšíří napříč aplikačními, datvými a funkčními hranicemi celéh pdniku. Strategická fáze implementace SOA bvykle trvá tři až šest měsíců. Umžňuje účastníkům prjektu splečně pchpit principy a přínsy SOA a je základem pr vytvření plánu neb harmngramu prjektu. Během tét fáze lze vhdnými aktivitami zlepšit infrmvanst zainteresvaných stran výhdách a mžnstech SOA. Přitm je důležité vysvětlit reálné mžnsti nástrjů pr implementaci a prvz SOA, upzrnit na situace, v nichž tyt nástrje mhu zklamat čekávání, a prezentvat mžnsti SOA, kterým se nevěnvala pzrnst během první fáze seznamvání. IT ddělení může například uspřádat wrkshpy, na něž pzve klíčvé zainteresvané sby. Cílem wrkshpů je zvážit specifické ptřeby pdniku i způsb, jakým by SOA mhla tyt pžadavky uspkjit. Nicméně hlavním úklem wrkshpu pr implementaci architektury SOA je vytvření harmngramu jejíh zavádění bvykle dvu- až tříletéh plánu zavedení SOA d prvzu v celém pdniku, jehž sučástí je i plán piltníh prjektu. Přechd k SOA není jediný izlvaný prjekt; jde kmplexní transfrmaci, která zasahuje d mnha prjektů a mění způsb, jakým se IT prvzuje v pdniku. Změny v důsledku tét transfrmace se týkají i vnitřních prcesů vývjvéh cyklu, způsbu, jakým jsu prjekty financvány, a také samtných vývjářských znalstí ptřebných k tvrbě přínsných služeb. 4

5 První piltní prjekt Řím nepstavili za den a stejně je tmu s pdnikvu architekturu SOA. Zavedení SOA je pstupný prces d jednh prjektu ke druhému. Pkud rganizace začne s jedním explicitním piltním prjektem SOA, může se pučit z úspěchů (i nezdarů) a zvýšit úspěšnst celéh zavádění SOA. Obr. 1: Identifikace ptenciálních blastí pr pakvané pužití služeb je důležitým aspektem při zahájení zavádění SOA Aby byl piltní prjekt SOA úspěšný, měl by prjektvý tým pstupvat p jedntlivých krcích. Krk 1: identifikujte cíle pčátečníh piltníh prjektu SOA Cíle pčátečníh prjektu by měly zahrnvat: pakvané pužití služeb, z něhž může těžit více ddělení, slučení duplikátních aplikací na jeden server, vytvření příkladu úspěšné implementace SOA, který bude jasně ilustrvat výhdy pakvanéh pužití a knslidace služeb, 5

6 získání cenných zkušenstí, které lze využít při větším nasazení SOA, pchpení úklů spjených s uvedením služeb d stréh prvzu a také každdenních úklů vyžadvaných d správy SOA v prdukční fázi. Krk 2: vytvřte multifunkční SOA tým Na úspěšných piltních prjektech SOA splupracují ddělení s různým zaměřením. Práce se účastní zástupci linivých úseků, vývje, prvzu, bezpečnsti atd. I když tit zainteresvaní nemusí být s typickým piltním prjektem v každdenním kntaktu, je důležité, že svu účastí v týmu získají zkušenst jak s úskalími, tak přínsy SOA. Pravidelné schůzky a kmunikace dhalí jakékli bavy neb teritriální prblémy, které mhu zbrzdit přechd SOA d prdukční fáze. Členy týmu vybírejte pečlivě a uvažte, zda jsu schpni se zúčastnit práce nad rámec svých každdenních pvinnstí. Navrhněte dbu nutnu pr účast na jednáních a pr čtení kmunikace a vyžádejte si d každéh člena týmu suhlas s tím, že tent čas může prjektu věnvat. Dále vypracujte kmunikační strategii, která zahrnuje rzumný pčet aktualizací psílaných každému členu týmu, a seznamte s ní všechny zainteresvané. Pté se tét strategie držte, abyste nenarušili důvěryhdnst piltníh prjektu a zbytečně nepřišli zpětnu vazbu a účast členů týmu na pradách. Pkud začnete zavádět SOA, s největší pravděpdbnstí se nevyhnete změně způsbu, jakým se aplikace vyvíjejí a nasazují. Většina lidí má tendenci věřit, že nejhrším prblémem při přechdu na SOA jsu změny v týmu a rganizaci, prtže tyt změny chápe jak destrukci sučasných aplikačních útvarů (sil). Výběr členů multifunkčníh týmu pr zavádění SOA je tudíž nejkritičtějším aspektem piltníh prjektu. Obr. 2: Zahájení implementace SOA zahrnuje určení multifunkčních rlí v celém pdniku 6

7 Krk 3: určete vhdný piltní prjekt Abyste mhli přesně a úspěšně prkázat přínsy SOA, musíte nejprve zvlit vhdný piltní prjekt. Ten musí jasně ukázat přísliby SOA a zárveň nesmí djít k narušení jakýchkli aspektů pdnikání. Znamená t realizvat službu s nejlepším pměrem mezi rizikem a přínsy. Úspěch prvníh piltníh prjektu psiluje důvěryhdnst a tevírá cestu k nasazení SOA d prdukční fáze. Při výběru vhdnéh piltníh prjektu si dpvězte na následující tázky: 1. Jak nejlépe začít? Vytvřit nvu službu neb využít již existující? Nvé služby se vytvří snáze, ale zabalíme-li existující půvdní systém d webvé služby, můžeme získat výraznější přínsy a v kratším čase. 2. Zvlit piltní prjekt s vysku neb nízku vizibilitu? Prjekty s nízku vizibilitu: jsu méně riskantní, pkud se během implementace vyskytnu prblémy, umžňují určit priritu prjektu pdle dstupnsti zdrjů bez průběžnéh zkumání. Prjekty s vysku vizibilitu: evkují více názrů a plitických kmplikací, pskytují přínsy dříve a pr více ddělení, umžňují zjistit pžadavky zainteresvaných stran a t, zda je, neb není nezbytné úspěch zviditelnit. 3. Zvlit aplikace generující tržby neb back-endvé aplikace? Nejběžnější piltní prjekty jsu čast spjené s uživatelskými systémy, jak jsu prtály a webvé stránky. Může t být například prtál, který pskytuje suhrnný přehled určitých údajů pr zákazníky neb zaměstnance zalžený na datech sebraných z jednh neb více různých systémů. Čast jde dbru vlbu, prtže knečné výsledky jsu hmatatelné a mhu přinést praktické zkušensti s přínsy SOA. Naprti tmu back-endvá integrace, jak je synchrnizace dat mezi systémy, může být pr pdnik přínsnější, ale jasně demnstrvat tyt přínsy je btížné. 4. Zvlit aplikaci určenu pr interní využití, neb pr zákazníky? V bu případech existují mnhá pr a prti. Interní služby, jak je například aplikace umžňující zaměstnancům aktualizvat jejich sbní infrmace prstřednictvím pdnikvéh interníh prtálu, může chránit zákazníky před ptenciálními prblémy, ale zpětná vazba nemusí dpvídat pzdějšímu širšímu pužití SOA. Na druhé straně by například finanční instituce mhla pužít pr mezený, ale vysce přehledný piltní prjekt službu pr zbrazvání směnných kurzů měn. 7

8 5. Zvlit transakčně rientvanu službu, neb službu rientvanu na dtazy? Služby rientvané na dtazy, jak je například získávání labratrních výsledků ve zdravtnictví, jsu pužívané především pr zpřístupnění existujících dat pr jiné účely. Naprti tmu transakčně rientvaná služba (například registrace nvéh autmbilu) je takvá, která vytváří nvé infrmační záznamy neb spuští nvý pdnikvý prces. Transakčně rientvané služby jsu ve své pdstatě riskantnější, prtže prblémy mhu vést ke ztrátě dat. Prt rganizace častěji začínají se službami rientvanými na dtazy, kterými zpřístupňují dříve vytvřená a zálhvaná data. Pzději je rzšíří i transakčně rientvané perace, prtže mnh zákaznických služeb vyžaduje bjí typ služeb. Například v telekmunikacích by sambslužné webvé stránky měly být schpny realizvat jak sambslužné pskytvání funkcí (tj. transakčně rientvané perace), tak infrmace pžadavcích na službu, účtvací histrii atd. (tj. perace rientvané na dtazy). Krk 4: Kvantifikujte výsledky piltníh prjektu Nejdůležitější výstupy z piltníh prjektu SOA jsu kvantifikvané výsledky. Vyšší management čast vyžaduje kalkulace ROI a také hmatatelné věření úspěchu vašeh piltníh prjektu. Zejména v případě, kdy je prjekt řízen dluhdbě, vytvřte metdu pr průběžné ukládání dat, takže při uknčení prjektu jsu k dispzici přesné a snadn dstupné údaje. Jejich shrmáždění a kmpilace jsu klíčem k rzpčtvému bhájení další fáze jakékli iniciativy SOA. Kvantifikace ROI prjektu SOA Mezi efektivní hdncení návratnsti investic d SOA patří například pčet instancí, v nichž je sdílená služba pakvaně pužita. Každé pakvané pužití vede k úspře nákladů neb mezení tvrby, údržby a prvzu jednúčelvé služby. Pr správný výpčet návratnsti investic d sdílených služeb jsu zaptřebí některé další základní metriky: Náklady na tvrbu/prvz/údržbu sdílené služby, tj. cena za její vlastnictví. Náklady na tvrbu/prvz/údržbu jednúčelvé služby. Pkud je vaše infrastruktura SOA efektivní, měly by být v pdbné výši jak náklady na sdílenu službu. Náklady na pužití existující služby vytvřené jiným subjektem, tj. cena za pakvané pužití služby (alternativu by mhl být vytvření jednúčelvé zákaznické služby). Kntrla tét metriky je pr úspěch SOA kriticky důležitá. Opakvané pužití služby je vlastně integrace je tudíž nutné, aby SOA byla strukturvaná a šl tak kntrlvat náklady na integraci. 8

9 Obr. 3: Kvantifikace úspěšnsti SOA: která iniciativa SOA přináší vyšší návratnst investic? Významnu metriku je i pměr mezi pčtem knzumentů sdílených služeb a celkvým pčtem knzumentů, který udává míru přijetí SOA a ukazuje, jak dbře se rganizace vyrvnává s kulturním přerdem SOA. Nejde přím ukazatel celkvé úspěšnsti zavádění SOA, přest je t významná metrika. Ani pčet vytvřených webvých služeb není ve skutečnsti měřítkem úspěšnsti SOA, ale primárně ukazuje míru přijetí technlgií, na nichž je SOA pstavena. V mnha případech může být tat metrika spíše pužita jak indikátr selhání SOA. Pkud existuje velký pčet webvých služeb, ale jen mál z nich se pakvaně využívá, může t znamenat, že pstup nasazvání SOA ptřebuje určitu revizi. Vedle výše uvedených metd měření bude mít každý prjekt svá vlastní hdncení z hlediska pdnikání a měřítka úspěšnsti SOA. Například vystavení zákaznických infrmací prstřednictvím služby s cílem vytvřit sambslužný zákaznický prtál může znamenat výrazné snížení nákladů na prvz call centra. Tyt přínsy jsu samzřejmě pr každý prjekt jiné, ale v žádném případě by neměly zcela chybět. Dknce i když plánujete frmální piltní prjekt, nedělejte t čistě kvůli přechdu na SOA prjekt by měl pskytnut pdniku skutečnu hdntu. Úskalí testvacích prstředí Úskalí, kterému je třeba se při implementaci piltníh prjektu SOA vyhnut, je jeh mezení puze na testvací prstředí. T sice pskytne týmu pr implementaci piltníh prjektu bezpečné míst pr seznámení se s prblémy a přínsy zavádění SOA, avšak úspěšné závěry labratrníh testvání bhužel nezajišťují úspěch SOA v reálném světě. 9

10 Architektura SOA má ttiž výrazný vliv na každu fázi a změnu živtníh cyklu aplikací (vývj, testvání, zavádění, prdukce a zejména následný přechd na vyšší verze). Prblémy spjené s těmit dlišnými fázemi živtníh cyklu patří mezi nejběžnější příčiny situací, v nichž je prjekt SOA vnímán jak neúspěšný. V testvacím prstředí však takvé zkušensti nezískáme. Přechd na celpdnikvu SOA P úspěšném převdu piltníh prjektu d prdukčníh prstředí nastává čas zkumat tázky týkající se přechdu celéh pdniku na rámec SOA. První piltní prjekt dhalil mnh užitečných infrmací, které se dají využít během přechdu na celpdnikvu SOA. Pečlivě analyzujte, c se během realizace piltníh prjektu pdařil, a cž je ještě důležitější zkumejte, c se nepdařil a jak byly prblémy překnávány. Udržujte dstupnst těcht infrmací, sdílejte je s týmem a čast se k nim vracejte. Je také důležité analyzvat jakékli situace neb prblémy, které nebyly sučástí vašeh pčátečníh SOA prjektu včetně zadávání kmplexnějších bezpečnstních pžadavků, splnění regulačních pžadavků atd. Cílem je zjistit, kde jsu ve vašich znalstech stále mezery. Vedle úspěšných piltních prjektů existují i další klíčvé aspekty, na nichž záleží úspěšnst zavedení pdnikvé SOA. Definice splečných standardů Ve vašem prvním prjektu SOA nemusí být kritickým faktrem úspěchu výběr infrastruktury a technlgií. V kamžiku, kdy se vaše iniciativa přesune d prjektvé na celpdnikvu úrveň, se takvým kritickým faktrem stane schpnst sdílet splečné standardy SOA mezi prjekty. Pkud vaše služby nehvří stejným jazykem, pak pakvané pužití služeb může být btížné a nákladné. T může vést až k selhání celéh zavádění SOA. První úrvní definice standardů je rzhdnutí standardech aplikační interperability tj. jak splu budu služby kmunikvat. Seznam zahrnuje bvykle XML, SOAP, HTTP a UDDI. Krmě těcht základních standardů budete jistě uvažvat i vaší bezpečnstní strategii. Všude tam, kde je t jen trchu mžné, byste měli vlit standardy, ne prdukty. Pstupem dby budete mít mnh různých aplikací a služeb, které splu kmunikují. Některé budu vytvřeny vlastními silami na vašich sučasných aplikačních platfrmách, jiné budu vytvřeny vlastními silami na buducích aplikačních platfrmách (můžete například v určitém kamžiku vyměnit vašeh ddavatele aplikačníh serveru) a ještě jiné budu sučástí kmerčních aplikací. V mnha případech nebude aplikace knzumující služby pstavena na stejné technlgii jak aplikace, která tyt služby pskytuje, a vy se budete ptřebvat ujistit, že vámi zvlené standardy pr kmunikaci služeb nenaruší schpnst přidávat d sítě SOA nvé aplikace. Prt je pr dluhdbý úspěch pdnikvé architektury SOA důležitý výběr tevřených standardů, které jsu pdprvány mnha ddavateli. Existují dva výrazně dlišné typy tevřených standardů: standardy pr rzhraní API (jak JMS, JDBC a ODBC) a standardy pr interperabilitu (jak TCP/IP, HTTP a XML). I když jsu API standardy důležité, stále mají něklik zásadních nedstatků: jsu platfrmvě specifické (například JMS se dá pužít puze v Javě, 10

11 nikli v.net) a jsu ddavatelsky specifické (aplikace, která pdpruje MQ Series nemůže přím kmunikvat s aplikací pdprující TIBCO, i když bě aplikace mhly být napsány pmcí JMS). Abyste umžnili jejich kmunikaci, ptřebvali byste další vrstvu infrastruktury (tj. messagingvé adaptéry). Naprti tmu splu mhu kmunikvat aplikace knzumující služby a aplikace pskytující služby, které pdprují standardy pr interperabilitu (i když jsu psány na výrazně dlišných platfrmách). Abyste se prt vyhnuli mezením pramenícím ze zvlených platfrem, vlte takvé standardy pr interperabilitu, které jsu nejrzšířenější. P vlbě splečných aplikačních standardů pr interperabilitu musíte ještě prmyslet další sadu standardů pr bezpečnst a správu. Kriticky důležitá je sjedncená bezpečnstní architektura. Pkud budete mít mnh meziaplikačních interakcí a pkud má každá aplikace dlišný bezpečnstní mdel, mhu se bjevit bezpečnstní díry a djde ke zvýšení nákladů na správu a údržbu prstředí SOA. Sjedncená strategie řízení umžní získat lepší braz zavádění pdnikvé architektury SOA napříč prjekty. Půjde přitm phled z hlediska pdnikvých prcesů, které pdpruje, nikli útvarů (sil), které vytváří. T umžní efektivnější kntrlu SOA a zajistí její splehlivst a rbustnst. Nezapmeňte, že se již dále nemůžete spléhat na bezpečnst a správu vytvřené na kterékli samstatné platfrmě. Ze stejnéh důvdu ptřebujete splečné standardy pr interperabilitu. Architektury SOA jsu ze své pdstaty hetergenní, ale správa a bezpečnst musí jít napříč celu SOA. Řízení prjektvých týmů Dalším krkem k zavedení celpdnikvé architektury SOA je řízení následných prjektů, jimiž se dstartuje zavádění SOA v širším měřítku a s větším pčtem vývjářů a prjektvých týmů. Tyt týmy musí vstřebat mnh nvých infrmací a získat infrmace mnha úskalích, kterých si nemusí být předem vědmy. Služby vytvřené těmit týmy mhu například mít nestandardní zabezpečení, nemusí být v suladu s prfily WS-I (WS-I definuje prfily, které vysvětlují nejasnsti standardů pr zajištění interperability mezi platfrmami) neb mhu být zaměřeny technicky, nikli pdnikatelsky. Tyt typy prblémů se mhu stát bariérami celéh zavádění SOA, prtže znesnadňují využití stávajících služeb. Naštěstí existují mžnsti, jak takvé prblémy řešit: Šklení: pr využívání nvých nástrjů a technlgií jsu především nezbytné šklicí týmy. Nutná jsu i šklení dpručených pstupů a seznamvání s úskalími. Například šklení vývjářů využití časvých zón v datvých typech Datum může mít vliv na interperabilitu. Infrastruktura: vybírejte sftware pr infrastrukturu tak, aby vývjáři nemuseli prgramvat ve své aplikaci funkce pr bezpečnst, auditing, správu atd. Nejenže se zjednduší a zrychlí realizace služeb, ale také se budu autmaticky prsazvat pdnikvé standardy. Nástrje, které vývjáři mhu pužívat při tvrbě svých služeb, jim mhu pmci i při autmatizvané kntrle prblémů. K dispzici jsu například nástrje, které pmáhají vývjářům zajistit, aby při vytváření služeb dpvídaly jejich definice (WSDL) standardům WS-I. 11

12 Kntrlní bdy: Naknec by tent prces měl definvat kntrlní bdy, v nichž můžete věřvat vhdnst služeb. V těcht kntrlních bdech můžete prvádět autmatizvané vyhdncvání bvyklých prblémů (jak jsu služby, které nedpvídají WS-I neb které se neřídí dpručenými pstupy hledně návrhu schématu), stejně jak manuální revizi kntrl, které nemhu být efektivně autmatizvány (tj. zda pdnik vhdně využívá schválená schémata neb zda je realizvána správná granularita služeb). Samzřejmě dchycení prblému v tét fázi je nákladné může vyžadvat výrazné přepsání neb nvé navržení služby, cž bude mít za následek zdražení neb prdlužení prjektu. Prt byste se na tyt kntrlní bdy měli spléhat až jak na pslední mžnst prcesy by měly být navrženy tak, aby c mžná nejvíce prblémů byl mžné řešit už předem (díky šklení, infrastruktuře a nástrjům) a nedcházel k mrhání zdrji a úsilím. Mnžství prblémů týkajících se kntrlních bdů a infrastruktury vedl k tmu, že se pdniky začaly zajímat gvernanci. Dnes se pdniky zabývají gvernancí většinu z hlediska th, jak navrhnut, vyvinut a nasadit služby. Ale t je jen plvina aspektů spjených s gvernancí. Druhá plvina se týká prvzníh prstředí a zajištění, aby služby byly skutečně v prvzu a řídily pdnikání tak, jak byl zamýšlen. Tyt dva aspekty gvernance se musí řešit splečně. Zárveň je třeba chápat, které části gvernance řídí předprdukční fázi, které řídí prvzní fázi a které pkrývají bě fáze. Rzdělení dpvědnstí Využití infrastruktury, díky níž nemusí prjektvé týmy d svých prjektů zabudvávat funkce pr bezpečnst, auditing, správu apd., umžňuje přirzené ddělení rlí a dpvědnstí ve vaší SOA. Splupráce na SOA znamená, že můžete vytvřit SOA týmy s půsbnstí napříč funkcemi, které budu dpvědné za každu z následujících blastí: bezpečnst, sulad s legislativu neb prvz. Pkud tyt základní dpvědnsti prjektvým týmům debereme, může sice djít ke zkrácení realizace prjektu a prjekt může celkvě mít lepší výsledky, ale také mhu vyvstat nvé překážky. Klíčvý prblém splupráce na zavádění SOA nastane, pkud tyt vícefunkční rle vyžadují pr dknčení svých úklů specifické znalsti. Například: Člen týmu dpvědný za bezpečnst by měl znát příslušná pravidla pr autrizaci vytvření bjednávky versus zrušení bjednávky. Člen týmu dpvědný za sulad s legislativu by měl zajišťvat vynucvání suladu s předpisy týkajícími se zajištění sukrmí, ale nemusí vědět, jaké schématické prvky XML dkumentu takvé zajištění sukrmí vyžadují. Člen zaváděcíh týmu by měl vědět, že pr zajištění úrvně služeb pr významné zákazníky by měl být pužit přesměrvání přes datvá centra, ale že prt, abychm se vyhnuli replikaci dat a prblémům s knzistentnstí, určité perace být přesměrvány nemhu. Člen týmu dpvědný za perace by měl být dstat za úkl vyřešit mnitrvání SLA rzlišených pdle třídy zákazníků, ale nemusí vědět, jak se dá určit, d jaké zákaznické třídy určitý zákazník spadá. Tent prblém řešit lze řešit například tím, že týmy s půsbnstí napříč funkcemi zapůjčí prjektvým týmům členy, kteří d každéh prjektu ptřebné znalsti přinesu. T však čast vytváří při realizaci prjektu úzká místa prjektvý tým musí stát ve frntě a čekat na sbu přidělenu jejich prjektu; navíc se tým stává dpvědný za pskytvání specializvanéh šklení členvi vícefunkčníh 12

13 týmu cž zvyšuje rizika realizace prjektu. Alternativním přístupem je jasně nadefinvat v celé rganizaci klíčvé kncepty specifické pr určité dmény (tj. zákazník, bjednávka, sbní identita ). T pak umžní: aby se týmy s půsbnstí napříč funkcemi zaměřily s využitím těcht knceptů na abstraktní definvání svých pravidel nezávisle na jakékli individuální službě (tj. všechny sbní identity musí být zašifrvány ), aby každý prjektvý tým zvlášť namapval na kncepty svá unikátní data (tj. Tent XML prvek služeb <scn> je sbní identita neb Tat perace může být přesměrvána ). Vícefunkční týmy tak mhu díky tmut ddělení definvat své plitiky puze jednu, zárveň je však mhu aplikvat glbálně na všechny služby. Prjektvé týmy pak mhu být svbzeny d úzkých míst, které vznikají tím, že tyt týmy vyžadují, aby příslušné plitiky byly reimplementvány členy vícefunkčních týmů. Využití existujících aplikací Je vysce pravděpdbné, že pdstatná část existujících aplikací nepdpruje XML a webvé služby ať už byly tyt aplikace napsány v pdniku neb nakupeny zvenčí. I když se rzhdnete některých z nich zbavit, mnh jiných jich zůstane v prvzu. Prt je nutné frmulvat strategii, jak při přechdu na nvé aplikační prstředí SOA využít existující aplikace a umžnit, aby je byl mžn využít jak služby. Existuje mnh různých přístupů. Jeden přístup je ručně naprgramvat webvé služby, které budu fungvat jak baly kl existující aplikace. Výhda tht přístupu je, že můžete tut vrstvu využít k většímu zaměření aplikace na pdnikvé činnsti. Nevýhda je, že vytvřit škálvatelnu, splehlivu a rbustní naprgramvanu službu služící jak bal klem stávající aplikace může být časvě nárčné a btížné. Alternativu je využít již htvé integrační prdukty, jimiž umžníme, aby se existující aplikace chvala jak služba. Může jít řešení zalžená na EAI neb ESB, či adaptér, který přím a najednu knvertuje existující aplikace na webvé služby. Výhdu těcht řešení je vyšší rbustnst, nevýhdu naprti tmu je, že nezjednduší změnu služby existující aplikace vypadá jak webvá služba, ale její rzhraní nemusí být na správné úrvni granularity pdnikvých činnstí. Určitá webvá služba například může mít ddělené perace pr vytvření prázdných bjednávek a pté vyplnění bjednávky řádkvými plžkami naprti tmu dbře navržená bjednávkvá služba by vám měla umžnit vytvření kmpletní bjednávky v jediné peraci. Jde dbrý příklad rzdílu mezi technicku službu (navrženu způsbem, který zcela dpvídá technlgickým pžadavkům) a byznys službu (navrženu pr namapvání na lgické perace, které pdnik vyknává). Výsledkem je, že existují rzdílné způsby, jak zabudvat aplikace, které nejsu webvými službami, d aplikačníh prstředí SOA. Čast je nejlepším pstupem kmbinvat techniky uvedené výše: pužít adaptér, EAI neb ESB pr t, aby existující aplikace mhla fungvat jak technická služba, a pté nad ní naprgramvat vrstvu pdnikvé služby s využitím zvlené platfrmy. 13

14 Přehledy pr vedení Při práci na nvém prjektu realizujícím určitu byznys funkci se využívají všechny vhdné existující služby. Prt je důležité, aby vedení pdniku měl k dispzici celkvý přehled prstředí rganizvaný pdle byznys funkcí, nikli pdle služeb neb prjektů. V minulsti, kdy každé sil služil jak samstatná byznys funkce, byly řídicí panely a jiné nástrje pr pdpru rzhdvání prvázány přím s jedntlivými sily v pdstatě mhly být implementvány stejným prjektvým týmem, který vytvřil danu aplikaci. Naprti tmu byznys-relevantní řídicí panely a nástrje pr pdpru rzhdvání v SOA ptřebují shrmáždit a zkmbinvat infrmace ze všech vzájemně prpjených služeb, z nichž se dnes skládá jedna byznys funkce. T vyžaduje dlišný přístup bvykle jsu týmy a nástrje rganizvány klem byznys funkcí, nikli svázány s jednu určitu službu neb prjektem, které vytvářejí sil. Využití znalstí expertů Jak při jiných aktivitách je i při zavádění SOA výhdné využít znalsti těch, kteří již realizvali více úspěšných implementací a nechat si pradit cenné tipy a triky z praxe. T platí především pr piltní prjekty, prtže úspěch (či neúspěch) piltníh prjektu čast určuje, zda se v zavádění SOA bude pkračvat. Prtže SOA je relativně nvý kncept, budete muset uskutečnit analytický průzkum neb se pr vhdné infrmace brátit na jiné pdniky či ddavatele. Pkud rzpčet dstačuje, spjte se se zkušenu rganizací pskytující prfesinální služby, která vám bude při úspěšné implementaci SOA asistvat Prgress Sftware 14