U današnje vrijeme kada se sve više stvari digitalizira, kada je sve više mladih developera, kada se  sve više developera trudi napredovati i istaknuti u velikoj konukrenciji, često se zapitaju, u kojem smjeru se dalje razvijati i kako se izdvojiti iz mase. Učiti sve pomalo i upoznati se sa sve više programskih jezika, ili se možda usmjeriti dublje u jednom smjeru pa tu napredovati i penjati po ljestvici senioriteta?

Često je odgovor na gornje pitanje odgovoren i nametnut od strane okoline u kojoj developer radi. Pored sebe uglavnom ima senior developera i barem jednog arhitekta. Arhitekta kojeg gleda kao neki cilj koji želi postići.

Autor: Tomislav Globlek, Application Architect, ELEKS

Teorija o arhitekturi i arhitektu

Da bi imao što bolji uvid u arhitekturu kao vještinu, svaki developer bi se trebao zapitati Tko je arhitekt softvera?

Odgovor na pitanje se krije u daljnjem tekstu, ali prije nego iznesem svoje osobne stavove i viđenje stvati oko tog tko je ta osoba, potrebno je malo zaviriti u teoriju oko tog pitanja, a teorija se uvijek nalazi u brojnim knjigama na tu temu. Jedna knjiga u kojoj sam naišao na zanimljive definicije (i po mojem mišljenju dosta točne) je Software Archiecture In Practice - fourth edition.

U toj knjizi se definira što je uopće arhitektura softvera (prije nego se postvetimo tome tko je osoba koja to radi).

Dakle, arhitektura softvera je skup struktura koje su potrebne da bi se sustav objasnio i razložio, a te strukture obuhvaćaju elemente, relacije između njih te sva njihova svojstva. Također, arhitektura software-a uključuje i ponašanje tih elemenata koje također pomaže u objašnjavanju arhitekture.

Ako želimo dalje razložiti arhitekturu, možemo vidjeti da postoji i više vrsta arhitekture.

System architecture

“A system’s architecture is a representation of a system in which there is a mapping of functionality onto hardware and software components, a mapping of the software architecture onto the hardware architecture, and a concern for the human interaction with these components. That is, system architecture is concerned with the totality of hardware, software, and humans.”

Enterprise architecture

“Enterprise architecture is a description of the structure and behaviour of an organisation’s processes, information flow, personnel, and organisational subunits. Thus a modern enterprise architecture is concerned with how software systems support the enterprise’s business processes and goals.”

Iz ovih definicija je vidljivo da se Enterprise arhitektura ne bavi razvojem aplikacija ili softvera općenito, nego kako se taj softver može uklopiti i pomoći organizaciji i unutarnjim procesima organizacije.

Uloga arhitekta prema razinama može biti Associate, Architect, Solution Architect, te strateški ili Enterprise Architect

Većina developera kada žele postati arhitekt softvera zapravo misle i razmišljaju o System Arhitekturi, odnosno arhitekturi sustava ili aplikacija koja obuhvaća prezentaciju i dizajn arhitekture aplikacija kao mapiranje softverskih komponenti na hardware-ske komponente i kako ljudi koriste taj softver - taj ogranak arhitekture se bavi tehnologijom i tehničkim izazovima koje arhitekti rješavaju kada rade i dizajniraju arhitekturu sustava ili aplikacija.

Gledajući dalje, Arhitekt uloga se, ovisno o organizaciji u kojoj radite, može gradirati u nekoliko razina, počevši od početnika ili Associatea, preko Arhitekta, Solution Arhitekta, pa do strateškog ili Enterprise Arhitekta. Kako se kreće po tim ulogama, može se primijetiti kako se fokus osobe u tim ulogama prirodno ili sustavno mijenja, krenuvši od 100% tehnološkog fokusa kod početnika koji se smanjuje na samo 20% tehnološkog fokusa kod Strateškog ili Enterprise arhitekta. S druge strane se ostali fokusi pojavljuju i rastu u obrnutom smjeru, gdje je najveći fokus kod stratega na poslovnom aspektu, odnosno, kod svog posla najveći fokus je zadovoljiti poslovanje i poslovne potrebe dugoročno i u budućnosti, a ne samo trenutne tehnološke probleme.

Teorija je jedno, a praksa je drugo

Kada developeri ili striktno tehničke osobe gledaju Arhitekt rolu kao uzor i njihov cilj u karijeri, referiraju se na teoriju i na temelju toga odlučuju. Često ne vide sve ostale stvari koje arhitekti rade u svakodnevnom poslu.Ta ostala zaduženja arhitekta izlaze iz okvira teorije, odnosno, u teoriji i definiciji se uopće ne spominju, ali jesu u opisu posla arhitekta.

U praksi, arhitekti sudjeluju u svim fazama projekta, i često su ključni sastojak za uspješnost projekta. Neke od faza projekata, koje ne isključuju i ostale faze koje nisu ovdje pobrojane, su:

1. Presales - arhitekt je uglavnom najkompetentnija osoba za inicijalnu procjenu projekta, njegovu izvedivost, isplativost i u konačnosti procjenu potrebnih radnih sati ili dana. Dakle, Arhitekt će često razgovarati i surađivati sa prodajom u toj fazi.
2. Na samom dobivenom i dogovorenom projektu (ili čak i prije početka projekta), arhitekt će također razgovarati i surađivati sa klijentom i poslovnom analitičarima kako bi se dogovorio i detaljizirao opseg projekta.
3. Projektni menadžer je osoba koja će od arhitekta dobiti najtočnije informacije o procjeni zadataka, prioritetima te definiranju vremenskih rokova i okvira za rad developera i ostalih tehničkih resursa na projektu
4. Arhitekt je najkompetentnija osoba za razgovor sa klijentom te prezentacije idejnih rješenja sa tehničke a često i poslovne perspektive, tako da će arhitekt često razgovarati i sa klijentom, počevši od presales faze, te tokom projekta održavajući radionice i prezentacije.
5. Management organizacije u kojoj arhitekt radi vidi te osobe kao najbolji izvor točnih informacija u kontekstu projektnih eskalacija, kako bi se saznali detaljni i realni razlozi potencijalnih problema ili kašnjenja

U konačnici, Arhitekt na projektu je u sredini, ima kaotičnu ali u isto vrijeme i ključnu ulogu u svim aspektima projekta, primoran je komunicirati sa svima, pa to i čini na dnevnoj bazi, jer mu je to u opisu posla. Ukoliko Arhitekt na projektu podbaci, podbacit će i cijeli projekt jer ostali članovi vjerojatno neće imati ključne informacije u pravo vrijeme, a s druge strane, ako Arhitekt odradi svoj dio posla, projekt uspijeva (naravno, pod pretpostavkom da svi odrade svoj dio posla, ne samo Arhitekt).

Tko je na kraju Arhitekt?

Konačne definicije Arhitekta po mojem mišljenju na kraju i nema. Nisu još svi projekti i sve arhitekture napravljene da se ne bi projektni tim našao na nepoznatom terenu, i onda je potrebno izlaziti iz okvira svojih uloga, a tu je Arhitekt najčešće gurnut u vatru, da istraži teren, da osmisli barem neko konceptualno rješenje, da razgovara i dogovara što će se i kako će se napraviti, što je bitno a što nije….

Ono što je sigurno, a to je da je Arhitekt, između ostalog, i netko tko:

• Razgovara sa ljudima - jer je to jedini način da sazna, njemu i projektnom timu sve relevantne tehničke informacije kako bi mogao odraditi svoj dio.
• Razumije business - kako bi mogao klijentima predložiti i osmisliti rješenje koje će riješiti njihove probleme i dati im dodatnu vrijednost, a ne samo slijepo slušati često nerealne zahtjeve.
• Piše čitljive dokumente - jer će često ti dokumenti biti čitani od strane ne-tehničkih osoba, primarno kod klijenata, koji će na temelju tih dokumenata donositi daljnje odluke oko projekta, budžetiranja i slično.
• Rješava konflikte - s obzirom da je često u sredini i pored projektnog menadžera jedini komunicira sa svim uključenim strankama projekta, može razumjeti i uzrok problema pa ga samim time i riješiti.
• Donosi odluke - koje drugi ne mogu ili možda ne žele donijeti jer nisu sigurni u posljedice. Netko ipak mora, pa je to onda često Arhitekt.
• Prezentirati ideje - tko najbolje klijentima i managementu prezentira ideje nego osoba koja je inicijalne zahtjeve i pretočila u konceptualnu ideju.
• Crtati dijagrame - ipak moja najdraža vještina, jer je putem dijagrama najlakše prezentirati ono što osmisliš, bilo da se radi o poslovnim procesima, relacijama između objekata i klasa u kodu, ili pak relacijama između gotovih servisa, itd…dijagram je ključ vizualizacije softvera!

Dakle, zaključak je, Arhitekt je “tehnička” osoba, koja mora posjedovati i razviti puno “soft skill”-ova na koje mladi developeri na početku svoje karijere ne trebaju, i o kojima ne razmišljaju. A za razviti te vještine, potrebno je vremena.

Ovo nije spojler na kraju za developere, nego samo osvješćivanje realnosti Arhitekt role kojoj ipak dobar dio developera stremi - i neka stremi, jer je, iz vlastitog iskustva pričajući, biti Arhitekt često je izazovno, ali nikad dosadno! Nemojte se žuriti da se ne bi razočarali.

Želite li ostvariti karijeru kao arhitekt softvera, javite se na https://careers.eleks.com/ ili posjetite facebook stranicu ELEKS Inside