Quello dei microservice è un tema scottante. Sul quale è tutto un fiorire di opinioni, di discussioni in conferenze e di post sui blog. Io stesso ho iniziato a fare microservice tre anni e mezzo fa, quando stavo progettando un sistema per una compagnia di assicurazioni. Da allora, su questo tema ho tenuto spesso conferenze, ho pubblicato numerosi articoli e tenuto molti corsi di formazione. Di solito, chiedo a chi partecipa ai miei corsi se dispongono di un grande sistema monolitico del quale vorrebbero liberarsi. Nella maggior parte dei casi, ovviamente ce l’hanno. Non sarebbero venuti alle mie conferenze, né mi avrebbero invitato a tenere corsi se non fosse stato così. E c’è più di un buon motivo per cui si intende abbandonare i monoliti. Vediamo alcuni esempi pratici, tratti dalla vita reale.

I monoliti – Uno dei miei clienti gestiva gran parte del suo software di produzione su un mainframe. Il codice era stato scritto in un interessante dialetto Cobol, con 18 milioni di righe di codice. Solo mantenere in vita il mainframe costava più di un milione di euro all’anno. Senza contare che la maggior parte dei programmatori di Cobol sono ormai in vista del pensionamento. Un’altra società con cui ho lavorato ha iniziato con due ragazzi, di cui uno ha scritto codice. In VBA. Quando la società ha cominciato a crescere, hanno migrato a Visual Basic. Attualmente, l’azienda impiega oltre 20 sviluppatori e scrive codice sia in C# sia in VB.NET. Il prodotto è cresciuto a quasi 4 milioni di righe di codice. Un ultimo esempio. Nel corso di 12 anni, una terza società ha scritto 3 milioni di righe di applicazione di codice. In PHP. La complessità del database e le numerose domande di codice on top rendono difficile aggiungere nuove funzionalità.

.@aahoogendoorn presenterà a Roma per @techtran il 9 e 10 nov. 2017
Click To Tweet

Le analogie – Diverse aziende, diversi scenari. Ma ciò che mi ha colpito è il numero di somiglianze presenti in questi scenari: 1) In tutte e tre le aziende, diverse persone avevano lavorato su questi sistemi per molti anni, con inevitabili differenze in termini di intuizioni, idee architetturali e stili di coding. 2) Di conseguenza, nel corso del tempo l’architettura si è sfilacciata ed è divenuta sempre più difficoltosa da mantenere o estendere. 3) Non ci sono test automatici (unità o integrazioni) in nessuno di questi scenari. Con il Cobol posso capirlo, ma con linguaggi più moderni come Java, C#, VB.NET o PHP, non c’è nessuna scusa. In tutti e tre gli scenari, aggiungere nuove funzionalità è diventato praticamente impossibile. Come mi hanno spiegato i tester: «Per ogni bug che risolviamo, ne introduciamo uno nuovo».

Serve velocità – Ma allora cosa è andato storto in questi esempi? Le chiare analogie in questi scenari indicano un possibile fallimento dell’architettura. Queste aziende hanno lasciato che il loro software crescesse nell’arco di lunghi periodi di tempo: vent’anni, o dodici anni. E si sono trovate continuamente a scegliere tra l’aggiunta di nuove funzionalità e il mantenimento della qualità. Se vuoi avere un codice che sia nel tempo manutenibile, dovrai trovare un buon equilibrio tra caratteristiche e qualità.

La rana bollita – C’è una vecchia metafora che si adatta al comportamento di tali società: la sindrome della rana bollita. Se una rana viene messa di colpo in acqua bollente, salterà fuori. Ma se viene messa in acqua tiepida che poi viene portata lentamente a bollore, non avverte il pericolo e verrà bollita viva. Anche se si tratta di una leggenda, come metafora è abbastanza azzeccata. Le aziende sembrano sempre aver bisogno di crescere. C’è sempre bisogno di velocità. Il business tira sempre fuori più caratteristiche di quanto i team riescano ad aggiungere ai sistemi. Di conseguenza, le aziende spesso optano per i benefici a breve termine invece che per quelli a lungo termine, cioè per le nuove funzionalità invece che per la manutenibilità. «Aggiungeremo i test più avanti». Oppure: «Lasciamo alcuni “to do” nel codice, e più avanti li aggiusteremo». Ma il problema è che il tuo codice non si rompe quando lo crei per la prima volta: si rompe dieci o quindici anni dopo. E in posti che non avresti mai pensato. Questo è lo stato in cui di solito trovo le aziende: rane bollite che mi chiedono di aiutarle a sbarazzarsi dei loro monoliti non manutenibili, nei quali l’architettura è un pasticcio e non ci sono test automatici, oppure il sistema non scala bene e a ogni variazione di codice il sistema crolla da un’altra parte.

Buttarsi sui microservice? – Dato che l’espressione è stata coniata quasi quattro anni fa, le aziende ora credono che i microservice risolveranno i loro problemi e che porteranno cose buone, in quanto componenti piccoli e indipendenti che consentono di scalare e scrivere un codice gestibile e testabile. Tuttavia, l’implementazione di microservice comporta anche molte domande alle quali è necessario trovare una risposta lungo il percorso, come per esempio:

• Cosa rende un componente un microservice?
• Come integro tutti questi piccoli componenti indipendenti?
• Come progettare le interfacce di questi componenti, le API?
• Cosa significa essere RESTful?
• Come progettare l’implementazione dei miei componenti?
• Come faccio a organizzare l’autorizzazione e l’autenticazione?
• Quali tecnologie posso utilizzare per costruire, testare e distribuire i miei microservice?
• Come posso impostare e mantenere le pipeline di deployment automatizzato?
• Posso integrare i miei microservice con altri sistemi più tradizionali?
• Ultimo ma non meno importante: i microservice implicano che il sistema è distribuito. Quindi, come posso organizzare l’integrità e la coerenza dei miei dati se uno dei servizi non è temporaneamente disponibile?

Nel complesso, i microservice sono una scelta architettonica interessante se si intende eliminare il monolite, ma hanno anche alcune conseguenze non secondarie. Trovare le risposte giuste alle domande appena viste, specifiche per la propria azienda, può essere una sfida. È per questo che bisogna intraprendere seriamente il percorso verso i microservice. Ci vuole tempo, fatica e preferibilmente esperienza. Se non sei stato in grado di tenere in ordine l’architettura, il codice e i test negli ultimi 15 anni, pensi di poter implementare i microservice, che sono un’architettura ancora più difficile?

.@aahoogendoorn Come Progettare e implementare una architettura #Microservice
Click To Tweet

Ma hai davvero bisogno dei microservice adesso? – Sono convinto che i microservice siano l’architettura giusta per questa epoca altamente scalabile. I loro vantaggi non sono pochi: migliorano la scalabilità e consentono di distribuire singole parti piccole e sostituibili in tutta l’infrastruttura. Ma aggiungono anche un altro livello di complessità all’infrastruttura stessa: pensiamo alla progettazione di API RESTful, o all’autorizzazione e all’autenticazione, oppure ancora alle nuove infrastrutture (cloud) e al fatto che adesso state costruendo sistemi distribuiti.Tuttavia, alla maggior parte delle rane che bollono mancano il tempo e l’esperienza per operare tali migrazioni su larga scala dei loro prodotti, ed è per questo che dovrebbero indagare se hanno bisogno di migrare adesso ai microservice. Ci sono molti aspetti dei microservice che già da soli forniscono molti miglioramenti, senza dover per forza ricorrere a tutto il pacchetto completo:

• Fanno aderire a un approccio più agile.
• Migliorano la collaborazione in team e comprendono sia le attività sia le operazioni.
• Migliorano il design modulare dei monoliti.
• Aumentano i test automatizzati, rendendo meno difficile il refactoring a un design più modulare.
• Impostano le pipeline per il deployment automatizzato, che consentono di passare a implementazioni più regolari, eliminando così tutti i tipi di attività di distribuzione manuale.

Forse la sfida principale è migliorare la qualità e la manutenzione del codice. O ridurre il time to market. O forse innovare più velocemente. In questi casi, le tecniche elencate sopra aiuteranno a ottenere risultati senza necessità di passare direttamente ai microservice in una sola volta. Quindi? Stai pensando di spostarti verso nuove architetture? Verso i microservice? O verso il serverless? L’importante è cominciare sempre rispondendo alla domanda: “che cosa mi serve davvero per migliorare?”. E solo dopo aver risposto a questa domanda si migliorerà gradualmente. E si eviterà di entrare a far parte della prossima generazione di rane bollite.

Sander Hoogendoorn

Mentore, allenatore, software architect, sviluppatore, speaker e scrittore. Apprezzato dai suoi numerosi clienti internazionali come grande innovatore nello sviluppo software, è autore del best-seller “This is Agile”. Oltre a essere keynote speaker in molte conferenze internazionali, presenta seminari e corsi di formazione in tutto il mondo su diversi argomenti tra i quali: Agile, Scrum, Kanban, continuous delivery, architettura software, Microservices, modeling e UML.

