L’architettura dei prodotti software che ASIT propone, segue le linee guida di AGID. I nuovi prodotti software web-based realizzati, devono garantire un ottimo grado di usabilità su dispositivi desktop (via web browser) e su dispositivi mobili (responsive design o native). I servizi devono essere progettati e realizzati per dialogare in modo headless via web API (REST, GraphQL). A tal fine, è possibile impiegare eventualmente anche CMS API-oriented, sempre in modalità headless. I processi a lunga esecuzione devono essere eseguiti in modalità batch. La comunicazione tra REST API e operazioni batch è asincrona, orientata agli eventi (eg. event-driven) e implementata mediante un message broker. I dati devono essere memorizzati in database di tipo SQL o NoSQL, a seconda dei vincoli funzionali imposti dal progetto (eg. necessità ambiente transazionale e/o ACID, etc…). I documenti non devono essere archiviati nelle basi di dati in modo binario, bensì in repository documentali. Il codice sorgente delle interfacce utente del front end, il codice sorgente delle API nel back end e gli schemi SQL e NoSQL, devono essere archiviati in un sistema per la gestione e versionamento del codice sorgente. Il codice sorgente deve essere rilasciato con licenza open-source, il repository associato deve consentirne il riuso. Per quanto riguarda la licenza per ciascuna tipologia di prodotto rilasciato è necessario fare riferimento alle “Linee guida Agid per l'acquisizione e riuso di Software Open-source” (LOS). I nuovi sistemi devono essere progettati con architettura a microservizi con lo scopo di aumentare il grado di disaccoppiamento tra dati, business logic e interfaccia utente; si vuole conseguentemente aumentare il grado di manutenibilità. Lo sviluppo e il dispiegamento negli ambienti di test e di produzione, deve avvenire in modo programmatico utilizzando tecnologie a container. Le procedure di build e dispiegamento negli ambienti di test e produzione sono necessarie per realizzare l’integrazione continua.

Seguendo il principio cloudfirst e riuso di AGID, l’architettura proposta è basata su:

• Versionamento del codice sorgente e CI/CD: repository del codice GitHub e pipeline per automatizzare test e deploy;
• Automazione sistemica per il dispiegamento dell’infrastruttura: Teraform e Ansible per descrizione ed automazione della parte sistemistica;
• PaaS: Container docker per astrazione dal layer di infrastruttura ;
• Basi di dati: database relazionali (RDBMS) e NoSQL. Si prevede l’adozione di PostgreSQL come RDBMS e MongoDB nel caso NoSQL;
• Archiviazione documentale: S3 come object store per i files, evitando di salvarli direttamente sulla virtual machine o dentro il DB;
• Message Broker: si prevede l’utilizzo di Redis (o equivalente) come message broker per la gestione della comunicazione tra i vari microservizi;
• Framework e Ambienti di sviluppo per il Backend (batch node): Framework JS basati su Node.js per la business logic e l’esecuzione asincrona mediante processi batch;
• Framework e Ambienti di sviluppo per il Backend (interactive node): Framework JS basati su Node.js (eg., Express, NextJS) per la business logic e l’esposizione di API. È pratica comune impiegare un reverse proxy (eg.  NGINX) per l’efficientamento del consumo delle API esposte;
• Framework e Ambienti di sviluppo per il Frontend: Framework JS basati su React (eg. NextJS, React native) + componenti UI di React secondo gli standard tecnici definiti da ASIT (eg. UI kit, template grafico).