vielen Dank für Ihren Beitrag, der hoffentlich endlich mehr Realismus in die SOA-Diskussion bringt.

Vor allem Ihr Hinweis auf die organisatorischen Veränderungen, die durch SOA-Projekte ausgelöst werden, ist dabei für mich wesentlich. IT-Projekte mit diesem Ausmaß können nicht allein aus einer technischen Perspektive betrachtet werden.

Ich weise in diesem Zusammenhang gerne auf meinen Beitrag in diesem Blog zum Thema “Change Management in BPM- und SOA-Vorhaben” hin:

http://www.computerwoche.de/soa-expertenrat/2008/03/14/change-management-soa-und-bpm-initiativen-gezielt-begleiten/

Die Weiterbildung der IT-Projektleiter und -Führungskräfte muss ergänzt werden durch die Vermittlung von Kompetenzen für Organisationsentwicklung und Change Management, damit IT-Projekte zukünftig auch nachhaltig in den Organisationen umgesetzt werden.

Ich werde am 9.9. auf der “Zukunft Personal” in Köln einen Vortrag zu diesem Thema halten.

Mit freundlichen Grüßen

Uwe Feddern

Sind sowohl die fachliche Seite als auch die technische Seite nicht 100% beschrieben, so kommt es folglich zu einer loose-loose Situation. Das Ziel wird nicht erreicht und/oder Nacharbeiten des Lieferanten senken seine eigene Marge.

Die grundlegenderen Techniken sind vorhanden und weniger fehlerhaft als die beteiligten Personen. Zeitliche, finanzielle und zwischenmenschliche Gründe sorgen dafür, dass Projekte oft am Ziel vorbei laufen. Grenzen wie die ersten beiden sind natürlich wichtig. Wer aber immer noch nach der Geiz ist Geil Mentalität seine Projekte betreibt, erhält was er bezahlt. Jasager und Katastrophen.

Aus mehr als 20 Jahren Software Entwicklung haben sich einige Details herauskristallisiert:
„Früher war alles anders“.
„Technik lässt sich schneller/einfacher ändern als Menschen“.
„Alles was sich exakt beschreiben lässt, ist ohne Kostenbetrachtung technisch umsetzbar“.
„Kleine Schritte in die richtige Richtung sind besser als Nichts zu unternehmen oder auf das Ultimative Ergebnis zu warten“. (Siehe dazu auch den Text in einer anderen Computer Zeitung. „Thema ich kaufe mir seit 2 Jahren einen Computer“).
„Man lernt nur aus Fehlern“.

Aus meiner Sicht gibt es keinen Grund den Kopf in den Sand zu stecken und eine Rolle rückwärts zu machen (Schon probiert? Man bricht sich das Genick).
Wie bei allen Projekten sollte man die Erwartungen nicht zu hoch schrauben, sondern realistisch seine Lage beurteilen. Wo bin ich, wo will ich hin, was habe ich erreicht und sind wir bereits soweit?

SOA ist die IMHO die Verknüpfung von spezialisierten Diensten die ihre Aufgabe optimal erledigen können, anders als Giga Anwendungen die Alles, aber das nicht richtig beherrschen. Gerade SOA ermöglicht es mir einen Anfang zu machen und in kleinen Schritten an den Stellen wo es nicht klappt bessere Systeme zu integrieren.

Sie haben völlig Recht: Natürlich haben Fachmedien wie die COMPUTERWOCHE ausführlich über die Potenziale einer SOA berichtet, dabei aber auch immer die Versprechen der Hersteller kritisch hinterfragt. Die schlechten Anwendererfahrungen haben die Medien aber ebenso wenig erfunden wie die Beispiele erfolgreicher Projekte.

Grüße

Wolfgang Herrmann

Bitte nicht die Fachpresse (ja, auch die CW) vergessen!

Gruß,

Sebastian

Um Wiederverwendbarkeit zu ermöglichen, benötigt man ein sehr gutes (neuartiges) Repository, in dem genau und für jeden verständlich beschrieben ist, was der Service leistet. Das Problem ist mir seit vielen Jahren Erfahrung mit modularer Software bekannt - eine Lösung kenne ich bisher nicht. Gibt es eine?

Great! It’s a good site to learn more and have discussion.

It’s not bad to know that England Foreign Exchange EFXCO has so many facilities for traders and customers such as Loan Facilities, Mutual Fund, Hedge, Credit facilities, Insurance and etc…

Good Luck

ich habe in unserem Arbeitsgebiet, der Geschäfts- und Betriebsprozessmodellierung im Hinblick auf den Einsatz von IT-Services ähnliche Schwierigkeiten wie Sie mit solchen Einteilungen wie “Top-Down” und “Bottom-Up”. Man weiss nämlich nie, was der Gesprächpartner als Top (hier: die Ablauf- und Aufbauorganisation des Unternehmens) und was als Bottom (hier: das Rechnersystem und die IT-Services) verstanden wissen möchte. Zudem klingt “Top-Down” nach “grob” und “Bottom-Up” nach “detailliert”. Dieser Sprachgebrauch ist jedoch in der Praxis vielfach anzutreffen.

Ich würde, um Mißverständnisse auszuräumen, unabhängig davon, ob wir uns auf der Ebene der Unternehmensorganisation oder auf der Ebene der IT befinden, lieber einen Modellierungsanfang “aus der Mitte” heraus suchen. Also: Auch bei der Aufgaben- und Arbeitsprozessmodellierung von Einheiten (Komponenten) mittlerer Größe ausgehen und dann einer Insight-The-Component/Outsight-The-Component-Dychotomie das Wort reden.

Je nachdem, wie genau wir die Modellierung hierbei jeweils durchführen können, kommen wir zu einer hohen “Runnability” (spezifizierte “Betriebsmittel” der Prozesse) sowie einer hohen “Applicability” (spezifizierte “Bezugsobjekte” der Prozesse) unserer Prozessmodelle. Ein Betriebsmittel eines Prozesses ist bspw. ein Arbeitsplan, der einzuhalten ist und ein Bezugsobjekt eines Prozesses könnte bspw. ein Störfall in einem Unternehmen sein, dessen Beseitigung das Prozessmodell (Runnability) garantiert.

Die Modellierungsrichtung wäre: From Applicability to Runnability! Denn warum soll ich Prozessen eine Runnability (Betriebsmittel) “aufmodellieren”, wenn ich noch nicht spezifiziert habe, was eigentlich ihre Applicability (Bezugsobjekte) sein wird?

Beste Grüsse
Erich Ortner

ich sehe die größte Herausforderung zur Erreicherung von lauffähigen, technischen Prozessen, welche auf der initialen fachlichen Modellierung (Kompetenz BPM) beruhen, in der Abkehr vom Bottom-Up-Prinzip (bspw. Anwendungsfallmodellierung in UML) als Folge der Top-Down-Modellierung (Geschäftsprozessmodelle). Vielmehr gilt es, in Form einer erweiterten Geschäftsprozessmodellierungsphase Hilfsmittel wie eine Prozesslandkarte, Domänenmodell, Anwendungslandschaft, Rollen, Geschäftsobjekte, etc. heranzuziehen und die fachlich modellierten Geschäftsprozesse mit Informationen aus den genannten Hilfsmitteln anzureichern. Dadurch entstehen (theoretisch) fachlich orientierte, technisch angereicherte, ausführbare Prozesse, welche als Grundlage (plus weitere Ergebnistypen wie eine Liste der fachlichen Schnittstellen und Geschäftsobjekte) für die eigentliche implementierungsnahe Modellierung (z.B. UML) dienen. Die sogenannte “Runnability” zeichnet sich ja nicht durch eine maximale Detailmodellierung auf technischer Ebene aus, sondern durch die Ausrichtung an der Fachlichkeit! Der Mitarbeiter handelt fachlich, nicht technisch. Daher ist die Übertragung der “Fachsemantik” aus den GP-Modellen in die durch Services unterstütze ausführbare Prozesse mit Hilfe sequenzieller, teils iterativer Modellierungsstufen ein Hauptanliegen zur Erreichung von “Runnability” - denn ohne Nutzer leben die Prozesse nicht (außer bei einer 100%igen Automatisierung).

Viele Grüße,
Falk Ostermann
SAPICON GmbH

