Dokumentation und Management von Servicearchitekturen mit einem „Service Owner Handbuch“

Nach Erfahrung des Autors besteht für größere Unternehmen der Bedarf die internen IT-Dienstleitungen zu Dienstleistungpaketen (Services) zusammenzufassen. Um diese Services zu steuern und auch monetär bewerten (und intern weiterverrechnen) zu können, müssen diese dokumentiert werden. Darüber hinaus erleichtert eine derartige Dokumentation die Einarbeitung neuer Fachkräfte und leistet einen Beitrag zur Transparenz der erbrachten Leistungen. Dabei ist es wichtig, dass dieses Dokumentationskonzept nicht zur „Ablage“ oder als Übergabedokument bei einem Personalwechsel gesehen wird, sondern als Tool, welches die/den Service OwnerIn bei der Steuerung des Services unterstützt.

Erfahrungsgemäß werden Dokumentationen in vielen Fällen nicht regelmäßig gewartet. Eine unvollständige oder nicht aktuelle Dokumentation ist nur bedingt sinnvoll. Eine Einbindung eines Dokumentationskonzepts in das Wissensmanagement ist daher ratsam. Dies hilft auch redundante Dokumentationen zu vermeiden. Der Autor hält mit aktuellem Wissenstand hierzu eine zentrale Plattform, welche sowohl zur Dokumentation genutzt werden kann, aber auch die Möglichkeit bietet, auf andere Systeme (zum Beispiel: Ticketsystem für das Backlog der Anpassungen, ein Metadatenmanagementsystem oder die Kostenübersicht des Service) zuzugreifen, für eine adäquate Lösung. Das hier beschriebene Konzept eines „Service Owner Handbuchs“ wurde vom Autor bereits mehrfach genutzt, laufend erweitert und hat sich als praktikable Vorgehensweise erwiesen.

Abstrakt gesehen kann ein Service als ein Haus/Firmengebäude in einer Stadt, der Servicelandschaft, gesehen werden. Die Erstellung der IT-Architektur sollte gemäß der vier Schichten der Schritte B, C und D des "Architecture Develepment Models" (ADM) des TOGAF-Ansatzes (Business-, Daten-, Applikations- & Technologiearchitektur) von der obersten Ebene, der Business-Ebene erfolgen. Die Business- und Datenebene können auch gemeinsam in der Ebene der Informationsarchitektur zusammengefasst werden.

Zum einfacheren Verständnis wird eine Hausmetapher benutzt und die Reihenfolge bei der ersten Übersicht in der Einführung angepasst, die Vorgangsweise in der Anwendung sollte aber wie von TOGAF vorgesehen erfolgen.

Folgende Grafik stellt die Struktur dieses Dokumentationskonzepts dar:

Abbildung 1: Servicearchitektur in Anlehnung an die vier Architekturtypen des ADM von TOGAF (Quelle: Eigene Darstellung)

Das Fundament (gelb) stellt die technologische Plattform dar. Diese ermöglicht die Betreibung des Service

Die Außenwände des Hauses (blau) bieten Platz für die Datenarchitekturen des Service, sowie der Applikationen. Ein weiterer Aspekt ist es hier nicht nur die Datenstrukturen, sondern deren Zusammenhänge und Interpretation (Metadaten) zu beschreiben.

In den unteren Stockwerken (grün) befinden sich die Applikationen, welche in diesem Service betrieben werden. Ebenfalls wird zur Steuerung ein Überblick über die geplanten Anpassungen (Backlog), die zurzeit laufenden Anpassungen sowie eine Historie der durchgeführten Anpassungen dargestellt. Darüber hinaus bietet dieser Bereich auch Raum den Service selbst zu beschreiben.

Die oberen Stockwerke (rot) stellen dar, wie der Service die Strategie des Unternehmens unterstützt, auf welche Prozesse dieser Einfluss hat und welche Anspruchsgruppen bzw. Stakeholder vorhanden sind.

Ohne ein Dach (rot) regnet es in das Haus. Der Zweck eines Service ist ein Beitrag zur Wertschöpfung des Unternehmens. Diese Wertschöpfung kann sich je nach Stakeholder unterscheiden und sollte in messbarer Form definiert werden.

Zum Schluss werden noch die Straßen und Verbindungswege (grau) zu anderen Services definiert. Dies stellt die Abhängigkeiten zueinander dar.

