Anwendungsbetrieb – Schnittstelle zwischen Systembetrieb, Entwicklung und Fachbereich

Der IT-Betrieb ist kein Selbstzweck. Zu den wesentlichen Aufgaben einer IT-Organisation gehört daher der Anwendungsbetrieb, d. h. die Bereitstellung von Anwendungen für die Fachbereiche. Und genau wie die Systeme und operativen Verfahren müssen auch diese dokumentiert werden. Anders aber, als bei den IT-Systemen und der Systemsoftware zu dessen Betrieb, liegt die Verantwortung für die Anwendungsdokumentation keineswegs allein bei der IT-Organisation.

Wichtig ist vielmehr eine ganzheitliche Betrachtung ausgehend von der Entwicklung, über die Bereitstellung durch die IT und die Nutzung der Applikation durch den Fachbereich. In der Praxis stellt das jedoch die IT-Administration und die operative IT-Organisation immer wieder vor die Frage, welchen Teil der Anwendungsdokumentation sie eigentlich dokumentieren muss. Hierzu möchte der Beitrag ein paar Anregungen liefern.

Versucht man sich dem Thema über verschiedene Literaturquellen zu nähern, muss man zunächst einmal feststellen, dass es keine einheitliche Definition für den Begriff der Anwendungsdokumentation gibt. Vielmehr gibt es eine Reihe von Begriffen, die im Kontext der Dokumentation von Anwendungen Verwendung finden. Hierzu zählen neben Anwendungsdokumentation auch, Verfahrens-, Architektur-, Software- und Anforderungsdokumentation u. a. Verwirrender weise werden diese Begriffe manchmal synonym verwendet, vielfach aber beschreiben sie unterschiedliche Dokumentationsfelder.

Erschwerend kommt hinzu, dass es bei Frage nach den Inhalten sehr davon abhängt, wer und mit welcher Zielrichtung die Anwendungsdokumentation gefordert wird. In der Softwareentwicklung spielt das Thema Requirements Engineering und damit auch die Dokumentation von Anforderungen eine wichtige Rolle. Das Ziel des Anforderungsmanagements ist es, ein gemeinsames Verständnis über ein zu entwickelndes System zwischen Auftragnehmer und Auftraggeber zu erreichen. Die Anforderungen an die GoBS-Konformität der Dokumentation finden vor diesem Hintergrund jedoch in der Regel keinen Niederschlag. Eine Dokumentation aus Compliance-Sicht wird hingegen sicherlich andere Schwerpunkte einfordern.

Regelungen für das Softwareprodukt, aber nicht für den Betrieb

Rein rechtlich ist eine Software ein Produkt, für das alle Aspekte von Verbraucherschutz, Haftung und Gewährleistung u. a. zum Tragen kommen und für das eine entsprechende Dokumentation zu erstellen ist. Das findet seinen Niederschlag in zahlreichen Normen und Standards zur Dokumentation von Softwareprodukten, wie unter anderem der ISO/IEC 26514:2008 System and Software Engineering – Requirements for designers and developers of user documentation. Diese definiert sehr eindeutig Anforderungen an die Entwicklungsdokumentation und auch an die Dokumentation, die dem Betreiber der Software zur Verfügung zu stellen ist.

Nicht ganz so eindeutig verhält es ich mit der Dokumentation für den Anwendungsbetrieb. Für diesen fehlen eindeutige Vorgaben und klare Definitionen. Wie etwa das Betriebshandbuch formal und inhaltlich auszugestalten ist, wie die Dokumentation (technisch) geführt wird, welche Qualitätsmerkmale gefordert werden oder welcher Umfang als angemessen zu betrachten ist, das bleibt dem operativen IT-Betrieb überlassen.

Die Frage nach der Zuständigkeit

Wie aber kann man die Anwendungsdokumentation sinnvoll strukturieren und welche Dokumente sind aus Sicht der IT relevant?

Nähert man sich den Fragen aus Sicht der Zuständigkeiten, findet man in der Regel drei Zuständigkeitsbereiche, die sich aus den folgenden drei Aufgabenbereichen ableiten

1. Entwicklung und/oder Anpassung der Anwendung
2. Betrieb und Wartung der Anwendung im operativen IT-Betrieb. Dies schließt auch das Störungsmanagement ein.
3. Pflege und Nutzung der Anwendung durch den Fachbereich.

