IT-Landschaften präsentieren sich zunehmend komplexer. Management, Partner und Kunden fordern heute Internet-basierende Lösungen. Diese haben jedoch zur Folge, dass oft die unterschiedlichsten Systeme miteinander verbunden werden müssen. Die Bestandteile, die es dabei zu integrieren gilt, stammen häufig aus verschiedenen Epochen der IT-Geschichte. Kein Wunder, wenn der Begriff Enterprise Application Integration (EAI) heute in aller Munde ist.
Die Integration verschiedener Generationen von Software zählt heute zu den größten Herausforderungen der IT. Und das Thema bleibt mehr denn je bestehen, denn der Generationenwechsel bei Technologien und Schnittstellen wird immer schneller. Wer in seiner IT-Landschaft jeden neuen Hype mitmachen möchte, wird bald überfordert sein. Kaum jemand ist in der Lage, seine Systeme alle zwei Jahre, alle zehn Monate und schon gar nicht alle zwölf Wochen neu zu gestalten. Abgesehen von den Ressourcen, die man für die Bewältigung solcher Kurzzyklen benötigen würde, sind derartige Investitionen in der Regel auch finanziell nicht durchführbar.
Die entscheidende Frage ist hier, ob eine Neuentwicklung ganzer Systeme einen erkennbaren funktionellen Nutzen für die Anwender bringt oder ob es letztlich darum geht, existierende Prozesse lediglich über neue Technologien verfügbar zu machen. Schließlich sind vor allem die Altsysteme eine Fundgrube für bewährte Business-Prozesse. Sie sind meist in Cobol implementiert und nicht selten so mit ihrer Umgebung "verbacken", dass es zunächst unmöglich erscheint, sie wiederzuverwenden. Gelänge es, die eigentlichen Prozesse aus diesen Cobol-Sourcen herauszufiltern und als eigenständige Komponenten zur Verfügung zu stellen, dann ließen sich diese Komponenten jederzeit auch in neue Architekturen integrieren: Bewährte Prozesse könnten tatsächlich ohne großen Aufwand mit neuen Technologien umgesetzt werden.
Brauchbare Regeln kapselnIm Grunde besteht das Ziel in einer offenen Softwareinfrastruktur: Alle Business-Prozesse sollen als eigenständige, gekapselte Komponenten zur Verfügung stehen. Eine solche "Biz-Komponente" sollte plattformunabhängig sein, wobei sich Plattform nicht nur auf die Hardware, sondern auch auf den eingesetzten Applikations-Server bezieht. Denn in verschiedenen technischen Kontexten können unterschiedliche Infrastrukturen nützlich sein, weshalb eine Biz-Komponente in der Lage sein sollte, in jede dieser Architekturen zu passen.
Um solche Komponenten zu erhalten, benötigt man die reinen Business-Regeln. Diese sind zwar in den Legacy-Systemen enthalten, dort aber leider nicht direkt sichtbar. Es geht darum, in dem riesigen Sammelsurium von Sourcen, das sich heute in den Systemen verbirgt, die wertvollen Bestandteile aufzufinden und sauber aus dem Rest herauszulösen. Dabei sollte dem Anwender klar sein, dass der Anteil brauchbarer Bestandteile letztlich sehr klein im Vergleich zu dem insgesamt vorhandenen Programmcode ist. Der größte Teil der Anwendungen entfällt nämlich fast immer auf den Benutzerdialog, gefolgt von der Datenhaltung und der Steuerung. Nur ein relativ geringer Anteil entfällt auf die eigentlich interessanten Business-Prozesse.
Vorgehensmodell wie im BergbauDie Aufgabe, solche Regeln aus den vorhandenen Systemen zu filtern, war der IT-Welt offenbar wichtig genug, gleich mehrere Fachbegriffe hervorzubringen: Legacy Reengineering, Knowledge Mining oder Business Rule Extraction. Am besten passt der Begriff Application Mining, dessen Analogie zum Bergbau das Vorgehensmodell sehr gut umschreibt. So beginnt die Exploration von Diamantenfeldern mit der Befragung von Geologen über die lokalen Gegebenheiten, um festzustellen, in welchem Teilbereich eine genauere Suche überhaupt Sinn macht. Genauso sollte man es auch beim Application Mining handhaben, und auch hier können Werkzeuge helfen, den richtigen Ansatzpunkt zu finden: Analyse-Tools verschaffen einen Überblick über die Abläufe eines Legacy-Systems, indem sie Abhängigkeiten und Programmfluss grafisch darstellen. Auf dieser Basis kann jemand, der die fachlichen Zusammenhänge kennt, recht schnell bestimmen, wo es sich lohnt, Sourcen näher zu analysieren, um den eigentlich gesuchten Business-Prozess aus dem Sourcen-Gestein herauszuholen.
Auf der Suche nach wertvollen CodeteilenDieser groben Annäherung folgt ein methodisches Vorgehen, um gezielt "Edelsteine" ausfindig zu machen. Für das Auffinden von Business-Prozessen benötigt man Methoden zur Qualifizierung der ausgewählten Sourcen. Auch dafür gibt es Werkzeuge, die in der Lage sind, Cobol-Programme Abschnitt für Abschnitt automatisch zu untersuchen. Wie im Bergbau gibt es, abhängig von den spezifischen Eigenschaften der gesuchten Prozesse, unterschiedliche Vorgehensmodelle. So lassen sich zum Beispiel Bereiche nach der Art der enthaltenen Cobol-Anweisungen bewerten. Mit Hilfe einer Punktewertung beziehungsweise eines Rating-Verfahrens können die Tools so auf Paragraphenebene Schätzungen abgeben: Etwa in der Art, dass ein Code-Abschnitt mit einer Wahrscheinlichkeit von 90 Prozent Business-Logik enthält, weil an dieser Stelle beispielsweise Berechnungen vorgenommen werden; an einer anderen Stelle beträgt diese Wahrscheinlichkeit vielleicht nur 20 Prozent, weil dort eigentlich nur File-I/O erfolgt.
Eine Möglichkeit bietet auch die Suche nach kopiertem Code - mit einem einfachen Hintergedanken: Jeder Programmierer hat höchstens einmal in seinem Leben zum Beispiel einen Sortieralgorithmus geschrieben und diesen jedes Mal, wenn er wieder einen brauchte, kopiert und lediglich die verwendeten Datentypen angepasst. Über ein Fingerabdruck-Verfahren können Analysewerkzeuge solche Stellen finden, die es sich später, als aufrufbare Hilfsroutinen, herauszuziehen lohnt. Hier ist Application Mining sogar schlauer als der Bergbau.
Festzuhalten bleibt, dass das Entdecken von Softwarediamanten beziehungsweise verwertbaren Business-Prozessen kein Ablauf ist, der sich vollständig automatisieren lässt. Dennoch: Die Kombination von Fachwissen, Kenntnis der vorhandenen Systeme und der richtigen Analysewerkzeuge kann den Vorgang doch erheblich beschleunigen.
Sind die interessanten Stellen endlich gefunden, geht es in einem nächsten Schritt darum, sie aus den vorhandenen Sourcen herauszulösen und in einer neuen Quelle zusammenzufassen. Auf den ersten Blick scheint das eine Aufgabe auf der Ebene von "Copy and Paste", aber wie so oft steckt der Teufel im Detail. Das Problem ist nicht, die Anweisungen zu kopieren, sondern zugleich die benötigten Datendefinitionen zusammenzustellen. Das ist dann wieder die Stunde der Automatik - gute Werkzeuge können das selbständig erledigen. Nachdem man die gewünschten Stellen selektiert hat, klassifizieren sie die benötigten Daten in Eingabe- und Ausgabeinformationen sowie temporäre Daten und generieren eine entsprechende Daten- und Parameter-Schnittstelle.
Am Ende erhält man ein für sich unabhängiges Cobol-Unterprogramm, das den ausgesuchten Business-Prozess kapselt. Im Regelfall wird dieses Ergebnis aber noch nicht der fertige Diamant, sondern ein roher Stein mit Beimischungen etwa von Erde sein. Der Rohstoff muss also noch gereinigt, veredelt und geschliffen werden. Das Ziel ist eine echte Biz-Komponente, die man je nach Wunsch mit einer anderen Fassung in verschiedene Architekturen wie COM- oder EJB-Server einsetzen kann.
Integration in KomponentenarchitekturenUm von unterschiedlichen Anwendungen genutzt werden zu können, müssen diese Biz-Komponenten mit entsprechenden Kommunikationseinrichtungen ausgestattet werden. Dabei haben sich in den vergangenen Jahren die drei bekannten Standards Corba, DCOM/ COM+ und EJB herausgebildet. Für solche, teilweise ganz neuen Anforderungen müssen nun die Cobol-Programme mit Komponententechnologie kombiniert werden. Auch bei Cobol ist die Zeit nicht stehen geblieben; ein modernes Entwicklungssystem für Cobol-Anwendungen hat nicht mehr viel gemein mit den kargen Zeileneditoren der 70er Jahre. Das Cobol von heute unterstützt selbstverständlich moderne Softwarekonzepte wie OOP und die Komponententechnologie.
Eine moderne Cobol-Entwicklungsumgebung zur Erstellung verteilter Anwendungen verfügt daher über Assistenten, die auf Basis von Cobol-Programmen verteilte Komponenten nach den verschiedenen Modellen weit gehend automatisch erzeugen. So kann beispielsweise ein "Class Wizard" einen Dialog mit dem Entwickler führen und dabei alle nötigen Informationen abfragen, um die objektorientierten Klassen, Methoden und Daten zu implementieren. Der Wizard generiert aus diesen Informationen automatisch Cobol-Source-Code, der nur noch mit der passenden Logik gefüllt werden muss. Er hilft so dem Entwickler, die gewünschten objektorientierten Vorgaben in die Syntax von OO-Cobol (objektorientiertes Cobol) umzusetzen. Solche Assistenten lassen sich dazu nutzen, Wrapper-Objekte für Biz-Komponenten zu generieren, welche die Kommunikation und Architektur von unseren eigentlichen Business-Regeln kapseln. Beim Anlegen einer neuen Klasse kann man dann bestimmen, ob diese Klasse eine COM-, OLE- oder auch EJB-Komponente abbilden soll. Die dazu nötigen Quellen und Erweiterungen generiert der Assistent.
Kapselung eines Legacy-WorkflowsOft wollen Unternehmen die vorhandenen Anwendungen nicht verändern, sie aber trotzdem in Komponentenumgebungen nutzen. Auch dafür gibt es neuerdings Werkzeuge, die es beispielsweise ermöglichen, CICS-Transaktionen über ein EJB-Interface zu kontrollieren. Die Idee dahinter ist, einen ganzen Workflow, der sich aus verketteten Einzeltransaktionen zusammensetzt, als aufrufbare Komponente zu kapseln.
Angenommen, der Kunde eines Unternehmens, für den spezielle Konditionen gelten, will seine Bestellungen über das Internet absetzen. Im Rahmen einer CRM-Lösung soll er sich über das Internet anmelden und anhand seiner ganz persönlichen Konditionen seinen Auftrag erfassen können. Bisher ruft er im Call-Center an, wo die Datenerfassung direkt in ein CICS-System erfolgt. Die Struktur des Ablaufs bleibt dieselbe: Zunächst muss der Kunde im System identifiziert werden, um die Konditionen zu ermitteln. Dann können die Auftragspositionen erfasst werden, wobei die Preise direkt mit den hinterlegten Rabatten und Konditionen verrechnet werden. Nachdem der Kunde am Telefon sein Okay gegeben hat, wird der Auftrag freigegeben, und es folgt per Fax eine Auftragsbestätigung. Der Workflow für personifizierte Auftragserfassung existiert also im vorhandenen Legacy-System, allerdings nicht als in sich abgeschlossene Komponente, sondern als interaktive Abfolge von Einzeltransaktionen. Ziel ist es nun, diesen Workflow nicht mehr von einem Anwender kontrollieren zu lassen, sondern von einer Internet-Anwendung. Dabei soll der gesamte Ablauf automatisiert werden; lediglich wenige Schritte, wie die Auswahl der Artikel, soll auch weiterhin der Anwender steuern.
Für diese Aufgabe muss zunächst ein Steuerprogramm implementiert werden, das die unveränderten Transaktionen von außen lenkt. Das ließe sich beispielsweise durch Abgreifen des Terminal-Datenstroms erreichen, aber bei CICS bietet sich dafür die 3270-Bridge an. Denn so werden die Daten nicht mehr wie bisher nach jeder einzelnen Transaktion über das Netzwerk geschickt, sondern können bereits auf dem Host zu automatisierten Einheiten zusammengefasst und über normale Daten-Schnittstellen kontrolliert werden. Das Steuerprogramm bildet also den Workflow ab: Es "weiß", welche Einzelschritte in welcher Reihenfolge mit welchen Daten kombiniert werden müssen. Moderne Werkzeuge erfassen diese Informationen automatisch, indem sie den Workflow eines Legacy-Anwenders protokollieren und negative Abzweige wie Fehlerbehandlungen durch Analyse der Sourcen ermitteln. Das so generierte Steuermodul kann nun als Hostservice über eine Middleware wie IBMs MQ Series aufgerufen werden. Es fehlt nur noch ein Wrapper-Objekt, das die Schnittstelle über ein Komponenten-Interface zur Verfügung stellt. Auf diese Weise können Komponentengeneratoren fertige EJB-Interfaces generieren, um den Workflow in Web-Server-Anwendungen zu integrieren.
Frage nach dem Wert von AltsystemenBleibt die grundlegende Frage, wozu der ganze Aufwand notwendig ist. Die Antwort hängt davon ab, wie viel einem Unternehmen seine Legacy-Systeme und damit die darin enthaltenen Business-Prozesse sowie Workflows wert sind. Dieser Wert steigt im Regelfall mit Alter und Mächtigkeit der Systeme. Denn je älter und mächtiger sie sind, desto seltener existieren überhaupt noch Informationen über die zahlreichen Sonderregeln und Details, die darin verarbeitet sind. Mit Modellen wie dem Asset Mining muss man nämlich keinerlei logische Änderung am Ablauf der Business-Prozesse oder der Workflows vornehmen und kann somit die gleiche Funktionalität und Stabilität wie im "Alt-System" sicherstellen. Es ist sogar möglich, die Legacy-Systeme parallel zu neuen Internet-basierenden Architekturen zu nutzen, ohne deswegen einen doppelten Aufwand in der Wartung zu generieren.
Aber ändern sich im E-Business nicht die Prozesse? Tatsächlich hat sich gezeigt - mittlerweile gibt es sogar für Web-Computing Erfahrungswerte -, dass in den meisten Fällen sich nicht die Prozesse selbst, sondern nur einzelne Parameter ändern oder neue Reihenfolgen in der Abarbeitung entstehen. Mit der Einführung von Biz-Komponenten oder -Workflows lassen sich diese Parameter steuerbar machen und die Reihenfolgen komplexerer Abläufe jederzeit neu zusammenstecken.
Wichtig ist dabei, aus den Fehlern der Vergangenheit zu lernen und nicht wieder Geschäftsprozesse fest an bestimmte Plattformen oder Applikations-Server zu binden. So empfiehlt es sich, neu entstandene Biz-Komponenten mit Steuerprogrammen in CICS oder IMS-Systeme einzuhängen oder eben mit Wrappern in Architekturen wie COM+ /DCOM oder in J2EE auf Basis von EJB einzubinden.
*Nicole Holthöfer ist Solution Architect bei der Merant GmbH in Dortmund.
Abb.1: Integration in Steuerprogramme
Generierung einer EJB-Komponente für die Kontrolle von CICS-Transaktionen. Quelle: Merant
Abb.2: Vorgehensmodell
Mit Asset Mining wird Businesslogik aus vorhandenen Systemen extrahiert, um sie dann in Komponentenarchitekturen einzubinden. Quelle: Merant