Iz ugla arhitekte: Arhitektura softvera i uloga arhitekte u fintech rešenjima

Intervju 25. jan. 2022

Uloga arhitekte u softverskim kompanijama je ujedno i izazov, ali  i užitak – da nije tako, teško da bi se ko odlučio na ulogu arhitekte.

Kada bacim pogled unazad sve do mojih skromnih početaka i dalje, imao sam priliku da vidim koliko su se menjale paradigme i platforme – ali je suština uvek ostala ista.

Zato sam odlučio da pristupim pisanju ovog teksta kao pravljenju zen ručka – malo ću pisati o onome što prolazi, najviše o onome što je aktuelno i malo o onome što nam tek dolazi.

Kompleksnost problema pri razvoju softvera se neprekidno uvećava, ali uvek ide u korak sa razvojem novih metodologija i alata sa kojima raspolažemo.

Šta je arhitektura u razvoju softvera?

Jedan od ključnih elemenata u procesu razvoja softvera jeste definisanje arhitekture koju smo dugo posmatrali kao važan, ali pomalo maglovit koncept. A takvi su bili i opisi arhitekture softvera:

  • Arhitektura su stvari koje se teško menjaju
  • „Arhitektura je nešto o važnim stvarima... šta god one bile“ – Ralph Johnson
  • Arhitektura je nacrt sistema

Samim tim, bilo je nejasno kako se postaje softverski ahritekta – nije postojala precizna karijerna putanja za tu ulogu.

Najbolja definicija arhitekture do koje sam došao jeste da se ona sastoji od:

  1. Strukture sistema
  2. Karakteristika sistema
  3. Odluka
  4. Principa dizajna

Šta to tačno znači?

Struktura sistema se odnosi na stil ahritekture u kome je sistem implementiran (slojevita arhitektura, mikroservisi, monolitan sistem itd.).

Karakteristike sistema su kriterijum uspeha rešenja, one su ortogonalne na funkocionalnost i često se u literaturi na engleskom označavaju kao "ility’s" (availability, reliability, testability, scalability, security…).

Odluke se donose u vidu pravila da bi se odredilo kako se sistem implementira – npr. da samo servisni ili domenski sloj imaju direktan pristup bazi podataka.

Principi dizajna se razlikuju od odluka po tome što nisu tvrda pravila nego pre smernice poput toga da je u mikroservisnoj arhitekturi asinhrona komunikacija među servisima poželjnija od direktnih poziva.

Dakle, uloga arhitekte je:

  1. Da donosi odluke
  2. Kontinuirano analizira arhitekturu
  3. Prati najnovije trendove
  4. Osigurava saglasnost sa odlukama
  5. Poseduje iskustvo i upoznat je sa raznim tehnologijama
  6. Poseduje domensko znanje kao i veštinu mueđuljudskih odnosa

Na kraju, a ne manje važno arhitektura i arhitekta se mnogo više bave pitanjem zašto, a ne kako.

(R)evolucija arhitekture softvera

Davne 2000. kad sam ušao u svet fintecha već su bila prisutna sofisticirana rešenja sa specijalizovanim i povezanim komponentama, no potpuno prihvatljiva arhitektura sistema u industriji bila je i ona kod koje su se i prezentacioni sloj i aplikativna i domenska logika nalazile u jednoj izvršnoj aplikaciji koja je komunicirala sa bazom direktno gde je eventualno bio deo poslovne logike u vidu procedura.

Prvi put sam za jednu od važnih karakteristika poput pokrivenosti koda unit testovima dobio direktno pitanje od klijenta 2003. godine.

To su otprilike i bile zadnje godine za takav stil, te se tada i počelo insistirati na višeslojnoj strukturi sa precizno definisanim servisnim slojem u kome se nalazio što je moguće više izolovan domenski (poslovni) sloj i kome je prezentacioni sloj pristupao na standardan način.

Izolacija je postala kljućna reč i taj princip neizmenjeno vredi do danas.
Izolacija podrazumeva ne samo izolaciju slojeva već razne oblike nezavisnosti od infrastrukture, baza podataka itd.

Nastupio je ubrzan razvoj obrazaca, koji su prerasli u standarde, kao i frameworka koji te standarde implementiraju, bilo da se radi o servisnoj komunikaciji, ORM rešenjima, integracijama itd.

A danas?

Danas kada je cloud infrastruktura sazrela, kada imamo kontejnerizaciju i orkestraciju, svi uslovi su se stekli da na standardan način dekompozicijom problema kroz mikroservise obezbedimo karakteristike poput dostupnosti (availability), skalabilnosti i mnoge druge.

Zašto je arhitektura fintech rešenja posebna?

Fintech je izraz koji se koristi za bilo kakva rešenja u domenu finansijskih poslovanja.

Konkretno on obuhvata bankarstvo, kapitalna tržišta i platni promet, između ostalog. To je dosta široka oblast vrlo raznorodnih domena, ali koji dele neke zajedničke karakteristike i to je zaista vidljivo u kontekstu arhitekture.

Naime, apsolutno su krucijalne karakteristike poput:

  • dostupnosti 24/7
  • visokih performansi
  • tesno skrojene sigurnosti
  • pokrivenosti testovima
  • integrisanosti sa drugim sistemima

Takođe su sva rešenja domenski vrlo intenzivna, jer je svet finansija vrlo složen po pitanju proizvoda, učesnika, pravnih okvira, raznih analiza nad velikim brojem podataka itd.

Kako veliki zahtevi traže velika rešenja – fintech je uvek bio okrenut inovacijama i novim tehnologijama.

Gde smo sad?

Fintech domeni su neretko veoma povezani i čest je bio slučaj da jedno (enterprise) rešenje pokriva više od jednog domena.

Danas možemo reći da postoje dva trenda:

  1. Dekompozicija i specijalizacija
  2. Integracija tako nastalih komponenti

U arhitekturi nema srebrenog metka. Arhitektura koja odgovara jednom rešenju i grupi ljudi koja ga razvija, možda ne odgovara drugom.

No, da bi se ispratili navedeni trendovi i zahtevi prirodno je da struktura novih kao i tranzicija postojećih sistema u fintechu bude mikroservis sa cloudom kao ciljnom platformom.

Slojevita arhitektura i izolacija koju smo pominjali je i dalje važeća za konkretan mikroservis.

Veoma važna metodologija u definisanju odgovornosti takvih komponenti jeste domenom vođen dizajn (domain driver design), jer se dekompozicija u mikroservise obično sprovodi po granicama poddomena.

Integracija, sa druge strane, omogućava korisnicima da skroje rešenje koje u potpunosti odgovara njihovom poslovnom modelu prostim izborom komponenata iz ponude.

Šta onda čini dobru arhetekturu softvera?

Kriterijumi šta je dobar softver su brojni, no za mene jedan iskače pre drugih:

Za mene je dobar softver onaj koji možemo beskonačno refaktorisati i proširivati da bismo očuvali njegovu aktuelnost.

Primer iz davnina je UNIX operativni sistem nastao u zlatno doba AT&T korporacije.

Koja je njegova tajna?

Jednostavan dizajn.

Rešiti kompleksan problem jednostavnim dizajnom je recept za dugovečnost. Svakodnevno se suočavamo sa takvim izazovima i kad se nađemo pred problemom reagujemo često kao optimisti ili pesimisti.

Skoro sam čitao nešto dobro što me oblikuje već duže vremena:

Svi smo mi trenirani "solušnisti", dakle ljudi koji traže rešenja na teške probleme, a dobra stvar je što svaki problem ima rešenje.

Reč dve o procesu i metodologijama

Razvoj softvera je tim.

Tim nije skup pojedinaca sa unapred određenim ulogama. To je živi ogranizam koji funkcioniše kao jedna celina.

Bez obzira da li se radi o scrum timu koji se može nahraniti sa dve pice i koji uživa zajedničko vlasništvo nad komponentom (servisom) koji razvija, ili je to širi tim celog proizvoda, ili još širi tim cele organizacije, on mora da poseduje duh koji motiviše i čini da ljudi uživaju dok rade jedni sa drugima.

Mi stvaramo u agilnim, iterativnim procesima zahvaljujući kojima i možemo da garantujemo uspeh rezultata. U srcu agilnog razvoja je agilni tim koji ima sve članove neophodne da domensko znanje pretoči u implementaciju i potvrdi kvalitet rešenja. U procesu su prisutni svi stakeholderi tako da je povratna informacija uvek aktuelna. U agilnu metodologiju se savršeno uklapa i današnji pogled na arhitekturu sistema i ostale procese dizajna i modeliranja.

Mesto arhitekte u tom procesu je definitvno u timu. Naime, proces u kome su arhitekte donosile odluke i prepuštale drugima implementaciju pokazao se pogrešan, kako u smislu kvaliteta samog rešenja, tako i povratne informacije.

No, arhitekta se od ostalih developera razlikuje po širini znanja i kako obično put do pozicije arhitekte vodi preko ostalih pozicija u razvoju, on je dubinu već stekao. Česta je greška da arhitekta pravi neki framework dok ostali čekaju, te on mora da deli posao sa drugima i da pre razivja neki proof of concept nego ceo framework.

Recimo još da se većina karakteristika, odluka i prinicipa dizajna može validirati u dobro osmišljenom CI/CD procesu, te da zato postoje brojni alati.

Gde ćemo biti?

A kraj? Pa nema kraja.

Ima samo novi početak.

Nalazimo se u osvitu novih tehnologija. Među njima je, naravno, veštačka inteligencija i obećanje da će svaki uređaj imati softver. Naši telefoni već imaju specijalizovane AI čipove koji menjaju način na koji ljudi komuniciraju sa njima, ili nam pomažu da neke stvari (fotografisanje npr.) uradimo bolje.

I eto, time se načinje novo poglavlje, jedna druga vrsta razvoja softvera. U fintech svetu AI dovodi do stvaranja novih uloga u kojima softverski agenti menjaju ljudske. Velika su očekivanja od blockchain tehnologije i pametnih ugovora (smart contract) koji bi trebalo da pojednostave proces izvršavanja finansijskih transakcija.

Umesto tipičnog zaključka, jer kao što sam rekao – nema kraja, preporučio bih budućim i sadašnjim arhitektama jednu knjigu:

  • Fundamentals of Software Architecture: An Engineering Approach 1st Edition, by Mark Richards (Author), Neal Ford  (Author) (O'REILLY)

Autor teksta:

Željko Tešić, Software Architect | FIS Securities Finance Trading and Collateral Platform

Tagovi

FIS

FIS je globalni lider u tehnologiji finansijksih usluga i najveća FinTech kompanija na svetu.

Tvoja prijava je uspešno sačuvana!
Odlično! Da bi imao pristup kompletnom sadržaju bloga potrebno je da završiš proces plaćanja.
Tvoja prijava je uspešna!
Tvoj nalog je aktiviran, sada imaš pristup kompletnom sadržaju bloga.