Suche
Ein neues Nest

Herausforderungen der IT-Migration: eine Case Study

Philipp Benkler , Veronika Wasza
Ein neues Nest

IT-Systemlandschaften werden ständig weiterentwickelt: Upgrades und Aktualisierungen von Software, Datenbanken oder Hardware gehören zum ganz normalen Alltag von IT-Verantwortlichen und Entwicklern. Dennoch machen viele Unternehmen irgendwann die Erfahrung, dass Updates alleine nicht mehr ausreichen und alte Systeme sowie deren Funktionalitäten an ihre Grenzen stoßen. Ein neuer Server, ein neues Betriebssystem oder eine neue Plattform werden dann notwendig. Ein klarer Cut muss es sein, ein grundlegender Wechsel – eine so genannte (ablösende) Migration.

Der Crowdtesting-Anbieter Testbirds, der Software mithilfe der weltweiten Internetgemeinde auf Benutzerfreundlichkeit und Funktionalität testet, sah sich rund anderthalb Jahre nach der Unternehmensgründung mit der Notwendigkeit einer Migration konfrontiert. Welche Herausforderungen es dabei zu meistern galt und was andere Unternehmen aus diesen Erfahrungen lernen können, erläutert der folgende Beitrag.

Der Nestbau: „Schnell, schnell“, lautete die Devise

Das Unternehmen Testbirds wurde Ende 2011 gegründet. Ursprünglich war geplant, die Plattform – das so genannte „Nest“ – im Juni 2012 in Betrieb zu nehmen. In rund sechs Monaten galt es Design, Workflow und User Management zu definieren und zu entwickeln. Eigentlich. Denn bereits im Dezember 2011 stand der erste Kunde vor der Tür und wollte ein erstes Projekt umsetzen. Die hierfür benötigte Plattform zur Testabwicklung musste also schnellstmöglich einsatzbereit sein. Gerade einmal zwei Wochen blieben dem Team, um ein System aufzusetzen, das zumindest über die wichtigsten Grundfunktionen verfügte, um Softwaretests abwickeln zu können.

Die zentrale und wichtigste Funktion im Nest war und ist dabei das Workflow Management Tool, das ein effizientes Arbeiten mit den verschiedenen Status unterschiedlicher Benutzer ermöglicht. Bei Testbirds überprüfen Endanwender, die so genannte Crowd, Software hinsichtlich Funktionalität und Usability. Die Tester arbeiten dabei „on remote“ von Zuhause aus, wodurch eine gute Kommunikation unerlässlich ist. Insgesamt treffen im Nest drei unterschiedliche Nutzergruppen aufeinander. In der Regel schreibt jeder Tester (Bird) einen Bericht und erfasst separat Bugs. Des Weiteren überprüft ein Projektmanager (Birdmaster) alle eingehenden Berichte und weist diese bei mangelhafter Qualität an den Tester zurück. Erst nach der Freigabe durch den Birdmaster werden die Ergebnisse dem Kunden schließlich als dritte Usergruppe sichtbar gemacht.

Aufgrund des Zeitdrucks war es allerdings nicht möglich, eigene Codes für das Nest zu programmieren, weshalb die Entscheidung auf Drupal 7 fiel. Denn die nötigen Prozesse ließen sich sehr gut durch die dort vorhandenen „Contributed Modules“ abbilden. CI und Usability mussten aufgrund des knappen Zeitfensters ohnehin erst einmal hintanstehen. Und so war das Nest beim ersten Test alles andere als perfekt – aber zumindest erfüllte es für den Anfang seinen Zweck. In den folgenden Monaten wurde die Plattform um zahlreiche Features erweitert, die Contributed Modules durch Custom Code ergänzt bzw. weiterentwickelt und komplett neue Funktionen erstellt.

Warum ein neues Nest? Anforderungen an die Plattform

Mit der Ausweitung und Internationalisierung der Community, des Portfolios sowie des Kundenstamms gelangte das alte Nest zunehmend an seine Grenzen. Mit der Zeit kristallisierte sich heraus, dass es nicht mehr ausreichte, das System nur zu verbessern. Eine komplett neue Plattform musste aufgesetzt werden, um den gewachsenen Anforderungen gerecht zu werden. Im Herbst 2013 fiel dann schließlich die Entscheidung für ein neues Nest, das auf den Namen „Cuckoo“ getauft wurde.

Im ersten Schritt galt es, genau zu analysieren, welche Anforderungen und Ziele das zu entwickelnde System erfüllen sollte, welche Teile oder Funktionalitäten von der alten Plattform übernommen werden konnten und wo komplett neue, eigene Codes geschrieben werden mussten. Je umfangreicher die Änderungen, desto länger dauert natürlich der gesamte Prozess. So nahm das Team das Altsystem nochmals genauer unter die Lupe und identifizierte auf diesem Weg häufig auftretende Probleme sowie hilfreiche Funktionen. Ergänzend dazu wurden zur Optimierung auch das Feedback der Tester sowie die Anregungen der Kunden einbezogen. Zwei Hauptziele wurden dabei festgelegt, die bei der neuen Plattform höchste Priorität genießen sollten – Flexibilität und hohe Benutzerfreundlichkeit für alle drei Gruppen, die im Nest arbeiten: Tester, Projektmanager und Kunden.

Neben der Frage nach den Anforderungen an das neue System mussten die Verantwortlichen auch entscheiden, welcher Weg bei der Migration beschritten werden sollte: Eine Stichtagsumstellung oder eine schrittweise Migration. Beide Varianten besitzen Vor- als auch Nachteile. Da die Stichtagsumstellung durch einen kurzen Umstellungszeitraum geprägt ist und der parallele Betrieb von Alt- und Neusystem vermieden werden kann, entschied sich Testbirds für diesen Weg. Die Kunden und das laufende Geschäft sollten durch die Umstellung so wenig wie möglich beeinträchtigt und die Downtime entsprechend kurz gehalten werden. Das Migrationsprojekt erschien in der Gesamtbeurteilung überschaubar genug, um diese Variante zu rechtfertigen.

Konzeption und Vorbereitung: Vom Zeitplan zur To-do-Liste

Bei der Konzeption von Cuckoo bezog das Unternehmen nicht nur die bisher gesammelten Erfahrungen ein; auch die künftige Entwicklung wurde so weit wie möglich mitbedacht. Neben einem Pflichtenheft für die erforderlichen Funktionalitäten galt es auch, das Design festzulegen und eine Entscheidung bezüglich Softwarearchitektur, Programmiersprachen und Frameworks zu treffen. Entwickelt wurde die neue Umgebung komplett in PHP 5 sowie dem Framework Symfony 2. Darüber hinaus musste das Unternehmen festlegen, wer die Programmierung übernehmen sollte und wie die hierfür notwendigen Kapazitäten geschaffen werden konnten. Da bei Testbirds die Plattform das Herzstück des Unternehmens ist und auch das bisherige System maßgeblich aus den praktischen Erfahrungen heraus weiterentwickelt wurde, stand außer Frage, dass die Entwicklung Inhouse und von den eigenen Programmierern übernommen werden muss und kein externer Dienstleister zum Zuge kommen kann. Auf Basis der vorhandenen Kapazitäten setzte das Projektteam daher einen groben Zeitplan auf und legte ein erstes Datum für die Stichtagsumstellung fest. Neben der Erstellung von To-do-Listen und der Aufteilung der Aufgaben innerhalb des Entwicklerteams musste auch festgelegt werden, in welchem Umfang noch Änderungen am alten System vorgenommen werden sollten. Hierzu kategorisierten die Projektverantwortlichen typischerweise auftretende Fehler entsprechend ihrem Schwierigkeitsgrad und hinterlegten diese mit einer Agenda, ab wann diese nicht mehr bearbeitet werden sollten.

Stolpersteine bei der Migration

Bei der Entwicklung von Cuckoo setzte Testbirds auf ein agiles Vorgehen. Nach Abschluss der Konzeptionsphase dauerte es insgesamt über ein Mannjahr, bis die neue Plattform programmiert war und alle Datensätze umgezogen werden konnten. Der Zeitplan geriet dabei das eine oder andere Mal durchaus heftig ins Wanken. Es zeigte sich deutlich, wie wichtig es ist, trotz Planung flexibel zu bleiben, aber wenn nötig eine gewisse Portion Pragmatismus walten zu lassen. So tauchten während der Programmierung häufig vollkommen neue Ideen hinsichtlich der Funktionalitäten auf, die das Team ursprünglich gar nicht angedacht hatte, aber durchaus als hilfreich einstufte. Hier stellte sich stets die Frage, ob die Idee sofort umgesetzt werden sollte – und damit der Zeitplan unter Umständen komplett über Bord geworfen werden müsste – oder ob die Umsetzung erst zu einem späteren Zeitpunkt erfolgen sollte.

