Tuesday, 29 July 2008

Dates and Calendars

Mike makes a plea for publishing calendars in i-cal format or specifically in Google Calendar. I agree and suggest that owners of calendar information (governments, local authorities, boards) take some care when getting their information 'out there'.
I followed up Jon Udell on this subject and noted that Google's Calendar API makes a good effort at parsing all but the most obscure presentations of event information. If you do publish event details on the web, make it easy for your audience to capture the information into their calendar. You can be really helpful by adding a specific Google Calendar button for the event.

Sunday, 27 July 2008

Business Process Failures

Business Process Failures Examples of business processes that cover the 'normal path' abound and I often come across organisations that will present completed requirement specifications that pay scant regard for exception conditions leaving it to some IT practitioner to make it all up. This may not matter when the computer systems are recording what has happened in business processes after the event, but when there is a BPMS facilitating the end to end process, leaving the exception flows to the end is a risky approach. You are likely to end up with the business operation grinding to a halt.
Bruce Silver provided this useful example of the ease with which the business semantics involved in exceptions can be expressed formally in BPMN. This shows a requirement to undo a hotel booking if the corresponding flight cannot be booked. I loaded this into a BPMN tool (Intalio) to confirm that this fitted with BPMN1.1 and had an executable solution in BPEL. Intalio generates BPEL from the BPMN diagram. To allow it to be executed, I added the Initiator pool which causes a simple UI to be generated for the start of the process.
Unfortunately, at Intalio 5.2 Beta, the "end no flight" compensation end event is flagged as an error "The compensation activity can only be used in an exception flow". I modified the original further, putting the test for success in booking the flight into the subprocess Book Air. This seems a reasonable view of the real life business situation as well.
That did not work either. Perhaps I have misunderstood the meaning of the compensation end event. Looking at some Intalio Reference information the compensation end event is not mentioned, so how about simply failing the subprocess and not trapping the failure.
That does the compensation cancel Hotel on failure of sub-process Book Air, BUT the process fails and the Confirmation task is not executed! Fair enough, there is no handling specified for failure ( I was limiting the changes made to locate the thing that was stopping the compensation). Now add a failure handler on the outer sub-process. I was glad I had one of those, because Intalio does not allow you to put a subprocess around existing elements and I would have had to start again!
Surprisingly that stopped both the failure and the compensation action! HELP!
[Update: This relates to a post on the Intalio forum]

Monday, 21 July 2008

Where do we get our reusable services from?

With an emphasis on process design first, we do have an opportunity to realise the much vaunted reuse of IT components but not if the expectation is that IT will engage with a process diagram and infer all sorts of things about the future of the business. Definition of services belongs out in the business world (this is what we need the service to deliver) not in the builders yard of the IT engineer. In What does SOA mean for the process modeling world? Rick Geneva wrote
In a SOA system, certain parts and pieces are offered as a service to the entire organization. The role of the IT engineer shifts slightly to where their primary responsibility is to create services, and reuse existing assets before purchasing or building new ones. If a service is needed that doesn’t already exist, the first step is to determine if the organization already has a system that performs a similar function. If so, then there are ways to expose an operation (activity) as a service with minimal impact to the surrounding IT environment.
This is all true but it is going a bit far to suggest that when presented with this abstract of a process diagram (from Rick's post)
the IT team should immediately think of providing as Rick suggests ...
1) The request router. 2) the lookup manager service. The lookup manager service would probably be not be directly used by the process. Instead, we would use the lookup manager service as part of the request router. The request router would most likely be created as a generic service that could also handle the manager response.
Implicit in the use of this type of model as a specification of requirements is an understanding of message handling. Routing messages should certainly be part of a generic implementation (in a BPMS solution perhaps) but hardly considered in a single business process. The process analyst is, at best, defining a requirement for a service that will satisfy the Lookup Manager activity in terms of the data available in Receive Request and required in Route to Manager.
A better approach may be for the process analyst to signal the requirement for a more abstract and generally applicable service by renaming Lookup Manager to Apply Business Rules for Routing Message.