Lotus Notes / Domino Sonstiges > Tools & Downloads

Wenige englische/US Workflow Lösungen? Was nutzt Ihr?

<< < (2/3) > >>

flaite:
In großen Organisationen hat sich das stark in diese sogenannten SOA Engines verlagert. Oracle und IBM (Websphere Process Server) haben dafür angebotsportfolio-bedeutsame Lösungen. BPEL ist eine Sprache zur Beschreibung von Workflows und damit ein Standard. Diese Lösungen sind halt auch in der Administration sehr komplex und eignen sich deshalb weniger für den Mittelstand. Großer Vorteil ist, das Integration von Systemen dank messaging basierter Middleware einfach ist. Wieder: Sofern man eine entsprechende Admin-Abteilung hat. Das wird stark eingesetzt. Praktisch alle java-progger-nahen Consultants von IBM Global Services, die ich treffe, sind recht stark darauf fokussiert.

Am Ende des Tages besteht eine Workflowlösung aus Statusfeldern, authentification/authorization und zeit/event-gesteuerten Agenten. Das bieten heute allemöglichen Plattformen.

Die SOA Engines erzeugen nette Diagramme, die die Kommunikation mit den Fachabteilungen erleichtern.

Ich hab mal vor Jahren ein Workflow Notes-Framework für ein großes westdeutsches Chemie-Unternehmen geschrieben. Der Kunde und ich waren damit eigentlich recht zufrieden. Danach wurd die Organisation einmal kräftig durchgeschüttelt und die neue Kommando-Brücke hatte überhaupt keine Lust, sich mit dem bestehenden Workflow-Framework auseinanderzusetzen. Wir haben das da auch erst für 2 Lösungen implementiert. 

Domino Workflow wird nach meiner Beobachtung in etwa 20% aller Notes-Umgebungen eingesetzt. Und davon kenn ich nur 1 Unternehmen, das es im großen Stil einsetzt. Die haben allerdings ein Beratungshaus, das z.T. auf DWF spezialisiert ist... nachdem IBM Global Services das Projekt fast vor die Wand gefahren haben.

Wünschenswert wäre ein solches Framework, allerdings sollte es gut gescoped sein. Also weder zu allumfassend noch zu simpel. Dürfte schwierig sein, dafür Akzeptanz zu gewinnen, da es eine Menge an organisations- oder Consultant-gebundenen Frameworks gibt (wie Ulrich und Thomas bereits gesagt haben). 

atbits:
Hallo Julian,

jetzt geb ich mal auch noch meinen Senf dazu.
Prinzipiell geb ich meinen Vorrednern soweit recht. Ergänzen würde ich vielleicht, das aus meiner Sicht die Modellierungs-Komponente sehr wichtig ist.

Es gibt zahlreiche WF-Engines, aber nur wenige, bei denen ich den Workflow grafisch modellieren kann und das ist denke ich sehr wichtig, einmal zur internen Doku, aber auch um mit dem Fachbereich reden zu können.

Die freien Java / BPEL Tools machen das ganz gut finde ich, Pavone Espresso auch, bei Gedys und Lotus-WF kann man über die Modellierung streiten.

Wenn sich aus der modellierung automatisch der Workflow ergibt hat man in jedem Fall den Vorteil nicht parallel entwickeln und modellieren zu müssen mit Visio oder Aris oder ....

Grüße David

JulianBuss:
David, ich finde das mit der Modellierung völlig unwichtig für die eigentliche Engine.

Denn ich modelliere / plane meinen Prozess ja im Vorfeld, zusammen mit der Fachabteilung. Dafür nehme ich Visio oder ähnliche Tools.

Erst wenn der Prozess fertig geplant ist, setz ich mich doch an die Implementierung. Und dabei ist eine grafische UI m.E. nach eher hinderlich.

Aber hier haben sicher unterschiedliche Kunden unterschiedliche Meinungen :-)

atbits:
Hallo Julian,

prinzipiell gebe ich Dir das Recht.
Aber es ist doch so, dass kein Workflow einmal modelliert wird und dann für alle Ewigkeiten so bleibt.

Und genau dann ist es praktisch, wenn ich nicht an 2 Stellen Änderungen machen muss, sondern eben "nur" das Workflow-Modell anpassen und das gnaze damit auch gleich dokumentiert habe.

Ich finde das äußerst praktisch, klar bei kleinen Workflows mit einer handvoll Stati ist das alles kein Problem.

Für komplexere Workflows ist das schon schick, auch wenn der Anwender dann in der Grafik sehen kann, wo er sich gerade befindet.

Dass es nicht grafisch evtl. schneller geht steht ja ausser Frage, am schnellsten wäre wahrscheinlich ein Konfig-File, aber dahin will ja keiner ;-)

Grüße David

Thomas Schulte:
Julians Sichtweise ist so ähnlich wie das was ich immer wieder sehe. Bei der Auswahl eines solchen Tools ist die Integration einer graphischen Modellierung des Workflows ein KO Kriterium.

Benutzt, also ich meine wirklich richtig konsequent verwendet, wird es dann seltenst bis nie.
90% des Workflow Designs finden immer noch in den Köpfen der Leute statt. Wenn man wirlich mal mit jemand zusammenkommt, der soweit denken kann, das man mit ihm ein UML Modell oder auch nur ein Ablaufdiagram zeichnen kann und derjenige das dann auch noch versteht, dann ist das an und für Sich schon ein Erfolgserlebnis. Spätestens nach der fünften Kante ist für die Meisten sowieso Schluß. Da hören die dann auf mitzudenken. Und da nützt dann auch kein graphisches Tool mehr.

Was David sagt hat Gültigkeit für die Anzeige des Prozesses. Und da stimme ich ihm zu. Um dem Anwender zu zeigen, wo er gerade ist, macht eine Graphische Aufbereitung tatsächlich bei komplexeren Workflows Sinn.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete