IT-PMS

La realizzazione di un ecosistema digitale di servizi richiede un’infrastruttura software in grado di gestire contemporaneamente:

• un numero elevato e crescente di attori indipendenti;
• servizi digitali eterogenei per tecnologia, dominio e modello di business;
• continue modifiche funzionali, normative e tecnologiche;
• transazioni economiche, regole di ingaggio e standard condivisi.

La letteratura scientifica classifica sistemi con queste caratteristiche come Ultra Large Scale Systems (ULSS), per i quali gli approcci tradizionali di progettazione software risultano inadeguati.

Il problema affrontato da AURIGA-PBM è quindi:

come progettare e validare una piattaforma ULSS che abiliti un ecosistema di servizi digitali per il business, mantenendo nel tempo integrabilità, manutenibilità, resilienza e qualità.

Le piattaforme digitali più diffuse (marketplace, app store, API platform) presentano almeno uno dei seguenti limiti:

• forte accoppiamento a tecnologie o stack proprietari;
• centralizzazione del controllo e delle decisioni evolutive;
• difficoltà di integrazione di sistemi legacy;
• elevato costo di manutenzione al crescere della complessità;
• scarsa trasferibilità delle soluzioni a contesti diversi.

In ambito scientifico, le architetture ULSS sono spesso descritte a livello teorico, ma raramente validate sperimentalmente su piattaforme reali con evoluzione incrementale.

Il contributo principale di AURIGA-PBM è la progettazione e validazione sperimentale di IT-PMS, una piattaforma ULSS che combina in modo sistematico:

• Process-Aware Information Systems (PAIS);
• architettura a microservizi;
• principi di Information Hiding;
• orchestrazione e coreografia dei servizi.

ULSS governato dai processi di business

IT-PMS dimostra che un sistema ULSS può essere governato efficacemente ponendo i processi di business al centro dell’architettura:

• i processi descrivono le procedure dell’ecosistema;
• i servizi sono risorse orchestrate o coreografate;
• l’evoluzione funzionale avviene tramite modifica dei processi, non del codice.

Questo riduce l’impatto dei cambiamenti e aumenta la resilienza nel lungo periodo.

Information Hiding applicato a scala ecosistemica

Il progetto estende l’uso dell’Information Hiding:

• dal livello dei moduli software;
• al livello dei servizi di piattaforma;
• fino al livello delle piattaforme integrate.

Ogni componente espone solo le interfacce necessarie, isolando: – decisioni tecnologiche; – politiche di evoluzione; – vincoli interni dei fornitori.

Microservizi come unità di evoluzione controllata

In IT-PMS i microservizi non sono solo una scelta tecnologica, ma:

• unità di evoluzione indipendente;
• confini di responsabilità architetturale;
• elementi misurabili in termini di qualità e debito tecnico.

Questo consente sostituzioni tecnologiche progressive senza interrompere l’ecosistema.

Valore per il mercato

• riduzione del rischio nella costruzione di piattaforme;
• maggiore prevedibilità dei costi di evoluzione;
• supporto a ecosistemi aperti e scalabili.

Valore scientifico

• validazione empirica di un’architettura ULSS reale;
• evidenza quantitativa sull’efficacia di PAIS + microservizi;
• contributo alla letteratura su ecosistemi digitali.

IT-PMS è strutturata come un insieme coordinato di:

• microservizi applicativi;
• servizi infrastrutturali;
• workflow BPMN (Camunda);
• gateway e adapter di integrazione;
• meccanismi di identità e sicurezza.

La piattaforma supporta:

• gestione del catalogo dei servizi;
• gestione delle transazioni e dei modelli di business;
• orchestrazione e coreografia delle coalizioni;
• monitoraggio di qualità, sicurezza e debito tecnico.

Integrabilità

Nel processo di integrazione della piattaforma IT-PMS con sistemi esterni, la valutazione dell’efficacia ed efficienza è stata condotta attraverso la rilevazione di quattro misure fondamentali:

1. TR (Tempo Persona Realizzato): rappresenta l’effort totale in ore-uomo impiegato per l’integrazione. Include la progettazione, l’implementazione, i test e le eventuali rilavorazioni.
2. TSD (Tempo Solare di Delivery): misura il tempo in ore, o giorni, intercorrente tra l’inizio e la consegna effettiva del sistema integrato agli utilizzatori finali.
3. TD (Debito Tecnico): calcolato attraverso strumenti automatici (es. Kiuwan), rappresenta il livello di imperfezione tecnica presente al momento del rilascio. Lo standard aziendale di Auriga prevede una soglia massima di 10 ore.
4. TTD (Tempo Tecnico di Debito): indica il tempo persona necessario per assicurare che il debito tecnico non superi la soglia accettabile.

Non avendo serie storiche da cui ricavare soglie per definire le linee di base, tali misure sono state confrontate con valori attesi definiti da esperti di dominio per casi simili (TRP, TSDP, TTDP). Da questi confronti derivano tre indicatori di scostamento normalizzato:

