ZURÜCK

Zuerst erschienen in der Ausgabe .public 02-2020

von Ludwig Scherr

Cloud in Behörden

In den letzten Beiträgen zu Cloud- und IT-Service-Management wurden – zum Teil behördenspezifische – Merkmale einer Cloud-Organisation behandelt. In diesem Beitrag geht es um die Vorgehensweise zur Entwicklung von IT-Services, für die es im behördlichen Umfeld keine grundsätzlichen Unterschiede zu kommerziellen IT-Service-Providern gibt. Vielmehr spielen IT-Service-spezifische Domänen eine Rolle, die sich von denen der Softwareentwicklung doch wesentlich unterscheiden.

Aus der Softwareentwicklung sind klassische Vorgehensmodelle wie Wasserfallmodell oder Spiralmodell bekannt, die durch agile Methoden wie Scrum oder Kanban ergänzt oder abgelöst werden. Klassischen und agilen Vorgehensweisen ist gemeinsam, dass am Anfang Anforderungen stehen, die die Basis für den Systementwurf bilden. Die Implementierung folgt dann dem Systementwurf und das Testen prüft, ob die Anforderungen in der notwendigen Qualität umgesetzt wurden.

Und wie sieht es nun bei den IT-Services aus? Im Grunde genommen gibt es in der Vorgehensweise keine Unterschiede zur Softwareentwicklung. Es müssen Anforderungen vorliegen, auf deren Basis ein Entwurf erstellt wird. Dieser wird umgesetzt und in einem Test der Qualitätskontrolle unterzogen. Der Unterschied liegt in den IT-Service-spezifischen Domänen.

Ein IT-Service ist wie folgt definiert: Ein vom Software-Provider bereitgestelltes Softwareprodukt wird zu einem nutzbaren Service weiterentwickelt, sodass aus einer zu installierenden Software ein vom Kunden direkt nutzbarer IT-Service entsteht. Auf diese Weise unterstützt der IT-Service die Geschäftsprozesse der Behörde „direkter“. Bei einer Behördenanwendung heißt das beispielsweise, dass das installierbare Softwarepaket des Software- Providers mit unterstützenden IT-Services – zum Beispiel virtuelle Server mit Netzanbindung und Storage, Datenbank, Applikationsserver, Loadbalancer etc. – zu einem kundengerichteten IT-Service gebündelt wird. Für einen vollständigen kundengerichteten IT-Service, der als Up-and-running-IT-Service zur aktiven Nutzung den Anwendern des Kunden bereitgestellt werden kann, müssen die IT-Service-spezifischen Domänen noch integriert werden. Auch in den IT-Service-spezifischen Domänen, wie User Help Desk, Incident-Management, Capacity-Management oder Service-Level-Management, müssen, analog der Softwareentwicklung, Design- und Build-Aktivitäten durchgeführt werden, um die neue Behördenanwendung zu einem vollständigen IT-Service zu machen.

Der Kern dieses Artikels beschäftigt sich mit den Schritten, die aus einem installierbaren Softwarepaket einen nutzbaren IT-Service mit definierten Service-Leveln machen.

Wie oben beschrieben stehen am Anfang eines IT-Services die Anforderungen – in diesem Fall die betrieblichen Anforderungen (Service- Level-Requirements), die der zu entwickelnde IT-Service erfüllen muss. In der Regel sind die Service-Level-Klassen, in die der neu zu erstellende IT-Service eingruppiert werden soll, bereits definiert.

Idealerweise wurde dieser neue IT-Service bereits im Vorfeld in das Portfoliomanagement für IT-Services eingebettet. Auch die Grundinformationen zum neuen IT-Service liegen seit Längerem vor, sodass eine ausgiebige Planung bereits im Vorfeld vor Übergabe des Software-Packages möglich war. Zu diesen Grundinformationen zählen, neben der Grobbeschreibung des IT-Services, Merkmale wie Anzahl Nutzer/Zeiteinheit, notwendige unterstützende IT-Services, Service-Level-Anforderungen des Kunden, geschätzter Realisierungsaufwand und ungefähre Realisierungsdauer etc. Im Service-Design und in der Realisierung des IT-Services gibt es drei Ebenen, die zu betrachten sind.

1. Die Sicht auf die technische Komponentenebene, die IT-Operations, den „Maschinenraum“, betrifft. In dieser Ebene wird der IT-Service aus technischer Sicht erbracht und gesteuert. Hier liegen beispielsweise die Ressourcen-Pools für die Service-Instanziierung oder das Monitoring für die Komponentenüberwachung.

Definite Media Library (DML) Bereich zur sicheren Speicherung von Softwarepaketen und zugehörigen Artefakten wie Dokumenten. Die DML ist Bestandteil des Configuration- Management-Systems. Service-Katalog Der Service-Katalog enthält Informationen zu allen verfügbaren und im Deployment befindlichen IT-Services. Kundengerichtete IT-Services sind im Bestellportal sichtbar, unterstützende IT-Services sind in kundengerichteten IT-Services integriert. Die im Service-Katalog hinterlegte Leistungsbeschreibung zu einem IT-Service informiert über den Leistungsumfang. Service-Inventar Das Service-Inventar enthält alle instanziierten IT-Services mit den zugrunde liegenden Unterlagen wie Bestellungen, Verträge oder Service-Level-Agreements. Die IT-Service-Instanzen sind mit den technischen Services/Komponenten in CMDB verknüpft. CMDB, CI und CI-Modell Die CMDB (Configuration-Management-Database) ist der Speicherort für CIs (Configuration-Items), die auf Komponentenebene die technischen Services und Komponenten identifizieren. CIs sind in einem CI-Modell eingebunden, das die Struktur und Vernetzung verschiedener CIs insgesamt darstellt.  IT-Service-Spezifische Domänen Gegenüber der Softwareentwicklung sind in der Entwicklung eines IT-Services andere Fachbereiche relevant. Das gelieferte Softwarepaket muss beispielsweise in das Configuration-Management, das Availability-Managment oder das Incident- und Problem-Management eingebettet werden. In der Softwareentwicklung stehen beispielsweise Software-Design und Schnittstellen im Vordergrund.

2. Die Service-Ebene, in der die technischen Komponenten zu einem IT-Service aggregiert und als solcher ganzheitlich gemanagt werden. Dies betrifft beispielsweise das Service-Inventar, in dem alle Service-Instanzen geführt werden.

3. Die, in der die Aspekte des Kunden und der IT-Service-Provider-Strategie betrachtet werden. Hier werden alle IT-Services eines Kunden aggregiert betrachtet. Sowohl die IT-Service-Verrechnung als auch das IT-Service-Portfoliomanagement sind hier angesiedelt. (siehe in diesem Zusammenhang auch den Artikel „Automatisierte Bereitstellung von IT-Services“, .public 02-2019) .Im Folgenden werden diese drei Ebenen näher betrachtet, und dabei wird auf die wichtigsten Inhalte eingegangen

Abbildung 1: Komponenten-Ebene in der IT-Serviceentwicklung

 Technische Komponentenebene (IT-Operations)

• Vom Software-Provider wird das Softwarepaket der Behördenapplikation mit der begleitenden Dokumentation bereitgestellt. Darin sind die Applikationsstruktur sowie die notwendigen Plattform- und Infrastrukturservices beschrieben, die die Grundlage für die einzelnen Komponenten der Behördenapplikation darstellen. So wird beispielsweise beschrieben, wie das Frontend der Behördenapplikation auf einen definierten Applikationsserver und das Backend auf eine definierte Datenbank aufgebracht wird. Das übergebene Softwarepaket wird mit allen Bestandteilen inklusive Dokumenten in das zentrale Repository für Software-Packages der Behördenapplikationen, der „Definitive Media Library“ (DML), eingebracht.
• Im Rahmen des Configuration-Managements wird für den neuen IT-Service ein Configuration-Item-Modell (CI-Modell) erzeugt, das die technische Sicht auf die einzelnen Configuration Items (CIs) im vernetzten Zusammenhang darstellt. Das CI-Modell findet Eingang in die Configuration-Management- Datenbank (CMDB), in der es als Modell hinterlegt wird.
• Für die Bereitstellung der einzelnen Applikationskomponenten und der darunterliegenden Plattform- und Infrastruktur- IT-Services werden Installations- und Konfigurationsskripte sowie -templates für die Produktionsstraße erstellt und als technische Blaupause für eine Instanziierung im Automatisierungsrepository hinterlegt. Hierdurch ist es möglich, die einzelnen Komponenten beziehungsweise Sub-Services automatisiert immer in gleicher Qualität und in verschiedenen Umgebungen bereitzustellen.
• Der neue IT-Service wird in die Überwachung (Monitoring) auf Komponentenebene integriert. Dies betrifft einerseits die Überwachung und andererseits die Messung: - Im Rahmen der Überwachung werden komponentenspezifische Alarme (Alerts) definiert und für eine Erzeugung von Komponenten- Tickets mit den in der CMDB hinterlegten CIs verknüpft. - Für die Messung werden Prozesskennzahlen- und SLA-Nachweis- relevante Prozeduren erstellt, so dass definierte Auswertungen und SLA-Nachweise im Betrieb generiert werden können. Dies betrifft auch den Aspekt der Verbrauchserfassung zur Messung der Verbräuche auf Basis des Service-Designs. Die Verbrauchsmengen werden an die Serviceebene kommuniziert.
• Die für den neuen kundengerichteten IT-Service eingerichteten Überwachungen und Messungen werden in die bestehenden Standardberichte auf Komponentenebene integriert.

