În Cariere

De la Software Developer la Software Architect: provocări şi recomandări

software-architect-cariera

După câţiva ani petrecuţi în industria de software development este normal să începi să te gândeşti la paşii următori. Poate doreşti o poziţie de conducere, un rol similar cu al managerului tău, în care să coordonezi şi să iei deciziile importante din cadrul proiectului. Sau poate vrei o carieră de Software Architect pentru că vrei să fii persoana responsabilă de alegerea soluţiilor tehnice din proiect.

Ca să nu mai vorbesc de nenumăratele provocări tehnice pe care vei avea ocazia să le întâlneşti.

De fapt, nici una din aceste două perspective nu este întocmai corectă deoarece Project Managerul nu decide absolut totul în cadrul proiectului şi nici Arhitectul nu poate impune întru totul framework-urile sau soluţiile tehnice. Sunt criterii naive şi superficiale la care unii developeri ar putea să apeleze atunci când se gândesc la următorul pas în carieră.

 

Ca atare m-am decis ca în acest articol să împărtăşesc experienţa şi provocările mele, din momentul în care am făcut tranziţia de la Technical Lead la Software Architect. Sper ca aceste informaţii să vă fie utile atunci când aveţi de luat o decizie similară legată de viitorul carierei voastre.

 

În cazul meu, alegerea a fost simplă deoarece nu îmi doream să devin Project Manager. Voiam să rămân în contact cu tehnologia şi îmi doream să pot scrie cod în continuare. Acest lucru probabil că avea legătură cu trecutul şi experienţa mea, deoarece am petrecut mulţi ani programând şi mă simt foarte bine atunci când fac asta. Însă în noul meu rol ca Arhitect s-au schimbat câteva lucruri.

 

În primul rând a trebuit să schimb paradigma în care mă aflam:  să trec de la perspectiva unui programator, unde majoritatea timpului scriam cod, la una de ansamblu, unde trebuia să fiu capabil să gândesc la un nivel abstract întreaga soluţie, incluzând componentele tehnice, modul în care relaţionează şi mediul în care vor funcţiona.

De asemenea trebuia să iau în considerare şi atributele lor de calitate (e.g. specificaţiile nefuncţionale) pentru a mă asigura că întregul sistem satisface nevoile stakeholderilor.

 

Mai jos am descris câteva din diferenţele importante între rolul de Software Architect şi cel de Software Developer:

 

 

  • Ca Arhitect trebuie să ai sau să începi să îţi dezvolţi abilităţi de comunicare

Te vei afla mereu în situaţii în care trebuie să interacţionezi şi să discuţi cu oamenii cheie din proiect (project managers, reprezentanţi ai clientului, business analysts, quality engineers, developeri, utilizatori etc.) legat de nevoia de a investi în anumite tehnologii sau de a face achiziţii noi (training-uri, licenţe software, echipamente noi).

 

Ca Arhitect va trebui să discuţi şi cu persoane cheie din proiect care au experienţă tehnică pentru a-ţi prezenta viziunea si ideile legate de evoluţia acestuia.

 

Ca Software Developer abilităţile de comunicare nu sunt atât de importante. Sunt foarte mulţi programatori buni cărora le lipsesc aceste abilităţi sau care preferă să se dedice în totalitate scrierii de cod.

 

 

  • Ca Arhitect trebuie să te concentrezi pe a-ţi dezvolta ceea ce se numeşte “technical breadth”

Cu alte cuvinte trebuie să fii la curent cu cât mai multe tehnologii şi framework-uri, pentru a avea o paletă cât mai largă din care să alegi. Acest lucru îţi oferă flexibilitatea necesară de care ai nevoie atunci când ai o problemă specifică, pentru că ai acces la mai multe posibilităţi de analiză şi design al arhitecturii.

 

