Architettura

Negli ambienti in locale, i clienti spesso hanno un team centrale per l'architettura delle tecnologie che funziona da livello superiore per altri team di prodotto o funzionalità, al fine di garantire che i team rispettino le best practice. I team dell'architettura delle tecnologie spesso sono composti da diversi ruoli come il Technical Architect (infrastruttura), il Solutions Architect (software), il Data Architect, il Networking Architect e il Security Architect. Spesso i team usano TOGAF o il Framework di Zachman come parte delle competenze architetturali aziendali.

Noi di AWS, preferiamo distribuire le competenze tra i team, invece di centralizzarle in un unico team. Quando si sceglie di distribuire il potere decisionale si corrono dei rischi, ad esempio il rischio di garantire che i team interni rispettino gli standard. Noi mitighiamo questo rischi in due modi. Innanzitutto, abbiamo le pratiche« [ Modalità per eseguire attività, processi, standard e norme accettate. ] »  che hanno lo scopo di permettere a ogni team di possedere tali competenze e ci serviamo di esperti che garantiscano che i team adottino standard più severi di quelli che devono rispettare. In secondo luogo, implementiamo meccanismi« [ Le buone intenzioni non bastano mai, per avere successo servono buoni meccanismi Jeff Bezos. Questo significa sostituire gli sforzi umani con meccanismi (spesso automatizzati) che verificano la conformità alle regole e ai processi. ] »  che eseguono controlli automatizzati per garantire che gli standard vengano rispettati. L'approccio distribuito è supportato dai principi di leadership di Amazon, e stabilisce una cultura tra tutti i ruoli che lavorano a ritroso« [ Il lavoro a ritroso è una parte fondamentale del nostro processo di innovazione. Partiamo dal cliente e da quello che vuole e sulla base di questo definiamo e indirizziamo i nostri sforzi. ] »  a partire dalle necessità del cliente. I team che mettono il cliente al centro sviluppano prodotti sulla base delle necessità del cliente.

Per l'architettura questo significa che ci aspettiamo che ogni team sia in grado di creare architetture e di seguire le best practice. Per aiutare i nuovi team ad acquisire queste competenze o i team esistenti ad alzare il livello, abilitiamo l'accesso a una community virtuale di ingegneri responsabili che possono eseguire la revisione dei loro progetti e aiutarli a comprendere le best practice di AWS. La community di ingegneri responsabili lavora per rendere visibili e accessibili le best practice. Uno dei modi per fare ciò, ad esempio, è servirsi delle lunchtime talk che si concentrano sull'applicazione di best practice a esempi reali. Le lunchtime talk sono registrate e possono essere utilizzate come materiale di onboarding per i nuovi membri del team.

Le best practice AWS sono il risultato della nostra esperienza nell'esecuzione di migliaia di sistemi su Internet. Preferiamo utilizzare i dati per definire le best practice, ma ci serviamo anche di esperti in materia come ingegneri responsabili per stabilire le best practice. Quando gli ingegneri responsabili vedono emergere nuove best practice lavorano con la community per garantire che i team le rispettino. Con il tempo, queste best practice vengono formalizzate nei nostri processi di revisione interna e nei meccanismi che rafforzano la compliance. Well-Architected è l'implementazione del nostro processo di revisione interno rivolta ai clienti, in cui abbiamo codificato la nostra idea di ingegneria responsabile attraverso ruoli di campo come Solutions Architecture e i team di ingegneria interni. Well-Architected è un meccanismo scalabile che ti permette di sfruttare queste nozioni.

Seguendo l'approccio della community di ingegneri responsabili con la proprietà distribuita dell'architettura, riteniamo che si possa ottenere un'architettura aziendale Well-Architected che si basa sulle necessità del cliente. I leader della tecnologia (come i CTO o i manager dello sviluppo) che eseguono revisioni Well-Architected tra tutti i carichi di lavoro ti permettono di comprendere più a fondo i rischi relativi al portfolio delle tecnologie. Tramite questo approccio puoi identificare dei temi tra i team che la tua organizzazione può affrontare tramite meccanismi, formazione o lunchtime talks in cui gli ingegneri responsabili possono condividere le loro idee su aree specifiche con diversi team.