Az architekt, aki nem szállt ki a liftből

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 felhőtlenebb a kilátás.

Nos. A baj nem az, hogy felmegyek, hanem az, hogy egy idő után elfelejtek elindulni 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 meetingekkel, ütemterv-egyeztetésekkel és vezetői prezentációkkal, miközben a bányába 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 release note-okat, 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. Mert a dashboard jelzi, hogy a telepítés sikeres volt, azt azonban nem mondja el, hogy előtte valaki kézzel javított ki egy, vagy több csomagfüggőséget, konfigot. A report pedig zöldre festi a projektet, miközben nem látszik rajta, hogy a csapat két hete megkerüli az eljárásrendet, 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. Szóval 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.

Tehát 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.

Nos…de 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 jelenségeket. Nem azt, hogy Sentry-re 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 dolgokat 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ó keresztezésükben 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 pirosan csillogó warning, elakadt CI/CD pipeline vagy egy 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 papíron 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