In der Praxis agieren die drei Bereiche natürlich nicht getrennt voneinander. Vielmehr gibt es mehrere übergreifende Prozesse. Der Fachbereich muss die Anforderung für die Anwendung definieren, die Entwicklungsabteilung muss diese umsetzen und der operative IT-Betrieb muss die Anwendung bereitstellen. Die Dokumentation muss diese Prozesse widerspiegeln, d. h. eine isolierte Betrachtung aus Sicht der einzelnen Zuständigkeiten ohne Betrachtung von Schnittstellen ist wenig nutzbringend.

Ihr Vorteil: Wir unterstützen Sie u. a. bei der Bestandsaufnahme der aktuellen Anwendungsdokumentation sowie bei der Konzeption und dem Aufbau einer Dokumentationsplattform für den Anwendungsbetrieb. Außerdem stellen wir Ihnen auf Ihr Unternehmen zugeschnittene Vorlagen für die Verfahrensdokumentation zur Verfügung.  Mehr erfahren …

Application Lifecycle Management

Einen hilfreichen Ansatz auch für die Dokumentation bietet hierbei das Modell des Application Lifecycle Managements (ALM). Der Lebenszyklus von Anwendungen umfasst sowohl die Entwicklung, als auch den Betrieb und die Wartung von Anwendungen. Allerdings wird ALM von vielen Autoren und Anbietern von ALM-Lösungen aus ganz verschiedenen Blickwinkeln betrachtet. Eine nähere Auseinandersetzung mit den verschiedenen Ansätzen zum Thema Application Lifecycle Management aber würde den Rahmen dieses Beitrags sprengen und ist an dieser Stelle auch nicht notwendig. Vielmehr soll mit dem nachfolgend exemplarisch gezeigten Phasenmodell ein besseres Verständnis für die Dokumentationserfordernisse geschaffen werden. Hierbei spielt es im übrigen auch nur eine untergeordnete Rolle, ob die Entwicklung der Software im eigenen Hause stattfindet oder ob es sich um angepasste Standardprodukte handelt.

Die nachstehende Abbildung zeigt die verschiedenen Phasen einer Anwendung gemäß des Application Lifecycle Management Ansatzes nach M. Rohloff (2011). Dieser unterscheidet innerhalb des Lifecycles zwischen Anwendungsentwicklung und Anwendungsbetrieb. Hierbei werden die drei Phasen, Requirements, Design und Build der Entwicklung zugerechnet.

Aus Sicht der Dokumentation ist eine Betrachtung der sechs Phasen hinsichtlich ihrer Dokumentationsanforderungen interessant:

Requirements

Am Anfang steht die Erhebung und Dokumentation der fachlichen Anforderungen durch den Fachbereich. Häufig wird hierzu ein Fachkonzept erstellt, das die funktionalen Anforderungen an eine Software und deren anwendungsbezogenen Nutzen aufzeigt. Eine zentrale Rolle in dieser Phase spielt die Erstellung der Lasten- und Pflichtenhefte. Mithilfe des Lastenheftes (Anforderungsspezifikation) wird dem Entwickler mitgeteilt, was er zu programmieren hat. Dieser entwickelt aus den Anforderungen des Kunden (Lastenheft) die genaue Produktspezifikation. Damit stellt das Lastenheft die Problemstellung des Auftraggebers dar und geht dem Pflichtenheft voraus. Das Pflichtenheft liefert den Lösungsvorschlag des Auftragnehmers. Bei Vergabe an Dritte bilden diese Dokumente wichtige Vertragsgrundlagen.

Aus Nachweisgründen ist eine vollständige und jederzeit nachvollziehbare Dokumentation der Anforderungen sowie deren Umsetzung wichtig. Dokumentiert werden sollten der Grund von Veränderungen, der jeweils zugrunde gelegten Ziele und Anforderungen und die als Vorgaben benutzten Dokumente (z. B. in Lastenheften und Pflichtenheften), ggf. beteiligte Personen und Organisationseinheiten; erfolgreiche und erfolglose Entwicklungsrichtungen, Planungs- und Entscheidungsunterlagen etc. Eine solche Dokumentation ist insbesondere in größeren Umgebungen ohne eine spezielle Software für das Requirements Engineering kaum darstellbar.

Design

Während das Requirements Engineering die Dokumentation der fachlichen Anforderungen umfasst, wird im Design die Umsetzung dieser fachlichen Anforderungen in der Software und den technischen Systemen festgelegt. Die Dokumentation von Modellen, Architekturkonzepten, Entscheidungsvorlagen, Dokumentation von Prototypen und Risikobewertungen sind typische Dokumente dieser Phase.

Build

Die Buildphase beinhaltet die eigentliche Entwicklung und deren Dokumentation sowie die Integration der einzelnen Komponenten. Einen hohen Stellenwert in dieser Phase haben die verschiedenen Tests der zu entwickelnden Softwarelösung. Tests sind ein unverzichtbares Element der Qualitätssicherung im Rahmen von Softwareentwicklung. Hierbei müssen in der Regel mehrere Teststufen durchlaufen werden: Funktionstests, Integrationstests, Lasttests, Abnahmetests usw. Alle Tests müssen systematisch und klar definiert durchgeführt werden, was nur mit einer entsprechenden Dokumentation möglich ist.

In dieser Phase ist in der Regel eine hohe Integration aller involvierten Bereiche erforderlich, was auch verteilte Dokumentationspflichten mit sich bringt. So müssen u. a. die Fachverantwortlichen in die Tests einbezogen werden und die IT muss die Infrastruktur und die Systeme für die Laufzeitumgebung der Anwendung bereitstellen. Am Ende steht die Abnahme der gesamten Applikation und Systemlösung.

Deploy

Mit der Deploy–Phase erfolgt der Übergang von der Anwendungsentwicklung in den Anwendungsbetrieb. Während dieser Phase werden sowohl die Anwendung, als auch die dafür erforderliche Infrastruktur implementiert und in die bestehende IT-Umgebung integriert. Abschließende Tests und dokumentierte Freigabeverfahren sind für einen geregelten Betriebsübergang erforderlich.

Aus Sicht der IT-Organisation werden sowohl für die Übernahme, als auch für den sich daran anschließenden Betrieb eine ganze Reihe von Dokumenten benötigt. Diese werden im anschließenden Abschnitt vorgestellt.

Operate

Diese Phase beschreibt den Einsatz der Anwendung in Betrieb und die damit verbundenen Wartungs- und Überwachungsaufgaben. Hierzu gehört auch die Behandlung von Störungen.

Optimize

Im Fokus dieser Phase steht die Verbesserung und regelmäßige Anpassung der Anwendung. Während des gesamten Lebenszyklus des Systems wird es immer wieder neue oder geänderte Anforderungen geben. So können beispielsweise neben neuen Kundenanforderungen, auch Probleme im Betrieb zu Service Requests führen, die Anpassungen erforderlich machen.

Erforderliche Dokumente für den Anwendungsbetrieb

Aus dem Application Lifecycle lässt sich nun auch die für den Betrieb der Anwendung im operativen IT-Betrieb erforderliche Dokumentation ableiten:

Technische Spezifikation

Damit der operative Betrieb die erforderliche Infrastruktur implementiert und die Anwendung in die bestehende IT-Umgebung integrieren kann, benötigt er eine Dokumentation der technischen Spezifikationen. Hier ist zu dokumentieren, wie die Anwendung zu implementieren ist, auf welchen Plattformen und auf welchen Infrastrukturkomponenten. Erforderlich ist eine Beschreibung der,

• Komponenten des Systems,
• Architektur,
• Anforderungen,
• Schnittstellen (Quellsysteme und Zielsysteme).

Installationshandbuch

Nicht in jedem Fall erforderlich wird hingegen ein Installationshandbuch sein. Bei komplexen Systemen empfiehlt sich jedoch dessen Erstellung. Das Installationshandbuch beschreibt, wie die Anwendung technisch aufgebaut ist, aus welchen Komponenten sie besteht und wie diese Komponenten zusammenwirken und enthält alle relevanten (Detail-) Informationen, um ein System vollständig aufzusetzen und zu konfigurieren. Den Hauptteil bildet deshalb die Detailbeschreibung der einzelnen Schritte während der Installation. Die Installationsanleitung sollte so weit wie möglich grafische Elemente enthalten.