Die Ebenen greifen ineinander, daher kann sich die Dokumentation über mehrere Ebenen erstrecken. Beispiel: Ein Datawarehouse besteht aus mehreren Applikationen, wie zum Beispiel Vertrieb, Einkauf, Personal, Bestände, etc. Jede dieser Applikationen hat wiederum eigene Ansprechpartner, „Prozesskunden“, Architekturen, etc. In diesem Falle hat der Architekt seinen Freiraum. Man könnte zum Beispiel unter Applikationen einen Grundüberblick mit Ansprechpartner geben und darstellen, wie diese Applikationen untereinander in Verbindung stehen. Die Datenarchitektur könnte dann für jede der Applikationen im Datenlayer beschrieben werden. Ebenso könnte eine Gesamtübersicht der Ansprechpartner mit einer sinnvollen Gruppierung dargestellt werden.

Ein weiterer wichtiger Aspekt ist es darzustellen, wie die Strategie auf die Applikationen wirkt und, ob diese auch von diesen unterstützt wird. Die technologischen Wirkungen auf den Service können so ebenfalls dargestellt werden.

Business-Ebene

Um den Service an die Anforderung des Unternehmens auszurichten, muss man die Strategie nach TOGAF des Unternehmens kennen, welche sich aus der Vision bzw. Mission ableitet. Diese Strategie hat direkten Einfluss auf die IT-Strategie und damit auf die Services. Daher ist der erste Schritt zu ermitteln, ob die aktuellen Services überhaupt der Strategie entsprechen bzw. was notwendig ist, um diese darauf auszurichten -> „IT follows Business“.

Viele Unternehmen haben bereits Ihre Prozesse in Prozesslandkarten oder –häusern dokumentiert. Um die Auswirkungen des Service auf das Geschäft zu ermitteln, ist es daher wichtig zu wissen, welche Prozesse und in welcher Form diese durch dieses Service beeinflusst oder unterstützt werden. Dieses Wissen ist auch wichtig, um sinnvolle Service Level Agreements (SLAs) zu definiere bzw. Schwächen in den Prozessen zu ermitteln.

Die beteiligten Personen oder Interessengruppen (Stakeholder) stellen einen wesentlichen Faktor dar. Wie wichtig Stakeholdermanagement ist, zeigt das Beispiel des Atomkraftwerks Zwentendorf, welches fertiggestellt, aber nach Intervention der Stakeholdergruppe „Bürger/innen Österreichs“ mittels einer Volksabstimmung nicht in Betrieb genommen wurde. Die Kenntnis über die Stakeholder und deren Anforderungen hilft dabei den Service weiterzuentwickeln und als funktional wahrgenommen zu werden.

Daten-Ebene

Das Ziel der Datenarchitektur laut TOGAF besteht darin, den Applikationen zu ermöglichen, die Vision des Business umzusetzen. Die Dokumentation der Datenarchitekturen ist wichtig, da sich hier schon Abweichungen zur Unternehmensstrategie bzw. der daraus abgeleiteten Datenstrategie zeigen können. Diese Datenarchitektur kann nun als Bestandteil für eine Data Governance (Überbegriff für das generelle Datenmanagement in einem Unternehmen) sein bzw. kann darauf auch ein Stamm- und Metadaten-Management durchgeführt werden.

Für das bessere Verständnis der enthaltenen Daten dieses Service sollten auch die Metadaten berücksichtigt werden. Hier liegt der Fokus darauf zu verstehen, wie die Daten in Zusammenhang stehen und welche Informationen diese bereitstellen. Dies ist wichtig, um die Fachbereiche bei neuen Anforderungen optimal beraten zu können.

Applikations-Ebene

Die Applikationen des Service sollen laut TOGAF die Vision des Business umsetzen. Daher wird an dieser Stelle zunächst der Service in seiner Gesamtheit definiert. An dieser Stelle kann eine Vielzahl an unterschiedlichen Informationen bereitgestellt werden. Die Möglichkeiten reichen von Entwicklungsrichtlinien über finanzielle Aspekte bis hin zu Ablaufbeschreibungen, die alle Applikationen betreffen. Diese Sektion könnte man auch als Kern- oder Herzstück bezeichnen.

Nachdem der Service ausreichend dokumentiert wurde, können alle laufenden Applikationen in ähnlicher Form hinzugefügt werden. Dabei sollte der Fokus nicht auf einfacher Dokumentation liegen, sondern den zuständigen Personen die Möglichkeit geben, die Applikation optimal an die Bedürfnisse der Fachbereiche und der Strategie auszurichten.

Die aktuell geplanten und laufenden Anpassungen des Systems sollen an dieser Stelle ebenfalls schnell verfügbar sein, um den zuständigen Personen einen Überblick über die Entwicklungen im Service zu geben. Die sorgt für Transparenz gegenüber dem Fachbereich und vereinfacht die Priorisierung der Anpassungen.

Technologie-Ebene

TOGAF definiert das Hauptziel der Technologie-Ebene als logische und physische Bereitstellung einer Architektur, welche von den Applikationen benutzt wird.

Daher müssen diese auch in das „Service Owner Handbuch“ einfließen. Zum einen ist es relevant zu wissen, welche Abhängigkeiten es in der Infrastruktur gibt und wo notwendige Änderungen durchgeführt werden können. Zum anderen ist es ebenfalls wichtig frühzeitig zu erkennen, welche Handlungsbedarfe es in der Zukunft geben wird (Zum Beispiel: der Windows Server 2008 SP2 wird am 14. Jänner 2020 seitens Microsoft nicht mehr unterstützt werden, daher ist es relevant zu wissen, ob der Service unter Umständen davon betroffen ist und die entsprechenden Schritte frühzeitig einzuleiten). Darüber hinaus kann auch die Infrastruktur bewertet und angepasst werden.

Ebenen übergreifend

Ein zentraler Aspekt des Service ist die Wertschöpfung. Es ist wichtig zu erkennen, welchen Wert das Service für die einzelnen Anspruchsgruppen bietet. Der Wert kann sich naturgemäß je nach Gruppe erheblich unterscheiden und sollte demnach für jede Anspruchsgruppe separat ermittelt werden. Das bekannte Pareto-Prinzip mit der 80:20 Regel findet auch an dieser Stelle Anwendung. Daher ist es sehr wichtig, die Hauptansprüche der „Servicekunden“ zu kennen, um den Nutzen des Service auch bei Ressourcenengpässen zu erhalten.

Es kann auch vorkommen, dass der Service selbst Kunde eines anderen Service ist, oder einen anderen Service beliefert. Daher ist es notwendig, auch diese Abhängigkeiten darzustellen. Dies unterstützt die zuständigen Service Owner und Applikations Manager bei der Definition von SLAs bzw. lassen sich auch Optimierungs- und Verbesserungspotenziale und Risikofaktoren darstellen.

Schlussbetrachtung

Bei dieser Vorgehensweise handelt es sich um keinen „Best-Practise“-Ansatz und kann demnach noch an diversen Stellen erweitert werden. Dem Autor hat dieser Zugang in seiner Tätigkeit einen Mehrwert gebracht. Eine derartige Erstellung ist Zeit- und Ressourcenintensiv und sollte daher ein „lebendes“ Objekt sein, welches die Verantwortlichen unterstützt und nicht nur ein Dokument auf einem Fileshare sein. Vielmehr sollte es als Steuerungsmöglichkeit gesehen werden, um die Potenziale optimal zu nutzen. Dabei verweist der Autor auf die Möglichkeit einer logischen Integration einiger Inhalte, da diese Daten nicht dezentral und redundant gewartet werden, aber zentral (Single-Point-Of-Truth) genutzt werden sollten.

Über den Autor

Markus Rotter, MA ist seit den 2000ern in der IT tätig und hat in dieser Zeit Erfahrungen mit IT-Management, Business Intelligence, Datawarehousing, Datenbanken, Systemadministration, IT-Architekturen, Mitarbeiterführung und Projektmanagement gemacht.

Zurück

Übersicht der Artikel

Dieser Artikel behandelt die Grundlagen des agilen Arbeitens, im speziellen KANBAN und SCRUM.

Weiterlesen

Dieser Fachartikel beschreibt das Abbilden des Keyuserkonzepts in einem Ticket-Issue-System.

Weiterlesen

Dieser Artikel beschreibt eine Vorgangsweise, um mittels eines Leuchtturmprojekts ein Keyuserkonzept voranzutreiben.

Weiterlesen

Dieser Artikel beschreibt die Definition von Kennzahlen im Rahmen eines BICC.

Weiterlesen