Wie erwartet mussten während der Zeit, welche die Entwicklung des neuen Nests benötigte, auch Änderungen am Altsystem durchgeführt werden, um die aktuellen Bedürfnisse des Unternehmens und der Kunden zu erfüllen. Die Einstufung, was noch gemacht wird und was direkt erst im neuen Nest umgesetzt werden sollte, erwies sich nicht selten als schwierig. Und natürlich stellte sich auch einmal mehr die Frage: „Machen wir es direkt jetzt – oder erst später“?

Neben dem Schreiben des komplett neuen Codes nahm insbesondere die reine Datenmigration der über 50 000 registrierten Tester und mehr als 200 Kundenaccounts viel Zeit in Anspruch. Rund 25 Prozent des Aufwands fielen alleine auf diesen Teil des Projekts. Da die Crowd und der Kundenstamm auch während der Entwicklung des neuen Nests kontinuierlich weiter wuchs, mussten letztlich deutlich mehr Daten umgezogen werden als eingeplant. Außerdem galt es für die Projektverantwortlichen zu überlegen, ob alle Konten umgezogen oder ob ggf. die Gelegenheit genutzt werden sollte, Accounts, die seit Längerem nicht aktiv waren, gleich auch zu deaktivieren. Da die Prüfung der einzelnen Datensätze jedoch zu viel Zeit in Anspruch genommen hätte, verwarf das Team diese Idee wieder. Im neuen Nest sollte es aber fortan eine automatische Benachrichtigung geben, falls Konten über einen längeren Zeitraum nicht mehr benutzt wurden.

Die Stichtagsumstellung: Schlaflos beim Shutdown

Als ein Großteil der Entwicklungsarbeit erledigt war, legten die Verantwortlichen ein festes Datum für die Stichtagsumstellung fest. Um die Kunden und die Tester möglichst wenig zu beeinträchtigen, wurde hierfür ein Wochenende ausgewählt. Alle Beteiligten mussten informiert und Projekte entsprechend terminiert werden. Natürlich stellte sich die Frage, mit wie viel Vorlauf die Umstellung angekündigt werden sollte. Je früher ein Shutdown angemeldet wird, desto höher ist natürlich das Risiko, dass der Termin am Ende doch nicht zu halten ist. Zu kurzfristig sollte die Ankündigung aber auch nicht erfolgen, um den Betroffenen einen entsprechenden Vorlauf für ihre Planung zu ermöglichen. Bei der Inbetriebnahme von Cuckoo erschien eine Zwischenlösung daher als die optimale Lösung. Kunden, die bereits einen Test in den Wochen vor oder nach dem Wochenende der Stichtagsumstellung angekündigt hatten, wurden frühzeitig darauf hingewiesen, dass es unter Umständen zu Ausfällen kommen kann. Die Testercrowd erfuhr von der Umstellung erst etwas später, als der Termin als relativ sicher zu halten eingestuft werden konnte.

Für die Stichtagsumstellung im Mai 2014 stoppte Testbirds alle laufenden Projekte über ein Wochenende, um den gleichzeitigen Betrieb von Alt- und Neusystem zu vermeiden. Zeitunkritische Projekte wurden erst nach dem Wochenende gestartet, alle anderen sollten möglichst vorher abgeschlossen sein. Während des Wochenendes hatten weder Kunden noch Tester oder das Projektmanagement einen Zugriff auf ihre Accounts bzw. die Plattform. Im Entwicklerbüro liefen die Tastaturen hingegen heiß und wurde das ganze Wochenende über – Tag und Nacht – mit Hochdruck gearbeitet, um das neue Nest pünktlich am Montagmorgen in Betrieb nehmen zu können.

Die Migration ist erst der Anfang

Die Umstellung auf das neue Nest erfolgte ohne größere Zwischenfälle oder Probleme. Der Zeitplan konnte im Großen und Ganzen eingehalten werden. Mit der Umstellung alleine war es aber noch längst nicht getan. Da die Lokalisierung von Cuckoo in englisch führend war – ein großer Teil der Crowd aber aus Deutschland stammt – mussten in den Tagen nach Inbetriebnahme insbesondere bei den Testeraccounts noch sprachliche Anpassungen und Übersetzungen vorgenommen werden. Außerdem galt es, alle Beteiligten in die Funktionalitäten des neuen Nests einzuweisen und die Akzeptanz zu steigern. Die Tester wurden eingeladen, an einem allgemeinen Crowdtest teilzunehmen. Dabei sollten sie sich auf die Suche nach funktionalen Fehlern begeben und die Usability der neuen Plattform bewerten. Das Feedback wurde in den folgenden Monaten stückweise berücksichtigt und umgesetzt.

Seit Inbetriebnahme wird Cuckoo ständig weiterentwickelt, um auf dem aktuellsten Stand zu bleiben und den Anforderungen aller Beteiligten gerecht zu werden. Unerlässlich sind hierfür die praktischen Erfahrungen, die mit jedem neuen Projekt gesammelt werden. So sollen etwa in Kürze neue Funktionalitäten wie die „Bird School“ zur Weiterbildung der Tester und Komponenten für mehr Interaktivität innerhalb der Community folgen. Und auch für eine Ausweitung der Crowdtesting-Services ist Cuckoo bestens für die Zukunft aufgestellt.

Zehn „Lessons Learned“

  1. Man lernt nie aus: Praktische Erfahrung geht oftmals über theoretische Überlegungen.
  2. Die Koordination der Beteiligten aus verschiedenen Unternehmensbereichen ist oftmals nicht einfach: Eine Person muss „den Hut aufhaben“ und die Einhaltung von Deadlines und Verantwortlichkeiten überwachen.
  3. Eine gute Vorbereitung ist das A und O: Ein realistischer, aber ambitionierter Projektplan und eine genaue Timeline sind wichtig. Dennoch sollte man weiterhin flexibel bleiben und die Prozesse laufend anpassen.
  4. Eine Stichtagsumstellung sollte realistisch geplant und alle Parteien zum richtigen Zeitpunkt darüber informiert werden: Der richtige Zeitpunkt muss dabei nicht unbedingt der frühestmögliche Termin sein.
  5. Klare Abgrenzung und Priorisierung der Features für die neue Software: Zu Beginn kann nicht alles umsetzbar und verfügbar sein.
  6. Keep it simple: Kein Technokratismus. Die Architektur muss möglichst einfach sein, die aktuellen Anforderungen erfüllen und flexibles Wachstum zu einem späteren Zeitpunkt ermöglichen. Die Komplexität von Morgen bedenken – aber nicht ab Tag 1 umsetzen!
  7. Ein 1:1-Nachbau bestehender Software, nur mit besserer Architektur und Codebase, ist demotivierend für Entwickler: Im vorliegenden Fall hat sich ein Nachbau mit ein paar neuen „Sahnehäubchen“ zum Umstellungszeitpunkt bewährt. Danach können Schritt für Schritt weitere interessante Features implementiert werden.
  8. Die Fachseite muss frühzeitig beteiligt werden: Was braucht ihr, was können wir heute nicht – oder nur schlecht? Aber auch: Was können wir heute mit der alten Software bereits sehr gut? Hier ist eine maximale Priorisierung vorzunehmen – auch wenn es richtig weh tut.
  9. Die Community in die Entwicklung einzubeziehen hat wertvolle Erkenntnisse geliefert: Durch die Einbindung der wesentlichen Beteiligten und Nutzer des Migrationsprozesses konnte die Akzeptanz für die resultierenden Veränderungen und auch für etwaige Probleme bei der Umstellung gesichert werden.
  10. Der Spaß sollte bei der Arbeit nie zu kurz kommen: Um die Laune im Team aufrecht zu halten, sollte man jederzeit für Abwechslung und Unterhaltung sorgen.
Geschrieben von
Philipp Benkler
Veronika Wasza
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: