Bis in die neunziger Jahre musste ein Karten-Managementsystem zwingend eine Mainframe-basierte Anwendung sein. Wegen den notwendigen Performance-Anforderungen1) kam nur die Mainframe-Architektur in Betracht, um den notwendigen Datendurchsatz im Batch und im Onlinebetrieb zu gewährleisten. Entsprechende Standardsysteme zur Kreditkartenverarbeitung wurden meist nur auf Mainframe-Architekturen angeboten. Nicht Mainframe-basierte Anwendungen konnten von den IT-Branchenexperten im Karten Processing zwar wahrgenommen werden aber zu keiner Zeit als wirkliche Alternative zu den Mainframe Anwendungen angesehen werden.
Die Mainframe-basierten und hoch integrierten Kartensysteme wurden entlang dem Softwarelebenszyklus, basierend auf fachlichen Anforderungen ständig weiter entwickelt und zeichnen sich heute durch einen sehr hohen funktionalen Abdeckungsgrad aus.
Legacy-Systeme mit hohem Wartungsaufwand
Alle über einen solchen langen Zeitraum lauffähig gehaltenen und fortwährend angepassten, historisch gewachsenen Systeme tragen naturgemäß einen erheblichen Teil an Altlasten in sich und werden in der Fachwelt als Legacy-Systeme bezeichnet. Diese Systeme zeichnen sich zwar durch eine hohe Funktionalität und meist auch individuelle Abdeckung des Geschäftes aus, sind aber oftmals nur mit unverhältnismäßig hohem Aufwand auf neue Anforderungen hin anpassbar und haben in der Regel hohen Wartungsaufwand. Dieser wird vom Top-Management oft nicht verstanden und akzeptiert. Auch wollen die Vertriebs- und Kundenbetreuungsabteilungen nicht lange auf die Umsetzung von neuen Anforderungen warten, denn der Kunde will die geforderten Funktionen immer zeitnah implementiert und als Alleinstellungsmerkmal für sich nutzbar haben. Eine hohe Geschwindigkeit bei der Anpassung ist gefragt, dies ist eine Konsequenz aus unserer Globalisierung und der schneller werdenden Welt. Gleichzeitig werden die Anforderungen an das IT-System anspruchsvoller, weil die vom System zu unterstützenden Prozesse komplexer werden. Weiterhin hat die IT selbst die Aufgabe, die Qualität und die Wirtschaftlichkeit der IT laufend zu verbessern. Eine unverhältnismäßig lange Entwicklungszeit von Anforderungen und hohe Ausgaben für die Wartung wir ken sich negativ auf die Wirtschaftlichkeit aus.
Funktionale Teilbereiche
Doch wie ist das sinnvolle Vorgehen um sich aus den Altlasten heraus zu bewegen und Neues und Flexibleres zu schaffen und die Wirtschaftlichkeit der IT-Landschaft zu erhöhen? Das komplexe und hoch integrative Modell eines Karten-Managementsystems muss in funktionale Teilbereiche zerlegt werden, man kann auch wie folgt sagen.
Das monolithische Konstrukt ist abzulösen und durch einen Komponenten orientierten Ansatz zu ersetzen. Der Hebel zur Erreichung einer besseren Wartbarkeit und zur Realisierung von schnelleren Entwicklungszyklen ist die Komponentenbildung. Die Anpassung einer Funktion ist schneller vollzogen, wenn diese in einer isolier ten Komponente liegt. Wiederkehrende Änderungen (zum Beispiel Compliance) sollten immer in Komponenten abgekapselt werden, um die wiederkehrenden Änderungen losgelöst von anderen Änderungen durchführen zu können. Durch losgelöste Komponenten ergeben sich bessere Handlungsmöglichkeiten für Performance- Maßnahmen, als ständig auf sequentielle Verarbeitung zu warten.
Welche Komponenten es letztendlich sein werden, hängt stark von der Business Strategie ab, also wieder von den Komponenten, die ein Issuer, Acquirer oder Prozessor seinen Kunden als Dienstleistung anbietet, es gibt hier nicht die Universallösung.
Komponentenbildung
Die zum Kartenprocessing notwendigen IT Komponenten basieren in der Regel auf folgenden übergeordneten geschäftlichen Prozessen und unterstützen diese entsprechend: Authorisation, Clearing & Settlement, Cardholder/Merchant Accounting, Letterwriting, Interfaces/Compliants Card Schemes, Plastics and PIN, Terminal Management, Chargeback & Disputes, Document-, Fraud- und Risk Management, Collections sowie Reporting and Data Analysing.
Die Liste der Komponenten kann beliebig verfeinert werden und muss individuell aufgestellt werden, genauso wie deren fachliche und technische Implementierung angepasst auf das Unternehmen erfolgen muss. Fest steht aber, man kommt heute nicht mehr um diese Komponentenbildung herum, will man die Basis schaffen, um schnell und flexibel notwendige Änderungen umzusetzen. Die Liste der Komponenten darf nicht zu fein werden, sonst ergibt sich eine unbeherrschbare Anzahl von Elementen. Eine Komponente darf höchstens so groß sein, dass diese von einem oder einer kleinen Gruppe von Programmierern beherrscht werden kann. Es ist darauf zu achten, dass eine Komponente sich nicht zu einem Monolith entwickelt.
Auch sind organisatorische Anforderungen innerhalb des Unternehmens zu berücksichtigen, damit nicht nach der nächsten Reorganisation in einem Unternehmen die IT-Architektur umgestaltet werden muss.2) Weiterhin können fachliche Unterschiede oder auch funktionale Gemeinsamkeiten die Komposition beeinflussen. PCI-Anforderungen und Security-Sachverhalte sind ebenfalls eine wichtige Grundlage für die Bildung von Komponenten.
Der Sponsor oder verantwortliche Nutzer für die Komponente muss eindeutig identifizierbar sein und deckt sich idealerweise mit dem Prozessverantwortlichen. Dies sind üblicherweise Team-/Abteilungsleiter, in deren fachliche Verantwortung eine Komponente fällt. Natürlich trägt die IT die übergeordnete Verantwortung für alle Komponenten und für die Schnittstellen zwischen den Komponenten.
Eine Komponente kann ein eigenes Produkt sein, als Service von einem Drittanbieter bereit gestellt werden, im eigenen Rechenzentrum laufen, im Rechenzentrum eines Anbieters gehosted sein oder in Lizenz selbst betrieben werden. Alle möglichen Kombinationen sind hierbei denkbar.
Schnittstellen vertraglich festlegen
Die Komponenten müssen durch Schnittstellen verbunden sein. Diese sind ganz wesentliche technische Objekte innerhalb der Komposition. Sie haben für den Sender und den Empfänger verbindlichen Charakter und werden in einer eigenen Spezifikation definiert. Das Design der Schnittstellen ist möglichst exakt3) auszuarbeiten und bilateral inklusive der Datenmengen abzustimmen und vertraglich festzulegen. Änderungen müssen unter einem geordneten Rahmen ablaufen, sonst haben weitere Betroffene der Änderung keine Chance, sich darauf einzustellen. Merkliche Verzögerungen im Projekt oder erhebliche Störungen in der Produktion wären die Auswirkungen.
Bei Datei-basierten Schnittstellen ist es vom praktischen Architekturansatz erforderlich, diese über eine zentrale Anwendung zu transportieren, deren Aufgabe es ist, vom jeweiligen Sender die Schnittstellendateien entgegenzunehmen und an den Empfänger bereitzustellen. Dieser zentrale Service ist eine eigenständige Komponente mit zentraler Bedeutung für das komplette IT-System.
Bei online-basierten Schnittstellen ist es zu empfehlen, dass jegliche Kommunikation mit dem gleichen Kommunikationsprotokoll durchgeführt wird. Unterschiedliche Protokolle treiben den Aufwand hoch, weil zusätzlich Skills benötigt werden und zusätzliche Lizenzausgaben für Hardware oder Software anfallen können.
Exogene Faktoren entscheidend
Wenn eine Komposition leicht verständlich klingt, auf einen Blick begreifbar und eingängig ist, dann ist es eine gute Komposition. Dahin ist es ein weiter und schwieriger Weg. Es kommen oftmals Interessen in das Design, die ihren Ursprung in der persönlichen Präferenz von Managern haben können. Der IT-Architekt bewegt sich also im Spannungsfeld zwischen Software- und Plattformarchitektur4) und steuert die Anwendungsarchitektur, den Dreh- und Angelpunkt zwischen IT-Betrieb, IT-Entwicklung und dem Business.
Die Arbeiten der IT-Architektur müssen integrativ mit dem Business erfolgen, ansonst ist die Wahrscheinlichkeit zu scheitern enorm hoch. Dem IT-Architekten muss ein Business-Architekt gegenüber stehen, der die Vorgaben aus dem Business für den IT-Architekten formuliert. Der IT-Architekt stimmt diese Anforderungen mit der IT-Entwicklung und dem IT-Betrieb ab, und zwar nur mit den Verantwortlichen der betroffenen Komponenten.
Es ist übrigens selten zu beobachten, dass nur aus Architekturgründen eine Reorganisation von IT-Systemen vom Top-Management genehmigt wird. Die Reorganisation der IT-Landschaft erfolgt meist in Verbindung mit anderen aus IT-Sicht exogenen Faktoren, wie zum Beispiel einem geschäftspolitisch motivierten Wechsel des Serviceproviders oder Neugewinn eines großen Kunden, dessen Anforderungen nur durch neue Komposition und IT-Systemreorganisation erfüllt werden können.
Fertiggerichte gibt es hier nicht, eher die gemeinsam durch das Business und die IT erstellte Lösung. Ein besonderes Augenmerk sollte auf die PCI-Anforderungen gelegt werden. Jede Komponente, die nicht in den PCI-Scope fällt, erspart Zeit und Ressourcen. Deshalb ist es klug, in das Design zur Komponentenbildung die PCI Sachverhalte frühzeitig mit einzubeziehen.
Auf Komponentenbildung basierende Trends
Verfolgt man den Ansatz der Komponentenbildung weiter, so begreift man auch folgende Trends, die allesamt auf dem Ansatz der Komponenten und der Schnittstellen basieren.
1. Service orientierte Architektur (SOA): Im Grunde ist die SOA eine lose Kopplung von Komponenten, die über einen Enter prise Service Bus (ESB) verbunden sind. Man nennt diese Architektur auch Schnittstellenorientierte Architektur. Hier geht es darum, auf fachlicher Ebene als Anbieter (Provider) Informationen bereitzustellen und für einen Nutzer (Consumer) abrufbar zu machen. Dies geschieht nicht über bilaterale Kommunikation, sondern über den ESB. Es ist vielmehr ein Denkmuster als eine in sich geschlossene Architekturvorgabe.
Anwendungen, die Services integrieren, gibt es von SAP Netweaver die SAP-XI Prozessintegration oder in ähnlicher Form von IBM mit dem Produkt Websphere oder von Progress Software den Sonic ESB mit einer Fülle von Adaptern. Aber Vorsicht, man kann nicht durchgängig beliebige Daten über diesen Bus schieben, weil nun einmal bei der Kartenverarbeitung PCIrelevante Sachverhalte als Muss-Abforderungen zu berücksichtigen sind. Oftmals wird bei SOA der Begriff Web Services gebraucht, aber ein Service muss nicht unbedingt auf HTTP, XML oder SOAP basieren, sondern kann durchaus von einer Komponente auch auf dem Mainframe erbracht werden.
2. Governance: Gerade bei verteilten Anwendungen ist es notwendig, Softwareentwicklung und Betrieb laufend zu steuern. Dies ist eine zentrale Aufgabe. Wird sie nicht wahrgenommen, dann besteht die Gefahr der Chaosbildung, was wiederum gerade für die Kartenverarbeitung ein hohes Risiko darstellen würde. Zu nennen sind hier das Vorhandensein und das Leben von Richtlinien und von Prozessen, die in sich nicht-technische Objekte sind, aber zur IT-Architektur dazu gehören, ebenso wie die Einbettung der IT-Architektur in eine Business-Architektur.
Vielfach wird in der Kartenbranche, weil diese ein technisch getriebenes Geschäft ist, gerne und zu schnell bei Problemstellungen auf die IT5) verwiesen, was aber falsch ist. Es ist klar dass in der Kartenverarbeitung die Performance der Geschäftsprozesse in einem hohen Grad von der IT-technischen Unterstützung abhängt, aber der Kern ist und bleibt der Geschäftsprozess als solcher, der von der IT richtig6) unterstützt werden muss.
3. Cloud Computing: Die Auslagerung von Software- und/ oder Hardwarediensten auf räumlich entfernte Dienstleiter ist nicht neu. Vor allem lassen sich hier Skalierungsbedürfnisse befriedigen. Aber Vorsicht, denn bei Kartendaten handelt es sich um hoch empfindliche Informationen, die nicht beliebig auf virtuelle Standorte verteilbar sind. Auch die gemeinsame Nutzung von Services von mehreren Kartenverarbeitern muss sehr genau geprüft werden, allzu leicht kann es zu uner wünschten Querverbindungen7) kommen, die (wenn diese durch einen PCI-Prüfer aufgedeckt werden) sehr unangenehm für die Verantwortlichen sein können.
Als Fazit lässt sich festhalten: Ein entscheidender Produktionsfaktor und auch Erfolgsfaktor in der Kartenverarbeitung ist die Informationstechnik. Neben den IT-Kosten zählt heute vor allem die Geschwindigkeit, mit der neue Funktionen und Produkte zur Verfügung gestellt werden können. Monolithische Architekturen wirken sich hierbei nachteilig aus. Architekturen, die sich aus Komponenten und Schnittstellen zusammensetzen, sind schneller anpassbar und erzeugen weniger Wartungsaufwand. Zur Erreichung einer passenden IT-Architektur gibt es kein fertiges Rezept, sondern sie ist individuell in Abhängigkeit und unter den Vorgaben der Business-Architektur zu gestalten. Diese Gestaltungsaufgabe ist eine Daueraufgabe für die erfolgreiche Kartenverarbeitung.
Anmerkungen
1 Vor allem im Issuing Processing, weil hier die zu verarbeitenden Kontenzahlen schon mal an die Million heranreichen kann oder diese gar übersteigen kann.
2 IT-Anwendungen sind nicht ohne entsprechenden Aufwand auf organisatorische Änderungen hin anpassbar.
3 Möglichst exakt ist gleichzusetzen mit nicht perfekt. Gutes Design ist unerlässlich, Perfektionismus ist nicht bezahlbar.
4 Die Trennung IT-Betrieb (Plattform) und IT-Entwicklung (Software) ist meist durchgängig vorhanden.
5 Vor allem auf die Softwareentwicklung, weil dort die Prozesse in Programmcode umgesetzt werden und das Prozesswissen besonders konzentriert ist.
6 Was im Grunde hinter dem Begriff Governance auch steht.
7 PCI-Fachleute sprechen hier auch von sogenannten "Traversen".