Rechenzentrumsumzüge sind erheblich kompliziert und haben diverse Abhängigkeiten, welche es zu managen gilt. Im Outsourcing Umfeld ist die Konsolidierung von Rechenzentren keine Seltenheit. Konsolidierung und Standardisierung ist das Ziel und das erfolgt vielfach im Rechenzentrum des Providers. Sind in den vergangenen Jahren die Bandbreiten und allgemein die Nutzung von Internet vielfältiger geworden so bringen diese Möglichkeiten auch Ihre Probleme mit sich. Allein bei der Verlagerung an einen entfernten Standort sind zwei entscheidende Faktoren zu berücksichtigen. Latenz und IP-Adressenänderung. Allein diese Komplexität durch die entfernte Anbindung über eine WAN Leitung deutet auf ein ausgeachsenes Projekt hin.Was hat das aber jetzt mit agilen PM Methoden zu tun? Prinzipiell erst einmal gar nichts und in dieser Phase ist agil eher hinderlich. Begeben wir uns mal in eine höhere Flughöhe. Ein RZ Umzug umfasst mehr oder weniger folgende Phasen:

  1. Ermittlung der Systeme die umzuziehen sind
  2. Erstellung einer Zielarchitektur
  3. Aufbau der Infrastruktur im Ziel RZ
  4. Umzug der Systeme
  5. Rückbau der Kundenumgebung
  6. Projektabschluß

Diese 6 Phasen lassen sich sehr gut mit Wasserfallmethodik abbilden. Phase 1 und 4 sind allerdings die entsprechenden Phasen, welche für agil in Frage kommen. Diese müssen wir uns einmal genauer ansehen.
In Phase 1, Ermittlung der umzuziehenden Systeme, wird eine Auflistung aller Assets gemacht, welche aus dem Kunden RZ in das Provider RZ wandern. Diese Liste ist quasi das "Product Backlog". Wichtig ist das wirklich ausnahmslos alle Assets in diesem "Product Backlog" dokumentiert werden. Ebenfalls wichtig ist das die Verantwortung für dieses Dokument klar geregelt ist. Im Idealfall ist es der "Product Owner". Er und wirklich nur er stimmt die Details zu den Einträgen mit dem Kunden ab und sorgt für Ordung in dieser Liste. Natürlich gibt es viele weitere technische Parameter die ebenfalls zu diesen Assets gehören und auch für weitere Transparenz und Tätigkeiten sorgen. Unter anderem ergeben sich aus diesen Informationen auch die Vorgaben für den Aufbau der Zielinfrastruktur im Provider Rechenzentrum, für das Sizing der Zielumgebung, für den Betrieb (Operations), für den KnowHow Transfer, …. Ergeben sich heiraus schon Abhängige Infrastruktur Systeme, welche vor dem eigentlichen Move vorhanden sein müssen, werden diese in das Product Backlog mit aufgenommen und einsortiert.
Die Aufgabe des Product Owners ist mit dem Kunden möglichst viel über diese Systeme in Erfahrung zu bringen. Daraus ergibt sich eine Sortierung für dieses "Product Backlog". Auch kann an dieser Stelle bereits ein "Dependency Log" gefüllt werden. Dieses wiederum ist eher ein Element aus der Wasserfallmethodik – ist aber zwingend notwendig bereits hier und jetzt zu installieren. Um die Assets einschätzen zu können und um ein Ordering der assets zu erstellen ist eine weitere Methode sinnvoll. Für jedes Asset oder eine sinnvolle Gruppe an Assets ist ein "System Context Diagramm" zu erstellen. Ziel eines solchen Diagramms ist nicht hohe Detailtiefe zu erreichen, vielmehr ist es wichtig zu sehen wie sich das Asset in der Landschaft bewegt und eingliedert. Das System Context Diagramm erzeugt die dringend notwendige Transparenz zwischen Kunde und Dienstleister und kann böse Überraschungen vermeiden. Ein 80/20 Ansatz auf dieser Flughöhe ist ausreichend. Die vollständige Betrachtung würde dann im eigentlichen Move Sprint erfolgen und durch das "Developement Team" erfolgen.
Der Product Owner versucht die Sortierung entsprechend so zu gestalten, dass die einfachen Systeme jeweils oben sind. Hier haben wir bereits eine erste Möglichkeit den Kunden abzuholen und einzubinden.

  1. Der Product Owner arbeitet eng mit dem Kunden zusammen um die Liste zu erstellen
  2. Der Product Owner identifiziert Assets die quasi "low hanging fruits" darstellen und kann darüber die ersten "Quick Wins" für den Move vorbereiten.

