Implementace SOA vyžaduje oběti (1.)

14. 1. 2009

Sdílet

SOA se možná někomu jevila jako spása před špatnou softwarovou architekturou a nekvalitním projektovým plánováním, realitou však zůstává, že jde o velmi obtížný a riskantní podnik.

Také z toho důvodu odpovídá počet neúspěšných SOA implementací počtu těch úspěšných. Jinými slovy, organizace má padesátiprocentní šanci na to, že nebude úspěšná, a pravděpodobnost neúspěchu je dokonce větší, pokud se jedná o velké společnosti nebo o státní správu. Nicméně již existují klíčové modely úspěšných nasazení SOA, jež mohou pomoci určit, zda se implementace SOA ve firmě podaří, či nikoliv.

Zásadní příčinou ne-úspěchu SOA je nedostatek kvalitních lidí pracujících na architektuře, což se týká jak vedoucích pracovníků, tak i zaměstnanců. Nedostatek nevězí v jejich počtu, jde o málo znalostí a vizí potřebných k uskutečnění změn. Neúspěchy SOA, jež mají příčinu v lidském faktoru, začínají už „tam nahoře“. Nedávná studie společnosti Burton Group zjistila, že už jen příchod nového CIO předznamenává úspěch pro nasazení SOA. V podstatě platí, že inovativní vedení a schopnost změnit kulturu a následně i příslušnou architekturu představuje klíčový faktor správného nasazení.

Navíc je pro úspěch SOA důležitá přítomnost vedoucího týmu, který odhadne výši investic do infrastruktury, chápe dlouhodobý přínos schopnosti rychle reagovat na změny – ještě lepší ale je, pokud je ochotný investovat. SOA totiž není levná. Vlastně jde o obrovskou systematickou změnu v architektuře, budování, nasazování, navrhování a testování firemních informačních technologií. Jde o investici, která zdaleka přesáhne desítky milionů korun potřebných na nezbytný trénink, konzultace a následně na technologii nutnou k uskutečnění změn. Investici do SOA také nelze považovat za jednorázový transformační projekt. Namísto toho je třeba SOA pojímat jako proces, nikoliv jako samostatný projekt a – hlavně kvůli rozpočtu – ji brát coby sérii úkonů, které tento proces vytvářejí.

Pro dobrý výsledek nasazení SOA je důležité, aby byla její cena jasně stanovena a závazek docílit této částky byl učiněn předem. Protože SOA je skutečně procesem, nikoliv projektem, podniky potřebují dlouhodobý výhled SOA. Je to víceletý závazek k uskutečňování systematických změn v klíčových IT mechanizmech. Většina SOA „projektů“ je však v určitém bodu zastavena, obvykle kvůli rozpočtovým problémům nebo kvůli potřebě přesměrování prostředků na některé krátkodobější taktické potřeby. Tím pádem SOA nikdy nemá šanci; nikdy se nedotáhne do konce. Výkonný a IT management však tohle nesmí nikdy připustit.


SOA dále zahrnuje dvě zásadní obchodní změny, které IT historicky nemělo možnost uskutečnit: Jednou z nich je sdílení procesů překračující jednotlivá „panství“, což vyvolává strach ze ztráty kontroly. Ta druhá spočívá v tom, že SOA vyžaduje změnit způsob uvažování o základních procesech, což je nejen těžké, ale navíc to i zpochybňuje zavedené zvyklosti, alokaci zdrojů, politickou moc atp.

Na úrovni managementu a zaměstnanců jsou požadavky na lidský faktor vyžadované pro úspěch SOA dokonce ještě zásad-nější. Ačkoliv by mnozí rádi směrovali svůj stávající tým do nového světa SOA, krutou pravdou je, že mnoho členů takového týmu nemá potřebné zkušenosti nebo schopnosti. Musíte učinit některá těžká rozhodnutí předem, jako třeba to, který pracovník je schopen vás posunout vpřed. To ale neznamená, že musíte vyměnit některé zaměstnance nebo rozšířit kolektiv – obojí je totiž nákladné.

Mnoho firem zaměstnává mentory nebo konzultanty, aby pracovníky naučili novému stylu práce se SOA. Jiní investují do SOA tréninku, nebo dokonce přivádějí zcela nové týmy či pracovníky, kteří „budou změně asistovat“. I kdybyste se stavěli na hlavu, nikdy nezkoušejte zavádět SOA s nevhodnými lidmi. Prostě to nebude fungovat.

Chápání procesů IT
Přístup SOA představuje změnu způsobu, jakým se firma staví k architektuře a k vývoji systému. Dříve se mnoho společností postavilo k systému tak, že k sobě přitáhlo cokoliv, co se v danou chvíli jevilo jako výborné řešení taktického problému. Samozřejmé ale je, že taktické problémy vedou k jiným taktickým problémům a tyto organizace pokračovaly v podkopávání architektonické jednoduchosti a efektivity.

Je tedy třeba přistupovat k SOA promyšleně, účelným postupem, který umožní rozložit architektonickou doménu na jednotlivé základní prvky, a ty pak znovu poskládat do SOA. Pokud vaše firma nepatří mezi nejmenší společnosti, potřebujete rozčlenit tyto domény na dosažitelné kousky, které budou moci pracovat sekvenčně a později paralelně.

Pak už půjde udělat nějakou skutečnou práci, což obnáší průzkum informací v problémové doméně, čímž jsou myšleny aplikační sé-mantika a metadata. To obvykle představuje spoustu činností, neboť většina společností nemá kvalitní znalosti svých podnikových systémů na sémantické úrovni. Takže obvykle nejde o proces přezkumu, ale o vytvoření zcela nových řešení. Mnoho pokusů o SOA tento krok přeskakuje, což se negativně projeví na výsledku.

Od informační fáze je nutné se přesunout ke službám: Je třeba definovat stávající a nové služby, jež budou tvořit příslušné SOA. Tento proces spočívá v tom, že uživatel zjistí, co už má, stanoví, co potřebuje, a potom normalizuje služby do použitelné a dobře definované tabulky. Ujistěte se, že jste definovali a zdokumentovali služby, a pak je zpátky propojte s modelem metadat, který jste již dříve vytvořili.

Mějte na paměti, že většinu služeb budou tvořit ty již existující, jež budou zpřístupněny skrze middleware. Většina lidí si myslí, že SOA znamená kompletní vytváření nových služeb, ale tak tomu ve většině případů není. Mnoho pokusů o SOA nedopadne dobře kvůli tomu, že se pokouší znovuobjevovat Ameriku, místo toho, aby řešili aktuální obchodní problémy.

Dále je potřeba definovat a vytvořit proces k provázání služby s podnikovým řešením. Máte k dispozici tři varianty řešení, jak to-ho docílit. Za prvé, můžete vytvořit obchodní aplikaci orientovanou na službu (service-oriented), což je způsob, jak programově propojit službu s procesem či s aplikací. Za druhé, lze využít orchestrační vrstvu (jako je například BPEL) k provázání služeb do podoby příslušného řešení. Za třetí, je možné využít tradiční proces integračních nástrojů k navázání služeb na řešení. Bez ohledu na to, jakou variantu zvolíte, ujistěte se, že jste nezapomněli na design a na požadavky.

Samozřejmě existuje celá řada dalších věci, které se musejí udělat, například vytvoření plánu testů a výběr nástrojů k odzkoušení služeb. Také potřebujete strategii řízení SOA, musíte určit řídící procesy založené na této strategii a vybrat nástroje, jež pomohou zmíněná pravidla vytvořit a vynutit.

Pokračování článku najdete zde...