Lerántjuk a leplet a szoftver architektről

April 21, 2021

Mi is az architekt szerepe egy vállalatban? 

A szoftveriparban jól ismert definíciója van a szoftver architektúrának, de nincs pontos meghatározása annak, amit a kapcsolódó munka magában foglal - ez cégenként nagy eltérésekhez vezet. Noha számos cikk leírta már, hogy mi a szoftver architekt szerepe, most azt is bemutatjuk, mi nem az. Erre azért van szükség, mert gyakran látunk átfedéseket más szerepkörökkel, mint például a fejlesztési menedzserrel, a fejlesztővel vagy a műszaki vezetővel, ami nemegyszer hajmeresztő félreértéseket szül. Egy szereptévesztett architekt ráadásul fontos szempontokat hagyhat figyelmen kívül. 

A modern szoftverfejlesztés során széleskörű ismeretekre, erőfeszítésre és szakértelemre van szükség egy időtálló, megbízható termék létrehozásához. Olyanhoz, amelyet az ügyfelek szívesen használnak. Ebbe beletartozik a technológia, a folyamatok és az üzleti területek ismerete is. Ehhez szükség van generalistákra, akik megértik a különféle üzleti és technológiai szempontokat, másrészről pedig specialistákra is, akik meg tudják becsülni egy komplex fejlesztési munka időigényét és minőségét. Nem lehet mindenki mindenben szakértő. Az architektúra ezek közül egy kiemelt terület, amely külön kompetenciát igényel. 

Akkor ki is az a szoftver-architekt? Létezik egy túlzottan leegyszerűsített definíció rá, amely szerint, „aki dokumentál”, és aki a fejlesztő mellett „kódol”. Ó, nem, nem, nem! Tegyük tisztába ezt a dolgot. 

Kezdjük az elején - mi manapság a szoftver architektúra? 

„A szoftver architektúra a fontos dolgokról szól... bármi is legyen az.” - Ralph Johnson 

A szoftverarchitektúrát nehéz tömören meghatározni, mert folyamatosan változó terület: ahogy az új technológiák egyre gyorsabban válnak elérhetővé, úgy az architektúrák is gyakorlatilag évente változnak. A felhő-alapú megoldások csak tovább bonyolítják a platformok, nyelvek, keretrendszerek, programkönyvtárak, paradigmák és eszközök már amúgy is nyomasztó mennyiségű kombinációját, amellyel a kihívás exponenciálisan növekszik. A szoftver architekt célja ebben az összefüggésben, hogy feltérképezze, mi áll a fentiekből rendelkezésre, és mindez hogyan illeszkedik a cég ökoszisztémájába. Elemzi a lehetőségeket, és kizárja a kevésbé előnyös opciókat, így szűkítve a fókuszt. Bizonyos szempontból a felhő alapú megoldások megkönnyítették a munkájukat azáltal, hogy menedzselt erőforrásokat nyújtanak, amelyek integrálják a fontos koncepciókat. A kihívás azonban megint csak az, hogy tudjuk, melyik megoldás érhető el a cég számára, az mennyire érett, mik az előnyei, merre tart, és mennyire illeszkedik hosszabb távon az adott (üzleti) probléma területéhez. A ‘vendor lock-in’ ősrégi problémáját itt is figyelembe kell venni, bár teljesen új kontextusban. 

Ki valójában a szoftver-architekt és ki nem az?
Gyakorlati tapasztalatok 

  • A szoftverfejlesztő és az architekt közötti különbség sok mindenki számára homályos. A szoftver architekt fontos szerepet játszik a szoftverfejlesztés életciklusának (Software development life cycle - SDLC) korai szakaszában, és - ideális esetben - nagyon aktív a végrehajtás és a szállítás szakaszában is. Kritikus kapcsolattartó szerepet tölt be az üzleti és a technikai csapatok között, segíti őket a közös célok elérésében, miközben számításba veszi az adott korlátokat (költségvetés, idő, infrastruktúra, stb.) is.
  • Az architekt egy szerep, nem feltétlenül rang. Nagyfokú technikai tapasztalatot és szakértelmet igényel, amelyhez erős ‘soft’ készségek kell, hogy társuljanak, úgy, mint befolyásolás, részvétel és vezetési képesség a legkülönfélébb technikai és funkcionális területeken.
  • Az architekt nem egy ‘szuper-szenior’ fejlesztő. Mégis gyakran használják egyfajta rangként a fejlesztői hierarchia csúcsán. Ez nem egészen a megfelelő módja az architekt pozicionálásának; sokkal inkább egy tangenciális munkakör, amely alapvetően különálló, kibővített készségkészletet igényel a szenior fejlesztői készségeken felül.
  • Ahogy nem minden fejlesztő alkalmas fejlesztési vezetőnek, ugyanúgy nem minden fejlesztőből lesz jó architekt. Sokszor az adott technológiát vagy keretrendszert legjobban ismerő csapattagot nevezik ki architektnek. Egy tehetséges fejlesztő architektté való előléptetése azonban elégedetlenséget is szülhet, amely végül további változtatást és a karrier célokhoz való jobb igazodást kényszeríthet ki a menedzsmentből. Az architekt egy önálló szakterület, amit karrierváltásként kell felfogni.
  • Ha egy fejlesztőből architekt lesz, valószínűleg meg kell változtatnia az addigi ismeretszerzési gyakorlatát, és fel kell adnia a nehezen megszerzett mély technikai szemléletét. Az architektnek széles körű műszaki ismeretekre van szüksége a döntések támogatásához. Ez a sokrétűség a különféle lehetőségek megértésében rejlik, amellyel ki tudják választani a problémához és az adottságokhoz legjobban illeszkedő eszközt, nyelvet vagy módszertant. Egy architektnél sokkal előnyösebb, ha tudja, hogy egy adott problémára öt megoldás létezik, mint hogy egy megoldás szakértője legyen!

1. ábra: Az architekt tudáspiramis. Minél vastagabb a középső rész, annál szélesebb az architekt technikai látóköre.


 

 

  • Az architekt feladata az iránymutatás, nem pedig az utasítgatás vagy követelőzés.
  • Az architektnek menedzseri és vezetői készségekkel is rendelkeznie kell, hogy sikeresen el tudja látni a feladatát.
  • Egyes szervezeteknél az architekt egyben menedzser is. Ez rendben is van, ha abban a szervezetben ez a struktúra jól működik, és igazodik az egyén karriercéljaihoz. Mégsem biztos, hogy ez a legjobb ötlet, mert egy menedzser-architekt eltávolodhat a részletes megoldásoktól. Ha nem követi a gyors ütemű technológiai változásokat, néhány év alatt a technikai tudása elavulttá válik. Mielőtt még felocsúdna, a kritikus architektúrákkal kapcsolatos döntéseket már át is adták egy másik szenior csapattagnak. Ez sem feltétlenül baj, ha az adott csapatnál ez jól működik, de fel kell ismerni, hogy a szerepek megosztása több kolléga között valószínűleg hatékonysági problémákhoz fog vezetni. Fontos, hogy a termék életciklusa során lehetőleg ne változzanak a szerepek túl sűrűn.
2. ábra: A szoftver architekt kompetenciái

 

Az architekt NEM műszaki vezető 

Az architekt nem tévesztendő össze a műszaki vezetővel (Technical Lead). Talán a legkézenfekvőbb különbség közöttük, hogy a műszaki vezető a fejlesztői csapat javításán fáradozik, az architekt pedig a terméket akarja jobbá tenni. Az alábbi táblázat a főbb különbségeket foglalja össze: 

  

  • A fejlesztői csapatnak a fenti szempontokat alapul véve kell kifejlesztenie a terméket, de a feladatok meghatározása, az iránymutatás, a kommunikáció, a módszertanok és a végrehajtás felelőssége a fenti vezetőké.
  • Sok kisebb csapatban az architekt és a műszaki vezető szerepét egy személy tölti be. Nagy vagy összetett projekteken viszont több architekt is dolgozhat egy vezető architekt irányítása alatt.

Az architekt és az agilis módszertan

A szoftver architektnek felelősséget kell vállalnia a kód megírásáért és ellenőrzéséért is. Ez különösen fontos az agilis és iteratív módszertanok esetében, ahol a korai architektúrát csak informálisan vagy prototípus jelleggel tervezik meg, és a végső architektúra a termék fejlesztése során, a részletes követelmények specifikálása után áll össze. Az architekt részvétele nélkül nem valósulhat meg az architektúra-terv alapján történő fejlesztés, ami növeli a projekt kockázatát, azzal a további buktatóval, hogy az architekt sem kapja meg a visszajelzést arról, hogy tervei a gyakorlatban is működnek-e. A részvétel segíti az architekteket a realitások talaján tartani, és eltávolítani az idealizált diagrammoktól és folyamatábráktól. Az architekt meghatározza az irányt, és a csapatot a - sokszor mozgó - cél felé tereli.

Architekt típusok 

  • Enterprise Architekt - absztrakt, vállalati-szintű összekötő kapocs projektek és szervezeti egységek között
  • Rendszerarchitekt - a megoldásokra összpontosít, részletes (kevésbé absztrakt) interakciókkal több csapat / projekt között
  • Solution / Szoftver architekt - egyetlen szoftverprojektre összpontosít, különös tekintettel a komponensek és programkönyvtárak újrahasznosíthatóságára, karbantarthatóságára, teljesítményére, skálázhatóságára, tesztelhetőségére, biztonságára, stb.
  • Információs Architekt - az adatok és információk rendszeren belüli, és alkalmazások közötti áramlására összpontosít; kidolgozza az adattérképet (data map), amely meghatározza az adatok tárolásának, felhasználásának és értelmezésének módját.
  • Üzleti / funkcionális architekt
  • Infrastruktúra architekt, stb. 

   

3. ábra: A technikai mélység és “szélesség” követelménye szerepek szerint

 

Minden architekt típusnak más a látóköre, és a szerepe is változhat a projekt igényeitől függően. A látásmódok közötti különbségek azért is fontosak, mert egy esetleges szerepváltás a későbbiekben kommunikációs problémákhoz vezethet. 

A különböző architekt típusok között nem érdemes karrierutat, rangsort vagy alá-fölérendeltségi viszonyt keresni. Ezek persze létezhetnek és léteznek is, de függetlenek az architektek munkakörétől: mind hasonlóak, hasonló készségeket igényelnek, de eltérő üzleti perspektívából közelítik a problémákat.

Az architekt felelőssége 

Az architekt felelőssége a teljes rendszer integritása és az üzleti célok megvalósítása a kockázatok csökkentése mellett. Idejekorán meg kell határoznia a főbb irányokat, amelyeket később már nehéz és drága lenne változtatni, és biztosítania kell, hogy a felhasználói igények is kielégítésre kerüljenek. Az architektnek holisztikus szemléletre van szüksége: egyrészről látnia kell az összképet és a teljes szoftver rendszer működését, másrészről a megvalósítás mélyreható részleteit is értenie kell (zoom-in / zoom-out képesség).

