Agilis Talend

.
* Alapfeladat(-analógia):
Akarunk venni 1 vagy 2 kg/zsák lisztet. Pénztárnál a kifizetés után ott az öröm, hogy miénk a vásárolt cucc, de ott a feladat is, hogy haza kell vinni (ezt most én előre megfontolt szándékkal overheadként aposztrofálom). Nyilván több cukrot nehezebb hazavinni, pláne ha egy nyugdíjas rokonunk volt a vásárló.
De ott a lehetőség, hogy kérünk szállítást is extra-felárért. Vegyük észre, hogy az egyszerű hétköznapi példában az overhead (további) termék(vétel)be fordult/konvertálódott.

Propozició:
Minden szolgáltatásterméknek (informatikában legalábbis többnyire) van egy látványos "darabra számolható" termék-része és van egy implikált kevésbé látványos, hogy ne mondjam "láthatatlan" overhead-massza része (vö.: felosztott és felnemosztott költségek).
Informatikai szolgáltatás-termékben egy új szolgáltatás beizzítása (legrövidebb úton), azonnal szuboptimálissá tesz/tehet néhány régebbi megvalósítást és ezt a legacy-terhet aztán lehet továbbgörgetni.
Szép is lenne ha kódolt karakterszámra "skálázva" kéne fizetni, dupla kód dupla pénz. Én a magam részéről nem gondolnám, hogy a szoftver ipar skálázódása ott tartana, ahol a hardveré, a komplexitás-overhead nullához konvergálásával.
Az overhead egyfelöl tehát sosem nulla, másfelöl sokszor szeretünk elfeledkezni róla, ami problématengerek ősforrása (hogy egy "kis" képzavarral éljek).

Propozició:
Ha van overhead, akkor egyet tehetünk (ami kötelességünk is egyúttal), minimalizálni az overheadet (dinamikusan alkalmazkodva).
A lehető létező legrosszabb ám nem minden alap nélküli opció, hogy agilis megrendelő projektvezető szabadságakor "fű alatt" orvosoljuk az overheades problémákat, megyünk utána elmaradt dolgoknak, na pláne "ingyen".
Egy sokkal ígéretesebb út lehet viszont, ha korrekten, számonkérhetően, elszámolhatóan - bevezetőben említett látható(!) módon - termékké konvertáljuk.


* Axióma:
Az agilis fejlesztési módszertan (hadd hívjam innentől agilitásnak, mert sokkal rövidebb) az inkoherenssé válás - divergálós - melegágya: amennyiben minél rövidebb és benne minél hatékonyabban termékrefókuszált időre optimalizálunk (csak) amiáltal törvényszerű a rendszer-szétesés idővel lineárisan, rosszabb esetben progresszív haladvány szerint arányosan.

Miért is?
Mert a termék-leszállítás legjobb esetben is csak egy pillanatba fókuszált lokális optimum lehet, globális (teljességre nézvést tökéletességet hordozó) semmiképpen, merthogy hiszen bőven vannak egyéb optimalizációs szempontok.
A "látható" termékre fókuszálva a megrendelő csökkenteni véli a költségeit, a szállító meg "túlélésre" rendezkedik be. Én bizony azt konkludálom, hogy kizárólag a jóindulaton és a pillanatba zsúfolt szakmai képességeken múlik, az érintett rendszer jósága, szakmai kényszerítő erő a minőségi konzisztenciára egyáltalán nincs.
Azt gondolom rendszerszinten kell globális optimumra törekedni.

Analógia a lokális optimum kontextusára:
Meg lehet nyerni egy Tour de France-t doppinggal és aztán el lehet veszteni 7 db Tour-elsőséget is akár. A kulcsszó a dopping aka megengedett/korrekt eszközök. Nemcsak (korrekt) terméket kell szállítani, hanem korrekten is kell megtenni ezt: egy "doppinghoz" felemásan viszonyuló világban ("a leggyorsabb célbaérés követelménye felülírhat vagy nem írhat felül minden más szempontot").
Vagy egy másik példában 1-200 év alatt seggére lehet verni a könnyen kitermelhető kétszázmillió év alatt keletkezett fosszilis energiakincsnek, "piacgazdaság pörgetése" címszóval, aztán lehet szembesülni a nem végiggondolt overhead-következményekkel.


Axióma:
Ahogy az ETL-t, mint adatintegrációs módszertant megbukottnak tekintem, hogy ha business userek desktop-környezetben Access-szel enterprise data martot fejlesztenek, úgy az agilitást mint módszertant megbukottnak tekintem az adott projektben, ha időben haladva nő az overhead és romlik a minőség. Az első mérföldkő minőségét overhead-szintjét tartani kell tudni, csak akkor van miről érdemben beszélni.


* Overhead-tényezők vég nélkül folytatható listája, ízelítőnek (adatintegráció ETL/Talend útján)

- Rendszer-divergálás/-szétesés, inkosziztencia, névkonvenció-megbicsaklások, gányolás-szag erösődés, "esztétika-" majd minőségromlás, egyre gázabb belenyúlni korábban fejlesztett cuccokba.

- Idő lineáris múlásával progresszíven nő az overhead (kétszer annyi idő után pl.: négyszer annyi gond)

- Visszamérések többszörös üzemeltetési költségnövekedést láttatnak az agilis projektben.

- Szellemi munkát, extra költségnövelő erőforrást igényel az üzemeltetés. Ez durván hangzik, vélhetően olyan generálódott munkát takar, amit a fejlesztő nem végzett el és meglehet el kellett volna végeznie.

- Agilis fejlesztők egyre többször egyre hosszabb/komplexebb dolgokat mindig újra kitalálnak zöld kányhától, zöld mezősen (jobb híján). Nem tud a korábbi tapasztalat beépülni a fejlesztés kereteibe. allokált idő hiányában.

- Egyre több mellékhatás kódolódik a rendszerbe, okozhatja a legváratlanabb hibákat, vagy csak a hibalehetőségeket, ráadásul a teljes ETL-DB szoftverláncon.

- Az általános célú job-ok, egyre több (felesleges) specifikumot tartalmaznak

- A specifikus job-ok feleslegesen szaporodnak, generálják a (sokszor inkonzisztens) redundanciát.

PS: Érdekes lenne belegondolni, hogy egy VirtDB-nél hogy néz ki ez az overhead-lista. Így first lookra, egyfelöl a fentiek kvázi egyike sem jeletkezik, HURRÁ! Másfelöl data governance meg változás-management tudhat extra kihívásokat produkálni, ha túl sokan, túl könnyen jutnak adathoz, heterogén környezetben, a nagy adatdemokratizálódás útján. Az ETL, önmagában, önnön önminőségéből fakadóan definitive garantál bizonyos fékeket, amiknek vannak/lehetnek pozitív szempontjai is, nemcsak negatívak. Egy VirtDB vélhetően jóval kisebb kikényszerítő erővel hat egy vállalati MDM-re, mint egy ETL.


Megoldás-alternatíva:

+ Termék és termékarányos rendszerkonszolidációt kell értékesíteni, számonkérni objektív cost-benefit alapokon (nemcsak úgy l'art pour l'art).

+ Pontosan kell tudni mi legyen általános/generikus és mi specifikus egy ETL-projektben.
* Vagy mindent egy job csinál univerzális kalapácsként (túl általános)
* Vagy mindent spéci job-ok csinálnak (túl spéci)
* Kettő között van vélhetőleg az arany középút
* Egyfelöl: csak olyan legyen általános, amihez nem kell nyúlni (konfiguráláson túl). Vagy hozzányúlásnál teljes impact analizis és teszt, majd konzisztens állapotra hozás.
* Másfelöl a spéci job-okat objektumkönyvtárhoz hasonló "elemkönyvtár best practice"-szel lehet érdemes megtámogatni, hogy ha már spéci a job, csak integrálás legyen lehetőleg.

+ Agilisen NEM fejleszteni overhead-generáló és/vagy szabványkönyvtárból elérhető funkcionalitást.
* Komoly vesszőparipám idevágóan például, hogy custom-logolót semmiképpen nem szabad fejleszteni agilis projektben, ha egyszer létezik egy log4j.
* Nem gondolnám, hogy egy agilis projekt nem tud eltartani egy custom-logolót: meg lehet próbálni csak a kockázat nem tünik arányosnak várható eredménnyel.
* Nem hiszem el, hogy agilisen jobbat lehet adni egy log4j-nél, "majd mi megmutatjuk alapon".
* Egyik érv az szokott lenni, hogy kevesebb info kell, mint amit a log4j ad (ami túl sok és rapid módon nő), amire gyógyszer lehet az log-eszencia-képzés és policy-s szabályozás:
(1) kimazsolázás után minden adat szükségesen elégségesen álljon rendelkezésre
(2) majd szigorú törlés / kiarchiválás
* Másik érv szokott lenni, hogy szükséges infót meg nem tud mindig kiadni magából (pl.: table reccount forrás és céloldalon). Ugyanakkor nehezen emészthető, hogy ez miért implikáljon custom logolót.
* Én abban hiszek, hogy aggregálós eszenciaképzés után egy komplexebb view-val bármilyen ETL-operációs dashboard kiszolgálható.

+ Legyen jól felépített az agilis fejlesztés szervezetileg is
* Vagy minden fejlesztő egyenrangúan jól csinálja az overheadet érintő dolgokat (pl.: deploy, névkonvenció etc) és azért mert jó policy folytán ez egyszerű, bolondbiztosan hibamentesen elvégezhető.
* Vagy legyen a Java-ban megszokott deployer/release-maintenance-r aki a darabra elkészült termékeket, csomagokat, komponenseket, verziókat, (név)konvenciókat admin hatókörrel "kordában" tartja, mellékhatásokat feltérképez, menedzsel etc.
* Semmi sincs ingyen másképpen szólva szűznek maradva nehéz kurválkodni. Ha nincs jó fejlesztési policy ÉS nincs semmiféle agilis projektpusztulás-gátlás az egyértelműen a káoszba visz.

+ Continuos integration adaptálandó, release managementtel, megfelelően rendesen szétválasztott DEV-PROD környezetekkel.
* Egyik végletes megközelítésben, jó policy-k esetén ezt a bekezdést ki sem kell fejteni. ;)
* Másik végletes megközelítésben túl sok lokál-specifikum lehet a történetben, hogy általános célú poszt foglalkozzék vele.
Én mindenesetre most kihátrálok belőle azzal a jelszóval, hogy külön posztot érdemel. :DDDD Az igazság az egyébként, hogy egyelőre nem tudtam rendbetenni a témát magamban.

+ Technikai hibák magas szinten katalógusosan kategorizálandók legyenek ne nyers error-message legyen csak és legyen hozzá todo is.

 Örök memento hogyan ne... ;)