Sander Hoogendoorn presenterà a Roma per Technology Transfer i seminari “Progettare, sviluppare e implementare una Microservices Architecture” il 9 novembre 2017 e “Introduzione a Agile, Scrum, XP, Kanban e Continuos Delivery in pratica” il 10 novembre 2017.

L'articolo Arrivano i microservice. Quando sbarazzarsi dei monoliti. E quando no proviene da Data Manager Online.

Da sempre si sa che il cervello umano è dotato di una complessità strutturale incredibile, ma finora non si poteva che immaginarlo. Grazie al progetto Blue Brain, nato nel 2005 per iniziativa del Politecnico di Losanna e della Ibm, questa affascinante architettura è stata finalmente svelata in tutta la sua complessità, arrivando a scoprire come le cellule nervose interagiscono fra loro formando strutture a due dimensioni come i piani, ma anche a tre come i cubi, fino a strutture a cinque, sei e perfino 11 dimensioni. Precedenti ricerche hanno studiato il cervello durante l’attività onirica osservando per la prima volta l’impronta lasciata dai sogni e l’ultima mappatura, la più dettagliata mai realizzata, ha rivelato 100 nuove regioni.

Uno studio basato sull’algebra

Pubblicata sulla rivista Frontiers in Computational Neuroscience, la ricerca è coordinata da Henry Markram, direttore del progetto Blue Brain e ricercatore del Politecnico di Losanna, e si basa sull’applicazione allo studio dei neuroni della topologia algebrica, la branca della matematica che usa l’algebra

per studiare proprietà e struttura delle forme nello spazio. Questo strumento è stato applicato per la prima volta allo studio del cervello da Kathryn Hess, del Politecnico di Losanna, e Ran Levi, dell’università scozzese di Aberdeen.

«L’algebra topologica – ha detto Hess – è nello stesso tempo un microscopio e un telescopio: può fare uno zoom all’interno delle reti per scoprirne le strutture più nascoste, come gli alberi in una foresta, e riuscire a vedere gli spazi vuoti, come le radure».

Strutture come castelli di sabbia

Grazie a questo approccio è stato possibile arrivare a studiare il cervello umano a questa profondità dimensionale, rivelando una rete di circuiti che non si limita a intrecciarsi nell’ambito delle quattro dimensioni finora note ma può raggiungere perfino 11 dimensioni. Una conferma che è arrivata dall’osservazione sia del tessuto della corteccia cerebrale ottenuto dal progetto Blue Brain nel 2015 con una simulazione, sia di un frammento reale di tessuto cerebrale. Si è osservato così non solo il formarsi delle strutture multidimensionali si formano ma anche che il cervello si riorganizza costantemente, creando nuove strutture e poi demolendole per costruirne di nuove.

«Sono come castelli di sabbia multidimensionali, che continuamente si materializzano per disintegrarsi subito dopo», ha osservato Markram. Abbiamo scoperto – ha aggiunto – un mondo che non avremmo mai potuto immaginare» e che «esistono decine di milioni di questi oggetti anche in una porzione del cervello piccola come una briciola».

L'articolo Cervello, un’architettura con strutture fino a 11 dimensioni proviene da Data Manager Online.

La SEAT ha selezionato il progetto vincente per la creazione del suo futuro Museo Digitale durante l’Archithon, un evento ispirato ad un hackathon al quale hanno partecipato 40 studenti di Architettura, provenienti da Università spagnole e tedesche. Partendo dalle linee guida fornite dalla Casa spagnola venerdì 15 maggio, i partecipanti, divisi in squadre, hanno lavorato per 48 ore consecutive durante lo scorso fine settimana presso l’OneOcean Club di Barcellona. Il progetto vincente è opera di un gruppo composto da tre studenti: Anton Sahler e Patricia Loges, della Technische Universität di Berlino, e Ksymena Borczynska, proveniente dall’Università di Kassel, sono infatti gli autori dell’innovativa idea per custodire la storia del Brand.

Tre dei gruppi di lavoro in cui si sono divisi i giovani studenti sono arrivati sul podio, ricevendo un premio in denaro. Gli artefici del progetto che si è classificato primo, inoltre, continueranno nei prossimi giorni a lavorare per sviluppare in maniera più dettagliata la loro proposta, che la SEAT porterà a termine contando di dare vita a settembre al proprio Museo Digitale.