Însă un Arhitect nu ar trebui să studieze aceste tehnologii în detaliu, deoarece necesită timp şi este greu să menţii un nivel ridicat de know-how pe termen lung. Dar trebuie să ştii ce există pe piaţă.

 

În comparaţie, un Software Developer este interesat în principal de îmbunătăţirea şi menţinerea “technical depth”, a expertizei sale în câteva limbaje de programare pentru a scrie cod mai eficient.

 

 

  • Un Arhitect nu trebuie să renunţe la programare

Acest lucru te ajuta să rămâi la curent cu noutăţile din domeniu şi doar aşa poţi să rămâi aproape de programatori şi să le înţelegi mai bine provocările.

 

Dar iată care este diferenţa. În cazul unui Developer, procentajul de timp dedicat programării tinde să fie maxim, în timp ce pentru un Arhitect aş spune că mai degrabă 25% – 30% ar trebuie să fie dedicat programării.

 

Restul timpului este ocupat cu activităţi precum dezvoltarea şi menţinerea diagramelor arhitecturale (criterii şi pattern-uri de programare), implementarea proof of concepts pe baza cerinţelor architecturale cu impact major, dezvoltarea şi menţinerea unui technology radar (e.g. matrice a technologiilor) în cadrul proiectului, revizuirea codului şi actualizarea documentaţiei tehnice.

 

Cu alte cuvinte Arhitectul trebuie să asigure integritatea şi corectitudinea proiectului.

 

  • Project Management

Există şi anumite activităţi care sunt mai apropiate de project management, precum analiza de cost şi risc.

Un Arhitect trebuie să fie implicat în dezvoltarea planului de management al riscului, pentru a identifica eventualele probleme, atât din punct de vedere tehnic cât şi din punct de vedere organizaţional.

Din moment ce costul este un factor cheie în toate proiectele, Arhitectul trebuie să fie capabil să găsească un echilibru între valoarea adăugată a soluţiilor pe care le propune şi costul total al acestora, pentru a lua cele mai bune decizii tehnice.

În cazul unui Software Developer, aceste activităţi l-ar distrage de la sarcinile sale.

 

 

  • Un Arhitect nu ar trebui să impună framework-uri şi nici nu ar trebui să gândească plecând de la o tehnologie

Toate acestea sunt doar instrumente sau opţiuni care modelează arhitectura. Un Arhitect bun ar trebui să găsească o cale prin care anumite tehnologii apar ca soluţii în urma unei analize profunde, nu invers.

 

Un Arhitect ar trebui să fie interesat în mare parte de calitatea internă a proiectului, calităţile sistemice (performanţă, scalabilitate, disponibilitate, securitate etc.) şi nu de aspecte auxiliare precum instrumente sau framework-uri.

 

S-ar putea să te afli în situaţia în care să amâni anumite decizii pentru mai târziu în derularea proiectului (e.g. project lifecycle), deoarece ulterior este mereu mai bine din moment ce există mai multe informaţii contextuale pentru a lua deciziile potrivite.

 

 

  • Un Arhitect trebuie să contribuie şi la metodologia de dezvoltare a proiectului

Trebuie să fie implicat şi să monitorizeze ce merge bine şi ce ar putea fi îmbunătăţit. Spre exemplu, dacă metodologia “waterfall” nu este eficientă, Arhitectul poate să sugereze schimbarea sa. Sau dacă strategia continuous deployment nu creşte viteza de livrare, Arhitectul poate să sugereze o alternativă.

 

În concluzie, un Arhitect trebuie să aibă viziune, să fie la curent cu cele mai noi tehnologii şi framework-uri, să propună noi idei atunci când este nevoie şi să fie capabil să comunice eficient cu toate persoanele implicate în proiect.

 

Sper ca informaţiile oferite vă pot ajuta să luaţi o decizie raţională în legătură cu următorul pas din cariera voastră.


Ionut-Balosin-Thumb

 

Ionuţ Balosin

Software Architect @Luxoft Training