Az első részben nem tudtam megmondani, melyik Angular-verziót használjuk, a másodikban pedig azt próbáltam megmutatni, hogy az architekt értéke nem a fejből felmondott verziószámokban, hanem a visszafordíthatóbbá tett döntésekben van.
Maradt azonban egy kellemetlen kérdés: honnan tudom, melyik döntést kell könnyebben változtathatóvá tenni, ha egyre ritkábban találkozom azzal a rendszerrel, amelyről döntök?
Sokáig azt hittem, az architekt szakmai fejlődésének természetes iránya a távolodás: kevesebb kód és több rendszer, kevesebb kódfelülvizsgálat és több stratégia, kevesebb idő a fejlesztőkkel és több egyeztetés azokkal, akik egész portfóliókról döntenek; felmentem hát a lifttel, a magasabb emeletekről pedig valóban nagyobb területet lehetett belátni.
A baj nem az volt, hogy felmentem, hanem az, hogy egy idő után már nem indultam vissza lefelé.
Mire való az Architect Elevator?
Gregor Hohpe Architect Elevator metaforájában a nagy szervezet egy sokemeletes épület, amelynek legalján a gépház található, ahol a szoftver készül és fut, legfelül pedig a penthouse, ahol a stratégiáról, a pénzről és a szervezeti irányról döntenek. A két szint között gyakran annyi vezetői és szervezeti réteg húzódik, hogy mire egy üzenet célba ér, már alig hasonlít arra, ami elindult.
Az architekt feladata ezért nem az, hogy valamelyik emeleten berendezze az irodáját, hanem az, hogy járassa a liftet: felfelé elvigye a technikai döntések valódi árát, lefelé pedig olyan korlátokra és lehetőségekre fordítsa le a stratégiát, amelyekkel a csapat dolgozni tud.
Az emeletek közötti mozgás tehát nem státuszjelkép, hanem maga a munka.
Miért olyan könnyű fent maradni?
A felsőbb szinteken minden nagyobbnak látszik, hiszen egy platformstratégia több csapatot érint, mint egy hibakeresés, egy technológiai irányelv pedig hosszabb időre szól, mint egy kódfelülvizsgálat; a naptár hamar megtelik döntési fórumokkal, ütemterv-egyeztetésekkel és vezetői prezentációkkal, miközben a gépházba tett látogatás egyre nehezebben indokolható időtöltésnek tűnik.
Ekkor az olvasás könnyen az érintkezés helyére lép: elolvasom a kiadási jegyzetet, a dokumentációt, a migrációs útmutatót és a csapat státuszjelentését, vagyis információból nincs hiány, mégis eltűnik belőle valami, mégpedig a súrlódás.
A dokumentáció megmutatja, hogyan kellene működnie egy migrációnak, de azt a három belső csomagot már nem, amelyet senki nem mer frissíteni; a műszerfal jelzi, hogy a telepítés sikeres volt, azt azonban nem mondja el, hogy előtte valaki kézzel javított meg egy konfigurációt. A státuszriport pedig zöldre festi a projektet, miközben nem látszik rajta, hogy a csapat két hete megkerüli a központi platformot, mert a szabályos út túl lassú.
Az olvasás tudást ad, az érintkezés viszont a saját rendszerünkhöz kalibrálja ezt a tudást.
Először nem a szókincs kopik meg
A gépháztól elszakadt architekt még sokáig meggyőzően beszél, hiszen ismeri a mintákat, a szakkifejezéseket és a megfelelő ábrákat; nem a szókincse avul el először, hanem az arányérzéke.
Továbbra is helyesen mondja, hogy az aszinkron kommunikáció csökkenti a szolgáltatások közötti időbeli csatolást, csak azt nem érzi, mennyibe kerül éppen ennél a csapatnál az események nyomkövetése, a hibás üzenetek kezelése és az átmenetileg eltérő állapotok megértése. Ugyanilyen helyesen beszél a szabványos platform előnyeiről, de már nem látja, hogy a fejlesztőknek öt napig kell várniuk egy új környezetre.
Az elv nem lett hamis, csupán a helyi ára változott meg.
Hohpe szerint az architekturális döntéseket közvetlen és rövid visszacsatolással kell ellenőrizni, ennek egyik módja pedig az, ha az architekt maga is felelősséget vállal a szállításért. Az általa bemutatott ArchOps-gyakorlatban az architektek részt vesznek az általuk épített platformok ügyeleti munkájában, így a döntés nem áll meg a jóváhagyott diagramnál, mert előbb-utóbb visszajelez róla az éles rendszer.
Nem a commitok száma a megoldás
Ebből könnyű volna azt a szabályt levonni, hogy minden architekt töltsön hetente két napot kódolással, csakhogy a kötelező commitszám ugyanúgy rossz mérőeszköz lenne, mint a verziószám. Lehet sok kódot írni úgy, hogy közben valaki csak a számára kényelmes részekkel találkozik, és egyetlen sor módosítása nélkül is nagyon közel lehet kerülni a rendszer valóságához.
Hohpe ezért javasolja a hibakeresést az architekt visszatérésének egyik formájaként, mert ilyenkor a rendszer megmutatja, hol tér el a valóság a mentális modellünktől, ráadásul éppen a komponensek közötti kapcsolatok, időzítések és rejtett függőségek kerülnek elő — vagyis azok a részek, amelyekkel az architektúrának foglalkoznia kellene.
A gépházba több ajtó vezet:
- végig lehet követni egy változtatást a feladattól az élesítésig;
- be lehet ülni egy nehéz hibakeresésre vagy incidensértékelésre;
- át lehet nézni azt a migrációt, amelyet a csapat hónapok óta halogat;
- meg lehet kérdezni, melyik központi szabályt vagy platformot kerülik meg rendszeresen, és miért;
- időnként részt lehet venni az ügyeletben annál a rendszernél, amelynek a korlátairól döntünk.
Nem azért megyek le, hogy átvegyem a billentyűzetet a fejlesztőtől, hanem azért, hogy ismét legyenek olyan tapasztalataim, amelyek képesek megcáfolni a saját elképzeléseimet.
Mit vigyen a lift?
A mozgás önmagában még kevés, hiszen az is számít, mit viszünk magunkkal a két irányban.
Felfelé nem technológiai neveket kell szállítani, hanem következményeket: nem azt, hogy OpenTelemetryre van szükségünk, hanem azt, hogy a jelenlegi rendszerben egy több szolgáltatáson átmenő hiba feltárása órákig tart. Ugyanígy nem azt, hogy belső fejlesztői platformot akarunk, hanem azt, hogy egy új környezetre öt napot várunk, ezért lassan és nagy csomagokban adunk ki.
Lefelé sem elég szabványokat küldeni, mert a csapatnak értenie kell, melyik üzleti kockázatot csökkenti egy döntés, miért fontos éppen most, és hol van lehetőség helyi kompromisszumra; a technikai vezetés tehát nem a valóság leegyszerűsítése, hanem fordítás. Hohpe szerint az architekt készségei éppen az egymással való szorzásukban válnak értékessé, mert a technikai tudás és a kommunikáció együtt teszi érthetővé a valódi döntéseket és kompromisszumokat.
Ha a lift csak lefelé szállít szabályokat, akkor nem lift, hanem csőposta, ha pedig csak felfelé visz prezentációkat, akkor legfeljebb kilátó; az érték a két irány összekapcsolásában van.
Vissza a verziószámhoz
Az Angular verziószámára adott üres válaszom nem azért volt érdekes, mert az architektnek minden számot fejben kell tartania, hanem azért, mert akkoriban kevés friss tapasztalatot tudtam volna mellé tenni: olvastam, terveztem és egyeztettem, de ritkábban találkoztam azokkal a pontokkal, ahol a terv ellenállásba ütközik.
A megoldás nem az, hogy ezentúl bemagolom a kiadások verziószámait. Inkább rendszeresen visszamegyek oda, ahol egy rossz feltételezés még nem prezentációs probléma, hanem piros teszt, elakadt telepítés vagy hajnali riasztás.
Az előző részben azt írtam, hogy az architekt feladata felszámolni a nehezen változtatható dolgokat, ehhez azonban tudnia kell, mi nehezen változtatható valóban, és mi csak a diagramon tűnik annak, ezt a különbséget pedig nem lehet kizárólag a penthouse-ból látni.
A lift akkor hasznos, ha több emeleten is kinyílik az ajtaja, az architekt pedig nem attól jut magasabbra, hogy fent marad, hanem attól, hogy ugyanazt a rendszert több szintről képes látni — és minden út után hoz valamit vissza.
Források
- Gregor Hohpe: The Architect Elevator — Visiting the upper floors — 2017
- Gregor Hohpe: Debugging Architects — 2023
- Gregor Hohpe: Being an architect isn’t the sum of skills. It’s the product. — 2025