Objektorientierte und funktionsorientierte Dokumentation von Betriebsaufgaben

Transkript

1 Objektorientierte und funktionsorientierte Dokumentation von Betriebsaufgaben Ein integrales Modell mit Ansatz und Vorgehen zur Dokumentation von IT Systemen End-2-End - Liefert Produkte, Systeme und Lieferketten - Definiert Arbeitsfähigkeit über End-to-End Funktionen - Verbindet über Prozeduren Betriebsprozesse nach ITIL mit Systemen in Lieferketten Kai Schwarzer März

2 Probleme bei Definition und Beschreibung von IT- Betriebsaufgaben - Moderne IT-Architekturen sind geographisch stark verteilt - Enorme Produktvielfalt erzwingt große Anzahl verantwortlicher Organisationen (Produktverantwortung) - Je Ort viele Systeme mit vielen Produkten im Einsatz erzwingen geographische Verantwortung für Funktionsfähigkeit (Systemverantwortung) - Eine Vielzahl von Geschäftsprozessen mit extrem divergierenden Anforderungen über Orte und Systeme hinweg erzwingt eine End-to-End- Verantwortung (Leistungsverantwortung) Kai Schwarzer März

3 Herausforderung Ziele für Inhalte Analysefähigkeit - technische und organisatorische logische Abhängigkeiten normiert Wissensmanagement - manuelle Funktionen integrierbar Entscheidungsunterstützung - Komplexität über Produkte-Systeme- Abläufe beherrschbar Ziele für Dokumentationskonzept Robustheit - Robustheit Unabhängigkeit von semantisch festgelegten Hierarchien Pflegbarkeit - normierte Verfahren verfügbar Hierarchisierbarkeit horizontal und vertikal - Jeder sieht nur das, was zur Aufgabenerfüllung notwendig ist - Why - How sichtbar Prüfbarkeit Konsistenz - Cross Referencing, Datenbank- Abfragen verfügbar Kai Schwarzer März

4 Produkte objektorientiert dokumentieren Produkte sammeln und modellieren - jedes Produkt ist eine Klasse. Produkte über "besteht aus und "ist ein" zu Bäumen klassifizieren - Kennzahlen, Konfigurations-Daten ergänzen - Funktionen mit Zeiger auf Abnahme- Prozedur ergänzen Kai Schwarzer März

5 Systeme objektorientiert dokumentieren Systeme sammeln und mit Produkten modellieren - jedes System ist eine Klasse. Systeme über "besteht aus" und "ist ein" zu Bäumen klassifizieren - die Blätter des Baums sind Produkte - Kennzahlen, Konfigurations-Daten ergänzen - Funktionen mit Zeiger auf Abnahme- Prozedur ergänzen Kai Schwarzer März

6 Funktionen dokumentieren Funktionen sammeln und als Baum dokumentieren - erst System- Funktionen heranziehen - dann ggf. manuelle Funktionen ergänzen Kai Schwarzer März

7 End-to-End Leistung System funktional dokumentieren Leistung der Systeme aus erfassten Funktionen dokumentieren - triggernde Ereignisse ergänzen - System-Funktionen heranziehen Kai Schwarzer März

8 Lieferkette funktional dokumentieren Ablauf der Leistung Systeme aus erfassten Funktionen dokumentieren - triggernde Ereignisse ergänzen - erst Folge von System-Funktionen heranziehen - dann ggf. manuelle Funktionen ergänzen Kai Schwarzer März

9 Betriebsfunktionen System funktional dokumentieren Ablauf der Unterstüzung der Systeme aus erfaßten Funktionen dokumentieren - triggernde Ereignisse ergänzen - System-Funktionen heranziehen - manuelle Funktionen ergänzen Kai Schwarzer März

10 Beziehung Systemprozess - Betriebsprozess Systeme sind strukturiert Funktionen (Zweck) definiert Abnahmeprozeduren zugeordnet Kennzahlen und Konfigurationsdaten dokumentiert Funktionen (Betrieb) definiert Durchführungsanweisungen (DA) zugeordnet Prozesse sind strukturiert Prozesse (ITIL) definiert SLA zugeordnet OLA und KPI dokumentiert Schnittstellen (Zulieferung) definiert Durchführungsanweisungen (DA) zugeordnet System-Handbuch fertig DA S 1 DA S 2 DA S 3 DA S 4 DA S 5 DA S. ḌA S S Prozeß-Handbuch fertig Kai Schwarzer März

11 Betriebsprozess vervollständigen Prozeduren aus Systembaum in Funktionsbaum Betrieb einfügen - erst System-Funktionen Unterstützung heranziehen - dann ggf. manuelle Funktionen ergänzen Kai Schwarzer März

12 Möglichkeiten - einfache Administration, da semantische Konflikte auf ein Minimum reduziert - Projekte liefern alle notwendigen Produkt-/Systembäume und Funktionen zu - Ergänzung im Gesamtbestand nur dort, wo Änderungen notwendig - Single Point of Documentation reduziert Kosten - Audit mit nur einem Link - Simulation - Ausfertigung von monolithischen Betriebshandbüchern automatisch - übliche Teststrukturen direkt und prozedurbasiert abbildbar: - Funktionstest am Produkt - Integrationstest am System - E2E-Nutzbarkeitstest am Ende der Lieferkette - Bezug zum Prozessmodell (z.b. ITIL) einfach herstellbar: Die Funktionen zum Betrieb werden den ITIL-Prozessen untergeordnet - Problem- und Changemanagment greifen auf Dokumentation der Abhängigkeiten zu - statt zu diskutieren: "Wie läuft das eigentlich ab?" Kai Schwarzer März