Integrace firemních systémů: Proč a jak na to?

Adastra | 30.09.2013 | Podniková infrastruktura | Žádné komentáře

Podle slovníkové definice má termín integrace následující význam: sjednocení, splynutí, začlenění, proces spojování ve vyšší celek. V oblasti IT se používá termín systémová integrace, jenž je podle Wikipedie definován jako „sestavení komponentových subsystémů do jednoho systému a zajištění, že tyto subsystémy budou společně fungovat jako systém“ . Co tato definice znamená a jaké možnosti nám integrace nabízí, se dozvíte v následujícím článku.

Proč je potřeba integrovat?

Pokud zavedeme z nějakého důvodu v našem firemním systému integrační vrstvu, zcela určitě to zvýší jeho komplexnost, náklady na jeho správu atd. Nejspíše bude muset vzniknout nové oddělení, které se o tuto integrační vrstvu bude starat a bude ji dále rozvíjet. Protože integrační řešení bývají složitá, bude potřeba najmout dostatečně seniorní (a tedy ne úplně levné) odborníky. Stojí tyto problémy vůbec za to a je nutné investovat do jejich řešení? Pojďme se podívat, jaké důvody vedou k potřebě integrovat firemní systémy a jaké benefity nám může tato integrace přinést.

Na počátku vytváření firemního systému byla, dost možná, jedna monolitní aplikace. Mohla být vyvinuta vlastními silami nebo zakoupena jako krabicové řešení a následně upravena (customizována) pro potřeby našeho podniku. S postupem času, jak se naše firma rozvíjela, přestal tento prvotní systém splňovat potřebné požadavky a bylo potřeba řešit, jak s ním dál naložit.

Jedna z možností by byla vyvinout nebo koupit zcela nový systém, který by aktuální (a nejlépe i ty budoucí) požadavky splňoval. To však není levná záležitost, protože kromě nákladů na systém samotný bude potřeba připočítat přeškolení všech uživatelů starého systému, migraci funkčností a hlavně dat z původního systému do toho nového.

Druhou možností je vytvořit samostatný subsystém, který bude řešit určitou množinu funkcí, nejspíše z jedné domény, jako je např. HR, finance, sklad apod. V tomto subsystému bychom určitě nechtěli držet duplicitní data, která již máme v našem prvotním (a nejspíše primárním) systému. Jenže jak se k těmto datům dostat? Jednoduše – prostě se primárního systému dotážeme. A právě ono dotazování, neboli sdílení dat, je podstatou integrace mezi systémy.

Tři stupně integrace

Integrace je velmi rozsáhlým tématem, na který lze nahlížet z mnoha různých úhlů. Jedním z nich může být stupeň „zralosti“, či rozvinutosti integrace. Tento způsob rozdělení zároveň bývá velice často kopírován historickým vývojem integrace v daném podniku aneb od jednoduchosti ke složitosti.

Integrace „napřímo“
Integrace napřímo, nazývaná také „každý s každým“, „špagetová“ integrace, hvězdicová integrace apod., je v podstatě velmi jednoduchá. A to jak z hlediska architektury, tak z hlediska analýzy a implementace a také z hlediska pozdější správy. Ve výchozím stavu máme dva a více systémy. Jeden z nich (systém A) potřebuje získat data (nebo funkčnost) z jiného systému (systém B). Správce systému A definuje, která data požaduje po systému B a oba systémy se domluví, jakým způsobem a v jakém formátu spolu budou komunikovat. Systém B pak požadovaná data vystaví domluveným způsobem a systém A se na ně dotazuje.

Obrázek 1: Systém A požaduje data, systém B data vystavuje

Obrázek 1: Systém A požaduje data, systém B data vystavuje

Výhodou tohoto způsobu integrace je rychlá domluva mezi dvěmi zainteresovanými systémy. Rychlá bývá i potřebná implementace na obou stranách a požadovaná data tak bývají velmi brzy k dispozici.

Nevýhody tohoto způsobu integrace se projeví, pokud nám začne narůstat počet systémů, které sdílejí data. Pokud například bude systém A potřebovat informace z dalšího systému (systém C), bude potřeba absolvovat stejný cyklus jako při integraci se systémem B. Je pak docela pravděpodobné, že to, na čem se domluví systémy A a B, nemusí odpovídat tomu, na čem se domluví systémy A a C. Může se lišit formát vyměňovaných dat, může se lišit architektura komunikace mezi systémy atd. A to jsme ještě nezmínili, že prozatím spolu nemohou nijak komunikovat systémy B a C. S rostoucím počtem integrovaných systémů tak tyto problémy rostou geometrickou řadou a systém jako celek se pak stává obtížně spravovatelným.

Obrázek 2: Chaotické požadování a vystavování funkcionalit

Obrázek 2: Chaotické požadování a vystavování funkcionalit

Integrační vrstva
Vylepšení předchozího, nejnižšího stupně integrace, spočívá v zavedení nové technologicko-architektonické vrstvy, kterou vložíme mezi konzumenty a poskytovatele dat. Tato vrstva se často nazývá middleware, integrační nebo servisní vrstva. Jejím úkolem je odstínit žadatele o data od jejich poskytovatelů tak, aby vystavená data byla pro uživatele transparentní – nemusí vůbec vědět, odkud data pocházejí, jakým způsobem jsou získána a zpracována. Konzument požaduje data po integrační vrstvě a pouze s ní se domlouvá na formátu dat a způsobu jejich doručení. Integrační vrstva potom data, která jsou požadována po ní, požaduje po dalších systémech, ať už interních nebo externích.

Obrázek 3: Vložení integrační vrstvy mezi konzumenty a producenty dat

Obrázek 3: Vložení integrační vrstvy mezi konzumenty a producenty dat

Výhody integrační vrstvy se dají shrnout do několika bodů:
• Umožňuje mít centrální kontrolu nad tokem dat mezi jednotlivými systémy
• Umožňuje definovat jednotný formát zpráv, které si systémy vyměňují
• Je možné definovat množinu komunikačních protokolů jako integrační standard ve firmě a požadovat jeho dodržování po dodavatelích
• Je možné znovu používat již vystavené služby různými systémy. Tím nedochází k duplikaci volání a služeb
• V rámci integrační vrstvy je možné provádět různé transformace dat

Poslední zmíněný bod se obecně nazývá orchestrace (dat, služeb) a je jedním z nejsilnějších konceptů, který integrační vrstva nabízí a často také jeden z hlavních důvodů, proč je vytvářena. Aktivity, které se skrývají pod pojmem orchestrace. mimo jiné zahrnují transformaci z jednoho formátu dat na druhý (např. XML -> JSON), transformaci z jednoho přenosového protokolu na jiný (např. TCP -> HTTP), dynamické směrování, požadování dat z více systémů (sériově i paralelně), změna typu volání (synchronní -> asynchronní) a mnoho dalších. Plný seznam možností orchestrace je zpravidla dán použitou technologickou platformou, která ale velmi často umožňuje implementovat různá rozšíření, takže konečný seznam možností je velmi široký a schopný řešit všechny myslitelné integrační scénáře.

Obrázek 4: Příklad orchestrace na integrační vrstvě

Obrázek 4: Příklad orchestrace na integrační vrstvě

Benefity ze zavedení integrační vrstvy jsme již zmínili, pokud bychom naopak shrnuli nevýhody, jde zejména o zvýšení komplexity firemního systému zavedením nové vrstvy v komunikaci a s ním spojené odpovídající náklady na pořízení, údržbu a vývoj služeb. Proto je zavedení této vrstvy vhodné až od určitého počtu systémů, které je potřeba integrovat.

Servisně Orientovaná Architektura
Dalším krokem na pomyslné stupnici integrační zralosti je zavedení další, částečně abstraktní, částečně technologické vrstvy nad integrační vrstvou. Částečně abstraktní proto, že některé koncepty této vrstvy jsou definovány pouze metodicky, konvencemi, či jsou implementovány pouze procesně. Částečně technologicky, protože splnění některých konceptů je potřeba ošetřit pomocí vhodné technologie.

Servisně orientovaná architektura (SOA) je téma značně rozsáhlé, dalekosáhle přesahující rozsah tohoto článku. Z našeho pohledu je podstatné to, co nám SOA přináší nad rámec integrační vrstvy – vypíchněme zde tedy několik nejpodstatnějších aspektů.

Vystavené služby mají standardizovaný kontrakt
Pokud je např. naše SOA technologicky založena na webových službách, je základem tohoto kontraktu WSDL (Web Service Description Language) dokument, který dále definuje věci jako zabezpečení, adresovatelnost, směrovatelnost, interoperabilitu atd. Takto definovaný kontrakt se pak používá napříč celou integrační infrastrukturou.

Opětovné použití služeb
Služby jsou už od počátku koncipovány tak, aby mohly být konzumovány více systémy. Princip znuvupoužitelnosti také velmi napomáhá vytváření kompozitních služeb, tedy služeb složených z jiných služeb – je to podobný designový princip jako když ze subsystémů vytváříme systémy.

