Am stat de vorbă cu Mark Richards despre fundamentele meseriei de arhitect software și direcțiile de dezvoltare ale acesteia. Mark va fi speaker la ce de-a treia ediție a conferinței The Developers, 17 iunie, online.
Ovidiu Mățan: Ultima dumneavoastră carte, Fundamentals of Software Architecture, prezintă punctele esențiale ale paradigmei pe care ar trebui să o adopte arhitecții software. Care este drumul pe care ar trebui să îl parcurgă o persoană care dorește să devină arhitect software?
Mark Richards: Sfatul pe care îl dau de obicei persoanelor care doresc să devină arhitecți software este să se asigure că sunt pregătiți pentru acest rol înainte de accepta rolul. Ca să devii arhitect software ai nevoie nu doar de abilități tehnice foarte bune. Un arhitect trebuie să fie pasionat de găsirea de soluții pentru problemele de business, de dezvoltarea abilităților oamenilor și de dorința de a fi mentor, coach și leader al acelor echipe.
Tradițional vorbind, puteți deveni arhitecți software dacă sunteți programatori, apoi deveniți manageri tehnici și ulterior arhitecți. Vă puteți pregăti pentru poziția de arhitect dacă vă axați pe lărgirea setului de domenii tehnice cunoscute, în loc de a vă specializa tehnic pe un singur domeniu. Acest lucru înseamnă să stăpâniți mai multe domenii în loc de a vă specializa pe un domeniu anume. O altă modalitate de a vă pregăti este să începeți să vă concentrați pe identificarea și analiza compromisurilor, dar și pe învățarea diverselor stiluri de arhitecturi cu avantajele și dezavantajele fiecărui stil. Finalmente, dezvoltați-vă abilitățile de interacțiune cu oamenii - de acestea veți avea nevoie în 50% din munca voastră de arhitect.
Ultima mea carte, scrisă împreună cu Neal Ford, The Fundamentals of Software Architecture, are trei părți. Prima parte are în vedere modurile în care putem învăța să gândim ca un arhitect. Partea a doua se referă la aspectele tehnice ale arhitecturii software, iar partea a treia vorbește despre tehnicile și abilitățile soft de care aveți nevoie. Toate aceste trei aspecte sunt necesare pentru a deveni un arhitect software eficient.
Care sunt punctele forte ale unui arhitect bun?
Mark Richards: Primul punct forte este capacitatea de a analiza compromisurile, de a lua deciziile de arhitectură potrivite pentru o situație anume. A avea abilități bune de analiză a compromisurilor (tradeoff analysis) îi ajută pe arhitecți să justifice o decizie de arhitectură sau o soluție, astfel obținând suportul factorilor decizionali.
Al doilea punct forte este reprezentat de negociere și facilitare/intermediere. Aproape fiecare decizie pe care o ia un arhitect va fi pusă sub semnul întrebării - deciziile vor fi schimbate de alți arhitecți care cred că au o abordare mai bună; vor fi puse sub semnul întrebării de programatorii care nu sunt de acord cu arhitecții; vor fi puse sub semnul întrebării de factorii decizionali care nu doresc să investească timp și bani într-o soluție anume. O bună înțelegere a climatului politic din organizație și navigarea acestor politici sunt factori cheie pentru a duce la bun sfârșit sarcinile de lucru zilnice ca arhitect.
Al treilea punct forte presupune abilități interpersonale puternice care vă vor permite să conduceți și să ghidați echipele în procesul de implementare a unei arhitecturi. Echipele de dezvoltare vor veni la arhitect cu întrebări, vor aștepta ca acesta să fie lider și să ofere sfaturi, cu precădere pentru problemele dificile care sunt parte a tuturor inițiativelor și a eforturilor tehnice. Pentru a deveni un arhitect software de succes trebuie să știi să comunici și să colaborezi cu echipele de dezvoltare, factorii decizionali și cu personalul IT.
Microserviciile și conceptul serverless au schimbat modul în care dezvoltăm software în zilele noastre. Cu ce ar mai trebui să ne familiarizăm?
Mark Richards: Cu toate că microserviciile și serverless sunt două concepte populare, companiile se orientează momentan spre arhitectură ghidată de evenimente (event-driven architecture), acesta fiind următoarea tendință. Deși conceptul de arhitectură ghidată de evenimente nu este nou (există de ceva vreme), din ce în ce mai mulți oameni îl folosesc pentru problemele complexe din orizontul tehnic de azi: sisteme reactive, fluxuri de lucru dinamice (dynamic workflows) sau procesare non-deterministă complexă (non-deterministic processing). S-au scris recent multe cărți despre sistemele bazate pe evenimente, iar furnizorii de cloud au adoptat arhitectura bazată pe evenimente pentru a crea servicii noi, inovatoare. Cred că va fi noul val în industria IT.
Prezentarea de la conferința The Developers din acest an este Understanding Architecture Styles - And when to use them. La ce ar trebui să se aștepte publicul?
Mark Richards: A implementa un stil arhitectural potrivit este un lucru esențial pentru succesul oricărei aplicații. Întrebările sunt : Care este arhitectura potrivită? Cea stratificată (Layered)? Cea bazată pe microservicii? Cea bazată pe evenimente? SBA? Cea bazată pe monoliți modulari?
În prezentarea mea voi vorbi despre opt stiluri diferite de arhitectură software. Voi prezenta punctele forte și punctele slabe ale fiecăreia și voi explica cum să le folosim pe fiecare. Voi vorbi despre stilurile de arhitectură monolitice precum Layered, Modular Monolith, Microkernel, dar și despre arhitecturile distribuite precum Microservices, Service-Based, Event-Driven, SOA, SBA. Voi oferi o privire de ansamblu pentru fiecare stil de arhitectură și voi vorbi despre situațiile când putem folosi sau nu fiecare dintre aceste stiluri.
Prezentarea vă va ajuta să înțelegeți nu doar cum să selectați arhitectura potrivită pentru aplicațiile noi, dar și cum să validați aplicațiile existente pentru a evalua dacă folosiți arhitectura corectă. Dacă nu folosiți arhitectura potrivită, veți putea să înțelegeți ce stil de arhitectură (sau ce stiluri) ar fi potrivite pentru a asigura succesul aplicației voastre.
de Dan Sabadis
de Sorin Stan
de Ovidiu Mățan
de Ovidiu Mățan
