Strumenti per l’architettura aziendale: come scegliere quelli giusti

Gli strumenti per l’architettura aziendale consentono di mappare capacità, applicazioni, dati e processi e di comprenderne le relazioni. La scelta dipende dalle esigenze: creare un inventario, definire standard e roadmap o basarsi su dati concreti per capire come si svolge il lavoro.

Un repository chiarisce che cosa è presente e come dovrebbe integrarsi. Non mostra necessariamente che cosa accade quando le persone utilizzano quei sistemi e processi.

Questa distanza non è una mancanza di chi si occupa di mantenere l’architettura. Il lavoro cambia, i documenti invecchiano e i sistemi operativi registrano dati che un modello statico, da solo, non può fornire.

A cosa servono gli strumenti di architettura aziendale?

Gli strumenti di architettura aziendale aiutano a descrivere un’organizzazione e le relazioni tra le sue parti. In genere supportano tre attività principali.

• Inventario: registrare capacità, processi, applicazioni, dati, responsabili e dipendenze.
• Standard e roadmap: applicare framework come TOGAF o ArchiMate per valutare le modifiche proposte e pianificare il passaggio dallo stato attuale a quello desiderato.
• Analisi: capire come opera l’organizzazione e quale impatto potrebbe avere una modifica.

Un repository può aiutare a rispondere a domande come quali applicazioni supportano una capacità o quali processi dipendono da un sistema. Può anche fornire ai team un vocabolario condiviso per discutere le modifiche.

Un repository di architettura, però, non spiega automaticamente come si svolge il lavoro nella pratica. Il nome, il responsabile e la descrizione di un processo non indicano quante volte i casi seguono un percorso eccezionale, dove si fermano in attesa o quanti cicli di approvazione attraversano.

Questa distinzione è alla base del confronto che segue: gli strumenti di repository descrivono ciò che è presente e ciò che si intende fare; ProcessMind aiuta a verificare che cosa sta accadendo, secondo i dati dei Suoi sistemi.

Cosa valutare nel confronto tra software di architettura aziendale?

Confronti i software di architettura aziendale in base al lavoro che devono supportare, non soltanto alle funzionalità elencate sul sito del fornitore.

1. Repository e metamodelo: lo strumento rappresenta capacità, processi a più livelli, applicazioni, dati e relazioni senza richiedere soluzioni alternative?
2. Supporto dei framework: supporta ArchiMate e TOGAF nel prodotto oppure offre soprattutto elementi per creare diagrammi?
3. Dettaglio dei processi: è possibile passare da un processo di alto livello a sottoprocessi, attività, gateway e varianti? Chieda di vedere un processo rappresentato a più livelli.
4. Collegamento ai dati: è possibile aggiornare o verificare una parte dell’architettura in base ai dati operativi, anziché affidarsi interamente agli aggiornamenti manuali?
5. Collaborazione e autorizzazioni: i team possono contribuire e rivedere il lavoro? È possibile consultare il repository senza una licenza da editor?
6. Hosting e residenza dei dati: dove vengono archiviati i dati, chi può accedervi e la soluzione soddisfa i Suoi requisiti?
7. Interoperabilità: è possibile esportare l’architettura e utilizzare API o formati aperti? Il lavoro deve poter essere trasferito.
8. Licenze: come vengono concessi in licenza editor, revisori e visualizzatori in sola lettura? Confronti il costo totale per tutte le persone che devono accedere, non solo per il team principale.

Presti particolare attenzione al dettaglio dei processi e al collegamento ai dati. Una mappa delle capacità può essere utile per la pianificazione, ma è più difficile tradurla in azioni se non la si può collegare ai processi svolti dalle persone.

Chieda ai fornitori di mostrare come viene mantenuto un modello, fino a che livello della gerarchia dei processi è possibile scendere e se le informazioni possono essere verificate rispetto ai dati. Le risposte chiariscono se lo strumento supporta il livello dei processi oppure si limita a registrarlo.

Queste verifiche aiutano a capire se serve un repository di architettura aziendale, un livello di dati concreti sui processi o entrambi.

Quale strumento di architettura aziendale è adatto a ciascuna esigenza?

Le diverse categorie di strumenti di architettura aziendale rispondono a esigenze diverse. Per un confronto utile, conviene partire dall’attività da svolgere, non dal numero di funzionalità. La tabella seguente applica gli otto criteri alle varie categorie e riporta per ultima la nostra soluzione.

Le suite EA orientate al repository, come Software AG ARIS, Bizzdesign, MEGA HOPEX, Orbus iServer e Sparx EA, sono pensate per repository di architettura, framework, governance e gestione del portafoglio. Sono adatte alle organizzazioni che hanno il mandato e le risorse per gestire un programma formale di architettura.

