Die Schnittstelle zwischen den Entwicklungs- und Betriebsabteilungen in einer IT-Organisation ist immer wieder problematisch und bietet Anlass für handfeste Streitigkeiten (vgl. Disterer, siehe „Quellen“ unten).

Warum, wenn ITIL doch genau an dieser Stelle den „Early Life Support“ propagiert? Um diesen Problemen zu begegnen, sollen Service Transition und Service Operation doch gemeinsam die Verantwortung tragen?

So einfach ist die Welt aber leider nicht. Die Entwicklungs- und Betriebs-Teams haben unterschiedliche Präferenzen und Arbeitsweisen. Dadurch ist die Sichtweise auf das Release Management uneinheitlich. Die Release Prozesse der einzelnen Technologieabteilungen haben unterschiedliche Zielsetzungen (vgl. Hinrichs). Ebenso ist die Bedeutung der Release-Begriffe unternehmensweit nicht klar definiert. Daraus ergibt sich, dass die Release-Prozesse eigenständig und kaum miteinander verknüpft sind (vgl. Knittel, S. 170). Völlig außen vor bleibt das Deployment. Es wird schlicht vergessen.

Diese Gründe führen bei der Produktivsetzung eines Release bzw. bei der Übergabe einer Änderung an den Betrieb zu hohem Kommunikations- und Koordinierungsaufwand (vgl. Elsässer, S. 72ff):

• Rollen- und Aufgabenverteilungen sind nicht klar geregelt, dies führt zu Missverständnissen und Spannungen.
• Der Prozess zur Übergabe an den Betrieb, das Deployement,  ist nicht klar geregelt und muss ad-hoc erstellt werden.
• Ansprechpartner der Entwicklung sind trotz „Early Life Support“ nicht erreichbar, da sie bereits in anderen Projekten arbeiten.
• Die für den Betrieb notwendigen Vorlaufzeiten zur Vorbereitung und Durchführung einer Inbetriebnahme werden von der Anwendungsentwicklung oft ignoriert.
• Der Betrieb kann auf Zeitverschiebungen in den Entwicklungsprojekten nicht immer mit der von der Anwendungsentwicklung erwarteten Flexibilität reagieren, sondern muss auf fest definierte Zeitfenster zur Inbetriebnahme Rücksicht nehmen.
• Komplexe und verteilte Betriebsumgebungen sind nur schwer in Entwicklungs- oder Testumgebungen nachzustellen, so dass unterschiedliche Hardware- und Softwareumgebungen in der Entwicklung und im Betrieb zu Problemen führen. (vgl.Disterer)

Wie aus diesem Dilemma herauskommen? Ist der „Early Life Support“ oder sogar das gesamte ITIL ungeeignet?

Ganz und gar nicht. ITIL ist aber auch kein Kochbuch das genau sagt was man nehmen muss, um ein bestimmtes Ergebnis zu erzielen. Man muss nach wie vor das Gehirn anstrengen und ITIL auf die eigenen Bedürfnisse anpassen. Nachdenken und Feinarbeit sind notwendig.

Wie könnte aber eine Lösung für unser Dilemma aussehen?
Man muss in der Designphase den Fokus auf den Service legen. Im Service Design Package muss eindeutig definiert werden, was der Service für den Nutzer liefern soll und wie dieser Service technisch unterstützt bzw. gewährleistet wird. Bei einem Änderungsantrag, kann dann direkt die Beziehung zu einem Service und dessen technischer Unterstützung hergestellt werden.

Mit diesen Informationen ist das „Fine Tuning“ an der Schnittstelle zwischen Entwicklung und Betrieb wesentlich einfacher. Schon bei der Entwicklung können die Besonderheiten des Betriebs eingeplant werden: Rollen- und Aufgabenverteilung, Ansprechpartner, Testszenarien der Liveumgebung, Zeitfenster für die Inbetriebnahme…

Schlussfolgerung:
Die Release und Deployment Planung muss bereits im Service Design beginnen und nicht erst in der Service Transition.

Konkret: Bei der Bewertung eines Änderungsantrags muss das betroffene Service Design Package herangezogen werden. Nur mit den Informationen des Service Design Package kann eine umfassende Bewertung des Änderungsantrags erfolgen, inklusive der Aufwände für Release und Deployment Management.

Schaut man sich die reale Welt in den IT-Organisationen an, fehlen meist genau diese Service Design Packages. Gerade bei großen Änderungen wäre es aber angebracht, vor der Bewertung Service Design Packages zu erstellen. Das vereinfacht das Leben ganz enorm an der Stelle.

Vorschlag: Das könnte das Leben an dieser Stelle enorm vereinfachen.

-- Guido Hoffmann

13. Juni 2012

Quellen:
Georg Disterer, ITIL: Zwischen Entwicklung und Betrieb hakt es.
Computerwoche, 26.05.2007. http://www.computerwoche.de/592968

Björn Hinrichs, ITIL V 3, Buch 3: Übergang zwischen Entwicklung und Betrieb. Computerwoche, 08.10.2007.http://www.computerwoche.de/546849

Silvia Knittl, Entwicklung eines Konzepts zur plattformübergreifenden Integration des Release-Managements bei der HVBInfo.
INSTITUT FÜR INFORMATIK DER LUDWIG–MAXIMILIANS–UNIVERSITÄT MÜNCHEN, 2006

Wolfgang Elsässer, ITIL einführen und umsetzen, 2006