Large Language Models for Analyzing Enterprise Architecture Debt in Unstructured Documentation

1. Il Problema

L'Architettura Aziendale (EA) guida la progettazione e l'evoluzione dei sistemi IT di un'organizzazione. Tuttavia, nel tempo, le architetture accumulano inefficienze note come Debito di Architettura Aziendale (EA Debt), derivanti da decisioni di progettazione subottimali, tecnologie obsolete o componenti disallineati. Questi problemi si manifestano spesso come "cattivi odori" (EA Smells), che sono sintomi riconoscibili di un potenziale accumulo di debito.

Attualmente, l'identificazione e l'analisi di questi debiti sono processi prevalentemente manuali, basati su workshop, interviste e valutazioni di esperti. Questo approccio presenta diverse criticità:

• Scalabilità: Non riesce a gestire la crescente complessità e il volume dei sistemi IT moderni.
• Dati non strutturati: La maggior parte delle soluzioni automatizzate esistenti si concentra su artefatti strutturati (modelli, grafi della conoscenza), ignorando una vasta quantità di conoscenza architettonica risiedente in documenti non strutturati (descrizioni di processi, note di riunioni, strategie, policy).
• Rischio: La mancata analisi di questi documenti porta a una rilevazione tardiva dei problemi, aumentando costi e riducendo l'agilità aziendale.

L'obiettivo dello studio è colmare questo divario utilizzando i Large Language Models (LLM) per rilevare e quantificare l'EA Debt direttamente da documentazione non strutturata, con un focus specifico sul livello aziendale (business layer).

2. Metodologia

La ricerca adotta un approccio Design Science Research (DSR) per progettare, implementare e valutare un prototipo automatizzato.

Scope e Requisiti

• Obiettivo: Rilevare 12 specifici "EA Smells" nel livello business (es. "Contraddizione negli input", "Soluzione temporanea", "Mancanza di documentazione").
• Vincoli: Il sistema deve operare in un ambiente on-premise per garantire la protezione dei dati (nessuna chiamata API esterne), su hardware limitato (Windows, 16 GB RAM, solo CPU).
• Input: Documenti non strutturati (.docx, .pdf) come descrizioni di processi e policy.

Sviluppo dell'Artefatto

1. Selezione del Modello: È stato scelto LLaMA-3.2-3B-Instruct per la sua capacità di seguire istruzioni e la compatibilità con tecniche di fine-tuning efficienti (PEFT) che funzionano su CPU.
2. Strategia di Addestramento:
   • Utilizzo di LoRA (Low-Rank Adaptation) per addestrare il modello con risorse limitate, aggiornando solo un piccolo set di parametri.
   • Dataset: Costruito con 960 istanze (80 esempi per ciascuno dei 12 smells) coprenti 8 domini aziendali (es. Order-to-Cash, Procure-to-Pay). Il dataset è bilanciato (50% positivi, 50% negativi).
   • Pipeline: Ingestione del documento -> Preprocessing (chunking con sovrapposizione) -> Rilevamento smells tramite LLM -> Generazione report con tracce testuali.
3. Baseline di Confronto: Per valutare le prestazioni, è stato creato un Custom GPT (basato su OpenAI) configurato con gli stessi 12 smells e lo stesso prompt di sistema, utilizzando lo stesso dataset per l'apprendimento contestuale (few-shot) senza aggiornamenti parametrici.

Valutazione

Lo studio è stato condotto su un caso studio con un'azienda fittizia ("NextTech") utilizzando 30 documenti aziendali sintetici ma realistici, annotati manualmente con "ground truth".

• Protocolli di test:
  1. Elaborazione singola (Run 1).
  2. Batch di 10 documenti (Run 2).
  3. Batch di 30 documenti (Run 3, solo per il modello on-premise).
• Metriche: Accuratezza, Precisione, Recall, F1-score, False Positive Rate (FPR), tempo di elaborazione e adattabilità.

3. Contributi Chiave