“Il progetto che abbiamo ritenuto vincente è basato sull’idea di una nuvola, in grado di spostarsi da una città all’altra. Ci sembra un progetto coerente e pienamente rappresentativo dei valori della nostra Marca, internazionale e in grado di raccontare la storia della SEAT in maniera molto originale”, ha sottolineato Christian Stein, Direttore Marketing di SEAT S.A. e uno dei 5 membri della giuria dell’Archithon alla fine della gara.

Patricia Loges, una dei tre componenti del team vincitore, insieme ai suoi compagni di squadra ha sottolineato: “Il premio che abbiamo conquistato è il nostro lasciapassare per il mondo che ci appassiona, l’architettura. Senza ombra di dubbio, il fatto che un’azienda come la SEAT scommetta sul talento dei giovani attraverso iniziative di questo tipo è una grande notizia. Non vediamo l’ora di iniziare a sviluppare il nostro progetto e vederlo prendere vita”.

Il Museo Digitale della SEAT racconterà la storia dell’Azienda a partire dalla sua fondazione, avvenuta nel 1950, e lascerà intravedere l’innovazione e l’idea di futuro verso cui il Marchio sta puntando: sarà caratterizzato da spazi polivalenti volti a ripercorrere la storia dei modelli più rappresentativi della Casa di Martorell, e da una galleria dedicata a tutti coloro che hanno contribuito ai progressi dell’Azienda.

L'articolo Il Museo Digitale della SEAT avrà forma di nuvola proviene da Data Manager Online.

«E’ un esempio che deve servire da stimolo e, fatemelo dire, anche da monito per molti altri privati e imprese italiane», ha commentato il ministro, esprimendo piena gratitudine verso il il manager della Tsusho Ltd, marchio di esportazione di tessili italiani in Giappone, che ha sponsorizzato la rinascita del meraviglioso sito archeologico della capitale.

Un incentivo per gli atti di mecenatismo

«Questo bene appartiene al mondo –  ha detto appena arrivato il signor Yagi – un bene che appartiene a tutta l’umanità». Alla visita alla Piramide ha partecipato anche il soprintendente ai Beni archeologici di Roma, Mariarosaria Barbera: «Siti come questo, censito dall’Unesco, è difficile dire che appartengono allo Stato, al Comune o al privato che li possiede pro tempore – ha aggiunto -. E’ veramente importante che ci sia stato un atto di mecenatismo di un privato che guarda con grande amore all’Italia e al suo straordinario patrimonio storico e monumentale».

I lavori di restauro, la cui conferma era arrivata nel 2012 con la stipula dell’accordo tra Soprintendenza e Yagi, sono in effetti iniziati a marzo del 2013. Il ministro prosegue invitando le imprese italiane a trarre esempio dal generoso atto di mecenatismo di Yagi: «Adesso ci sono degli incentivi fiscali formidabili che valgono per le imprese che hanno sede in Italia: l’art bonus è il 65%, quindi un incentivo che ci mette davanti a tutti gli altri Paesi europei».

Un cantiere d’eccezione

Anche se in Italia risulta difficile da credere, questo cantiere procede a ritmi velocissimi: il primo lotto era già terminato con 5 mesi di anticipo. Il ministro prevede che anche il secondo lotto finirà con 3 mesi di anticipo rispetto al previsto. Anche Yagi si è mostrato soddisfatto dell’andamento dei lavori e ha commentato con un entusiasta «Very well». Il manager giapponese ha spiegato che «gli archeologi e gli architetti sono molto seri e anche gli italiani sono sorprendentemente tutti puntuali. Io faccio affari nel campo della moda con gli italiani da 40 anni, sono molto creativi, ma non sono proprio puntuali. E invece qui finiscono prima della scadenza programmata».

La velocità dei lavori ha sorpreso anche Yagi stesso, che si è detto impreparato alla preparazione di una degna cerimonia di inaugurazione, che potrebbe quindi slittare alla prossima estate «intorno a giugno o luglio, con molti amici europei e americani», ha detto. Non si esclude al momento anche una seconda sponsorizzazione, stando alle dichiarazioni di Yagi, ancora da confermare: «Potrei, non ho idee particolari, ma in Italia ci sono molte bellezze, anche addormentate, sepolte sotto la polvere. In futuro ci piacerebbe».

L'articolo Restauro lampo della Piramide Cestia grazie a un mecenate giapponese proviene da Data Manager Online.

by Mike Rosen

