Architektura informačního systému z pohledu integrace v kontextu podnikové integrace

Architektura informačního systému z pohledu integrace v kontextu podnikové integrace Marek Ondruška Katedra informačních technologií Vysoká škola ekonomická v Praze [email protected] Abstrakt Esej pojednává o integraci v rámci podniku z pohledu architektury. Rozšiřuje pojem integrace z aplikační integrace na integraci podnikovou. V rámci práce jsou identifikovány některé vybrané typy integrace, které lze zařadit pod podnikovou integraci. Konkrétně je pojednáno o aplikační integraci, integraci business procesů na IT systémy podniku, integraci business a IT architektury a v neposlední řadě je diskutována otázka B2B integrace. Klíčová slova: Integrace, podnik, aplikace, architektura Abstract The essay describes integration in the enterprise from the architecture point of view. It extends the integration from application integration to enterprise integration. There are indentified four types of integration, which can be seen as parts of enterprise integration, in the paper. Application integration, integration between business processes and IT systems, business architecture and IT architecture integration and finally B2B integration are discussed in the text. Key Words: Integration, Enterprise, Application, Architecture

1. Zaměření studie a definice pojmů Vymezení pohledu této studie lze charakterizovat jako architektonický pohled na integraci v rámci podniku a podniku s okolním světem. Zabývá se architektonickým pohledem na integraci a vymezuje jednotlivé typy podnikové integrace. Nezaměřuje se tedy pouze o aplikační integraci. Primární zaměření se však týká IS/IT z pohledu integrace a to jak v rámci tohoto systému, tak na jeho okolí interní (v rámci podniku) i externí (okolí podniku). V textu jsou vytipovány některé oblasti integrace, které jsou v textu diskutovány. Některé jsou vynechány. Důvodem je příliš velký rozsah této problematiky, který by nebylo možné v této studii dostatečně projednat. Oblast podnikové integrace se neustále vyvíjí a oblastí, které jsou pod ní zařazovány, neustále přibývá. Dále bude projednán historický vývoj v těchto oblastech. Studie není příliš technicky orientovaná, ale spíše se zaměřuje na logiku věci a její vývoj v čase. Vlastní text bude uveden některými vybranými definicemi. Následně je proveden obecný popis zkoumané problematiky. V dalších kapitolách jsou diskutovány oblasti aplikační integrace, integrace business procesů a služeb poskytovaných aplikacemi. Dále je diskutována otázka integrace business architektury a IT architektury a jako poslední vybrané téma se týká problematiky B2B integrace. Poznamenejme, že v textu a v obrázcích se vyskytují anglické termíny, které, dle názoru autora, není účelné překládat do Českého jazyka. Popisky v obrázcích jsou popsány v anglickém jazyce.

SYSTÉMOVÁ INTEGRACE 4/2009

143

Marek Ondruška

Definice (architektura) „Formální popis systému, nebo detailní plán systému na úrovni komponent, kterým se řídí jeho implementace“ [TOG09] „Struktura komponent, jejich vztahů a principy a postupy řídící jejich návrh a vývoj v čase“ [TOG09] Samotná definice architektury reflektuje potřebu integrace. V případě aplikační integrace lze namapovat aplikace na komponenty a integraci na vztahy mezi aplikacemi (způsob propojení/komunikace). Ne jinak je tomu u ostatních typů integrace, které jsou v textu popisovány. Definice (informační systém) Informační systém je v této studii chápán v užším smyslu - pouze ta část informačního systému podniku, která je automatizována/podporována výpočetní technikou. Informační systém jako takový má podstatně širší rozsah. „Systém, který využívá výpočetní techniku a informační technologie k přenosu, uchování, získání, transformaci nebo zobrazení dat pro business procesy v organizaci.“ Inspirováno [KHO07] Definice (integrace) Propojení částí (množiny komponent) tak, aby vytvořily celek, který odpovídá, resp. reflektuje pravidla a principy stanovené pro daný typ integrace. Podniky mají „integrační potřeby“, které se týkají jak jednotlivých architektonických vrstev – business, aplikační, datové a infrastrukturní, tak jdoucí přes tyto vrstvy. Tyto potřeby mohou být adresovány různými architektonickými přístupy. Jednou z těchto integračních potřeb je potřeba integrovat podnikové aplikace, nicméně množina integračních potřeb je poněkud širší a (dle názoru autora) teprve ve svých počátcích a čeká jí bouřlivý vývoj, který již začal. Na informační systém je možné nahlížet z pohledu architektury, což je základní pohled, z kterého vycházíme v této studii, pokud nebude řečeno jinak. Dále je možné v tomto pohledu zaujmout užší hledisko a to hledisko integrace. Integraci lze definovat na mnoha místech v rámci i mezi podniky. Existují různé klasifikace např. externí a interní integrace, popř. procesní, servisní, aplikační, datová, prezentační aj. Klasifikace integrace v rámci podniku není snadným úkolem a je značně závislá na definování obsahu každé identifikované integrace. Text rozlišuje mezi podnikovou integrací (enterprise integration) a aplikační integrací v rámci podniku (enterprise application integration). Aplikační integrace je součástí podnikové integrace. Dále poznamenejme, že pohled na B2B integraci je v této studii poněkud širší, než je integrace aplikací podniku na IT systémy okolních subjektů (dodavatelů, státu, finančních institucí, zákazníků a dalších) a to zejména tím, že zahrnuje i business procesní integraci. K tomu, aby bylo účelné uvažovat o integraci aplikací, musí existovat určitý kontext, který je dán integrací procesů podniku a procesů externích subjektů. Více o rozsahu B2B ve vazbě na IT systémy viz kapitola „B2B integrace“. Tento přístup je intuitivní. Business procesy jsou formalizovaným popisem (modelem) činnosti podniku. Samotná činnost podniku odvíjející se od jeho strategie a cílů je to, co stojí vždy na počátku, tj. i před aplikační integrací. Aplikační integrace umožňuje kolaboraci aplikací za účelem automatizace definovaných aktivit v rámci procesů, resp. dodání aplikačních služeb do procesů. Tento přístup zároveň reflektuje posun vnímání integrace z technologické úrovně na úroveň businessu a jeho procesů, což je moderní 144