Ich stimme Ihnen zu, wenn Sie schreiben, dass eine genaue Kenntnis bzw. Überwachung der Geschäftsprozesse und einzelner Geschäftsvorgänge von zentraler Bedeutung für ein Unternehmen ist. Man benötigt ein klares, aktuelles, auf die jeweiligen Anforderungen abgestimmtes Bild der Situation um bessere (schnellere, qualifiziertere, auf einer idealen Datenbasis, …) Entscheidungen zu treffen.

Dennoch kommen mir spontan noch ein paar Fragen zu Ihren Ausführungen:
- Wo sehen Sie nach Ihrer Beschreibung die Abgrenzung zwischen BI und BAM?
- Sprechen sie von einem klassischen BI Ansatz oder eher einem ‘operational BI’ Vorgehen
- Was meinen Sie damit, wenn Sie schreiben ‘Wenn in der SOA erst einmal die relevanten Daten hinterlegt sind, können sich Unternehmen schneller als je zuvor auf Veränderungen einstellen.’?
- Ich würde mich freuen, wenn Sie die Synergieeffekte, die Sie zwischen SOA und BI sehen noch etwas erläutern würden.

Interessant zu diesem Thema ist ggf. auch meine Präsentation bei der 5. Expertenrunde zu BPM/BAM/CEP/SOA/EDA des CITT vom 26. Juni 2007 –> http://www.citt-online.com/downloads/exp5/Architectural%20Perspective%20on%20future%20Dashboards%20in%20a%20SOA%20and%20EDA_20070626_shown.pdf

Grundsätzlich kann ich dem Geschriebenen schon zustimmen, möchte aber dennoch ein paar aus meiner Sicht wichtige Dingen ansprechen, die im bislang aufgeführten zu kurz kommen:
- BPM (als Business Process Management) umfasst ja nicht nur die Beschreibung von Geschäftsprozessen (anhand einer entsprechenden Prozessmodellierung), sondern ist doch vielmehr eine Disziplin, welche Businessexpertise und Softwarefunktionalität dazu kombiniert Prozessverbesserungen zu beschleunigen und Innovationen zu erleichtern. Dazu gehören sicherlich auch entsprechende Komponenten wie die Simulation, Prozessmonitoring und Einbeziehen von Nutzern sowie eine mögliche Prozessautomatisierung.
- Um mein Geschäft besser auf aktuelle Situation und die Marktanforderungen ausrichten zu können reicht es doch nicht nur aus, die Geschäftsprozesse nach bestem Wissen und Gewissen zu modellieren und dann (automatisiert) umzusetzen. Nein. Ich muss doch vielmehr auch die Möglichkeit haben die Auswirkungen der Veränderungen bereits im Vorfeld zu prüfen (simulieren) und dann auch im produktiven Einsatz fortwährend einen aktuellen (echtzeitnahen) Einblick in meine Geschäftsprozesse erlangen um so kurzfristige Trends und auch Problemstellungen schnell erkenn zu können und auch auf einzelne Prozessinstanzen einwirken zu können — wobei wir dann bei Business Activity Monitoring (BAM) wären. Diese Informationen sollten natürlich auch möglichst wieder an die zurückgehen, die die Prozesse modelliert haben um hier die Anpassungen an die Realität auch vornehmen zu können.
Ich sehe es auch so, dass nicht alle KPIs, die für die unterschiedlichen bereiche eines Unternehmens wichtig sind auch über den aktuellen Geschäftsprozess erfasst und geliefert werden. Dies ist auch nicht weiter schlimm, es muss nur sichergestellt werden, dass eine Korrelation ermöglicht wird und auch relevante Informationen, die nicht aus dem Geschäftsprozess stammen mit einbezogen werden können.
- Im Bezug auf den Vergleich zwischen dem Vertrieb, der nicht programmiert und dem Programmierer, der nicht verkauft ist meine Erfahrung, dass das Ergebnis dann umso besser ist, wenn sich beide Seiten gut verstehen und es schaffen sich gegenseitig zu bereichern. Damit ziele ich darauf ab, dass es nicht nur wichtig ist, einen Weg zu definieren, wie Daten aus der Modellierung des Prozesses nachher zur Umsetzung gelangen, sondern wie es ermöglicht wird, eine Plattform zu schaffen, die einen Austausch an Informationen in beide Richtungen ermöglicht und auch als Diskussionsbasis sowohl für die Prozessbeschreibung als auch die Prozessumsetzung wertvoll ist. mein Ansatz ist hier zu sagen, je mehr der Business Analyst an Informationen bereits bereitstellen kann(Prozessmodell, KPIs, Business Objekte, Daten, …) umso mehr kann auch der Developer wieder übernehmen.
- Ich denke, wir müssen uns im Klaren sein, dass es sowohl zu BPM, als auch zu SOA unterschiedliche Einstiegspunkte gibt, die von der jeweiligen Kunden- und Geschäftssituation abhängen

Dennoch verwenden viele Werkzeuge ein BPMN-Modell zur Definition des Kontrollflusses, der - nach Erweiterung mit proprietären Elementen und Transformation in eine direkt von der Process Engine interpretierbare Repräsentation - ausgeführt wird. Insofern spielen BPMN-Modelle durchaus eine wichtige Rolle als Teil der Spezifikation ausführbarer Prozesse. Zumindest für diesen Teil eine standardisierte Notation zu haben, ist bereits ein Fortschritt.

Zahlreiche Elemente der BPMN haben einen ganz klaren Bezug zur Ausführung, wie z. B. Schleifen und Ausnahmebehandlungen.

Dass in der BPMN noch vieles fehlt - sowohl für ausführbare als auch für fachliche Prozessmodelle - ist sicherlich unbestritten.

Dem Statement, BPMN eigne sich besonders gut für genau den Zweck der Definition von technisch konfigurierten Prozessen kann ich aktuell also nur entschieden widersprechen!

Ich selbst bin der Meinung, dass es eine wünschenswerte Entwicklung wäre, wenn grafische Prozessdefinition für ausführbare Prozesse einem Standard unterliegen würde. Dies ist jedoch eine Zukunftsvision und hat mit dem Standard BPMN 1.x nichts zu tun.

Ein High-Level-Prozessmodell in ein ausführbares Modell zu überführen ist ein kreativer Akt, der sich nicht automatisieren lässt.