Un modo di guardare a questi aspetti è quello di prendere in esame la domanda: «Cos’è l’architettura»?
Una comune definizione informale di architettura è: «La struttura degli elementi fondamentali e le loro relazioni all’interno di un ambiente». Qualcuno ritiene questa definizione troppo soggettiva. Ecco, quindi, un’altra buona fonte per definire l’architettura: “ISO/IEC/IEEE 42010:2007, Ingegneria dei sistemi e del software – Raccomandazioni per la descrizione architetturale dei sistemi a elevato tasso di software”. Si tratta di uno standard per descrivere l’architettura e quello che l’architettura dovrebbe descrivere. I principali concetti della “42010” sono:

• Un sistema è “un gruppo di componenti organizzati per raggiungere una specifica funzione o insieme di funzioni”.
• Un sistema esiste all’interno di un ambiente (o contesto), dove “l’ambiente determina i confini del sistema rispetto ad altri sistemi”.
• Un sistema dispone di uno o più stakeholder.
• Uno stakeholder ha una o più preoccupazioni relativamente al sistema. Preoccupazioni sono “quegli interessi che riguardano lo sviluppo del sistema, il suo funzionamento o qualsiasi altro aspetto critico o comunque importante per uno o più stakeholder”.
• Un sistema ha un’architettura, e questo sistema può essere espresso in una descrizione architetturale.
• La descrizione architetturale può essere suddivisa in “viste” che sono “una rappresentazione di un intero sistema dalla prospettiva di un insieme correlato di preoccupazioni”. Ogni vista affronta una o più preoccupazioni degli stakeholder.

Ma ci sono altri modi di pensare a ciò che è o non è l’architettura. Per esempio, John Zachman distingue tra architettura e ingegneria in termini di elementi primitivi e compositi, mentre un altro approccio è quello di formalizzare l’architettura in termini di un modello architetturale o metamodello. In realtà, questo è fondamentale per raggiungere la coerenza tra i punti di vista che la conformità alla “42010” richiede. Ma non solo: altri mettono in discussione il valore di un approccio e sono più preoccupati per la sua efficacia rispetto al fatto che si tratti o no di “architettura”.

E mentre è importante capire la struttura di una buona architettura, è anche importante capirne lo scopo. Ciò che è altrettanto rilevante è capire che in genere gli approcci di architettura “one-size-fits-all” non sono efficaci. In ogni impresa, la cultura, la struttura, l’organizzazione, il personale e la motivazione per l’architettura sono differenti. Alcune ricorreranno a un’architettura per ridurre la complessità e i costi, mentre altre imprese cercheranno un’architettura in grado di aiutarle nei processi di fusione o acquisizione, e altre ancora lanceranno un nuovo prodotto o servizio, o ci sarà qualche altro motivo. Ma ciascuna di queste ragioni richiederà un approccio diverso, e avrà un diverso insieme di stakeholder.

Il primo passo – Quindi, il primo passo nella progettazione di un programma di architettura è di articolare chiaramente gli obiettivi del fare architettura presso la propria azienda. Facendo qualche passo ulteriore, si può utilizzare il Business Motivation Model (BMM) per definire gli obiettivi, le strategie per il raggiungimento di tali obiettivi, i criteri di implementazione delle strategie e gli obiettivi per misurare l’efficacia delle tattiche.

In genere, utilizzo il BMM nello stesso momento in cui eseguo l’analisi degli stakeholder per assicurarmi di aver identificato gli stakeholder importanti e che i loro obiettivi e traguardi siano rappresentati. Con una migliore comprensione del perché stiamo adottando un’architettura, potremmo rivolgere la nostra attenzione al come.

Definire lo scopo – Alla base, lo scopo dell’architettura è quello di creare un contesto che influenza le decisioni. Si può trattare di decisioni di selezione delle tecnologie o di progettazione delle soluzioni, oppure ancora di scelta di progetto e gestione del portfolio, o di esecuzione di business transformation, solo per citarne alcune. Chiaramente, ciascuna di queste decisioni richiede un contesto diverso e informazioni differenti per influenzare le varie persone che prendono tali decisioni, mentre gli stakeholder e le decisioni dovrebbero essere già stati identificati nell’analisi precedente. È facile mettere in relazione tutto questo alla descrizione di cui alla ISO 42010: stakeholder diversi hanno problemi differenti, che sono descritti in vari punti di vista. Ma non basta aver individuato gli stakeholder e le loro preoccupazioni, perché bisogna portare la definizione della nostra architettura e del programma al passo successivo. Bisogna anche capire il modo migliore per influenzare le decisioni degli stakeholder per quanto riguarda queste preoccupazioni.

