ESB and BPM come together

October 22, 2012

Am 17.10.2012 hieß es in Wiesbaden “camunda fox + Mule ESB”. Eine (kostenlose) gemeinsame Veranstaltung von camunda und Mulesoft, in der gezeigt werden sollte, wie sich eine offene BPM-Plattform mit einem ESB sinnvoll kombinieren lässt.
Am Vormittag wurden von beiden Seiten die typischen Einsatzszenarien beider Plattformen bzw. Tools aufgezeigt und demonstriert. Am Nachmittag sollten ein paar “typische Szenarien” für den kombinierten Einsatz vorgestellt werden und in einem Hands-on Workshop Fälle aus der Praxis durchgespielt werden.
Während der Vormittag noch das hielt, was er versprach (es für mich jedoch keine neuen Informationen gab), war ich vom Nachmittag etwas enttäuscht. Nicht nur, dass es nach dem Mittagessen keinen Kaffee mehr gab (!!!), aus den “typischen Szenarien” konnte ich nur ein einziges Szenario erkennen. Schade, etwas dürftig. So zwei, drei unterschiedliche Szenarien hätte ich mir schon gewünscht. Vielleicht kenne ich aber auch schon zu viele Real-Life-Szenarien aus der Oracle SOA Suite Projekt-Praxis, so dass ich mich nicht mehr mit den Standard-Beispielen zufrieden gebe. Der Teil des Hands-on Workshops - immerhin 2 Stunden waren angesetzt - wandelte sich dann eher in ein Frage-und-Antwort Spiel. Auch interessant, keine Frage, aber ich hätte mir gewünscht, mehr von den beiden Tools bzw. Plattformen zu sehen, mehr von Konfiguration, Kombination, Integration, etc.
Etwas überflüssig fand ich die sehr akademisch geführte Diskussion eines Teilnehmers, der unbedingt alles “nach dem Standard (denn BPMN2.0 will ja Standard sein)” lösen und hier BPMN2.0 einige “Fehler” nachweisen wollte. Leider ist das reale Leben ja auch nie “Standard”, sondern von pragmatischen und zielführenden Lösungen geprägt. Uni-Dozenten halt…
Sehr interessant hingegen fand ich, und das spiegelt mal wieder meine “it’s all about communication”-Haltung wider, als Bernd Rücker von camunda davon erzählte, wie lange die Umsetzung eines kleinen Prozesses von dem ersten Workshop bis hin zur Abnahme gedauert hat: Lag die Zeit der reinen technischen Implementierung (und Test) bei ca. 2 Tagen, dauerte der Gesamtprozess rund 2 Monate. Der Grund: Abstimmungen, Änderungen, Diskussionen, Ängste, usw… Tja, mein Reden seit Jahren. ;-)

« Ein agiles Projekt ist kein Ponyhof Wasser in der Wüste - Apache Camel Vortrag bei der JUG Darmstadt »