Warum unternehmensweite SOA-Projekte scheitern

Firmen, die den unternehmensweiten Einsatz von Service-orientierten Architekturen (SOA) planen, müssen auf technische und regulatorische Probleme achten.

Auch wenn das Scheitern der SOA-Projekte zunächst mit einer schlechten technischen Implementierung in Verbindung gebracht werde, stelle die mangelhafte Governance ein immer höheres Risiko dar, hieß es vom Marktforscher Gartner.
 
Aktuelle SOA-Implementierungen zeigten, dass SOA mehr Aufwand in Sachen Service Design Governance sowie Best Practices für die Integration von Applikationen benötige, als in den meisten Unternehmen geleistet werde, sagte der Gartner-Analyst Paolo Malinverno. Zu Beginn eines SOA-Projektes seien die Risiken noch gering. Ein SOA-Projekt entwickele sich jedoch schnell. Die Unternehmen sollten daher kein unternehmensweites SOA-Projekt beginnen, ohne vorher Governance-Prozesse für die Definition, Implementierung und Aufrechterhaltung der Services festzulegen.

Ein typischer organisatorischer Fehler ist es demnach, ein unternehmensweites SOA-Projekt wie andere AD-Projekte (Application Development) abzuwickeln. Zudem wird unterschätzt, dass mit einer SOA viele Services dazukommen.

Wie viel Governance einer SOA gut tut, ist dabei laut Malinverno schwer einzuschätzen. “Zu viel und zu wenig Governance tötet ein SOA-Projekt.” Das Ausmaß der Governance müsse im richtigen Verhältnis zur Größe, Organisation und Kultur des Unternehmens stehen. Zudem sei die Einrichtung eines ‘Integration Competency Centre’ (ICC) oder ‘SOA Centre of Excellence’ (CoE) erforderlich.

Nach Angaben des Gartner-Analysten Massimo Pezzini gilt es gleichzeitig, die technischen Risiken zu beachten. Die unternehmensweite SAO-Installation erfordere Fähigkeiten, die in vielen Firmen nicht zu finden seien. Ein typischer technischer Fehler liegt demnach darin, die Komplexität der SOA zu unterschätzen. Oft werden falsche Komponenten für die Infrastruktur ausgewählt. Die SOA wird zudem ohne Proof of Concept und ohne Belastungstest implementiert.

Pezzini empfiehlt den Unternehmen, die SOA-Infrastruktur auf Basis ihrer realen funktionalen und nichtfunktionalen Anforderungen zu entwerfen – und nicht auf der Basis eines theoretischen Modells. Etwas 25 Prozent aller technischen Bemühungen sollten darauf gerichtet sein, ein leichtes Debuggen der SOA zu sichern, so der Analyst.