Reasons to love Metastorm BPM version 9 (part 1)

OK, I know I give the product a hard time, but hey, if I don't, who will? The fact is, though, I really do like it, even if some bits could be improved. One aspect of Metastorm BPM that really lights my candle, and those of our customers, is the Visual Scripts. Not because they are easy to create (they are not, I'm afraid), but because the documentation they provide is stunning.

When I first saw the product now called Metastorm BPM, it was in its infancy, its first version on Windows (v3). I thought it was the most amazing way to develop systems I had ever seen. My view on that has not changed in the past 13 years. All that mucking about converting Data Flow Diagrams to code - why not make the diagram itself the code? It was so good a model, it actually remains fairly similar now, albeit with excellent and powerful enhancements such as Linked and Sub-Processes.

Well, now it is mainstream to do this. It is almost expected. Metastorm BPM (e-work in the day) was just the first of a new breed, long before BPM was even a TLA (Three Letter Acronym). The current challenge as far as I am concerned, is twofold. Fistly to integrate with Metastorm's other products, but more importantly for those at the coalface, to improve the development environment.

Well, in the Visual Scripting idea, I think they have done it (make it faster and it will be even better).

Here's why: Imagine I have a complex calculation that relies on a great many inputs and decisions. How would I typically manage this? Well, in the main, in previous versions, by writing a lot of code. In other development environments, such as Oracle BPM, I may use a nifty Business Rules generator. In Metastorm BPM you can always use a 3rd party Rules Engine.

But in version 9 we have Visual Scripting. It is not designed specifically to create Business Rules, but it does the job extemely well, for a number of reasons. Mostly this is because of the ease of communication, just like the Metastorm BPM process maps do, but to an additional level of detail. It is almost like looking at the Process Map, and then zooming in to a step to examine the decisions being made at that step. I do not have to explain the logic as I would have to with most Business Rules engines, it is extremely clear just as it is.

So, in this example, I have complex decisions  and calculations:

(Excuse the blurriness - it is deliberate to avoid giving away any proprietary information. The actual image is over twice as large and perfectly clear.)

I can discuss this with business owners and explain to them exactly what is happening at each step. The ability to expand and collapse groups at will makes this very easy to do 'live' rather than view the script as a whole. Each decision can be examined for validity, and in debugging, each output can be traced to determine accuracy. During development and testing, you can also disable any part of the script at will, and it and all contained activities will not be executed.

Here is a clip:

As you can see, the decisions tree is very clear. When descriptive titles and even comments (that appear as tool tips) are employed, the communication is massively greater than any code can be.

And yet, just as the Process Map that astounded me over a decade ago, this 'decision tree' is not merely documentation, it is the code!

In part two I shall discuss how we make this even better by creating full decision process tracing for primarily testing, and then auditing purposes.