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
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.
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
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
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
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