index_img1.gif Is Metastorm BPM Version 9 productivity as good as is promised?
I was asked this question on a user group recently.
Answer
My first question would be, "What was promised"? To tell the truth, I have pretty much ignored the marketing from Metastorm, and concentrated on ... well, the product itself.
Is it better? Yes. No question. .Net and C# are a great way to go.
Is it more productive (ie faster to use)? Perhaps not, at least at first. It probably never will be as fast as version 4/5/6/7, but it is a more complex beast, and everything can take longer to do right.
Is it more powerful (better / more features)? Yes. With the ability to add custom controls, promised tentatively for 9.1 but I gather delayed while they get it right, the product will stand up to any BPM tool on the market, and well above most. Right now the user interface is still set in version 4/5/6/7, but they were forced to in order to allow upgrading to work at all.
Can you collaborate? Yes, but you need to plan it well. Our training is modular in that we have separate but interdependent modules for Analysts. Developers and Administrators. We think that has never been done before, and it is better than any other we have seen.
So, I have waxed lyrical about the benefits, albeit with a slight loss of development speed. That slight loss is outweighed by the benefits of proper code, syntax checking, promoting of functions, proper Business Objects, strong typing, Intellisense etc, all the things that were seriously lacking in previous versions.
So what is the down side? I mean, I don't work for Metastorm's marketing department, so I can tell you if there is one, right?
Well, the only down side I can see so far is that you need to understand C#, or at least basic 'low level' coding concepts like casting, constructs such as looping and even the favourite C++ shortcut of mine adding a "." after a function call to call a function on the returned object. The difference between pre- and post-increment (++x and x++) and what a tertiary operator is, for example. So many things that are second-nature to developers, but 100% opaque to Process Designers.
One of the main strengths of Metastorm BPM (formerly e-work), was the ability for non-developers to build complete systems that worked, and were very productive. Those people are being marginalised by the need to understand and use C#, IMO. I think that a decade of very proficient and productive Process Designers (Analysts) will be barred from being even half as productive with this new version, and many will not use it at all quite possibly.
What we will have going forward is a load of Process Designers who cannot code, and a load of .Net Developers who cannot design a Process, and very little real possibility of allowing them to collaborate. (see here, for example: http://metastorm.processmapping.com.au/post?id=5150273 )
Our training approach gives these Analysts at least a fighting chance to keep using the product. We do this by showing them how code and Business Process can be kept separate. In effect, I am saying that I think that even this problem can be managed if approached in the right way.
 
<= Return to Articles
next: