IT OKUS 6 (2003) Case Consult. Seite 37 bis 40. Herausforderung für Multitalente. The Evolution En@bling Experts. Testverfahren in EAI-Projekten

Transkript

1 IT OKUS 6 (2003) Seite 37 bis 40 Testverfahren in EAI-Projekten Herausforderung für Multitalente Die Welt spricht von E-Business, Workflow, genormten Kommunikationsvorgängen und geschäftsprozessorientierten IT-Diensten. Doch innerhalb der Unternehmen hat die Weiterentwicklung der Informationstechnologie und der Softwaresysteme über die Jahre hinweg deutliche Spuren hinterlassen. Unternehmen verfügen heute über eine große Zahl von Anwendungen bestehend aus Standardsoftware und Individualsoftware, die auf spezielle technische und unternehmensspezifische Belange abgestimmt sind. In den IT-Abteilungen herrschen heterogene Systemumgebungen vor. In dieser Landschaft existieren klassische Hostanwendungen in COBOL, PL/I oder auch Assembler neben 4GL-Anwendungen, Client-Server-Systemen, Websystemen und ERP-Lösungen. Die Daten sind in unterschiedlichen Datenbanksystemen gespeichert und es existiert eine ülle von Schnittstellen zwischen den Anwendungen, so dass das Abschalten oder Austauschen einer Anwendung oder von Teilsystemen mit unerwartet weitreichenden olgen für das Unternehmen verbunden sein kann. EAI = Austausch von Geschäftsprozessdaten Genau hier setzt Enterprise Application Integration (EAI) als "eine Integration von Anwendungen über unterschiedliche technische und logische Infrastrukturen hinweg" an, mit dem Ziel, "dass Geschäftsprozessdaten in ormat und Zusammenhang jederzeit ausgetauscht werden können, ohne dass dabei die Bedeutung der Daten verändert wird". Das "Schnittstellen-Spagetti" soll also methodisch beseitigt werden. Die durch EAI geweckten Erwartungen sind entsprechend groß: die Mauern zwischen betriebsinternen Anwendungen sollen abgerissen und die IT- Anwendungen eines Unternehmens in die Lage versetzt werden, miteinander zu kommunizieren und auf gemeinsame Daten zuzugreifen. Es soll eine Software- Seite 1

2 Architektur entstehen, die für mehr lexibilität und eine bessere Wartbarkeit verbunden mit geringeren Kosten und höherer Transparenz sorgt. Denn auch wenn der Markt für Standardprodukte ständig wächst, Bild 1: Typische IT-Strukturen heute: "Spagetti"-Architektur. sprechen vor allem wirtschaftliche Gründe dafür, dass viele der bestehenden alten zumeist prozeduralen Anwendungssystemen auch in den kommenden Jahren weiterhin eingesetzt werden und "lediglich" mit den in neuen Programmiersprachen entwickelten Teilsystemen zu verbinden sind. Die zukünftigen Anwendungssysteme werden aus heutiger Sicht mit großer Wahrscheinlichkeit sehr komplexe Hybridsysteme sein. Diese Gesamtlösung wird performanz- und kostenoptimiert sein und in unterschiedlichen Programmiersprachen implementierte Teillösungen enthalten, die wiederum sowohl als Individual- als auch aus Standardsoftware bestehen und verschiedenste Rechnersysteme umfassen werden. Integration erfordert Methoden und Konzepte Der Weg dahin ist allerdings nicht neu, sondern schließt von der Idee her an die Tradition früherer Integrationskonzepte aus den 60er Jahren an. Mit Sicherheit aber ist dieser Weg nicht einfacher geworden und auch mit gewissen Risiken verbunden. Betrachtet man beispielsweise ein Untersystem zur Zinsberechnung innerhalb eines Kreditvergabesystems, wird es in den meisten ällen aufgrund wechselseitiger Abhängigkeiten mit anderen Systemen nicht ohne weiteres möglich sein, dieses System in web-basierte Lösungen oder auch bereits vorhandene Standardlösungen zu integrieren. Der Grund ist ebenso trivial Bild 2: EAI und Paradigmenwechsel = EAI-Typen. wie für viele EAI- Seite 2