La formula del successo – La mia formula per il successo architetturale è questa: «Se la tua architettura rende più facile per qualcuno svolgere il suo lavoro, lo faranno. Se lo rende più difficile, la combatteranno».

La formula in sé è davvero molto semplice. Sembra così ovvio, ma si sa bene che raggiungere il successo è sempre un’altra questione. Quindi, potrebbe essere doveroso chiederci come potremmo rendere più facile il lavoro di qualcuno? Ovviamente, la risposta a tutto questo dipende dalle persone, dalle loro competenze, dal loro lavoro, da come la pensano, e da quali risultati o decisioni stiamo cercando di influenzare. Io uso una serie di domande per determinare la struttura delle architetture:

1 . Quali decisioni stiamo cercando di influenzare con l’architettura? (preoccupazioni)

2 . Chi prende queste decisioni? (stakeholder)

3 . Quali processi usano per prendere tali decisioni?

4 . Dove sono le opportunità all’interno di questi processi per influenzare le loro decisioni?

5. Quale struttura sarebbe utile: (punti di vista)

• a questo punto nel processo

• per quella persona

• dal loro punto di vista, dai loro tool e insieme di skill

• e che sia coerente con i principi architetturali e con le best practice!

Quindi, il problema successivo per un architetto è capire come rispondere a queste domande. Uno dei metodi migliori è quello di chiedere ai decisori stessi: chi meglio conosce i propri processi e le proprie esigenze? E poi, se sono coinvolti nella progettazione delle architetture, forse se ne sentono anche un po’ proprietari e saranno più propensi all’utilizzo.

Per fare un esempio, un cliente voleva sviluppare un’architettura di riferimento per l’implementazione di servizi SOA. L’organizzazione stava già creando servizi, ma c’erano distinzioni non necessarie e incongruenze tra tali servizi. Così, abbiamo chiesto ad alcuni degli sviluppatori più senior: “Come si fa a creare un servizio?”. Questo ha portato a numerose domande successive come “Hai pensato così e così?”, “Perché ci sono queste differenze?”, “Cosa potrebbe essere riutilizzato in tutti i servizi per risparmiare tempo e fatica a tutti?”, “Che tipo di relazioni e di interazioni vi sono tra i servizi?”, “Quali sono alcuni dei problemi?”, “Come potevamo affrontarli in anticipo in sede di progettazione?”.

Queste sono tutte le preoccupazioni architetturali alle quali gli sviluppatori di solito non pensano. Gli architetti avrebbero potuto aver appena ponderato una soluzione a questi problemi e cercato di imporla, ma avrebbe avuto successo? Invece, coinvolgendo chi adotta le scelte progettuali, siamo arrivati a far comprendere la più ampia serie di requisiti e a far sentire proprietari della soluzione. Il risultato finale della discussione è stato uno schizzo alla lavagna di un “modello di progettazione” per l’implementazione dei servizi. Successivamente, il team architetturale ha preso lo schizzo e lo ha formalizzato in un modello di progettazione vero e proprio, che viene largamente utilizzato da tutto il team per una serie di motivi:

• ha il buy-in degli “utenti”, visto che sono stati coinvolti nella sua creazione
• è la struttura giusta per influenzare le decisioni di progettazione (un modello è perfetto per questo)
• utilizzare il modello facilita il lavoro degli sviluppatori!

Così, quando si esamina ciò che è architettura e quanto ha successo un programma di architettura, forse dovremmo guardare verso l’interno e chiedere: “La nostra architettura è correttamente concentrata sugli obiettivi più importanti e sugli stakeholder?”, “La nostra architettura rende più facile o più difficile il lavoro delle persone?”, “Riesce a influenzare le decisioni che portano alla realizzazione della visione architetturale?”. Le architetture di successo sono in grado di rispondere sì a tutte queste domande. E voi?

Mike Rosen

Mike Rosen è director per l’Enterprise Architecture presso il Cutter Consortium e direttore editoriale del SOA Institute. Ha esperienza pluriennale nell’architettura e nella progettazione di applicazioni e oltre 20 anni di esperienza nello sviluppo di prodotti per tecnologie distribuite come DCE, CORBA, DCOM, J2EE, Web Services, Transaction Processing e Messaging. È speaker di fama internazionale e autore di numerose pubblicazioni, tra cui “Applied SOA: Architecture and Design Strategies”. È stato chief enterprise architect presso IONA Technologies, dove era responsabile dello sviluppo dell’intera architettura di prodotto della piattaforma di Web Services di nuova generazione di IONA e della creazione dell’architettura di riferimento per la realizzazione di applicazioni su questa piattaforma.

