I've spent a portion of the last year or so looking at executable process applications built through visual modeling of activities and participants. Many of these applications can by styled as either workflow, BPM, or just service orchestration.
The point I would like to make is that drag and drop of icons does not an application make. It takes many varied parts to render an application, one of those is a language expressive enough to actually impart a reasonable chance that the application solves some particular problem, preferably many problems considering the typical investment.
Java, perl, python, C/C++ being languages that have this quality, they are generally composed of things like loops, conditionals, assignment, scope/namespaces, etc.
Subsequently, if a tool that provides executable processes via some visual notation does not support these fundamental primitives, its only recourse is to provide them via one of the above languages or derivative (javascript, something proprietary, etc).
This usually manifests itself as right-click code behind the notation icon.
Personally I believe this is directly opposed to the point of having a visual modeling notation. Without strict discipline (and a 100+ process models), this can lead to significant maintenance headaches.
And does not enable further benefits, like reasoning against dependencies between participants, processes, and systems. For example, if system A is going down for a day, who gets that day off. Or detecting potential deadlocks among concurrent processes.
Hiding portions of the business rules a process embodies in code hidden behind a model icon is not a solution. The rules, relationships, and participants must be explicit in the visual model to justify having the visual model.
I can guess at the reasoning behind this. Namely, if the icon represents a remote service, the those rules are hidden too. In reply I say why aggravate matters. In a perfect world, the models that represent those services will be available, if you are entitled to them, to incorporate into your analysis, documentation, or what have you.
As an aside, what would be nice is the ability to switch between a visual notation (such as BPMN) and a text language (other than XML/BPEL). Here the visual notation can express things important and best suited for visualizing, and the text notation can provide richer features, control, and likely productivity for those who like to type.
Leave a comment