Simulieren statt reparieren

Die gewichtige Rolle von SAP-Systemen im Testing-Markt ist darin begründet, dass diese das transaktionale Herz vieler Unternehmen in Deutschland und weltweit darstellen.

Ein intensives und rechtzeitiges Testing neuer Systeme oder Eigenentwicklungen ist deshalb lebenserhaltend für SAP-Anwenderunternehmen. Je früher man die IT im Entwicklungsprozess auf produktionsähnlichen Systemen testen und validieren kann, desto weniger kritische und dadurch aufwändig zu behebende Fehler treten bei den großen Integrationstests kurz vor dem Go-Live oder danach auf.

Durch die neue Version Lisa 7.0 von CA Technologies kann frühes Testen in komplexen SAP-Umgebungen schnell und effizient realisiert werden, weil nicht nur die auf offenen Standards beruhende Kommunikation über Enterprise-Bus-Systeme analysiert wird, sondern erstmals auch die direkte SAP-proprietäre Kommunikation über RFCs.

SAP-Anwenderunternehmen wird dadurch in der Entwicklung zu einem viel früheren Zeitpunkt ein intensives Testing unter Berücksichtigung von Systemabhängigkeiten ermöglicht.

Ausgangssituation

Etwa zehn Prozent der mehr als 100.000 SAP-Kunden kommen aus dem deutschsprachigen Raum (DACH). Aus dem Heimatmarkt der SAP kommen die ältesten SAP-Kunden mit einer hohen Dichte an sehr komplexen Systemlandschaften auf häufig unterschiedlichen Release-Ständen.

Gerade weil im deutschsprachigen Raum sehr komplexe SAP-Landschaften mit multiinterdependenten Abhängigkeiten zwischen SAP-, aber auch Nicht-SAP-Systemen aufgebaut wurden, tun sich Unternehmen mit der Einführung neuer SAP–Technologie schwer, wie der mühsame Upgrade-Prozess auf ERP 6.0 zeigt. Und noch immer betreiben viele Unternehmen hierzulande R/3-Systeme. Systemlandschaften mit mehr als zehn unterschiedlichen produktiven SAP-Systemen sind auch im gehobenen Mittelstand keine Seltenheit und bei international ausgerichteten Unternehmen sogar eher die Regel.

Einen großen Anteil an der Systemkomplexität hat das in der DACH-Region traditionell weitverbreitete SAP-Customizing beziehungsweise das Custom Development rund um die SAP-Systemlandschaft. Jährlich geben SAP-Kunden nach Berechnung von PAC mehr als 650 Millionen Euro für Custom Development in der DACH-Region aus.

Aufgrund der Bedeutung von SAP-Systemen ist das intensive Testen neuer Funktionen und Applikationen teilweise überlebenswichtig für SAP-Kunden, wie zwei beispielhafte Interviews zeigen, die PAC im Rahmen einer Studie zum SAP-Testing-Markt durchgeführt hat:

• Der australische Bundesstaat Queensland hat ein neues System auf Basis von SAP und Workbrain implementiert. Aus den ursprünglich auf umgerechnet 4,2 Millionen Euro veranschlagten Kosten wurden letztendlich umgerechnet 836 Millionen Euro.Aus einem Bericht des eingesetzten Untersuchungsausschusses geht hervor, dass das System ohne angemessene Tests live gegangen war. Der Bericht erklärte das Projekt zu einer der größten IT-Projektpleiten in der Landesgeschichte.
• Das ehrgeizige Projekt des US-Bundesstaats Kalifornien, die Gehaltsabrechnung öffentlicher Einrichtungen auf einer SAP-Plattform zu vereinheitlichen, scheiterte 2013, nachdem die kalifornische Gesetzesbehörde ein „signifikantes Ausmaß besorgniserregender Fehler“ identifiziert hatte. Durch Projektmisserfolg entstandene Kosten: 274 Millionen Euro.

Unternehmen sind deshalb bestrebt, die Qualität bei Entwicklungsprojekten zu erhöhen. Gleichzeitig muss die Geschwindigkeit, mit der neue Applikationen in Produktion gehen können, zukünftig deutlich gesteigert werden, was zunächst im Widerspruch zu einer Qualitätserhöhung steht.

Im Zeitalter der digitalen Transformation ist die Geschwindigkeit, mit der IT-Systeme angepasst werden können, entscheidend für die Wettbewerbsfähigkeit von Unternehmen. Wie wichtig die Geschwindigkeit bei der Anpassung heutzutage ist, zeigt die Tatsache, dass von den Fortune-500-Unternehmen aus dem Jahr 2000 innerhalb von nur dreizehn Jahren weniger als die Hälfte heute noch existieren.

Einstige Marktführer wie BlackBerry und Nokia können sich nicht schnell genug an sich ändernde Marktgegebenheiten anpassen und geraten in arge wirtschaftliche Bedrängnis.

Die Komplexität der vorhandenen Systemlandschaften macht das Testing aufwändig, langwierig, schwierig und schließlich teuer. In diesen Systemlandschaften arbeiten häufig mehrere interne oder externe Service- und Entwicklungsteams gleichzeitig an verteilten Standorten und Systemen, die im Entwicklungsprozess koordiniert werden müssen.

Die Verfügbarkeit von Testsystemen und -daten wird durch unterschiedliche Zeitpläne, Sicherheitsbeschränkungen und Ressourcenkonflikte zwischen verschiedenen Teams eingeschränkt, wenn nicht jedes Team ein eigenes Abbild der produktiven SAP-Systemlandschaft bekommt. Dies scheitert allerdings in der Regel an den Kosten, die für Testlizenzen und gesonderte Hardware notwendig sind.

Aufgrund dieser Beschränkungen finden aufwändige Tests häufig erst kurz vor dem Produktivstart statt, wenn überhaupt.

Für Funktionstests schreiben sich Entwickler Testumgebungen meist selbst, um zumindest grob neue Funktionalität testen zu können. Häufig ist dies ausreichend, aber limitiert, wenn Abhängigkeiten von anderen Komponenten oder – noch aufwändiger – von schon bestehenden Systemen nicht berücksichtigt werden.

Bei Schnittstellentests werden hierfür oft Mock-Objekte verwendet, um die Zusammenarbeit von unabhängigen Komponenten zu simulieren. Je früher und besser auf Komponententestebene Schnittstellen-, Datenkonsistenz-, Stress-, Last-, Performance- und Rechnernetz-Tests durchgeführt werden können, desto geringer ist der Aufwand bei den Integrationstests. Desto früher werden schwerwiegende Fehler erkannt und desto geringer ist der Aufwand für die Behebung dieser Fehler. Hier setzen spezielle Softwarelösungen an.

Service-Virtualisierung

Bei der Service-Virtualisierung werden Systeme und ihr Verhalten simuliert, was die Entwickler in die Lage versetzt, zu einem viel früheren Zeitpunkt intensiver zu testen. Welche Idee steckt dahinter? Wenn ich keinen Zugriff auf das Live-System habe, dann baue ich mir ein Modell des Systems und simuliere sein Verhalten.

Im Prinzip funktioniert dies wie mit komplexen Klimamodellen, mit denen sich zumindest in der Dreitages-Kurzfrist ziemlich genau das Wetter vorhersagen lässt. So kann über statistische Modelle das Systemverhalten von IT-Systemen geschätzt und dann simuliert werden. Hierzu notwendig sind Datenpunkte, aus denen ein Modell der Realität geschätzt werden kann.

Hier wird bewusst der Begriff „geschätzt“ gewählt, weil ein Modell nie exakt das natürliche Systemverhalten abbilden kann. Aber die heutigen Näherungen sind beachtlich und führen zu signifikanten Verbesserungen beim Testing. Eine Studie von Voke zeigt die Verbesserungen auf, die sich durch den Einsatz von Service-Virtualisierung ergeben können:

• Kürzere Wartezeit auf Ressourcen: Die meisten Benutzer warten nur noch halb so lang oder gar nicht mehr.
• Die Teilnehmer meldeten bedeutende, messbare Vorteile:
• um 23 Prozent verkürzte Softwarezyklen
• um 58 Prozent verkürzte Testzyklen
• um 24 Prozent kürzere Time-to-Market
  
• um 45 Prozent erhöhte Testabdeckung
  
• um 22 Prozent weniger Produktionsfehler

Je besser die Messungen, die der Modellbildung zugrunde liegen, desto besser das Modell. Anbieter solcher Testsoftware-Suiten sind CA Technologies, HP, IBM, Panaya und weitere kleinere Player.

Gemeinsam ist den unterschiedlichen Suiten, dass sie über eine automatisierte Modellbildung verfügen, bei der die Software das Systemverhalten quasi lernt, indem die Kommunikationsprotokolle, die zwischen den Systemen im Produktivbetrieb ausgetauscht werden, mitgelesen und aufgenommen werden.

Aus den Aufnahmen der Kommunikationsprotokolle der Systeme wie XML, SOAP lassen sich quantitative Größen wie Antwortzeiten herauslesen. Diese lassen sich für die Simulation von Antwortzeiten beispielsweise bei Performancetests verwenden.

Aus den übertragenen Daten in den Protokollen lassen sich Datenmodelle abstrahieren. So lassen sich durch die Analyse der Antworten eines Umsystems bestimmte Muster finden und im resultierenden Modell dynamisiert werden, beispielsweise Werte, die in Anfrage und Antwort identisch waren, oder Datumswerte, die immer eine gewisse Zeit in der Zukunft oder Vergangenheit liegen (Lieferdatum, Wertstellung). Dies funktioniert vor allem dann gut, wenn es sich um offene standardisierte Protokolle wie SOAP handelt, die über ein Bussystem übertragen werden.

Bei stark integrierten oder älteren SAP-Systemen hat diese Art der Modellbildung jedoch seine Grenzen. In diesen Fällen kommunizieren die SAP-Systeme über Remote Function Calls (RFCs). Diese SAP-spezifische Protokollart zeichnet sich dadurch aus, dass die Kommunikation sehr effizient, aber durch ihre Vielschichtigkeit auch sehr komplex ist.

Die Komplexität der RFCs führt dazu, dass sie für Testmodellumgebungen nur schwer zugänglich sind. Auf der anderen Seite hat in Deutschland noch rund ein Viertel der SAP-Kunden R/3-Altsysteme, die häufig parallel zu modernen SAP-ERP-Systemen gefahren werden und deren Funktionalität benötigt wird.

Gerade in Deutschland werden deshalb noch sehr häufig RFC-Protokolle genutzt. Vorteil für die SAP-Kunden ist, dass sie ihre meist aufwändig angepassten Altsysteme länger produktiv halten können.

Ausblick

Durch die Integration von RFCs in die Test-Suite Lisa hat sich CA in den von Altsystemen und Eigenentwicklungen geprägten Heimatmärkten der SAP einen Wettbewerbsvorteil gegenüber den Platzhirschen HP und IBM verschafft. Das Mitschneiden der RFC-Protokolle stellt einen wesentlichen Schritt für die Weiterentwicklung der Test-Suiten im SAP-Umfeld dar.

Weitere Schritte müssen allerdings folgen, die vor allem darauf abzielen, IT-Abteilungen ein höheres Maß an Agilität zu verschaffen. Bisher sind beispielsweise die Entwicklungs- und Betriebseinheiten in der IT noch stark voneinander getrennt, was meist lange Release-Zyklen zur Folge hat.

Im Zuge des DevOps-Trends wird diese Entwicklung revidiert, und die Zusammenarbeit zwischen Entwicklung und Betrieb soll intensiviert werden, um die Time-to-Market von Applikationen und Releases weiter zu verkürzen.

Dies bedingt zukünftig ein Zusammenwachsen von Entwicklungs- und Betriebsapplikationen, beispielsweise die Integration von Service-Virtualisierung in die Softwarewelt des Automatic Releasing.

Diese Entwicklung werden in den nächsten Jahren die Hersteller von Testing- und Betriebssoftware gehen müssen, um ihre Kunden optimal bedienen zu können.