Élet-architektúra projekt, 1. rész: belevágás.

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:

  1. 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.
  2. 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.
  3. 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:

  1. 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.
  2. Szépen tegyük oda mindegyik entitás mellé hogy milyen rendszerben generáljuk az adatot, ő a master adatkomponens, logikai.
  3. É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!

Következő rész >>