SOA meets BPM

Dieser Tage wurde ein Interview von mir zum Thema SOA und BPM veröffentlicht. Eine meiner Aussagen lautete sinngemäß, dass die Methodologien wie z.B. die Vorgehensmodelle der großen SW-Hersteller à la Oracle, SAP, IBM, etc. noch nicht ausreichend Prozess-zentrisch ausgerichtet seien. Damit meinte ich ganz einfach den Umstand, dass bei der Verwirklichung Service-orientierter Architekturen die Entwicklungsarbeit heute idealtypischerweise zweigeteilt ist:

Teil 1: Beim Anwender findet top-down (Enterprise Modeling) die Arbeitsprozessanalyse und -optimierung statt.

Teil 2: In einem nachfolgenden Schritt wird dann seitens der Nachfrager bei den Anbietern der bottom-up rekonstruierten Anwendungssoftware, die wir in Zukunft auch Application Service Provider nennen könnten, nach dem passenden Service gesucht. Hierzu werden eine Service-Anbieter-Analyse sowie eine Service-Rekonfiguration und -Evaluation durchgeführt.

Wie das mit Interviews heutzutage so ist, wurden natürlich vor dem Druck Meinungen anderer Experten eingeholt. Und eine dieser Kommentare möchte ich nun als Grundlage für den heutigen Blog-Beitrag nehmen.

Rolf Schumann (Europa-CTO Netweaver, SAP) antwortete auf meine Ausführungen: „Unsere Transformationsmethodik zur Enterprise SOA enthält ein Vorgehen, um betriebswirtschaftliche Prozesse auf der Business-Prozess-Plattform zu implementieren. Hinzu kommt eine Methodik zur semantischen Modellierung von Enterprise Services.“

Sie werden mir sicherlich zustimmen, dass es dieses Statement verdient, hier diskutiert zu werden. Ich mache gerne den Anfang und zwar mit der Frage, was Herr Schumann im Kontext von Enterprise Services mit „semantisch“ meint. Semantik, was übersetzt bekanntermaßen „Bedeutung“ heißt, ist eines der schwierigsten Konzepte in der Computer Science überhaupt. Aber ich denke, Herr Schumann meint mit „semantisch“ das, wofür wir hier in diesem Zusammenhang genauer die Bezeichnung „fach-semantisch“ verwenden sollten.

Wie also ist beispielsweise der Prozess-Abschnitt „konstruiertes Produkt zur FertigstellungFREIGEBEN“, „MitarbeiterEINSTELLEN“ oder aber „SteuerbilanzERSTELLEN“ genauer auszumodellieren, damit entschieden werden kann, welchen Teil des Prozesses ein Enterprise Service und welchen Teil weiterhin ein Mitarbeiter ausführen müsste?

Die Betriebssystem-Leute – wobei es bei uns natürlich um Arbeitsprozesse geht – werden sagen: „I need requirements to provide runnability“. Requirements (Erfordernisse) könnten wir mit „Betriebsmitteln“ im weitesten Sinne übersetzen, zu denen dann organisationstheoretisch auch Mitarbeiter gehören. Und diese Betriebsmittel gilt es auszumodellieren, um den Prozessen ihre Runnability zu verschaffen. Dazu müssen dann Methoden zur Aufgabenmodellierung wie beispielsweise Use Case Diagramme sowie Methoden zur Arbeitsprozessmodellierung wie beispielsweise BPMN-Diagramme zum Einsatz kommen. Mein Eindruck ist hier der, dass noch zahlreiche weitere Gegenstände einer Ablauf- und Aufbauorganisation wie z.B. Arbeitspläne oder Stellenbeschreibungen als „Betriebsmittel“ auszumodellieren wären, um zu einer „tatsächlichen“ Runnability zu gelangen.

Auf den ersten Teil der Aussage von Herrn Schumann würde ich übrigens – zugegeben ein wenig polemisch und mit Augenzwinkern – folgende Frage erwidern: Wenn die SAP über prozess-zentrische Vorgehensmodelle zur Einführung von SOA verfügt, wozu brauchen wir dann noch Firmen, wie beispielsweise die IDS Scheer?

Ihre Meinung ist gefragt: Wie sehen hier Sie die Situation auf der Seite der passenden Methodologien und welche Antwort haben Sie auf die Frage, was in fachsemantischer Hinsicht bei unserem Umgang mit den Arbeitsprozessen des Anwenders zur Erreichung ihrer hohen „Runnability“ modellierungsseitig getan werden müsste?