CIF: Továrna na informace

DEFINICE CIF (Customer Information Factory) je koncepce architektury informačních systémů, která umožňuje z dat v prov...


DEFINICE
CIF (Customer Information Factory) je koncepce architektury informačních
systémů, která umožňuje z dat v provozních systémech účinně vytvářet informace,
jež jsou klíčové pro strategické rozhodování.

Součástí podnikatelské strategie každé firmy jsou dvě složky: stávající
podnikatelský záměr a budoucí strategie. Řízení stávajícího podnikatelského
záměru je podpořeno provozními daty, naproti tomu plánování budoucí strategie
firmy se opírá o analytická data. Poskytování uvedených typů dat představuje
pro informační systémy dva zcela protikladné úkoly. Pokud má jeden systém
zajistit obojí, od určité velikosti firmy a složitosti procesů vznikají
problémy. Systém má pomalou odezvu, jeho provoz i údržba jsou nákladné,
zavádění nových produktů na trh trvá dlouho apod.
Častějším přístupem je proto prioritizace a optimalizace systému pro zajištění
běžného provozu. Informace nutné pro krátkodobé až střednědobé strategické
řízení lze pak získávat pouze za předpokladu, že nebude ohrožen provoz, tedy
pouze omezeně a v mnoha případech vůbec. Důsledky jsou podobné jako v prvním
případě, projeví se pouze s jistým zpožděním. CIF zde nabízí řešení. Zavádí
specializaci komponent informačního prostředí pro konkrétní typy úloh a
definuje pravidla pro jejich vzájemnou komunikaci.
Komponenty v CIF se rozlišují na:
lprovozní systémy
lanalytické systémy
loperativní sklad
lintegrační vrstvu
lmetadata
Liší se účelem, typickými uživateli i způsobem uložení dat, jejich zpracováním
a použitými technologiemi.

Provozní systémy
Provozní systémy jsou ty aplikace, které pokrývají základní obchodní procesy
firmy a kde vznikají data. Data v nich vytváří uživatel (například zadáním
objednávky zboží), vznikají automaticky (třeba vystavením faktury v billingovém
systému) nebo z externích zdrojů (soubor od partnera nebo z internetu).
Výpadek takového systému mívá přímý dopad na zákazníka, proto je nutná jeho
vysoká dostupnost a rychlá odezva. Provozní systémy v CIF jsou optimalizovány
na zpracování jednotlivých požadavků, nikoliv dávek, pracují pouze s daty
nezbytnými pro provoz a neuchovávají historii ani nezajišťují analýzu.
Analytické systémy Při definici strategie je třeba znát současný stav i trendy.
Jak se mění počty objednávek v čase? Jak rychle jsou objednávky realizovány?
Souvisí rychlost realizace objednávek s tím, zda zákazníci zaplatí nebo si
objednají další zboží či služby?
EDW (Enterprise Data Warehouse) je analytické prostředí, které vytváří kopii
těch dat z provozních systémů, která jsou podstatná pro analýzu a strategické
rozhodování. Data z více zdrojů integruje do jednoho obrazu obchodní entity
tak, jak ho chápe firma. Historii uchovává podle potřeby, často i desítky let.
Dotazy nad EDW jsou jednodušší a nezpůsobují žádnou dodatečnou zátěž provozních
systémů.
EDW mívá typicky tyto komponenty:
lDimenze seznamy hodnot, ke kterým se vztahují obchodní události, například
seznamy zákazníků, produktů či seznam dnů v roce. Tvoří jakési souřadnice
prostoru pro analytické dotazy. Lze je seskupovat do hierarchií (například
dimenze kalendářních dní je seskupena do kalendářních měsíců nebo jsou produkty
sdruženy podle oblasti podnikání). V databázi bývá dimenze uložena jako tabulka
s klíčem, s jedním či více popisky a u hierarchických dimenzí s odkazem na
nadřízenou hodnotu. Počet řádků je malý, záznamy se nemažou, přibývá jich
zvolna. lFakta obchodní události, například založení objednávky, vystavení
faktury či přijetí platby. Obsahují odkazy na dimenze a veličiny. Dimenze
například definují, ke kterému zákazníkovi, produktu a dni v roce se objednávka
vztahuje. Veličiny určují například počet kusů, zaplacenou částku apod. Dimenze
tedy umisťují fakta do souřadnic, zatímco veličiny dávají bodům v prostoru
konkrétní hodnotu.
Fakta jsou uložena v tabulkách i s cizími klíči pro tabulky dimenzí a s
hodnotami veličin. Počet řádků bývá vysoký a rychle roste.
lDatamarty díky EDW se analytický dotaz zjednodušil na spojení několika tabulek
v jedné databázi. Pokud je ale dat mnoho, může práce s nimi stále trvat velmi
dlouho. Lze ovšem předem připravit struktury, které dotaz omezí na jednu
tabulku a navázané dimenze. V tabulce jsou předem spojeny a agregovány údaje z
více faktových tabulek. Takovým tabulkám se říká datamarty.
Speciálním typem datamartů jsou datové kostky. Ty využívají hierarchických
dimenzí. Uživatel si může zobrazovat veličiny na různé úrovni agregace v
různých dimenzích a hledat v datech trendy a souvislosti. Správně navržené
datamarty jsou rozhodně přínosem, mají ale i svá proti. Jejich údržba není
nijak jednoduchá (při chybě kdekoliv mezi provozním systémem a datamartem je
třeba přepočítat všechny odvozené údaje). Je proto třeba důkladně zvážit, kdy
je vytvářet a s jakými dimenzemi a veličinami. Jejich minimální počet by měl
pokrýt maximum požadavků. Jejich správný návrh je složitý a vyžaduje velmi
důkladnou znalost prostředí i potřeb uživatelů.