Le piattaforme di gestione EA, come SAP LeanIX, offrono un approccio SaaS agli inventari di applicazioni e capacità. Possono essere adatte alle organizzazioni che desiderano una visione del proprio parco applicativo e un metodo strutturato per gestire l’architettura aziendale.

Gli strumenti per diagrammi e ArchiMate possono essere una scelta pratica quando l’esigenza principale è creare e condividere modelli. Archi è un’opzione gratuita, open source e nativa per ArchiMate. Anche i flussi di lavoro basati su Visio possono servire a documentare l’architettura. Verifichi che le funzionalità di repository, collaborazione e governance soddisfino le Sue esigenze.

I moduli ITSM e di piattaforma possono essere adatti quando le viste di architettura devono affiancare i sistemi già in uso. Verifichi che il livello di dettaglio della modellazione e le funzioni di repository del modulo siano adeguati alle pratiche di architettura adottate.

ProcessMind risponde a una domanda diversa: come si svolge il lavoro e che cosa mostrano i dati operativi? Collega i flussi di valore e i livelli di processo ai dati degli eventi già registrati dai sistemi, così da poter consultare l’architettura fino alle attività svolte dalle persone e verificarla rispetto a ciò che è realmente accaduto.

Non esiste una soluzione migliore in assoluto per tutte queste categorie. Scelga lo strumento più adatto all’attività da svolgere per prima. Se la priorità è capire il comportamento dei processi, inizi dai dati concreti del livello dei processi e aggiunga un repository quando il programma di architettura ne avrà bisogno.

Perché l’architettura aziendale si allontana dalla realtà?

L’architettura aziendale può allontanarsi dalla realtà quando il repository dipende da aggiornamenti manuali e il modello resta distante dal lavoro che dovrebbe descrivere.

Tre fattori strutturali rendono più probabile questo scostamento:

• Il repository viene aggiornato manualmente. Le modifiche a processi, applicazioni e responsabilità devono essere inserite e sottoposte a revisione.
• I benefici possono arrivare in seguito. I team potrebbero aver bisogno di un inventario accurato per un audit o un’analisi d’impatto futuri, mentre il lavoro di aggiornamento va svolto subito.
• Il modello descrive le intenzioni, non il comportamento. Un processo documentato potrebbe non mostrare le rilavorazioni, le eccezioni, i passaggi di consegne o le attese che si verificano nei casi reali.

Le mappe delle capacità e gli inventari delle applicazioni sono utili per comprendere l’organizzazione a grandi linee. Tuttavia, chi svolge il lavoro potrebbe non riconoscere le attività quotidiane in un modello che si ferma al livello delle capacità o delle applicazioni.

Le differenze emergono spesso nei dettagli: varianti di processo, passaggi di consegne, approvazioni ripetute e tempi di attesa. Un repository può registrare il processo previsto, ma serve un’altra fonte di dati per verificare se la descrizione corrisponde ancora al comportamento operativo.

Un’architettura in cui nessuno si riconosce presenta uno di due problemi. Le persone la aggirano perché il modello prevede un’approvazione, mentre il team sa che sono tre, e così smettono di consultarlo. Oppure resta un artefatto di conformità, aggiornato prima di un audit e ignorato nel resto del tempo. In entrambi i casi, il problema non è lo strumento, ma la distanza tra il modello e il lavoro.

Una governance più efficace può aiutare a mantenere aggiornato il repository. Da sola, però, non fornisce dati indipendenti per verificare che il modello corrisponda a ciò che accade. Collegare i modelli di processo ai dati operativi offre un modo per controllare questo livello.

Come si collega l’architettura al lavoro delle persone?

Descrivere nel dettaglio il luogo in cui si svolge il lavoro aiuta i team a riconoscersi nell’architettura e offre un riferimento da verificare rispetto ai dati operativi.

Una mappa delle capacità descrive ciò che l’organizzazione deve fare. Un modello di processo può mostrare come viene svolto il lavoro, chi ne è responsabile e come sono collegati i sottoprocessi. Più chiaro è il collegamento tra i livelli, più semplice è passare dalla vista architetturale al lavoro che rappresenta.

Un Event Log aggiunge dati sui casi completati. Può mostrare quali attività si sono svolte, in quale ordine e quanto tempo hanno richiesto i casi. Confrontare questi dati con un modello di processo aiuta a individuare le differenze tra il comportamento osservato e il percorso documentato.

