Monday, May 14, 2012

On BPM, Workflow, Documentation and BA work

I am currently working on a proof of concept to introduce Camel as Orchestration Engine in our BHUB implementation. While reading through some Camel posts I came across a thread about using Camel for Workflow.

The issues presented by the first poster are not unique to Camel but to the actions of "externalizing workflow logic". In simple words "Debugging gets more complicated". Once again you will notice how experienced developers recommend to put the logic (infamous if/else) in Java beans anyway.

While I see a lot of value for Camel on the Orchestration and Integration side I see as a difficult task (to say the least) to try to use Camel for Workflow. Again this is not unique of Camel. Apache Ofbiz has gone from Workflow engines (state machines) to Messaging (albeit not Camel but just straight seda) to resolve the "externalization dilema".

I believe that we keep on searching the silver bullet instead of having better development processes. The fact that documentation is on the right side of the Agile Manifesto does not mean it is not necessary. I believe the real problem is that Business dictates what has to be done and the developers implement, later Business wants to know what was implemented and the reverse engineering does not sound right of course. As a consequence the development team figures externalizing all the way to expensive BPM implementations (which I have used and in fact built one from scratch using SCXML in the past) should resolve the problem just to realize that debugging is affected and agility is compromised.

How about maintaining plain spoken language (not to say just English as clearly Business speaks not just English) User Stories that are maintained with the gaps as Business introduces new necessities? Is this just telling us we need a Business Analyst ( BA ) in the middle?

No comments: