Architect: önálló pozíció, vagy szerepkör?

Ha elképzelünk egy szoftverfejlesztésről szóló ábrát, és azt a feladatot kapjuk, hogy illesszük bele az ún. architekturális tervezést, akkor valószínűleg nem lesz egyszerű dolgunk. Megoszlanak ugyanis a vélemények, az egyik véglet szerint az ilyesfajta tervezés a megszokott design folyamat része, felesleges neki új nevet kitalálni, míg mások azt vallják, hogy a szoftverfejlesztés legfontosabb lépéséről van szó, melyhez csak az igazán magasan képzett fejlesztők érthetnek. Az igazság, mint mindig, most is valahol félúton keresendő.

Amikor az architect csupán kívülálló

Ha úgy tekintünk az architectekre, mintha a mindenek felett álló csodatevők lennének, akiknek külön csapatban dolgozva kell megfogalmazniuk a nagy ideákat, és fejlesztési alapelveket, amiket aztán közölhetünk az egyszerű fejlesztőkkel (akik csupán végrehajtók), akkor nagyon rossz úton járunk.
Főleg azért, mert a szoftverfejlesztés folyamatából ezáltal teljesen mást fognak látni a "bányában" dolgozó fejlesztők, és mást a fehérgalléros architectek, aminek következtében hamar felszínre tör majd néhány jellemző probléma:

• az architectek nem fogják tudni helyesen megítélni az általuk kitalált ötletek létjogosultságát, megvalósíthatóságát
• ha az implementálásban a fejlesztők kizárólag végrehajtóként vesznek részt, szinte képtelenség az architektek által megjelölt eszközök, keretrendszerek alkalmasságát objektíven értékelni
• a fentiekből fakadóan mindkét csoport jó eséllyel kezd majd egymásra mutogatni, holott csupán a kommunikáció csúszott el kettejük között

Amikor az architect elsősorban inkább fejlesztő

A másik véglet. Ez az eset akkor fordulhat elő, ha az architectek annyira szerves részét képezik a fejlesztői gárdának, hogy sem idejük, sem energiájuk nincs arra, hogy időnként eltávolodjanak a klasszikus implementációs folyamattól, és felülről, mintegy kívülállóként tekintsenek arra, amit a többi fejlesztővel közösen megalkottak.

Az egészséges egyensúly

Képzeljünk el egy olyan szervezeti struktúrát, ahol az architectek ugyan különálló, jól definiált szerepkörrel rendelkeznek, de mindeközben a fejlesztői csapat aktív tagjai.
Ezek a szakemberek nem egy "Architectet keresünk SOS!" álláshirdetésre jelentkezve kerültek a céghez, hanem a feladatra legalkalmasabb FEJLESZTŐK, akik felelősségel tartoznak az architekturális döntésekért. Ebben a modellben

• a csapat minden tagja tanulhat a másiktól,
• a rossz döntések sokkal hamarabb eszkalálódnak a felelősök felé,
• és nem elhanyagolható az sem, hogy lényegesen jobb lesz a munkamorál, mint a fenti struktúrák esetében.

Mitől lesz valaki jó architect?

Erre a kérdésre is lehetetlen egzakt választ adni, de az biztos, hogy az architekturális designhoz alapvetően inkább csak egy másfajta szemmérték, vagy ha úgy tetszik nézőpont kell, melyből az adott rendszerre tekinthetünk. Valahol itt dől el a kérdés, hiszen egy nagyobb rendszert absztrakt módon, egészben átlátni nem mindenki képes.

Forrás: Shawn Crowley, Simon Brown