SOA Blueprint – Werkzeugkasten für Architekten
Wer SOA im Unternehmen einführen will, muss vorab die Grundlagen und die Werkzeuge klären. Unser allgemeiner SOA Blueprint hilft, den Nutzen kommerzieller und Open-Source-Tools zu ermitteln. Denn bei SOA gilt noch immer das Erfolgsrezept: Think big, start small!

Von klein nach groß
Der Begriff "SOA" wird immer weiter verwaschen, fast universell eingesetzt. Einer der Gründe liegt darin, dass SOA-Designprinzipien und -Werkzeuge in den unterschiedlichsten Kontexten eingesetzt werden. Eine konkrete Anwendung der theoretischen Prinzipien sorgt für Klarheit.

Die SOA-Service-Kategorienmatrix
Wie kommt man zu wirklich wiederwendbaren "kanonischen" Businessservices, die auf Funktionalität in einer heterogenen Systemlandschaft abgebildet sind? Hilfreich ist ein Vokabular, das sich in konkreten Projekten bewährt hat.

Lose Kopplung – Warum das Loslassen verbindet
Werden immer mehr Anwendungen und Systeme verbunden, wächst rasch auch die Komplexität und die damit verbundenen Verwaltungs- und Integrationsanforderungen. Eng gekoppelte Integrationsansätze beginnen daher bei hoch vernetzten, heterogenen Systemen, wie bei SOA, an ihre Grenzen zu stoßen.

Was macht einen guten "Public Service" aus?
Wenn wir beurteilen sollen, ob ein vorliegender Service "gut" oder "schlecht" ist, brauchen wir klare Richtlinien und Anforderungen, an die sich alle Services halten müssen. Generell existieren zwei Szenarien: Man stellt uns Services zur Verfügung, die verwendet werden sollen, oder wir müssen selbst Services erstellen, die dann wieder von anderen weiterverarbeitet werden.

SOA Governance – Ordnung ins Dickicht
Wenn nichts mehr vor und zurück geht, fehlen Regeln, die das Verhalten des Einzelnen bestimmen und ihn in bestimmten Situationen anleiten. Das Ziel einer Governance ist es, mithilfe von Regeln und der Überwachung der Einhaltung dieser Regeln dafür zu sorgen, dass ein komplexes Gesamtsystem möglichst rund funktioniert.

SOA Security
In klassischen Systemen sind Sicherheitsanforderungen durch ihre lokale Beschränkung meist relativ einfach beherrschbar. Ihre Komplexität erhöht sich in der verteilten Systemlandschaft einer SOA: Sicherheit beschränkt sich hier nicht nur auf eine Applikation oder eine Anwendungsdomäne, sie muss anwendungs- und geschäftsprozessübergreifend wirken.

SOA Design Pattern: Compensation
Einige SOA Design Pattern sind in Projekten besonders erfolgreich angewandt worden. Dazu gehören das Compensation Pattern, das UI Mediator Pattern, das Common Data Format Pattern und das Data Access Pattern.

SOA und Benutzeroberflächen
Das Zusammenspiel von Benutzeroberflächen mit Diensten einer SOA ist ein oft vernachlässigtes Thema. Daher gibt es besondere Herausforderungen, die bei der Erstellung von Oberflächen zu meistern sind, wenn ganze Prozessketten aufzurufen sind und mit diesen interagiert werden soll.

SOA und Daten – Das kanonische Datenmodell
Mit SOA sollen sich neue fachliche Anforderungen in kürzerer Zeit umsetzen lassen. Das aber erfordert die konsequente Anwendung der Architekturparadigmen, wie die Implementierung loser Kopplung. Ohne ein kanonisches Datenmodell gelingt daher auch keine SOA.

Menschen zählen – SOA und Change Management
SOA wird weitläufig als IT-Architektur begriffen und erscheint auf den ersten Blick oft als nicht relevant für das operative Geschäft. SOA leistet jedoch sehr viel mehr als eine reine „Orchestrierung“ der Systemlandschaft. Was muss getan werden, damit das Business beginnt, die Vorzüge und Mechanismen von SOA zu begreifen und gezielt einzusetzen?

Data Access Services oder: Wie komme ich an meine Daten?
Automatisch ablaufende Prozesse arbeiten auf Daten, die bereits in den verschiedenen Systemen vorhanden sind. Auf dem Weg zu einer SOA ist es wichtig, eine einheitliche Vorgehensweise zu entwickeln, wie diese bestehenden, datenliefernden Systeme eingebunden werden.

Event-driven SOA – ein Überblick
SOA ist wichtig, um die Grundlagen für unsere zukünftigen Architekturen legen zu können. Betrachtet man aber echte Unternehmen und deren Geschäftsvorfälle, so stellen wir fest: Die reale Welt läuft gar nicht so stark serviceorientiert, sondern vielmehr ereignisorientiert ab.