1. SCR – Scostamento positivo tra TRP e TRR: valuta l’efficienza realizzativa.
2. SCSD – Scostamento tra TSDP e TSDR: misura la rapidità di consegna rispetto alle attese.
3. SCTD – Scostamento tra TTDP e TTDR: verifica l’efficacia nella riduzione del debito tecnico.

Manutenibilità e Resilienza

Per valutare l’efficienza si utilizzano le seguenti misure:

• TM: Tempo persona speso per l’analisi, progettazione e implementazione della modifica.
• NI: Numero di componenti impattate per ogni componente modificata.
• TTS: Tempo persona speso per la progettazione e produzione del piano di test di sistema necessario per validare la modifica.
• TTA: Tempo persona speso per la progettazione e produzione del piano di test di accettazione.
• NTS: Numero di esecuzioni del piano di test di sistema per rendere negativi tutti i casi di test previsti.
• NTA: Numero di esecuzioni del piano di test di accettazione per rendere negativi tutti i casi di test previsti.

Per rilevare l’efficacia abbiamo utilizzato:

• NTS: se questo numero è piccolo vuol dire che le modifiche effettuate risultano essere tecnicamente corrette.
• NTA: se questo numero è piccolo vuol dire che le modifiche effettuate risultano essere tecnicamente corrette.
• TD: debito tecnico del sistema. Se il debito tecnico non aumenta rilevantemente a seguito di ogni manutenzione, il processo risulta efficace.
• TTD: tempo persona speso dopo la manutenzione per riportare il debito tecnico entro la soglia prevista.

Le ricerche empiriche condotte su IT-PMS mostrano risultati misurabili su più dimensioni.

Integrabilità

Su numerosi casi di integrazione (piattaforme proprietarie e terze):

L’analisi dei casi di indagine evidenzia una coerenza metodologica e una buona efficienza del framework di integrazione. Tutti i casi rispettano il vincolo della soglia di debito tecnico (TD ≤ 10), e gli indicatori SCR, SCSD e SCTD si mantengono costantemente sopra il 70%, con valori mediamente superiori all’80%.

Tutti i casi rispettano la soglia qualitativa definita per il debito tecnico, un dato che testimonia la maturità del framework architetturale adottato. Il mantenimento del TD entro la soglia, in combinazione con TTD costantemente contenuti, evidenzia che il sistema risponde positivamente a requisiti di manutenibilità e che le eventuali rifiniture post-integrazione richiedono effort limitati.

Manutenibilità e Resilienza

L’impatto della modifica si mantiene sempre ampiamente al di sotto della soglia prevista. Per ogni componente da modificare, il cambiamento si propaga sempre ad un numero di componenti minori di tre.

Le tecniche di information hiding applicate hanno reso relativamente lasco l’accoppiamento tra componenti: le modifiche in una componente non si propagano sulle componenti collegate, e ogni componente gestisce una specifica informazione del sistema.

Il degrado della qualità del software a seguito della manutenzione è stato misurato dal debito tecnico lasciato dopo le modifiche. IT-PMS, in quanto ULSS, deve sopravvivere per almeno un ventennio nonostante i numerosi cambiamenti richiesti dalle evoluzioni tecnologiche e delle richieste delle parti interessate.

Piattaforma guidata dai processi, non dal codice
In IT-PMS l’evoluzione dell’ecosistema avviene circoscrivendo le modifiche ai processi di business. Questo riduce tempi, costi e rischio di regressioni.

ULSS progettato per cambiare
IT-PMS nasce per essere modificata frequentemente senza degradare la qualità, caratteristica essenziale per ecosistemi digitali reali.

Eterogeneità tecnologica come requisito, non come problema
A differenza delle piattaforme chiuse, IT-PMS integra sistemi legacy, SaaS e piattaforme terze senza imporre stack tecnologici.

Qualità misurata, non dichiarata
Ogni integrazione ed evoluzione è accompagnata da misure quantitative su tempi, debito tecnico e impatto delle modifiche.

Per i fornitori

• vendita come servizi digitali sistemi o componenti software legacy;
• vendita di servizi in nuovi contesti di mercato;
• flessibilità nei metodi di tariffazione e piani di pagamento;
• gestione di metodi di tariffazione e piani di pagamento out-of-the-box;
• gestione della fatturazione e degli incassi out-of-the-box;
• possibilità di co-produzione di nuovi servizi.

Per i consumatori

• facilità di ricerca del servizio desiderato;
• facilità di acquisto del servizio selezionato;
• possibilità di richiedere servizi che non siano nel catalogo;
• possibilità di richiedere servizi erogati in coalizione.

Dai risultati emerge che:

• l’industrializzazione richiede ulteriore consolidamento;
• alcune funzioni avanzate di governance possono essere raffinate;
• la crescita dell’ecosistema porrà nuove sfide di scala.

Questi aspetti sono coerenti con la natura sperimentale del progetto.