The pain of using a BPM tool

If you lookup the term BPM online, you will either find Business Process Management or Business Process Modelling. As concepts they make sense; In business process modelling, you represent your business process graphically, so that you understand them better, implement them correctly and continuously improve them. Business process management is a more high level ‘holistic management approach’, which I visualize as a master business process which manages smaller business processes. Now what exactly is a business process ? It is a sequence of steps which make your business work (i.e. makes you money). They can be automated (like an ATM/cash machine) or manual (the teller at a bank). It took me sometime to grasp all these definitions (which I hope are correct) because the internet is filled with buzzwords and jargon which no normal human being can understand easily. A lot of companies are selling BPM tools which are supposed to be magic pills that get you into the ‘BPM groove’. There are some open source tools too (jBPM). I have personally worked with two (Biz talk and jBPM) and here are the reasons I think you should avoid them:

  1. Steep learning curve : To make a process work, I have to understand how the system and the editor works. It is hard enough for a developer to understand the system, let alone a business user. The drag and drop and visual representation is a great demo tool. It certainly impresses managers (who ultimately pay for it), but a developer’s productivity just drops.
  2. Non developers changing the process : I haven’t seen one BPM solution do it flawlessly (The business analyst sees that a process can be improved; he moves a box here, re-connects a few arrows and presto job done). Though it doesn’t look like code, right click on the box and you do have to put some code, otherwise it is not going to work. So you definitely need a developer to do it. The best part is that it is neither developer friendly nor business user friendly, just demo user friendly.
  3. Testablity and refactoring : It is virtually impossible to test drive a BPMS. You do have ‘unit test frameworks’ advertised, but most of them are hacks and hard to use. Recently I tried the JBPM one; I ended up writing a lot of glue code and fake workflow handlers to make it work. The deal breaker for me though is refactoring. If the business radically changes it’s mind about how a business process should look, then good luck re-arranging the boxes, because just re-arranging them won’t work, all the variables bound to the boxes also need to be re-arranged. I would prefer the power of the IDE and tests to refactor my business process.

If your application has workflow, then you could try a workflow library (with or without persistent state). It will still manage your workflows without all the bloat that comes with a BPM. If a business user needs to understand the code, then let the business prepare good process flowcharts and the developers translate them faithfully into good domain driven code. Use cucumber style acceptance tests to make bring the developers and business together (I am not a big fan of cucumber style tests, but it is way better than a BPM). If you need business activity monitoring, it is not rocket science to log data into a database, pull it out and use an html table or nice graphing tool to show it. A BPM tool is just something that tries to do too many things and ends up doing all those things badly.For some companies, the reason for choosing a BPM is because, they have been bitten by badly written bespoke code. Buying a BPM is not going to solve the problem because a bad developer can mess up a BPM too(actually more easily because of the steep learning curve). You now have two problems, the BPM tool and the badly configured BPM tool. Buying a BPM tool is like paying for torture.

Advertisements

2 comments

  1. I see the same issues with content management systems or anything involving a graphical workflow editor… It’s programming, but with none of the skill or best practices like source control, automated testing, easy branching etc. Just a disaster waiting to happen… and usually for quite a high price.

  2. Yeah, and usually it is the people who don’t understand these things who make the decision to buy these tools. Once you’ve paid millions for it, then the developers are forced to use it to solve every problem.


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s