Larchitettura IT è importante. Lascia che ti dica perché

Adoriamo disegnare !!

(Miguel Angel Coll) (2 luglio 2020)

Ho investito gli ultimi 5 anni nella mia carriera lavorando intorno alla funzione di architettura IT. In tutti questi anni ho dovuto giustificare anche a me stesso la mera esistenza della funzione Architettura. A volte ci sentiamo anche come degli intrusi circondati dalle persone che fanno davvero il lavoro (sviluppatori e sys-op).

Dopo 5 anni sono ancora convinto che larchitettura sia importante, lascia che ti dia alcuni argomenti per dimostralo.

Miglior rapporto qualità-prezzo

Se devo scegliere una sola missione per larchitettura IT, sceglierò questa. I reparti e le piattaforme IT sono in genere solo in crescita. Alcuni perché lazienda sta crescendo, altri perché lazienda è nel mezzo di una trasformazione digitale. In ogni caso, il risultato è lo stesso, anno dopo anno hai più sistemi, più team, più complessità.

Mi piace semplificare eccessivamente una piattaforma IT come segue:

La funzione principale dellArchitettura è mantenere la relazione con il Il costo della piattaforma IT e il valore che offre in buone condizioni.

Qualche tempo fa ho lavorato in una società di viaggi con un modello di business basato sulla distribuzione di prodotti online tramite API. Queste API erano fortemente accoppiate con un enorme sistema monolite basato su Oracle Exadata. Ciò significa che ogni volta che aumentiamo il traffico API (e il traffico cresceva più del tasso di conversione) dobbiamo ridimensionare verticalmente il nostro database.

Larchitettura guida lefficienza della piattaforma IT

La proposta di architettura a quel tempo era di disaccoppiare i servizi API creando un nuovo livello di micro servizi su il cloud per gestire tutto il traffico con minori costi mantenendo linfrastruttura Database solo per la prenotazione e le operazioni (che purtroppo non crescono in modo esponenziale). Il risultato, non è stata più la nuova infrastruttura necessaria per il DB negli anni successivi e un migliore rapporto tra traffico e costi IT.

Usa la stessa lingua

Non preoccuparti, sto non parliamo di linguaggi di programmazione (java, python, ecc.). Come architetto sono più che aperto alla diversità con un certo controllo (non il caos). Qui mi riferisco al termine Integrità concettuale che ho letto per la prima volta in Mythical Man Month e altri saggi sullingegneria del software di Frederick P . Brooks Jr.

Nel Libro, Fred Brooks spiega come crescono i team IT e come tale crescente impatto sulla loro produttività. Per Fred, uno dei maggiori problemi da affrontare quando si tenta di scalare un team IT è la comunicazione tra i team. Per parallelizzare le attività è necessario che i team siano il più indipendenti possibile. Ma, non appena tutti i team lavorano su una piattaforma interconnessa, abbiamo bisogno di una comunicazione tra i team. È in quegli scenari in cui avere un linguaggio comune è la chiave del successo.

Ricordo ancora le conversazioni infinite con i miei ex compagni di squadra che discutevano su cosa sia un sistema, un componente tecnologico, uninterfaccia o un elemento costitutivo. Se lavori in un grande reparto IT, probabilmente sai quanto sia frustrante che le cose abbiano nomi diversi dai team. A volte è anche peggio quando usano lo stesso nome per cose diverse.

Un esempio comune di questultimo è nominare unapplicazione monolite con un solo nome. Anche se ha senso (dato che è un monolite), quando vuoi rompere quel monolite, avrai bisogno di più dettagli. Lintroduzione di nomi diversi per il database, il frontend, il modello di dati, ecc. Aiuterà nel processo.

Anche se lavori in un reparto IT piccolo o più grande, è sempre un buon momento per iniziare con una convenzione di denominazione, un catalogo di servizi / sistemi / soluzioni, ecc. Non sai mai quanto sarai grande in futuro.

Informazioni sullintegrità concettuale, nudo con me, prima è meglio è.

Forza conversazioni sul design

Nella mia mente ogni soluzione a un problema inizia sempre con un analisi della situazione e progettazione della soluzione prima dellimplementazione. La realtà per un team di sviluppo è che ogni settimana abbiamo nuovi problemi sul tavolo da risolvere. Dopo alcuni mesi di routine Business as Usual, i team iniziano a funzionare con il pilota automatico e trovano semplicemente soluzioni ai problemi senza pensare troppo alle implicazioni a medio e lungo termine.

