Na ITBIZ.cz nyní dáváme prostor třídílnému seriálu, který je zaměřen na vybrané části SOA důležité pro vytvoření kvalitní architektury. První díl stručně shrnuje principy SOA a jak poznat, zdali je SOA vhodná právě pro vaši organizaci. Na závěr jsem slíbil, že se dále podíváme na organizačně-praktickou stránku celé věci neboli tzv. governance.
Tomáš Kadlec
Charakteristika governance
Termín governance obecně představuje řídící rámec definující role, odpovědnosti, pravomoci a způsob komunikace. Cílem je vybavit organizaci jasně definovanými pravidly pro efektivní plnění svých cílů. Součástí je rovněž měřící a kontrolní systém. Specifickým případem je pak IT governance, jejíž součástí je navíc i rozvoj IT architektury. Governance zde pak slouží i jako kontrolní rámec, ve kterém je realizován koncepční rozvoj v souladu s architektonickými principy.
Není tedy překvapivé, že SOA jako jedna z architektur IT systémů definuje vlastní pravidla governance, která představují specifické rozšíření tradiční IT governance. Je nutné si uvědomit, že jednou z hlavních charakteristik SOA je horizontální distribuovanost komponent (služeb), která jde přes organizační strukturu společnosti. Logické je, že nároky na koordinaci, komunikaci a způsoby řešení rozdílných priorit jsou vyšší než u tradičních přístupů. Kromě toho je zde i celá řada nových aspektů jako:
A) Identifikace, definice, vývoj, registrace a publikace služby, provozování, verzování a odstavení služby,
B) Finanční aspekty provozování služby z hlediska poskytovatele resp. konzumenta,
C) Bezpečnost,
D) Obchodní a technický monitoring,
E) Problematika SLA – Service Level Agreement.
Otázka tvorby nové služby
Jak postupovat v případě tvorby nové služby? Určitě se shodneme na tom, že najít kandidáta na službu není žádný problém. Všude tam, kam se podíváte, je „služební“ potenciál. Ať již použijete některé „top-down“ techniky umožňující dekompozici vybrané funkční oblasti organizace (např. IBM CBM – Component Business Modeling), nebo naopak inventarizační „bottom-up“ přístupy vycházející z existujících rozhraní a aplikací, kandidátů bude v každém případě dost.
Je tedy vhodné sestavit a udržovat portfolio kandidátských služeb, a to nejlépe ve formě hierarchického stromu, který umožňuje kandidáty přehledně klasifikovat a třídit. Portfolio se následně bude postupně zaplňovat již realizovanými službami. Každý projekt by měl vycházet z portfolia služeb a návrh cílové architektury by měl zároveň zahrnovat využití existující služby nebo novou implementaci ze seznamu kandidátů.
Jak se ale rozhodnout, která služba je tou nejvhodnější, kterého kandidáta skutečně vybrat jako službu? Zde je nutné sestavit střízlivý seznam kritérií, která musí kandidát splňovat. Metodologie IBM SOMA (Service Oriented Modeling and Analysis) toto definuje jako tzv. Litmus test. V podstatě se jedná o strukturovaný dotazník, který v první řade zkoumá návaznost na obchodní cíle, ochotu službu financovat a sdílet, ale rovněž i potenciál pro snížení existujících redundancí. Dále se zkoumají i technické aspekty servisní orientace s ohledem na budoucí implementaci. Jedná se např. o pokrytí mimofunkčních požadavků vzájemné závislosti, technologickou neutralitu, kvalitu definice rozhraní dané komponenty apod.
Výsledkem je standardizované a transparentní posouzení příslušného kandidáta. V případě negativního výsledku je pravděpodobně lepší použít klasický způsob implementace. Co když vám ale neprojde žádný kandidát? V tom případě máte na semaforu červenou a něco je špatně.
Neopomenutelnou oblastí je přirozeně finanční stránka celé věci. Tradiční způsob, jakým je IT v současné době financováno, na SOA často zapomíná. Jednoduše chybí uvažování v servisním stylu.
Je tedy nutné pozměnit finanční model, umožnit poskytovateli službu prodávat a na službě vydělávat (minimálně virtuálním způsobem). Konzumenti služby si naopak musí zvyknout na skutečnost, že se na vývoji služby a jejím dalším rozvoji musí také podílet.
Důležité best practices
Na závěr se ještě podíváme na několik „best practices“, na které je dobré pamatovat:
— Koncepční a plánovaný postup, a to již od „laboratorních“ pokusů a malých projektů, kdy každý projekt ověří jednu z částí vaší SOA architektury. Je nutné se smířit s faktem, že SOA nevznikne ze dne na den, ale postupně projekt po projektu a ještě dlouho bude koexistovat se současnými architekturami v organizaci.
— Klíčové je vybrat si správný projekt. Vhodným kandidátem je v současné době automatizace obchodního procesu. Výhodou je zde především spojení s obchodními cíli organizace minimálně prostřednictvím zrychlení příslušného procesu. Zároveň se zjednodušuje výběr potenciálních kandidátů na „službu“. Pro tyto účely existuje řada kvalitních procesních platforem s využitím BPEL standardu, od IBM je to např. WebSphere Process Server. Naopak nevhodným příkladem je postupná „systematická“ příprava současných aplikací na budoucí roli služby. Chybí tu vazba na reálnou obchodní potřebu, návratnost investice je problematická a v neposlední řadě je zde samoúčelné zvyšování komplexity kódu v důsledku vývoje servisní obálky kolem aplikace. Je to přesně opak toho, čeho jste chtěli dosáhnout.
— SOA projekt není o vlastní implementaci, ale o zvolení správné architektury.
— Součástí SOA projektu je i aspekt governance. To, co vám projde u běžné aplikační implementace, může naopak zahubit servisní implementaci.
— Najděte vlivného a trpělivého sponzora. Protože SOA je dlouhodobá iniciativa, která je těsně provázána s obchodní strategií společnosti, tak zde platí „čím výše, tím lépe“. Na druhou stranu se nezapomeňte vašemu sponzorovi odvděčit rychlým úspěchem, který pomůže etablovat SOA a umlčí kritiky.
— Komunikace, komunikace, komunikace je jednoznačně tím nejdůležitějším faktorem. Ostatně každá architektura stojí a padá s tím, jak jsou spokojeni její „stakeholders“. SOA je vlastně jako týmový sport, proto je klíčové, do jaké hloubky a jak dobře učiníte „stakeholders“ aktivními účastníky na vaší cestě k SOA.
Na tomto místě končí druhá část našeho seriálu. V třetí, závěrečné části se podíváme na módní trend Web 2.0 a jak jinak, než ze SOA perspektivy.
Profil
Autor v roce 1994 ukončil jadernou fakultu ČVUT. Od roku 1996 je zaměstnán v různých technických pozicích ve společnosti IBM. Od roku 2004 pracuje jako IT architekt v IBM Software Group se zaměřením na finanční a průmyslové podniky. V roce 2006 získal Open Group ITAC certifikaci v oblasti IT Architektury.
Odkazy a reference:
SOA Governance and Service Lifecycle Management
Exploring the fundamentals of architecture and services in an SOA
IBM RUP for Service-Oriented Modeling and Architecture V2.4
IBM Rational Method Composer plug-in for SOA Governance V1.0
Implementing Technology to Support SOA Governance and Management
Přečtěte si také
