Die Antwort ist einfach: Nicht nur einen, sondern viele. In meinem letzten Beitrag hatte ich angekündigt, in den nächsten Wochen drei wesentliche Lösungsszenarien für eine Modernisierung der Banken-IT vorzustellen.
Beginnen werde ich mit der goldenen Mitte: Der Migration auf kosteneffiziente und wartungsfreundliche Plattformen mit offener Komponentisierung.
Heterogene Technologien als Grundübel
Jedes Unternehmen hat seine eigene Geschichte, hat eigene Richtungsentscheidungen getroffen und ist eigene Wege gegangen. In unseren Future-IT-Projekten identifizieren wir vor allem in drei Bereichen immer wieder heterogene Technologien mit komplexen Integrationsverfahren:
- Betriebsplattformen,
- Entwicklungstechnologien und
- Applikationslandschaften
sind selten aus einem Guss, sondern meist natürlich gewachsen. Wechselnde Verantwortlichkeiten, sich fortwährend verändernde Technologie- und Applikationsangebote, kürzer werdende Time-to-Market-Anforderungen, Modetrends und Top-Down-Interventionen – das alles hat eine unflexible, intransparente und veraltete Landschaft mit hohen TCO-Kosten hinterlassen. Oft geht diese Entwicklung mit einem unkontrollierten Funktions- und Datenmanagement einher. Dann kommen Redundanz- und Inkompatibilitätsprobleme auf der Daten- und Funktionsseite hinzu.
Der große Befreiungsschlag macht selten Sinn
Stößt man auf eine derartig ausgeprägte Symptomlage, so ist die Frage nach einem Ausweg aus diesem Dilemma legitim und guter Rat teuer. Alle Herausforderungen auf einmal zu lösen, würde tatsächlich einer Quadratur des Kreises gleichkommen. Mit punktuellen Maßnahmen Budget für den nächsten Optimierungsschritt freizusetzen, liegt zwar auf der Hand, hat in der Praxis aber kaum Relevanz. Ich stelle immer wieder fest, dass das verantwortliche Management nach dem großen Befreiungsschlag sucht. Dieser verschlingt dann meistens ein Vielfaches des geplanten Budgets – wenn er denn überhaupt erfolgreich zu Ende geht. Denn in nahezu 50 Prozent der Fälle schlägt er komplett fehl, weil die Komplexität nicht beherrscht wird. Trotzdem raten einige große Beratungshäuser ihren Kunden immer wieder zu derartigen Mammutprojekten. Ich möchte hier unterstellen, dass sich die Motivationslage für einen solchen Rat nicht am Erfolgsdruck des Kunden orientiert, sondern am Erfolgsdruck des eigenen Hauses – nämlich Manpower beim Kunden abzusetzen.
Einen Schritt nach dem anderen
Wir bevorzugen eine Strategie der kleinen Schritte, quasi die „Agile-and-Scrum“-Methode für die Modernisierung der IT. Das heißt, wir suchen nach den größten Produktivitätsblockern bzw. Kostentreibern, prüfen Substitutions-, Emulations- oder Migrationsoptionen und kreieren darauf basierend ein neues, punktuelles IT-Szenario mit qualitativen und quantitativen Vorteilen:
- Qualitativ: Verbesserungen hinsichtlich Flexibilität, Zukunftsoffenheit, Stabilität und Compliance zur strategischen Ausrichtung der zukünftigen IT
- Quantitativ: reduzierte Lizenzkosten, weniger Service- und Maintenancekosten in einem kompetitiven Angebotsumfeld
Aus der Theorie in die Praxis…
Im Rahmen unserer Future-IT-Projekte sind wir u.a. auf die folgenden Kostentreiber gestoßen:
- Hardwareplattformen („Hosts“ aus grauer Vorzeit)
- Applikationsplattformen (IMS, CICS, UTM, Tuxedo, JCL, JES2)
- redundante Technologien auf einer Plattform
- Datenbankplattformen (DL/1, UDS, ADABAS, Filesysteme)
- proprietäre Technologien mit hohen Lizenzkosten
- betagte 2GL-, 3GL- oder auch 4GL-Sprachen (Assembler, PL/1, Natural)
- unflexible Standardsoftware
Um diesen Kostentreibern den Garaus zu machen, bedarf es einer ausgefeilten Migrationskompetenz – basierend auf Parsern, plattformunabhängiger Architekturkompetenz sowie Modellierungs-, Emulations- und Testautomationskompetenz. Know-how, das wir in den letzten 35 Jahren mit unseren eigenen Systemen erworben haben. Daraus haben wir eine Crossplattform-Technologie entwickelt, die es uns erlaubt…
- partiell einzelne Bausteine eines Solutionstacks zu substituieren,
- Technologien zu emulieren,
- auf beliebige Plattformen zu migrieren (RPG, COBOL, C++, VBA und C auf Java ist kein Thema für uns – der umgekehrte Weg genauso wenig. So haben wir unseren IBAN-Konverter z.B. in PL/1, COBOL, C, C++ und Java ausgeliefert, obwohl er in CAL entwickelt worden ist.),
- einen vollkommen neuen Architekturansatz aus einem betagten Ansatz abzuleiten
- und dabei Wartbarkeit sicherzustellen.
Die harten Zahlen
Mit Hilfe dieser Crossplattform-Technologie konnten wir für unsere Kunden teure Technologien durch flexiblere und kosteneffizientere Lösungen ersetzen. Einige einfache Beispiele für Substitutionsprojekte und deren zukünftig verbesserte TCO-Position sind:
- BS2000 auf Linux: Einsparung von 0,7 Mio. Euro/Jahr
- Oracle BPEL auf Activiti: Einsparung von 2,7 Mio. Euro/Jahr
- IMS auf CICS: Einsparung von 1 Mio. Euro/Jahr
Keines dieser Projekte hat länger als ein halbes Jahr gedauert. Der ROI konnte nach einem halben Jahr erreicht werden. Danach standen jährlich frische Mittel für weitere Schritte zur Realisierung einer konvergenten Systemlandschaft zur Verfügung. Wie gesagt: Auf die richtige Methodik kommt es an!
Bildquelle: Shutterstock
