Never change a running system – so lautet eine bekannte Weisheit in der IT. Das ist natürlich nicht ganz ernst gemeint: Es lässt sich kaum vermeiden, auch in laufende IT-Systeme einzugreifen und sie anzupassen. In die Jahre gekommene Onlineshops oder Beschaffungsplattformen entsprechen irgendwann nicht mehr den Bedürfnissen des Marktes, passen nicht zu aktuellen Leistungs- und Sicherheitsstandards oder sind nicht mehr anschlussfähig für moderne Technologien. Also muss etwas Neues her. Selten bedeutet das jedoch eine komplette Neuentwicklung. Häufig bedeutet es, einzelne Funktionen zu verbessern, Features zu ergänzen und neue Services einzubinden.

Für eine Technologie-Agentur gehört so ein Projekt zum Alltag – ebenso die anfänglichen Herausforderungen. Legacy-Systeme sind häufig unzureichend dokumentiert und nutzen alte Bibliotheken oder Frameworks. Oft sind die notdürftig mit Patches und Workarounds an die aktuelle IT-Umgebung angepasst. Wer jetzt einfach mit der Entwicklung loslegt, nimmt verlängerte Projektlaufzeiten in Kauf und damit einen ausgedehnten Parallelbetrieb, bis die neue Lösung einsatzbereit ist.

Der Ausweg heißt Plattform-Audit. Dabei stellt ein Team der Agentur alle Informationen zusammen, die für die spätere Umsetzungsstrategie entscheidend sind und den Entwickler:innen bei der Implementierung helfen. Das ist als ein eigenes Projekt vor dem Projekt zu begreifen, das letztlich Effizienz und Termintreue für die Umsetzung bringt.
Erreicht wird beides mit Best-Practices, die den Audit vereinfachen und die Qualität der Ergebnisse erhöhen. So ist es sinnvoll, in fünf Schritten vorzugehen:

1. Technologische Ziele definieren: Ohne Ziel kein Erfolg. Das Team muss Grundlegendes explizit und gemeinsam festlegen, etwa: Sollte die Plattform erweitert, optimiert oder gar vollständig erneuert werden? Gleiches gilt auch für Zielkriterien, die bei der Bewertung von später formulierten Optionen helfen. Sprich: Wann kann man überhaupt von einem erfolgreichen Projekt sprechen?
2. Gains und Pains ermitteln: In diesem Schritt geht es um die wichtigsten technischen Fragestellungen. An welchen Stellen macht die bestehende Applikation Schwierigkeiten? Wo ist die Arbeitsgeschwindigkeit zu niedrig? Wo werden Daten nicht optimal verarbeitet? Wo und wann kommt es zu Störfällen?
3. Die Systemlandschaft analysieren: Ein korrektes Bild der gesamten IT-Infrastruktur ist ein mächtiges Werkzeug, um Abhängigkeiten und die Projektabfolge festlegen zu können. Dargestellt werden sollten alle Anwendungen und nicht nur ein kleiner Ausschnitt rund um das Zielsystem. Denn die Datenflüsse ziehen sich häufig durch mehrere Anwendungen hintereinander. In vielen Unternehmen sieht die IT-Landschaft aus wie ein Teller kalter Spaghetti – alles hängt mit allem zusammen und lässt sich kaum voneinander lösen.
4. SWOT-Analyse: Hierbei wird ermittelt, wo die grundlegenden Risiken, Stärken und Schwächen des aktuellen Anwendungsstatus liegen – und die Chancen, die das Entwicklungsprojekt verwirklichen soll. Grundlage sind dabei nicht nur die Punkte, die das Tech-Team selbst ermittelt hat. Ebenso wichtig sind die Einschätzungen weiterer Mitarbeiter:innen und Stakeholder.
5. Tiefenanalyse: Hier werden die einzelnen Punkte aus der bisherigen Analyse auf den Prüfstand gestellt und genauer untersucht. Das Ziel dabei ist, den Entwicklungsaufwand möglichst exakt zu ermitteln und einen Plan für das weitere Vorgehen zu formulieren.

