Systémová integrace na úrovni informačního systému má za úkol sladit definici a správu požadavků, které vznášejí jednotlivé obchodní jednotky (BU, business units) na odpovídající aplikace. Nekoordinovanost tohoto postupu má pak za následek problémy se zahlcením systému mnoha požadavky téhož druhu řešenými v různých subsystémech či s následnou integrací jednotlivých aplikací. Také může dojít k potížím při konsolidaci výstupů na datové úrovni. Pokud dvě aplikace používají různou identifikaci klienta, může například nastat problém při určování toho, jaké produkty patří stejnému klientovi. Definice správného zadání a efektivní realizace jsou dvě klíčové podmínky pro finální úspěch systémové integrace.
Systémová integrace nabízí řešení prostřednictvím jednotek systémové integrace (SI). Ty představují novou strukturu mezi jednotkami zodpovědnými za informační systémy. Tyto jednotky jsou založené především na společné metodice a jejich schopnosti vzájemně konsolidovat požadavky. Tato metodika definuje procesy a postupy (poskytuje šablony, upravuje úroveň detailu atd.), které se používají při definování a zadávání požadavků a při komunikaci všech zúčastněných stran. Další nezbytnou podmínkou je udržení know-how pro jednotlivé oblasti BU i IS tak, aby byla zajištěna nezávislost know-how na jednotlivých lidech. Sféra přenosu požadavků mezi obchodními jednotkami a jednotkami zodpovědnými za IS je jen jednou z oblastí, v nichž se systémová integrace uplatňuje. Další oblastí je samotná realizace požadavků, tedy transformace požadavku na informační systém do jeho konkrétní implementace.
EFEKTIVNÍ REALIZACE
Při realizaci požadavků se velmi často naráží na fakt, že množství realizovatelných požadavků je zbytečně limitováno dlouhou řadou faktorů. Zásadními omezujícími činiteli jsou například použité technologie, zejména jejich špatná škálovatelnost nebo nevhodná životnost. Nevhodně použité realizační postupy, stejně jako nedostatečně zvládnuté zdroje (nedostatek kvalifikovaných pracovníků či obtížná použitelnost externích zdrojů/dodavatelů), mohou závažným způsobem ohrozit realizaci projektů. Cílem dobře zvládnuté systémové integrace je eliminace těchto rizik.
Jednotka SI přebírá zodpovědnost za koordinaci všech projektů v rámci dané části BU a je zodpovědná za eliminaci výše zmíněných faktorů. Tato jednotka sleduje a koordinuje použité technologie (např. definuje a udržuje seznam schválených technologií nebo aktuální a plánované výkonnostní nároky na harware i software), použité realizační postupy (výběr, úpravu a dodržování metodiky, přičemž jedním ze základních požadavků při výběru může být jednoduchá realizace paralelních projektů) a rovněž zdroje (stanovení podmínek pro externí dodavatele nebo postupy pro realizaci externích projektů). Aby mohla svoji činnost vykonávat, musí jednotka SI vytvořit a dlouhodobě udržovat metodický set závazný pro všechny zúčastněné. To také umožní, aby bylo množství realizovaných požadavků limitováno pouze velikostí dostupného rozpočtu. Systémová integrace je standardní součástí všech informačních systémů vyvíjených nebo implementovaných ve velkých a rozsáhlých organizacích. V řadě projektů se dokonce vyčleňuje jako samostatná část. Systémová integrace však nespočívá jen a pouze v informačním systému…
„OSTRŮVKOVÉ SYSTÉMY“
Organizace si za dobu své existence implementovaly mnohdy celé zástupy vzájemně separovaných systémů. Často však zúčastněného pozorovatele při celkovém pohledu na takovou infrastrukturu polije studený pot – to tehdy, když si uvědomí smutnou realitu: Sdílení informací mezi těmito systémy a jejich propojení je tristně nedostačující, takže jinak očekávatelné benefity mizejí v imaginární černé díře. Pozornost CIO se tedy pozvolna přesunula od implementace izolovaných systémů k integraci již zavedených aplikací a systémů. Jako dobrý příklad lze zmínit CRM (Customer Relationship Management), který vyžaduje integraci zákaznických souborů, objednávkových systémů, splatných pohledávek a celé řady dalších datových zdrojů. Zákazníci od poskytovatelů svých služeb logicky požadují co nejvíce informací. Poskytovatelé služeb si zase stále více uvědomují klíčovou roli integrace v řetězci snah o uspokojení svých zákazníků. Integrace však není poháněna jen zákaznickou poptávkou. Dalším z důležitých hnacích impulzů je akutní potřeba zlepšit vlastní obchodní procesy, ještě umocněná tlakem konkurenčního prostředí. Firmy proto hledají způsoby propojení svých systémů a nové cesty sdílení informací mezi nimi, což v důsledku vede ke snížení provozních nákladů, ke zrychlení operací a ke zkvalitnění vztahů s dodavateli i klienty.
INTEGRACE PODNIKOVÝCH SYSTÉMŮ
Ještě poměrně nedávno nebyla situace na trhu s řešeními systémové integrace příliš růžová. Experti nízký podíl integrací obchodních procesů v podnicích svalovali hlavně na nedostatek vyspělých integračních technologií, ale také na to, že IT projekty včerejška většinou ani nevyžadovaly takovou provázanost jako ty dnešní (informační systém separovaný od důležitých datových zdrojů je dnes většinou vcelku nepoužitelný). Vše bylo předtím prováděno ručně, později ve velkém nastoupila tzv. EAI (Enterprise Application Integration neboli Integrace podnikových aplikací).
Integrace podnikových aplikací zjednodušuje stávající řešení, umožňuje integrovat aplikace v průběhu transformace společnosti, standardizuje a opětovně využívá formáty zpráv a usnadňuje přechod stávajících systémů na nové řešení. Metodiky EAI zahrnují objektově orientované programování, distribuovanou programovou komunikaci mezi platformami pomocí zpráv, opětovné využití podnikových plánovacích systémů (ERP), celopodnikovou distribuci dat a obsahu využitím společných databází a standardů na bázi XML, middlewaru, message queuing a jiných přístupů. Řešení EAI se neposkytuje jako hotový produkt, který přináší okamžitý zisk. Integrace podnikových aplikací vyžaduje dlouhodobější plánování a investice do rozvoje strategií a taktických postupů.
JAK NA TO?
Integrace začíná konkrétní vizí. Úkol CIO je pak tuto ideu jasně přetlumočit ostatním a vyzdvihnout přínosy její realizace. Všemu tedy předchází rozvržení a zvážení požadavků vaší firmy a jejich zákazníků. Systémová integrace ve finále musí uspokojit obě zmíněné skupiny. Společnosti zvažující integraci svých systémů mohou zvolit jeden ze dvou přístupů – strategický či taktický. Firmy, které zvolí odvážnější strategický přístup, většinou usilují o efektivní integraci veškerých systémů, jejímž výsledkem bude jediný pramen schopný vykreslit pravdivý obraz o stavu jejich podnikání. Nechtějí jen snížit náklady, touží se zároveň stát flexibilnějšími a získat možnost pružně reagovat na aktuální stav trhu rychlou změnou obchodního modelu. V rámci těchto snah dané subjekty zavádějí integrační páteř, na níž postupně nabalují nové či již existující systémy.
Druhý, taktický přístup je obyčejně přijímán organizacemi, které implementují odlehčenější a jednodušší portály s omezenou funkcionalitou a s menšími nároky na integraci datových zdrojů v pozadí. I tyto společnosti by však měly brát ohled na veškeré eventuality a využívat technologie, jež jsou dostatečně flexibilní pro integraci s dalšími portály. Jinak mohou skončit ve slepé uličce.
Strategický přístup sice skýtá rychlejší cestu k dosažení kýžených obchodních benefitů i hlavního integračního cíle, zároveň je však těžší vůbec se do něj pustit, neboť o výhodách musíte přesvědčit také management společnosti. Naproti tomu, taktický přístup se snáze načíná, ale docílení plánované úrovně integrace může být obtížnější. Důvod? Každý projekt musí být doprovázen rozhodnutím o tom, který software v dané situaci použít.
Již jsme naznačili, že jedním z hlavních přínosů kvalitní integrace je možnost poskytovat zákazníkům přístup ke konsolidovaným informacím. Kvantifikace tohoto přínosu může být obtížná, jeho výhody jsou však nesporné. Klientům tak stačí se dostat k jedinému zdroji (například k firemnímu portálu), kde naleznou vše potřebné. Organizacím díky tomu kupříkladu klesají administrativní a provozní náklady, urychluje se také proces rozhodování. Podle expertů lze navíc návratnosti investic v této oblasti dosáhnout již do dvou let od integrace.
METODY INTEGRACE
Vedle celkového přístupu je nezbytné se zamyslet nad vhodnou metodou jak systémy propojovat do větších celků – v některých případech to úzce souvisí i s použitými technologiemi.
Vertikální integrace je proces kdy jsou jednotlivé systémy propojeny podle své funkčnosti – vytváří se funkční entity nazývané sila. Výhodou tohoto přístupu je obvykle rychlá realizace nižší náklady, následné provozní náklady mohou být ale výrazně vyšší, zejména v případě že budete chtít rozšířit stávající či přidat zcela nové funkce. Jediný způsob jak to provést je obvykle vytvoření nového sila – opakované použití komponent či subsystémů obvykle není možné.
Hvězdicová integrace, někdy také označovaná jako „špagetová“ vyžaduje propojení všech částí systémem každý s každým. Z pohledu integrovaného subsystému pak připomíná struktura propojení hvězdu, celkový diagram ale vypadá spíše jako propletené špagety. Náklady při použití této metody závisí na rozhraních, které používají jednotlivé subsystémy – v případě kdy se jedná o proprietární dodavatelské standardy, může se nepříjemně prodražit, nemluvě o tom že s každým dalším prvkem rostou náklady i čas potřebný na dokončení integrace exponenciálně. Jedná se ale zároveň o nejflexibilnější řešení s možností opakovaně používat existující funkce.
Horizontální integrace, která je často chápána jako synonymum pro technologii ESB (Enterprise Service Bus – viz dále) využívá specializovaného systému, který funguje jako sběrnice a tlumočník komunikující se všemi ostatními subsystémy – tím je omezen počet spojení (rozhraní) na jedno na každý subsystém. Kombinují se tak výhody relativně nízkých nákladů a vysoké flexibility a rozšiřitelnosti. Je-li třeba nahradit některou z komponent za nový subsystém s obdobnými funkcemi ale jiným rozhraním, stačí upravit ESB tak, aby toto rozhraní podporoval.
TECHNOLOGIE PRO INTEGRACI
Dnes se lze v korporátním prostředí setkat se stovkami komplexních aplikací se složitými vazbami a závislostmi. Požadavky na tyto aplikace se často mění, a proto je potřeba, aby i takto složité integrační prostředí bylo schopné na změny reagovat pružně, za současného udržení vysoké rychlosti, dostupnosti, stability a bezpečnosti veškerých systémů. Jde o velmi obtížný úkol, zároveň však nutnost, bez níž má firma jen malou naději na úspěch. Výrobci integračních nástrojů dnes nabízejí mnoho prostředků k dosažení vytouženého cíle.
Nejstarším způsobem integrace systémů je výměna dat pomocí souborů. Běžně se v jednodušších případech používá i dnes. Jeho hlavní předností je nízká cena a univerzálnost, dalším plusem je pak vzájemná nezávislost propojených systémů z pohledu technologií, dostupnosti i dalších kritérií. Horší je to se zdlouhavostí daného procesu a s jeho obtížnějším monitoringem.
Jednoduchého přenosu dat pomocí souborů se ještě stále hojně využívá také při výměně dat mezi obchodními partnery (v procesu B2B). Důvodem jsou minimální náklady na vybudování infrastruktury i na definici rozhraní. Zde navíc mohou pomoci již existující oborové standardy zaštítěné mezinárodními organizacemi (například S.W.I.F.T. neboli Society for Worldwide Interbank Financial Telecommunication). Zvláštní skupinou jsou takzvané nástroje ETL (Extract-Transformation-Load), které jsou specializované na stažení dat ze zdroje, jejich transformaci a uložení výsledku do cílové databáze. Jejich přínos spočívá hlavně v komfortním uživatelském rozhraní, bývají také optimalizované na zpracování souborů s velkými objemy dat. Typicky se ETL nástroje používají pro stahování dat z provozních systémů do datových skladů.
RPC (Remote Procedure Call) nebo také RPI (Remote Procedure Invocation) jsou mechanismy řešící v rámci integrace dlouhé časové prodlevy nastavající v případě použití souborů. V případě RPC je volání vzdáleného rozhraní zabaleno do stejné sémantiky, jako by šlo o volání lokální aplikace. Klient pošle dotaz na vzdálený server, kde se spustí procedura, přičemž čeká do té doby, než server ukončí zpracování, a předá mu odpověď. Odpadá tedy čekání na spuštění dávkového přenosu. Velkou výhodou tohoto přístupu je to, že vývojář může použít stejný postup, který zná z volání v rámci jedné aplikace. Je-li syntaxe i sémantika obou typů volání stejná, lze se také rozhodnout o tom, zda aplikace či komponenta poběží lokálně nebo na jiném stroji, až během nasazení hotové aplikace, nikoliv nutně již při vývoji.
I tato technologie má však své zápory. Vzdálené a lokální volání se totiž v mnoha detailech liší. Klient vždy čeká na to, až mu server vrátí odpověď, a to i v případě, že ji k ničemu nepotřebuje. Vlastní volání přes síť může být velmi pomalé anebo může být vzdálené rozhraní dokonce nedostupné, takže klient může na odpověď čekat značnou dobu. A je-li poskytovatelem rozhraní třetí strana, co se stane, pokud toto rozhraní bez varování změní? Nic z toho u lokálních volání není třeba řešit. Ani následující generace RPC na většinu těchto problémů nedokázala odpovídajícím způsobem reagovat.
Pozdější implementace RPC, většinou už založené na distribuovaných objektech, však přišly s jednou důležitou funkcionalitou, a sice s adresářem nabízených služeb. Zde již klient může požadovat službu bez toho, aby přesně znal její rozhraní a umístění poskytovatele v distribuované síti. Veškerá veřejná rozhraní jsou popsána formou IDL (Interface Definition Language) a výsledné definice jsou uloženy v adresáři služeb. Tento adresář se využívá (často až za běhu), pro vyhledání požadovaných komponent a informací o tom, jak je třeba s nimi komunikovat. Adresáře služeb odstranily problém s dopadem drobných změn rozhraní, a protože vznikl jakýsi katalog nabízené funkcionality, umožnily také větší znovupoužití hotových služeb. Práce s komponentami (DCOM a CORBA) je ale poměrně složitá a k tomu přetrvával problém s pevnou vazbou mezi klientem a serverem. Než se dostaneme k technologiím, které nabídly řešení obou problémů, podívejme se nejprve v krátkosti na nástroje zvané MOM.
MOM (Message Oriented Middleware) je software určený pro komunikaci mezi aplikacemi, který umožňuje asynchronní přenos zpráv. Znovu tak zavádí volné vazby mezi systémy zmiňované u souborů. Podporu pro zasílání zpráv lze najít v různých typech softwaru, dokonce už na úrovni operačních systémů (např. Microsoft) a databází (např. Oracle).
MOM je vhodným řešením pro situaci, kdy uživatel potřebuje informovat jiný systém, ale přitom nechce čekat na odpověď. Systémy nemusejí být k síti připojené současně, zprávu si vyzvednou po připojení. MOM také často slouží jako mezivrstva mezi více různými technologiemi. Pro tento účel vznikají řady takzvaných konektorů nebo adaptérů, vyvíjených buď přímo dodavatelem MOM, nebo pomocí SDK. Produkty MOM však nejsou určeny pro složitější obchodní logiku nebo pro implementaci obchodních procesů a samozřejmě jako každá další vrstva v komunikaci mohou selhat, čímž zvyšují zranitelnost celého prostředí.
Teď ale zpět k objektovým RPC. Aby programátoři nemuseli služby, které se opakují, programovat stále znovu, objevily se tzv. aplikační servery. Jde o jakési kontejnery, které zajišťují stále se opakující služby, a aplikace, která v nich běží, se může starat pouze o tu funkcionalitu, pro kterou byla vyvinuta.
Aplikační servery ulehčují vývoj aplikací tím, že umožňují využít obecné služby popsané výše. Lze v jejich případě také většinou volit mezi request-reply komunikací, tedy pevnými vazbami mezi komponentami, a asynchronní komunikací. Hlavní nevýhodou integrace přes aplikační servery je však to, že nejde o opravdový distribuovaný systém, respektive že je sice možné instalovat celý aplikační server, ale vždy za cenu další licence. V tomto směru je podstatně výhodnější použít ESB.
Enterprise Service Bus (ESB) poskytuje systém pro zasílání zpráv a nad ním abstraktní vrstvu pro definici služeb a pro práci s nimi. Snaží se o oddělení logické definice služby od její technické implementace. ESB zpravidla nabízí vyspělé GUI, kde se mapování a XML transformace definuje pouhým kliknutím myši. Mnoho lidí se mylně domnívá, že služby v ESB musejí být implementovány jako webové služby. Ačkoli je to nejběžnější případ a webové služby jsou pro tyto účely velmi vhodné, existují i další možné technologie.
CO NÁS ČEKÁ?
Systémová integrace je velice obšírné téma, čemuž odpovídá také pestrost jejího trhu. A na co se v této oblasti můžeme těšit? Všeobecně se počítá s postupnou dominancí obecných standardů, které vytlačí stále velice rozšířený proprietární přístup. Častým jevem je rovněž spojování menších dodavatelů integračních nástrojů, kteří se tak snaží bránit konkurenci ze stran největších hráčů (Microsoft, Oracle, IBM…). O dalších obecných trendech pro budoucnost panují dohady, jisté je však jedno – správný výběr integračních technologií je klíčový pro jakékoli složitější informační prostředí, a tak systémové integraci prozatím vymření po vzoru dinosaurů nehrozí.
7 0246/pat
--vložený text--
Integrační evergreen
Jiří Laciga
Zabývám se informatikou 35 let a za tu dobu se objevilo velké množství pojmů, metod, jazyků a standardů, které v dané době představovaly větší či menší „objevy“ a jevily se jako spása největších akutních problémů. Většina pojmů časem zanikla, a to buď proto, že nebyla tou spásou, nebo problém přestal být zajímavý a důležitý, či přišel někdo, kdo potřeboval vytvořit novou teorii a pojem prostě přejmenoval. Systémová integrace však je jeden ze stálých pojmů, který se drží již velmi dlouho. Bylo o ní napsáno mnoho, učí se na školách. Splňuje totiž všechny znaky evergreenu:
1.Jeho definice je tak obecná, že nikoho neurazí.
2.Každý si představuje, že řeší právě ten jeho problém.
3.Náplň systémové integrace se v čase může pohodlně vyměňovat, zanikající problémy se nahrazují vznikajícími.
4.Neví se, zda se jedná o název vědy, teorie, metody, produktu nebo služby. Můžete si vybrat nebo můžete říci, že to je všechno současně.
HISTORIE SYSTÉMOVÉ INTEGRACE
V začátku devadesátých let vzniklo v ČR obrovské množství informatických firem, pod heslem co Čech, to podnikatel. Tyto IT firmy se rozdělovaly poměrně striktně na vývojářské, dodavatele hardwaru a síťaře. Je třeba si vzpomenout, že zde zdaleka nepanoval monopol Windows na koncových stanicích, že Unixů byla celá řada a nebyly kompatibilní, že srovnatelných databázových systémů bylo asi šest, že prakticky neexistoval internet, který by nutil všechen software propojit se touto cestou.
PRVOPOČÁTKY
Systémová integrace vznikla jako služba zákazníkovi, aby vůbec mohl zavést nějaký funkční systém a mohl si jej složit z více specifických částí. V další fázi byla systémová integrace v zásadě předurčena těmito objektivními jevy, které probíhaly téměř současně:
1.Rozvoj internetu a nástup jazyků pro něj.
2.Monopolizace Windows na koncových stanicích.
3.Vyjasnění pozic v databázových systémech, jejich standardizace.
Nejdůležitějším aspektem měnícím náplň systémové integrace však byl totální průnik IT do každodenního života firem a občanů. Tento proces byl umožněn a zároveň generoval obrovské množství malých i velkých aplikací pro téměř každou činnost, kterou lidé ať už jako zaměstnanci nebo ve svém volném čase vykonávají. Tyto aplikace si technologicky mohou vyměňovat data, ale nemusejí to umět logicky.
INTEGRACE OBSAHU
V současné době není hlavním úkolem systémové integrace technologické propojení jednotlivých prvků systému, ale propojení obsahu dat. Každý systém, specificky vyvinutý pro danou oblast činností, si udržuje svoje data ve své struktuře. Současným úkolem tedy je vyřešení logicky správného přenosu, vyčištění dat a jejich integrace tak, aby se data dala použít pro další uplatnění. Takovým všeobecně známým řešením je export a import přes Excel, ale všichni víme, jaké problémy při tom musíme řešit, pokud na to aplikace nejsou připraveny logicky.
KONSOLIDACE APLIKACÍ
Další výzvou, která stojí před systémovým integrátorem je skutečnost, že v řadě podniků se postupným neřízeným způsobem pořizování aplikací dospělo do stavu, že stejné procesy se v různých útvarech zajišťují různými autonomně nakoupenými aplikacemi a naopak některé procesy nejsou podporovány žádnou aplikací. Jsou případy, že na stejný proces byly v podniku pořízeny i více než 3 aplikace. Je tedy potřeba zmapovat procesy v podniku a jejich pokrytí aplikacemi, je třeba vyhodnotit, která z aplikací splňuje stanovená kritéria. Na základě této analýzy se pak provede návrh konsolidace, tj. které aplikace se zruší, které budou dále podporovány a které se pořídí nové. Zároveň se musejí vyřešit logické přenosy a sdílení dat.
Autor je generálním ředitelem společnosti CCA Group.
Typické funkcionality ESB:
- audit, logování
- směrování zpráv podle adresy nebo podle obsahu
- záruka doručení zpráv
- komplexní nástroje pro zpracování a transformaci dat
- podpora distribuovaného prostředí
- různé modely zasílání zpráv (request-response, hub-and-spoke, publish-subscribe, peer-to-peer…)
- podpora definice obchodních procesů a orchestrace služeb
- služby pro zajištění bezpečnosti, šifrování či signatur
- centralizované monitorování a administrace
Sdílené služby EJB
Mezi sdílené služby, zajišťované na úrovni vrstvy obchodní logiky komponentami zvanými EJB (Enterprise JavaBeans), patří podle J2EE specifikace:
- správa transakcí
- zajištění bezpečnosti (JCE, JAAS)
- kontrola souběžných přístupů
- vystavení obchodních rozhraní jako webových služeb
- perzistence objektů
- spuštění komponent v aplikačním serveru
- podpora událostí v JMS
- jmenné a adresářové služby (JNDI)
- vzdálené volání procedur s použitím RMI-IIOP
PŘEDPLATNÉ
ČLÁNKY DO MAILU