Im Rahmen meines Studiums habe ich eine wissenschaftliche Ausarbeitung zum Thema "Das Plan-Build-Run Modell" angefertigt, welche ich in diesem Artikel zusammengefasst habe.
Eine Liste weiterer wissenschaftlicher Arbeiten, sowie deren Nutzungsbedingungen, ist hier verlinkt.
Einführende Beschreibung
Das Plan-Build-Run Modell ist allgemein auch als „das klassische IT-Modell“ bekannt. Lange Zeit galt dieses als das Standard-Modell für die Koordination der Softwareentwicklung. Nachdem sich das Modell in den 1980er Jahren herauskristallisiert hat, hat es die Rolle als Standard-Modell gut 20 Jahre vertreten können; Anfang der 2000er Jahre wurden aber neue Modelle entwickelt, die dem Plan-Build-Run Modell diese Rolle strittig gemacht haben (zum Beispiel das Source-Make-Deliver-Modell).
Das Plan-Build-Run Modell ist ein systemzentrierter Ansatz, welcher die einzelnen Aufgaben und Prozessschritte in die drei umfassenden Bereiche Plan, Build sowie Run unterteilt. Durch das Modell werden strukturierte Abläufe und Prozesse für eine ganze IT-Organisation definiert.
Historische Entwicklung und Ziele
Die ersten in der freien Wirtschaft entwickelten Software-Anwendungen erfüllten das Ziel zeitaufwendige, rechenintensive und in der Regel in sich geschlossene Prozesse vereinfacht und mit weniger Aufwand ausführen zu können. Als die Anwendungen größer wurden, indem mehr Anforderungen aus mehreren, voneinander abhängigen Bereichen in einer Anwendung umgesetzt werden sollten, wurde für die Planung und Entwicklung dieser ein Modell benötigt – konkret hat sich das Plan-Build-Run Modell als die geeignetste Lösung herauskristallisiert und sich als Standard durchgesetzt.
Das Plan-Build-Run Modell legt großen Wert auf eine hohe Stabilität, eine ständige Verfügbarkeit sowie eine hohe Sicherheit der Anwendungen, während als Hauptziel die Effizienzsteigerung verfolgt wird. Hierbei betont das Modell die Eigenständigkeit der IT-Wertschöpfungskette mittels unabhängiger Planung.
Definition der einzelnen Bereiche
Das Plan-Build-Run Modell ist in die Bereiche Plan, Build sowie Run unterteilt, welche eindeutig durch eigene Aufgaben und Methoden voneinander getrennt sind. Wird in einem Unternehmen das Plan-Build-Run Modell eingesetzt, so ist nicht selten eine Aufspaltung der IT-Abteilung dieses Unternehmens in drei Unterabteilungen, die den drei Bereichen des Modelles entsprechen, zu beobachten.
Plan
Der Plan-Bereich ist der erste der drei Bereiche des Plan-Build-Run Modells. In diesem wird allgemein die IT-Strategie erarbeitet, wobei sowohl Aspekte der Planung als auch der Steuerung und der Kontrolle betrachtet werden. Innerhalb dieses Bereiches werden alle Anforderungen des Kunden, für den die Anwendung entwickelt werden soll, oder die Anforderungen des eigenen Unternehmens ermittelt. Hierbei werden die Anforderungen aller betroffenen Abteilungen gesammelt und in einer kompletten Anforderungsausarbeitung zentralisiert zusammengetragen.
Neben der Ausarbeitung der Anforderungen, werden auch die IT-Architektur sowie interne Anforderungen an die IT und an die Infrastruktur definiert. Dabei werden sowohl technische Anforderungen als auch organisatorische Anforderungen und Bedingungen ausgeplant. In der Regel werden die Anforderungen – sowohl technisch als auch organisatorisch betrachtet – auf eine langfristige Unterstützung des Unternehmens, für das die Anwendung entwickelt wird, ausgelegt.
Ein weiterer wichtiger Aspekt, der in diesem Bereich betrachtet wird, ist die Budgetierung der Anwendung. Nicht selten wird die Ausarbeitung der Budgetplanung an die jährlichen Budgetierungsplanungsprozesse von Unternehmen gekoppelt, weshalb die Handlungsfelder nicht selten für zwölf Monate fixiert sind.
Häufig eingesetzte Methoden sind die Portfolioanalyse, die SWOT-Analyse sowie die Prozessmodellierung, auf die im Rahmen dieser Ausarbeitung nicht weiter eingegangen wird.
Build
Während im Plan-Bereich die IT-Strategien, wie Anwendungsanforderungen oder Bedingungen an die Infrastruktur, ausgearbeitet wurden, werden diese im Build-Bereich des Plan-Build-Run Modell umgesetzt.
Hierfür werden passende Standard-Softwarelösungen ermittelt, welche dann verglichen werden, sodass die für die Anforderungen am besten passende Standard-Software genutzt und passend konfiguriert werden kann. Für Anforderungen, die nicht durch standardisierte Software erfüllt werden können, wird im Rahmen des Build-Bereiches auch Individualsoftware entwickelt. Ein weiterer Aspekt, der im Rahmen dieses Modellbereiches umgesetzt wird, ist die Bereitstellung der Infrastruktur, die für das Betreiben der Anwendung benötigt wird.
Im Build-Bereich werden neben der erstmaligen Entwicklung und Einführung der Anwendungen auch die Weiterentwicklung und die Pflege abgebildet. Eine weitere wichtige Aufgabe ist die Befähigung der Organisation die entwickelte Anwendung auch einsetzen zu können.
Die Aufgaben, die im Rahmen des Build-Bereiches umzusetzen sind, lassen sich in der Regel gut in einzelne Aufgabenpakete unterteilen, sodass Teamarbeit in diesem Bereich standardmäßig gut möglich ist. Häufig kommen in diesem Bereich Projektmanagementmethoden und Prozessmodellmethoden zum Einsatz.
Run
Der Run-Bereich des Plan-Build-Run Modells beschäftigt sich mit der Übernahme der Resultate des Build-Bereiches in den produktiven Betrieb.
Neben der Einführung in den produktiven Betrieb wird durchgehend der korrekte Betrieb der Anwendung überwacht. Hierfür werden in der Regel Ist- mit erarbeiteten Soll-Werten verglichen, um Unstimmigkeiten feststellen zu können. Parallel hierzu werden Wartungsarbeiten an der Anwendung durchgeführt, wozu unteranderem die Pflege von Software und Daten gehört.
Zum Aufgabenfeld des Run-Bereiches zählt auch der Support sowie das Katastrophenmanagement der Anwendung. Der Support umfasst Anfragen von Anwendern, welche einfache Fragen zur Benutzung der Anwendung sein können, aber auch Anfragen bezüglich fehlerhafter Konfigurationen oder Softwarefehlern. Der Katastrophenmanagement wird benötigt, um bei schwerwiegenden Problemen mit der Anwendung, wie zum Beispiel dem Ausfall eines kompletten Systems, schnell Lösungen erarbeiten zu können und größere Schäden zu vermeiden.
Methoden, die häufig zum Einsatz kommen, sind das Hardware- und Softwaremonitoring, sowie Service Level Agreements.
Bewertung des Modells
Vorteile sowie Stärken
Eine große Stärke des Plan-Build-Run Modells ist der hohe Standardisierungsgrad seiner Prozesse sowie die festen Strukturen. Diese ermöglichen bei korrektem Einsatz des Modells eine effiziente IT und somit Kostenreduzierung im Vergleich zur Anwendungsimplementierung ohne Modell. Die klare Struktur des Modells bietet die Möglichkeit, die Effizienz und Rentabilität der Prozesse mit relativ geringem Aufwand zu messen. Durch die hohe Standardisierung des Plan-Build-Run Modells können eine hohe Stabilität, eine hohe Verfügbarkeit sowie eine hohe Sicherheit der Anwendung erreicht werden.
Eine weitere Stärke des Modells ist das frühe Einbeziehen der Planungsinstrumente. Dies ermöglicht es den Entwicklern der Anwendung früh Entscheidungen zu treffen, was dazu führt, dass schon zu frühen Zeitpunkten ein klares Bild der Anforderungen vorliegt.
Ein weiterer positiv zu betrachtender Effekt des Plan-Build-Run Modells ist, dass Aufgabenblöcke in der Regel gut in einzelne kleinere Aufgaben unterteilt werden können, was die Teamarbeit gut möglich macht, sodass durch diese die Effizienz des Entwicklungsprozesses gesteigert werden kann.
Änderung der Anforderungen und der Rahmenbedingungen
Während das Plan-Build-Run Modell die Anforderungen zu seiner Anfangszeit gut erfüllen konnte, veränderten sich diese mit der Zeit, sodass diese vom Plan-Build-Run Modell nicht mehr in Gänze abgedeckt werden konnten.
Während in den 1980er- und 1990er-Jahren wenige und lange Wertschöpfungsketten die Regel waren, haben sich diese immer weiter verkürzt, sodass viele kurze Wertschöpfungsketten der Standard wurden. Viele Aufgaben wurden beispielsweise in Cloud-Anwendungen ausgelagert – ein verbreitetes Beispiel hierfür ist das Software as a Service-Modell.
Eine weitere entscheidende Änderung ist die stark wachsende Marktdynamik – umgangssprachlich wird häufig von einer immer schneller werdenden Welt gesprochen. Ein Auslöser für dieses Wachstum ist unter anderem die Digitalisierung, welche diverse neue Anforderungen mit sich bringt. Beispielsweise muss die Umsetzung von neuen Ideen und Kundenanforderungen schneller erfolgen als bisher. Neben dieser hohen Innovationsfähigkeit wird außerdem immer weniger Fokus auf den eigentlichen Entwicklungsprozess und viel mehr auf die Brauchbarkeit der fertigen Anwendung für konkrete Anforderungen gesetzt. Während die Umsetzung neuer Ideen und Anforderungen allgemein immer schneller erfolgen muss, werden auch kurzfristige marktorientierte und/oder technologische Impulse, die sehr kurzfristig zu erkennen und umzusetzen sind, immer häufiger.
Nachteile, Schwächen sowie Anforderungen an Nachfolgemodelle
Neben den zuvor beschriebenen Stärken, weist das Plan-Build-Run Modell auch diverse Schwächen auf.
Je nach Anforderungen kann die Umsetzung dieser im Plan-Build-Run Modell sehr zeitaufwendig werden. Unter anderem ist dies damit zu erklären, dass Entscheidungen im Modell zwar früh getroffen werden können, sich deren Umsetzung allerdings häufig viele Prozessschritte hinziehen kann. Zu erklären ist dies unter anderem durch den Einsatz von tendenziell getrennten und eindimensionalen Prozessen, zwischen denen während ihrer Durchführung nur ein geringer Austausch an Informationen erfolgt.
Eine weitere bedeutende Schwäche ist die geringe Innovativität des Modells. Änderungen an bereits festgelegten Anforderungen sind während der Entwicklungsphase nur mit großem zeitlichem und organisatorischem Aufwand möglich. So kommt es nicht selten vor, dass Anforderungen beim Abschluss ihrer Umsetzung bereits veraltet sind – ein Schlüsselbegriff hierfür ist die hohe Time-To-Market-Zeit, welche das Plan-Build-Run Modell aufweist.
Für viele Schwächen des Plan-Build-Run Modells können die geänderten Anforderungen, welche im vorherigen Kapitel beschrieben wurden, verantwortlich gemacht werden. Während das Plan-Build-Run Modell die Marktanforderungen zu seiner Anfangszeit noch gut erfüllen konnte, ist dies nach deren Änderungen nicht mehr möglich.
Da in vielen IT-Betrieben aber noch immer am Plan-Build-Run Modell – oder an Teilen des Modells – festgehalten wird, kommt es in diesem durch die geänderten Marktanforderungen häufig zu Effizienz- und Effektivitätsproblemen.
Die geänderten Anforderungen machen ein Modell notwendig, welches neben der hohen Stabilität, die durch das Plan-Build-Run Modell bereits gegeben ist, auch eine hohe Flexibilität und eine kurze Time-To-Market-Zeit ermöglicht. Inwiefern diese Anforderungen durch Nachfolge-Modelle bereitgestellt werden können, wird in den folgenden Kapiteln näher erläutert.