Při ideální implementaci architektury SOA jsou rozeznány všechny dostupné informace a pochopeny veškeré relevantní interakce dat. Každý jedinečný element dat existuje pouze jednou a lze ho efektivně načíst. V tomto ideálním scénáři lze snadno navrhnout přidružené služby k získání a prezentaci informací v nejvýstižnějším či nejvhodnějším formátu. Veškerý hardware, software a data vyhovují a jsou bez potíží integrovány. Je zavedena infrastruktura lidské podpory, potřeba údržby je minimální a přínos služeb je doveden k dokonalosti.
To je krásná fantazie, ne? A teď zase zpátky na zem.
Praktická SOA
Ve skutečnosti má jen pár podnikových řešení tak komplexní cíle. Většina IT projektů vyžaduje kooperativní či sdílený přístup, což přináší spíše kompromisy, překryv dat a duplicitní procesy než optimální efektivitu. Nemůžete si dovolit náhradu celého systému (jinými slovy, počítačoví nadšenci si vždy nemohou dělat to, co by chtěli). Mnohem praktičtějším přístupem namísto zaměření veškeré pozornosti na závěrečný cíl je vyhodnocení vlastní cesty za případnými ideály SOA. Uvážení rozdílu mezi implementacemi interní a externí architektury SOA takovou analýzu umožňuje.
Finanční odvětví je často citováno jako modelový příklad pro implementace architektury SOA, protože tato řešení podporují jak externí, tak i interní požadavky zákazníků. Ať již záměrně, nebo náhodou, tyto snahy určitě nezačaly formálním návrhem architektury SOA.
Mnoho finančních organizací si spíše náhodou uvědomilo hodnotu zákaznických informací agregovaných prostřednictvím jednoho rozhraní. Musely pracovat na shromažďování informací z nesourodých systémů, aby získaly použitelný výchozí produkt. Elementy služby přinášely zapouzdření, abstrakci, opětovnou použitelnost, kombinovatelnost a autonomii součástí ještě před tím, než byly tyto koncepty formálně definovány jako součást architektury SOA. Není to hezké mít náskok před vznikem populárních slov?
Když banky začaly prvně nabízet internetový přístup, byly technologie poháněny spíše nezbytnou konkurenceschopností než jakýmikoli strategickými návrhy. Spojnice mezi back-endovými systémy a zákazníky vytvořily služby, které nakonec mohla využívat také interní oddělení.
Od interní k externí
Vývojáři ve všech odvětvích často rozlišovali mezi externě a interně založenou architekturou SOA, nebo alespoň odděleně zjišťovali její náročnost. Výsledkem byly velmi rozdílné přístupy s identifikovatelnými fázemi, časovými harmonogramy a pravděpodobnou cestou vývoje architektury SOA.
Řada průzkumů North American Developer Survey, které provádí společnost Evans Data už několik let, sledovala postupný posun důrazu z interní na externí architekturu SOA. Většina vývojářů stále věnuje většinu své práce interně zaměřené architektuře SOA a naznačuje, že před plnou a nákladově efektivní implementací robustních externích řešení je nejprve nutné zajistit vlastní infrastrukturu podniku. Avšak navzdory interním požadavkům pokračují snahy v externí oblasti, protože to podporuje i interní změny. Vyhodnocení a implementace součástí služeb jsou například prováděny v jiném pořadí.
Infrastruktura, architektura a technologie pohánějí snahu o vytvoření interní SOA. Implementátoři se zaměřují na migraci dat a často používají přístup „systém po systému“ – vývojáři tak upravují každý projekt zvlášť tak, aby poskytoval nejzákladnější běžné rozhraní k plně sdíleným datům a službám.¨Takto lze vytvořit rozdrobenou interní architekturu SOA, která umožňuje současný přístup pomocí zastaralých rozhraní při probíhající migraci k plně integrované dodávce služeb. To však neznamená, že je to snadné.
Mnoho interních systémů bylo navrženo nebo pořízeno už s proprietárními centrálními skladišti dat, která postrádají interoperabilitu vyžadovanou architekturou SOA. Tento starý způsob návrhu pak může přinést rozpočtové potíže. Obhájení nákladů na architekturu SOA je nejtěžší, když mají data obrovský objem a byla vytvořena pro konkrétní oddělení či podnik. Úsilí o interní architekturu SOA vyžaduje nákladnou migraci systému nebo dat, a to ztěžuje přesné vyčíslení návratnosti investic. Je potřebný silný podporovatel projektu a příslib od vrcholového managementu ohledně financování. Související projekty mohou trvat roky a překračovat jedno fiskální období.
Pozitivní stránkou věci ale je, že úsilí o interní architekturu SOA směřuje k lepší shodě se zásadami a řízením praktického managementu. Je tím podpořena podniková jednolitost i ucelenost a zároveň umožněn přístup udělat vše správně napoprvé. Harmonogram realizace však může být z těchto důvodů delší.
Jakmile je zavedena, může být interní architektura SOA přizpůsobena mnoha produktům a řízena či vyhodnocována z hlediska úspěchu při dosahování podnikových cílů. Projekt lze rozdělit do fází za účelem lepšího řízení a zaměření na specializované prostředky (jako třeba zabezpečení systémů či návrh webového rozhraní), namísto opakování souvisejících a potenciálně nákladných činností. Interně vytvořená řešení jsou použitelná pro mnohem rozmanitější situace.
Externí SOA
Úsilí v externí části má tendenci vyvíjet se na základě strategie dodávky služeb. Shromažďuje se a dodává se pouze takový obsah, který je potřebný ke splnění požadavků spotřebitelů nebo obchodních záměrů. Externí architektura SOA vyžaduje, aby společnost stanovila celou trasu dodávky služeb. Řešení musí často zahrnovat procesy podávání objednávek, plnění, zabezpečení, auditu, fakturace a plateb, ale také současně získávání a údržbu profilu zákazníka. Externí webové služby jsou obvyklým indikátorem toho, že může být použita architektura SOA, ačkoli jen některé doručovací mechanizmy webových řešení kompletně vyhovují zásadám SOA.
Je často snazší identifikovat a splnit požadavky vnějších zákazníků (které jsou ojedinělé, nebo cílené) než se vyrovnat se specializovanými požadavky rozdílných interních divizí a oddělení (všechny obvykle chtějí upřednostnit své potřeby). Jakmile je na základě konceptu SOA vytvořena externí trasa, můžete udržet spokojenost zákazníka pravidelnými změnami podle jeho požadavků. A co je ještě důležitější – zvýší se pravděpodobnost toho, že někdo za vývoj softwaru zaplatí. Můžete také porovnat vybudování externí architektury SOA s tvorbou zisku a posoudit návratnost investic.
Nevýhodou je, že omezený a na zákazníka zaměřený přístup vytváří závislost společnosti na tržních změnách a ne vždy podporuje možnost vyhodnocení a opravu vytyčeného směru. Zdvojení systémových funkcí a informačního obsahu je běžné, protože je málokdy čas na vyčkávání, než dojde k migraci interního systému na nově vzniklé řešení.
Externě zaměřená architektura SOA méně často splňuje požadavky na poskytování informací či reporting pro interní oddělení a provozní informace jsou považovány za až druhořadé.
Závěrem
Koncepty a komponenty architektury SOA se mezi interním a externím nasazením neliší. Každý přístup se jen pokouší vypořádat s obchodními procesy poněkud jiným způsobem tak, jak se mu to jeví nejúčinnější vzhledem ke stávající obchodní strategii, procesům a technologiím.
PŘEDPLATNÉ
ČLÁNKY DO MAILU