Dátový Sklad verzus Dátová Skládka

Nemiesto úvodu faktovka

Štatistika nám hovorí, že 88% dátovo integračných projektov končí neúspechom – z toho 50% úplným a zvyšných 50% prekročí v priemere projektový plán asi o 170%. Vo väčšine prípadov ide o opakujúcu sa históriu a príčiny nie su technické pôvodu ako by sa dalo očakávať.

Veľké oči

V prvom kroku keď organizácia dospeje k presvedčeniu, že potrebuje dátový sklad nastane zber požiadavkou. V tomto momente potrebuje každý všetko a v maximálnom detaile, bez ohľadu na to, že by sa zamyslel nad tým, či požadovane dáta niekedy prakticky použije. Dôsledkom je neustále narastajúci rozsah projektu. Jediným riešením je prioritizácia požiadavkou – vždy ich bude viac ako sa stihne naimplementovať.

Pramatka všetkých C-diskov

Keďže „potrebujeme“ všetky obchodné údaje dať na jedno miesto, vyvstáva otázka do akých štruktúr. Akademická pôda nás zásobí dostatkom argumentov pre/proti de/normalizácií dát. Málokedy nás, ale upozorní, že okrem nadčasových problémov dátových štruktúr existujú časovo lokálne a relatívne rýchlo sa meniace obchodné problémy a dátový model musí byť dostatočne flexibilný, aby obsiahol aj zmeny, s ktorými nikto nerátal. Dátový model je nutnou, ale nie dostatočnou, podmienkou výkonnosti dátového skladu.

Dátové smetisko

Po prvom nahraní dát a vyprodukovaní prvých reportov sa často namiesto búchania šampanským ozýva pleskot dlaní o čelo – užívatelia prvý krát uvidia konsolidované dáta, respektíve stav konsolidácie dát a ich kvalitu. Dátová kvalita je Medúzou súčastného IT sveta. Všetci s ňou bojujú, ale nikto živý ju nevidel. 70% projektov dátových skladov má za následok spustenie dodatočného projektu na riadenie kvality dát [2] s celým zmenovým riadením, ktoré je nutné kvôli dodatočnosti takéhoto snaženia. Začnite s riadením dátovej kvality na začiatku projektu –ušetríte si neskoršie nemilé prekvapenia.

Otesánek

Nástrahy nekončia nasadením dátového skladu do prevádzky. Ako každý systém bude rásť a bude rásť rýchlejšie ako si myslíte pokiaľ na to nebudete pripravený. Sú dva dôvody rastu – samotný objem dát rastie; užívatelia, ktorý objavia jeho hodnotu budú chcieť do neho pridávať ďalšie a ďalšie položky. Samozrejme všetky údaje užívatelia potrebujú mať k dispozícií na veky vekov a nikdy ináč... Definícia každej entity v dátovom sklade by mala obsahovať životnosť dát v nej obsiahnutých, ktorá zodpovedá ich ekonomickej hodnote.

Skladové karty

Predstavte si ako hľadáte v IKEA stôl do kuchyne bez katalógu a v sklade police a lepenkové škatule na nich nemajú žiadne označenie alebo pri najlepšom skratkovitý popis typu „stôl tak pre troch“. Bizarná predstava? Možno by sme boli prekvapený koľko dátových skladov je presne v takomto stave. Hektický vývoj, zmena vývojárov a nevhodná voľba nástrojov majú veľmi často za následok absenciu použiteľných metadát – funkčného popisu, entít, ich spôsobu plnenia a obchodného významu. Každý projekt potrebuje štábnu kultúru. Dátový sklad ju potrebuje dvojmo. Mimochodom viete aký je rozdiel medzi metodikom vývoja a teroristom? S teroristom sa dá vyjednávať.

Pí Ár

Drvivá väčšina ľudí pohybujúcich sa v prostredí dátových skladov sú technici bez valného záujmu o marketing, natož predávanie. Nanešťastie pre nich, je nutné dátový sklad predať do vnútra organizácie, aby sa začal používať. Ako na každú novú vec sa zo začiatku budú užívatelia pozerať skepticky. Vedenie okrem toho bude poznať cenovku tohto snaženia. Preto je vhodne naplánovať prácu takým spôsobom, aby prinášala viditeľné výsledky maximálne každé tri mesiace, nájsť si komunikačný kanál a s pompou noviny oznámiť svetu. Kto nás už v dnešnom svete pochváli ak nie my sami?

---

[1] The Standish Group 2003

[2] Gartner 2003