Naravno, mi ovdje govorimo o softver arhitektama, ali i svaki drugi arihtekta se može “pronaći u priči”.

Vjerovatno ste se nekada (možda kao djeca) pitali, koja se to škola treba završiti ili šta se treba znati da bi se bilo u mogućnosti nacrtati neku prelijepu zgradu ili kuću koju ste vidjeli u katalogu. I to je odlično pitanje, zato i želimo u nastavku da navedemo nekoliko različitih profesija, a koje u svom nazivu imaju aritehkta. Neki od njih su usko vezani za izgradnju zgrada ili kuća, dok drugi nisu ni blizu.

Tipovi (klasičnih) arhitekata:

• Rezidencijalni (Stambeni) arhitekt — Ovo je vjerovatno onaj o kom ste sanjali/razmišljali, koji osmišljava dizajn zgrada i/ili kuća.
• Komercijalni ili javni ahirekta — Ovaj arhitekta je veoma sličan onom iznad, ali je specijalizvoan za omišljavanje dizajn građevina od javnog dobra, kao što su aerodromi ili gradske vijećnice, biblioteke, …
• Pejzažni arhitekta — Ako se budete bavili ovim poslom u životu, to će vjerovatno značiti da se bavite dizajnom i arhitekturom parkova, travnjaka, vrtova, koji mogu biti javni ili privatni. Ako se možda sada u ovom trenutku pitate, a kome to treba, zamislite samo da neko treba da dizajnira golf teren.

Ova lista je poprilično duga i mi je nećemo navoditi cijelu. Mnogi od tih arhitekata u našoj zemlji ćemo naći u jednoj osobi. Tj. osoba je istovremeno i rezidencijalni i komercijani arhitekta, ali također i pejzažni.

S druge strane, postoje i neke druge arhitekte, a to su oni o kojima želimo reći par riječi ovdje. To su:

• Softver ahitekta — Zanimanje koje podrazumijeva izradu dizajna fundamentalnih osnova softverskog sistema.
• Aplikacioni arhitekta — Radi s veoma specifičnim vrstama aplikacija. Usko specijalizovani arhitekta.
• Arhitekta rješenja — Mogao bi se nazvati kao neki šef ili nadređeni gore spomenutog, aplikacionog arhitekte. Tj, arhitekta rješenja iznalazi dizajn i arhitekturu kompleksnih softverskih rješenja gdje pojedine aplikacije komuniciraju medjusobno.
• Sistemski arhitekta ili Poslovni (Enterprise) arhitekta — Bavi se dizajnom softverskog rješenja, a koji je veoma uticajan u donošenju poslovnih odluka, tj. aktivno učestvuje u poslovnim pregovorima. Veoma velike kompanije imaju posebnu poziciju samo za ovaj posao, dok srednje i male firme uglavnom objedinjuju ovu ulogu u još neke druge iznad spomenute, ili je čak ni nemaju. U tom slučaju poslovne odluke donose neki drugi ljudi/uloge.
• Arhitekta oblaka (Cloud architect) — Nova disciplina, usput rečeno, i veoma popularna. Arhitekta oblaka ustvari se ne bavi samom arhitekturom softvera kao oblaka, nego softvera koji će biti pogonjen na obalacima. Najpoznatija rješenja u oblacima danas su svakako Amazon AWS, Microsoft Azure, Google Cloud i drugi.

Zašto ovakav, pomalo grub, naslov?

Osnovni razlog zašto bi arhitekte trebale biti više inžinjeri, a (mnogo) manje umjetnici jeste stvar komunikacije. Trebamo da se učimo i vježbamo tako da zajednički radimo “protiv” projekta, a ne jedni protiv drugih! Ako želimo raditi po agilnim metodologijama, onda je komunikacija ključni faktor uspjeha. Da bi komunikacija bila dobra, svi moramo pričati istim jezikom. Jer ono što su arhitekte zamislile i predstavile u svojim dokumentima, nužno, mora biti razumljivo svima ostalima u timu koji radi na tom projektu. Ne samo tehničkim licima, poput vođe tima, ili krajnjeg inžinjera, nego i svima ostalima, od Project Owner-a, Scrum Master-a, pa nadalje.

Simboli kao standard i “sloboda umjetnika”

U svijetu arhitekture koristi se jako mnogo simbola, ali i “sloboda umjetnika”. Stoga je gotovo postalo pravilo da svaka prezentacija softvera izgleda drugačije. Od korištenja boja, veličine nekih oblika (trougli, četverougli, krugovi, elipse, …), do načina na koji se oni povezuju na nekoj šemi. I šta sada da se radi? “Slobodni umjetnici” žele da budu domišljati i stvari predstaviti na “moderan”, prihvatljiv način, ne poštujući (strogo) standard. Uglavnom zbog toga mnnoge sheme ne znaju pročitati niti druge arhitekte, a o ostalim članovima tima da i ne govorimo — posebno netehnička lica.

Kontejneri

Docker je nažalost “ukrao” ovu riječ i danas kada se spomene kontejner, svi nekako po automatizmu misle na Docker container. No! U svijetu softverske arhitekture to nije tako! Kontejner predstavlja jednu nezavisnu cjelinu. Kada se kaže nezavisnu, misli se da se može pokreniti, čak i ako tako pokrenuta ne radi (gotovo) ništa. Primjer kontejnera može biti:

• Baza podataka — ona sama po sebi ne radi ništa, odnosno servis koji nam služi za upravljanje bazama podataka, sve dok ne počnemo da upisujemo i čitamo iz te baze.
• Mobilna aplikacija — naravno mobilna aplikacija može da radi sama po sebi, ali zamislimo recimo facebook ili twitter aplikaciju. One su u potpunosti beskorisne ako ne preuzimaju podatke s nekog servisa.
• Backend servis — neki mali servis koji može da npr pretvara podatke ili ih objedinjuje ili bilo šta drugo. Takav jedan servis je moguće pokreniti bez zavisnosti o drugim servisima, ali je sam po sebi beskoristan, sve dok ga neki drugi servis ne iskoristi. Tj, ne pošalje mu nešto da on uradi i dostavi nekome rezultat.

Veoma je važno prilikom predstavljanja nivoa shema da se posmatraju kontejneri. A to opet zavisi o kom nivou dizajna i arhitekture softverske aplikacije se priča.

C4 model bez 4

Da bi se znalo u kojoj fazi ili u kojoj shemi se šta prikazuje, bilo bi možda dobro da se iskoristi jedan novi pristup softverskoj arhitekturi. Od toga šta i kako se priča na sastanacima, do toga kako i gdje se prezentuje ono što se dogovorilo ili o čemu se pričalo. U tu svrhu je dobro početi s C4 modelom.

S C4 modelom se arhitektura softvera posmatra veoma slično kao kada pristupamo virtualnim mapama. Ako vidimo ulice i par kuća na mapi, to nam neće reći mnogo o tome gdje se mi ustvari nalazimo. Zbog toga nam treba da vidimo za primjera radi prvo kontinent, zatim državu, pa grad, pa unutar grada ulicu.

Broj 4 u nazivu upravo i govori o 4 nivoa. Ti nivoi predstavljanja su:

1. Cjelina sitema (System context) dijagram predstavlja početnu tačku. Prikazuje kako se softverski sistem uklapa u ostatak svijeta oko njega.
2. Dijagram kontejnera predstavlja prvo povećanje (ulazak u) samu strukturu softvera koji se obrađuje. Prikazuje blokove/kontejnere i njihovu međusobnu zavisnost.
3. Dijagram komponenata predstavlja bliži opis svakog pojedinog kontejnera iz prethodnog nivoa.
4. Dijagram koda se u osnovi izbjegava prilikom arhitekture softvera! To je i razlog što smo u naslovu naveli “bez 4”. No, dijagram koda je standardni UML dijagram klasa koji pobliže objašnjava same međusobne odnose unutar koda.

0

Hits: 0