Questo non significa che sia possibile ricavare ogni parte dell’architettura aziendale dai dati degli eventi. Le decisioni sul portafoglio, gli standard e le scelte sullo stato desiderato richiedono comunque pratiche di architettura e governance. I dati possono fornire una base verificabile per il livello dei processi, non sostituire l’intero repository.

Il dettaglio dei processi, ricavato da dove si svolge il lavoro, evita entrambi i problemi. Quando l’architettura arriva fino alle attività, ai passaggi di consegne e ai tempi di attesa, il team può riconoscere nel modello il proprio lavoro e il responsabile può vedere quale decisione rientra nelle sue responsabilità. Uno strumento EA può contenere il portafoglio; è il lavoro stesso a collegarlo alle persone che lo rendono concreto.

I dati forniscono un riscontro che un revisore può verificare. I tempi di attesa nel modello dovrebbero corrispondere a quelli registrati nell’Event Log; quando non coincidono, la discussione riguarda il processo, non il diagramma. È un confronto più utile di un ulteriore giro di aggiornamenti.

Cambia anche l’ordine del lavoro. Invece di completare prima il repository e sperare che i dettagli arrivino in seguito, misuri un processo, lo colleghi al livello superiore e lasci che il modello guadagni credibilità dove può essere verificato. Questo primo intervento è abbastanza circoscritto da poter essere completato e offre al programma di architettura un esempio concreto, anziché un piano.

Può consultare la documentazione dell’architettura dei processi per vedere come vengono rappresentati i livelli e le relazioni tra processi. Per la parte relativa ai dati, legga come creare un Event Log per il Process Mining.

Perché ProcessMind adotta un approccio diverso all’architettura?

ProcessMind affronta l’architettura partendo dagli aspetti che è possibile verificare con i dati. È una differenza di approccio intenzionale, non una versione ridotta di ciò che fa un repository.

La gestione del portafoglio, del ciclo di vita delle applicazioni e della governance degli standard sono ambiti propri dei repository. ARIS, SAP LeanIX, Bizzdesign, MEGA HOPEX, Orbus e Sparx svolgono bene questo lavoro. Qui trova spazio il livello dei processi.

Ci concentriamo sul livello dei processi: flussi di valore, livelli di processo configurabili, responsabilità RACI, flussi di lavoro di governance e un portale per i visualizzatori, collegati ai dati degli eventi. Questo livello risponde autonomamente alle domande sui processi e si affianca naturalmente a un repository quando il programma di architettura ne ha bisogno.

Come scegliere uno strumento di architettura aziendale?

Scelga in base alle domande a cui i team devono rispondere e al lavoro di architettura da sottoporre a governance.

• Servono gestione del portafoglio, standard e roadmap: consideri una suite EA completa e pianifichi le risorse e i processi necessari per mantenere il repository.
• Serve un inventario SaaS di applicazioni e capacità: valuti una piattaforma di gestione EA come SAP LeanIX in base ai requisiti di inventario e governance.
• Servono risposte sul comportamento dei processi: inizi dai modelli di processo e dai dati operativi, quindi valuti se serve anche un repository più ampio.
• La scelta è ancora aperta: individui le domande che i team pongono più spesso. Questo aiuterà a decidere se iniziare da un repository, dai dati sui processi o da entrambi.

Se sta confrontando strumenti orientati al repository, consulti il nostro confronto delle alternative ad ARIS. Se sta valutando come interagiscono modelli e dati, legga come si integrano la modellazione dei processi e il Process Mining.

Inizi da dove può ottenere dati concreti. Aggiunga il repository quando il programma di architettura avrà bisogno delle sue più ampie funzionalità di governance e gestione del portafoglio.

Qual è il ruolo di ProcessMind?

ProcessMind è un livello dedicato ai processi e ai flussi di valore, che collega l’architettura ai dati su come si svolge il lavoro.

Mentre un repository raccoglie il portafoglio e gli standard, ProcessMind gestisce il livello dei processi e i dati che lo documentano. I team che utilizzano entrambi possono verificare i dettagli dei processi nell’architettura; chi ha bisogno soltanto del livello dei processi può utilizzarlo autonomamente.

Può organizzare i processi in livelli configurabili, modellarli in BPMN 2.0, assegnare responsabilità RACI e utilizzare flussi di lavoro di governance e un portale per i visualizzatori. Può inoltre collegare i modelli di processo ai dati degli eventi per confrontare i processi documentati con il comportamento osservato. La simulazione dei processi consente di esplorare una modifica nel modello prima di intervenire sul processo in produzione.

Per approfondire le funzionalità di ProcessMind dedicate all’architettura dei processi, visiti la pagina sull’architettura dei processi aziendali. Può anche leggere informazioni sulla governance dei processi e scoprire che cos’è il Process Mining.