Mike Rosen presenterà a Roma per Technology Transfer i seminari “Le scelte architetturali che funzionano” il 24-25 novembre 2014 e “Come diventare un grande Architetto” il 26-27 novembre 2014.

L'articolo Ma la vostra architettura è efficace? proviene da Data Manager Online.

Una casa completamente alimentata dall’energia solare e a impatto zero. E’ questo il progetto RhOME for denCity, realizzato da un gruppo di ricerca dell’Università Roma Tre guidato da Chiara Tonelli. L’abitazione ecosostenibile da 76 m2 è stata pensata per l’area di Tor Fiscale, nella periferia Sud-Est di Roma, ma è stata costruita per essere collaudata a Chienes, in provincia di Bolzano.

Una casa alimentata dal Sole

Dal 27 giugno, i moduli assemblabili di RhOME for denCity saranno in mostra al contest Solar Decathlon Europe 2014 nella Cité du Soleil allestita a Versailles. Per trasportare i diversi moduli fino alla reggia vicino Parigi si è preferito utilizzare il treno rispetto al trasporto su ruota, riducendo così le emissioni di anidride carbonica del 64%. RhOME for denCity dovrà vedersela con altri 20 progetti internazionali per ottenere lo scettro della soluzione più ecofriendly.

Tra le novità più curiose legate ad architettura e rispetto per l’ambiente ci sono anche i condomini con classe energetica A+ edificati a Genova, la casa modulare Livinbox e CoeLux, una tecnologia che riproduce fedelmente la luce naturale. A ciò si aggiungono i grattacieli più green scelti dalla rivista di architettura eVolo.

L'articolo RhOME for denCity: la casa green Made in Italy illumina Versailles proviene da Data Manager Online.

A Fancoforte si è tenuta la fiera Light+Building, evento durante il quale sono state presentate le innovazioni sul tema dell’illuminazione in architettura. Tra le proposte più interessanti c’è CoeLux, un sistema che permette di ottenere luce naturale in qualsiasi tipo di struttura.

Recentemente l’architettura ha dato una forte spinta verso soluzioni ecosostenibili. La rivista eVolo ha premiato i grattacieli più avvenieristici e green e i moduli preassemblati Livingbox permettono di costruire diversi edifici in modo economico e senza intaccare la salute dell’ambiente.   

CoeLux: una finestra sul cielo blu

La tecnologia ideata da Paolo Di Trapani, docente all’Università Insubria di Como, è costituita da un’apertura nel solaio che sfrutta LED ad ultima generazione e particolari sistemi ottici per riprodurre l’effetto della luce naturale. La sensazione che si ha quando si entra in una stanza dotata di CoeLux è che fuori ci sia una cielo terso e un sole luminosissimo.

Il progetto ha attirato le attenzioni dell’Unione Europea, che potrebbe utilizzare il sustema nei Paesi Nordici. In Scandinavia, dove le ore di luce sono ridotte, l’eccessivo utilizzo di illuminazione artificiale provoca disturbi sia a livello fisico che psichico. In Italia i primi test per CoeLux saranno effettuati nelle stazioni e nei tunnel di circolazione sotterranei della metropolitana di Milano.

L'articolo CoeLux: la tecnologia riproduce fedelmente la luce naturale proviene da Data Manager Online.

Dal 2006 la rivista di architettura eVolo premia i progetti di grattacieli più innovativi dal punto di vista estetico e tecnologico che siano anche ecosostenibili, come i giardini pensili a 54 metri di altezza immaginati in Svezia. All’edizione 2014 del “eVolo Skyscraper Competition” hanno partecipato 525 studi di architettura da 43 Paesi nel mondo. La giuria, formata da esperti del settore, ha scelto 3 vincitori e ha distribuito 20 menzioni speciali.

I vincitori

Il primo premio è andato a “Vernacular Versality”, realizato dall’architetto statunitense Yong Lu. Il suo grattacielo combina lo stile di costruzione tradizionale coreano con il profilo tipico di uno skyline. Molti degli elementi strutturali del concept sono stati realizzati in legno ed è presente un tetto mobile per regolare l’ingresso della luce solare.

La seconda posizione del concorso è occupata da “Car And Shell Skyscraper: Or Marinetti’s Monster” degli architetti USA Mark Talbot e Daniel Markiewicz. Il loro grattacielo è stato pensato per essere costruito a Detroit ed è stato ispirato dal filosofo del futurismo Filippo Tommaso Marinetti.

