BPM Products Consolidate Functionality For The Future

Posted by Mark Little on Oct 15, 2008

Sections

Architecture & Design,

Enterprise Architecture

Topics

Business Process Management ,

Workflow / BPM ,

SOA

Tags

jBPM ,

BPEL ,

BPEL4People

According to a Dennis Byron, in a recent survey of vendors all BPM vendors agree that "Business process management (BPM) needs to automate all types of business processes.", with distinctions between workflow and straight through processing, internet vs intranet etc. disappearing. What this means is that ...

[...] many of the heritage ERP/ECM suppliers have exposed their workflow and integration features to everyone, not just those “in the know,” in order to provide their BPM functionality. Many of these providers are willing to sell you these capabilities even if you do not purchase their applications. The best example of that mindset change is SAP. The ERP giant says limiting BPM to a part of the software stack “automatically means limiting its potential for real business impact.”

As Dennis writes, those vendors with an integration-server background such as Sun, look at decomposing their once monolithic packages into composite applications to increase the coverage and applicability. As many have noted over the past few decades, the move towards distributed systems (whether composed of services or objects) increases the need for orchestration. Today that makes BPM even more critical. This isn't news because as Joe McKendrick mentioned in 2006:

An important point that needs to made is that SOA is not exclusively an IT initiative. To succeed, ownership of SOA needs be shared by a cross-section of the enterprise. To date, it has not — it has been mainly an IT initiative. SOA will fail miserably as an IT initiative. IT has a role to play in creating, maintaining, and testing service components, but SOA belongs to — and should be driven by — the entire business. Both SOA and BPM need to be viewed and governed as business-led initiatives, or else they will fall into the opposing silos ...

 Back to the original article, Dennis believes that:

IT departments should look at BPM as a “new development paradigm,” grounded in service-oriented architecture (SOA) methodologies. In this view, the goal is to deliver functionality that can be controlled and visualized by business users, and also enable re-use. In this mode, IT is less of a bottleneck when it comes to providing the thousands of industry-specific and even enterprise-ecosystem-specific services.

Tom Baeyens, lead of the jBPM, has this to say on a related topic:

I believe many BPM folks miss insight on general application development to talk about software architectures. In my opinion, applications are developed in silos. Connectivity between application silos is enhanced with the typical SOA, WSDL, WS-* armoury. But BPM is much broader applicable then only on top of services.

Apparently Cordys, mentioned in the entry and related article, is pushing their next generation BPM such that the process layer provides a level of abstraction and ...

[...] removes the processes from the control of applications in much the same way that middleware removed data. But to do this well, Cordys says, BPM must support all the attributes of a business process, which it defines as

• Manage applications in parallel as well as in series
• Manage people-intensive applications
• Decouple the process from the application
• Work inside and outside the firewall
• Allow processes to change over time
• Put the process into the hands of the busines

As we have seen before, others might add different things to that list or even remove them, such as the support for a range of Domain Specific Languages (DSLs), better standards,and better analyst tooling. But one thing that most seem to agree is that how BPM plays with SOA is important. Gartner analyst Mark Raskino had this to say in 2007:

For a business to increase its flexibility the majority of a company needs SOA architecture with BPM functions on top.

But as Steve Jones points out, that is often easier said than done:

To be 100% crystal clear. If you are doing BPM and then just saying "step = service" then you are doing VISUAL Cobol and replacing function calls with service. The fact that you are using WS-* or XML does not make these elements services.

The market is certainly seeing more and more SOA or BPM vendors starting to embrace one another for a variety of reasons. But this does lead to one final question: in 2004 when asked about the future vision for BPM, Scott Dixon Smith, CEO of Lanner Group said:

In ten years time, he sees an executive working on the golf course following the progress of an important order via a PDA. Depending on the outcome, the options would be to either keep playing, proceed to the 18th hole, or call another colleague to help fix the process.

So are we there yet?

1. Back to top

   2nd link : access not granted

   by John Mettraux

   It says "Oops! It looks like you are trying to access a resource to which your access is not granted."
   
   The title of the pdf linked to sounds interesting though.

   Reply

2. Back to top

   Re: 2nd link : access not granted

   by Mark Little

   Sorry about that. Should be fixed now.

   Reply

• Older >