enterprise2punkt0.at

Die CMG-AE (www.cmg-ae.at) hat im Rahmen des Arbeitskreises “IT Management” am 30. September 2009 die beiden gängigen Konzepte “Geschäftsprozesse” und “SOA” miteinander kombiniert und fünf Vortragende eingeladen, über das gegenseitige Verhältnis der beiden zueinander (oder miteinander oder gegeneinander) zu referieren. Ich selbst habe auch unsere Vorstellungen berichtet; anbei meine durchaus umfangreiche und persönliche Zusammenfassung der Veranstaltung.

Hinweis: Diese Zusammenfassung gibt ausschließlich meine persönliche Meinung wieder. Zum Zeitpunkt der Zusammenstellung hatte ich auch keinen Zugriff auf die Unterlagen (PDFs) der Vortragenden.

BPM & SOA: 2 Ansätze, 1 Suite. Zum State-of-the-Art der technischen Konvergenz von BPM(S) und SOA.

Ich selbst habe mich darauf konzentriert, nachzuweisen, dass BPM und SOA letztendlich auf ein gemeinsames Ziel und Ergebnis hinauslaufen, man hat nur an unterschiedlichen Seiten des Grabens zwischen Fachabteilung und IT begonnen, diese Trennung zu überwinden.

Das UNIQA Elektronischen Belegfluss Projekt ist zwar prima facie ein lupenreines BPMS Projekt, wo ein Humanprozess mit einer Prozessmaschine abgebildet wird (Ansteuerung der Sachbearbeiter mit elektronischen Akten), man (= die IT) stößt aber bei der Realisierung (hier mit webMethods) sofort auf die Notwendigkeit, IT-Funktionen elegant ins BPMS zu integrieren: Voila, hier ist ein SOA Service bzw. wäre es hübsch, wenn wir ein solches schon hätten.

Raiffeisen Capital Management hingegen hat bei einem reinrassigen Integrationsprojekt (technische Integration im Order Management mit SWIFT und FIX etc. Anbindungen) sehr rasch erkannt, dass man die atomaren technischen Integrationsfunktionen (Adapter liefert oder schreibt Daten) sinnvollerweise recht rasch miteinander kombinieren möchte (einfacher, rascher, weniger fehleranfällig). Voila, hier ist ein „Service Flow“ oder ein Prozessfragment (aus „orchestrierten Services“, um im SOA Jargon zu bleiben) Und für die Fehlerbehandlung wäre ein kleiner Humanprozess ganz angenehm, womit wir bei Prozessmaschine und Präsentationslogik sind.

Natürlich unterstützt die webMethods Suite das alles ganz perfekt und insbesondere auch von ihrer Architektur her, aber auch sonst bewegen sich die Standards und die Mergers & Acquisitions der Anbieter von BPMS und SOA Infrastruktur in eine gemeinsame Richtung — auf den Punkt Omega hin. „Business Process System“ habe ich das genannt, Gartner und Forrester nennen das sicher irgendwie anders, dort, wo BPM(S) und SOA sich in durchaus naher Zukunft treffen werden.

Apropos Standards: Die aus meiner Sicht wichtigsten drei Standards im Bereich BPM(S) sind derzeit (nach fallender Bedeutung geordnet): BPMN, XPDL und (da ist ein großer Abstand) WS-BPEL. Letzteres wird meiner Ansicht nach maßlos überschätzt (sieht ja doch nur die Maschine und die Portierbarkeit von BPEL Prozessen zwischen zwei BPEL-Engines wird von etlichen Organisationen deutlich falsch eingeschätzt); dito mit BPEL4People, wo es seit Juli 2009 gerade erst einen (internen) Committee Draft der OASIS gibt.

Die gerade laufende Akquisition der IDS Scheer AG durch die Software AG ist ebenfalls nur ein (weiterer) Schritt der zahlreichen Akquisitionen im BPMS und SOA Umfeld, die auf den Punkt Omega konvergieren (die SAG hält derzeit übrigens schon mehr als 75% der Aktien der IDS Scheer AG).

