von Redaktion IT-A…
Lesezeit
3 Minuten
Möglichkeiten und Stolpersteine beim Replatforming
In komplexen, über Jahre gewachsenen Systemlandschaften lauern viele Gefahren. Häufig offenbaren sie sich jedoch nicht im laufenden Betrieb, sondern erst bei der Arbeit an einzelnen Komponenten, etwa für ein Replatforming oder bei der Integration neuer Systeme. Damit dabei nicht ein Totalausfall mit fatalen, wenig vorhersehbaren Folgen eintritt, gilt es, die gängigen Problemfelder für Stabilität und Sicherheit zu kennen. Ein Praxisbericht für erfolgreiches Replatforming.
In die Jahre gekommene IT-Infrastrukturen erwecken bei IT-Administratoren manchmal den Eindruck, sie seien in John Hammonds "Jurassic Park": Selbst, wenn auf den ersten Blick alles störungsfrei zu laufen scheint, lauern im Hintergrund überall Risiken. Schwächen bei Stabilität und Sicherheit können sich immer auftun, wenn gewachsene Applikationen zu komplex, unflexibel und schwer wartbar werden – oder sich ihrem End of Life nähern.
Bleibt etwa die Unterstützung einzelner Komponenten in Form von Updates und Patches aus, öffnen sich im Hintergrund Einfallstore für Cyberkriminelle oder es kommt zu unerwünschten System-Outputs. Die Folgen reichen von einer schlechten Anwendererfahrung und damit sinkender Kundenzufriedenheit bis hin zu eklatanten Compliance- und Datenschutzverstößen, die auch rechtliche Konsequenzen mit sich bringen können. Der Worst Case: ein Totalausfall mit fatalen Folgen.
Replatforming richtig angehen
Um dies zu verhindern, sollten Unternehmen ihre Plattformen immer wieder auf Herz und Nieren überprüfen und in die Jahre gekommene Systeme ersetzen. Das Problem dabei ist oft, dass die Unternehmens-IT über die Zeit komplexe Systemlandschaften erzeugt hat. Als Administrator gilt es, diese am Laufen zu halten und den Geschäftsbetrieb zu gewährleisten. Kommt das Lebensende einzelner Systeme näher, muss deren Austausch oder Modernisierung erfolgen, ohne dass das Geschäft Schaden nimmt. Kunden und Geschäftspartner sollten im Idealfall gar nicht mitbekommen, dass etwas verändert wurde.
Schwachstellen und potenzielle Gefahren offenbaren sich jedoch nicht nur im laufenden Betrieb des Gesamtsystems, etwa in Form von Kundenfeedback oder offensichtlichen Fehlermeldungen. Vielmehr sind es die Interaktionen einzelner Subsysteme, die unerwartete Szenarien zum Vorschein bringen. Jedes System für sich kann in einer Testumgebung reibungsfrei funktionieren – im Realbetrieb mit diversen Querverbindungen sieht es dann jedoch oft ganz anders aus. Folgende Schritte sollten Sie daher beim Replatforming beherzigen.
First things first: Nicht alles auf einmal!
Zuallererst sollten Sie den offensichtlichsten Rat befolgen: nicht zu viel auf einmal. Eine Systemlandschaft, etwa im E-Commerce-Bereich, besteht aus diversen Komponenten: ERP- und PIM-Systeme, die E-Commerce-Plattform selbst mit all ihren Komponenten und zusätzlich angeschlossene Drittsysteme für Ein- und Verkauf oder Lieferung. Steht ein Replatforming-Prozess an, geht dieser – oft getrieben aus dem Business-Operations-Bereich – mit dem Wunsch einher, direkt weitere Systeme auszutauschen oder neue Funktionen hinzuzufügen. Somit wäre gleich alles auf einmal erledigt.
Abgeleitet daraus ergibt sich der zweite Grundsatz, nämlich nie ein System in Gänze auszuwechseln. In einem idealen Szenario sollte niemals eine Applikation auf einen Schlag ersetzt werden, sondern nach Möglichkeit einzelne Teile peu à peu. Je kleiner sich dabei die Veränderungen beziehungsweise die Pakete halten lassen, desto geringer ist das Risiko eines Kontrollverlusts und damit das Ausfallrisiko. Debugging sowie sauberes Testing und die Dokumentation nehmen dabei in der Summe deutlich weniger Zeit in Anspruch, verglichen mit vollumfänglichen Anwendungen oder einem Austausch des Gesamtsystems. Durch eine solche Strategie des "Teil-Replatformings" lässt sich der Betrieb weiterhin sicherstellen – das zu modifizierende System muss weder abgeschaltet werden noch fällt es ungeplant komplett aus.
ln/Bernd Alter, Technical Director bei Turbine Kreuzberg
Bleibt etwa die Unterstützung einzelner Komponenten in Form von Updates und Patches aus, öffnen sich im Hintergrund Einfallstore für Cyberkriminelle oder es kommt zu unerwünschten System-Outputs. Die Folgen reichen von einer schlechten Anwendererfahrung und damit sinkender Kundenzufriedenheit bis hin zu eklatanten Compliance- und Datenschutzverstößen, die auch rechtliche Konsequenzen mit sich bringen können. Der Worst Case: ein Totalausfall mit fatalen Folgen.
Replatforming richtig angehen
Um dies zu verhindern, sollten Unternehmen ihre Plattformen immer wieder auf Herz und Nieren überprüfen und in die Jahre gekommene Systeme ersetzen. Das Problem dabei ist oft, dass die Unternehmens-IT über die Zeit komplexe Systemlandschaften erzeugt hat. Als Administrator gilt es, diese am Laufen zu halten und den Geschäftsbetrieb zu gewährleisten. Kommt das Lebensende einzelner Systeme näher, muss deren Austausch oder Modernisierung erfolgen, ohne dass das Geschäft Schaden nimmt. Kunden und Geschäftspartner sollten im Idealfall gar nicht mitbekommen, dass etwas verändert wurde.
Schwachstellen und potenzielle Gefahren offenbaren sich jedoch nicht nur im laufenden Betrieb des Gesamtsystems, etwa in Form von Kundenfeedback oder offensichtlichen Fehlermeldungen. Vielmehr sind es die Interaktionen einzelner Subsysteme, die unerwartete Szenarien zum Vorschein bringen. Jedes System für sich kann in einer Testumgebung reibungsfrei funktionieren – im Realbetrieb mit diversen Querverbindungen sieht es dann jedoch oft ganz anders aus. Folgende Schritte sollten Sie daher beim Replatforming beherzigen.
First things first: Nicht alles auf einmal!
Zuallererst sollten Sie den offensichtlichsten Rat befolgen: nicht zu viel auf einmal. Eine Systemlandschaft, etwa im E-Commerce-Bereich, besteht aus diversen Komponenten: ERP- und PIM-Systeme, die E-Commerce-Plattform selbst mit all ihren Komponenten und zusätzlich angeschlossene Drittsysteme für Ein- und Verkauf oder Lieferung. Steht ein Replatforming-Prozess an, geht dieser – oft getrieben aus dem Business-Operations-Bereich – mit dem Wunsch einher, direkt weitere Systeme auszutauschen oder neue Funktionen hinzuzufügen. Somit wäre gleich alles auf einmal erledigt.
Soll aber alles auf einmal bewerkstelligt werden, bleiben die saubere Implementierung sowie die Konfiguration meist auf der Strecke. Damit geraten die Systeme zu "Moving Targets", was die Fehleranalyse und die Antizipation von Problemen bei der Implementierung drastisch erschwert. Ein Beispiel verdeutlicht das: Angenommen, es geht um den Aufbau eines neuen E-Commerce-Systems. Während das initiale Setup des Systems in der Regel kaum eine Herausforderung darstellt, sind es oft die einzelnen zusätzlichen Komponenten, die Schwierigkeiten bereiten können – besonders, wenn sich hier parallel Entwicklungsschritte vollziehen.
Während etwa der Produktimport läuft, um das System mit den Daten aus der bisherigen Plattform zu befüllen, arbeitet parallel jemand an der Konfiguration des neuen PIM-Systems. Treten nun Fehler auf, so lässt sich kaum oder nur sehr schwer feststellen, ob diese ihren Ursprung in einem verbuggten Import oder der Funktion des PIM liegen.
Solche Szenarien vermeiden Sie, indem Sie einen Teil der etablierten Systeme weiterlaufen lassen und nur graduelle Anpassungen vornehmen. Bei einem PIM, das bereits seit mehreren Jahren reibungsfrei läuft, lassen sich bestimmte Fehlerquellen von vornherein ausschließen und die Fehlersuche konzentriert sich auf die gegebene Veränderung am Gesamtsystem. Dieses vereinfachte Beispiel illustriert eindrucksvoll, was bei zwei Komponenten passieren kann.
Die Folgen eines überstürzten Replatforming-Prozesses mit diversen Änderungen an unterschiedlichen Systemen sind daraus leicht ableitbar. Erfahrungsgemäß steigt die Anzahl der Fehlerquellen bei multiplen Operationen exponentiell. Daher lautet das Entwicklungs-Credo stets, Änderungen nacheinander anzugehen und vor dem Hintergrund eines verlässlichen Systems oder einer Schnittstelle zu arbeiten. Das bekannte Verhalten und etwaige Schwachstellen fließen so in die Kalkulation ein.
Abgeleitet daraus ergibt sich der zweite Grundsatz, nämlich nie ein System in Gänze auszuwechseln. In einem idealen Szenario sollte niemals eine Applikation auf einen Schlag ersetzt werden, sondern nach Möglichkeit einzelne Teile peu à peu. Je kleiner sich dabei die Veränderungen beziehungsweise die Pakete halten lassen, desto geringer ist das Risiko eines Kontrollverlusts und damit das Ausfallrisiko. Debugging sowie sauberes Testing und die Dokumentation nehmen dabei in der Summe deutlich weniger Zeit in Anspruch, verglichen mit vollumfänglichen Anwendungen oder einem Austausch des Gesamtsystems. Durch eine solche Strategie des "Teil-Replatformings" lässt sich der Betrieb weiterhin sicherstellen – das zu modifizierende System muss weder abgeschaltet werden noch fällt es ungeplant komplett aus.
| Seite 1 von 2 | Nächste Seite >> |
ln/Bernd Alter, Technical Director bei Turbine Kreuzberg