Tra le proposte più hitech c’è “Propagate Skyscraper: Carbon Dioxide Structure”, realizzato dai canadesi Yu Hao Liu e Rui Wu e classificatosi terzo. Questo particolare grattacielo è in grado di crescere in altezza grazie a materiali che assorbono la CO2 prodotta dall’uomo. Ciò lo rende una sorta di struttura “vivente”.

L'articolo eVolo premia i grattacieli più hitech ed ecosostenibili proviene da Data Manager Online.

Negli ultimi tempi la realtà virtuale è tornata di moda dopo essere stato l’obiettivo mai raggiunto negli Anni 90. Oltre ai Google Glass, sul cui contro Big G ha sfatato alcuni miti, sono stati sviluppati numerosi altri dispositivi che permettono di muoversi in uno spazio virtuale. Ad esempio, Facebook ha acquisito Oculus VR mentre Sony ha progettato un sistema immersivo per la sua PS4 chiamato Morpheus. La Scuola Superiore Sant’Anna di Pisa ha invece realizzato Alex, un sistema di realtà aumentata che garantisce un’esperienza virtuale del tutto simile a quella reale.

Anche Eni, che ha registrato un grande successo per la webolletta, ha pensato di utilizzare questa tecnologia per il training dei suoi ingegnieri. Eni Cave, costruito nell’Eni Corporate University, è infatti una stanza di realtà virtuale che permette di muoversi in uno spazio digitale come se fosse reale.

Eni Cave

Eni Cave è composta da una stanza composta da sei pareti, di cui quattro sono ricoperte da schermi retroproiettori. Indossando degli appositi occhiali 3D, l’utente potrà interagire con un ambiente virtuale che si modifica dinamicamente a seconda del movimento e della posizione della persona. “Lo scopo della Cave – ha spiegato Gianluigi Castelli, Executive Vice President ICT di Eni – è costituire un ambiente di realtà virtuale in cui sia possibile immergersi e quindi vivere l’esperienza dell’ambiente che viene creato. Questo apre una serie di prospettive”. Cave può essere utilizzata per “la validazione di progetti architettonici” o per addestrare gli operatori di impianti energetici simulando le attività che dovranno compiere quotidianamente.

La stazione di riformento del futuro

Il primo progetto realizzato con Cave riguarda la stazione di rifornimento del futuro. Grazie al supporto del MIT, un gruppo di ricercatori del dipartimento ICT di Eni ha costruito una simulazione in cui un braccio robotico effettua il rifornimento in automatico senza che il guidatore debba scendere dalla vettura. Il cliente inoltre potrà pagare il servizio tramite smartphone e sarà guidato verso la pompa più adatta alla sua automobile grazie ad un sistema di riconoscimento della targa. 

L'articolo Eni Cave: realtà virtuale per istruire gli operatori degli impianti proviene da Data Manager Online.

Genova sta diventando sempre più green. Dopo aver installato 17 nuove colonnine per la ricarica di auto elettriche, nel capoluogo ligure sono stati presentati da Ance Genova-Assedil due progetti per altrettante case ad impatto zero e costi di gestione energetica praticamenti nulli. “E’ possibile – ha spiegato il presidente di Ance Genova, Federico Garaventa – con le tecnologie effettivamente accessibili sul mercato, comprare una casa che non impatti sull’ambiente e sul nostro portafogli con le bollette energetiche”.

Residenza Le Pietre Rosa

La residenza Le Pietre Rosa, realizzata a Genova Albaro, è la prima abitazione in classe energetica A+. La climatizzazione avviene tramite due pompe di calore geotermiche e nove sonde che estraggono il calore a 150 metri di profondità durante l’inverno e lo cedono d’estate. La superficie dell’edificio, così come le finestre, ha la capacità di trattenere il calore nei mesi freddi e respingerlo in quelli più caldi. L’energia elettrica viene prodotta da pannelli solari.

Residenza La Rondine

La residenza La Rodine è stata costruito nel quartiere di Molassana ed è anch’esso dotato di classe energetica A+. La rete elettrica ottiene l’energia necessaria da un impianto fotovoltaico da 2.5 kw e materiali di cui è costituito l’edificio riducono la dispersione termica. La stessa forma dell’edificio è stata progettata per aumentare l’esposizione solare in inverno e trattenere il calore.

L'articolo Costruiti a Genova i condomini più green d’Italia proviene da Data Manager Online.