Und warum tut man sich das überhaupt an? Hauptsächlich wegen des ROIs (Return on Investments) auf der Ebene der Geschäftsprozesse und der Prozessoptimierung. Als Nebeneffekt gibt es auch einen IT ROI — aber jeder, der probiert, seine SOA rein und ausschließlich über die Einsparungen in der IT zu rechnen (Stichwort. Reuse), ist bis dato meines Wissens nach gescheitert. Geben sie aber nur ein bisschen Verbesserungen im Fachbereich dazu (bei der UNIQA arbeiten knapp 3.000 Sachbearbeiter mit webMethods: Da genügen schon kleine operative Einsparungen und der ROI auf Ebene der Fachabteilung ist unter 12 Monaten), und SOA mit BPM(S) ist erfolgreich.

Performance Management von Geschäftsprozessen

Herbert Groiss von Groiss Informatics konzentriert sich in seinem Vortrag auf die Möglichkeiten der Optimierung von Geschäftsprozessen. Dazu bemerkt er einleitend, dass in sehr vielen Fällen trotz eines hübschen Kreislaufmodells (Strategie -> Design -> Ausführung -> Optimierung -> Strategie… u.s.f.) in der Praxis die Optimierung ausschließlich in der Technik (= IT) statt findet. Der Rückfluss von der Technik in das (strategische) Geschäftsprozessmanagement (u.a. auch die Modellierung) fehlt häufig.

Spannend waren seine Ausführungen über probabilistische Methoden der Vorhersage. Im Gegensatz zur Simulation wird dabei die Wahrscheinlichkeitsrechnung bemüht, um Aussagen über zukünftige Eigenschaften der laufenden Prozessinstanzen zu machen, bspw. wann wird der Prozess voraussichtlich enden, wie viel Ressourcen werden wir in 4 Wochen voraussichtlich benötigen. Vorteile: schneller und (angeblich) exakter als die Simulation.

Kernpunkt waren aber seine Ausführungen zu den drei (!) Kreisläufen der Optimierung (bzw. den drei Feedback-Schleifen der Prozessoptimierung):

• automatische Steuerung: Lastverteilung durch eine Workflow-Engine, Rerouten von Aktivitäten und Aufgaben bei Nichtverfügbarkeit von Ressourcen.

• interaktive Steuerung: Ein „Prozessmanager“ greift händisch — unterstützt durch Prozessmanagement „Dashboards“ und Business Activity Monitoring — in den Prozessablauf ein (bspw. Vergrößeren der Ressourcen, Eskalationen)
• strukturelle Steuerung: Auf Basis der Echtdaten von zahlreichen Prozessdurchläufen überlegt sich das Management gemeinsam mit dem Prozessmanager Verbesserungsmaßnahme, die auch in die Prozessgestaltung und Prozessschritte eingreifen. D.h. diese Maßnahmen betreffen auch die Aufbau- und die Ablauforganisation.

Dass das Ganze zwar auf einem Forschungsprojekt mit der TU Wien und Uni Klagenfurt beruht, aber in der Praxis schon (länger) ausgezeichnet funktioniert, beweist Groiss mit zahlreichen Verweisen auf Referenzprojekte seines @enterprise Workflow Management Systems.

Vergiss vor lauter SOA den Anwender nicht.

