Evolution der Integrationsarchitektur

EAI – Die replizierte Anwendungslandschaft

Strategien zur Datenreplikation sind nichts Neues. Datenbank- und ETL/Warehouse-Hersteller bieten ein breites Spektrum an. Die Technik ist gut verstanden, kostenmäßig überschaubar und bringt einen gewissen Komfort mit sich. Zudem wird dieser Ansatz von den Herstellern hoch stilisiert und stark empfohlen. Sie versprechen „blitzschnelle“ Synchronisation im Gigabit-Netzwerk und absolute Konsistenz. Zudem klingt der Ansatz einfacher, praktikabler und ist besser zu kommunizieren als ein kompliziertes Redesign der IT-Anwendungslandschaft. Ferner würde ein kostenintensives Redesign das Wachstum womöglich gefährden und es müssten u. U. neue Mitarbeiter mit entsprechenden Qualifikationen wie z. B. IT-Architekten oder Integrationsspezialisten eingestellt werden. Replikation hingegen ist trivial, denn eigentlich ändert sich ja gar nichts.

In den meisten Fällen ist das anfangs ja auch so. Es wird nochmals kräftig in Hardware und Lizenzen investiert. Die Performance steigt, die Ausfallsicherheit erhöht sich. Abbildung 2 illustriert das Szenario. Die IT-Anwendungslandschaft wurde um ein paar Datenbanken reicher. Ein so genannter Replicator repliziert die Masterdaten in alle anderen applikationslokalen Datenbanken und vice versa. Nun wird mithilfe des Tools ein Teil der Masterdaten, der für die Auftragsannahme relevant ist, in die neue „Order-Datenbank“ dupliziert. Da Servicecenter und externes Callcenter einen anderen Schwerpunkt setzen, erhalten sie ebenfalls eine eigene lokale Datenbank mit replizierten Daten. Damit sind die wichtigen Portale unabhängig vom Hauptsystem und müssen sich nicht mehr mit den Callcenter-Applikationen einen Datentopf teilen. Wenn das Masterdatensystem jetzt nicht verfügbar ist, sind nicht mehr alle Applikationen gleichzeitig betroffen. Kurzfristig scheint das Ziel der Skalierbarkeit erreicht.

Abb. 2: EAI und Datenreplikation
Doch ist das auch tatsächlich der Fall?

Die Skalierbarkeit sinkt mit der Anzahl der Systeme. Werden replizierte Masterdaten in einer applikationslokalen Datenbank verändert, müssen das Masterdatensystem und alle anderen applikationslokalen Datenbanken aktualisiert werden. Verkomplizierend wirkt dabei, dass sich Applikationen spezifisch und autark weiterentwickeln. Um die Kompatibilität zu erhalten, müssen die Daten hiernach transformiert werden. Je nach Anzahl der Systeme kann die vermeintlich gewonnene Skalierbarkeit schnell einbrechen, vor allem, wenn die IT des Unternehmens global verteilt ist. Befindet sich das externe Callcenter beispielsweise in Indien, müssten die Daten über schmale Ozeanleitungen repliziert werden. Aber auch im eigenen Netz ist es eine Herausforderung, die Synchronität der Daten und damit die Konsistenz zur gewährleisten: Die geänderten Daten müssen in allen applikationslokalen Datenbanken umgehend zur Verfügung stehen.

Im gesamten Unternehmen werden Daten invasiv verteilt. Für die Bearbeitung fast gleicher Daten existieren unzählige Komponentenvarianten (Order H, K, K1, S, S1). Von „fast“ gleichen Daten ist hier die Rede, da der „Kunde“ häufig nicht ein und dieselbe Entität über alle Applikationen hinweg verkörpert. Durch das „ganz wichtige IT-Projekt“ werden die replizierten Datensätze in den applikationslokalen Datenbanken mal eben um ein paar Felder erweitert – wer kennt diese Situation nicht? Das Projektbudget und der gesetzte Zeitrahmen reichen selten aus, um die Änderungen am Masterdatensystem und dann auch in allen peripheren Applikationsdatenbanken vorzunehmen. Zusehends verschwimmt die Kenntnis darüber, welche Applikation die Hoheit über welche Daten hat, und so schwindet auch die Kontrolle über die Daten mehr und mehr. Diese Entwicklung wirkt sich bis in den Fachbereich aus, der für rasche Erweiterungen des Geschäftsmodells eine Art Geschäftssicht benötigt. Das Beispiel des Geschäftsobjekts „Kunde“ kann somit in einem applikationsübergreifendem Geschäftsprozess kaum noch modelliert werden. In der Konsequenz wird die Adaptivität und Reaktivität des Unternehmens zum Markt reduziert und das weitere Wachstum gefährdet.

Das ursprünglich allein existierende Masterdatensystem muss Geschäfts- und Zugrifflogik auf die Daten angewendet haben. Die Verteilung der Daten bringt damit zwangsweise auch die redundante Verteilung dieser Logik mit sich. Auch hier wird diese separat und applikationsspezifisch modifiziert, d. h. Änderungen im Masterdatensystem müssen nun in alle peripheren Applikationen, die die ursprünglich gleiche Geschäfts- und Zugriffslogik spezifisch erweitert haben, migriert und getestet werden. Nicht selten erfordert diese Änderung einen erheblichen „Roundtrip“ durch die IT-Anwendungslandschaft. Testteams haben in solchen Unternehmen eine beachtliche Größe und Sonderstellung. Nicht selten können sie schon in der Entwurfsphase mitbestimmen, was überhaupt testbar ist und somit umgesetzt werden darf. Änderungen werden so kostenintensiv und unplanbar, Agilität und Flexibilität des Unternehmens nehmen immer mehr ab.

Die Komplexität erhöht sich weiter, wenn für Applikationen bereits replizierte Daten erneut repliziert werden. Am Beispiel des externen Callcenters in Abbildung 2 zeigt sich die so genannte zweistufige Replikation. Klar ist, dass auch hier wieder die Geschäfts- und Zugriffslogik mitgeliefert werden, die sich nur diesmal nicht direkt vom Masterdatensystem ableiten. Diese Replikation entwickelt sich nicht selten zu einer zweistufigen Transformation. In diesem Komplexitätsstadium lassen sich IT-Projekte kaum noch umsetzen und testen. Vor dem Hintergrund, dass aus der Geschäftsstrategie bestimmte Geschäftsziele abgeleitet und zu Anforderungen und von IT-Projekten umgesetzt werden, können die langfristigen Folgen für die Wettbewerbsfähigkeit eines Unternehmens drastisch ausfallen. Ursprünglich wurde die Replikationsstrategie gewählt, um Kosten zu sparen. Mittelfristig ist jedoch das Gegenteil der Fall: Es werden zusätzliche Infrastruktur, mehr Plattenplatz, mehr Netzwerk-Traffic und weitere Datenbanken benötigt – und außerdem weitere Mitarbeiter, die das alles administrieren. Sicherlich existieren in einigen Bereichen auch sinnvolle Replikationsszenarien, z. B. im Umfeld der Hochverfügbarkeit, Reporting oder auch bei der später diskutierten Legacy-Entkopplung.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.