News: Article: Open source workflow and the BPM-market
This article gives a compact overview of the open source projects, standards and commercial tools on business process management and workflow. The reason for this publication is that a lot of companies are not even aware of the fact that there are open source alternatives for business process management. We give those organisations a start in selecting the open source workflow engine that best fits their needs.
- Posted by: Tom Baeyens
- Posted on: March 19 2003 11:59 EST
See: Open source workflow and the BPM-market
Do you think the mega-$$$ spend on commercial workflow tools are wurthed or would you consider an open source alternative?
- Any Real projects in production by Sam S on March 24 2003 12:52 EST
- OpenSymphony by Sam S on March 24 2003 12:55 EST
- We are using OfBiz by umesh khandelwal on March 25 2003 03:33 EST
- It seems to be working out ok by Dheeraj Ravula on March 25 2003 16:19 EST
- Workflow targets by Pradeep Sekar on March 25 2003 04:38 EST
- Workflow targets by Tom Baeyens on March 25 2003 07:53 EST
- Workflow targets by kurt ostbahn on March 25 2003 11:09 EST
Has anybody used this in real project?
* Does it support transactional Workflow?
I looked at the documentation, they do not seem to reveal much..
I was refering to OpenSymphony
Really ,what market are you talking about?
We are not IBM/EDS/SAP etc. and we haven't seen a market for bleeding edge IT in a while!
I would be interested to know what other tech startups are doing to market their products !
BPEL4WS seems to be emerging as the dominant flow language. It might result in providing portability across orchestration engines (similar to what SQL offered for data management and query).
 BPEL4WS tutorial
