Kā Tu izvēlējies strādāt šajā jomā un kur apguvi šo profesiju?

Skolas laikā sporta turnīrā kā balvu saņēmu grāmatu „Kā Pēcis Beiskāns Maiju Saprātiņu programmēt mācīja”. Grāmata man ļoti patika, taču nebija datora, uz kura to visu izmēģināt. Pēc kāda laika tēvam uzdāvināja datoru, ar kuru varēju „spēlēties” – rakstīju vienkāršas programmas. Nākamais solis bija iesaistīšanās skolas informātikas pulciņā. Pēc tam konkursa kārtībā tiku uzņemts „Progmeistars” programmēšanas kursos, kuros mācījos 3 gadus. Piedalījos arī Sorosa fonda rīkotajā olimpiādē, kuras laikā veselu gadu bija jārisina dažādi programmēšanas uzdevumi. Tā arī sapratu, ka gribu būt par programmētāju. Studēju LU un ieguvu akadēmisko bakalaura un maģistra grādu datorzinātnēs. Studiju laikā nokārtoju arī MCP sertifikātu.

Darbā mani pieņēma kā programmētāju. Taču darba gaitā es aizvien vairāk pildīju uzdevumus, kas prasīja koordinēšanu, iniciatīvu un argumentāciju. Nolēmu ar to necīnīties, bet izmantot izaugsmei. Sistēmas arhitekta darbs lielā mērā ir saistīts ar cilvēku darba koordinēšanu. Tā vienmēr ir sava veida vīzija, kuru ne tikai ieraksti dokumentā, bet arī komunicē komandas biedriem. Ir jāprot to izskaidrot un pamatot izstrādātājiem. Jāseko līdzi, lai tavas idejas tiktu pareizi realizētas. Ar IT speciālistiem darbojas tikai argumentēta pieeja.

Kādi ir Jūsu galvenie pienākumi?

Izstrādājot informācijas sistēmas, pielieto noteiktas tehnoloģijas. Sistēmu arhitekts ir viens no galvenajiem speciālistiem, kurš tās izvēlas, pamato to izvēli un savstarpēji saskaņo šo tehnoloģiju izmantošanu. Tehnoloģijas ir gan operētājsistēmas, gan programmatūra, tai skaitā serveru programmnodrošinājums, gan aparatūra, gan programmēšanas valodas, gan atkārtoti izmantojamas koda bibliotēkas.

Jebkura sistēma ir loģiska struktūra, kas sastāv no sastāvdaļām jeb moduļiem, katram no kuriem ir sava atbildība un kuri ir savstarpēji atkarīgi. Sistēmu arhitekts ir tas, kas izveido un pārvalda šo struktūru.

Piemēram, jāizstrādā personāla pārvaldības sistēma. Vispirms jāsaprot, kādi uzdevumi tai būs jāveic, kāds būs tās funkcionēšanas mērķis. Jāsaprot, kāda tehnika darbinās šo sistēmu. Tad, kad ir uzprojektēta kopējā struktūra, tā ir jādekomponē jeb jāsadala loģiskos moduļos, jāuzprojektē, kā tie mijiedarbosies.

Otrs darba piemērs - sistēma jau ir izveidota, un tiek saņemts izmaiņu pieprasījums. Sistēmas arhitekts ir viens no tiem, kurš pasaka, kur šī izmaiņa tiks realizēta, kādus moduļus skars. Viņš pasaka, kādas izmaiņas vispār ar esošo sistēmas arhitektūru var veikt. To, vai arhitektūra ir laba vai slikta, nosaka no vienas puses spēja nodrošināt šī brīža prasības, bet no otras puses –  noturība pret izmaiņām. Veidojot sistēmas arhitektūru, jau sākumā jāparedz iespēja nākotnē veikt tās papildinājumus vai izmaiņas. Nav iespējams vienmēr paredzēt, kādas šīs izmaiņas būs, bet var, līdz zināmai pakāpei, nodrošināt, lai tās varētu veikt un veikt pietiekami viegli.

Esmu strādājis divos lielos virzienos: palīdzējis izstrādāt sistēmas projekta piedāvājumus un vadījis sistēmu izstrādi. Pirmajā gadījumā tiek izsludināts konkurss par IT sistēmas izstrādi. Es palīdzu uzņēmumam sagatavot tehnisko piedāvājumu šim konkursam, gatavoju risinājuma arhitektūru atbilstoši izsludinātajām prasībām. Ir bijis tā, ka veselu gadu nodarbojos tikai ar piedāvājumu gatavošanu, bet pats nevadīju manis projektēto risinājumu izstrādi. Lai sagatavotu risinājuma arhitektūru konkursa piedāvājumam, parasti paiet no divām nedēļām līdz mēnesim.