Abbildung 2: Service-Ebene in der IT-Service-Entwicklung

Service Ebene

• Im Service-Katalog werden die Eintragungen für den freizuschaltenden Service aus der Service-Pipeline übernommen und um aktuelle Informationen, wie Leistungsbeschreibung und Servicebaum, ergänzt. Der Service-Katalog enthält somit alle notwendigen Informationen, die den IT-Service beschreiben.
• Im Service-Inventar werden Vorbereitungen getroffen, so dass nach einer erfolgreichen Service-Orchestrierung die Service- Instanzen mit Verlinkungen in die CMDB der technischen Service-Ebene eingetragen werden können.
• In der Service-Orchestrierung werden Skripte zur Aussteuerung der Service-Instanziierung auf Komponentenebene in den einzelnen Produktionsstraßen erstellt. Die beteiligten „Komponenten-Services“ sind aus dem Servicebaum des Service- Katalogs zu entnehmen. Instanziierte Services der Service- Ebene werden im Service-Inventar eingetragen.
• Das Service-Monitoring wird eingerichtet und mit dem Monitoring auf Komponentenebene verknüpft. So wird auf Basis von Komponenten-Alerts entschieden, wann ein Alert auf IT-Service- Ebene ausgelöst wird. Aufgrund eines IT-Service-Alerts kann ein Serviceticket eingestellt werden.
• Die Verbrauchsmengen aus der Komponentenebene werden hier zu Servicekosten ausgewertet und akkumuliert.
• Die erforderlichen Kapazitäten für die IT-Services werden aus den Service-Level-Anforderungen sowie aus dem prognostizierten Nutzungsvolumina ermittelt, im Kapazitätsplan hinterlegt und an die technische Ebene zur Berechnung der erforderlichen Zahl an IT-Service-Instanzen weitergeleitet. Die Auslastung und Performance von IT-Services wird verfolgt.
• Die erforderlichen Verfügbarkeiten werden ebenfalls aus den Service-Level-Anforderungen abgeleitet und mit der technischen Ebene abgestimmt. Die erforderlichen Kennzahlen werden in das Monitoring integriert, um einerseits dem Kunden die IT-Service-Verfügbarkeit nachweisen zu können und andererseits Hinweise für Optimierungsmaßnahmen ableiten zu können.
• Für den Service-Desk werden entsprechende Informationen wie Checklisten oder Lösungsbäume zur Behandlung oder Eingrenzung von auftretenden Störungen erstellt.
• Im IT-Service-Continuity-Management werden die in einem Katastrophenfall mindestens erforderlichen Service-Level betrachtet, und der aktuelle Service wird darin eingebettet.
• Letztendlich wird im Service-Reporting der neue IT-Service eingebunden, und die Berichte werden entsprechend erweitert beziehungsweise ergänzt.

 Abbildung 3: Business-Ebene in der IT-Serviceentwicklung

Business-Ebene

• Wenn die Schnittstellen vom Service-Katalog und zur Service- Orchestrierung so weit offen sind, dass die servicespezifischen Informationen als Variablen abgebildet sind, sind im Idealfall in den etablierten Bestellkanälen keine Anpassungen notwendig.
• Im Identity-Management muss der neue IT-Service eingebettet werden, so dass die Bestellberechtigung sowie die Kundenzuordnung ausgesteuert werden kann. Authentifizierungen und Autorisierungen werden eingerichtet.
• Die mit dem Kunden vereinbarten Service-Level müssen in eine neue beziehungsweise in bereits bestehende Vereinbarungen eingebettet werden. Für die Operational Level Agreements der unterstützenden IT-Services wird überprüft, ob diese die zugesicherten Servicewerte wie Verfügbarkeit und Performance unterstützen. Die vereinbarten Service- Level werden dem Monitoring mitgeteilt, so dass dort die Skripte für die Messung der Kennzahlen erstellt werden können.
• Im Finance-Bereich werden Service-Instanzen des neuen IT-Services kundenbezogen akkumuliert und für den Kostennachweis und die Kostenverrechnung verwendet.

Zusammenfassung

Diese Aktivitäten im Rahmen der Erstellung eines IT-Services stellen nur einen groben Überblick über die notwendigen Schritte zur Entwicklung eines vom Anwender nutzbaren IT-Services dar. Aber es ist erkennbar, dass sich die Entwicklung eines IT-Services doch deutlich von der Entwicklung einer Anwendungssoftware unterscheidet.