Riepilogo esecutivo
Man mano che le organizzazioni crescono e le loro operazioni IT maturano, l’architettura di base della loro piattaforma di IT Service Management (ITSM) può fare la differenza nel raggiungere agilità a lungo termine, integrazione efficace e un elevato standard di servizio.
Alcune soluzioni ITSM, come HaloITSM, utilizzano un modello semplificato a tabella unica (che memorizza tutti i record di servizio in un’unica tabella unificata). Al contrario, Ivanti Neurons for ITSM adotta un’architettura orientata agli oggetti più avanzata, che segmenta processi ITIL distinti (incident, problemi, modifiche e richieste) in entità separate e modulari.
Questo white paper esamina i limiti dell’approccio a tabella unica, in particolare negli ambienti enterprise complessi, e mette in evidenza i vantaggi dell’adozione di un’architettura ITSM più strutturata e scalabile.
| Funzionalità/capacità | Tabella unica | Modulo |
|---|---|---|
| Flessibilità dei workflow | Limitata | Elevata |
| Allineamento a ITIL | Di base | Completo |
| Isolamento della personalizzazione | Basso | Elevato |
| Granularità del reporting | Moderata | Avanzata |
| Complessità dell’integrazione | Elevata | Bassa |
| Scalabilità | Moderata | Elevata |
| Prestazioni | Moderate | Elevate |
| Sicurezza | Complessa | Semplificata |
1. Introduzione
Il panorama ITSM si evolve rapidamente, con crescenti esigenze di automazione, integrazione ed erogazione dei servizi incentrata sull’utente. Sebbene la semplicità possa essere un vantaggio per piccoli team o startup, spesso diventa un limite man mano che le organizzazioni crescono. Questo documento esamina i compromessi architetturali tra il modello a tabella unica di HaloITSM e il design modulare di Ivanti Neurons.
2. Comprendere il modello ITSM a tabella unica
Nelle piattaforme che utilizzano una tabella unica, tutti i record di servizio, che si tratti di incident, richieste di servizio, problemi o modifiche, vengono memorizzati in un’unica tabella “Ticket”.
Di seguito è illustrata un’architettura ITSM a tabella unica con sei campi:
| Record n. | Tipo di record | Nome proprietario | Oggetto | Riservato | Priorità |
|---|---|---|---|---|---|
| 1 | Incident | Don | Errore VPN | 2 | |
| 2 | Modifica | Jamie | Patch SQL Server | Bassa | |
| 3 | Caso HR | Harold | La mia retribuzione è errata | Sì | Urgente |
| 4 | Incident | Don | Errore SAP | 1 | |
| 5 | Richiesta | Patricia | Nuovo computer | Bassa |
La prima cosa che si nota è il campo denominato “Tipo di record”. Questo determina quali dati vengono memorizzati nel record ed è il campo principale per limitare l’accesso a quel tipo di campo.
Sicurezza
Per prima cosa, esamineremo il framework di sicurezza per questa tabella. La definizione seguente descrive le autorizzazioni di accesso per Harold.
Harold dispone di accesso completo alla tabella = “tickets” e tipo di record = “Caso HR”.
Questa regola di sicurezza garantisce che Harold possa accedere alla tabella dei ticket e visualizzare solo i casi HR.
Ora esaminiamo questa regola per Don, che lavora nell’IT…
Don dispone di accesso completo alla tabella = “tickets”.
Nasce un problema perché Don, un dipendente IT, ha accesso illimitato all’intera tabella. Questo potrebbe esporre inavvertitamente a Don dati riservati relativi ai casi HR.
La regola dovrebbe essere:
Don dispone di accesso completo alla tabella = “tickets” e tipo di record NON = “Caso HR”.
Questa complessità aumenta quando si concede a Don l’accesso completo a “incident”, ma solo l’accesso in lettura a “modifiche”.
Configurazione
Anche la configurazione in un ambiente a tabella unificata può essere complessa, perché i campi all’interno della stessa tabella possono avere requisiti diversi in base al tipo di record.
Osservando la nostra tabella, notiamo diversi tipi di priorità per i rispettivi tipi di record. Gli incident seguono lo standard ITIL, utilizzando un sistema numerico (1, 2, 3, 4), mentre modifiche e richieste sono classificate con priorità bassa, media o alta. Le richieste HR, invece, sono classificate come basse, alte o urgenti.
Come implementare e mantenere questa complessità? Sebbene un campo a formato libero riduca l’integrità e la standardizzazione dei dati, è preferibile una tabella di ricerca con filtri per tipo di record. Tuttavia, rimane la sfida dei tipi di dati misti, che complica il reporting e la manutenzione di campi e tabelle.
La configurazione in una tabella unica condivisa è più complessa, poiché tutte le modifiche di configurazione devono tenere conto di tutti i tipi di record. Ad esempio, il campo “Riservato” è obbligatorio per i casi HR, ma non per altri tipi di record. Se “Caso HR” fosse una tabella separata, sarebbe sufficiente rendere il campo obbligatorio a livello di tabella. Se applichiamo questa modifica in una tabella unica, quel campo diventa obbligatorio anche per incident, modifiche e richieste, che non lo richiedono. La soluzione consiste nell’imporlo programmaticamente come campo obbligatorio tramite una regola di business del campo, il che richiede una certa definizione e un’amministrazione aggiuntiva.
Supponiamo ora di avere un team legale che desidera creare un’applicazione personalizzata per le richieste legali. In un’architettura a tabella unica, il tipo di record dovrebbe essere “Legale” e alcuni campi potrebbero essere riutilizzati (ad es. “Oggetto”, “Descrizione”, “Riservato”). Tuttavia, il legale necessita anche di ulteriori campi obbligatori: “Esterno” (sì/no), “Procedimenti legali” (sì/no), ecc. Questi campi devono essere aggiunti alla tabella dei ticket, ai moduli e al workflow. I campi aggiuntivi richiedono un’attenta pianificazione per non impattare sui tipi di record, sulle definizioni di sicurezza e sulle regole di business esistenti.
Prestazioni e scalabilità
Sebbene un’architettura a tabella unica inizi in modo efficiente, gestendo un numero ridotto di record e campi OOTB, le sue prestazioni possono diminuire con l’aumentare del volume dei record, a meno che l’igiene del database e l’indicizzazione non vengano mantenute con attenzione. Inoltre, l’inclusione di campi personalizzati può aggravare ulteriormente potenziali cali di prestazioni.
In generale, le best practice per le tabelle di database prevedono di:
- Evitare campi di tabella non necessari.
- Normalizzare i dati ove possibile per ridurre i campi ridondanti.
- Interrogare e restituire solo i campi necessari.
- Indicizzare correttamente i campi nella tabella per ottimizzare le prestazioni.
In che modo un sistema ITSM con approccio a tabella unica garantisce prestazioni e scalabilità?
Sebbene un modello di dati a tabella unica semplifichi alcuni aspetti dell’IT service management, presenta limiti che è necessario comprendere.
3. Il caso a favore dell’architettura ITSM modulare
Un’architettura ITSM modulare è un’architettura in cui ogni processo ITSM è modellato come un oggetto di business distinto e correlato ad altri oggetti di business (processi); ad esempio, un incident a un problema, o un problema a una modifica. Questo approccio modulare segue da vicino i processi ITSM e garantisce l’isolamento dei dati, offrendo diversi vantaggi.
Workflow specifici per processo
In un workflow basato su un design modulare delle tabelle, SLA, approvazioni e regole di business possono essere unici per la tabella (processo). Non è necessario applicare filtri speciali per evitare che il workflow venga eseguito su un record di tipo diverso (processo ITSM). Ad esempio: criteri di escalation eseguiti su un incident in caso di violazione di un SLA.
Con questo approccio, l’allineamento alle best practice e alla governance ITIL è più fluido e impedisce di fatto l’esecuzione su processi non ITIL (come casi HR o ordini di lavoro per le facilities).
Sicurezza migliorata
Separando le tabelle per processo, si rafforza la sicurezza, mitigando il rischio di accesso involontario a dati sensibili. In questo caso, l’accesso viene concesso solo a chi è esplicitamente autorizzato, con misure di sicurezza aggiuntive facilmente adattabili per indirizzare dati e record specifici.
Inoltre, la sicurezza delle tabelle separate garantisce che reporting ed esportazione seguano regole di sicurezza standard a livello di tabella, anziché una sicurezza a livello di riga più complessa.
Personalizzazione avanzata
Le tabelle specifiche per processo offrono una maggiore flessibilità di configurazione, garantendo che le modifiche in un processo non interferiscano con gli altri (o con campi ampiamente utilizzati). Configurazioni di campo uniche a livello di tabella eliminano la necessità di regole di business complesse, estendendo il supporto a scenari più articolati, come le approvazioni CAB per le modifiche o l’analisi delle cause radice per i problemi.
Reporting e analytics avanzati
Con tabelle allineate ai processi che contengono dati strutturati, reporting granulare, analisi delle tendenze e monitoraggio dei KPI nei domini ITIL diventano più praticabili, mentre l’integrazione dei dati correlati risulta semplificata. Ad esempio, un report che mostra tutti gli incident risolti tramite modifiche.
Questo facilita anche il reporting di conformità e le dashboard direzionali tra processi o oggetti di business enterprise (ad es. casi HR, ordini di lavoro per le facilities).
Migliore integrazione ed estensibilità
L’integrazione semplificata con sistemi esterni include tabelle individuali allineate ai processi. Questo metodo non solo semplifica l’esposizione delle API, ma migliora anche la sicurezza (poiché le API richiedono l’accesso esplicito all’API della tabella).
Ciò consente l’estensibilità low-code/no-code per accelerare l’innovazione e offre la flessibilità di estendere gli oggetti di business esistenti o crearne di nuovi.
4. Domande da porre
Una struttura dati a tabella unica può limitare la crescita futura. Quando si valutano sistemi ITSM, è fondamentale comprendere a fondo l’architettura dati sottostante.
Poni al tuo fornitore ITSM le seguenti domande:
- Disponete di tabelle separate per i processi ITSM oppure sono tutti nella stessa tabella?
- Quanto è difficile mantenerla e proteggerla?
- Qual è l’impatto dell’aggiunta di una nuova funzione, come le richieste legali?
- Quanto è difficile replicare funzionalità personalizzate nello strumento?
- Quanto tempo sarà necessario per creare un oggetto personalizzato?
- Quanto è difficile proteggere i dati da accessi non autorizzati?
- Puoi mostrarmi come aggiungere nuovi campi e nuovi oggetti?
- Quante persone sono necessarie?
- Quale sarà il costo?
- Potrò effettuare l’upgrade?
5. Qual è l’architettura ITSM più adatta a te?
Una soluzione ITSM a tabella unica, come HaloITSM, è un buon punto di partenza per le organizzazioni che desiderano essere operative rapidamente con un’esperienza utente semplificata. Tuttavia, queste soluzioni possono creare sfide di crescita e scalabilità per operazioni IT mature di livello enterprise.
Quando le organizzazioni puntano ad allinearsi a ITIL, automatizzare workflow complessi e integrarsi nell’ecosistema digitale, un’architettura modulare come Ivanti Neurons for ITSM offre la flessibilità, la scalabilità e il controllo necessari per il successo a lungo termine.