La principale attività di Imola Informatica è l’Architettura IT, un’attività che può essere definita in vari modi.

Per Imola Informatica Architettura IT è uno strumento che consente di gestire in maniera organica non solo la parte IT, ma anche quella strategica che stabilisce la direzione aziendale. È un modo per collegare aspetti tecnici e decisionali che solitamente sono separati fra di loro.

L’enterprise architect è la figura che ha lo scopo di indirizzare e agevolare le attività che consentono il raggiungimento degli obiettivi stabiliti dalla visione aziendale; è un ruolo strategico, molto importante in quanto guida e governa le attività IT.

Quali competenze deve avere un enterprise architect? Quali sono le sue attività concrete? Perché è un ruolo rilevante sia per i business “tradizionali” che per quelli digitali più innovativi?

Le risposte a queste domande insieme a molti altri spunti si possono trovare nel libro “The Software Architect Elevator” di Gregor Hohpe, un’autorità in questo campo.

Lo scopo del volume è:” incoraggiare gli architetti IT ad assumere un ruolo attivo nel trasformare le organizzazioni IT tradizionali che devono competere con i disruptor digitali che sovvertono lo status quo.” La chiave di lettura è quella di riuscire a creare e indirizzare i cambiamenti per trasformare una azienda tradizionale in qualcosa in grado di competere in un mondo sempre più digitale.

Se qualcuno ritiene che i “business tradizionali” non siano interessati dal tema digitalizzazione e dall’affrontare i “disruptor”, e quindi la figura di enterprise architect definita da Hohpe non sia necessaria, la risposta dell’autore è: “Some traditional businesses may feel safe from disruption because their industry is regulated…..The fintechs Lemonade (insurance) and N26 (banking) are vivid examples of successful challengers in a regulated industry.” (pag. 235)

Il volume è strutturato in sei parti, ognuna delle quali si articola su diversi capitoli (41), i macro temi affrontati sono:

1. La figura dell’architetto
2. Architettura
3. Comunicazione
4. Organizzazioni
5. Trasformazione
6. Epilogo

Lo spettro dei temi trattati è veramente ampio e coerente: si parte della definizione della figura di architetto per passare a quella di architettura descrivendone chiaramente gli aspetti fondamentali per poi affrontare il tema della veicolazione dei contenuti, gestione dei rapporti all’interno dell’azienda per concludere con le azioni necessarie per poter competere con i disruptor.

Per chi lavora in un contesto “corporate” la visione dell’autore può essere in controtendenza, di seguito una serie di visioni tradizionali e la loro controparte nel libro:

• IT considerato semplicemente un centro di costo gestito con logiche di budget/acquisto standard, vs. “In the digital age, IT is competitive differentiator and opportunity driver, not a commodity like electricity”
• Gestione della documentazione come semplice formalità che fa parte del pacchetto di consegna vs. “Systems documentation, especially in IT, tends to depict the static structure but rarely the behavior of the system. Ironically, however, the system’s behavior is that’s most interesting: systems generally exist to exhibit a certain, desirable behavior”
• Separazione fra chi sviluppa e chi gestisce software vs. “The fear of change is even encoded in many IT organizations that separate “run” (operating) from “change” (development), establishing that running software doesn’t imply change. Rather, it’s the opposite of change…”
• Obiettivo di riduzione dei tempi di consegna tramite modifiche incrementali vs. “Large companies looking to speed up are used to optimizing the way they work: they can make production a few percent more efficient, negotiate a slightly higher discount from vendors, and reduce budget by printing in black and white. Sadly, though, their digital competitors don’t move 10% faster, but 10 times faster, leaving traditional IT departments somewhat puzzled by how this is even possible.”

Lo stile di scrittura è piacevole e facilmente comprensibile anche se in inglese, c’è un ampio uso di metafore per spiegare i concetti, non mancano le battute e gli aneddoti. Anche il titolo del libro è una metafora: l’architetto deve essere in grado di utilizzare un ascensore per poter parlare sia con i “piani bassi” dove avviene la produzione sia con i “piani alti” dove si prendono le decisioni strategiche. L’architetto, e il relativo ascensore, consentono di portare avanti una strategia che unifica tutti i livelli aziendali.

Ogni capitolo è lungo poche pagine (solitamente meno di 10), ma questo non deve ingannare, l’autore ha condensato le sue conoscenze (dal punto di vista informatico si potrebbe tranquillamente dire che sono zippate) e ci vuole tempo per assimilare tutti i contenuti.

Molto interessanti le citazioni e i riferimenti ad altri libri/pubblicazioni presenti in ogni capitolo che possono essere un ulteriore spunto di approfondimenti specifici.

Ho notato e apprezzato anche un uso dell’inglese volto alla divulgazione presso un pubblico non madrelingua.

La lettura può seguire percorsi diversi a seconda della conoscenza della materia da parte del lettore.
Per chi comincia, consiglio di leggere con attenzione le prime due parti, “metabolizzarle”, applicarle sul campo per qualche mese e poi rileggere il libro da capo. Avere chiaro il ruolo dell’architetto, su quali aspetti deve focalizzarsi (es. “Architects deals with non requirements”, “Architects live in the first derivative”), insieme a una definizione di architettura, è di grande aiuto quando ci si approccia al ruolo.

Se il lettore proviene da un percorso di sviluppo/gestione software ed è appassionato al tema, il libro può essere letto tutto d’un fiato e sicuramente fornisce degli spunti e dei riferimenti significativi (ad esempio spiega perché le aziende digitali hanno successo senza dei dipendenti che ricoprono il ruolo di architetto o illustrando le ragioni per cui alcuni framework di sviluppo interni hanno successo e altri no).

Nel caso venga letto da un architetto enterprise senior che non ha ancora affrontato il tema della competizione digitale, il consiglio è di leggere ogni capitolo con attenzione in quanto ci sono diversi aspetti della propria attività che vanno rivisti in un’ottica di trasformazione digitale (ad esempio la comunicazione, il colloquio sia con la parte tecnica che con il management, la visione su cosa deve essere svolto in azienda e su cosa viene gestito in outsourcing).

L’autore trasmette una parte della sua notevole esperienza nella descrizione di diversi scenari aziendali “tradizionali” e pagina dopo pagina ci si rende conto dell’importanza di essere capace di ascoltare i propri clienti e reagire in tempi brevi e del tantissimo lavoro che aspetta un architetto che segue il processo di trasformazione conseguente.

Ci sono troppi aspetti da elencare per fornire una idea precisa dei contenuti; l’unico modo per apprezzare veramente il contenuto del libro è leggerlo, magari più di una volta.

Personalmente ritengo il libro un must-have per chiunque voglia cimentarsi nel ruolo di enterprise architect con lo scopo di gestire la trasformazione digitale. Qualsiasi azienda che si occupa della tematica credo dovrebbe ordinarne almeno 5 copie da mettere a disposizione dei propri dipendenti.