Betriebshandbuch

Unerlässlich ist eine Dokumentation für die Anwendung im operativen IT-Betrieb. Wichtig sind u. a. Beschreibungen aller notwendigen Maßnahmen und deren Einhaltung zur Gewährleistung des ordnungsgemäßen Betriebs sowie der Betriebsbedingungen und Voraussetzungen. Das beginnt mit der Darstellung, welche Betriebsvoraussetzungen und Betriebsbedingungen gegeben sein müssen, damit ein ordnungsmäßiger Betrieb überhaupt stattfinden kann. Als Nächstes wird der Betrieb selbst beschrieben: Welche IT-Betriebsprozesse und Tätigkeiten gehören dazu? Welche Arbeiten fallen zu welchen Zeitpunkten an? Wer ist verantwortlich, wer zuständig für welche Prozesse und Tätigkeiten? Wie kann festgestellt werden, ob die Tätigkeiten rechtzeitig und in ausreichender Qualität (Vollständigkeit, Korrektheit) durchgeführt wurden? Existieren hierfür Kontrollen?

Gut zu wissen: Wir erstellen mit Ihnen gemeinsam die für Ihr Unternehmen passenden Vorlagen für die Betriebshandbücher. Mehr erfahren …

Weiterhin sind Beschreibungen erforderlich zu den durchzuführenden Überwachungs- und Wartungsmaßnahmen und auch Anleitungen für das Störungsmanagement können in das Betriebshandbuch aufgenommen werden. Kasten 1 zeigt die wichtigsten Gliederungspunkte eines Betriebshandbuchs für eine Anwendung.

Datenflüsse und Schnittstellen

Diese Dokumentation dient dazu zu zeigen, welche Daten über welche Schnittstellen auf welche Weise in die Anwendung einfließen, von welchen IT-Systemen dort verarbeitet und über welche Schnittstellen wieder ausgegeben bzw. an andere Stellen übergeben werden (Datenmodell). Eine Schnittstelle ist ein Übergangspunkt. In einer Schnittstellenübersicht wird entsprechend vermerkt, welche Übergangspunkte es gibt, von wo nach wo der Übergang erfolgt und wofür die Schnittstelle genutzt wird. Die Übersicht ist vorrangig wichtig, wenn die Abläufe eines Verfahrens betrachtet werden. Hierzu gehören auch Ablaufbeschreibungen für systeminterne Kontrollen. Wichtig ist beispielsweise, wie sichergestellt wird, dass übertragene Daten vom Zielsystem empfangen wurden und wann und aufgrund welcher Ereignisse es bemerkt wird, dass sie nicht empfangen wurden.

Weitere Dokumente

Daneben sind weitere Dokumente bzw. Dokumentationen erforderlich, die hier nicht im Einzelnen betrachtet werden können. Dazu gehört z.B. das Thema Lizenzmanagement und Vertragswesen, aber auch der gesamte Bereich des Changemanagements. Da es für diese Bereiche häufig eigene Prozesse bzw. viele Unternehmen für diese Bereiche spezielle Softwarelösungen einsetzen, macht eine weitere inhaltliche Betrachtung an dieser Stelle keinen Sinn.

---

Mustergliederung – Betriebshandbuch für den Anwendungsbetrieb

Geänderte Anforderungen berücksichtigen

Lange Zeit wurden Anwendungen vorwiegend aus Sicht der Anforderungen (Lastenheft / Pflichtenheft) und deren Umsetzung im Rahmen der Softwareentwicklung betrachtet. Heute aber spielen Anwendungsmanagement und Application Lifecycle Management, d. h. die Entwicklung und Betreuung von Anwendungssoftware über deren gesamten Lebenszyklus eine zunehmende Rolle. Dementsprechend nehmen auch die Dokumentationsanforderungen für den Anwendungsbetrieb stetig zu. Jede Anwendung muss im Rahmen des Lifecycles Managements als Komponente des operativen IT-Betriebs geplant, überwacht und gesteuert werden. Welche Anforderungen sich hieraus an eine Dokumentation für den operativen IT-Betrieb ableiten lassen, zeigt der Beitrag.