BPMS are used to automate and/or manage business processes. Since most tasks involved in a business process these days involves some computer system, BPMS invariably requires some kind of integration. The old way of doing this was to hard-wire connections between your BPMS engine and your applications. Leading to tightly coupled, brittle processes that were impossible to change.

Using SOA to expose application functionality in a system independent manner allows BPMS to be layered over your SOA. The processes and the systems are then loosely coupled and easier to change.

Many people lose sight of what SOA is all about. SOA is not an end in itself. It really only has value if it is ised to support higher value functionality such as BPMS, BAM, Business Optimization etc. Doing BPM without SOA is foolish and doing SOA without BPM is probably pointless.

So in turn, IT goes and creates some new terms – WOA, Composite application etc.. Do you think the latest incarnations of BPMS is also an SOA derivative?

My view is that WOA has been pitched as a “backlash” against SOA by people who have rebelled against the complexities of web services. But WOA does represent a different architectural approach to web services in that it embraces web technologies such as HTTP, proxies, caches, URLs, XML etc without adding the extra complexities of SOAP, WSDL and the whole web-services nightmare.

Bottom line is that I think there are many ways to implement SOA – web services represents one approach and WOA represents another approach. Fundamentally they are providing services for consumption by people or systems.

I have earlier written about this here: http://www.soabloke.com/?s=WOA

This is more a failure of IT professionals not positioning of SOA, and in particular vendors saying they are SOA enabled where in fact they just put some SOAP wrappers over the cobol api calls.