Bruce Silver writes about the distinction between workflow architecture and service orchestration architecture, pointing out why it’s important to distinguish between these two process architectures and see how they fit together. If you’re having trouble figuring out the difference between what the former workflow and former EAI vendors are saying, this might help.
He also discusses what’s changed in BPMS to actually make it as agile as the vendors would have you believe that it’s been all along: easier application integration. As he puts in, in the bad old days, when the EAI part of workflow systems didn’t work very well:
If you went to a workflow conference or trade show, any vendor could show you how to build a workflow in 30 minutes using no programming, just graphical drag-and-drop design. So once you bought the technology, why did it take six to twelve months to design and deploy real-world workflows?
There was a huge market for systems integration companies to do all that tricky application integration stuff — I know, because I ran a 40-person version of that model up until 2000, with a crack team that did design, development, testing, documentation, training and installation, all targeted at trying to turn the dream that the workflow vendors sold into a reality. If I hadn’t already got out of that business, I’d certainly be looking to do so now, as the EAI part of BPM gets easier and easier, leaving much less of the complex systems integration that used to drive a huge part of the market.
What I find amazing is that some of the large systems integrators continue to stick their heads in the sand and refuse to buy into the new way of doing things. Even though capabilities exist for much simpler (and therefore faster and less expensive) integration of BPMS with other technologies, the SIs have too much of a vested interest in selling huge pieces of custom code that they’ve written to augment previous versions of various vendor products, and the associated 1000’s of hours of customization that they can sell to the unsuspecting customer. They actually win work based on the premise that if it takes that long and costs that much, it must be good.
Back to the Silver article that started this thought, I also find it amazing when vendors (and therefore, by extension, their clients) don’t make the distinction between the two types of process architectures, and try to sell their legacy technology (usually either workflow or EAI) as if it spanned the entire space. Since most former workflow vendors have hopped on the EAI bandwagon by buying in that capability early, I see the problem more often with the former EAI vendors trying to sell service orchestration as if it were workflow, with only the barest of long-running process and human-facing capabilities. I remember leading a discussion on exactly this topic with a client’s IT group who had selected an EAI product as their BPM corporate standard, and never being able to get through to them that there are really two major classes of process functionality and architectures, only one of which was addressed by the product that they selected. Silver’s article may have helped.