Použití metadat pro řízení integrace
Aby byla integrační vrstva rozumně použitelná, mohou buď přímo služby nebo přilehlá infrastruktura obsahovat metadata, která umožní automatizaci některých náročných úkolů. Metadata mohou být využita při vytváření katalogu služeb nebo pro zajištění jejich dohledatelnosti (service discoverability).

image009

Obrázek 5: Příklad modulů servisně orientované architektury

Klíčovým elementem servisně orientované architektury je SOA Governance – soubor aktivit, které umožňují servisní architekturu efektivně spravovat a řídit. Mezi tyto aktivity patří mimo jiné správa portfolia služeb, která se stará o plánování nových služeb, podporu těch stávajících a také o udržování verzí vystavených služeb. S tím souvisí i správa životního cyklu služeb, obsahující fáze design, implementaci, nasazení, produkční běh a penzionování služeb. Další aktivitou je správa politik, které omezují chování jak samotných služeb (a tím zajišťují jejich konzistenci), tak i chování klientů, kteří služby konzumují. Důležité je také spravování a monitorování používání služeb, které zahrnuje, kdo a jakým způsobem služby používá.

Jak je vidět ze struktury článku, postupovali jsme od jednoduchého ke složitějšímu. Z toho vyplývají i výhody a nevýhody servisně orientované architektury. SOA je oblast velmi rozsáhlá a velmi komplexní. Její implementace je extrémně náročná na zdroje a kapacity a při jejím plánování je potřeba uvažovat v řádu let. Implementace v sobě také skrývá řadu rizik, která mohou celý projekt značně znesnadnit a někdy i znemožnit. Na druhou stranu od určitého rozsahu firemního systému může být SOA tím nejefektivnějším způsobem integrace, který významně zlevní náklady na integrování jednotlivých subsystémů a zároveň přináší (jaksi mimochodem) i další, výše zmíněné benefity.

Obrázek 6: Příklad modulů SOA Governance

Obrázek 6: Příklad modulů SOA Governance

Jak nákladná je vlastně integrace?

Odhady, sledování a vyhodnocení nákladů na implementaci a provoz řešení jsou standardní součástí softwarového inženýrství a nejinak by tomu mělo být i u integrace systémů. Ovšem s výjimkou SOA, která toto má zahrnuto přímo v sobě, se tato oblast dost často neřeší. To je dáno zejména komplexností problému, který integrace adresuje – integrované systémy jsou ve skutečnosti heterogenním distribuovaným systémem s masivním paralelním zpracováním informací. Monitoring takového systému je velmi složitý a nákladný, a proto se od něj buď upouští nebo se odsouvá do budoucna „až na to bude čas a prostředky“.

Pokud bychom chtěli vyhodnotit náklady na integraci u jednotlivých stupňů integrace, měli bychom se opírat o „tvrdá“ data, která se ale většinou nesbírají. U přímé integrace se nám náklady rozpadají na propojení jednotlivých systémů a ty postupně (teoreticky exponenciálně) rostou se zvyšujícím se počtem systémů. Naopak u integrační vrstvy, kdy počáteční náklady jsou vysoké z důvodu samotného pořízení této vrstvy (aniž třeba ještě bylo něco integrováno), se náklady na integraci s každým dalším systémem snižují, až se, od určité velikosti firemního systému, dají více méně zanedbávat.

Jestliže jsme si v tomto článku představili tři způsoby úrovně integrace, neznamená to, že je to takto také striktně dáno. Naopak je velmi časté, že se tyto způsoby ve firmě prolínají, někdy dokonce i všechny tři. Důvodem často bývají právě náklady – máme např. zavedenou integrační vrstvu nebo SOA, ale pro jeden systém potřebujeme udělat výjimku a napojíme ho napřímo. Může jít o nějaký starší systém, který námi požadované integrační technologie není schopen používat nebo by náklady na propojení přes integrační vrstvu byly řádově vyšší, než při integraci napřímo.

Kromě toho, že integrace systémů bývá chápána velmi často přes svůj technologický rozměr, není od věci se na ni podívat také jako na určitý koncept. Pokud se rozhodujeme, jakým způsobem budeme integrovat dva systémy, měla by tomu samozřejmě předcházet zevrubná analýza. Zároveň by však výsledek měl být v souladu s firemní IT strategií.

Autor je odborníkem ve společnosti Adastra.

Zanechte komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *


sedm − tři =

Můžete používat následující HTML značky a atributy: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Copyright © ICT manažer | ISSN 1805-5486 | SEO optimalizace a přizpůsobení SEO-care.cz