Some time has passed, and still there is a fight on the candidates to become a standard language for process definition. In this time BPEL has gained importance, but there are still doubts on which one will become the defacto standard.
Lucas Rodríguez Cervera
BPM is an emerging technology in the market for insurance and specifically commercial insurance where the nature of dynamic workflows is not as routine as the repeatable processes of personal insurance. Claims is a good example of traditional workflow moving toward more advanced forms of BPM, however, the nature of handling submissions is more long term and dynamic in nature, putting some distance between XML based document centric BPM and traditional and transactional "workflow"
After evaluating no of open source workflow engine, we found Ofbiz to be quite suitable as per our needs.
Main thingy is it s support of wfmc, which makes you safe to switch to new product in future if the current product does not satisfy you.
Also lot of other features and at last, the community is quite active.
The WfMC spec has received critisism of being vague. Which results very different engines being able to claim that they support the same standard. So portability would is not really a benefit of such a standard.
When you develop processes for your WfMC-compliant engine, is the separation clear between standard WfMC-constructs and tool-specific constructs ?
Can you give an estimation of the relative part of the tool-specific constructs ?
Has anybody ported a WfMC-compliant process from one engine to another ?
We are trying to build identify a good Open Source engine for a large organization.
Going by the level of maturity, full-functionality, testimonials & activity in the community OFBiz seems to be coming out on top.
A lot of the blurbs for many other projects seem attractive. But when we dig into the documentation further we see a different story.
Are there any real world experiences with any of these products, ESPECIALLY OFBIZ that anyone cares to share?
Thank you in advance
We are using the osworkflow at our office. but we are having to build\
on top of it to meet all our requirement.It is pretty flexible...there in
lies the problem. you will usually need only part of the flexiblity... because it is tempting to use some
of the functionality as a hack when you get into tought design situations. over all its a good framework to build on top of. Build on top of it ..and expose only the fuctionality you need.
Hope this helps
Excellent article!! I think the article serves its intended purpose very well.
Large users of production workflow systems are large organizations (Anything surprising?) where IT departments need to go with known trusted names - worst case, they need someone to hold responsible (SLA) if something goes wrong. This is important since bugs reported in production workflows can directly impact the company's ability to deliver services to customers and hence have direct profitability impact. Open source just does not stand a chance here... (Remember "Nobody got fired for choosing...") Such large organizations would even spend millions of dollars building their own solution, rather than pick up and use something that has already been done under opensource!!
Administrative workflows that can be used by companies on Intranets requires flexible definition of workflows and forms. This is the area that makes me feel that workflow tools have not matured yet. I do not know of a single tool that gives an out of the box intranet solution where you can define workflows, access control and forms using a GUI solution. And if any one is available, it is $$$ more expensive than what an Intranet budget would permit!! Typically, the team comprises of 1 or 2 programmers working for a month to create a hardcoded custom workflow for a specific process. Here is where I'd encourage organizations to use and try out opensource. And based on their experience, they can extend these tools to production systems.
For opensource to have a chance, more and more out of the box solutions should be available for the IT manager to choose from. Without such options, the IT manager would give way to FUD whether the open source app would suit him - esp. since he needs to justify his choice 3 levels up.
If it sounds like commercial solutions have a big advantage - they dont. People who try out solutions without a clear objective and going through a selection process can get into the quagmire of failed implementation much like "EPR" and "CRM" projects. And one failed project and one scrapegoat is enought to keep other IT managers wary of commercial solutions. The way out? - IT managers decide to build hardcoded workflows at a fraction of the cost of commercial solutions!
<quote>"nobody got fired for ..."</quote>
I regret that there are still managers that choose to pay mega-$$$ only to cover their ass (scusi for the bad vocabulary, caused by frustration).
But there's hope. I see more and more companies, especially governments are recognizing the advantage of
1) being vendor-independant
2) having the freedom, provided by the open sources.
The message I want to give to the top-managers is : "don't accept project failures from your middle mgmt any easier if their covered by big brand names."
<quote>create a hardcoded custom workflow for a specific process</quote>
I agree that for the non-IT-companies it is profitable to join the open source initiatives instead of building custom software. I even saw a non-IT company build their own engine from scratch.
<quote>out of the box solutions</quote>
jBpm provides a web-interface for executing processes which can be seen in the demo. Is that what you were looking for ?
<quote>quagmire of failed implementation</quote>
In my opinion, the most difficult aspect of automating business processes is not the implementation of processes in the business process management system (BPMS) but the analysis. I would estimate that for an average process 70% of the development effort is spent on analysis and the remaining 30% on building the process. The extra difficulty originates from the fact that workflow engines are used for integrating the existing infrastructure. If you need to integrate an existing application, you have to know exactly what data-items it stores and in what format the data is provided. Figuring that out often requires reverse engineering of legacy applications. Documenting all these applications together with matching the different formats of the applications is in my opinion the bulk of the work.
I tend to agree with almost every one of your comments - I was voicing the typical tendencies that still exist today in medium-to-large companies. A lot of that is changing, but not fully. As somebody who has always enjoyed doing cutting-edge stuff, I have had to face several several such reasons-for-not-doing-things, or for why-things-will-not-work.
Anyways, to comment on the jBpm demo - yes, you are right. More such stuff, stuff that can be installed on the company's servers and tweaked (Add some jazz with the company Logo, colors, etc) is what is required to get the market moving. I see tremendous opportunity for this category of applications. But Business owners (Non Techies) need to see it and be convinced that it is within their reach to do it the open source way...
> Administrative workflows that can be used by companies on Intranets requires flexible definition of workflows and forms. This is the area that makes me feel that workflow tools have not matured yet. I do not know of a single tool that gives an out of the box intranet solution where you can define workflows, access control and forms using a GUI solution. And if any one is available, it is $$$ more expensive than what an Intranet budget would permit!! Typically, the team comprises of 1 or 2 programmers working for a month to create a hardcoded custom workflow for a specific process. Here is where I'd encourage organizations to use and try out opensource. And based on their experience, they can extend these tools to production systems.
Please take a look at @enterprise. It does exactly what you want at a very low price. It can found at www.groiss.com.
BTW, I have no affinity to the vendor. I just used their product in rather large
We evaluated IBM WOrkflow 3.3 last year in March, Our requiremet was System workflow for backend integration for the Ordering System(Telecom networks). We found that IBM Workflow XML interface was not-so-mature. There were some bugs too and It was costing 250,000$, So we decided to build howme grown solution with specific to out requirements, we were able to do it in less than 3 man months.
It's interesting to read such experiences about IBM Workflow.. it adds another proof that companies rather keep on pushing their own products to get market share on a raising market than trying to create something usable. (See the article at http://tmitwww.tm.tue.nl/research/patterns/download/ieeewebflow.pdf for details).
I work for an ISP, with about 160+ employees. For the past months we've
tried to customize Oracle Workflow for our needs but I really feel terrorized with systems, that:
a) are written in 100% PL/SQL
b) include functions with more than 1000 lines (yeah, in one function)
c) have modules with more than 10k lines
d) print on the output stream of http response directly and it's not even centralized..
e) after about 30 workflow processes finished successfully have some
tables with 15k+ records inside
f) needed about 1-1.5 man-months of work to get their so called
out-of-the-box product working relatively bugfree as many of the interface functions either did not worked or was bugged to hell.
It's real painful to see companies pushing such products using clueless methods with technologies being obsolete for at least 5 years.
Ending the story, we decided to give up on customization and decided to develop a custom solution, building on an existing open workflow engine to speed up our work and reuse code. Time will show how we come along with that project, but our previous try was a clear dead-end.
A couple years ago I tried BEA process integrator. It was terrible, because it was syncronious - the client (application) had to wait (thread was locked) while server handled his reponce. I think it was improved. Another problem was with data flow - all data was (could be) visible and accessable to all participants, because it was declared at the process level with out any restrictions.
Recently I saw their last platform. Again, there is no restriction on data access.
By the way their submitted the JSR to standartized their approach to BPM solutions.
MQSeries workflow was built to be used for People workflow, What i mean by people workflow is that, a process is started and the forms will pop-up to different people in the ogranisation.
* It was not desined to support Distributed transactions(2PC), a requirement for intergration.
* It was not integratable with J2EE applications.
Now with the growing market for System workflow(Application integration) They quickly patched up sth together with their XML API. the IBM Workflow XML API, is the only IBM Workflow API supporting transactions with the help of MQSeries.
I hope thay have fixed the Bugs by now.