Cel mai bun răspuns
Nu există definiții formale ale acestor roluri care sunt adoptate pe scară largă ca standard de către organizații, deci va exista o mulțime de variații și context localizat.
Ca ghid general, folosesc următoarele definiții:
- Arhitect tehnic – specialist în domenii aliniate la infrastructură, rețea și securitate.
- Arhitect de soluții – Un generalist responsabil pentru soluțiile bazate pe proiecte care iau în considerare toate aspectele unei soluții (de exemplu, impactul afacerii, modificările aplicațiilor, considerațiile de date și informații și tehnologia care susține toate acestea) și, sperăm, și considerațiile clienților.
- Arhitect principal – Cineva cu un set de responsabilități mai larg decât rolurile de mai sus. Acest lucru se poate concentra pe un domeniu de afaceri, pe un program de lucru mai mare sau pe o întreprindere întreagă. De asemenea, este adesea folosit de consultanțe pentru a sugera un nivel de (experiență) superioritate față de alți arhitecți din echipă. În mod normal, aceștia vor avea preocupări generaliste, mai degrabă decât concentrate pe un singur domeniu de arhitectură, cum ar fi infrastructura, dar nu este întotdeauna cazul.
Sper că acest lucru vă va ajuta. nu există standarde acceptate, astfel încât termenii înșiși sunt specifici mediului în care sunt utilizați.
Răspuns
În primul rând, este important să diferențiem arhitectura software de cele mai bune practici. Un inginer software bun poate fi excelent în codificare, excelent și detaliat în abordarea lor și poate avea o perspectivă foarte mare asupra problemei, dar totuși poate să nu fie un bun arhitect.
Cel puțin un bun arhitectul ar trebui să aibă următoarele abilități:
Un arhitect este excelent la descompunerea problemei . Descompunerea problemei este abilitatea necesară pentru a vedea o problemă la practic orice nivel și a o împărți în pașii și piesele necesare pentru a o implementa. Un bun arhitect software poate lua o afirmație de genul „Sistemele noastre de control al traficului aerian sunt inadecvate și avem nevoie de un design mai bun” și știe întrebările pe care trebuie să le punem pentru a începe să descompunem problema în componente realizabile, pentru a descompune aceste obiective componente în sub-proiecte realizabile și descompune aceste subproiecte în sarcini de programare realizabile. Un arhitect bun poate face aceste lucruri la orice nivel sau scară, de la conceperea unui proiect software de miliarde de linii până la înțelegerea celei mai bune modalități de implementare a unui algoritm pentru a face față legăturilor nesigure. Scala nu este relevantă, deoarece procesul este întotdeauna același.
Un arhitect înțelege interfețele . Interfețele, fie sub formă de protocoale, biblioteci de funcții, interfețe de clasă sau scheme sunt instrumentul principal necesar pentru a gestiona complexitatea proiectelor atunci când există contractori și implementatori independenți. Cunoscând procesul de definire a interfețelor clare și lipsite de ambiguitate, care sunt complet logice, un arhitect poate împuternici multe persoane să construiască piese de sisteme care se conectează ușor pentru a atinge un obiectiv mai mare.
Un arhitect „> înțelege că complexitatea este inamicul și are o stăpânire a instrumentelor de programare și a paradigmelor necesare pentru a reduce complexitatea tuturor componentelor, pentru a reduce complexitatea interfețelor și pentru a asigura o redundanță minimă sau deloc a implementării de funcție. Ei pot recunoaște rapid algoritmi și implementări care sunt prea specifice sau prea generice și îi pot ghida pe cei care se dezvoltă pentru a crea componente care îndeplinesc doar funcția potrivită. Adesea, instrumentele de gestionare a complexității sunt lucruri precum ascunderea datelor, programarea orientată pe obiecte, sistemele de auto-validare și planurile de testare cuprinzătoare pentru interfețele standard. Însă, un bun arhitect nu este dogmatic în ceea ce privește instrumentele și tehnologiile, deoarece au o înțelegere academică cuprinzătoare a bazelor și a motivelor pentru care funcționează ascunderea datelor și de ce anumite limbaje acceptă principii de proiectare bune, iar altele nu.
arhitectul este un bun comunicator, un scriitor și documentar bun și prolific și este bun la vorbirea limbajului de programare, precum și a limbajului comun al celor care sunt părți interesate în proiectarea sistemului. Împreună cu o bună comunicare, un bun arhitect poate oferi motive concrete pentru practicile de programare, mai degrabă decât pentru opinii, și oferă o perspectivă echipei lor mai degrabă decât argumentare. Ei favorizează și caută cu părere opinia utilizatorului despre adecvarea la cel al lor sau al programatorilor implicați în proiect.
Un bun arhitect este un bun lider și este excelent pentru a câștiga respectul tuturor oamenilor tehnici lucrează cu .De obicei, acest lucru înseamnă că au un nivel ridicat de abilități, au lucrat în mai multe limbi și au fost arhitect anterior sau și-au demonstrat capacitatea de a crea proiecte de sisteme care au rămas flexibile în fața schimbărilor.
Multe definiții includ o serie de cuvinte cheie, subliniind metodologii cum ar fi proiectarea bazată pe date, programarea agilă, limbaje specifice, platforme și seturi de instrumente. Aceste lucruri sunt etichete actuale pentru diverse tehnici a căror bază trebuie să fie bine înțeleasă, nu sunt acceptate deoarece sunt în prezent la modă. Deci, în multe feluri, abilitățile principale ale unui arhitect sunt experiența, inteligența, dorința de a lucra din greu și de a lua un rol practic, o bună intuiție și abilitatea de a descompune problemele folosind logica, astfel încât, pe măsură ce cuvintele cheie ale industriei vin și pleacă, proiectele lor rămân utile și relevante.
Definiția mea de mai sus nu include intenționat managementul proiectelor, programarea și abilitățile de management. Rolul arhitectului este de a crea sisteme bune, nu de a rezolva problemele echipei sau bugetele. De fapt, cel mai bine este ca cei cu bugete și probleme de echipă să fie pur și simplu părți interesate care ajută la definirea uneia dintre constrângerile pe care arhitectul trebuie să le facă față, la fel ca dacă ar face parte din problema lor de proiectare.