3 Projekte folgenschwer: die Integration von monolitischen Legacy-Anwendungen in moderne komponentenbasierte Systeme erfordert Methoden und Konzepte, die über die ähigkeiten und Möglichkeiten typischer EAI-Werkzeuge hinausgehen. Gleichzeitig wird aufgrund der zunehmenden praktischen Erfahrungen immer deutlicher, dass es zwar für alle Entwicklungsphasen Techniken und Standards gibt, die einzelne Aufgaben der Integration von Informationssystemen unterstützen, dennoch ist eine allgemein akzeptierte Methode zur Informationssystemintegration derzeit leider nicht verfügbar. Im Rahmen von EAI-Projekten können bestehende Systeme entweder reimplementiert, konvertiert, direkt integriert, ersetzt, oder um Standardlösungen ergänzt werden. Dabei müssen die genannten Integrationsvorhaben methodisch sinnvoll gestaltet und technisch zielgerichtet unterstützt werden. Zum Teil ist dies bereits mit klassischen Verfahren zur Softwareentwicklung möglich, zum Teil müssen zu diesem Zweck aber auch bereits etablierte und anerkannte Verfahren entsprechend erweitert und modifiziert werden. Tests spielen dabei bei jedem einzelnen Schritt eines EAI-Projekts eine besondere Bedeutung und verlangen nach Multitalenten sowohl auf der Personal- wie auch auf der Werkzeugseite. Bild 3: Trends und Auswirkungen in der IT. Enterprise Application Integration beginnt mit einer Bestandsaufnahme Enterprise Application Integration beginnt in jedem all mit einer Bestandsaufnahme und Analyse aller vorhandenen Systeme. Dabei sind zunächst sämtliche Anwendungssysteme in Bezug auf fachliche unktionen, Software-Architektur und die zugrundeliegenden Datenstrukturen zu erfassen. Im Hinblick auf eine verlässliche Zeit- und Kostenplanung sollten anschließend spezielle Analysewerkzeuge eingesetzt werden, die über verschiedene Plattformen und Sprachen hinweg mit Hilfe von Metriken vergleichbare Zahlen und Aussagen zu Qualität, Quantität, und Komplexität der Anwendungen liefern. Die wichtigsten Kenngrößen sind dabei klassische Größenmaße sowie Maße zur Erfassung und Beschreibung der Schnittstellen und Daten. Diese Softwaremetriken unterstützen die Planung und liefern wichtige Zahlen zur Kostenabschätzung. Seite 3

4 Bild 4: Die Projekt-Lebenszyklen. Systeme unter Berücksichtigung des Datenflusses abzuleiten. Im nächsten Schritt werden die zu integrierenden Systeme dokumentiert bzw. in einem gemeinsamen Repository abgebildet. Die Beziehungen zwischen den Programmen, den Schnittstellen und den Daten steht hierbei im Vordergrund. Ziel ist es, die Architektur der vorhandenen Anschließend können die benötigten Schnittstellen implementiert werden. Bei bestehenden Systemen kann dies je nach Zustand und Komplexität der Systeme über Standardprodukte, Kapselungskonzepte oder einem systematischen Reengineeringansatz erfolgen. Die notwendigen Arbeiten werden dabei durch spezielle EAI- rameworks unterstützt. Nach erfolgter Implementierung der Schnittstellen wird die Workflowsteuerung der Geschäftsprozesse implementiert. In diesem Schritt wird festgelegt, in welcher Reihenfolge und mit welchen Ressourcen die unktionen und Komponenten der Geschäftsobjekte aufgerufen werden. In einem letzten Schritt erfolgt über EAI- Werkzeuge die Integration der einzelnen Komponenten mit übergeordneten Steuerungskomponenten entsprechend der Geschäftslogik, damit alle Komponenten untereinander gemeinsame Daten und Prozessinformationen austauschen können. Bild 5: Integrales Vorgehensmodell. Seite 4