Günter Grossberger von CA (Computer Associates heißen seit längerem ja nur noch „CA“ räumt mit dem Mythos auf, eine SOA würde die IT Landschaft einfacher machen. Das Gegenteil ist wahr: Durch die Entkoppelung von Anwendungsfunktionalität in einzelne (SOA) Services, durch die Aufspaltung der typischen SOA Architekturen in die zahlreichen Schichten (Präsentation, Prozesse, Service-Orchestrierung, Integration, Applikation Server, Legacy Applikationen, Outsourcing, Software as a Service Provider, alles über ein Netzwerk mit WLAN und GSM Anteilen) wird die IT natürlich deutlich komplexer als vorher.

Damit stellt sich sofort die Frage: Wenn die früheren Applikationsverantwortlichen („Meine Adabas Applikation“, „Meine CICS Applikation“) verschwinden: Wer kümmert sich dann um die Probleme, die der Anwender mit den „SOA Applikationen“ hat, wenn diese einmal nicht funktioniert? Stichworte hier sind vor allem langsame Antwort- und Reaktionszeiten der „SOA Applikation“ und Ausfälle.

Tatsächlich gibt es (hier der Application Performance Manager von CA Wily) dafür sozusagen ein „Kontrastmittel“ für die SOA Infrastruktur, das quer und verteilt über alle Schichten und Serverinstanzen anzeigt, wo es Schwachstellen und Ausfälle gibt. Damit steht dem SOA System Manager ein wirksames Werkzeug für die (seit ITIL gefürchtete) „Root Cause Analyse“ zur Verfügung (Wo hakt es wirklich). Ein interessanter Nebeneffekt des Application Performance Managers ist, dass er durch Korrelation auch die Abhängigkeiten der höherwertigen („orchestrierten“) Services von anderen Services zur Laufzeit erkennt.

Skeptisch wie ich bin habe ich in der Pause Günter Grossberger gefragt, wie denn das tatsächlich technisch funktioniert: Eine Kombination von Agents (die auf den Server Systemen sitzen) mit einem Netzwerk-Sniffer und einem Aggregierungssystem, das die Daten des Sniffers und der Agenten konsolidiert und korreliert. Da wir (Software AG) selbst etwas Ähnliches mit unserem webMethods Insight machen können, glaube ich ihm das auch. Am besten sie fragen ihn aber selbst — der Wahrheitsbeweis sollte ihm nicht schwer fallen, da die Software schon bei einigen österreichischen (großen) Kunden funktioniert.

Business-SOA versus IT-SOA

Gerald Hainbucher von IDS Scheer betrachtet SOA leidenschaftlich (wie man das zu Recht von der IDS Scheer erwarten würde) von der Fachseite und der Prozessmodellierung her kommend. Er hat sich in zahlreichen Projekten gefragt, ob und, gegebenenfalls, wo und wie man die „klassische“ Prozessmodellierung für eine SOA adaptieren müsste. Dabei fasst er den Begriff des „Service“ deutlich allgemeiner als die technische Fokussierung auf Web Services und WSDL: „Ein Service ist eine Leistung einer Person für ein andere Person“ (soweit ich mir das richtig gemerkt habe; PDFs habe ich derzeit noch nicht). Auto waschen, Fenster putzen, Kredit ausstellen wären dann derartige „Business Services“. In einer Business-SOA geht es jetzt in erster Linie nicht um die Frage, welche Web (WSDL) Services brauche ich, sondern wie zerlege ich meine Geschäftsmodell — neben den Prozessen — in Bereiche von Business Services, die sinnvoll zusammen hängen (diese Bereiche werden in der einschlägigen Literatur oft „Domänen“ genannt, auch wenn Hainbucher diesen Begriff nicht anführt). Unnötig zu erwähnen, dass das ARIS Tool Set natürlich die Definition und, noch wichtiger, die Abhängigkeiten derartiger Service Domänen mit den Geschäftsprozessen, Aktivitäten und Funktionen tatsächlich nahtlos mitführt. Erst bei der Umsetzung der Geschäftsprozesse stellt sich dann für derartige Business Services die Frage, ob das Business Service besser als „Human Service“ oder als ein „IT Service“ implementiert werden soll.

Wichtigste Neuerung gegenüber dem klassischen Prozessmodellierung ist die Trennung von Daten und Funktion (= ARIS Speak für „Aktivität“). Reine funktionale Prozessmodelle sind alleine nicht in der Lage, die relevanten Business Services zu finden, dafür benötigt man sozusagen die Daten als „Klebstoff einer Business und IT-SOA“.

In der Diskussion wurde auch deutlich, dass ein kritischer Erfolgsfaktor die Rolle des „Business Service Engineers“ ist, also derjenigen Person, die derartige Business Services bzw. Daten modelliert. Hainbucher berichtet zwar von glücklichen Fällen, in denen eine Wirtschaftsinformatikerin in der Buchhaltung unterfordert und daher gerne Datenmodelle (für die Daten Services) erstellt hat, aber das dürfte dann doch eher eine Ausnahme sein.

Business Prozess Management mit SAP

Hr. Weidner von SAP Österreich stellt Use Cases für den Einsatz der SAP NetWeaver Plattform vor. Extrem interessant war dabei die Tatsache, dass SAP (in diesem Vortrag) den Anwendungsfall für NetWeaver rein auf die Modellierung und Ausführung von „Ausnahmeprozessen“ zum „normalen“ Geschäftsprozess beschränkt. Die echten und wahren Geschäftsprozesse laufen natürlich nach wie vor in der SAP Business Suite (so heißt das normale SAP ERP heute, habe ich gelernt). Und keine Organisation, da stimme ich der Einschätzung von Hrn. Weidner zu, wird diese Prozesse in NetWeaver service-orientiert nachprogrammieren.

Es geht also bei NetWeaver weniger um große Geschäftsprozesse, sondern um die Kleinigkeiten und Supportprozesse, die man innerhalb von SAP „klassisch“, also innerhalb der ABAP Welt, nicht oder nur mit sehr viel Aufwand abbilden kann. Gefallen hat mir die Abkürzung „3 Ls“ für die Ursachen derartiger (begrenzter) Anpassungen: „Legal – Local – Language“.

Dafür gibt es einen (Eclipse- und BPMN) basierten BPM Designer, der letztlich WS-BPEL Code produziert, der im SAP NetWeaver PI ausgeführt wird (so genau wurde das gar nicht besprochen). Als Beispiele wurden u.a. genannt: Ausnahmen bei der Bestellannahme, Grid Asset Management eines Energieversorgungsunternehmens (als Ergänzung von SAP IS-U) sowie Exponierung von bestimmten Funktionen von SAP für den Endkunden, der natürlich keinen SAP GUI bekommt.

Wohltuend war die Bemerkung, dass die „Programmierung“ der Ausnahmeprozesse im SAP BPM Designer natürlich von einer IT-Rolle vorgenommen wird. Die Idee, dass der Fachbereich selbst ausführbare (BPMN-) Modelle erstellen könne, wurde unter dem (richtigen) Hinweise auf das notwendige tiefe IT-Wissen, dass für eine Ausführung in einer Prozess-Maschine notwendig ist, in das Reich der Märchen verbannt.

En passent ging Hr. Weidner auch auf die ca. 2.800 Services im SAP Enterprise Service Registry (ESR) ein, die „ready to run“ für SAP Kunden zur Verfügung stehen. Unter „Service“ versteht die SAP hier eine größer Menge von Serviceoperationen, bspw. „Manage Customer“ als eines der „Services“ im ESR, das natürlich zahlreiche Serviceoperationen wie bspw. „Create Customer“, „Change Customer“ u.a. umfasst. „Ready to run“ bedeutet in diesem Zusammenhang, dass man die entsprechenden Funktionen des Services in seinem „Basis SAP“ laufen und lizenziert haben muss, damit es (wieder) verwendet werden kann.

Die präsentierten Kundenimplementierungen waren allerdings alle in einem ausgesprochen frühem Stadium, manche noch gar nicht produktiv. Dies hängt mit dem Vorgehensmodell für die Entwicklung dieser Funktionen zusammen, die SAP sehr stark gemeinsam mit ausgewählten Pilotkunden vorgenommen hat.

Zuletzt gab es einen Ausblick auf die nächsten Features im Bereich von NetWeaver, wo u.a. der „Solution Manager“ erstmals in der Lage ist, auch fremde Prozesse in ein einheitliches Repository aufzunehmen. Ich schließe daraus, dass das ESR derzeit das gar nicht kann. Prozess-Dashboards und (real time) Business Activity Monitoring (BAM) gibt es auch erst in der nächsten Release (beides Funktionalitäten, die die „pure play“ BPMS Anbieter schon seit Jahren im Portfolio haben).

Diese Informationen würden meine Einschätzung und auch die im Vortrag antönende Selbstsicht von SAP bestätigen, dass SAP NetWeaver vor allem eine Integrations- und Prozessplattform für Kunden ist, die ihre Geschäftsprozesse und Kernprozesse bisher schon mit Masse in SAP selbst abgebildet haben.