Dabei können sich die einzelnen Audit-Schritte durchaus überlappen und gegenseitig verstärken. Neue Erkenntnisse im Rahmen einer Risikoanalyse bedeuten etwa, dass sich das Team bestimmte Komponenten in der Systemlandschaft noch einmal genauer ansehen muss. So nimmt die Detailtiefe der Informationen mit jeder Umdrehung der Audit-Spirale zu – bis zum Schluss ein Projektplan formuliert werden kann, der konkrete Optionen und Szenarien für die Umsetzung liefert.

Besonders entscheidend ist zudem, ob es sich um ein Optimierungsprojekt handelt oder um ganzheitliches Replatforming. Im ersten Fall sollte das Team die Punkte mit dem größten Optimierungspotenzial definieren und dann genauer analysieren. Idealerweise geht der Blick dabei zunächst in Richtung Spaghetti-Teller: Eine Entkopplung der Systeme steht an, zum Beispiel über eine zentrale Middleware. Replatforming ist aufwendiger. Es erfordert eine genaue Festlegung unterschiedlicher Migrationsszenarien und eine dazu passende Strategie. Dabei müssen die Besonderheiten der Zielplattform berücksichtigt und als Anforderungen in den Audit übernommen werden.

Der Erfolg eines Plattform-Audits hängt von einigen Faktoren ab. So sollten alle relevanten Stakeholder schon für den Audit ins Boot geholt werden, nicht erst im Umsetzungsprojekt. Dazu zählen gerade auch Teams der IT und die internen Nutzer:innen, die zum Beispiel das Order-Management verantworten oder sich um das Pricing kümmern.

Besonders wichtig sind präzise beschriebene Zielkriterien. Es muss klar sein, was das Kundenunternehmen, interne Anspruchsgruppen und letztendlich die Unternehmensstrategie von einem erfolgreichen Projekt erwarten. Das kann sehr unterschiedlich sein: etwa ein Replatforming ohne Umsatzschwund, das Senken der Kosten beim Dienstleister oder ein besseres Abfedern von Lastspitzen. Kurz: Das Audit-Team legt die unausgesprochenen, oft sehr unterschiedlichen Erwartungen offen und bringt sie auf einen gemeinsamen Nenner. Dabei ist es wichtig, ebenfalls interne Machtstrukturen und Entscheidungswege zu berücksichtigen, die sich im Zweifel auf die Umsetzung auswirken.

Ein dritter Erfolgsfaktor scheint selbstverständlich, wird aber oft vernachlässigt: eine genaue und materialreiche Dokumentation. Wichtig sind vor allem Architekturschemata, Datenmodelle und Datenflussdiagramme, um den Status quo festzuhalten und daraus einen optimierten Prozess abzuleiten. In der Zusammenarbeit ist es empfehlenswert, mit kollaborativen Tools wie virtuellen Whiteboards oder interaktiven Flowcharts zu arbeiten. Damit lassen sich einfacher Abläufe skizzieren und Entscheidungswege verfolgen – vor allem aber Wissen direkt digital festhalten.

In diesem Zusammenhang gibt es eine weitere Herausforderung: Wissensinseln, also Teams oder Einzelpersonen, die als einzige bestimmte Systeme, Datenflüsse und Prozesse genau kennen. Das betrifft häufig alte Technologien, die nicht mehr im Markt sind. Häufig nutzen Unternehmen sogar Anwendungen, ohne dass es noch Wissensträger für sie gibt. Diese potenziellen Stolperfallen müssen dringend ans Licht gebracht werden.

Die beteiligten Teams sollten keine Angst vor neuen Aufgaben haben. Es gibt keine Schablone für die Umsetzung komplexer Entwicklungsprojekte. Für alle Beteiligten gibt es viel Neues zu lernen – überraschungsarme Tage sind selten. Doch ein professionell umgesetzter Plattform-Audit deckt viele Schwierigkeiten im Vorfeld auf und erleichtert die Entwicklung.