5 Testszenarien entwickeln Bei jeder der beschriebenen Aufgaben ist es erforderlich, Tests durchzuführen. Dabei kann man prinzipiell grob zwischen Komponententest, Interface-Test, Prozesstest und Performanztest unterscheiden. Die zentralen ragen sind dabei immer wieder: "Bleibt die Information beim Weitergeben an andere Systeme korrekt?" und "Wie gut wird diese Weitergabe aus Anwender- und Systemsicht durchgeführt?". Testet man nur unzureichend oder erst nach erfolgter Integration, kann es aufgrund der Heterogenität der Systeme und der verschiedenen notwendigen Prozessschritte vorkommen, dass Daten überschrieben werden können oder integrierte Anwendungen falsche Informationen austauschen. Die ehlerursache ist in diesem Stadium nur sehr schwer zu lokalisieren und die Beseitigung ist entsprechend teuer. Es empfiehlt sich daher ein EAI-Projekt schrittweise zu testen. Dies ist allerdings nicht immer ganz einfach, denn die meisten Systeme sind geschäftskritisch und können zu Testzwecken nicht ohne weiteres offline geschaltet werden. Aufgrund der im Vergleich zu klassischen Softwareentwicklungsprojekten etwas anders gelagerten Paradigmen muss also auch der gesamte Testprozess neu ausgerichtet werden. Statt isolierter Testverfahren sind schon früh im Projektverlauf integral und breit angelegte und damit sich wechselseitig beeinflussende Tests notwendig, die sorgfältig geplant werden müssen. Dabei bieten sich spezielle rameworks zur Automation ganzer Testprozesszyklen an. Erreicht werden kann dies durch eine Workflow- und Prozesssicht, denn in typischen EAI-Projekten müssen Bild 6: Testautomation in EAI-Projekten = klassischer Ansatz! verschiedenste Vorgehensmodelle bedarfsgerecht implementiert werden! unterschiedliche Software auf unterschiedlichen Plattformen gleichartiger Tests unterzogen werden! verschiedenste, oft sehr spezielle Werkzeuge im Testprozess eingesetzt werden! an verschiedenen Orten verschiedene Aufgaben gesteuert und koordiniert werden Seite 5

6 ! Mitarbeiter und Spezialisten bei der Durchführung ihrer Aufgaben effizient unterstützt und von möglichst vielen Routineaufgaben entlastet werden Im Sinne von EAI kann unter diesen Randbedingungen eine Testautomation nur durch ein entsprechendes Architekturkonzept erreicht werden. Dazu bietet sich eine Hub-und-Spoke-Architektur bestehend aus Servern, Agenten und Clients an. Die Server stellen zentrale Steuer- und Kontrollfunktionen zur Verfügung und verwalten die Informationen, die zu den Testverfahren und Testprozessen gehören. Agenten übernehmen auf entfernten Rechnern lokal die Ausführung von notwendigen Schritten, um zu den im Testplan festgelegten Ergebnissen zu gelangen. Die Clients stellen schließlich die Benutzerschnittstelle für die Teilnehmer eines Testprozesses dar und steuern die lokal benötigten Werkzeuge. Die Testlogik des Prozesses wird im Rahmen einer skriptorientierten Process Definition Language (PDL) beschrieben, um einzelne Prozessschritte auf Servern, Agenten und Clients festzulegen. Dieser Ansatz bietet die notwendige lexibilität und Skalierbarkeit, um jeden Schritt eines EAI-Projekts begleiten zu können, bereits vorhandene Werkzeuge lassen sich bedarfsgerecht integrieren und steuern. Ebenso lassen sich in einem einzigen Werkzeug unterschiedliche Testverfahren und Konzepte abbilden. Durch Bild 7: Testautomation in EAI-Projekten mit Hilfe von CC-OPAIRA die Skiptsprache kann somit dem lokalen Komponententest genauso Rechnung getragen werden wie dem Prozess- oder Performanztest. Selbst der Aufbau einer für Tests wichtigen isolierten Testumgebung über verteilte Anwendungen und Plattformen hinweg kann so gelöst werden, ohne dass negative Auswirkungen auf kritische Geschäftsprozesse befürchtet werden müssen. Beim Einsatz dieses Verfahrens in mehreren Projekten hat sich in der Praxis gezeigt, dass Testprozesse wesentlich sicherer und effizienter gestaltet werden können. Allerdings wurde es vor allem bei dezentralen EAI-Projekten erforderlich, weitere Hilfsmittel zur Kommunikation bereitzustellen. Die Tragfähigkeit dieses Ansatzes wurde bisher von allen Beteiligten sehr positiv bewertet, denn verschiedene Entwickler-, Anwender- und Testergruppen können jeweils auf die ihnen vertrauten Werkzeuge beim Testen zurückgreifen. Im Vergleich zu herkömmlichen Testverfahren führte dies zu einem erheblich geringeren Kommunikations und Abstimmungsaufwand und damit zu einem geringeren ehlerrisiko. Vor allem gegen Ende der EAI-Projekte konnte wertvolle Zeit und damit Kosten gespart werden. Dr. Björn Wolle Seite 6