Ganz anders hingegen sind vertikale Transformationen. Hier findet eine Verfeinerung statt. Das ist genau das, was Prof. Allweyer in seinem ARIS-Intalio Tutorial beschrieben hat. Es ist auch genau das, was wir bei der IDS Scheer AG (http://www.aris.de/soa/) mit der EPK nach BPEL Transformation passiert. Die EPK enthält keine technischen Informationen wie z.B. Exceptions und diese müssen dann folgerichtig nach der Transformation in BPEL noch hinzugefügt werden.

Fazit: Horizontale Transformationen sind relativ einfach, vertikale Transformation über Abstraktionsebenen hinweg sind es nicht. Das gilt auch für die Automatisierung von Geschäftsprozessen - egal ob mit oder ohne SOA.

Gruß,

Sebastian Stein

Solange ich solche und ähnliche Aussagen immer wieder in renommierten Fachblättern lese, wird mir klar, wie groß der Graben zwischen Business und IT immer noch ist. In manchen Unternehmen hat er bereits die Größe des Grand Canyon erreicht.

Dies gilt leider auch immer wieder für viele Diskussionen zum Thema “SOA versus BPM”

Das Thema Prozessmangement prägt mehr als jedes andere Thema der letzten Jahre das Spannungsfeld zwischen Business und IT.
Allerdings hat auch kein anderes Thema stärker aufgezeigt, wie notwendig der zukünftige Dialog sein wird.
Das Berufsbild des Prozess Manager existiert noch nicht einmal, schon beginnt der unternehmensintere Kampf um die Position des Chief Process Officer (CPO).
Viele beanspruchen diese Rolle für sich. IT, Qualitätsmanagement, Organisation und Unternehmensentwicklung: alle argumentieren, dass Prozessmanagement doch schon immer Ihre Domaine war.
Doch wer wird das Rennen machen? Oder wird diese Situation nur einen Verlierer hervorbringen – das betroffene Unternehmen?
In einem Punkt sind sich viele in Wissenschaft und Wirtschaft einig. Die erfolgreiche Auseinandersetzung mit Prozessmanagement wird für viele Unternehmen eine zwingende Notwendigkeit sein, um sich im immer stärker werdenden globalen Wettbewerb auch zukünftig behaupten zu können.

Die erfolgreiche Implementierung von Prozessmanagement ist also viel zu wichtig, als mit einem Grabenkampf diverser Unternehmensbereiche zu beginnen und damit auch in der Regel erfolglos zu enden. Gefragt sind daher sauber formulierte Strategien und vor allem ein klares, eindeutiges Commitment des Top-Managements.
Prozessmanagement ist ein Management-Prozess und sollte auch so wahrgenommen werden.

Ich denke, hier muss noch einiges an Aufklärung betrieben werden, damit Aussagen wie zu Beginn des Textes zitiert, zukünftig nicht mehr in Fachzeitschriften zu finden sind und die Diskussionen zu SOA und BPM stärkeren Bezug zum eigentlichen Business bekommen.

Sven Schnägelberger

Dem kann ich nur zustimmen. Das Bild, das viele Anbieter von der schönen neuen BPM-SOA-Welt zeichnen, kann bestenfalls als naiv bezeichnet werden. In einem Paper (zum Donwload unter http://kurze-prozesse.de/?p=46) habe ich für einen einfachen Geschäftsprozess einmal die komplette Umsetzung eines fachlichen Modells in eine komplette BPMS-Anwendung beschrieben. Hier nur zwei Erkenntnisse aus dieser (recht mühsamen) Übung:

1. Fachliche und ausführbare Prozessmodelle unterscheiden sich deutlich. Das liegt nicht daran, dass in dem Beispiel das fachliche Modell als EPK und das ausführbare Modell mit BPMN erstellt wurde. Man hätte auch das fachliche Modell in BPMN erstellen können, und es wäre trotzdem noch ein großer Schritt zum ausführbaren Modell gewesen, weil ein ganz anderer Formalisierungsgrad erforderlich ist, weil bestimmte technisch begründete Anforderungen spezielle Strukturen im Prozessmodell erfordern, die aus fachlicher Sicht so nicht benötigt werden (und mit einem anderen BPMS vielleicht anders zu lösen wären). Auch wenn Business und IT beide BPMN sprechen, sind die Modelle der Business-Seite dennoch nicht ausführbar.

2. Der reine Kontrollfluss macht nur einen kleinen Teil einer BPMS/SOA-Anwendung aus. Der ganze BPMN/BPEL-Ansatz ist zweifelsohne nützlich, doch brauchen wir auch Datenstrukturen, Benutzungsoberflächen, Datentransformationen und Mappings zwischen Services usw. Wir brauchen einen ganzheitlichen Ansatz, bei dem alle Aspekte einer Anwendung aus fachlicher Sicht so spezifiziert werden, dass sie möglichst einfach und korrekt umgesetzt werden können. Hier würde zunächst schon ein einheitlicher methodischer Ansatz weiter helfen, der noch gar nicht automatisiert sein muss.

Alles ist neu, alles wird besser!

Das kennen wir. Die Welt der Informationstechnologie hat ein (nicht mehr so) neues Thema. Es heißt „serviceorientierte Architektur“ und verspricht uns endlich von allen Problemen zu befreien. Endlich wird es gelingen, die Betriebswirtschaft mit der Informationstechnologie zu versöhnen. Und da ein wesentlicher Bestandteil jeder serviceorientierten Architektur das genaue Verständnis der zugrunde liegenden Geschäftsprozesse ist, müssen diese zentral betrachtet werden.

Ich möchte kurz Daniel Liebhart vom Schweizer IT-Dienstleister Trivadis zitieren: “SOA stellt Standards und Techniken zur Verfügung, die eine direkte Umsetzung von grafisch modellierten Prozessen in ausführbaren Code erlauben. Wird nun der Prozess oder die Geschäftsregel geändert, so werden die Informationssysteme dank SOA automatisch auf den aktuellen Stand gebracht“. Ähnliche Aussagen verbreiten auch andere namhafte Hersteller und Berater.

Zugegeben etwas vereinfacht, aber als Ingenieur versuche ich das zum Leidwesen meiner Kollegen immer wieder, sollen etwa zukünftig Mitarbeiter ihre Arbeitsprozesse individuell grafisch modellieren, dann die betroffenen Systeme selbstständig auf Knopfdruck neu konfigurieren, neue Dienste kollaborativ im weltweiten Datennetz suchen und verbinden sowie die völlige Flexibilität in der Gestaltung von Abläufen eigenverantwortlich gestalten?

Geht es Ihnen wie mir? Ich höre die Botschaft, aber irgendwo tief in mir drin regt sich ein Zweifel. Die Aussage „das wird niemals gehen“ habe ich mir abgewöhnt, aber ein „das wird so schnell nicht gehen“ muss erlaubt sein.

Die Praxis zeigt, dass zwischen der Vision und ihrer Realisierung heute noch methodische, technische und organisatorische Fragestellungen liegen.

Zitat aus dem Artikel von Herrn Schuhmann: “SOA Technologieplattformen bieten umfangreiche Funktionalitäten für die technische Bereitstellung von Services. Der effiziente Einsatz von BPM Technologiekomponenten ist allerdings wesentlich von der Bereitstellung semantisch integrierter und betriebswirtschaftlich eindeutig definierter Services abhängig. Mit ihrer Hilfe sollen End-To-End Geschäftsprozesse flexibel orchestriert werden.”

Die “Bereitstellung semantisch intergrierter und betriebswirtschaftlich eindeutig definierter Services” ist der Kern des Problems. Viele Versuche in den 90er Jahren mit den Themen Business Process Reengineering und Prozessoptimierung oder -automatisierung hatten alle den gleichen Ansatz: Top Down. Mittlerweile gibt es Menge (auch renomierter) Tools, mittels derer immer wieder eine graphische Modellierung von Prozessen vorgenommen wird. Erfahrungen zeigen, dass diese “Versuche” meist auf der 2 oder 3 Prozessebene enden. Das Resultat ist in der Regel eine Umorganisation des Unternehmens oder bestimmter Bereiche. Keine dieser Massnahmen hat für den Sachbearbeiter eine Verbesserung seiner Situation gebracht. Geht man von dem POS (Point of Service) aus (dem Sachbearbeiterarbeitsplatz) und untersucht mit einem Bottom Up Ansatz das Zusammenspiel von Prozessen und IT-Systemen gewinnt man erstaunliche Erkenntnisse. Man kann sehr schnell fachliche Services identifizieren, die mit Hilfe einfacher Technologien in technische Services umsetzbar sind und das ohne die bestehenden IT-Systeme zu verändern. Ausgangspunkt sind einzig und allein die Dialoge, die der Sachbearbeiter nutzt. Viele Tätigkeiten, die der Sachbearbeiter mit Hilfe von Dialogen in unterschiedlichen Systemen erledigen muss, sind Hilfstätigkeiten, die enorm viel Zeit kosten. Entledigt man den Sachbearbeiter von diesen Hilfstätigkeiten, wie z.B. die Ermittlung eines aktuellen Kontostandes auf dem Vertragskonto des Kunden (dies wäre z.B. ein fachlicher Service), spart man enorm viel Zeit in der Prozesskette. Erfahrungswerte haben gezeigt, dass Einsparungen zwischen 40 % und 70 % möglich sind. Der Qlou des Ganzen liegt nun darin, dass viele dieser fachlichen Services (die ohne IT-Beteiligung identifiziert und umgesetzt wurden) später mit Hilfe der IT in eine technisch korrekte SOA-Welt dauerhaft transferiert werden können. Der erste Schritt wird also im Rahmen von BPM vollzogen und in einem zweiten Schritt nach Bewertung mit Hilfe einer ABC-Analyse mit Hilfe von SOA dauerhaft zur Verfügung gestellt.
Auf diese Art und Weise ergänzt SOA das BPM, aber BPM muss an erster Stelle liegen.
Die Auswahl der Technik (auch wenn viele Hersteller dies nicht gerne hören) spielt eine untergeordnete Rolle. Diese Entscheidung sollte einzig und alleine in der IT-Abteilung liegen, da hier dann ein entsprechendes IT-Mangement aus technischer Sicht erforderlich ist.