Integrace – podmínka efektivního zavádění (G)IS
Ing Ladislav Sedláček
Digis, spol. s r.o.
Gen.Sochora 6176
708 00 Ostrava-Poruba
tel (069) 693 8987
e-mail: das-admin@digis.cz
motto:
z h…a bič neupleteš,
a když upleteš, tak nezapráskáš,
a když zapráskáš, tak jenom sebe
(lidová moudrost)
Abstract
Integration seems to be one of the most discussed themes of IT nowadays. This paper is an attempt to focus on this problem from the (end-)user point of view. The main aim of the paper is to specify sources and consequences of conflicts of the integration, explain to the user what aspects the integration comprises, especially concerning particular components of IS (data, applications, platforms, orgware). Special attention is paid to how to prevent implementation difficulties and how to conceptually approach an integration as the dominant feature of the intended complex IS.
Abstrakt
Zdá se, že integrace je v dnešní době jedním z nejdiskutovanějších témat v oblasti IT. Tento článek je pokusem popsat tento problém z pohledu (koncového) uživatele. Hlavním cílem příspěvku je specifikovat zdroje a důsledky konfliktů integrace, vysvětlit uživateli, které aspekty integrace zahrnuje, zejména týkající se jednotlivých komponent IS (datové, aplikační, technické, organizační složky). Zvláštní pozornost je věnována předcházení implementačním potížím a koncepčnímu přístupu k integraci jako dominantní vlastnosti zamýšleného komplexního IS.
Zdroje problému integrace
Integrace je jedním z nejčastěji používaných termínů v oblasti IT, ať je s ním spojován proces, stav, jev nebo technologie. Mnohdy se zdá, že zájem o tento pojem a problematiku s ním spojenou inflačně klesá a zase narůstá, jako by šlo o módní záležitost. I přes množství seminářů a konferencí pořádaných na toto téma a nepochybný pokrok v tomto směru daný překotným vývojem informačních technologií jsou neustále patrné nejistota a rozpaky při vyslovení tohoto slova na straně uživatelů produktů informačních technologií. Tento příspěvek je proto určen uživatelům-zákazníkům s cílem poodhalit roušku tajemství skrývajícího se za tímto pojmem. Tomu odpovídá i silně pragmatické pojetí. Omluvu nechť přijmou ti zájemci o tuto problematiku, které by se mohli cítit dotčeni zbytečným popisováním některých jim samozřejmých skutečností.
Příčiny nedostatečného povědomí uživatelů-zákazníků o integraci jsou zřejmé – odborníci-specialisté nejsou motivováni k tomu, aby uživatelskou stranu srozumitelně komplexně s problematikou seznámili – nadneseně řečeno, nepořádají se semináře a konference na téma integrace pro uživatelskou část veřejnosti.
Důsledkem jsou potom následující situace. Uživatel-zákazník pojme úmysl pořídit si daný produkt (aplikaci, program) a vznese dotaz na tvůrce/dodavatele, zda je možno jeho produkt “propojit” s produkty, které již provozuje. Dostane se mu často pozitivní odpovědi. Mnohdy se ani neinformuje a předpokládá, že “se to nějak propojí”. Slovo “propojit” přitom vnímá jako zaklínadlo, samozřejmost, do které vloží se vší vírou a důvěrou svůj uživatelský osud, aniž má konkrétní představu, co se pod tímto slovem skrývá. Jak velké bývá mnohdy posléze rozčarování.
Prapůvod všech potíží zřejmě tkví v abstraktním pojmu, který je s integrací úzce spojen, v pojmu – systém.
Odborná veřejnost pohlíží na tento pojem z hlediska jeho základní definice – systém je (účelově na dané rozlišovací úrovni) definovaná množina prvků a vazeb mezi nimi. Rozlišovací úrovní se přitom rozumí skutečnost, že je neužitečné z hlediska požadavků na systém zahrnovat do systému to, z čeho se prvky skládají a jaké jsou mezi těmito podprvky vztahy. Účelovostí se myslí fakt, že při vymezování systému nás zajímá určitá část reálného světa z určitých hledisek a ne jakákoliv část z libovolných hledisek. Všimněte si, že tato definice neříká nic o počtu prvků a počtu vazeb. Z logiky definice plyne, že existence vazeb může být podmíněna existencí alespoň dvou prvků (stačil by i jeden). Neříká však, že vazby mezi prvky musí nutně existovat, ani neříká, že v případě že existují, jaký mají mít charakter.
Laická (uživatelská) veřejnost inklinuje k chápání pojmu systém jako synonyma pro stav uspořádání (objektů, jevů, procesů). Toto pojetí sice není úplně od věci, ale je příliš úzce zaměřené na vlastnost systému, nehledě na jeho pocitový podtón. Slovo uspořádání je však mnohem bližší pojmu integrace než pojmu systém. Integraci lze skutečně chápat i jako uspořádávání (jde-li o proces nebo technologii) nebo uspořádání (jde-li o stav nebo míru stavu).
Co a o čem je integrace.
Z pohledu laické (uživatelské) veřejnosti se integrace (jako stav) dá opsat slovy soulad, kompaktnost, homogenita, provázanost apod. (integrace jako proces je soubor činností vedoucí k tomuto stavu). Tyto pojmy vcelku dobře pojem integrace charakterizují. V úvodní pasáži tohoto příspěvku byl problém naznačen jako “propojení” dvou (a více) systémů (je lhostejné, máme-li na mysli svébytné-autonomní systémy nebo podsystémy nějakého systému). Na integraci se tedy budeme dívat jako na soudržnost, kompaktnost, homogenitu, provázanost, konzistenci systémů/subsystémů/prvků v rámci celku (systému) o jehož vytvoření usilujeme.
Tato pracovní definice možná postačuje pro uživatele systému k vysvětlení pojmu integrace, ale pro tvůrce systému jako reprezentanta odborné veřejnosti mají tyto pojmy zcela konkrétní, řekněme “technicko-inženýrskou” podobu. Jako příklad si představme budovu jako systém, který má dva subsystémy – základy a nástavbu. Pokud budou mít základy jiné dispozice než zamýšlená nástavba, pak zřejmě budova jako celek nebude odpovídat naší definici integrace (pokud vůbec za této situace si bude možno nějaký celek představit). Takže integraci posuzujeme z hlediska toho, nakolik každý z obou systémů je svými “dispozicemi” připraven akceptovat ten druhý a naopak. Dokonce můžeme připustit, že onen soulad (shoda, kooperace, apod.) nemusí být stoprocentní, ale do jisté míry postačující (vyhovující). Tedy integrace má svou míru. Tato míra je dána splněním/nesplněním tzv. integritních omezení (podmínek, požadavků,…).
Nikoho z nás by nenapadlo postupovat při pořizování vlastního domku tak, že si vybudujeme nějaké “sympatické” základy, potom si od některé projekční společnosti vybereme pěknou nástavbovou část (vlastní domek), a potom si pozveme stavební firmu, ať nám to nějak “propojí” (rozuměj – postaví domek na vybudované základy). Pokud základy a domek nebudou od počátku navrhovány tak, aby jako celek dávaly homogenní, provázaný = integrovaný systém, je nutno:
Pokusme se nyní tento problém objasnit na případě informačního systému. Na IS lze nahlížet z mnoha hledisek. Jak již bylo naznačeno, je rozdíl mezi pohledem na IS ze strany jeho uživatele a jeho tvůrce. Abychom si objasnili pojem integrace, půjdeme tentokrát cestou pohledu tvůrce, byť poněkud zjednodušenou. Z pohledu tvůrce je IS prvotně tvořen následujícími složkami (subsystémy):
Tady je zřejmé, že tvůrce (na rozdíl od uživatele) nevidí IS především jako celek skládající se z majetku města, katastrální mapy, územního plánu, ohlašovny apod. Tento pohled je pro něj druhotný.
Datová složka (aplikační) reprezentuje veškeré informace o prvcích (objektech) té části světa, kterou IS zahrnuje (např. data o občanech, domech, katastrech, parcelách apod.). Jednotlivé prvky jsou popsány tzv. atributy (občan má atributy jméno, příjmení, rodné číslo, …; parcela má atributy skupina, kmen, podlomení, výměra, využití, …). V datové složce jsou i údaje o tom, jak tyto prvky (objekty) spolu souvisejí (občan bydlí v domě, katastr zahrnuje parcelu, apod.) případně jaké jsou a mohou být jejich grafické obrazy. To vše včetně způsobu uložení těchto dat lze zahrnout pod pojem formát datové složky. Z pohledu uživatele je cílem řešení IS obsahová úplnost, aktuálnost a správnost informace. Pro tvůrce systému je cílem řešení datové složky právě návrh formátu, na jehož základě potom vytváří funkční složku IS !
Obsahové hledisko postihuje jeden zásadní problém – duplicitní implementace dat v rámci dvou různých formátů. Tato situace nastane, když dva posuzované IS mají vlastní strukturu (formát) datové složky, v jejichž rámci je definováno místo pro stejné objekty (např. občany, parcely,…). Každý z obou IS umí pracovat s těmito daty jen ve vlastním formátu. Pokud začneme používat oba IS, budeme muset vést stejné informace např. o občanech v různých datových formátech (implementovaných pro databáze obou IS). Pak nastávají těžkosti při změnách v datech, tzn. jak zajistit to, aby se každá změna provedená v databázi jednoho IS promítla i do databáze druhého IS.
Datovou složku je třeba chápat podobně, jako základy nějaké budovy. Rozměry a další parametry základů určují dispozice budovy (aplikační nástavby), která je na nich postavena. Z tohoto důvodu je jim třeba věnovat mimořádnou pozornost – jakmile se nástavba (aplikace) jednou postaví, nezbývá mnoho prostoru pro dodatečné zásadní zásahy do základů (dat).
Funkční složka (aplikační) reprezentuje veškeré aplikační programové komponenty (zjednodušeně programy). Je třeba si uvědomit, že program je napsán v závislosti na struktuře a obsahu datové složky. To znamená, že když se datová složka změní, je třeba program, který s ní pracuje, upravit. Čím větší je tato změna, tím výraznější je zásah do programu. Často se může jednat i o kompletní přeprogramování a tedy vytvoření nového programu.
Důležitým momentem v tomto směru je možnost škálování (definování potřebné struktury a parametrů) funkční složky. Možnosti škálování jsou dány tím, z jak malých základních programových komponent (modulů, procedur, funkcí…) je postupně “program” vystavěn a zda je možno tyto komponenty z programu vyřadit, nebo do programu zařadit. Čím je možnost škálování jemnější, tím přesněji lze implementovat tu funkcionalitu, která se v daném případě požaduje. Pokud je škálování příliš hrubé, může se projevit nepříznivě v tzv. duplicitách funkční složky, kdy dva různé programy pro různé účely se shodují v části své funkcionality nad stejnými daty, ale zcela odlišného pojetí (ne nutně špatného !). Jak potom zamezit neoprávněnému uživateli v úmyslném nebo neúmyslném použití této funkcionality ?
Funkční složku můžeme přirovnat k nástavbové části budovy nad jejími základy. Pokud se dispozice základů (datová složka) změní, musí se změnit odpovídajícím způsoben i dispozice nástavby (funkční složka). Pokud je nástavba řešena jako jediný modul, je složité ji přizpůsobit. Pokud je tvořena menšími manipulovatelnými moduly, jsou možnosti úprav variabilnější.
Je třeba si uvědomit, že i pouze přejmenování jediného atributu v datové složce může vyvolat velký objem práce na úpravě funkční složky.
Technická složka IS nereprezentuje pouze technické (HW) vybavení (počítače, sítě, tiskárny, apod.), ale rovněž i tzv. základní programové (SW) vybavení (například operační systém, databázový systém, speciální prostředí pro provozování aplikace tzv. runtime apod.). Z pohledu integrace se problematika technické složky ukrývá pod pojmem tzv. platformy. Pokud dané IS akceptují stejné platformy, jsou technicky kompatibilní, nejsou potom problémy s jejich implementací do jednotného (integrovaného) prostředí. Pokud je dokonce IS na některé z platforem nezávislý (např. na konkrétním databázovém systému), pak se jedná o platformově nezávislý (otevřený) IS. Opakem je platformová závislost resp. podmíněnost.
Speciální pozornost je přitom třeba věnovat organizaci, dispozičnímu řešení a parametrům technické složky (např. lokalizace a distribuce databázového prostoru, tzn. kde a jak bude datová složka umístěna, zabezpečení klient/server komunikace, tzn. kde a jak budou instalovány a provozovány aplikační programy a základní sw, škálování základních komponent apod.) a to pro všechny integrované produkty (informační systémy).
Organizační složka IS představuje veškeré podmínky, pravidla a postupy týkající se provozování a užívání IS. Zahrnuje stanovení pravomocí (autorizace) a povinností všech druhů uživatelů při užívání a správě datové, funkční a technické složky.
Tzv. koncovému uživateli se umožní pracovat s určitými “programy” (funkcemi) a v jejich rámci i určitými daty. Dokonce se mu může dát za povinnost s těmito nástroji pracovat, vytvářet a aktualizovat informace v IS pro potřeby vlastní i jiných koncových uživatelů.
Jiná pověření má tzv. intermediální uživatel. Jak už z pojmenování vyplývá, jedná se o jakéhosi prostředníka mezi koncovým uživatelem a tvůrcem/dodavatelem IS. Jeho úkolem skutečně je zprostředkovat kontakt koncového uživatele s tvůrcem resp. zastupovat tvůrce u koncového uživatele a naopak. Pomáhá řešit situace, se kterými si koncový uživatel neví rady, protože intermediální uživatel má mnohem hlubší vědomosti o struktuře IS (formátech dat, implementaci datové i funkční složky, technických vlastnostech jednotlivých platforem apod.) než koncový. Na druhou stranu intermediální uživatel není pověřen zabývat se úplností, přesností a správností aplikačních dat a vykonáváním aplikačních funkcí (operací). Intermediální uživatel je pověřen jinými úkoly spojenými se zajištěním bezproblémového chodu všech složek IS (tzv. administrace) zahrnující předepsané i vyvolané pravidelné i nepravidelné administrační úkony.
V mnoha případech, pokud k tomuto není pověřen externí subjekt (osoba, firma, … tzv. systémový integrátor), provádí intermediální uživatel i posuzování, zda zamýšlený nový produkt (systém, program apod.) vyhovuje struktuře dosavadního IS, tzn. zda ho lze integrovat do stávajícího prostředí IS. Pokud je nový produkt zařazen do IS, začne podléhat i všem postupům a podmínkám organizační složky, které jeho integraci završí.
Z výše uvedeného je zřejmé, že koncový uživatel je především zaměřen na aplikační datovou a funkční složku – přesněji na užitečnost funkcionality a potřebu dat. Předmětem činnosti intermediálního uživatele je technická a organizační složka systému a rovněž technické podmínky provozování datové a funkční složky. Je třeba zdůraznit, že pod pojmem uživatel můžeme rozumět jednu osobu (uživatele produktu), ale i celý útvar nebo úřad (obchodní partner dodavatele). Konkrétní personální (kapacitní, i externí) zabezpečení je individuální záležitostí každého uživatelského subjektu (úřadu).
Jak řešit integraci.
Shrňme si příčiny, které vedou ke stavu, kdy dva posuzované systémy mohou nabídnout nevyhovující míru integrace
Nyní se pokusme popsat, jaké jsou možnosti řešení jednotlivých konfliktů integrace, tzn. jaké požadavky by mohly být kladeny na tvůrce IS v souvislosti se zásahy do jeho produktu. Je třeba hned úvodem říct, že v podstatě každý takovýto problém je z čistě technicko-technologického hlediska řešitelný (viz. náš domek). Otázkou ovšem je za jakou cenu. Rozsah řešení daného problému má příliš velké rozpětí od drobného zásahu až po kompletní “předělání” produktu (= vytvoření nového, často na bázi zcela jiných komponent ). A tomu samozřejmě odpovídají i náklady. Nákladová položka má svoji okamžitou složku (na provedení úpravy) a průběžnou složku (na podporu a vývoj modifikované verze produktu).
Možná řešení a)
Provedení úprav datové složky, které vedou k méně náročným zásahům do funkční složky obou IS, než kdyby se měl přizpůsobit jen jeden z IS. Výsledkem je, že oba IS pracují nad společnou datovou složkou. Kromě možné velké finanční náročnosti tohoto postupu je zde problém neochoty ze strany tvůrce provést tuto úpravu a tím vytvořit speciální modifikaci svého produktu pro daného uživatele. Tuto modifikaci potom musí dále podporovat a rozvíjet.
Vynucení úpravy na straně jednoho z obou IS (nejčastěji toho nového nebo “menšího”). Ostatní viz předchozí řešení.
Vytvoření společného funkčního rozhraní, prostřednictvím kterého si oba IS předávají data a instrukce co s nimi dělat. Toto řešení většinou neodstraňuje (ale s omezeními může) problém duplicity datové složky jak byla popsána výše. Je možno předpokládat relativně menší náklady s potenciální možností stejného přístupu i v jiných případech (není nutno vytvářet modifikace produktu). Kardinálním problémem tohoto pojetí je však nestandardnost komunikačního rozhraní, které může výrazně omezit funkcionalitu u obou IS. Výhodou je, že každý z kooperujících IS provede příslušnou operaci na “své straně” (ve své databázi) korektně v celém kontextovém rozsahu.
Možná řešení b)
Odinstalování nebo zablokování nežádoucí funkcionality, pokud je reprezentovaná komponentou. Zejména v případě objektově založených řešení (object based systems) by tento problém měl být bezbolestně řešitelný.
Zablokování (disable) uživatelského rozhraní nežádoucí funkcionality zásahem do programu. Z toho plyne vytvoření modifikace programu pro tento případ a nezbytnost ze strany tvůrce tuto modifikaci podporovat a rozvíjet.
Možná řešení c)
Tento problém je v rovině technické složky. Ve svých důsledcích na provoz IS jako celku má tedy výrazný vliv. Tomu odpovídá i razantnost, ale zároveň jednoznačnost možných řešení. Jednou z možností je, že jeden ze systémů se platformově přizpůsobí.
Druhou z možností je souběžný provoz obou platforem s patřičným zabezpečením provozně-technických podmínek (a to může být někdy těžko řešitelné). Jako příklad rozporu je možno uvést platformy OS (např. Unix vs. Windows), databáze (např. SQL Server vs. Oracle), síťový komunikační protokol (např. IPX/SPX vs. TCP/IP) apod. Souběžné provozování může mít někdy výrazný dopad i na funkční složku.
Možná řešení d)
Zde se jedná zejména o případy, kdy uživatel disponuje jistým technickým vybavením, které uvažovaný IS neumí využít (např. terminálová síť vs. síť pracovních stanic, plotry vs. tiskárny apod.) protože nemá definované rozhraní. V tomto případě v podstatě platí totéž co pro c)
Existuje ještě jedno univerzální řešení
Orientovat se zcela pouze na jediný “komplexní” produkt/službu jediného dodavatele/tvůrce. Potom skutečně mizí výše popisované problémy, protože vše je řešeno jako jediný IS v kompetenci jednoho tvůrce. Tato výjimečnost v řešení integrace je však kompenzována výjimečným nebezpečím “technologického (tvůrce má tendenci dělat co, jak a do kdy jak sám uzná za vhodné) a obchodního (tvůrce má tendenci diktovat ceny a produkty bez obav z konkurence) vazalství” uživatele vůči tvůrci. Z takového “vztahu” je velmi obtížná (a drahá) cesta ven.
Z výše uvedeného velmi rámcového výčtu je zřejmé, že než se uživatel rozhodne pořídit nový nebo rozšířit stávající IS, je třeba zvážit řadu faktorů. Toto “zvažování” se uskutečňuje na základě tzv. studie proveditelnosti (feasibility study). Studie má za cíl posoudit všechny výše zmíněné aspekty s určením, jaké zásahy a opatření je nutno v systému provést (tzv. reengineering), aby všechny složky (stávající, nové i potenciální) byly dostatečně interoperabilní/konzistentní, zda existuje nejen technická, ale i obchodně-dodavatelská možnost řešení a za jak dlouho a za kolik se dá implementace realizovat.
Ve většině případů je zpracování studie proveditelnosti nad síly a možnosti MÚ. Toto je právě jedna z “parket” systémového integrátora (SI). Pro budování rozsáhlého IS je SI nezbytný. Při volbě SI je nutno velmi pečlivě stanovit pravidla jeho působení. Kritickým momentem je třeba skutečnost, že SI disponuje vlastním produktem/službou, kterému na trhu IT konkurují jiné produkty/služby jiných poskytovatelů. Pak zde hrozí nebezpečí, že SI nebude uživateli (MÚ) doporučovat optimální, ale svoje produkty. Tento stav se postupně může vyvinout v již zmíněný “vazalský” vztah.
Závěrečné doporučení
Nepřeceňovat profesní hodnocení produktu na úkor jeho technologické vhodnosti pro zamýšlený celek.
Raději pořídit aplikační systém, který méně přitažlivě, ne zcela úplně, méně přehledně pokrývá danou profesní problematiku, ale který lépe technologicky zapadá do konceptu budovaného komplexního IS. Problémy spojené s profesním dopracováním takového produktu jsou mnohem menší (a levnější) než ty, které jsou spojené se zakomponováním