Viele Unternehmen – darunter die großen Versicherungen und Banken – arbeiten seit Jahrzehnten mit Mainframe-Lösungen. Immer häufiger stellt sich die Frage, wie sich die bisherigen Host-Applikation möglichst reibungslos durch dezentrale Applikationen ersetzen lassen. Mit der UBS-Hainer TDM Suite ist dies problemlos möglich.
Schritt für Schritt von DB2 zu Oracle
Für einen fließenden Übergang müssen die verwendeten Tools, die bisher meist ausschließlich DB2-Datenbanken verwalten, nun in die Lage versetzt werden, z.B. auch mit Oracle-Datenbanksystemen zu arbeiten. Damit der Übergang auch hier funktioniert, muss das neue – für die Testdatengewinnung verwendete – Tool zwar auf dem bisherigen Host laufen, aber eben auch in der Lage sein, das Gleiche wie bisher auf Oracle-Datenbanksystemen durchzuführen.
Die UBS-Hainer TDM Suite bietet hierfür die optimalen Voraussetzungen, da sie sowohl Mainframe wie auch Distributed Systems beherrscht. Ist solch eine neue Konstellation dann einmal eingerichtet, wird Oracle als Standarddatenbank definiert. Ab da bekommt alles, was in den produktiven Stream hereinkommt, jede neu aufgesetzte Applikation eine Oracle-Datenbank. Und wenn Oracle damit zum neuen Standard wird, bewirkt das über die Zeit hinweg eine sukzessive und automatische Umstellung des Gesamtsystems.
Reibungslos ins neue System
Dabei kopiert die UBS-Hainer TDM Suite keine Daten zwischen DB2 und Oracle hin und her (obwohl dies jederzeit möglich wäre), etwa um eine neue Testdaten-Tabelle zu bestücken. Es ist eher wie bei einem Staffellauf, bei dem der erste mit dem nächsten Läufer noch eine Weile parallel mitläuft, bis dieser dann übernimmt. Praktisch bedeutet dies, dass in den Entwicklungssystemen eine neue Oracle-Datenbank auftaucht, z.B. als neue Applikation für die „Speicherung der Schadenfallbesichtigung“. Diese neue Applikation wird dann an die TDM Suite angebunden, enthält aber zunächst keine Daten.
Erst wenn in der laufenden Produktion das nächste Mal Daten dafür anfallen, wird die Applikation produktiv. Das kann dann je nach Bereich ein, zwei Monaten dauern. Ab diesem Moment können dann Daten darüber bereitgestellt werden. Die alten Informationen bleiben in den alten DB2-Tabellen enthalten, werden aber nach und nach irrelevant.
Neue Flexibilität und Effizienz
Auf diese Weise gelang es einem Kunden von UBS-Hainer sein System mit über 7 Millionen Versicherten sukzessive umzustellen. Sein erklärtes Ziel ist es, den Mainframe nach einer Übergangsphase von einigen Jahren komplett abzuschalten. Dies wurde mit hoher Priorität angegangen. Um die Projektgeschwindigkeit zu erhöhen, wurden dafür sogar 100 neue Mitarbeiter eingestellt.
Ursprünglich wurden die 7 Millionen Versicherten für das Testing in verschiedenen Applikationen aufgerufen, was aber im Zuge des Projekts vereinheitlicht wurde. Heute gibt es einen zentralen Einstiegspunkt in Form eines einfach zu bedienenden Datashops. Dahinter hängen dann die entsprechenden Anwendungen, die von einer Handvoll Experten modelliert werden können.
Agiles Testing mit hochwertigen Testfalldaten
So arbeiten im beschriebenen Fall rund 100 Personen mit dem Datashop. Dabei handelt es sich etwa zur Hälfte um Entwickler und zum anderen um Fachmitarbeiter aus dem Versicherungsgeschäft, die den Teams zugeteilt werden. Es gibt keine zentrale Testabteilung mehr, sondern jeder kann sich für seinen Test jederzeit einen Testfall in Produktionsqualität kopieren.
Sämtliche Testteams wurden abgeschafft. Die Tester sind Teil des jeweiligen Applikationsteams. Dieses ist für die Qualität ihrer gelieferten Software verantwortlich. Und alle Querschnittsoperationen werden durch automatisierte Tests auf den verschiedenen Ebenen abgedeckt. Mit diesem Set-up wurde ein extrem hoher Grad der Automatisierung erreicht, sowie ein agiles und iteratives Testing ermöglicht.
