Events and Business Processes

Sean McGrarth makes the following point: E-BUSINESS IN THE ENTERPRISE - When modelling business processes, upside down is the right way up:

"In this model, the programmer drives the business process onward, dictating the tempo which applications must follow. There are numerous terms used to describe this approach but my favorite is 'temporally coupled'. Applications must work in lock-step with each other for business process to function as they should.

This is a point solution. Why? Because it only works well when all the applications underfoot are under your control and (preferably) on the same physical network. Under those conditions, temporal coupling is manageable. Costly but manageable. The more general case of course is where not all the applications are under your control and not all on your local network. Web Services on an Extranet or the Internet for example.

To handle the general case of Web Services owned and hosted by other organizations, with the varying quality of service that that entails, programmers need to take a different approach to pan-application business process modelling. Instead of driving business processes programmatically, they need to deal with the fact that they are no longer completely in control. Web Services respond at different rates, they may not be up all the time, they will produce garbled data because somebody changes something without telling you and so on."

This seems natural to me; the ability to centrally model a process, even within a single company, is often an exercise in wishful thinking. Better to describe interconnecting patterns of behaviour and synthesise a view of how the parts work together.

Unless I misinterpret, it seems to me that UML Activity diagrams with Events can be used to model and view the results; what is the best mix of technologies underneath ? And can we generate these (or parts of these) from the UML diagrams?

No comments: