Élet-architektúra, 2. rész: alapelvek.

<< Előző (első) rész

Bevallom, az Élet-architektúra előző (első!) részében kicsit előreszaladtam — nagyjából a legizgalmasabb részénél csaptam bele a lecsóba, pedig a TOGAF szerint ez (mármint egy ilyen komponens katalógus) csak valahol később (Phase C, data architecture-nél) zajlik le rendesen.

Az előző rész végén is hinteltem már, most menjünk hát bele kicsit részletesebben a scope, és az alapelvek nem kevésbé izgalmas kérdésébe.

(Kis kitérő, hogy valós életből vett okot említsek ezeknek a fontosságára: amikor a minap átálltam Kolabra, nagyon gyorsan realizáltam, hogy hoppá, a chatem, nevezett Hangouts is Google, azt is weben használom, következésképpen valami Google szolgáltatásnak így is, úgy is nyitva kell lennie… Hümm-hümm, tisztán látható, hogy nem volt ez jól megalapozva, a chat is személyes adat, azzal is kezdenem kell valamit — kimondani hogy marad a Google-nél, vagy kimondani hogy implementálok egy saját Jabber servert… De egy lépést hátratéve: kimondani azt az alapelvet, ami mentén ezt, és a hasonló kérdéseket (mert biztosan lesznek még) meg tudom gyorsan, elfogulatlanul válaszolni!)

TOGAF-éknál egyébként ez a legelső (igazából nulladik) fázis (Preliminary Phase) lenne, amiben aztán vannak további dolgok is. Csak hogy teljes legyen a lista:

• szervezeti kontextus feltérképezése
• scope
• létező framework-ök, eljárások, stb. feltérképezése
• Capability Maturity target  meghatározása
• szervezeti felépítés
• architecture governace
• eszközök kiválasztása
• alapelvek meghatározása

Ez elég sok, de szerencsére egyrészt az Open Group nagylelkű szabványalkotói lehetőséget adnak a framework saját igény szerinti átszabására (tailoringolására!), tipikusan tehát lebutítására igény szerint, másrészt ez itt nem egy full blown architecture capability építés, ezért eleve megtehetem, hogy csak azt veszem át, aminek értelmét látom, mert nem sokmillió dollár a tét, és ha elrontom, bármikor újra lehet kezdeni, visszalépni, stb. Úgyhogy én önkényesen azt mondom, hogy egyelőre két dologgal foglalkozom a Preliminary Phase-ből: a scope-pal, és az alapelvekkel. A szervezeti kontextusomat és felépítésemet a háziorvosomra hagyom (bár a kontextusra biztosan pályázik a család is), a governace viszonylag egyszerű (én volnék az, kezicsókolom), az eszközökkel részleteiben egyelőre ráérek (most Google Docs-ba gyűjtöm amit gyűjtök, lehet, hogy egyszer pl. bepakolom Archi-ba), a Capability Maturity target… nos az még egy érdekes téma, aminek ezen a szinten is értelme lehet. Elképzelhető, hogy visszatérek majd rá, ha legalább az „as is” állapot fel van rendesen térképezve. Azt sejtem egyébként, hogy az alapelveimből viszonylag direkt következni fog ez is.

Na de vágjak is bele igaz?, mert megint írtam egy Androidportálnyi cikket és még csak a bevezetőnél tartok.

Scope

• Ami teljesen egyértelmű alapvetés scope-ügyben: elektronikus szolgáltatásokról, az ezek által generált adatokról beszélünk. A kocsiba vásárolt benzint nem fogom itt optimalizálni, sem pediglen a kajavásárlást. (Arra ott a háztartási kanban, amire, hú tényleg, szintén kéne egy update!)
• A cél pedig az azonosított adatok, rendszerek optimalizálása (az alapelvek mentén). (Ide jöhetne egy fasza mantra is. Ha kitalálok egyet, beillesztem!)
• „As is” állapot feltérképezése, átfedések megállapítása, megszüntetése
• Elsődleges prioritás: személyes adatgenerátorok, korlátozott/intim közönséggel (a „saját” adatom, levelezésem, ilyesmi.)
• Másodlagos prioritás: szociálmédia, publikus szirszarok, ezek közötti kapcsolatok.
• Harmadlagos prioritás: kisegítő, pl. adatátviteli-átalakító rendszerek; nagyvállalati környezetben middleware-nek hívnánk, de ne legyünk ennyire yuppie-k.

Alapelvek

• De-cloud: a személyes (elsődleges prioritású) adataim ne legyenek felhőben.
• Multiplaftorm: a felhőkiváltó szolgáltatások legyenek felhőszerűen multiplatform elérhetőségűek (böngésző, asztali kliens, Android app, stb.)
• Usability: a kiváltó szolgáltatások legyenek annyira használhatóak/személyre szabhatóak, hogy a felhőhöz képest ne szenvedjen csorbát a munkafolyamom. Benchmark: Juli. Ha neki elég jó, akkor elég jó.
• What would the SMB do: If in doubt (hogy mi legyen egy adott megoldással), elgondolkodom, mit tenne egy cég, mondjuk egy közepes méretű vállalkozás. Erre a vállakozásra egyébként van nagyjából egy persona-m, kb. úgy képzeljük el, hogy valamelyest többet törődik az adatával, mint egy mai startup, de persze szem előtt tartja/mérlegeli, hogy egy adott megoldás mennyire pazarló.
• What would Mozilla do: ez egy kicsit a De-cloud elv kiterjesztése, sőt, talán felül is írja azt (ha úgy látom igen, majd jól áthúzom azt.) A lényeg: olyan szolgáltatásokat használni, amik miatt nem köpöm szembe magam. A jelenlegi világban ez sok esetben egyenértékű lesz a De-cloud-dal, sokat fogom forgatni a Mozilla Kiáltványt és a Miért Firefox OS? postot. De persze lesznek dolgok, amik maradnak felhőben, maradnak Google-nél, stb.
• És végül: az architektúra van a projektért, és nem a projekt az architektúráért. Biztosan lesznek pillanatok, amikor annyira belemerülök ebbe, hogy elkezdem ráhúzni az életemet egy tankönyvi ADM-re, remélem vagyok annyira összeszedett, hogy ezt észreveszem és teszek egy lépést hátra.

Látható, hogy ezek az elvek nem túl konkrétak, illetve nem mind. Nem feltétlen van ezzel baj, bár főleg az utolsó kettőt olvasva úgy látom hogy lesz itt még

• fejvakarás, amikor adott problémára ezeket az elveket értelmezni próbálom;
• az elvek átírása/bővítése/konkretizálása, amikor rájövök, hogy mire is gondoltam tulajdonképpen.

Nincs ezzel baj, nagy pálfordulások nem várhatók, ugyebár.

Akkor ezzel most azt állítom, hogy megvan a scope és az alapelvek draft verziója. Csiszolni fogok még rajtuk, de már lehet velük dolgozni!

Közben csöndben gyűlnek a múltkor emlegetett adat-entitások, én 60 fölött járok, hát ti? A következő részben megmutatom őket, kategorizálok is egy kicsit remélhetőleg, és akkor már látszani fog valami irány. Sail ho!