Adattárházas projektek menedzsmentje: Kihívások és Legjobb Gyakorlatok I.

A hagyományos projektmenedzsment módszertanokat követő projektvezető számára hatalmas kihívást jelenthet már egy átlagos komplexitású adattárházas projekt is.

Jelen cikkünkben néhány olyan szempontot veszünk górcső alá, amelyek értelmezése, alkalmazása eltér a hagyományos- és a DWH-rendszerek projektmenedzsmentjében.

Egy DWH-s anomália: Sikeres projekt az, ami nem ér véget

Egy generalista projektvezető általában ahhoz szokott, hogy az igényeket az előkészítési fázisban kell összegyűjteni, azokat részletezni, az üzleti vonatkozásokat átbeszélni, IT specifikációt készíteni, végül a fejlesztés és tesztelés után a termék előáll.

Az adattárházas projektek egyik legfőbb jellemzője azonban az, hogy sokszor az üzleti igény kellően mély részletezése társrendszeri adatok hiányában, vagy társrendszeri fejlesztések hiányában nem áll rendelkezésre. Tudjuk ugyanakkor, hogy ezek valamilyen szintű tervezése (ETL folyamat, adatmodellezés, DW szintű letárolás, DM szintű logikák specifikálása) elengedhetetlen; ráadásul az adatok üzleti folyamatokba való becsatornázása további adatigényekkel járhat, melyeket még a társrendszerektől is meg kell rendelnünk.

A szállítóval való közös berendezkedés is eltérhet más rendszereknél tapasztaltaktól. Például egy CRM-rendszer új moduljának fejlesztéséhez készülő követelmény specifikáció viszonylag jól definiálható, így az implementáció is elkészülhet olyan formában, ami akár évekig komolyabb (koncepcionális) módosítás nélkül használható.

Ezzel szemben, amikor egy adattárházba egy új adatpiacot vezetünk be, egy-egy adatkör bekötése gyakran további adatkörök és társrendszerek adattárházba való becsatornázását teszik szükségessé. A szállítók ilyen környezetben való, projektalapú (fixáras) alkalmazása gyakran csak a tulajdonosi szemléletük elvesztése mellett kivitelezhető, ezért kevésbé jelent hosszú távon jól működő megoldást. Sokkal előnyösebb az olyan stratégiai partnerség kialakítása, ahol a szállító (még ha a forráskód jogi értelemben nincs is a tulajdonában) gondos gazdaként tud fejlesztéseket implementálni, adatköröket gondozni a szakmai szkóp lazá(bba)n tartása mellett.

Menedzsment szintű pozícionálás

Sok esetben az adattárházas fejlesztések vezetői szinten való pozicionálása is nehézségbe ütközik, mivel egy egyszerű, adatpiac szintű tábla előállítása és töltése, szélsőséges esetben akár emberhónapokat is igénybe vehet – ami mondjuk 10 db mező esetén eléggé lesújtó tapasztalás.

Aki már foglalkozott banki környezetben adatbányászok által definiált termékhasználati vagy ügyfél-viselkedési metrikák szervezésével és fejlesztésével, könnyen beláthatja, hogy egy mozgó változós, illetve üzleti felhasználók által paraméterezhető, lineáris regresszión alapuló termékhasználati valószínűség körültekintő specifikálása időigényes feladat. Szélsőséges esetben ez akár heteket is igénybe vehet, nem beszélve a fejlesztésről és a változók társrendszerekből történő kinyeréséről.

„Garbage in, Garbage out”, az adatminőség jelentősége

Létezik egy adattárházas axióma: a DWH ereje az egyszerűségében és a robusztusságában rejlik. Ugyanakkor nagymértékben a társrendszerektől függ, hiszen a kapott adatok pontosságára, struktúrájára és időbeli rendelkezésre állására is nagyon érzékeny. Ha ezek a rendszerek nem megfelelő integritás mellett működnek, vagy az általuk küldött adat nem tekinthető megbízhatónak, az alapjaiban határozza meg adattárházunk menedzsment szintű megítélését.

„Garbage in, Garbage out” (GIGO) hallhatjuk angol nyelvű DWH-s körökben, ami az adattárházba becsatornázott rossz minőségű adatokból levont téves üzleti következtetésekre (is) utal.

Vezetőként igyekeznünk kell lavírozni a megrendelői terület és az adott társrendszer között, amikor kétes megbízhatóságú adatokat kell az adattárházba becsatornáznunk. Fontos szempont, hogy az adattárházba való betöltés és felhasználás jól specifikált legyen, ahol alapvető üzleti szabályok, értékkészletek, dimenzió adatok is kellő mélységben és jó minőségben specifikálva legyenek, a társrendszer oldali szervezők által jóváhagyott módon. A megbízható DM-szintű felhasználás csak így valósulhat meg.

Fontos szempont, hogy míg egy harmadik szolgáltató adatainak (Opten, Cégtár, vagy Belügyminisztériumi adatok) adatminőségére nem, vagy csak nagyon korlátozottan lehetünk ráhatással a DW-be való becsatornázáskor, addig adattárházas vezetőként igenis fenntarthatjuk az igényt a becsatornázni vágyott belső adatkörök minőségének és kontextusának megismerésére. Ha mi nem tudjuk, hogy milyen adatvagyon felett rendelkezünk, az üzleti területektől sem várhatjuk el ezt.

A valóságban sokszor a DWH-t felhasználó területek egy-egy adatkörre fókuszálnak (pl. kártyaadatok, cégháló, ügyféltörzs, viselkedési-, vagy termékhasználati adatok, stb.), ahol már rendelkeznek valamilyen szintű információval a társrendszeri adattárolási sajátosságokat illetően, vagy ezekre már támaszkodnak is az üzleti folyamataikban.

Adattárházas vezetőként célunk, hogy az adatkiszolgálás központosítottan, megfelelő adatminőséggel, az adattárházat nem megkerülve történjen.

Batch folyamatok szervezése

Fontos előre definiálni a szervezői munka részeként, hogy milyen gyakorisággal állnak elő a társrendszeri adatok, milyen ütemezéssel és határidővel kaphatja meg azokat az adattárház, illetve milyen más adatkörök lehetnek még szükségesek, amivel egy adatpiac szintű riport előállítható.

Fájltranszfer alapú kommunikáció esetén a transzfer területen érkeztetett fájlok kezelését jellemzően különféle célszkriptek végzik. Az adatok Stage, DW, majd DM szintre történő áttöltéséért különböző batch folyamatok felelősek.

Utóbbiak általában ütemezett job-ok által futtatott betöltő eljárások, melyek lefutását úgy szervezik, hogy az adatok a lehető leghamarabb bekerüljenek az adattárházba a függőségek figyelembevétele mellett; mindezt automatizáltan, minimális üzemeltetési pluszráfordítás mellett.

A fentiek menedzselésére szolgáló alkalmazás a PWM, mely jelentősen képes rövidíteni a Batch folyamatok átfutási idejét. A rendszerbe épített öntanuló algoritmusok révén csökkenteni lehet a DWH-s szerverek erőforrás-felhasználását, illetve a hibakezelésre fordított időt.

Az önvizsgálat helye, DWH adatkorrekciók

Azon szervezeteknél, ahol nincs kellően jó minőségű adatvagyon és mégis az adattárház bevezetése mellett döntenek, könnyen alakulhat ki olyan felállás, ahol érdemi data governance stratégia hiányában csak az infrastruktúra és a szakértők állnak rendelkezésre, az adatokat senki sem tekinti sajátjának. Ilyen esetekben a menedzsment elköteleződése hosszú távon nehezen fenntartható, ami könnyen az adattárházas terület eróziójához vezethet.

Amennyiben kénytelenek vagyunk adattárházunkba kétes minőségű adatokat is betölteni, úgy valószínűleg meg fog jelenni a korrekciózás igénye. Az igények komplexitásától, mennyiségétől függően ilyenkor érdemes időnként önvizsgálatot tartanunk:

• A DWH szervező biztosan kellő mélységben megismerte az adattárházba becsatornázandó adatok körét?
• Kellően meggyőződtünk annak adattisztaságáról?
• Kellően őszintén kommunikáltak a társrendszer oldali rendszerszervezők, vezetők az adatok felhasználhatóságáról?
• Létezik bármilyen olyan körülmény, amiről nem tudunk?

A kérdés nem fogalmazható meg teljesen általánosan. A lényeg, hogy valami félrecsúszott, és ez nem válik elfogadhatóvá attól, hogy gyakran előfordul.

Az adatkorrekciók, illetve üzleti paraméterezések is kizárólag auditált módon, historizálva történhetnek. Ebben tud segíteni a hazai bank- és biztosítási szektorban már ismert CLARA alkalmazás, mely költséghatékonyan és gyorsan implementálható adattárházas környezetben.

Ettől függetlenül érdemes lehet a lehető legkorábban, már forrásoldalon végrehajtani a korrekciókat, betartva azt az általános irányelvet, hogy mindig az adatgazda felelőssége az adatok megfelelő minőségben való tárolása.

Ilyen értelemben az adattárház a DW szinten tárolt adatok tekintetében sohasem lesz adatgazda, ugyanakkor az ezekből származtatott DM szintű adatok vonatkozásában már igen.

Ezektől függetlenül előfordulhatnak olyan esetek, amikor kénytelenek vagyunk forrásoldali, adatminőséggel kapcsolatos hibákat adattárház oldalon korrigálni, még ha data governance szempontból nem is ez a legtisztább megközelítés.