Enterprise Cloud System Migration

Heute steigen wir tief in die Schnittstellentechnologie ein und schauen uns ein international aufgestelltes Projekt mit Beteiligung von SYSTECS genauer an. Ein neu zu entwickelndes, großes Enterprise System soll ein bestehendes, in die Jahre gekommenen Systems in mehreren Schritten ablösen. Die Aufgabe ist nicht nur umfangreich, sondern auch sehr komplex, denn Teile der Bestandssoftware sind annähernd 20 Jahre alt und kommen dazu noch teilweise von Drittanbietern. Eine reibungslose Migration der Bestandssoftware in die Geschäftsabläufe des neuen Systems macht das zu einer Mammutaufgabe. In der Verantwortung von SYSTECS liegt die Sicherstellung der Anbindung dieser Bestandssysteme. 

Je nach Alter und Qualität der existierenden Schnittstelle entstehen diverse Problem bei der Implementierung

Die verschiedenen Bestandssysteme verwenden diverse Transportschichten und Kommunikationsprotokolle. Ein Teil davon ist standardisiert, der andere wiederum ist proprietär. Wir möchten uns vier Schnittstellenschwerpunkten zuwenden und diese genauer ansehen: 

1. Fehlende oder unzureichende Schnittstellenspezifikation 

Es existiert entweder keine Schnittstellenbeschreibung oder die existierende Beschreibung ist unvollständig bzw. fehlerhaft, weil z. B. die letzten vorgenommenen Änderungen in der Dokumentation nicht nachgezogen wurden. 

• Eine Analyse mittels Netzwerk-Analyse-Tools wie Wireshark oder tcpdump ist unerlässlich. Diese ermöglichen das Protokollieren und Auswerten realen Netzwerkverkehrs, um die Details des Protokolls per Reverse Engineering zu ermitteln. 
• Durchführen von Integrationstests zur Überprüfung des Kommunikationsprotokolls. Hierfür kann es auch schon zu einem frühen Zeitpunkt sinnvoll sein, einen Prototypen einzusetzen

2. Schnittstelle enthält benötigte Funktionen nicht 

Hier hängt es davon ab, ob die Möglichkeit für Änderungen an der bestehenden Schnittstelle existiert oder nicht. Für viele Altsysteme sowie für Standardprodukte großer Firmen sind individuelle Anpassungen nicht bzw. nicht mehr möglich. Die Applikationslogik der neuen Anwendung muss notfalls mit den Unzulänglichkeiten umgehen können. 

3. Schnittstelle enthält keinen Heartbeat-Mechanismus

Diesist leider bei vielen älteren Kommunikationsprotokollen der Fall. Gerade bei TCP/IP-Verbindungen ist es nicht möglich, einen Verbindungsabbruch auf Netzwerkebene zu detektieren. Um das Problem zu überwinden gibt es folgende Optionen: 

• Pings über das ICMP Protokoll können implementiert werden. Diese stellen zumindest die Erreichbarkeit des Zielservers sicher, nicht aber der Zielanwendung. Für die Erkennung von Netzwerkausfällen sind Pings aber bereits ausreichend.
• Je nach Anwendungsprotokoll und Fehlertoleranz des Bestandssystems kann es weitere Möglichkeiten geben, einen fehlenden Heartbeat-Mechanismus zu kompensieren:
  • Es gibt eine „Dummy“-Nachricht, die periodisch verschickt werden kann (z. B. eine Statusabfrage des Zielsystems).
  • Das Zielsystem kommt damit klar, dass periodisch eine Nutznachricht mit ungültigen Werten geschickt wird. 
  • Idealerweise wird eine Nachricht gewählt, die vom Zielsystem beantwortet wird. So hat die sendende Anwendung über die Netzwerkerreichbarkeit hinaus die Gewissheit, dass das Zielsystem noch ordnungsgemäß funktioniert.

4. Sicherheit 

Viele ältere Systeme enthalten keine Authentifizierungsmechanismen und keine Verschlüsselung des Datenverkehrs. In vielen Fällen lässt sich dieses Problem lösen, indem man den Netzwerkverkehr durch einen VPN-Tunnel routet. Das macht aber nur dann Sinn, wenn eine physische Zugangskontrolle zu den Serversystemen auf beiden Seiten gewährleistet werden kann.