A Kolab project kapcsán eszembe jutott, hogy le kell porolnom a saját életem architecture capability-jének megvalósítását célzó törekvéseimet.
Elmagyarázom. (És ha eddig nem volt világos: kőkemény geek, illetve architecture post következik.)
Adott ugye egy ember, aki idejének jelentős részét tölti a neten, ennek során különféle webes appokat használ. Ezek tipikusan egy kialakult core körül mozognak, de szintén tipikusan vannak „szatelit” webappok, amiket váltogatunk — ki többet (pl. aki félévente átáll blog.hu-ról Tumblr-re, onnan Postr-re, majd amikor az bezár, valami másra stb.), ki kevesebbet (pl. én, aki 2002 óta blogol és 2, azaz kettő platformot használt ezalatt; és egy domaint).
A probléma: a szolgáltatások jelentős része átfedésben van, mármint ami a funkcionalitást, és főleg a tárolt/átvitt adatot illeti. Az Instagramról átkerül a fotó a blogra, onnan Facebookra és Google+-ra, meg Twitterre, és kész a baj, egyrészt három helyen van meg a fotó ami architekturálisan ugye botrány, másrészt három külön like- és kommentfolyam van, ami szintén.
A probléma persze az, hogy a fenti jelenség a jelenlegi világrendből fakad: a walled garden szolgáltatásoknak nyilván pontosan az a célja, hogy minél több adatot magánál tartson, sőt, minél több adat „mastere” legyen. A Facebook nem fog Google+-nak kiadni kommentfolyamot, mert az az ő üzletüket rontja, pedig lehetne. („Minden adat metaadat” — lehetne.) A vesztes természetesen a felhasználó, nem csak az, aki létrehozza a tartalmat, hanem az is, aki fogyasztaná, de egyszerre csak egy bizonyos vetületét látja. Írtam erről a problémáról már a Miért Firefox OS? posztomban is, talán látható, hogy több aspektusból is foglalkoztat, hovatovább: zavar a jelenség.
A probléma tehát adott, viszont több síkon létezik:
- Felhőszolgáltatások esetén nem nagyon tudjuk kontrollálni, hogy mi történik. A Twitter, a Facebook, a Google+ nem fognak a kedvünkért hajlani, ha úgy döntünk, hogy fontos ott a jelenlét, el kell fogadnunk az adatduplikálás tényét, és az ezzel járó kavarodást. Maximum ki tudjuk találni, hogy kit tekintünk (mi, a felhasználó; nem a szolgáltató!) master adatforrásnak, és pl. IFTTT segítségével megoldjuk a webappok közti reshare-láncot.
- Személyes jellegű adatok esetében már (elvileg) jobb a helyzet: a levelezésünkre, naptárunkra, címjegyzékünkre tipikusan egy szolgáltatást használunk, és ideális esetben ezt a master forrást tudjuk használni több helyen is. Vannak persze kivételek, amikor pl. egy termék nem API-n, hanem fix időközönkénti importáláson kersztül éri el a címjegyzékünket (ezáltal ugye beépített lemaradással duplikálva a mastert, brr), vagy amikor POP3-mal használjuk a levelezést, amit remélem 2014-ben már senki sem csinál.
- Aztán pedig vannak a „határon mozgó” adatok: ilyennek tekintem a chatet, a blogot, személyes fotókat, jegyzeteket, stb. Ezeknél fennáll a választás lehetősége, nem is feltétlenül vagyunk egy-egy társadalmi elvárás diktálta walled gardenbe kényszerítve, mégis megvan bennük a walled garden veszély, a felhő jelenség (pl. megszűnő Catch Notes, ugye), a duplikálás veszélye — ha nem vigyázunk, összekutyulódik az egész.
Attól függetlenül (persze majd erre is kitérek), hogy adott feladatra felhő- vagy „vasalapú” szolgáltatást használunk (vagyis pl. levelezésre Gmail vagy saját szerver), és talán itt következik a posztom témamondata:
Fontos, hogy feltérképezzük az online életünket felépítő komponenseket, építőkockákat, és meghatározzuk ezek magasszintű architektúráját.
A Kolab projektben felmerült egyik probléma kapcsán jöttem rá, mennyire fontos ez: bár a levelezésem Kolabon van, a Gmailemmel (korábbi levelezés megoldás ugye) együtt jött a Hangouts, amit jelenleg Kolabon nem tudok duplikálni. Miért fordult ez elő? Mert eszembe se jutott. Miért? Mert nem voltam felkészülve a létem adatmodelljével, amikor belevágtam a projektbe! Az ember nem is látja, hogy mennyire függ egyik adata a másiktól, amíg el nem kezdené őket szétválasztani valami mentén.
Ennek kiküszöbölésére hétköznapiasan fogalmazva a következő lépcsőket kell végigjárni:
- Gondoljuk át hogy milyen fajta adat entitások fordulnak elő az életünkben (pl. „levél”, „tweet”, „fotó”, „kontakt”, stb.), írjuk le amennyire teljesen csak lehet.
- Szépen tegyük oda mindegyik entitás mellé hogy milyen rendszerben generáljuk az adatot, ő a master adatkomponens, logikai.
- Érdemes azt is feltérképezni, hogy adott masterről milyen más rendszer készít másolatot, transzformálja, vagy egyszerűen csak transzferálja.
Ha ezzel megvagyunk, kész van életünk adat entitás/komponens katalógusa, és kezdődhet az érdemi munka:
- az adatfolyamok, ha úgy tetszik: saját folyamataink tisztázása, a mastership-ek definiálása;
- a fölöslegek, duplikát masterek eltávolítása, kiküszöbölése;
- és ami miatt számomra az egész gyakorlat jelenleg fontos: annak felmérése, hogy milyen adat esetében tudok esetleg szabadabb, biztonságosabb, nyíltabb alternatívát felhasználni.
Azt hiszed ez pikk-pakk megvan? Nos, akkor vágj bele! Én legalábbis ezt fogom tenni, aztán haladok tovább: meghatározom az alapelveket, a komponens interakciókat, létrehozok mátrixokat, mely kaland végén egy jól definiált szolgáltatáskészletet fogok tudni használni mindenféle adatigényem kielégítésére. Épül-szépül a capability!