SOA ist gut, aber nicht für jeden – zu dieser gemeinsamen Position kamen die Teilnehmer einer Podiumsdiskussion über Service-orientierte Architekturen auf der Kongressmesse OOP 2008 in München. Wenn typische, mit SOA verknüpfte Eigenschaften wie Agilität und Flexibilität nicht erforderlich sind, etwa weil die unternehmensspezifischen Geschäftsprozesse strukturiert, vor allem aber sehr gleichförmig ablaufen, dann sollten Anwender die Hände von einer neuen Architektur lassen. Er habe Situationen erlebt, wo Anwender in ihrer SOA-Euphorie aufwändige BPEL-Services aufgesetzt haben, obwohl einfache Datenbankeingriffe oder Batch-Programme gereicht hätten, meinte Panel-Teilnehmer Stefan Tilkov von der InnoQ GmbH aus Ratingen bei Düsseldorf.

Einen im Vergleich zu Agilität und Flexibilität deutlich pragmatischeren Ansatz in der Beschreibung von SOA-Zielen wählte Diskussionsmoderator Nicolai Josuttis von IT-communication.com in Braunschweig. SOA habe zunächst nichts mit Produkten zu tun, vielmehr handele es sich um ein Konzept beziehungsweise eine Strategie, mit der sich große, verteilte und in der Regel heterogene IT-Systeme besser verwalten lassen. Wer solche Komplexität nicht im Haus hat, sollte auf SOA-Techniken oder Web-Services besser verzichten. Doch oft gibt es keine Alternative, denn spätestens im B-to-B-Umfeld geht es darum, die in verteilten Systemlandschaften unterschiedlich definierten Datentypen so zusammenzubringen, dass sie den diversen Sichten der Fachbereiche konsistent zur Verfügung stehen. Das SOA-Rezept dafür heißt Reduktion von Abhängigkeiten, insbesondere die Trennung von fachlicher und technischer Schicht sowie deren lose Kopplung über APIs. Im Prinzip nichts Neues, so Josuttis, aber immerhin habe der SOA-Hype dazu geführt, dass man nun nicht mehr verzweifelt gegen die Komplexität einer heterogenen IT-Landschaft ankämpft, sondern diese akzeptiert und Wege sucht, mit ihr zu leben.

Schwache Wiederverwendung

Als einen der wesentlichen Treiber, mit dem IT-Umbau nach SOA-Prinzipien zu beginnen, nennt der Experte neben der Pflege und Wartbarkeit komplexer Systeme auch die Software-Entwicklungskosten, die im Vergleich zu traditionell wachsenden Infrastrukturen auf lange Sicht deutlich niedriger ausfallen sollten. Die von Herstellern in diesem Zusammenhang gerne ins Feld geführte Wiederverwendbarkeit von Services eignet sich dagegen kaum als SOA-Motivator. Josuttis zufolge habe sich in zahlreichen SOA-Projekten herauskristallisiert, dass ein Softwareservice (Provider) im Durchschnitt nur von ein bis zwei Nutzern (Consumer) in Anspruch genommen wird, von einer intensiven Mehrfachverwendung also kaum die Rede sein kann.

Bezüglich der Einführung von SOA gab der Berater im Rahmen einer eigenen OOP-Session eine Reihe wertvoller organisatorischer und technischer Tipps. Da SOA die Summe aus Infrastruktur-, Architektur- und Prozessaspekten ist, muss sich dieser Umstand auch in der Zusammensetzung des Projektteams widerspiegeln. Haben Entwickler oder die IT das Sagen, droht ein technischer Überhang, verordnet das Topmanagement SOA, kann das ein teures, aber wenig erfolgreiches Projekt zur Folge haben. Ansonsten gilt das unter Experten bekannte Prinzip: "Think big, start small". Josuttis empfiehlt einen überschaubaren Piloten mit einer kleinen Anzahl von Basisdiensten und Serviceteilnehmern. Erst im nächsten Schritt sollte man Prozesse in Form kombinierter oder orchestrierter Services sowie Prozessregeln einführen.