Migliore risposta
Non ci sono definizioni formali di questi ruoli che sono ampiamente adottate come standard da organizzazioni, quindi ci saranno molte variazioni e un contesto localizzato.
Come guida generale, utilizzo le seguenti definizioni:
- Architetto tecnico – Uno specialista in aree allineate infrastruttura, networking e sicurezza.
- Solution Architect – Un generalista responsabile di soluzioni basate su progetti che tengono conto di tutti gli aspetti di una soluzione (ad es. impatto aziendale, modifiche alle applicazioni, considerazioni su dati e informazioni e sulla tecnologia che è alla base di tutto ciò) e, si spera, anche le considerazioni dei clienti.
- Architetto principale: qualcuno con una serie di responsabilità più ampia rispetto ai ruoli di cui sopra. Questo potrebbe essere focalizzato su un dominio aziendale, un programma di lavoro più ampio o lintera azienda. Viene spesso utilizzato anche dalle società di consulenza per suggerire un livello di (esperienza) superiorità rispetto ad altri architetti del team. Normalmente avranno preoccupazioni generaliste piuttosto che concentrarsi su un singolo dominio dellarchitettura come linfrastruttura, ma non è sempre così.
Spero che questo aiuti. È importante ricordare che ci sono nessuno standard accettato, quindi i termini stessi sono specifici dellambiente in cui vengono utilizzati.
Risposta
In primo luogo, è importante differenziare larchitettura del software dalle semplici best practice. Un buon ingegnere del software può essere eccellente nella programmazione, eccellente e dettagliato nel suo approccio e avere una grande conoscenza del problema, ma potrebbe non essere un buon architetto.
Come minimo, un buon larchitetto dovrebbe avere le seguenti capacità:
Un architetto è eccellente nella scomposizione dei problemi . La scomposizione del problema è labilità necessaria per vedere un problema praticamente a qualsiasi livello e scomporlo nei passaggi e nei pezzi necessari per implementarlo. Un buon progettista di software può accettare una dichiarazione del tipo “I nostri sistemi di controllo del traffico aereo sono inadeguati e abbiamo bisogno di un design migliore” e conosce le domande da porre per iniziare a scomporre il problema in componenti realizzabili, per scomporre gli obiettivi dei componenti in sottoprogetti realizzabili e scomporre questi sottoprogetti in attività di programmazione realizzabili. Un buon architetto può fare queste cose a qualsiasi livello o scala, dallimmaginare un progetto software di un miliardo di linee alla comprensione del modo migliore per implementare un algoritmo per far fronte a collegamenti inaffidabili. La scala è irrilevante perché il processo è sempre lo stesso.
Un architetto comprende le interfacce . Le interfacce, sotto forma di protocolli, librerie di funzioni, interfacce di classe o schemi, sono lo strumento principale necessario per gestire la complessità dei progetti quando sono presenti appaltatori e implementatori indipendenti. Conoscendo il processo di definizione di interfacce chiare e inequivocabili che sono logicamente complete, un architetto può consentire a molte persone di costruire parti di sistemi che si connettono facilmente per raggiungere un obiettivo più ampio.
Un architetto capisce che la complessità è il nemico e possiede una padronanza degli strumenti e dei paradigmi di programmazione necessari per ridurre la complessità in tutti i componenti, per ridurre la complessità delle interfacce e assicurare ridondanza minima o nulla di implementazione di funzione. Sono in grado di riconoscere rapidamente algoritmi e implementazioni troppo specifici o troppo generici e guidare coloro che sviluppano a creare componenti che eseguono la giusta funzione. Spesso, gli strumenti per gestire la complessità sono cose come nascondere i dati, programmazione orientata agli oggetti, sistemi di auto-convalida e piani di test completi per interfacce standard. Ma un buon architetto non è dogmatico riguardo a strumenti e tecnologie perché ha una comprensione accademica completa delle basi e dei motivi per cui loccultamento dei dati funziona e perché alcuni linguaggi supportano buoni principi di progettazione e altri no.
An larchitetto è un buon comunicatore, un bravo e prolifico scrittore e documentatore , ed è bravo a parlare il linguaggio di programmazione così come il linguaggio comune di coloro che sono stakeholder nella progettazione del sistema. Insieme a una buona comunicazione, un buon architetto può fornire ragioni concrete per le pratiche di programmazione piuttosto che le opinioni e offre intuizioni al proprio team piuttosto che argomentazioni. Favoriscono fortemente e cercano lopinione dellutente sullidoneità a quello dei propri o dei programmatori coinvolti nel progetto.
Un buon architetto è un buon leader ed è eccellente nel guadagnarsi il rispetto di tutti i tecnici lavorano con .Di solito questo significa che hanno un alto livello di abilità, hanno lavorato in più lingue e sono stati già architetti o hanno dimostrato la loro capacità di creare progetti di sistemi che sono rimasti flessibili di fronte al cambiamento.
Molte definizioni includono una serie di parole dordine, che enfatizzano metodologie come la progettazione basata sui dati, la programmazione agile, linguaggi, piattaforme e toolkit specifici .. Queste cose sono etichette correnti per varie tecniche le cui basi devono essere ben comprese, non accettate perché sono attualmente in voga. Quindi, in molti modi, le capacità principali di un architetto sono lesperienza, lintelligenza, la volontà di lavorare sodo e assumere un ruolo pratico, una buona intuizione e la capacità di abbattere i problemi usando la logica in modo che, come le parole dordine del settore vanno e vengono, i loro progetti rimangono utili e pertinenti.
La mia definizione sopra intenzionalmente non include la gestione del progetto, la pianificazione e le capacità di gestione. Il ruolo dellarchitetto è creare buoni sistemi, non risolvere problemi o budget del team. In effetti, è meglio se coloro che hanno budget e problemi del team sono semplicemente stakeholder che aiutano a definire uno dei vincoli che larchitetto deve affrontare, proprio come se fosse parte del loro problema di progettazione.