Operativní sklad
Provozní systémy jsou často zatěžovány i dotazy z jiných aplikací. Pokud
provozní systém zátěž zvládá, je vše v pořádku. Pokud ne, existuje pro dotazy,
které data pouze čtou, podobné řešení jako pro potřeby analýzy. Je jím úložiště
dat specializované na dotazy aplikací, operativní datový sklad (ODS,
Operational Data Store). ODS se vlastnostmi hodně podobá EDW. Získává data z
provozních systémů a integruje je do obchodních entit. Několik dotazů do
provozních systémů tak lze nahradit jediným dotazem do ODS. Neuchovává ale
historii, je jen aktuálním obrazem provozních systémů. Zatímco do EDW lze data
načítat se zpožděním (analýza trendů nevyžaduje údaje z posledního dne), do ODS
se změny musejí promítnout v době trvající řádově minuty. Větší zpoždění už
způsobuje provozní problémy.
Použití ODS je vhodné tam, kde je rychlá odezva primárního systému kritická a
není možné jí dosáhnout jen posílením hardwaru. Aplikacím také nesmí vadit
drobné zpoždění aktuálnosti dat v ODS. Kvůli konzistenci by se nikdy neměly
kombinovat dotazy do ODS s dotazy do primárních systémů. ODS musí mít stejnou
dostupnost jako provozní systémy.
ODS lze řešit i jinak než klasickou databází. Může jej tvořit pouze sada funkcí
navržená podle obecné obchodní logiky. Funkce interně dotáže provozní systémy a
složí z dotazů jednu odpověď. Zátěž provozních systémů se tak sice nesníží, ale
architektura okolních aplikací je odstíněna od vlastností jednotlivých
provozních systémů.

Integrační vrstva
Integrace systémů je širším pojmem my se zde omezíme pouze na CIF, kde
integrační vrstva zajišťuje přenos dat z provozu do analytického světa.
Doručení dat do EDW a ODS může být realizováno různými technologiemi: lDotazy
inicializované z EDW a ODS: V tomto typu přenosu cílová komponenta pravidelně
spouští dotaz do dat zdrojového systému. Lze použít například databázový link
nebo nástroje typu ETL (Extract-Transformation-Load). Nevýhodou je, že každá
komponenta se dotazuje zvlášť a zvlášť zatěžuje provozní systém. Data k přenosu
hledá podle časových razítek a složitě odvozuje, co přenést. Jak zjistit, který
obchodní proces způsobil danou změnu? Také více změn stejných atributů
realizovaných mezi dvěma přenosy je pro cílové systémy ztraceno. Pro ODS je
tento typ nevhodný. Nelze efektivně zajistit dostatečně rychlou aktualizaci
dat. lPřenosy inicializované provozním systémem: Provozní systém předá k
přenosu informaci se všemi atributy, a to ihned poté, co k události došlo. Mizí
problém, jak zjistit, co vlastně přenést. lDatabázový link: Cílovým systémům
mohou být data předána přes databázový link. Logika ve zdroji se však
komplikuje s každým dalším cílovým systémem. Navíc je zdrojová aplikace fyzicky
závislá na dostupnosti cílové komponenty.
lPřenos souborů: Jeden soubor je možné použít pro více cílových komponent.
Provozní systém už pak také není závislý na dostupnosti cílových komponent.
Zpracování souborů však má omezené možnosti a pro ODS opět není příliš vhodné,
zejména s ohledem na rychlost aktualizace dat.
lPřenos zpráv: Při vzniku události předá provozní systém zprávu se všemi
atributy obchodní události messagingovému systému. Ten zprávu doručí všem
cílovým systémům. Může také zajistit validaci, filtrování, konverzi formátů,
obohacení zprávy o data z jiných systémů, případně vykonání složitějšího
integračního workflow. Přenos zpráv je vhodný pro jednotlivé transakce, ale
není optimální pro dávkové zpracování. Používá se zejména ve větších firmách.

Závěr
CIF přináší do informačního prostředí specializaci jednotlivých komponent.
Umožňuje tak firmě efektivně získat všechny nutné vstupy pro definici platné a
účinné strategie. CIF nabízí efektivitu a zkrácení doby potřebné k uvedení
produktu na trh, a to jsou kritéria, která dnes rozhodují. Při budování
architektury podle CIF je nutné mít na paměti, že univerzální řešení
neexistují. Vytvoření každé komponenty a její údržba něco stojí a vždy je nutno
posoudit přínosy a cenu konkrétního řešení. V CIF také hrají velmi významnou
roli metadata, rozsah jednotlivých komponent, vhodné pořadí jejich implementace
a možné synergie. To je ale téma na samostatný článek.
Autorka pracuje ve společnosti Cleverlance na pozici Solution Architect.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.