[ebxml-dev] Automating execution of Biz Processes (& BPSS)....

[Andrzej Jan Taramina <andrzej@chaeron.com>]

Mike cries that the sky is falling:

> In addition, if the BPSS 
> specifies a state that can't be easily matched to an internal application 
> state, then either application modifications are required in order to 
> support the state or the user is forced to intervene and handle that state 
> "out-of-band" as a manual exception.

I don't buy this thinking.  I'm finding, in my ebXML implementation, that the 
public state management (handled by the ebXML BPM engine typically) is 
independent of the back end private state management (handled by existing 
systems and/or Workflow/Choreography/BPM engines). The only requirement 
is that, for any particular B2B transaction (BPSS state transition), you need to 
have an encapsulated back end fulfilment service to make this easier to 
accomplish.

If you wrapper your back end systems as services (think web services, though 
this is not technically a requirement...could be MQ/JMS, EAI integration hubs 
and many other ways) then you can use a Workflow engine (hopefully based 
on a visual/XML based declarative standard like BPML/WSCI once such a 
standard emerges) to create a single exposed "service endpoint" that can be 
invoked by each ebXML business transaction. This works since BPSS 
Business Transactions are considered atomic in ebXML terms, so all you need 
is a single method to fulfill each Biz Transaction.  Since the interface between 
public and private is so clearly delineated, bolting the two together is not a big 
deal (relatively speaking).

In most companies this is not a big problem. They have long had a clear 
separation of public and private processes (manual at times) and have 
managed quite nicely. By definition, most companies have kept their public 
processes distinct from their private fulfilment ones. For those companies that 
have implemented EDI-based trading with partners, they have already 
resolved any mapping issues to a great degree, and the back end fulfilment 
systems are structured in such a way that they can be reused easily in an 
ebXML implementation. There is a lot of benefit to extending the Object-
Oriented concept of encapsulation (black-boxing) beyond services to 
processes, especially in separating the definition of private (internal back office 
systems) and public (B2B systems like EDI or ebXML).  

The current evolution I am seeing in BPM engines (for both private/public 
process automation, possibly even using a single engine for both sides) and 
candidate standard specifications for such processes (public = BPSS and 
private = BPML/WSCI/etc.) leads me to believe that the interface of the public 
and private worlds will not be as difficult as you imply. If you can wrapper a 
private fulfilment process to appear as a single, atomic service invocation 
(pretty easy with things like web services technologies coupled with 
workflow/BPM engines) then it is a straightforward matter to call such a 
service at the appropriate point in the public process.

> This leads me to the conclusion that while the BPSS and the UMM upon which
> it is based may be valuable tools for documenting and agreeing on business
> processes (for those who find ROI in using them), I see little utility for
> them in the near future for actually automating the execution of business
> processes.

Funny....I'm just about finished implementing a complete end-to-end ebXML 
Reference Implementation that starts with graphical/visual modelling of 
business processes using UML, generation of BPSS from the UML model and 
execution of the processes defined in the BPSS (by an automated BPM which 
also invokes choreographed sets of back end Web Services to provide 
fulfilment for the transactions).  And it's working end to end.

I see a LOT of utility in automating description and execution of business 
processes for the following reasons:

1) Doing such allows Business Modellers/Analysts to create and then execute 
new partner-facing processes with a minimum of scarce/expensive IT 
resources (including negative consultants who have a vested interest in doing 
things the slow/costly way. ;-)  ).

2) Maintenance of these production business processes becomes much more 
flexible and faster, allowing businesses to react to competitive pressures more 
quickly and effectively.

3) Writing procedural code to implement business processes is like pouring 
concrete over your processes.  You might have coarse-grained "services" 
exposed, but if you "glue" them together with procedural code, you lose the 
bulk of the flexibility and benefits that a service-oriented architecture brings.  
Better to specify the processes/workflow/choreography using declarative XML-
based approaches (eg. BPSS for public processes, BPML/WSCI for private 
processes) and let a BPM engine do the work of executing the process.

4) One of the key benefits of ebXML is not in the negotiation phase of setting 
up a partner relationship (at least not in the near term).  This will likely be a 
face to face process (think purchasing/procurement departments, contracting, 
etc.) for the forseeable future (especially with large partners).  The CPA will 
just be "yet another contracting artifact" produced by the existing contracting 
process most companies have.  Where the benefit comes in is, by having an 
agreed BPSS and CPA, the two partners can vastly speed up the technical 
implementation process of the trading relationship. This benefit does, however, 
presume service-oriented back end systems (private processes) that can be 
reconfigured in a similar manner (using declarative approaches rather than 
proceedural ones) so that linkage of the front office trading systems (ebXML) 
to the back office fulfilmnent systems (Legacy, COTS, custom) does not 
become a bottleneck.

> Mike (OK - so I still see the glass half empty ;^) )

Hmmm...you sure that is not your brain rather than your glass that you are so 
accurately observing?  ;-)

Mike...why is it that every one of your posts and articles is always so negative?  
Pointing out shortcomings and issues is not a bad thing....if accompanied with 
suggestions as to how to improve matters, something I do not recall you ever 
doing.  Standing from afar and just casting stones is not very productive, and 
is likely to find some boulders flung your way before too long.


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com