Architektura informačního systému z pohledu integrace v kontextu podnikové integrace

způsob vnímání této problematiky. Více o aplikační integraci viz kapitola „Aplikační integrace“. Na obr. 1 jsou naznačeny jednotlivé integrace popisované předkládanou studií. Chybí zde pouze integrace business architektury a IT architektury, i když je implicitně také obsažena.

Obrázek 1 - EAI, B2B, Business/IT integrace Procesní integrace Podstatou procesní integrace je provázanost jednotlivých procesů navzájem, jak v rámci podniku, tak mezi podniky. Procesní integrace je jednou z významných složek, které musí uvažovat dnes tolik diskutovaná disciplína nazývaná business process management (BPM). Procesní integrace reflektuje dnešní komplexitu činnosti organizace ve smyslu její vnitřní provázanosti. Poznamenejme, že procesní integrace musí respektovat granularitu popisu procesů a pattern popisu procesů. Jako příklad uveďme popis procesů jako sled aktivit, který je realizací definované dodávané služby. Otázka toho, jak správně modelovat procesy v podniku je aktuálním tématem dnešní praxe podniků i teoretiků. Servisní integrace Servisní integrace je poměrně komplikovaným a rozsáhlým tématem. Toto téma dosahuje až po dnes moderní přístupy v architektuře jako je architektura orientovaná na služby (SOA). Důležité je si uvědomit, že SOA není nutnou podmínkou pro servisní integraci. SOA klade širší a přísnější požadavky ve vztahu ke službám. Konec konců i systémy vystavěné v kontextu jiných typů architektur poskytují služby. Rozdíl je v tom, že architektura takto poskytovaných služeb nereflektuje některé principy jako např. znovupoužitelnost, kompozici služeb, volné vazby aj., které jsou základními požadavky kladenými ze strany SOA. Podnik disponuje určitým portfoliem služeb (jedná se o samostatné ucelené funkcionality), které ovšem z pohledu architektury neuvažuje nezávisle na sobě ve smyslu, že při tvorbě dané služby je reflektována existence ostatních služeb. SYSTÉMOVÁ INTEGRACE 4/2009

145

Marek Ondruška

Datová integrace Podniky disponují portfoliem různých datových úložišť. Postupem času potřeby podniku a požadavky kladené na IS/IT, konkrétně na datovou vrstvu, začaly přerůstat přes jednotlivé datové úložiště, navíc se začalo ukazovat, že udržovat duplicitně data je mnohdy zbytečné a vytváří se tím nové náklady. I když v určité míře (přesně definované) je řízená duplicita žádoucí. V této době se začala prosazovat datová integrace, která uvažuje o datech, datových úložištích a vazbách mezi nimi jako o celku. Datová integrace může být podporována např. pomocí datové replikace nebo ETL. Replikace dat – „je definovaná jako proces kopírování a udržování databázových objektů, jako např. tabulek, v různých datových úložištích, které dohromady vytvářejí distribuovaný databázový systém.“[SAM02] ETL- extract, tranform, load – je definován jako proces „extrakce, transformace, filtrace, směrování a nahrávání dat z různých typů datových úložišť, jako aplikací, podnikových databází, data warehouse a data martů do cílového datového úložiště.“[SAM02] Prezentační integrace Jedná se o integraci poskytovaných služeb na úrovni vrstvy front-endu (prezentařní vrstvy IT systému). V dnešní době se hojně nasazují portálová řešení, která poskytují customizované prostředí pro jednotlivé uživatele a to i z pohledu nabízených služeb. Jedná se o „single entry point“ pro uživatele ke službám s unifikovanou identifikací uživatele (single sign-on).

2. Aplikační integrace Aplikační integrace (AI) se může vyskytovat na těchto vrstvách: prezentační vrstva, aplikační (business logic) vrstva, datová vrstva a konečně vrstva infrastruktury. EAI se zaměřuje na sdílení jak business dat, tak business procesů. To, že aplikace potřebují sdílet data, je zřejmé. Co však znamená, že potřebují sdílet také procesy? Nejde v zásadě o nic jiného, než, že každá aplikace musí znát své místo v rámci procesu a způsob jak se zachovat, „když na ní přijde řada“. To znamená, že aplikace očekává určité volání, na které reaguje v souladu s procesem. Aplikace buď přímo automatizuje určitou aktivitu procesu anebo jí podporuje vybranou funkcionalitou.

146



Obrázek 2 - Topologie aplikační integrace Různé topologie integrace (viz obr. 2) Point to point – přímá komunikace mezi aplikacemi; Broker based – mezi aplikace je vložen tzv. HUB (middleware), který zajišťuje vlastní propojení aplikací; ESB – Enterprise service bus je také middleware, který má od HUBu určitá specifika viz dále. Point to point Point to point propojení není nutně nevhodná varianta integrace, nicméně by měly existovat pravidla, která budou říkat, kdy použít, který typ integrace. Tento typ integrace je založen na principu přímého napojení aplikací mezi sebou. Bohužel počet vazeb nutných pro integraci narůstá rychle, viz obr. 2. V praxi se většinou nepodaří nasadit v plné šíři architektury jako komponentní nebo orientovanou na služby, ale mnohdy koexistuje více typů. Nedomnívám se, že je to nutně špatný trend, neboť některé aplikace svojí povahou a specializací jsou natolik jedinečné, že je není nutné za každou cenu podrobit např. architektuře orientované na služby. Business logika aplikace nemusí být znovu použitelná dalšími jinými aplikacemi. Obecně to znamená, že náklady spojené s přechodem na SOA v plné šíři v oblasti IS/IT by byly příliš vysoké oproti přínosu z takové transformace. Tak jako není jediná univerzálně vhodná organizační struktura podniku, tak není ani jedna taková architektura. Broker based Jiným typem integrace je využití tzv. HUBu. Podstata spočívá v tom, že aplikace spolu nekomunikují napřímo, ale existuje komponenta (middleware), která má za úkol zprostředkovat komunikaci mezi aplikacemi. Tedy aplikace spolu komunikují přes tento HUB. Tím je zásadně dotčen počet nutných vazeb a to tak, že počet


147

Marek Ondruška

N.(N-1)/2 je snížen na počet N vazeb v případě plně integrovaného systému, blíže viz další text. ESB based ESB lze také zařadit do kategorie middleware. Má podobné umístění jako HUB, jeho funkcionalita je však poněkud širší a sofistikovanější. ESB je v současné době často diskutovaným způsobem integrace v souvislosti se SOA. ESB je integrační platforma, která umožňuje vzájemné volání služeb mezi sebou. Mezi funkcionalitu, kterou ESB pokrývá lze zařadit např. poskytování konektivity, datovou transformaci, inteligentní směrování posílaných zpráv, řízení služeb, monitorování, logování a bezpečnost. Závisí však na konkrétní instanci ESB zda danou funkcionalitu pokrývá, anebo je potřeba určitá nadstavba popř. jiná aditivní logika. IBM uvažuje o ESB také jako o architektonickém patternu[IBM09]. Tři typy integrace[CHA03] Manuální – jedná se o situaci, kdy lidé defakto nahrazují automatizovanou integraci. Příkladem může být pracovník, který si zobrazí data v rámci jedné aplikace a přepisuje je do jiné. I když tato situace zní poněkud nesmyslně, tak i v dnešní době je možné se s ní setkat. Automatizovaná – jde o plně automatizovanou integraci mezi aplikacemi. Mezi aplikacemi nevystupuje lidský faktor. Poloautomatizovaná – tento typ integrace lze popsat tak, že dochází ke kombinaci automatizovaného a neautomatizovaného propojení mezi aplikacemi. Tedy kombinace předchozích dvou variant. Implementace aplikační integrace[CHA03] Web services – aplikační (servisní) komponenty, které spolu komunikují přes WS protokoly; Extract, Transform, and Load (ETL) – aplikace (middleware) umožňující přenos a transformaci dat z definované výchozí množiny datových úložišť do cílové množiny úložišť; Communications message protocols – protokoly jako TCP/IP, HTTP a FTP; Screen scraping – je situace, kdy business logika je implementována na úrovni prezentační vrstvy. Integrace probíhá defakto jako simulace chování uživatele (human-aktor) s tím, že se jedná o aplikaci. Tento typ integrace nevyžaduje dodatečnou tvorbu API pro integraci; Direct data access – je způsob integrace, kdy jsou data jedné aplikace zapisována do datového úložiště, které využívá jiná aplikace; File transfer – přenos souborů mezi aplikacemi pomocí dávkového (batch) módu; Human involvement – částečné zahrnutí lidského faktoru do integrace mezi aplikacemi viz výše typy integrace. Postupné propojování (integrace) aplikací bylo zpočátku vcelku bezproblémové. Používal se přístup point-to-point. Při relativně malém množství těchto vazeb je tento přístup akceptovatelný. Avšak při postupném nárůstu začíná být údržba všech těchto vazeb neúnosná.

148



Při počtu N aplikací je počet vazeb, který je nutný udržovat N nad 2 (tzv. plně integrovaný systém). Neformálně často označovaný jako tzv. „špageti systém“. Pokud rozlišíme směr komunikace, tak se počet zdvojnásobí na N * (N-1), kde N je počet aplikací. Monolitické systémy začínaly být překážkou s tím, jak postupně narůstala potřeba integrovat jednotlivé systémy. Integrace byla realizována postupně dle potřeby, tj. byly vytvářeny spojení mezi aplikacemi, které spolu potřebovaly komunikovat. Tento přístup vedl k nepřebernému množství spojení, která se těžko udržovala. Změny v takovém systému představovaly značné úsilí a nemalé sumy finančních prostředků. Přestože byl použit minulý čas, lze se s tímto setkat u mnoha dnešních ICT podporovaných podniků (dle zkušeností autora). Problém neexistence standardizovaného způsobu komunikace mezi distribuovanými aplikacemi byl a stále je dalším problémem v oblasti integrace aplikací. Komunikace byla buď příliš svázána s určitou technologickou platformou a tím pádem postrádala standardizaci a široké přijetí nebo byla příliš složitá pro proces integrace v praxi. Problém se týkal toho, že všechny tyto přístupy nerespektovaly jeden zásadní princip a tím je tolerance různých technologií. Obecně není možné předpokládat, že kdykoli organizace získá aplikaci, která je postavena nad určitou technologií, tak že spustí proces vývoje a přebuduje tuto aplikaci nad technologie, které využívá. Představme si např. situaci převzetí podniku jiným podnikem. Taková transformace v rámci IS/IT by byla finančně a časové neúnosně velká v závislosti na složitosti IT systémů podniků a množství využívaných technologií. Tyto problémy se týkají primárně technologií jako CORBA, DCOM a dalších. Až webové služby a jejich standardizace SOAP, WSDL, UDDI a všechny WS standardy mohou tento problém překonat. Poznamenejme, že není vhodné konstatovat, že jeden typ integrace je lepší než jiný. Obecně, každý z nich se hodí na jiné situace a scénáře a má své výhody a nevýhody. Příkladem může být tvrzení, že P2P integrace je horším řešením, než např. využití ESB. To nemusí být nutně pravda, neboť je zde implicitně obsažena jedna podmínka a to je počet integrovaných systémů a podoba business modelu. Při malém množství aplikací, které plánujeme integrovat, se nemusí vyplatit využívat architektury typu SOA, ale může postačovat integrace typu P2P. V případě situace, kdy máme aplikace postaveny nad stejnými technologiemi, není příliš mnoho problémů s integrací. Avšak problém je s udržením předpokladu, že nedojde ke změně technologií. To je v dnešní době v zásadě nereálný požadavek. Styly aplikační integrace[HOH03] File transfer – přenos souborů mezi aplikacemi; Shared Database – sdílená databáze, přístup více aplikací; Remote Procedure Invocation – vystavení některých procedur, které je možné volat na dálku jinými aplikacemi; Messaging (MOM – message oriented middleware) – zasílání zpráv mezi aplikacemi. Tyto styly jsou seřazeny dle sofistikovanosti. To ovšem neznamená, že ten poslední je nejlepší a je nutné jej používat ve všech situacích vyžadujících integraci aplikací. Vždy je potřeba zvolit vhodný styl ve vazbě na specifika IS/IT prostředí daného podniku.


149

Marek Ondruška

Integrační patterny Integrační pattern se skládá ze dvou částí z integračního problému a jeho řešení. Patterny vycházejí ze zkušenosti, ale na rozdíl od ní jsou identifikovány a zdokumentovány a je možné je použít znovu při řešení integračních problémů dané třídy. Jedná se o popis toho, jak řešit daný integrační problém vycházejíc z dobré zkušenosti aplikace tohoto postupu na dříve adresovaném integračním problému. Vždy při aplikaci patternu je však potřeba přizpůsobit zvolený pattern konkrétním podmínkám, kde má být použit.

3. Integrace IS/ICT na business procesy V počátečních fázích vývoje HW a SW prostředků pro podporu činností podniků se prosazoval trend, kdy byly vymezeny oblasti činnosti podniku jako např. marketing, finance, lidské zdroje a další. Jednalo se tedy o funkční oblasti podniku (business domény). Každá z těchto oblastí pomyslně vyřízla vertikálně část organizace a v rámci ní byly vyvíjeny IT systémy, které jí podporovaly. Tento přístup byl zpočátku vyhovující a to až do té chvíle, než začaly vznikat požadavky, které měly dopady i na ostatní systémy, které patřily do ostatních business domén. Typická situace byla, když bylo potřeba získat např. různé informace o klientovi dané organizace. Tato situace nutně vyžadovala propojení systémů přes jednotlivé domény, což si vyžádalo zabývat se aplikační integrací, viz výše kapitola „Aplikační integrace“. Integrace byla zpočátku motivovaná technologicky, ale postupně začalo být těžiště přesouváno na stranu businessu a integraci business procesů. Integrace aplikací je defakto podporou integrace procesů. A to jak procesů probíhajících v rámci podniku, tak i mezi nimi a procesy okolních subjektů viz dále „B2B integrace“. Když se hovoří o business procesech, bylo by vhodnější říkat podnikové (enterprise) procesy, neboť samozřejmě i IT procesy mají významné vazby na IS/IT, ale zde se budeme primárně věnovat vazbě IS/IT na procesy na straně businessu.

Obrázek 3 - model OSIMM[OSI06] 150



Na obr. 3 je znázorněn model OSIMM, který popisuje maturitu servisní integrace, nicméně je z něj patrný postupný vývoj aplikační integrace od počáteční situace monolitické architektury až ve čtvrtém sloupci architekturu orientovanou na služby. Od té chvíle je možné měřit maturitu podniku v tomto typu architektury. Architektury předešlé jsou historickými předchůdci. Dále je popsáno prvních pět variant, které jsou pro tento text dostačující a s kterými je možné se v praxi setkat. Silo Na této úrovni maturity je podnik rozčleněn vertikálně, tak že IT systémy podporují vybranou doménu. Jsou vyvíjeny pouze pro tento účel bez předpokladu integrace na systémy okolních domén, viz obr 4. V případě situace, kdy vznikají požadavky na IT systémy, které mají dopad do více systémů napříč doménami, je tato úroveň maturity nevhodná. Na druhou stranu u podniku, který má např. několik divizí s velkou autonomií, kde každá má úzkou specializaci ve své činnosti, tato úroveň není kategoricky nevhodná, ale i v takové situaci je potřeba zajistit určitou míru integrace. V případě silo úrovně je situace taková, že jednotlivé útvary zabývající se určitou oblastí např. marketing, účetnictví nebo finance má k sobě přidružené IT, které řeší pouze systémy, které jsou pro podporu této oblasti. Takže integraci řeší jen velmi omezeně v rámci své domény. Lze si to představit jako vertikální řez podnikem podle jednotlivých business domén. Integrated Na této úrovni již vzniká integrace mezi jednotlivými doménami. Případná integrace systémů je však značně komplikovaná a znamená nemalé zásahy do integrovaných systémů. Tedy na této úrovni je možné adresovat požadavky businessu, které vyžadují spolupráci více aplikací, nicméně time-to-market se naopak dosti pohoršil a to včetně nákladů spojených se změnami v systémech v důsledku integrace. Componentized Překonání nedostatků předchozích fází je možné dosáhnout pomocí reengineeringu IT systémů do podoby komponentních systémů. To si vyžaduje přetvořit jejich architekturu tak, aby vznikly ucelené bloky funkcionality, které lze vzájemně integrovat a snadněji upravovat jejich logiku v případě potřeby. Avšak je zde jeden problém a ten je spojen s termínem „loosely coupled“, který je tak často spojován s architekturou orientovanou na služby. Tato úroveň předpokládá spíše opačnou situaci tzv. tightly coupled, což znamená, že integrované aplikace přijímají mnoho předpokladů o použitých technologiích a způsobu integrace. Takže i zde jsou překážky integrace. Service Tato úzká vazba mezi aplikacemi je nahrazena přístupem loosely coupled (tímto termínem se rozumí v této studii minimalizace technologické závislosti mezi IT systémy). Logika v komponentách je přizpůsobena popisu služeb vyžadovaných v rámci procesů. Vzniká zde možnost kompozice aplikací z jednotlivých služeb. Kompozice služeb je však řešena na straně vývoje a není řízena pomocí vydefinovaných procesů spouštěných v rámci procesního enginu za běhu (v runtime modu).


