Abeceda SOA

Služby jsou kusy nebo součásti softwaru konstruované tak, aby mohly být snadno propojeny s dalšími součástmi softwaru. Myšlenka takovýchto služeb je prostá: technologie by měla být vyjádřena v celcích, které jsou lidé z byznysu s to chápat, spíše než v podobě tajuplných aplikací typu ERP nebo CRM.

Jádrem koncepce služeb je abstrakce, myšlenka, že můžete soustředit softwarový kód do celku (kusu) dostatečně významného na to, aby bylo možno jej sdílet a opakovaně využívat v řadě různých oblastí firmy. Například existuje velké množství softwarového kódu, který se používá k vytváření automatizovaných úkolů, jako například k odesílání dotazů na internetové stránky pro zjišťování úvěruschopnosti s cílem zjistit, zda se zákazník kvalifikuje pro poskytnutí půjčky. Pokud však programátoři v dané bance dokáží celý tento kód abstrahovat na vyšší úroveň - tj. vzít celý tento kód, který byl napsán pro vyhodnocování úvěruschopnosti, a zabalit jej do jedné jediné jednotky s názvem "vyhodnocení úvěruschopnosti" - mohou pak tito programátoři onen kus softwaru opakovaně využít v libovolném dalším případě, kdy se banka rozhodne uvést na trh nový produkt v oblasti půjček, který bude vyžadovat stejné informace, a nebudou tak muset psát tento kód znovu od samého začátku, jak by tomu jinak bylo.

Jaký je rozdíl mezi SOA a webovými službami?

SOA je překlenující strategie pro budování softwarových aplikací v rámci jedné společnosti - představte si plán architekta - až na to, že v tomto případě architektura vyžaduje, aby veškeré kusy softwaru, který má být vybudován, používaly zvláštní metodologii softwarového vývoje, označovanou jako programování orientované na služby (Service-Oriented Programming). Webové služby oproti tomu jsou souborem standardních komunikačních mechanismů vytvořeným na základě internetu. Webové služby jsou propojující s komunikační metodologií. SOA je obecná, zastřešující IT strategie.

Jak zjistím, zda je vhodné, abych přijal SOA za svoji strategii?

SOA, vzhledem k tomu, že se jedná o strategii architektury, zahrnuje daleko více než jen budování softwaru. Vytváření architektury založené na portfoliu služeb vyžaduje, aby CIO dokázal přesvědčivě argumentovat ve prospěch celopodnikové architektury, centralizované metodologie vývoje a centralizované skupiny projektových manažerů, architektů a vývojářů. Vyžaduje také odhodlaného CEO a vedoucí pracovníky, kteří budou urovnávat cestu k tomu, aby se IT mohlo vrhnout na klíčové podnikové procesy. Pochopení těchto procesů a získání lidí pro sdílení v rámci podniku jsou klíčovými faktory transformace podniku na základě SOA.

Řízení je rozhodující. Aby služby mohly být opakovaně využívány v celé společnosti, musí existovat jedna centralizovaná metodologie vývoje softwaru, aby různé oblasti podniku nebudovaly stejnou službu různým způsobem nebo nepoužívaly spojení, jež jsou nekompatibilní. Musí existovat centralizovaný sklad či úložiště, aby vývojáři věděli, kde služby hledat - a aby lidé z IT věděli, kdo je používá. Tyto služby musejí být dobře zdokumentovány, aby vývojáři věděli, k čemu slouží, jak je propojovat a jaká jsou pravidla pro jejich používání. (Například některé firmy účtují poplatky za využívání služeb a vytvářejí dohody o výkonech, aby zajistily, že služby budou fungovat a nebudou příliš zatěžovat firemní síť.)
Většina firem, které se vydaly cestou SOA, si vytvořila centralizovanou skupinu pro architekturu; ta vybírá procesy, jež budou tzv. service-enabled, tedy zpřístupněny pro služby, a konzultuje s různými oblastmi ve firmě budování specifických služeb. Tato centralizovaná skupina také vytváří vhodné mechanismy pro řízení. Pokud všechny požadavky na služby musejí procházet přes tuto skupinu, metodologie vývoje služeb, projekty a výkonové dohody se dají snáze řídit.

Jaké jsou výhody SOA?

Za prvé se na přínosy SOA podívejte perspektivně. SOA je jakási kosa, pod jejímž ostřím padají složitosti a redundance. Pokud vaše firma není velká či složitá, tedy nejsou zde více než dva primární systémy, které vyžadují určitou úroveň integrace, není pravděpodobné, že by vám SOA mnoho přinesla. V celém tom horečném povyku kolem SOA se dnes ztrácí skutečnost, že vývojová metodologie sama o sobě žádný reálný přínos nemá - to, co je přínosem, jsou až dopady, jaké má na složitou, redundantní infrastrukturu. Architekti říkají, že udělat dobrou aplikaci orientovanou na služby dá víc práce než provést tradiční aplikační integraci. (Průzkumy trvale ukazují, že SOA se ve většině firem používá pro tradiční integraci aplikací.) Takže vývoj SOA vlastně vyžaduje v první fázi náklady navíc. Aby tato práce měla nějaký přínos, musí eliminovat nějakou jinou práci někde jinde, protože metodologie sama o sobě obchodní benefit nevytváří. Proto dříve, než začnete zvažovat, zda vám SOA něco přinese, musíte zjistit, zda máte ve firmě redundantní, špatně integrované aplikace, které by bylo zapotřebí konsolidovat nebo eliminovat přijetím SOA. Pokud tomu tak je, nějaký potenciální přínos to pro vás zřejmě mít může.

Abyste získali ucelenou představu o přínosech, které jsou se SOA spojovány, musíte se na ni podívat ve dvou rovinách: za prvé je třeba vidět taktické výhody vývoje orientovaného na služby a za druhé výhody SOA jakožto celkové strategie architektury.

Výhody vývoje orientovaného na služby

Opakované využití softwaru: Pokud balík kódu, který představuje službu, má správnou velikost a rozsah (což je velká otázka, jak říkají veteráni SOA), pak jej bude možno využít v libovolném příštím případě, kdy vývojový tým bude potřebovat tuto konkrétní funkci pro novou aplikaci, kterou bude chtít vytvořit. Například telekomunikační společnost může mít čtyři různé divize, každou z nich s vlastním systémem zpracovávání objednávek. Všechny tyto systémy provádějí určité analogické funkce, jako je například tzv. credit check (přezkoumání bonity) a prohledávání záznamů zákazníků. Protože ale každý z těchto systémů je vysoce integrovaný, žádná z těchto redundantních funkcí nemůže být sdílena. Vývoj orientovaný na služby vezme všechny kódy potřebné k vytvoření jedné verze credit checku, která může být následně sdílena všemi čtyřmi systémy. Tato služba může být naprosto nový kus softwaru, nebo to může být kompozitní aplikace sestávající z kódů některého či všech těchto systémů. Bez ohledu na to je onen kompozit "zabalen" do složitého rozhraní, které jeho složitost skrývá. Příště, když vývojáři budou chtít vytvořit aplikaci, jejíž součástí bude přezkoumání bonity, napíší jednoduše link k této kompozitní aplikaci. Nemusí si lámat hlavu s prolinkováním s jednotlivými systémy - dokonce ani nemusí vědět nic o tom, jak byl kód sbalen nebo odkud pochází. Stačí, když k němu vytvoří spojení.

Zvýšení produktivity: Pokud vývojáři využívají služby opakovaně, znamená to, že softwarové projekty mohou postupovat rychleji a stejný vývojový tým může pracovat na více projektech. Integrace se výrazně zlevňuje (alespoň o 30 procent, odhaduje Gartner) a je také rychlejší, vývojové cykly nových projektů se zkracují řádově o měsíce. Díky katalogu služeb se firma může obejít bez nutností vytváření projektového týmu pro vývoj procesu objednávání telefonních linek, protože služby potřebné k sestavení tohoto procesu již existovaly.

Vyšší rychlost: I když služby nebudou využity opakovaně, mohou mít svou cenu, pokud povedou ke snazší modifikovatelnosti IT systémů. Například u ProFlowers.com neexistují redundantní aplikace ani podnikové jednotky domáhající se služeb. Rozštěpení procesu objednávání květin do nespojitých služeb znamená, že každá složka může být izolována a změněna podle potřeby, když je třeba nutné zvládat výkyvy poptávky spojené například se svátky.

Výhody strategie SOA

Lepší propojení s byznysem: SOA představuje celkový obraz veškerých obchodních procesů a toků ve společnosti. Znamená to, že si lidé realizující obchodní činnosti mohou poprvé vizualizovat, jak je jejich činnost stavěna ve smyslu technologie. Když jsou IT projekty převedeny do podoby obchodních aktivit a procesů spíše než složitých softwarových aplikací, obchodníci je mohou lépe ocenit a podporovat. Velká vize, pokud jde o SOA, je, že až jednou IT dosáhnou toho, že hlavní procesy byznysu budou zcela zpřístupněny pro služby, lidé z obchodu budou moci sami kontrolovat modifikace, mísení a slaďování různých služeb do nových kombinací procesů, jaké oni sami potřebují. Ale tato budoucnost je skutečně ještě hodně vzdálená.

Lepší způsob, jak předkládat architekturu obchodníkům (a IT): Podniková architektura dlouho byla pojmem, který byl tabu a nesměl se prakticky ani vyslovovat. Někteří CIO se mu v hovorech se svými partnery z obchodní části vyhýbali hodně velkým obloukem, aby je nevyděsili, nezaplašili nebo prostě jen neunudili k smrti. Podniková architektura vždycky byla velká, obtížná a nákladná záležitost a návratnost investic v tomto směru byla pro byznys poměrně neprůhledná. Standardizace, mapování a kontrolování IT prostředků neznamená, že obchodní činnosti budou zřetelně flexibilnější, efektivnější nebo ziskovější. V důsledku toho snahy v oblasti IT architektury často selhávají nebo končí ve slepé uličce. SOA nabízí hodnotu, která ve staré podnikové architektuře málokdy byla něčím víc než jen nejasným příslibem. Opakované využití, zvýšená produktivita a rychlost v IT a softwarová infrastruktura vyladěná na specifické obchodní procesy jsou vějičky, na které se dá podniková sféra nalákat. Mějme ale na paměti, že architektura není pro každého. Malé nebo silně decentralizované firmy nemusejí být schopny plně využít centralizovaných týmů projektových manažerů, architektů a vývojářů.