My apologies for the title, but I couldn’t resist…  I was part of a meeting with a very interesting software technology we use internally (AptSoft), and we had a spirited discussion about the role of BPM, the role of CEP, and which is best suited for BAM.  But first, let me expand the acronyms:

• BPM == Business Process Management
• CEP == Complex Event Processing
• BAM == Business Activity Monitoring

Rather than a hypothetical discussion, I want to position each of these in the world of electronic commerce, especially when traditional EDI documents are at issue.

BPM is about “managing the expected” (before I get angry posts from BPM devotees, I do not mean only the “success case”, but the finite universe of expected “paths”, including errors and timeouts…).  Given the way modern electronic commerce plays out, this encompasses most of what goes on.  When a purchase order is issued (say an X12 850, for our purposes), we may expect a response within a certain period of time.  Either the response, or its absence is reasonably predictable, as are the ensuing shipment notice, invoices, RAs, etc.  Although much can go wrong with this business process driven by EDI documents — most of it is predictable, and can be nicely modeled using a BPM tool.

But what it I get a shipment notice for something I didn’t order?  Or what if sales are collapsing (demand) for something that I am ordering?  Or what if a price changes, as sales fluctuate and shipments are late?  Or suppose that not only did Partner ABC not acknowledge my purchase order, but he has not “done anything” for six hours — even though I normally receive traffic from him every 15 minutes (some partners are very needy….).  These situations are examples of problems that are better addressed by CEP, or Complex Event Processing.

My rule of thumb is that if the occurrence is not “likely enough” to be modeled in a process diagram, you should not handle it via business process management.  Also, if you are looking to correlate events across several processes (like a partner suddenly going “dead”, or sending bad data in all of their communications), BPM is likely to disappoint.  The reason is reasoning (pun intended).  BPM tools are following a defined process, and are usually not rules driven.  CEP systems, on the other hand, use sets of rules to analyze and respond to events in context (this means that each event is considered in light of all the events that occurred earlier — where appropriate — and all the subsequent events).  I consider this kind of rules based process to be “reasoning”, which is what enables such systems to respond to circumstances on the basis of “principles” rather than process models.

So given this amazing “reasoning” capability, why not use CEP for everything?  Because BPM’s predictability and clarity are among its greatest virtues.  Having sat with customers and sketched out their business processes on many whiteboards, I would not relish attempting the same exercise by “writing rules”.  Rules engines are deeply enmeshed in mathematical logic, and not necessarily a natural way of thinking for many people.  Also, the CEP system’s very flexibility is not an asset when you are trying to execute the exact same process a few thousand times.  Your auditors (or the government’s) will likely appreciate the predictability of standard BPM.

I firmly believe there is a place in most supply chains for the application of both technologies — but what about business activity monitoring?  BAM is all about seeing what is going on while there is still time to act on it (everything beyond that is more properly data-warehousing…), and that means BAM needs to have data from both BPM and CEP.  “Talking” to BPM systems will let your business monitoring tell you what is going on in terms of the “plan” (on target, delayed, in error, etc) and the micro level, while CEP provides information on the unplanned and the macro level.  Basically, even if you are using a BAM solution that is a component of a BPM or CEP suite, it had better be hooked up to the rest of the world…

I had a call with a client yesterday, who wanted to know what we were doing with web services, and I realized I had not blogged about any of this lately.  We have so much going on in this area that it will take several entries, but the best place to start is interoperability.

A major vision for the GXS Trading Grid is to achieve “preferential integration” with as many software packages and services as possible.  By “preferential integration”, I mean going beyond moving transactions and documents, and having an integrated solution for supply chain collaboration.  Essentially, integrating software and services in problem domains where there are no standards to implement (managing trading partners, tracking documents, tracking the execution of business processes).  As of today, we have realized the first stage of this vision, with the successful automation of important partner management functions.

What has been really interesting is how easily partners can use our web services.  To date we have five implementations in various stages, and they have all been relatively smooth.  Part of why I find this surprising is that the web services are fully commercial, with authentication, authorization, etc.  We provision access to them through the normal process used for all services of the GXS Trading Grid.

The “real interoperability” is a result of our decision to use SOAP, WSDL and WS-Security. 

Many folks like to use REST these days, and for good reason, but in our environment we prefer SOAP.  Much of the REST usage I have seen on other Software as a Service providers has tended more towards the consumer space, and we tend to deal more with enterprise IT or ISV folks.  Both enterprise IT groups and software vendors tend to have access to tools that “eat” WSDL and produce stub code to call services, so SOAP is not issue.  Sadly, few of them leverage the excellent abilities of the scripting languages (Python, Ruby, Perl), but they also use SOAP very well.

WS-Security was more surprising.  I was initially not to sure about our Chief Architect’s decision to use this standard, fearing it might be too complicated — and I was dead wrong.  By using a standard mechanism, we have had no push back from our partners on how we do authentication, which is a first.  On top of that, we are now able to accept WS-Security from partners, and use SAML assertions inside — so our developers don’t need to know anything about WS-Security!  That helpful capability was another great idea from our Chief Architect Jeff Barton, working with a key web services vendor Forum Systems.

So beyond all these acronyms what do I mean by “real interoperability”?  We now have “client” implementations in Java, .NET, and legacy Microsoft C — and none of them required more than about a week or two to complete.  Of even more surprise is that they all seemed about the same level of effort. 

Given the results to date, I think you can count on many more web services interfaces to the GXS Trading Grid.