151

Marek Ondruška

Composite Services Na této úrovni předpokládáme Business process management a modelovací jazyky jako BPEL, které je možné spustit přímo v rámci procesního enginu, který podle předepsané sekvence aktivit volá požadované služby. V této souvislosti se hovoří o tzv. choreografii a orchestraci služeb. Na tomto místě je vhodné vysvětlení těchto termínů. Pokud se hovoří o orchestraci, má se tím většinou na mysli, že existuje externalizovaný popis procesu, který definuje přesnou posloupnost volání jednotlivých služeb a který je spouštěn pomocí procesního enginu. Tedy existuje externí entita ve vztahu k volaným službám, která má za úkol zajistit správné volání služeb (stejné jako dirigent v orchestru). Na druhou stranu choreografie je defakto vložení procesu do kolaborace služeb. Neexistuje externí entita, která by zajišťovala správné volání, ale každá služba „zná své místo“ v rámci procesu, tj. čeká definované vstupy, implementuje danou část procesu a poskytuje určité výstupy.

Obrázek 4 - doménový přístup a přístup přes E2E procesy Vyjdeme z předpokladu, že v dnešní době se prosazuje procesní řízení podniků, které je spojováno s BPM. Dále budeme nahlížet na IT jako na poskytovatele IT služeb včetně aplikačních služeb (service provider). Business je klientem těchto služeb (service consumer). Integrace tohoto typu řeší otázku napojení business procesů na aplikační služby, viz obr 5. Takové napojení lze označit dle definice jako specifický typ integrace v rámci podniku, neboť cílem je vytvořit ucelený systém procesů a služeb IT systémů, které se v čase budou neustále měnit a vzájemně vylaďovat a tvořit tak ucelený konzistentní systém prostřednictvím dobře zvládnuté integrace.

152



Obrázek 5 - Vztah mezi business procesy a IT systémy Při tomto typu integrace se doporučuje kombinovat přístupy bottom-up a top-down. Tedy na jedné straně provést dekompozici business procesů a na straně druhé budovat a skládat služby IT systémů, které respektují „IT realitu“. Tento přístup klade nemalé nároky na propojení strany businessu s IT a účelné a účinné vyjednávání o podobě integrace aplikačních služeb a business procesů viz obr 6. Pokud by byl zvolen pouze přístup Top-down, tak může dojít k tomu, že požadavky na IT systémy budou nerealistické (např. příliš široký rozsah požadavků), které IT nebude schopno pokrýt, např. z důvodu nedostatečných kapacit. Na druhou stranu, pokud bychom vycházeli pouze od IT systémů, tak to může způsobit, že funkcionalita nabízená IT systémy bude přesahovat reálné potřeby business procesu. Proto je vhodné oba přístupy kombinovat, jak je znázorněno na obr 6. Této problematice mj. se věnuje publikace[JOS07].


153

Marek Ondruška

Obrázek 6 - Vztah procesních požadavků a poskytovaných služeb

4. Integrace Business architektury a IT architektury Další oblastí, která svojí povahou spadá do oblasti integrace, je vztah business architektury a IT architektury. Tyto dvě oblasti nesmí existovat vzájemně nezávisle ba právě naopak. Zde je na místě vysoká míra integrace, ať již na úrovni architektonických procesů, tak na úrovni různých architektonických aktiv (modelů, guidelines, principů a pravidel tedy governance), které je potřeba také integrovat. Významná je také integrace Business a IT architektury ve vztahu k projektové metodice, kterou se zde však zabývat nebudeme, stačila by na pokrytí samostatné studie. Business architektura Business architektura je relativně nový fenomén oproti architektuře v oblasti informačních technologií. Zahrnuje funkční architekturu, procesní architekturu a informační architekturu popř. i architekturu business služeb. Rozsah může být i širší. Business architektura vytváří a udržuje model businessu z různých pohledů zaměřujících se na určité elementy – procesy, funkce a data. Lze modelovat i další elementy, které však bývají součástí výše uvedených modelů, např. události events v této souvislosti se hovoří o tzv. event driven architecture. Tyto modely se využívají pro řízení business architektury podniku. Pokud uvážíme moderní trendy v oblasti architektury, tak lze obohatit business architekturu o služby. Tento koncept, však silně ovlivňuje vlastní tvorbu business architektury, neboť např. procesy chápe jako orchestraci/choreografii jednotlivých služeb do sekvence jejich

