Arhitectura software are un rol foarte important în producerea sistemelor software de succes, însă, cu toate acestea, este neglijată de multe echipe. Rolul de architect software există în fiecare echipă, dar cu toate acestea, în majoritatea cazurilor, "arhitectura" reflectă mai mult un ideal decât realitatea. Multe echipe consideră că nu am nevoie de arhitecți software, deoarece se pot autoorganiza (self-organize), folosindu-se de sintagme de genul "YAGNI", "evolutionary-architecure", "emergent-design".
În industria IT termenul "architecture" are multe înțelesuri pentru multe persoane, existând multe definiții pentru ceea ce presupune. Iată câteva exemple: "software design", "the big picture", "plan", "technical direction", "foundations", "abstract view", "non-functional requirements", "standards and goals", etc. . Adevărul este că nu există o singură definiție validă și cuprinzătoare, existând astfel mai multe tipuri de arhitecturi: "application architecture", "software architecture", "it architecture", "platform architecture", "infrastructure application", etc. Ce au toate acestea în comun: Structură și Viziune.
La o prima vedere, noțiunea de "software architecture" ar putea fi definită ca arhitectura produsului software. Dar exista mult mai multe aspecte de luat în calcul pe lângă partea software.
Acesta este termenul cel mai des utilizat de către programatori, deoarece aceștia creează aplicații (desktop, web, mobile, etc). Deci, în acest context, arhitectura reprezintă suma alegerilor cu care va fi construit produsul: limbaje de programare, tehnologiile alese, framework-uri, librarii, API-uri, etc.
Noțiunea de System Architecture este cu un nivel mai complexă, gândindu-ne la un sistem software ca fiind compus din mai multe aplicații. Am putea avea o interfață sub forma unei aplicații web, ce are legătură cu un serviciu back-end, care la rândul său are acces la un DB server/sistem. Bineînțeles, toate aceste aplicații rulează pe un suport hardware. Am putea defini în acest context system architecture ca fiind un amestec de software și hardware.
Acestea fiind spuse, combinația System Architecture și Application Architecture ne dă ca rezultat Software Architecture. Însă nu este vorba doar despre software, nu e așa?
Arhitectura și designul sunt doi termeni des utilizați pentru a exprima același lucru. Într-adevăr au unele lucruri în comun, dar nu înseamnă același lucru. După cum a spus și Grady Booch: : "All architecture is design but not all design is architecture." - Orice arhitectură este un design, dar nu și orice design este o arhitectură. Ceea ce au totuși in comun este procesul de a lua decizii. De fiecare dată când creăm un design sau o arhitectură, luăm o decizie. Investigăm ce platformă să folosim, ce librării, etc. .
Diferența cheie între aceste decizii este "costul" modificării - cât ne costă să modificăm aspecte în deciziile luate. O decizie arhitecturală este mai importantă decât una de design. Și cum măsurăm importanța unei decizii? Prin totalitatea resurselor alocate: timp și programatori alocați.
Să luăm de exemplu decizia de a scrie o aplicație web în ASP .NET MVC. Care ar fi costul portării acesteia la AngularJS? Bineînțeles că ar dura săptămâni, depinzând de progresul curent al aplicației. Deci aceasta este o decizie arhitecturală.
Dar decizia de a alege între două mecanisme de logging ? Alegem sistemul de log Microsoft Events și apoi vrem să trecem la NLog sau log4Net. Bineînțeles că această modificare poate fi ușor făcută într-o singură zi.
În esență, toate deciziile semnificative sunt "architecture", iar restul sunt "design". Deciziile arhitecturale sunt cele care nu pot fi schimbate într-o singură zi.
Am vorbit despre arhitectură software, dar nu și despre rolul în sine. În primul rând, rolul de arhitect software nu este un titlu într-o companie. Este un rol. Arhitecții software nu trăiesc izolați în turnuri de fildeș. A fi un arhitect software presupune a avea atât aptitudini tehnice, cât și capacitatea de a relaționa cu restul echipei (technical and soft skills). Un arhitect software introduce control, structură și viziune. De asemenea, ei ar trebui să programeze și să colaboreze cu membrii echipei din care fac parte. Iată un număr de aptitudini de care are nevoie un bun arhitect software: leadership, comunicare, negociere, colaborare, coaching și mentoring, etc. .
Cum creăm o arhitectură? De ce unelte avem nevoie? Alegerile sunt multe, dar nu avem nevoie neapărat de un editor pentru diagrame UML. Putem desena diagrame pe table și pe hârtie. Ideea este în esență de a avea un design colaborativ (collaborative design). Aduceți-vă aminte că arhitectura are rolul de a introduce structură și viziune. Vă prezentăm mai jos un număr de exemple cărora le lipsesc aceste două componente:
"The airliner"
"The Eh?"
Este foarte dificil de reprezentat un sistem întreg într-o singură diagramă. Sistemele din prezent sunt foarte complexe, prezentând multe puncte de vedere. O arhitectură deșteaptă prezintă diferite viziuni ce subliniază varii aspecte ale soluției. Încercați să vă imaginați o fotografie panoramică la o rezoluție foarte mare. Daca vreți să observați detaliile, trebui să faceți zoom in. Nu există posibilitatea de a vedea toate detaliile din cel mai înalt punct de observație.
Acesta nu este un set de reguli, ci mai mult niște sugestii ce au fost introduse de Simon Brown în cartea sa "Coding the Architecture". Este modelul "C4": Context, Containers, Components and Classes. Pe măsura ce mărim "imaginea", descoperim mai multe detalii și aspecte ale soluției.
Descrie imaginea de ansamblu (the big picture). Care sunt "actorii", cine folosește sistemul și care sunt părțile componente. Acest tip de diagramă poate fi prezentat persoanelor non-tehnice, cum ar fi managementul superior, având expectanța de a putea fi înțeles de acest grup de persoane.
În esență, orice poate conține cod sau date este un container. O aplicație web, o aplicație desktop, DB, sistemul de fișiere, etc. pot fi considerate containers. Aici am putea reprezenta tehnologiile high-level alese și felul în care acestea comunică.
Diagrama de componente prezintă tehnologiile high-level alese, interacțiunea între module și alte servicii.
Întrebarea principală pe care ar trebui să ne-o adresăm este: "voi dezvolta (scrie cod) în acest fel?" Acesta este un aspect foarte important deoarece în multe cazuri arhitectura este privită mai mult ca un ideal, decât ca modul în care va arăta sistemul.
Cât este destul din punctul de vedere al unei arhitecturi? Bineînțeles că nu putem reprezenta întreg sistemul de la început, nefiind indicat deoarece sistemele noi se schimbă des. În acest context, răspunsul este: destul design pentru a introduce structură și pentru a crea o viziune împărtășită de întreaga echipă. Identificați riscurile cheie și prezentați o viziune pentru a merge mai departe.
Încercați să creați puțină arhitectură decât deloc sau toată odată. Fiți mai degrabă pragmatici decât perfecționiști. Creați documente scurte și concise pentru arhitectura voastră, în loc de enciclopedii mari ce nu sunt actualizate și sunt greu de gestionat și citit.
Alegeți mereu simplitatea în detrimentul soluțiilor complexe și "prea arhitecturale".
de Ovidiu Mățan
de Vlad But
de Maria Revnic
de Delia Mircea