Taču esmu arī strādājis kā sistēmu arhitekts – projektu vadītājs. Esmu gan izstrādājis sistēmas arhitektūru, gan vadījis projekta darbiniekus, kas to īstenoja dzīvē.

Kāda ir Jūsu darba ikdiena?

Skatoties ilgākā laika posmā, aptuveni pusi laika aizņem dažādas tikšanās, telekonferences vai sapulces, un aptuveni puse laika tiek veltīta sistēmu arhitektūras veidošanai. Taču tas ir ļoti atkarīgs no projekta posma, kurā esmu. Nākas lasīt daudz e-pastu. Ja ir starptautiski projekti, saņemu e-pastus arī no citām valstīm. Uz e-pastu pienāk arī atgādinājumi no citām sistēmām par veicamajiem darbiem.

No rītiem mums ir īsas sanāksmes, kur visi projektā iesaistītie var pārrunāt tuvākos darbus. Nereti kolēģiem rodas jautājumi, kas attiecas uz sistēmas arhitektūru. Es no savas puses sekoju, lai darbi virzās nepieciešamajā virzienā.

Sistēmas arhitektūras dokumentācija ietver arī diagrammas. Manuprāt, UML (Unified Modeling Language) būtu jāmāca jau skolā, jo tā ir standartizēta un starptautiski atzīta diagrammu valoda, kas ir pietiekami izteiksmīga un vispārīga, lai to varētu izmantot ne tikai informācijas sistēmu projektēšanai vai aprakstīšanai, bet arī modelēšanai citās sfērās un nozarēs. Piemēram, studējot universitātē, nereti daļu lekciju esmu konspektējis UML klašu diagrammu veidā.

Kad uzprojektētā sistēma tiek realizēta, arhitektam ir jāseko līdzi programmētāju darbam. Tai skaitā, piemēram, ir jālasa kods (jāorganizē kopīga koda caurskatīšana – code reviews) un log-faili. Pirmkoda caurskatīšana ir lielisks veids, kā pārliecināties, ka sistēma ir uzprogrammēta tieši tā, kā tas ir paredzēts projektējumā. Jāseko līdzi, lai visa sistēma būtu veidota konsekventi, ievērojot noteiktus principus. IT arhitekta uzdevums ir ne tikai izstrādāt sistēmas projektējumu, ievērojot konsekventu pieeju, bet arī rūpēties par to, lai sistēma tieši tā arī tiktu uzbūvēta.

Daudz sanāk dokumentēt to, ko daru pats, un to, ko dara komanda. Tas noder, ja projektā kaut kas jāmaina un ir nepieciešams atgriezties kādā no iepriekšējiem posmiem. Dokumenti ne vienmēr ir Word formāta A4 lapa. Ir risinājumi, kas ļauj katrā programmēšanas vai izmaiņu solī pievienot komentārus par to, kad un kāpēc tas tika darīts.

Vai ir kāda atšķirība, ja Jūsu profesijas pārstāvis strādā individuāli, strādā nelielā IT nodaļā vai lielā IT uzņēmumā?

Mazos uzņēmumos, kuri piedāvā daudzus samērā līdzīgus pakalpojumus, veidojas iestrādes, kas padara šos pakalpojumus efektīvākus un vieglāk pārveidojamus. Te parādās darbs sistēmu arhitektam, kurš var pateikt, kā sagatavot pamata sistēmu, lai to varētu pielāgot dažādu klientu prasībām. Mēdz būt tā, ka sistēmu arhitekts tiek piesaistīts tikai kā pašnodarbinātais, nevis algots pastāvīgam darbam. Arī lielākos uzņēmumos ne vienmēr sistēmu arhitekts ir kā atsevišķs amats, jo šis ir samērā dārgs „instruments”, kas atmaksājas tad, ja veido lielas un sarežģītas sistēmas, vai tad, ja piedalās vairākos projektos vienlaicīgi. Nelielos projektos daļu no sistēmu arhitekta darba nereti veic sistēmanalītiķis.

Kādas prasmes un rakstura īpašības ir nepieciešamas, lai labi veiktu šo darbu?