154



volání tvořících vlastní business proces, který jako celek může poskytovat také službu. Tento přístup má také značné dopady i na organizační strukturu podniku. Business architektura by měla respektovat pattern integrace popsaný v kapitole integrace IS/ICT na procesy. Tento pattern by měl být reflektován i v rámci vytvářených modelů procesů, funkcí, entit a služeb. Na tomto místě je vhodné poznamenat, že integrace mezi business architekturou a IT architekturou je také na úrovni procesů, tj. architektonické procesy, jak na straně businessu, tak na straně IT by měly být adekvátně provázány. IT architektura Jedná se o služby a procesy, které jí zajišťují, v rámci podniku. IT architektura by měla primárně dodávat koherenci do služeb IT systémů a způsobů zajištění jejich poskytování. IT architektura zahrnuje tyto roviny: aplikační, datovou a technickou (infrastrukturní) architekturu. Jedná se o procesy realizující službu architektury, které musí zajistit vývoj ve výše uvedených oblastech v čase v reakci na měnící se požadavky a prostředí, ve kterém je podnik situován společně s reakcí na technologické trendy a interní optimalizaci podniku. Obdobně jako business architektura i IT architektura vytváří v rámci své činnosti nejrůznější modely, pravidla, principy obecně governance pro různé oblasti. Tyto pak využívá jako nástroje pro řízení architektury IS/IT. Na druhou stranu využívá referenční modely, nástroje, architektonické Frameworky pro podporu své činnosti.

5. Integrace podniku na okolní svět (B2B) Podnik neexistuje ve vzduchoprázdnu. Musí být v interakci s okolním světem, aby mohl přežít. Neboli musí být zajištěna integrace podniku na okolní svět včetně jednotlivých osob, ať již právnických či fyzických – partneři, dodavatelé, finanční instituce, státní instituce (eGovernance) a další. Tímto způsobem vznikají mnohdy komplikované sítě podniků, které mají integrační potřeby. Integrace se zákazníky zde uvažovat nebudeme, tou se zabývá vlastní oblast označovaná tj. jako B2C a systémy typu CRM a jiné. Integraci podniku na okolní svět je vhodné chápat, tak že nejde jen o integraci aplikací, ale také o procesní integraci. Aby bylo účelné stavět systémy založené na komunikaci aplikací, které jsou vlastněny různými podniky, musí existovat určitý kontext, ve kterém tyto aplikace budou integrovány. Tímto kontextem jsou procesy a jejich integrace. Pod B2B v užším smyslu budeme rozumět výpočetní techniku a softwarové vybavení a integraci těchto napříč podniky. B2B v širším smyslu zahrnuje i business a vlastní integraci business procesů na procesy ostatních externích podniků, s kterými je podnik propojen. Toto propojení je vhodné chápat jako kolaboraci mezi podniky, která má určitý cíl a probíhá ve vymezeném kontextu. B2B v užším smyslu je defakto důsledkem B2B v širším smyslu. Jedná se o promítnutí integrace mezi podniky do oblasti IT a výpočetní techniky. Tato užší SYSTÉMOVÁ INTEGRACE 4/2009

155

Marek Ondruška

integrace může být řešena pomocí různých integračních patternů a jejich kombinací. Mezi typické integrační patterny pro oblast B2B [SAM02]: Datově zaměřená integrace Unifikace přístupu k datům a sjednocení způsobu přístupu v podobě standardizovaných interfaců; snaha se vyhnout proprietárním interfacům a synchronizace dat napříč podniky. Aplikačně orientovaná integrace Zaměření na propojení aplikací pomocí vystavených interfaců (API). Portal oriented integration Jedná se o single point of access k různým službám nabízeným ze strany podniku (podniků). Procesně orientovaná integrace Integrace založená na vydefinovaných procesech. Jako příklad vezměme procesy popsané v jazyku BPEL a spouštěné v rámci procesního enginu, při kterém může dojít k volání systémů napříč podniky.

Obrázek 7 - Roviny B2B integrace Existuje situace, kdy se mohou tyto roviny obr. 7 sloučit a to v případě, kdy jsou business procesy plně automatizovány B2B řešením, tj. business procesy jsou implementovány v rámci IT řešení. Takovou situaci lze označit jako „úplnou“ automatizaci definovaného business procesu. Mezi cíle B2B lze zařadit: snahu eliminovat chyby ve zpracování B2B transakcí lidmi. Např. automatizace zpracování objednávek, zvýšit rychlost kolaborace mezi podniky na úrovni přenosu dat a zvýšit flexibilitu podniku ve smyslu rychlé integrace na jiné podniky.