1. Analisi del Problema e Requisiti: Definizione chiara dei requisiti funzionali e non funzionali per l'uso degli LLM nel rilevamento del debito architetturale in contesti con vincoli di dati e hardware.
2. Artefatto Prototipale: Sviluppo di un sistema on-premise che utilizza un LLM fine-tuned (LLaMA-3.2-3B) per identificare automaticamente 12 specifici EA Smells da documenti non strutturati.
3. Valutazione Empirica Comparativa: Un'analisi dettagliata che confronta un modello locale (risorse limitate, privacy-first) con un modello proprietario cloud (GPT), evidenziando compromessi tra accuratezza, velocità, privacy e scalabilità.

4. Risultati

I risultati hanno evidenziato un chiaro trade-off tra i due approcci:

• Modello On-Premise (LLaMA - Modello A):

  • Prestazioni: Bassa precisione (0.26 - 0.19) e alto tasso di falsi positivi (FPR 0.95 - 1.00). Tende a sovrastimare il numero di smells rilevati.
  • Comportamento: Molto sensibile (alta recall teorica, ma con molti errori), spesso genera spiegazioni generiche e commette errori di classificazione (es. confondere "Soluzione temporanea" con "Big Bang").
  • Tempo: Molto lento (~120 secondi per documento su CPU).
  • Scalabilità: Gestisce batch di 30 documenti, ma senza migliorare la precisione.

• Modello Cloud/Proprietario (Custom GPT - Modello B):

  • Prestazioni: Alta precisione (0.88 - 0.89) e basso FPR (0.09). È molto più conservativo e stabile.
  • Comportamento: Tende a perdere alcuni smells reali (Recall moderata, ~0.22-0.25), ma quando rileva un problema, è quasi sempre corretto.
  • Tempo: Estremamente veloce (~2 secondi per documento).
  • Limiti: Non può elaborare batch superiori a 10 documenti a causa dei limiti dell'interfaccia; mostra "perdita di contesto" (context leakage) tra documenti nello stesso batch.

• Qualità delle Raccomandazioni: Entrambi i modelli generano raccomandazioni, ma il modello GPT tende a fornire consigli più specifici e granulari (es. KPI specifici), mentre il modello LLaMA offre suggerimenti più generici.

5. Significato e Implicazioni

Lo studio dimostra che:

1. Fattibilità Tecnica: Gli LLM possono essere utilizzati per estrarre segnali di debito architetturale da testi non strutturati, un'area precedentemente trascurata dagli strumenti automatizzati.
2. Trade-off Privacy vs. Prestazioni: Esiste un compromesso significativo tra la protezione dei dati (modello on-premise) e l'accuratezza/velocità (modello cloud). Il modello locale, pur essendo meno preciso, offre un'alternativa valida per ambienti con stringenti requisiti di sicurezza dei dati, agendo come strumento di "triage" per segnalare potenziali aree di interesse da verificare manualmente.
3. Ruolo nell'EA Governance: Gli LLM non dovrebbero essere visti come diagnostici definitivi, ma come strumenti di supporto decisionale all'interno di flussi di lavoro "human-in-the-loop". Gli architetti devono validare i risultati, specialmente considerando l'alto tasso di falsi positivi dei modelli locali.
4. Direzioni Future: Per migliorare l'efficacia, è necessario:
   • Migliorare la qualità dei dataset di addestramento e le annotazioni (multi-annotatore).
   • Sviluppare pipeline ibride che combinino l'analisi testuale non strutturata con repository strutturati (es. modelli ArchiMate, Knowledge Graphs).
   • Implementare meccanismi di "grounding" (citazione diretta delle fonti) per ridurre le allucinazioni e migliorare la tracciabilità.

In conclusione, mentre i modelli on-premise attuali non sono ancora pronti per un uso produttivo autonomo a causa della bassa precisione, la ricerca apre la strada a strumenti di governance dell'architettura più proattivi, capaci di sfruttare la vasta mole di documentazione aziendale finora inutilizzata.