Sistēmu arhitekts ir līdzīgs arhitektam būvniecībā. Viņš veido projektu, kuru kāds cits realizēs. Lai arī arhitektam pašam nav jāmāk celt ēkas, viņam ir jāsaprot, ko var un ko nevar panākt ar tiem vai citiem materiāliem un instrumentiem. Sistēmu arhitektam ir ļoti vēlama programmētāja pieredze vai vismaz izpratne par to, ko programmētājs var paveikt. Jāpārzina dažādu tehnoloģiju saderība, jāsaprot, ko tā vai cita tehnika var paveikt. Svarīga ir loģiskā domāšana apvienojumā ar zināšanām par konkrētām tehnoloģijām. Jāpārzina arī tehnoloģiju un sistēmu „vājās vietas”.

Jābūt spējīgam darboties konsekventi nenoteiktos apstākļos. Prasības mainās, nav zināmas ļoti daudzas detaļas. Taču tev jāspēj strādāt precīzi un argumentēti. Jāspēj koncentrēties un iedziļināties. No otras puses, izteikti intravertam cilvēkam būtu grūti darīt šo darbu, jo tas ir komandas darbs, kas prasa spēju sarunāties, uzklausīt un pārliecināt.

Kādi ir vislielākie izaicinājumi šajā darbā?

Ja esi veiksmīgi ticis galā ar sarežģītiem uzdevumiem, tevi met iekšā vēl sarežģītākos darbos. Ne vienmēr sistēmu arhitekts sāk darbu no paša sākuma – jāspēj pieslēgties sistēmas būvēšanai jebkurā posmā.

Rit mūžīga cīņa ar perfekcionismu – vari iedomāties perfektu sistēmas arhitektūru, taču vienmēr ir jārēķinās ar realitāti un tās ierobežojumiem.

No otras puses, perfekcionisms ir viena no profesionālās piederības pazīmēm, ja tev tas ne mazākā mērā nepiemīt, visdrīzāk IT tev nepadosies.

Kas šajā darbā sagādā gandarījumu?

Gandarījums ir, ja notikumi attīstās tā, kā paredzēji. Piemēram, sistēma iztur slodzi, pateicoties tam, ka tu vajadzīgajā vietā esi to padarījis noturīgāku. Vari ātri un viegli realizēt sarežģītu izmaiņas pieprasījumu tāpēc, ka arhitektūra to atļauj. Jauni darbinieki viegli iekļaujas projektā, jo projekta uzbūve ir skaidra un dokumentācija ir saprotama.

Kādas ir izaugsmes iespējas šajā profesijā?

Sistēmu arhitekta līmenis pats par sevi ir daudzu programmētāju karjeras mērķis. Kad esi to sasniedzis, vari kļūt par ekspertu savā jomā – uzstāties konferencēs, rakstīt grāmatas. No otras puses – IT joma ir tik mainīga, ka jau pēc gada būs jaunas tehnoloģijas, tāpēc, lai tu joprojām būtu labs sistēmu arhitekts un spētu noturēt savas pozīcijas, tev visu laiku sevi jāpierāda un jāattīstās.

Vēl viens no karjeras virzības ceļiem ir strādāt ar aizvien lielākiem projektiem, vai darboties starptautiskā mērogā. Sasniedzot eksperta līmeni, vari kļūt par pašnodarbinātu konsultantu, kuru uzņēmumi piesaista uz projektu plānošanas posmiem.

Ko Jūs ieteiktu jauniešiem, kuri gribētu apgūt šo profesiju?

Šī profesija prasa zināmu briedumu, gan darba, gan dzīves pieredzi. Ļoti reti kurš strādā par IT arhitektu uzreiz pēc augstskolas pabeigšanas. Parasti vispirms iegūst programmētāja vai sistēmanalītiķa pieredzi. Taču jau skolas laikā var pievērst vairāk uzmanības matemātikai, informātikai, loģikai, arī fizikai. Noteikti vajag mēģināt programmēt. Nelielai programmiņai nav vajadzīga arhitektūra. Uzrakstot 3-5 tūkstošu rindiņu garu programmu, parasti jau var sajust, kādas problēmas rodas, pieaugot programmas apjomam. Šādas problēmas risina ar pārdomātu risinājuma arhitektūru. Pamēģiniet uzprogrammēt datorspēli. Tas būs gan pietiekami interesanti, gan pietiekami apjomīgi.

Iesaistieties programmētāju forumos un atvērtā koda projektos, pievēršot uzmanību sistēmu arhitektūras jautājumiem. Lasiet atbistošas tematikas grāmatas.