156



I v oblasti B2B se prosazují moderní trendy jakým je např. architektura orientovaná na služby. Typický model této situace je, že jeden podnik volá službu poskytovanou na straně podniku druhého. Neboli vzniká vztah service consumer-provider v kontextu B2B. Využitelnost kolaborace (B2B) mezi podniky závisí na velikosti a typu podniku. Obecně nelze říci, že B2B je řešení, které je vhodné pro každý podnik. Je nutné vzít v potaz, že náklady na vybudování takového řešení jsou často vysoké. Nicméně u podniků větších rozměrů se i přes to tento typ integrace vyplatí vybudovat. B2B má čím dál větší význam vzhledem k moderním trendům tvorby partnerství mezi podniky častými fůzemi, akvizicemi aj. Ve všech těchto případech vyvstává otázka integrace včetně B2B. K tomu, abychom mohli vytvořit B2B je mnohdy zapotřebí zajistit EAI. Dejme tomu, že máme v plánu nabízet svému partnerovi určitou službu, např. poskytnout informace o daném klientovi. Pro tento úkol bude pravděpodobně zapotřebí, aby byly volány různé systémy na straně poskytovatele služby a došlo k jejich vzájemné spolupráci, což není nic jiného než EAI. V dnešní době existuje nepřeberné množství řešení v podobě middlewarových systémů, které nabízejí služby jak EAI viz kapitola „Aplikační integrace“, tak služby v oblasti B2B. Middleware podporující EAI a B2B sdílejí řadu podobných charakteristik a funkcionality. Dochází ke sbližování těchto oblastí [SAM02]: datová transformace, využívaní adaptérů, zasílání zpráv, inteligentní směrování zpráv a procesní management. Na druhou stranu se, ale rozcházejí např. v oblasti bezpečnosti. Resp. zajištění bezpečnosti mezi podniky a v rámci podniku klade poněkud odlišné míry zabezpečení. Když byla diskutována otázka organizačních řezů (sila) podniku, tak tento model lze aplikovat na problematiku kooperace podniků. S narůstající potřebou spolupráce podniků narůstá potřeba integrovat jejich IT systémy a to pokud možno co nejrychleji.

6. Závěr Studie pojednala o podnikové integraci z pohledu architektury. Byly popsány základní oblasti této integrace. Avšak každé z probíraných témat by svým rozsahem stačilo na pokrytí knihy, je proto potřeba tuto studii chápat spíše jako rozcestník. Míra detailu studie reflektuje její rozsah. Zejména kapitola integrace business architektury a IT architektury je poměrně rozsáhlou a komplikovanou oblastí. Zde je spíše základní nástin této problematiky. Poznamenejme, že oblast integrace v podnicích zaznamenává v poslední době značný rozvoj doprovázený emergencí enterprise a business architektury v podnicích.


157

Marek Ondruška

Literatura [CHA03] Chandra D., Liu A., Roxburgh U., Mason A., Nadhan G. E.,Paul S.; Guidelines for Application Integration; 2003; Dostupné z www: http://msdn.microsoft.com/en-us/library/ms978650.aspx [FOW02] Fowler M.; Patterns of Enterprise Application Architecture;Addison Wesley; 2002 [JOS07] Josuttis N., M.; SOA in practice; O’REILLY; 2007 [KHO07] Khosrowpour M.; Dictionary of Information Science and Technology; Idea Group; 2007 [HOH03] Hohpe G., Woolf B.; Enterprise Integration Patterns; Addison Wesley; 2003 [IBM09] Enterprise Service Bus and Connectivity Patterns; IBM; 2009; Dostupné z www: https://www.ibm.com/developerworks/wikis/display/esbpatterns/ ESB+and+Connectivity+Patterns [LIT99] Linthicum D.; Enterprise Application Integration; Addison Wesley; 1999 [OSI06] Open Group; OSIMM; 2006; Dostupné z www:https://www.opengroup.org/projects/osimm/uploads/40/17990/OSIMM_ v0.3a.pdf [SAM02] Samtani G.; B2B Integration - A Practical Guide to Collaborative E-commerce; Imperial College Press; 2002 [TOG09] The Open Group Architecture Framework; 2009; Dostupné z www:http://www.opengroup.org/architecture/togaf9-doc/arch/

158


Architektura informačního systému z pohledu integrace v kontextu podnikové integrace

Recommend Documents