A modern szoftver iparnak megvannak a saját paradigmái. Van, amit átvett más hosszabb életúttal rendelkező tudományok rendszereiből és van, aminek a fejlődését indukálta azokban. A matematikával való szoros szimbiózisa nyilvánvaló, de személy szerint ugyanolyan fontosnak tartom a filozófiával való kapcsolatát. Azzal foglalkozik – függetlenül a számítógéptől – hogy hogyan gondolkodunk a világról, hogyan modellezzük azt, hogyan oldunk meg benne problémákat. A blog sorozatban olyan témákat szándékozom érinteni, amik ha nem is új paradigmák, de a jelenlegi fősodor által jellemzően nem alkalmazottak, néha el sem fogadottak.
Minden téma egy ilyen paradigmát szándékozik bemutatni egy alkalmazási példán keresztül.
Meta
A „Meta” fogalmat a továbbiakban arra a szoftverfejlesztési koncepcióra vonatkozólag használom, hogy egy probléma - illetve annak egyedi előfordulásinak ismétlődő - megoldása helyett magának a probléma megoldásának mikéntjére adjunk megoldást. Ebben a megközelítésben csak egy problémát (a „Meta” problémát) kell megoldani, és ezt a megoldást kell alkalmaztatni (további fejlesztési munka nélkül) az egyedi előfordulásokra. Az eredmény a végén egy egységes megoldáshalmaz lesz, aminek minden eleme pontosan ugyanúgy viselkedik.
A „Meta” fogalom arra a koncepcióra épül, hogyha azt állítjuk, hogy tudunk olyan pontos specifikációt írni egy probléma megoldására (akár egy ETL fejlesztés, akár dokumentáció készítés kapcsán), amit minden programozó egységesen hasonlóképpen interpretál, akkor azt a gépnek is el lehet magyarázni, azaz le lehet programozni. Hogy mikor érdemes elindulni és mennyire ezen az irányon, az esetenként egy-egy komplexebb feltárást igénylő döntés. A dokumentálás mindazonáltal az egyik olyan terület lehet, ahol érdemes e szerint eljárni.
Meta ETL dokumentáció
Az ETL (Extract Transform Load) dokumentálás területén ez azt jelentené, hogy ne egyedileg dokumentáljuk az egyes ETL-eket, hanem egy olyan megoldást építsünk, ami képes majd az ETL-eket maga dokumentálni.
A dokumentálási folyamat követelményei jellemzően egy fejlesztői dokumentumban szöveges formában kerülnek specifikálásra. Ebben jellemzően kitérnek, hogy magában az ETL kódjában milyen fejlesztői megjegyzésekkel kell ellátni a sarkalatos pontokat. Meghatározza, hogy az ETL-ről milyen eszközzel, milyen tartamú felhasználói dokumentumot kell készíteni. Az egyedi ismétlődő megoldás ebben az esetben úgy jelenik meg, hogy minden fejlesztő értelmezi a dokumentálásra vonatkozó leírást, majd alkalmazza saját munkája közben.
Azonban bármilyen alapos munkát is végeznek az egyes fejlesztők a végeredmény (a teljes dokumentációs megoldás halmaz) szempontjából, az idővel biztosan heterogén lesz. Nagy annak a kockázata, hogy a dokumentáció idővel el is fog térni az ETL-ben leprogramozott tényleges adatfolyam működési logikájától.
Két okból is folyamatos nyomás alatt fog állni az esetleg ideglenesen elért jó állapot:
- Egyrészt az ETL-ek nem statikusak, azokba a hibajavítások mellett várhatóan folyamatosan új képességek kerülhetnek beépítésre.
- Másrészt a dokumentálás követelményei is megváltozhatnak, és ez az összes meglévő ETL megoldás dokumentumát egyszerre teheti avulttá.
A felhasználói oldalon – legyen az másik fejlesztő, vagy üzleti elemző – ugyanakkor a dokumentáció megbízhatósága kiemelt fontosságú.
Vannak ugyan „dobozos” eszközök, amik azt ígérik, hogy jó minőségi dokumentációt tudnak szállítani az adatelemzésre kiajánlott objektumokról - az üzleti célú adatot tartalmazó táblákról, adatkockákról, dimenziókról. Ezen megoldásoknak nagy hátránya, hogy jellemzően csak valamilyen katalógusszerű leírást képesek generálni. Az ETL belső megoldásai ezekbe nem látnak bele, csak a végállapotot tudják felületesen (tábla és oszlop felsorolás szinten) prezentálni. Az ebben lévő információ jellemzően nem elegendő sem fejlesztői, sem elemzői szemmel nézve.
(Autóipari párhuzamként a kereskedői katalógus és a műszaki leírás közül az előbbit tudják produkálni)
A „Meta” fejlesztési koncepció úgy jelenhet meg ebben a problématérben, hogy a dokumentálási folyamatot kell formálisan leírni, azaz leprogramozni. Ennek a teljes adattárház megoldáson belül egy nagyon fontos résznek kell lennie.
- Biztosítja, hogy a dokumentáció azonos minőségben, egységes formában, és ami a legfontosabb: megkérdőjelezhetetlen tartalommal álljon rendelkezésre.
- Biztosítja, hogy egyrészt az ETL-ek fejlesztői a dokumentáláshoz szükséges információkat a megfelelő pontokon elhelyezzék.
- Biztosítja, hogy az ETL adattranszformáció logikája (amik a ténylegese végrehajtott SQL adatbázis műveletekben jelennek meg) is megjelenhessen a dokumentációban és az ettől a tényleges logikától ne térjen el.
- Biztosítja, hogy a megváltozott dokumentálási követelmények azonnal egységesen átvezetésre kerüljenek az összes már meglévő ETL dokumentumában.
Nagyjából három fontos eleme kell, hogy legyen egy ilyen megoldásnak:
-
A dokumentációs pontoknak formálisan meg kell jelenniük a programozási környezet részeként. A kódba beszúrt megjegyzés nem tekinthető formálisnak, a beszélt nyelv szabadsága egyben alkalmazási lehetőségeit is behatárolja. Képességei korlátozottak. A fejlesztő számára nincs kényszerítő erő, hogy azokat a megfelelő pontokon megfelelő minőségben elhelyezze. A megjegyzéseket jellemzően csak más fejlesztők érik el, az üzleti felhasználók számra a kód böngészése nem opció.
Ezen pont megköveteli, hogy az ETL-ek fejlesztése során rendelkezésre álljon valamilyen formális nyelvi eszköz. A dokumentálás megoldása így fordítási, vagy futási időben automatikusan ellenőrizhetővé tehető.
-
Csak az adatbázisban ténylegesen végrehajtott SQL tekinthető az adattranszformáció teljes értékű specifikálásának. Ennek értelmezése, megfelelő emberileg olvasható formára hozása, majd dokumentációba helyezése tudja csak biztosítani, hogy egy adat megjelenéséhez vezető út megkérdőjelezhetetlen minőségben állhasson rendelkezésre.
Ez megköveteli, hogy az ETL végrehajtása során megfelelő minőségben naplózza mit, hogyan hajtott végre. A végrehajtási log-ok feldolgozását majd program végzi, fejlesztőnek ezzel feladat nincs.
-
A dokumentálási követelmények formalizálása lesz a megoldásban az az elem, ami a dokumentumot a megfelelő formában ténylegesen legyártja. A dokumentálás végső terméke több különféle helyre leszállítható, pld. belső információs portálba (Confluence, pdf), vagy adatbázisba elemezhető struktúrába. Ezek között eltérés az egységes alapok és gyártásnak köszönhetően nem lesz.
Ez megköveteli egy olyan folyamat kialakítását, ami az előbbi két pontban biztosított információkat megfelelő formákra dolgozza át.
Ezen három elem biztosítása, egy egyszeri fix ráfordítással megvalósítható. A továbbiakban „elvileg” soha többet nem kell egyedi dokumentálással külön foglalkozni. Nem kell külön folyamat sem a fejlesztés és bevezetés során, és nem kell majd az adattárház további életében a dokumentálással foglalkozni.
Csak ezt a megoldást kell menedzselni – új felhasználói igények megjelenése következtében beépítendő új képességek kapcsán.
Összeségben ezen fix költség már rövid távon is megtérül a fejlesztési, dokumentálási feladatok egyszerűsödése vagy teljes szükségtelenné válása miatt. Az adattárház felhasználói oldalán az információk minőségi elérhetősége olyan hozadék, amit egyéb megközelítéssel nehezen, vagy egyáltalán nem lehet biztosítani.
Példaképpen ezen megközelítést pályafutásom során egy Oracle EBS bevezetés kapcsán is alkalmaztam.
Egy ilyen bevezetés folyamata (nagyon leegyszerűsítve): felmérés és tervek alapján setup dokumentáció, majd annak beállítása a rendszerbe. Ez egy többször ismétlődő folyamat, ahol először valamikor a rendszerbe, valamikor a dokumentációba kerül be új információ. Jellemző, hogy három-négy alkalommal végre kell hajtani a teljes beállítást. Ez munkaigényes és sosem hibamentes. A beállítási hibák (tervezettől való eltérés) hatása valamikor csak éles üzemben derül ki és utólagos javítása jelentős munkát indukálhat.
Helyette le lett programozva a setup elvégzésének folyamata, ami egyúttal a setup dokumentációt is legyártotta. Minden változás ezen folyamat implementációját érintette. A telepítés „gombnyomásra” történt, a 100%-osan hibamentes végrehajtás garantált volt, a dokumentáció (egy komplex html site) megkérdőjelezhetetlenül azt tartalmazta, ami be lett állítva. Összeségben az éles üzembe állás az ügyfélnek és számomra is stresszmentes lett ennek köszönhetően.