Heute war er der “SOA-Tag” bei Freund und Dirks. Zahlreich erschienen interessierte Teilnehmer zum Thema Serviceorientierte Architekturen. Nach und während meines Vortrages kamen natürlich zahlreiche Fragen auf, wie z.B.

  1. Was ist der Unterschied zwischen einem Service und einer Komponente ?
  2. Sind Web-Services nur Wrapper von bestehenden Anwendungen? Und wenn ja, wie ist dies vereinbar damit, das ein Service doch eigentlich nur Operationen auf Business-Level haben soll und keine API-Aufrufe einer Legacy-DLL nach außen über einen Webservice bereitstellt ?
  3. Kann ich meine beschriebenen UML-Use-Cases in Service-Beschreibungen transformieren ?

Fragen über Fragen. Hier nochmal meine Erkenntnisse von Heute in Kürze:

  1. Die verschiedenen Brillen der einzelnen Beteiligten (IT, Management, Fachabteilungen, …) und das Wording stellen ein Problem dar. Das Verständnis über den Begriff Prozeß allein stellt schon ein Problem dar. Ein Prozeß kann ein Betriebssystem-Prozeß sein, ein IT-Prozeß, ein Business-Prozeß, ….
  2. Prozesse die beispielsweise in BPEL beschrieben sind, aber in der Unternehmenswirklichkeit nicht gelebt werden, sollten mit SOA kein Problem darstellen. Denn: Stimmt die Granularität meiner Services, kann ich einen solchen Prozess problemlos neu orchestrieren und “deployen”
  3. Warum sollte ich innerhalb des Unternehmens anderen Einheiten Services bereitstellen, die über die Funktionalität, die meine Einheit selbst benötigt, hinausgeht? Warum sollte ich andere Services im Unternehmen nutzen, wenn ich sie auch selbst programmieren lassen kann? Ein Teilnehmer schlug hier vor, im SOA-Management ein Belohnungssystem einzuführen, wenn eine Einheit die Services einer anderen nutzt. Diese Idee sollte man meiner Meinung nach weitereintwickeln.
  4. Generell ist eine SOA-Verwaltung sinnvoll. Die Software AG stellt für den Lebenszyklus von Services hier entsprechende Tools bereit, die Services versionieren und die Abhängigkeiten zu den Prozessen darstellen.

Alles in Allem ein gelungender Tag ….