Az architekt tipikus feladatai: 

  • Meghatározza az architektúrát (rendszer „tervrajzot”) a problémakörhöz illeszkedő, bevált szoftvetervezési gyakorlatok felhasználásával.
  • Kiválasztja a technológiát - Óvakodjon a technológiai „hype-októl”, ha azok nem illeszkednek a probléma térhez vagy a csapat képességeihez.
  • Leszűkíti a fejlesztés rendelkezésére álló lehetőségeket az alkalmazásfejlesztési szabvány, illetve a fejlesztéshez szükséges eszközök és keretrendszerek kiválasztásával. Bizonyos esetekben ezeket a döntéseket a vállalati szabványok befolyásolják. (Gyakran viszont nem, ami viszont más kihívásokkal jár…)
  • Pragmatikus a döntéseiben, de törekszik arra is, hogy naprakész legyen a modern technológiákkal kapcsolatban, hogy elkerülje az úgynevezett „Frozen Caveman” effektust.
  • Átlátja a csapat képességeit és készségeit, és igazodik hozzájuk a legjobb eredmény elérése érdekében.
  • Közli a választott koncepciót a fejlesztői csapattal, és iránymutatást ad a fejlesztéshez.
  • Kommunikálja a választott megoldást a menedzsment felé és igazodik az esetlegesen változó követelményekhez.
  • Biztosítja a teljes megoldás költségoldali megvalósíthatóságát HR, eszközök, licencelés és infrastruktúra terén egyaránt.
  • Figyelembe veszi a megoldás kritikus biztonsági szempontjait.
  • Menedzseli a nem funkcionális követelményeket, és ellenőrzi/megköveteli azok teljesülését a rendszer különböző fejlődési szakaszaiban. Dokumentálja és kommunikálja a technikai választásokat és a kapcsolódó kompromisszumos döntéseket, például Architektúra Döntési Jegyzőkönyv (Architecture Decision Record) vezetésével.
  • Figyelemmel kíséri a tervezést és a kommunikációt / dokumentációt, hogy folyamatosan javítsa a problématérhez való illeszkedésüket.
  • Segít leküzdeni a fejlesztéssel kapcsolatos akadályokat.
  • Folyamatosan értékeli az architektúrát, és együttműködik a kapcsolódó területekkel.
  • Felismeri a szervezetben vagy az alkalmazáson belül történő lehetséges újrafelhasználhatóságot. Ehhez értelemszerűen ismernie kell a szervezet egyéb alkalmazásait, a rendszer tágabb környezetét és annak komponenseit.
  • Definiálja a rendszerösszetevők közötti kapcsolatokat és függőségeket; kezeli a külső rendszerintegrációkat, és meghatározza az alkalmazások közötti korlátozott kontextust.
  • Felosztja az összetett alkalmazásokat kisebb, könnyebben kezelhető modulokra.
  • Felügyeli a hosztolt környezeteket (ez a pont máig vita tárgya az architekt, a cloud és a DevOps csapatok között).

A csapatban mindenki felelős a műszaki dokumentáció készítésért. Ezen felül az architekt és/vagy a műszaki vezető felelős a sztenderdek felállításáért illetve a termék továbbfejlesztését és támogatását segítő dokumentáció előállításáért.

A rendszertervet és az architektúrát gyakran nehéz megkülönböztetni. Simon Brown K4-es Modellje a tervet és az architektúrát Kontextusra, Konténerre, Komponensre és Kódra bontja, de ez még jobban elmossa a határvonalat, mivel a kódolás nyilvánvalóan nem csak architekturális feladat. Jó ökölszabály, hogy ezek rendszerre gyakorolt ​​hatását kell alapul venni a megkülönböztetéshez, mind a rövid, mind a hosszú távú termékcélok és követelmények szempontjából. Egy azonban biztos: az architekt felelős azért, hogy minden tervmódosítás megfeleljen az architektúra definíciónak, és hogy a végcél mindenki számára világos legyen. 

Konklúzió

Egy jól működő architektúra megvalósításához az architektnek a teljes fejlesztési életciklus alatt kapcsolatban kell maradnia a fejlesztő csapattal. Ez a részvétel és elkötelezettség nagyban segíti az architektúráról való gyors visszacsatolást. Ráadásul, ez további lehetőségeket nyújt az architekt számára az architektúravízió kommunikálására és a technikai iránymutatásra. Bár az architekt tud kódolni is, nem szabad szenior fejlesztőként tekinteni rá. A rosszul értelmezett architekti szerep káros is lehet a csapat számára. Az sem szerencsés, ha fejlesztési vezetőként funkcionál, és az sem, ha a fejlesztőcsapat kompetencia körén kívül eső döntéseket hagy meghozni a csapatnak. A lényeg az “elefántcsonttorony” effektus elkerülése, amikor is az architekt a projekt elején kinyilatkoztatja a választott architektúrát, majd soha többé nem látják. Az architektnek jobb módszerei is vannak elkötelezettsége demonstrálására, ilyen például a páros fejlesztői munka vagy a szakmai véleményezés. Folyamatosan együtt kell működni mind a fejlesztő, mind a megoldást szállító csapattal az architekturális problémák mielőbbi azonosítása és orvoslása érdekében, hogy egy időtálló és sikeres végtermékünk legyen.

Hatházi Szilvia
HR Consultant/Social Media Manager