Sve velike kompanije, pogotovo one “stare” poput Microsofta, Oracla, IBM-a i drugih decenijama su radile po ne tako agilnim (proizvodu i klijentu prilagodljivim) metodama, nego po tzv. vodopadnom principu – principu gdje se nekada čak i godinama vršilo istraživanje, pripreme i pisanje (projektne) dokumentacije, prije nego se uopšte oformio tim koji će raditi na razvoju softvera. U tim i takvim timovima dječački snovi mnogih programera bili su da jednoga dana postanu Software Architect/Softver arhitekta.

U posljednoj deceniji sve više se promoviše jedan (za mnoge potpuno novi, inovativni) model, tzv. ravne hijerarhije (flat hierarchy) ili ravne strukture (flat structure) organizacije ne samo malog programerskog tima, nego cijele firme.

Taj novi model zastupa mišljenja i stavove da svaki pojedinac u timu treba da bude na prvom mjestu samoorganizovan (self-organized), proaktivan i da bude takav da prepoznaje sve probleme koji postoje, kao i na one koje će se eventualno naići i da ih rješava u skladu s mogućnostima. Ako nema dovoljno znanja (knowledge) ili vještina (skills), neophodno je da ih što prije (as soon as possible – asap) usvoji! To nas dovodi do najmanje četiri zaključka:
- biti član ravne hijerarhije je veoma uzbudljivo.
- biti član ravne hijerarhije znači da se nema nekog šefa koji će svaki dan, svake sedmice, tromjesečja, … govoriti kako da se radi, ali može i treba reći šta treba da se (u)radi.
- biti član ravne hijerarhije znači da je svaki pojedinac ustvari šef/menadžer sam sebi.
- biti član ravne hijerarhije znači da se svaki pojedinac mora dokazivati svaki dan.
Ako zovnemo vodoinstalatera da nam ugradi cijevi za vodu u našu novu kuću ili popravi kvar koji imamo, nećemo ga slati na dodatno obrazovanje, na razne “team buildings“, niti ćemo mu plaćati da se samo-obrazuje i samo-usavršava. Njega zapošljavamo zato što je profesionalac, stručnjak, zato što zna svoj posao. Naše je da kažemo šta želimo i damo određena ograničenja (ovdje će biti kada, ovdje tuš kabina, …), a on sam će odrediti sve ostalo u okviru budžeta kojeg smo dogovorili ili ćemo budžet možda naknadno ustanoviti jednom kada se posao završi.
Softverski zanatlija: profesionalizam, pragmatizam*, ponos (The Software Craftsman: Professionalism, Pragmatism, Pride)
Ova četiri (a sigurno je da ih se može nabrojati mnogo više – ali zaključak će biti isti) vodi nas do zaključa da biti član ravne hijerarhije je itekako stresan zadatak svakog pojedinca. U vremenima u kojima živimo, protok informacija, a time posljednično i znanja, te usvajanja vještina je mnogostruko veći nego ikada prije. Prostim rječnikom kazano, ako se nekada moglo s završenim fakultetom (bez obzira na ocjene i usvojeno znanje) postati direktor ili neki drugi rukovodeći organ (samo)upravne organizacije, danas je to apsolutno nemoguće. Nemoguće je opet iz najmanje dva razloga:
- ono što se uči na fakultetu uglavnom je već “zastarilo” i ne može se primijeniti u praksi.
- čak i ako se bilo najbolji student i usvojilo se ogromno znanje, to nikako ne znači da se može čak i na jedan dan odmoriti od učenja i usavršavanja.
a što nas opet vraća u začarani krug koji se zove: STRES.
Izuzimajući stres, barem na kratko, i vraćajući se na temu da li nam trebaju softver arhitekte, te vraćajući se na ravnu hijerarhiju i ono što pišu veliki informatički stručnjaci dolazi se do zaključka da ustvari svaki pojedini član tima, osim svega naprijed nabrojanog (ali i onoga nenabrojanog), mora biti još uz sve i softver ahitekta. Jer se od svakog člana tima očekuje da bude “sve u jednom”.
I upravo ovdje nastaju problemi koji se uočavaju širom svijeta. Mnoge kompanije “nazor” uvode ravnu hijerarhiju bez da su ispunile i osnovne, elementarne uslove da bi mogli da rade, usavršavaju se ili čak opstanu s takvom strukturom na tržištu.
Namjere softverske arhitekture
Mnogi zamišljaju softversku arhitekturu kao procese apstraktnog dizajna. Iako takve ideje mogu biti korisne, pa čak i neophodne, same ne mogu donijeti vrijednost. Drugi pak sitničare oko detalja i smatraju da bi se svime time jedan softver arhitekta trebao baviti.
Arhitektura govori o važnim stvarima. Ma šta to bilo.
Martin Fovlerova (Martin Fowler) definicija iz njegove knjige “Ko treba ahiretke?/Who Need an Architect?”
Ovo je svakako citat koji gotovo ne govori ništa i veoma je dobra osnova za pokreniti svađu. Šta arhitekta treba ili ne traba? Šta arhitekta može, a šta ne može? Šta arhitekta mora, a šta ne mora?
Međutim, ako se pogleda i jedan drugi Fovlerov citat iz iste knjige, možda se ipak dobije neko drugo značenje i možda se donekle i čak uvidi da ne može baš svako biti arhitetka – a i ne treba rekli bismo.
Mislim da je jedan od najvažnijih zadataka arhitekture ustvari uklanjanje arhitekture u pronalasku načina da se eliminiše ireverzibilni dizajn softvera.
No, neko će opet reći, kako to da je zadatak arhitekte softvera da ukloni arhitekturu? Ako bi se išlo u tumačenje Fovlerovih riječi moglo bi se reći da je to uklanjanje nepotrebnog dizajna i pomicanje iz sfere “umjetnika” u sferu “inžinjerstva”.
Prema Ajner Landreju (Einar Landre) svaki programer treba biti softver arhitekta, baš kao što spomenusmo da se silom prilika od programera to i traži u ravnoj hijerarhiji.
Razvoj softvera je proces pronalaženja/otkrivanja i učenja, a ne proces inžinjerstva i kontsrukcije.
97 Things Every Software Architect Should Know: Collective Wisdom From the Experts
Mada, uočava se da određeni fakulteti širom svijeta otvaraju odjeljenja na kojima može da se studira softverska arhitektura i time se po završetku fakulteta i primanja diplome postaje sofver arhitekta (?!). Za sada ne znamo na čemu oni baziraju takve stavove niti kako prave nastavne planove i programe (curriculum). Prema svemu onome što pišu stručnjaci širom svijeta softver arhitekta se ne može biti ako se nije dobro u programiranju – dobro u pisanju programskog koda!
Vrste arhitekata
Možda se ustvari ponajbolje može odrediti da li (nam) trebaju softver arhitekte ako ih razvrstamo u tipove.
Jedna od vrsta je svakako i ona gdje softver arhitekte sebi umisle, ili im jednostavno uprava firme dodijeli takve odluke, da su oni ti koji treba da “misle” i donose odluke, smatrajući sve ostale članove tima nedovoljno sposobnim, kompetentnim za takvo nešto. Ovakve arhitekte veoma često nameću svoje ideje i mudrost timu raznim metodama. Umjesto da budu partner i saradnik, oni su u najboljem slučaju dobroćudni diktator.

Druga vrsta su više kao iskusni programeri. Međutim, ovdje treba biti obazriv s tim šta znači iskusan. Nije isto ako neko ima 10 godina iskustva u 10 različitih projekata, tehnika i tehnologija i neko ko ima iskustvo u samo jednom timu, na samo jednom projektu, ali u trajanju od 30 godina! Arhitekta ovog tipa je više kao mentor cijelom timu. Ne donosi sam odluke, ali pomaže cijelom timu da iznađu najbolje, optimalno rješenje. Ovo po nekima dovodi do zaključka koji kaže:

Vrijednost softver aritekte je obrnuto proporcionalan broju donesenih odluka.
Fevlerov veli da mu je ova druga vrsta mnogo draža, ali da bi rado mijenjao njen naziv. Obzirom da godinama radi kao Softver Arhitekta to je mnogo puta u životu osjećao se veoma nelagodno kod donošenja odluka. Veoma često ljudi od njega očekuju da se ponaša kao prvi tip, a on bi radije da bude kao drugi tip arhitekte.
Zaključak
Ako će se u timu imati softver arhitekta drugog tipa (prema Fevleru naziva Archictus Reloadus), onda je on itekako dobrodošao. Međutim, ako će se imati tradicionalni arhitekta i to još posebno u hijerarhiji koja pokušava biti ravna što je moguće više onda takav arhitekta (prema Felveru naziva Architectus Oryzus) ipak nije dobrodošao, jer niko ne voli diktature i diktatore, rekli bismo.
* pragmatizam – Noviji filozofski pravac, čiji je osnivač američki filozof Vilijam Džejms (William James) – 1842 – 1910, po kome cjelokupno naše znanje treba mjeriti i cijeniti samo po njegovoj praktičnoj vrijednosti i koristi za život, i po kome je “istinito” samo ono što može imati praktične vrijednosti. Istina je ono što pomaže održanju. Istina ili istinistost nekog suda sastoji se u tome što je “koristan”, što “uspijeva”, polazi za rukom, što “zadovoljava”.
2Hits: 156