[OOP 2008] SOA ist nicht (nur) Technologie

Ralf hat auf meine Gedanken zu SOA mit einigen guten Gedanken geantwortet und empfiehlt Systemtheorie und systemisches Denken. Er gibt zu bedenken, dass SOA nicht nur Denken im Großen bedeuten kann. Nachdenken hat natürlich noch nie geschadet, auch nicht beim Programmieren :-) Mein Beobachtungen suggerieren, dass die Probleme auch woanders liegen, weil zum Beispiel SOA oft nur als weitere Middleware begriffen wird, nicht als Paradigma. Ist SOA eine schlichte Evolution von OO? Reicht es, existierende Applikationen durch Service-Wrapper zu SOA-enablen?

Aus meiner Sicht ist SOA eine Vielzahl von Dingen:

• Es ist keine Technologie, sondern ein Architekturparadigma.
• SOA ist nicht gleich WS-*.
• SOA erfordert Änderungen in Organisationen und Prozessen. Stichwort: Governance. Im Prinzip sind SOA-Entwicklungen Produktlinien.
• SOA ist keine Middleware, die bisherige OO Middleware ersetzt. Es ist eine Fortentwicklung von Message-Oriented Middleware.
• SOA ist eine Integrationstechnologie.

SOA lässt sich daher auch im Kleinen nutzen, betrachtet man es als Paradigma.

Sobald ESBs, SOA Frameworks und WS-* in den Mittelpunkt rücken, ist es ein Ansatz für grosse Systeme. Allein schon deshalb, weil die Komplexität von ESB-Lösungen und SOA Frameworks den Rahmen von Kleinprojekten sprengt.

Zur Umsetzung des SOA-Gedankens ist ein holistischer Ansatz gebracht, der auf folgenden Säulen beruht:

• Standardisierung: Es solte möglichst auf Standards gesetzt werden, nicht auf Eigengewächse. Es sei denn, ein proprietärer Ansatz wird angestrebt.
• Markt und Hersteller: Zu beachten ist der volatile SOA-Markt, der ständigen Änderungen unterworfen ist. Welche Standards unterstützen die Hersteller. Welche Produkte sind reif und welche noch nicht?
• Architektur und Domäne: Welche Anforderungen ergeben sich hinsichtlich der Domäne? Welche Technologien mappen am besten auf diese Anforderungen. In einem top-down Ansatz müssen grobgranulare Dienste aus den Geschäftsanforderungen abgeleitet werden. Feingranulare Dienste sollten nicht direkt für Clients zugreifbar sein. Service-Aufrufketten sind zu vermeiden, Versionierungsaspekte und verschiedene Service-Versionen zu berücksichtigen. Best Practice Ansätze (Patterns) bieten grosse Hilfe. Für die Integration von Legacy Software ist ein geplantes Vorgehen notwendig.
• Prozeß und Organisation: Die Organisation ist dem SOA-Paradigma entsprechend zu ändern, etwa Einteilung in Anwendungs- und Serviceentwicklung. Governance-Aspekte müssen durch eigene Teams abgedeckt werden, speziell bei SOA im Grossen. SOA fängt oben an bei den Anforderungen. Ein bottom-up-Ansatz ist lediglich für Integrationsaspekte zulässig. Jegliche Art von Big-Bang-Ansatz ist kontraproduktiv. Eine schrittweise Transition ist hingegen empfehlenswert.
• Technologie: Herstelleraussagen hinsichtlich SLAs und NFRs sind gründlich zu verifizieren, etwa durch Prototyping. SOA darf nicht als Middleware betrachtet werden. Den Fehler, in Point-to-Point Kommunikation zu verfallen, sollte man vermeiden, schon wegen der höheren Komplexität.

Das sind natürlich nur einige Punkte. Wir sehen, ein systemisches Vorgehen ist durchaus vorteilhaft. Dabei ist aber nicht nur die IT-Abteilung involviert sondern alle Stakeholder. SOA ist nicht einfach sondern sehr komplex, weil es schon heute Ansätze des Ultra Large Scale Computing vorweg nimmt, sich aber auch im Kleinen umsetzen läßt. Gerade diese Mischung sorgt für Sprengkraft.

Wer also sein Projekt unter Garantie gegen die Wand fahren will, greife jetzt zu einem SOA Toolkit nach Wahl und fange einfach an, darauf loszuprogrammieren.