Antwortzeiten, Funktionalität und Robustheit sind gängige Merkmale, mit denen sich unter anderem die Qualität einer Software beschreiben und über die sich messbare Ziele setzen lassen. Hinzu kommen weitere, vom Anwender geforderte Qualitätsmerkmale, die ebenfalls in einem Testkonzept samt dessen Methoden und Testumgebung berücksichtigt werden müssen.

Routinen, die sich auf den ersten Blick auch unter einer Service-orientierten Architektur nicht ändern. Genauer betrachtet zeigt sich aber ein anderes, differenzierteres Bild: Mit SOA entstehen komplexe Systeme, die den Aufwand für Qualitätssicherung steigern und insbesondere die Gesamtsystemanalyse sehr viel aufwändiger gestalten.

Services, wie sie das theoretische Konzept einer SOA vorsieht, sind Lehrbuchkandidaten für die Qualitätssicherung. Das beginnt schon beim Anforderungs-Management: Schnell ist geklärt, was ein Dienst leisten und welche Schnittstellen er haben soll. Auch die Funktionsprüfung ist per Blackbox-Test kein Problem. Das Eingabe- und Ausgabeverhalten ist in der Regel genau spezifiziert, die Testautomation simpel. Aus einer Datenbank etwa werden die benötigten Eingabewerte genutzt und die Ausgabewerte dorthin zurückgeschrieben, um sie dann automatisch auszuwerten. Bei großen Anwendungen hingegen kann die Testautomation vergleichsweise mit viel höherem Aufwand verbunden sein.

Weniger Abhängigkeiten

Ähnliches gilt für das Deployment, die Installation und Konfiguration der Software-Services in einer Produktionsumgebung. Es gestaltet sich sehr viel einfacher als bei großen Applikationen. Dies liegt unter anderem daran, dass die Zahl der Abhängigkeiten zum Beispiel vom Betriebssystem oder der von einem Dienst benötigten Bibliotheken in der Regel deutlich niedriger sind als bei großer monolithischer Software. Man könnte also meinen, dass die Qualitätssicherung es mit kleinen Bausteinen anstelle großer behäbiger Programme einfacher hat. Doch das SOA-Konzept ist nur scheinbar schlank.

Machtzentrale der SOA

Herzstück der komponentenorientierten Architektur ist ein SOA-Bus. Dabei handelt es sich um eine komplexe und massige Software, die eine Fülle von Aufgaben und Funktionen übernimmt und strukturelle Leistungen erbringt. Der SOA-Bus vernetzt die verschiedensten Applikationen, nimmt Daten entgegen, übersetzt diese für neue Zielsysteme und stellt über eine einheitliche Schnittstelle auf einer grafischen Benutzeroberfläche die von den Fachabteilungen benötigten Funktionen zur Verfügung. Sind im Unternehmen noch Legacy-Systeme im Einsatz, müssen diese über Adapter eingebunden werden und fügen der ohnehin schon sehr mächtigen SOA-Infrastruktur eine zusätzliche Übersetzungsschicht hinzu. Der SOA-Bus wird dadurch noch komplexer.

Sicherheitsfragen

Kritisch für die Qualitätssicherung sind auch Einzelaspekte wie das Thema Sicherheit, das in der gegenwärtigen Diskussion noch selten angesprochen wird: so zum Beispiel die Frage, wie Benutzerrechte geregelt sein sollten, wenn für Arbeitsabläufe Ressourcen aus verschiedenen Systemen mit unterschiedlichen Zugriffsrechten eingebunden werden. Auf dieses nicht nur die Qualitätssicherung betreffende Problem gibt es noch keine zufrieden stellende Antwort.

Über eines jedoch sollte sich jeder SOA-Interessent im Klaren sein: Während in herkömmlichen Architekturen die Komplexität auf mehrere Blöcke verteilt ist, entsteht mit dem SOA-Bus eine große monolithische Einheit in einer neuen und problematischen Dimension. Dass es dabei riskante Konsequenzen auch für geschäftskritische Prozesse geben kann, ist nicht völlig auszuschließen. Sollten Flaschenhälse im IT-Prozess auftreten, erfordert eine SOA aufgrund der kaum noch zu übersehenden Anzahl von Schnittstellen äußerst intensive Untersuchungen. Eine Herausforderung für die Qualitätssicherung, die mit effizienten Methoden dieser neu entstandenen Komplexität zu Leibe rücken soll.

Prozessanalyse

Das Entscheidende in diesem Kontext ist die Geschäftprozessanalyse. Denn eine SOA gewinnt ja gerade dadurch an Attraktivität, dass Geschäftsprozesse unternehmensweit einheitlich und schlanker gestaltet sowie verbessert werden können. Arbeitsabläufe sollen sich nicht mehr länger an der IT orientieren. Umgekehrt legen jetzt die Prozesse fest, wie und welche Software eingesetzt wird. Welche Services unter dem GUI ablaufen, ist zweitrangig, der Arbeitsablauf rückt sichtbar in den Vordergrund. Die Geschäftsprozessanalyse enthüllt dafür die Kernprozesse, modelliert restrukturierte, unternehmensspezifische Arbeitsabläufe und ist Basis zur Identifikation der wiederverwendbaren Services.

Die über den SOA-Bus zu Applikationen zusammengestöpselten Dienste sollen endlich die lang geforderte Flexibilität eröffnen, um rasch auf sich ändernde ökonomische Bedingungen zu reagieren. Ein neuer Aspekt dabei ist, dass mittels der Business Process Execution Language (BPEL) die aus der Analyse generierten Prozessmodelle simuliert und die Zusammenstellung der prozessorientierten Services geprüft werden können. BPEL wird damit im SOA-Ansatz zu einem neuen Testwerkzeug für die Qualitätssicherung, das den eher theoretischen Charakter der Geschäftsprozessanalyse aufhebt und per Computersimulation die Logik des Modells in seinen konkreten Auswirkungen sichtbar werden lässt. Dennoch darf man sich hier nicht täuschen: Was in der Simulation funktioniert, läuft nicht zwangsläufig auch in der Praxis.

Offene Fragen

Denn im Kontext des Gesamtsystems beginnt sich das Bild einzutrüben. Wie verhält sich ein einzelner Dienst, wenn mehrere Nutzer gleichzeitig darauf zugreifen? Zwar ist die Antwortzeit eines Service mittels Last-Performance-Test im System messbar. Jedoch ist keine direkte Aussage über sein Verhalten innerhalb eines Workflows möglich, der selbst aus mehreren Services zusammengesetzt ist. Die miteinander verknüpften Dienste können sich ganz anders verhalten als die Summe der Einzelservices. Einen Ausweg bietet die Qualitätssicherung, indem Arbeitsabläufe über Testfallketten hinweg simuliert werden - ein schon in der Vorbereitung arbeits- und zeitaufwändiges Vorgehen. Damit sollte jedem klar sein: Last-Performance-Untersuchungen werden im Kontext mit einer SOA komplexer und sind mit einem hohen Aufwand verbunden.

Keine neuen Anforderungen stellen dagegen die grafischen Benutzeroberflächen, die über die einheitliche Schnittstelle des SOA-Busses die Funktionen der Services dem Anwender zugänglich machen. Die Qualitätssicherung der GUIs ist mit den herkömmlichen Methoden und Werkzeugen einschließlich der Testautomation auch unter einer SOA gut zu bewältigen. Grundsätzlich stellt sich aber die Frage, wie die GUIs in der SOA-Welt aussehen sollen. Dies ist keineswegs trivial, sobald die Qualitätsmerkmale Bedienerfreundlichkeit und Benutzerakzeptanz ins Spiel kommen. Was einen Buchhalter begeistert, muss nicht automatisch einem Vertriebsmitarbeiter gefallen. Ungeklärt ist bislang auch, wer und mit welcher Sprache innerhalb einer SOA die Oberflächen entwickeln soll.

Fazit

Noch ist SOA mehr Theorie denn gängige Praxis. Störungen unter SOA-Strukturen zu beseitigen wird aufwändiger und langwieriger als in herkömmlichen Systemen. Die ganzheitliche Systemsicht wird durch die Komplexität des SOA-Busses und die Vielzahl der hier konzentrierten Schnittstellen erschwert. Während sich einzelne Services ideal testen lassen, treten die Probleme spätestens dann auf, wenn die Softwaredienste im Rahmen eines Workflows überprüft werden sollen. Fehler können zum Beispiel durch die falsche Konfiguration und Anbindung der Services entstehen, im SOA-Bus selbst liegen, in der Benutzeroberfläche oder schon bei der Definition der Geschäftsprozesse verursacht werden. Schlimmstenfalls kommen sie an mehreren dieser Stellen gleichzeitig vor.

Auch die Kontrolle der Systeme wird schwieriger. Im SOA-Bus selbst sollte deshalb beispielsweise ein zentrales Logging die möglichen Fehlermeldungen der voneinander unabhängigen Dienste protokollieren und der Fehleranalyse zugänglich machen.

Die Kernprozesse der Qualitätssicherung bleiben somit auch in einer SOA erhalten, die Fokussierung ändert sich jedoch. Ins Zentrum der Aufmerksamkeit rücken die Analyse der Geschäftsprozesse und die Infrastruktur des SOA-Busses. SOA-Projekte, so viel steht fest, erfordern schon allein aus Sicht der Qualitätssicherung aufgrund der detaillierten Analyse, Planung und Vorbereitung mehr Zeit. In der technischen Umsetzung sowie im laufenden Betrieb hängt viel davon ab, wie zuverlässig die zentrale SOA-Instanz, der Bus, zumindest die klassischen Qualitätsmerkmale zufrieden stellend erfüllen kann: Antwortzeit, Funktionalität und Robustheit.