Diese beiden Punkte sind sehr wichtig und sind kein Job für jemanden, der dieses nebenbei macht! Die Qualität und die Zusammenarbeit zwischen Kunde und Dienstleister entscheiden über den Erfolg in dieser frühen Phase. Ist die Bereitschaft des Kunden zur Mitarbeit hier begrenzt oder nicht wie notwendig, so wird sich das im Verlauf des Projektes verschlimmern und schwer korrigieren lassen.
Die Phase 1 unterscheidet sich nun nach Wasserfallmethode und Agile entscheident. Bei der Wasserfallmethode würde man nun versuchen die Planung für die Moves auf Basis dieser Liste komplett zu planen. Danach erfolgt die Umsetzung dieser Planung. Ein Replanning währe nicht vorgesehen. Dieses ist bei n x 1.000 Assets reine Glücksache das so etwas geht.
Bei dem agilen Ansatz würde diese Planung und aktualisierung des "Product Backlog" eine kontinuierliche Tätigkeit werden, welche nur so weit vorrauschauend sein muss um genug Items für die kommenden Sprints zur Verfügung zu stellen. Dabei sind wir bei einem weiteren agilen Element, dem "Sprint". Hier kommen nun zwei Faktoren ins Spiel die besonders sind.

  • Das Development Team, welches entscheidet was es aus dem "Product Backlog" in das "Sprint Backlog" übernimmt
  • Die Dauer des Sprints, welche maximal 4 Wochen sein sollte. Am Anfang sollten weniger Elemente enthalten sein und die Dauer < 4 Wochen gewählt werden.

Diese Ansätze sind grundlegend unterschiedlich und bringen eine grundsätzlich unterschiedliche Erwartungshaltung auf Kundenseite mit.
Bei der kompletten Planung der Umzüge (Wasserfallmethode) ist die Flexibilität gering und beim scheitern einer Umzugswelle ist der Ansatz gestorben und das Vertrauen des Kunden in den Dienstleister fort. Der Dienstleister hat spätesdens jetzt massive Probleme im Projekt.
Der agile Ansatz bringt die Chance mit sich, kleine Wellen zu schneidern, die Erkenntnisse aus dem Move in die kommende Welle sofort einzubauen. Auch sind Anpassungen, zeitlich, Ressourcen, technische Abhängigkeiten, noch bis vor oder sogar im Sprint möglich.
Für klassische Projektmanager wird es jetzt etwas komisch in der Magengegend.
Das "Development Team" soll eigenverantwortlich entscheiden welche, wie viele Assets es übernimmt und soll auch noch sagen wie lange es braucht. Das ist aber so gewollt und auch die Zusammensetzung des Teams ist bewusst so gestaltet, das es ohne fremde externe Hilfe den Sprint abarbeiten kann.
Warum soll das funktionieren?
Das Developement Team setzt sich aus Experten zusammen die ein commitment abgegeben haben. Sie stehen mit Ihrem Namen hinter der Entscheidung des "Sprint Logs". Die Zusammensetzung des Teams ist bewusst so gewählt, das sie "functional für den Sprint" sind, bedeutet alles was an Arbeit anfällt in diesem "Sprint" können sie auch.

Links:

imported from www2.georg-keller.eu