Executive Summary
Wenn Unternehmen wachsen und ihre IT-Abläufe reifer werden, kann die grundlegende Architektur ihrer IT-Service-Management-(ITSM)-Plattform entscheidend sein, um langfristige Agilität, effektive Integration und einen hohen Servicestandard zu erreichen.
Einige ITSM-Lösungen wie HaloITSM verwenden ein vereinfachtes Single-Table-Modell, bei dem alle Service-Datensätze in einer einzigen vereinheitlichten Tabelle gespeichert werden. Ivanti Neurons for ITSM setzt dagegen auf eine fortschrittlichere, objektorientierte Architektur, die unterschiedliche ITIL-Prozesse (Incidents, Problems, Changes und Requests) in separate, modulare Entitäten unterteilt.
Dieses Whitepaper untersucht die Schwächen des Single-Table-Ansatzes, insbesondere in komplexen Unternehmensumgebungen, und zeigt die Vorteile einer stärker strukturierten, skalierbaren ITSM-Architektur auf.
| Funktion/Fähigkeit | Einzeltabelle | Modul |
|---|---|---|
| Workflow-Flexibilität | Begrenzt | Hoch |
| ITIL-Ausrichtung | Grundlegend | Umfassend |
| Isolierung von Anpassungen | Gering | Hoch |
| Reporting-Granularität | Mittel | Fortschrittlich |
| Integrationskomplexität | Hoch | Gering |
| Skalierbarkeit | Mittel | Hoch |
| Performance | Mittel | Hoch |
| Sicherheit | Komplex | Vereinfacht |
1. Einführung
Die ITSM-Landschaft entwickelt sich rasant weiter, mit steigenden Anforderungen an Automatisierung, Integration und nutzerzentrierte Servicebereitstellung. Einfachheit kann für kleine Teams oder Start-ups ein Vorteil sein, wird jedoch mit zunehmendem Unternehmenswachstum häufig zur Belastung. Dieses Whitepaper untersucht die architektonischen Kompromisse zwischen dem Single-Table-Modell von HaloITSM und dem modularen Design von Ivanti Neurons.
2. Das Single-Table-ITSM-Modell verstehen
In Plattformen, die eine Einzeltabelle verwenden, werden alle Service-Datensätze – ob Incidents, Service Requests, Problems oder Changes – in einer einzigen „Tickets“-Tabelle gespeichert.
Nachfolgend ist eine Single-Table-ITSM-Architektur mit sechs Feldern dargestellt:
| Datensatz-Nr. | Datensatztyp | Name des Verantwortlichen | Betreff | Vertraulich | Priorität |
|---|---|---|---|---|---|
| 1 | Incident | Don | VPN-Fehler | 2 | |
| 2 | Change | Jamie | SQL Server patchen | Niedrig | |
| 3 | HR-Fall | Harold | Meine Vergütung ist falsch | Ja | Dringend |
| 4 | Incident | Don | SAP-Ausfall | 1 | |
| 5 | Request | Patricia | Neuer Computer | Niedrig |
Als Erstes fällt das Feld „Datensatztyp“ auf. Es bestimmt, welche Daten im Datensatz gespeichert werden, und ist das primäre Feld, um den Zugriff auf diesen Feldtyp einzuschränken.
Sicherheit
Zunächst betrachten wir das Sicherheitsframework für diese Tabelle. Die folgende Definition beschreibt die Zugriffsberechtigungen für Harold.
Harold erhält vollständigen Zugriff auf Tabelle = „Tickets“ und Datensatztyp = „HR-Fall“.
Diese Sicherheitsregel stellt sicher, dass Harold auf die Tickets-Tabelle zugreifen und ausschließlich HR-Fälle einsehen kann.
Betrachten wir nun diese Regel für Don, der in der IT arbeitet …
Don erhält vollständigen Zugriff auf Tabelle = „Tickets“.
Hier entsteht eine Herausforderung, da Don als IT-Mitarbeiter uneingeschränkten Zugriff auf die gesamte Tabelle hat. Dadurch könnten Don unbeabsichtigt vertrauliche HR-Falldaten offengelegt werden.
Die Regel sollte lauten:
Don erhält vollständigen Zugriff auf Tabelle = „Tickets“ und Datensatztyp NICHT = „HR-Fall“.
Diese Komplexität nimmt zu, wenn Don vollständigen Zugriff auf „Incidents“, aber nur Lesezugriff auf „Changes“ erhalten soll.
Konfiguration
Auch die Konfiguration in einer vereinheitlichten Tabellenumgebung kann komplex sein, da Felder innerhalb derselben Tabelle je nach Datensatztyp unterschiedliche Anforderungen erfüllen müssen.
Beim Betrachten unserer Tabelle erkennen wir verschiedene Prioritätstypen für die jeweiligen Datensatztypen. Incidents entsprechen dem ITIL-Standard und verwenden ein numerisches System (1, 2, 3, 4), während Changes und Requests als niedrige, mittlere oder hohe Priorität kategorisiert werden. HR-Anfragen hingegen werden als niedrig, hoch oder dringend eingestuft.
Wie lässt sich diese Komplexität implementieren und verwalten? Ein Freitextfeld reduziert zwar Datenintegrität und Standardisierung, doch eine Lookup-Tabelle mit Datensatztypfiltern ist vorzuziehen. Dennoch bleibt die Herausforderung gemischter Datentypen bestehen, was Reporting sowie Feld- und Tabellenpflege erschwert.
Die Konfiguration in einer gemeinsam genutzten Einzeltabelle ist komplexer, da alle Konfigurationsänderungen alle Datensatztypen berücksichtigen müssen. Beispielsweise ist das Feld „Vertraulich“ für HR-Fälle erforderlich, nicht jedoch für andere Datensatztypen. Wäre „HR-Fall“ eine eigene Tabelle, könnten Sie das Feld einfach auf Tabellenebene verpflichtend machen. Wenn wir diese Änderung in einer Einzeltabelle vornehmen, wird dieses Feld auch für Incidents, Changes und Requests verpflichtend, obwohl es dort nicht benötigt wird. Die Lösung besteht darin, es programmatisch über eine Feld-Geschäftsregel als Pflichtfeld durchzusetzen, was zusätzliche Definitionen und weiteren Administrationsaufwand erfordert.
Nehmen wir nun an, ein Legal-Team möchte eine benutzerdefinierte Anwendung für rechtliche Anfragen erstellen. In einer Single-Table-Architektur müsste der Datensatztyp „Legal“ lauten, und einige Felder könnten wiederverwendet werden (z. B. „Betreff“, „Beschreibung“, „Vertraulich“). Gleichzeitig benötigt Legal zusätzliche Pflichtfelder: „Extern“ (ja/nein), „Rechtsverfahren“ (ja/nein) usw. Diese Felder müssen der Tickets-Tabelle, den Formularen und dem Workflow hinzugefügt werden. Die zusätzlichen Felder erfordern sorgfältige Planung, damit bestehende Datensatztypen, Sicherheitsdefinitionen und Geschäftsregeln nicht beeinträchtigt werden.
Performance und Skalierbarkeit
Eine Single-Table-Architektur startet zwar effizient, da sie mit weniger Datensätzen und OOTB-Feldern auskommt, ihre Performance kann jedoch mit wachsendem Datensatzvolumen nachlassen – sofern Datenbankhygiene und Indexierung nicht konsequent gepflegt werden. Darüber hinaus kann die Einbindung benutzerdefinierter Felder potenzielle Performance-Einbußen weiter verstärken.
Allgemein gelten für Datenbanktabellen folgende Best Practices:
- Vermeiden Sie unnötige Tabellenfelder.
- Normalisieren Sie Daten, wo möglich, um redundante Felder zu reduzieren.
- Fragen Sie nur die Felder ab und geben Sie nur die Felder zurück, die Sie benötigen.
- Indexieren Sie Felder in der Tabelle korrekt, um die Performance zu optimieren.
Wie stellt ein ITSM-System mit Single-Table-Ansatz Performance und Skalierbarkeit sicher?
Ein Single-Table-Datenmodell vereinfacht zwar einige Aspekte des IT-Service-Managements, bringt jedoch Einschränkungen mit sich, die Sie kennen sollten.
3. Das Argument für eine modulare ITSM-Architektur
Eine modulare ITSM-Architektur modelliert jeden ITSM-Prozess als eigenständiges Business-Objekt und verknüpft ihn mit anderen Business-Objekten (Prozessen), beispielsweise Incident mit Problem oder Problem mit Change. Dieser modulare Ansatz orientiert sich eng an ITSM-Prozessen und stellt sicher, dass Daten isoliert bleiben, was mehrere Vorteile bietet.
Prozessspezifische Workflows
In einem modularen Tabellendesign können Workflows, SLAs, Genehmigungen und Geschäftsregeln eindeutig einer Tabelle (einem Prozess) zugeordnet sein. Es ist keine spezielle Filterung erforderlich, um zu verhindern, dass der Workflow für einen Datensatz eines anderen Typs (ITSM-Prozess) ausgeführt wird. Beispiel: Eskalationskriterien werden für einen Incident bei Verletzung eines SLA ausgeführt.
Mit diesem Ansatz gelingt die Ausrichtung an ITIL-Best Practices und Governance reibungsloser, da die Ausführung für Nicht-ITIL-Prozesse (wie HR-Fälle oder Facility-Arbeitsaufträge) wirksam verhindert wird.
Verbesserte Sicherheit
Durch die Trennung von Tabellen nach Prozess erhöhen Sie die Sicherheit und verringern das Risiko eines unbeabsichtigten Zugriffs auf sensible Daten. Der Zugriff wird nur ausdrücklich autorisierten Personen gewährt; zusätzliche Sicherheitsmaßnahmen lassen sich gezielt auf bestimmte Daten und Datensätze anwenden.
Darüber hinaus stellt separate Tabellensicherheit sicher, dass Reporting und Export den standardmäßigen Tabellensicherheitsregeln folgen statt komplexeren Sicherheitsmechanismen auf Zeilenebene.
Erweiterte Anpassungsmöglichkeiten
Prozessspezifische Tabellen bieten mehr Konfigurationsflexibilität und stellen sicher, dass Änderungen in einem Prozess keine anderen Prozesse (oder breit genutzte Felder) beeinträchtigen. Eindeutige Feldkonfigurationen auf Tabellenebene machen komplexe Geschäftsregeln überflüssig und unterstützen anspruchsvollere Szenarien, etwa CAB-Genehmigungen für Changes oder Root-Cause-Analysen für Problems.
Fortschrittliches Reporting & Analytics
Mit prozessorientierten Tabellen, die strukturierte Daten enthalten, werden granulareres Reporting, Trendanalysen und KPI-Tracking über ITIL-Domänen hinweg deutlich praktikabler, und die Einbindung zugehöriger Daten wird vereinfacht. Ein Beispiel ist ein Bericht, der alle durch Changes gelösten Incidents darstellt.
Dies erleichtert außerdem Compliance-Reporting und Executive-Dashboards über Prozess- oder Enterprise-Business-Objekte hinweg (z. B. HR-Fälle, Facility-Arbeitsaufträge).
Bessere Integration & Erweiterbarkeit
Die optimierte Integration mit externen Systemen umfasst einzelne Tabellen, die auf Prozesse ausgerichtet sind. Diese Methode vereinfacht nicht nur die API-Bereitstellung, sondern erhöht auch die Sicherheit, da APIs expliziten Zugriff auf die API der Tabelle benötigen.
Dies ermöglicht Low-Code-/No-Code-Erweiterbarkeit für schnellere Innovation sowie die Flexibilität, bestehende Business-Objekte zu erweitern oder neue zu erstellen.
4. Zu stellende Fragen
Eine Single-Table-Datenstruktur kann künftiges Wachstum einschränken. Bei der Bewertung von ITSM-Systemen ist es entscheidend, dass Sie die zugrunde liegende Datenarchitektur genau verstehen.
Stellen Sie Ihrem ITSM-Anbieter die folgenden Fragen:
- Verwenden Sie separate Tabellen für Ihre ITSM-Prozesse, oder befinden sie sich in derselben Tabelle?
- Wie aufwendig ist die Wartung und Absicherung?
- Welche Auswirkungen hat das Hinzufügen einer neuen Funktion, etwa Legal Requests?
- Wie schwierig ist es, benutzerdefinierte Funktionen im Tool zu replizieren?
- Wie lange dauert es, ein benutzerdefiniertes Objekt zu erstellen?
- Wie aufwendig ist es, die Daten vor unbefugtem Zugriff zu schützen?
- Können Sie mir zeigen, wie neue Felder und neue Objekte hinzugefügt werden?
- Wie viele Personen werden benötigt?
- Welche Kosten entstehen?
- Werde ich Upgrades durchführen können?
5. Welche ITSM-Architektur ist die richtige für Sie?
Eine Single-Table-ITSM-Lösung wie HaloITSM ist ein guter Ausgangspunkt für Unternehmen, die schnell mit einer vereinfachten Benutzererfahrung starten möchten. Für ausgereifte IT-Organisationen auf Enterprise-Niveau können diese Lösungen jedoch Herausforderungen bei Wachstum und Skalierung verursachen.
Wenn Unternehmen sich an ITIL ausrichten, komplexe Workflows automatisieren und Integrationen über das digitale Ökosystem hinweg schaffen möchten, bietet eine modulare Architektur wie Ivanti Neurons for ITSM die Flexibilität, Skalierbarkeit und Kontrolle, die für langfristigen Erfolg erforderlich sind.