Dokončení včerejšího článku...
Reálná implementace SOA
Praktické zkušenosti se zaváděním SOA se většinou shodují v několika níže popsaných faktech.
Iniciativa zavedení SOA vychází většinou z IT a byznys na SOA pohlíží jako na „novou hračku pro IT“.
Prvním krokem bývá selekce řešení Enterprise Service Bus (ESB). Výběr konkrétního ESB může po technologické stránce určit, jaký bude další směr v budování SOA. Při nasazování ESB je nutné si stanovit základní cíle, které se mají dosáhnout (například centrální řízení zátěže koncových systémů, centrální auditing apod.), a tyto cíle je třeba neustále sledovat a dodržovat. V této fázi většinou nemá smysl hledat hmatatelné přínosy pro byznys.
Nasazování SOA se děje přírůstkově realizací menších projektů, je ověřeno, že tzv. velký třesk (big-bang) nemá šanci na úspěch. Řízení úvodních SOA projektů by mělo být v kompetenci útvaru IT architektury, ve které by se měla izolovat část věnující se pouze integraci informačních systémů ve společnosti (tzv. ICC).
Jako první by měla vzniknout analýza „sdílených utilitních funkčností“, tj. funkčností, které nejsou spojené s konkrétní podnikovou doménou, jsou používány na několika místech a jejich centralizace zamezuje neustálou znovuimplementaci. Příkladem může být např. odesílání e-mailů, vytváření dokumentů, poskytování informací o adresách apod. Sdílené funkčnosti jsou ideálním kandidátem na ověření přístupu (proof of concept) a jejich převedení do SOA má snadno vyčíslitelné přínosy.
Součástí prvních projektů musí být vytvoření tzv. SOA Governance, což lze volně přeložit jako podpůrné a metodické prostředky pro nasazování a provozování SOA. Jedná se o nastavení procesu životního cyklu služby od žádosti o její vznik až po její vypnutí, o vytvoření metodik vývoje a provozování služeb, a v neposlední řadě tzv. repozitory služeb, což je knihovna popisů jednotlivých existujících služeb, jejich vlastností a principu jejich použití.
Existence této knihovny je klíčová pro úspěch SOA ve společnosti, protože má-li se služba využívat, je nutné, aby každý věděl, že tato služba existuje a kde je možné najít informace o tom, jak ji použít. Při budování SOA Governance je již většinou zformován tým ICC a napříč společností jsou komunikovány jeho pravomoci.
Následným krokem nutným k tomu, aby měla SOA smysl, je zmapování aplikačního portfolia společnosti, a to včetně funkcionalit, které existující aplikace nabízí. Principem SOA je znovupoužívání existujících funkčností, a proto je nutné tyto funkčnosti identifikovat. V této etapě je nutné do procesu nasazování SOA zapojit byznys architekturu, která by měla být odpovědná za návrh a popis podnikových procesů společnosti. V ideálním případě je zavedena spolupráce mezi byznys architekturou a ICC, jejíž výsledkem jsou popsané příslušné procesy a jejich mapování na služby a funkcionalitu koncových systémů.
Z obchodních procesů pak také vycházejí požadavky na implementaci nových služeb. V případě, že se tento krok nepodaří, je extrémně obtížné se v budování SOA posunout směrem vpřed a nemá smysl uvažovat o dalších fázích, jako jsou nasazení Business Process Management Serveru (BPMS) apod. Bohužel jen opravdu málo projektů nasazování SOA se dokáže přes tento bod posunout, a v případě, že se tak nestane, se z konceptu budování architektury SOA ruku v ruce byznysu a IT stává budování architektury, ve které jsou funkčnosti koncových systémů vystavovány jako služby na integrační platformě s jedinou přidanou hodnotou pro podnik – a tou je potenciální snížení nákladů na vývoj. Je to sice dobrý základ pro další posun, ale z pohledu SOA se jedná pouze o zlomek využití jejího potenciálu.
Kam kráčí SOA
SOA jako koncept tu byla, je a ještě nějakou dobu bude. V případě, že se objeví jiný přístup pro budování IT architektury, bude muset být jeho úspěch podpořen i jiným přístupem na straně podnikové architektury. Obrovskou devizou SOA je totiž existující propojení mez dvěma zdánlivě nepropojitelnými světy IT a byznysu mezi světy obchodních procesů a IT komponent.
Je nepopiratelným faktem, že SOA není pro každého (zejména z pohledu pořizovací ceny) a že je nutné nebrat pravidla SOA příliš dogmaticky, nicméně „rozumně“ aplikovaná SOA splňuje většinu z toho, co slibuje (snížení nákladů na integraci systémů, snížení času potřebného pro uvedení na trh…). S určitostí ale lze i konstatovat, že v dnešní turbulentní ekonomice nelze implementaci SOA v úspěšné a fungující společnosti nikdy dokončit a že budování SOA je dlouhodobý kontinuální proces. Stále bude třeba nových funkcionalit a systémů pro podporu nových obchodních příležitostí a stále bude docházet k fúzím a následným architektonickým optimalizacím (slučováním systémů apod.). Architektura SOA je aktuálně nejvhodnějším přístupem pro řešení těchto situací a na obzoru není vidět jejího nástupce – a tedy fáze adjourning je pro architekturu SOA v nedohlednu.