Avere la funzione di architettura integrata nei team di sviluppo aiuta sempre sullaumento delle conversazioni sul design per trovare le migliori soluzioni ai problemi che dobbiamo affrontare.

Inoltre, mi piace sfidare il processo di sviluppo della vecchia moda in cui il design è visto come qualcosa da fare solo allinizio di un progetto.Nellarticolo The Architect Elevator – Visitare i piani superiori , Gregor Hohpe descrive perfettamente la mia comprensione del ruolo dellArchitettura:

“… Quindi, invece di affidare tutte le decisioni cruciali a una persona, il rischio del progetto può essere ridotto da riducendo al minimo il numero di decisioni irreversibili .”

Larchitettura deve essere presente in tutto il processo di sviluppo . In effetti, se stai lavorando su Agile, prendi decisioni su ogni iterazione.

Discussioni strategiche

Come ragazzo IT mi piacerebbe essere nel consiglio di amministrazione dellazienda con e discussioni tecniche dettagliate. La realtà per le medie e grandi aziende è che i membri del Consiglio non possono permettersi di andare troppo in profondità nei dettagli. Ma il consiglio di amministrazione dellazienda dovrebbe prendere decisioni sulla strategia senza comprendere la situazione IT?

Nel mondo attuale, ci sono solo poche aziende che possono dire che lIT non è al centro della loro strategia. Allora, chi è responsabile della traduzione della strategia in IT e viceversa? – conosci già la risposta.

Uno dei nostri più grandi contributi nel team di architettura di TUI Destination Experiences è stato disegnare un modello di architettura di destinazione. Il TAM consente alle persone non IT di comprendere le nostre principali soluzioni e sistemi e come sono collegati ai flussi di valore della nostra azienda. Dopo aver distribuito il TAM, la maggior parte delle nostre conversazioni strategiche sono iniziate osservando come appare la nostra architettura e come dovremmo adattarci a una nuova situazione.

Ma attenzione, un modello di architettura di destinazione non è pensato per essere statico immagine dellarchitettura “così comè” e “futuro”. Provare a fare quel tipo di esercizio finirà per ottenere qualcosa di effimero che si adatta semplicemente a un progetto specifico. Secondo me, è meglio concentrarsi sul disegnare i componenti principali della tua architettura e selezionare le cose che vuoi preservare (perché sono il cuore della tua attività) e indicare le cose che dovrai cambiare o evolvere.

Prima diapositiva della presentazione TAM

Ricorda sempre ciò che ha detto Dee Hock, fondatore di Visa:

Scopo e principi semplici e chiari danno origine a comportamenti intelligenti complessi. Regole e regolamenti complessi danno origine a semplici comportamenti stupidi.

Verso linfinito e oltre

Lossessione per essere agili a volte trasforma i team IT in responsabili delle decisioni a breve termine . Come abbiamo già discusso, dobbiamo essere sicuri che le decisioni che stiamo prendendo oggi siano a prova di futuro. A volte significa avere una visione chiara della strategia a lungo termine. A volte significa stare attenti a non essere bloccati in una soluzione che non si adatta al tuo futuro. La maggior parte delle volte significa garantire un livello di qualità predefinito ed essere in grado di adattarsi a qualsiasi cosa.

Come abbiamo già commentato, lArchitettura deve lavorare anche a livello strategico. Ciò significa che probabilmente avranno nuove informazioni sulle possibilità future che potrebbero influenzare la piattaforma IT. A volte questi cambiamenti strategici sono persino confidenziali. Essere in grado di influenzare alcune decisioni cercando di evitare movimenti di rimpianto a volte è un compito difficile perché le persone non informate non capiranno mai la vera ragione dietro.

Ad un certo punto, eravamo nel mezzo del discussione sul miglioramento dellarchitettura della piattaforma B2C. Ha davvero senso migliorare molto larchitettura. Ma alcuni di noi sapevano che stavamo conversando per acquisire unazienda che sostituirà la nostra piattaforma B2C.

Fidati di me, non è sempre facile essere un architetto, ma devi sempre pensare a cosa è meglio per lazienda.

E anche …

… Inoltre amiamo disegnare e renderemo lufficio molto più interessante.

Team di sviluppo che discute utilizzando un diagramma di architettura

Spero che questo post modesto contribuire in futuro a comprendere un lavoro così bello.

Migue Coll, Head of Technology Domain presso Tui Destination Experiences.