Korábbi cikkünkből láthattuk, hogy egy szigorú fejlesztési szabályzat bevezetése (ami megfelelő hangsúllyal vegyíti a megengedő és tiltó szabályokat), az „átláthatóbb architektúra alacsonyabb belépési küszöb” elvén lehetőséget biztosít a Junior fejlesztőkkel való közös munkára. 

A megengedő standardokkal rendelkező informatikai területek azonban könnyen rabjává válhatnak egy-egy szenior szakember, vagy banki terület innovációs kényszerének, ahol a személyes karrierfejlődési célok, üzleti nyomás, esetleg új technológiák által fűtve rövid távon motiváló, hosszú távon fenntarthatatlan és nehezen üzemeltethető IT a végeredmény. Nagyvállalati informatikai rendszerek könnyen eshetnek az innovációs kényszer csapdájába. Mikor érdemes elgondolkoznunk azon, hogy mi is beleestünk?

▫︎ Kizárólag senior kollégák alkalmazhatók az adott területen;

▫︎Több kivezetésre szánt, vagy kivezetés alatt álló rendszer mellett már bevezetésre kerültek az utód-rendszerek;

▫︎ Különféle DWH-ra épülő alkalmazások párhuzamos használata hasonló céllal;

▫︎ Aránytalanul sok pilot projekt;

▫︎ Innovációs értékek túlzott kommunikációja;

▫︎ Nemrég bevezetett (nagyvállalati környezetben ez akár 3-5 év) rendszerek kivezetésre kerülnek;

▫︎ Sok szállító van jelen;

▫︎ Saját folyamataink állandó megkérdőjelezése, saját IT folyamataink folyamatos módosítása;

▫︎ Data Lake gyakori alkalmazása;

▫︎ Data Vault gyakori alkalmazása.

Míg a felsorolás első elemei valószínűleg nem igényelnek magyarázatot, addig a Data Lake, vagy Data Vault igen... Data Lake koncepció „innovációs prés”-ben való alkalmazásához először meg kell értenünk a főbb adattárházas irányzatokat, illetve az ezekhez fűződő kapcsolatát, melyről a „Data Lake koncepció és a használt akkumulátor” címmel megjelenő cikkünkben írunk.

Data Vault használata speciális esetekben lehet kifizetődő, ahol megéri a betöltő eljárásaink és adatmodellünk komplexitásának jelentős emelése, ami okán a pótlólagos fejlesztéseink is észrevehetően drágulnak. Ezzel szemben, ha észszerűen és nem öncélúan alkalmaztuk a Data Vault modellezési technikákat, akkor gyorsabban futó eljárások, magasabb szinten normalizált adatok, kisebb tárhelyigény és alacsonyabb számításikapacitás-igény egyenlíthetik ki a mérleg nyelvét.  

Az IT számos területén találkozhatunk olyan üzleti domainekkel, ahol elengedhetetlen a magasfokú innováció. Azonban fontos belátnunk, hogy az adattárházak világa egy meglehetősen jól kiforrott terület.

Fontos szempont – jelen cikkben nem szerepeltett számtalan egyéb mellett – hogy a szakmai standardok olyan biztonságérzetet is adhatnak, amitől a fejlesztők fluktuációja hosszú távon csökken. Persze egy idő közbeni refaktorálás, szabályzat-újragondolás könnyen a düh fázisába lökheti a csapatot a Kübler Ross által felvázolt változási görbén, mely megközelítés jól leírja a csapattagok innovációhoz való viszonyának fázisait pszichológiai szempontból: tagadás, düh, alkudozás, depresszió, elfogadás. Azonban ekkor is törekedjünk inkább a hosszú távú jó szakmai közeg kialakítására, mintsem a fejlesztők már megszokott, de nehezen fenntartható munkakörnyezetének biztosítására. 

Adattárházas vezetőként egyik legnehezebb feladatunk lehet, hogy ne essünk az innovációs kényszer csapdájába, ugyanakkor ne is törekedjünk a status quo minden áron való fenntartására. Paradox módon napjaink vezetőinek szakmai kiteljesedését új technológiák bevezetése, vagy kevésbé megalapozott pilot projektek menedzselése jelenthetik, amikhez kapcsolódó sikerek az adott vezető nevéhez fűződnek, ellentétben az akár 5-10 éves távon jelentkező extra kockázatokkal, technikai adósságokkal, amelyek kezelésének felelősségét az időközben munkahelyet váltó kolléga utódja fogja megörökölni. 

Kihívást jelenthet az üzleti területektől jövő innovációs igények (például egy MS BI bevezetés Oracle-ös környezetben), ami adott esetben akár jelentősen befolyásolhatja az adattárházunkat övező IT infrastruktúrát és a fejlesztők, üzleti kollégák kompetenciaigényét. Ezek akár az IT – üzlet viszonylatában politikai átrendeződést, illetve nem tervezett, vagy régóta halogatott refaktorálási feladatokat is magukkal ránthatnak.

Digitális immunitás

Bár az utóbbi évtizedekben számos SDLC (Software development life cycle) megközelítést ismerhettünk meg, addig a 2000-es évek adattárházas projektjeit a vízesésmodellben történő fejlesztés jellemezte, ahol a projektfázisok (specifikáció, fejlesztés, tesztelés, élesítés) szigorú egymásutániságával és tradicionális DWH projektmenedzsment technikákkal (erről egy későbbi cikkben írunk) kényszerítették ki, hogy az adott fejlesztés az akkori minőségi elvárásoknak megfelelően előálljon. 

Ahogy az üzleti környezet egyre inkább felgyorsult, úgy az informatikai területekkel, köztük az adattárházas területekkel folytatott közös munka során ezek a minőségi elvárások módosultak. Napjaink divatos kifejezését használva: megjelent a VUCA (Volatile, Uncertain, Complex, Ambigous) konform igénykielégítés szükségessége, ahol az üzleti igények hűen tükrözik az üzleti környezetre jellemző bizonytalanságot, változékonyságot, bonyolultságot és kétértelműséget.

Ezen a ponton szükséges megismerkednünk a digitális immunitás fogalmával, ahol részben a fent részletezett üzleti elvárások módosulása, ill. részben az IT management háromszögében érzékelhető szemléletbeli eltolódások keltették életre a digitális immunitás fogalmát. 

A szoftverek digitális immunitása alatt olyan gyakorlatok és technológiák ötvözését értjük, ahol a minőségbeli elvárások a gyors megvalósítás, gyors hibajavítás, gyors alkalmazkodás irányába mutatnak, és egyre sűrűbben találkozhatunk a „minimálisan életképes termék” (MVP – minimum value product) kifejezésekkel az adattárházas pilot projekteken. [5]

A digitális immunitást elősegítő módszertan lehet az IT-Business Award elismerésében is részesülő ErgonomX módszertan, mely felhasználói felületek újragondolása révén képes versenyelőnyt biztosítani, de ide értendő egy CI/CD pipeline bevezetése is, ami kevésbé gyakori a hazai adattárházaknál. 

Valahol a hype és a valóság között…

Adattárházas vezetőként számos olyan üzlet által is használt fogalommal találkozhatunk, ami innovációs csapdába vihet minket, kényszerpályára sodródva a technikai adósság felhalmozódását illetően. Ugyanakkor fontos látnunk, hogy minden kornak megvannak a divatos tudományterületei, legyen az BI, AI, ML, DevOps, Multi-cloud, vagy Data Governance. Fontos, hogy a kifejezések mögé lássunk, akár egy-egy üzletvezérelt rendszerbevezetésnél, mivel ezen kifejezések használata könnyen válhat belépési ponttá a menedzsmenthez. Bármilyen új metódus vagy eszköz mellett is döntünk fontos, hogy ismerjük meg a mögöttes tartalmat - valahol a hype és a valóság között.

 

forrás

[1] https://www.linkedin.com/pulse/kimball-vs-inmon-redux-bill-inmon-gatic/ 

[2] https://www.proquest.com/docview/214683052?sourcetype=Scholarly%20Journals 

[3] TEN D 05 Second Quarter For Data Warehouse Project Managers, Larissa Moss

[4] https://www.pmi.org/learning/library/leveraging-new-practice-standard-project-estimating-6222 

[5] https://www.gartner.com/en/articles/what-is-a-digital-immune-system-and-why-does-it-matter