Metastorm BPM : It’s not an application development tool

After 2 years of designing a large operational system using Metastorm v7.6, I wanted to reflect on why it’s a bad idea to use Metastorm BPM to build big workflow based systems.

The problem with the finished system is not that it doesn’t satisfy the requirements or doesn’t perform well enough (considering), it’s that it is a maintenance nightmare.  I wrote an article this time last year whilst travelling back home to Holland from being snowed in and which concerned why maintainability is the most important design factor (over and above scalability and extensibility).  Coupled with a ‘big bang’ design approach (over an agile dev approach) and consistent requirement changes, it’s a surprise the system runs in its operational state.

I don’t wish to run the product down, because for small to medium workflow driven applications, it does the job. But, it’s clear lack of object orientation is the biggest single product flaw and when building a big system with Metastorm this cripples maintainability.   A solid design architecture is obviously of major importance.  Basic application architecture fundamentals such as breaking a system design down into cohesive functional ‘components’  that represent ‘concern’ area’s for the application can be difficult to implement.  This is down to the fact that process data is stored in the database per process and passing data between processes using flags can become messy, especially when certain characters are passed using those flags (that Metastorm classes as delimiters).  Sub-processes are then an option, but these also have inherent flaws.

Forms, which again are application components are process specific, so re-use is again suffering and so replication of forms has to be done, further disabling the idea of good maintainability.

Having data repeated in processes and having no code dependency features is bad enough, but because you have to remember where you have used process variables and keep in mind when and where values may change, the tool puts all the responsibility on the developer.  Once the system get’s very large, the event code panels (the ‘on start’, ‘on complete’ etc) get very complicated and tracking variables and when they may change etc becomes a struggle in itself.  Changing a variable value in a large process has the risk of making other parts of the process not work quite right because ‘you’ve forgotten that the variable is used in a conditional expression later on’.

This then begs the question, should you even use the Metastorm event/do this panels for ANY business logic.  I’d say no.  Only UI or process specific logic should be used and you should push ALL of your business logic to server-side scripts and a suite of external .NET assemblies.  You can then at least implement a fully swappable business logic layer.

So along comes v9.  This product is a great move towards stronger application architectures.  OOP design and ability to debug alone save a whole lot of system maintenance time.  So although this version takes us closer to being able to create solid, maintainable operational applications, it was released too early.  It is slow (halving development productivity against version 7), it had many broken features and grids, one of the most used visual components, especially for data driven applications (which is most business apps) were just terrible.  They continue to perform almost independently from the rest of the system and patch 9.1.1 is still addressing grid shortfalls.  Obvious shortfalls which should have been picked up by a thorough QC team @ (OpenText) Metastorm.

The new OOP approach means that designers and developers no longer have to use the ‘Line by line interpreted’ syntax of v7 and can design re-usable components.  So there is a greater case for using Metastorm BPM as an application development tool for fair-sized applications but whilst development productivity is still poor and the designer is still very buggy, it’s not quite there yet.



  1. It is possible to design and develop large worflow system using Metastorm BPM 7.X if you use the ECL with ASP.NET. Using the Metastorm BPM engine, which is pretty stable in 7.6, with ASP.NET gives you the best of both worlds. No more problems with grids, in fact, you can use fancy components like Infragistics. And since it is C#/ASP.NET, you can build it using OOP principles.


  2. Hi Stephen, You make a fine point. Using the ECL to utilize the engine whilst using ASP.NET’s rich UI features makes total sense. The project I quote would of suited that approach. Assuming you’re not putting business logic in your code behind and throwing it into well defined components, this is probably one of the best ways to go if you’ve got Metastorm BPM rather than using some of the out of the box features.

  3. I have to agree with most of what you say. It was definitely released far to early. The fact that after two years they are still fixing issues from the release is poor.

    One problem appears to be that the product is not used enough internally. The ‘eat your own dog food’ approach (as that Steve Balmer?) is required. I tried while I was there, but the only use by the developers was myself and Chris Bell (aka Doogal).

    9.1 is much faster that 9.0, but you still have to keep solution files small, and I find rebooting regularly (at least once a week, daily if you can) on Windows 7 will help enormously. I assume that is because of flaws in the .net layer as well as some bugs in the Designer.

    You really have to know what you are doing, however, as if you do not understand C# you are somewhat lost without very good technical help and design. It is a shame, as a great many very good process designers will move away from the Metatsorm platform. They were the guts of the Metastorm evangelists, so the product will be left relying on technical ability themselves.

    We have looked at BizAgi, Oracle and IBM. All are better technically, so if that becomes the measure, Metastorm will have their work cut out remaining competitive.

    1. Hi Jerome, thanks for your views.

      Yep, in terms of internal testing it is quite shocking how basic features have slipped through as unstable or broken. As for the rebooting, fine point. I restart the engine each week because deployment starts to take longer and longer and post reboot takes about 15 to 20 seconds only.

      Re the C# side of things, I remember reading one of your articles about how this alienated the modellers and business analysts and completely agree with you. You pretty much have to be a developer as a pre-requisite for using BPM now, especially if you want a solid design.

      I’ve been working with Cordys recently and similar to yourself looking into other products, it really shows how much more growth is needed in BPM.


  4. I am starting to use Metastorm BPM 7.6 and ECL with ASP.NET. Can some one point me to some good resources on how to post a form with data to the engine. Currently I have a form created in designer to which people go and fill it and submit it for further processing. I am trying to create the same form in .net and let user submit to the Metastorm engine using ECL API’s. Appreciate some code samples on it will be very help full.

  5. Thanks for all the great comments. We recently upgraded from 7.7 to 9.1, and now working on I would agree with the .Net UI point. We’re currently limited to Metastorm’s UI and I have always found it quite limited and buggy (reason we’re moving to Hoping we can move to a .Net or Sharepoint UI in the future.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s