Re: [xml-dev] XML design for workflow management?

[Fraser Goffin <goffinf@googlemail.com>]

I think you may be combining several things here that would most
likely be separate aspects of the business process and the technical
solution space ?

In all likelihood the reporting of the claim and the management of
that claim are separate events. I am using the word 'events'
deliberately here.

The first event is a notification that an accident has occurred. For
insurance companies this is often termed as FNOL (First Notification
of Loss) and is a busines event that is notified to one or more
'subscribers'. That event may contain data about that claim (perhaps
including an estimate of the loss, but not necessarily). Equally the
FNOL event 'message' may not have much data in it at all, that is, it
could just contain enough data (like a Policy/Claim No) for the
recipient to retrieve the current 'state' of the process (and its
associated entities) from a Policy/Claims administration application.

Depending on the various rules (you mentioned 'estimated claim amount'
and claim location in your scenario) one or more other events may be
raised and notified. The controller of these might be a business rules
engine/state machine or perhaps a CEP (Complex Event Processing)
engine of some sort, and, as you point out a human workflow
application as well.

The event messages that tie the various applications together to
produce and consume event signals is to my mind a more likely
solution. There are a number of possible implementations, one of which
in the 'web services' space could be WS-Notification, or for a
slightly more agnostic standard something like the CBE (Comman Base
Event) that IBM use (CBE handles both business and technical events).
These provide a standard message format for both the data that relates
to the event itself as well as any associated business payload.
Similarly to the SOAP Envelope, meta-data (headers) and business data
(body) are separate.

Another possible avenue that you may be thinking about is CBR (Content
Based Routing) and perhaps even Itiinery-Based Routing. But from the
scenario you paint above it seems to me better to separate business
rules processing from messaging rather than conflate everyting
together.

Fraser.

2009/4/12 Costello, Roger L. <costello@mitre.org>:
> Hi Frank,
>
> Excellent questions!
>
>> you seem to assume that the workflow software
>> only needs to access the workflow data, and
>> the "tasks" only need to deal with "content" data.
>> But I can easily imagine a "task", not just the
>> workflow software, wanting to look at, for example,
>> location data.
>
> Yes. My thinking is that some workflow data may be replicated in the content section.
>
>> You talk about "workflow management data vice content data" and
>> present two approaches as if it's a given that these are two
>> kinds of data that (a) are easily separable and (b) need to be separated.
>
> Yes. That's what I'm thinking.
>
> You are hinting that the workflow management data does not need to be separated from the content data. The workflow management data can be integrated with the content data, such as this:
>
>    <claim xmlns="http://www.auto-insurance.com";>
>        <ID>49303203-AAD</ID>
>        <estimated-claim-value>$200</estimated-claim-value>
>        <client-location>Denver, CO</client-location>
>        <type>auto</type>
>        <date-of-accident>April 9, 2009</date-of-accident>
>        <date-of-filing>April 11, 2009</date-of-filing>
>        <description>
>          Car failed to stop at stop sign and broadsided
>          the car.
>        </description>
>        ...
>    </claim>
>
> Notice that <estimated-claim-value> and <client-location>, which are data values used to manage the flow of the claim and help determine the resources needed to process the claim, are now intermingled with the content data.
>
> I think there may be disadvantages to this:
>
> 1. There is no separation of concerns. The workflow management data and the content data is all mixed together. Isn't it beneficial to keep things separate so that the workflow designers can focus on identifying the workflow management data and processing it, and the claims designers can focus on identifying the claim data and processing it?
>
> 2. What about data that is workflow-specific? For example, "expected time to process the claim" and "time the claim arrived at inbox" are data values useful to manage claims but are not claim data. Isn't it bad to mix workflow-specific data with claim-specific data?
>
> Do these disadvantages suggest keeping the workflow data and the content data separate?
>
> What do you think?
>
> /Roger
>
>
>
>> -----Original Message-----
>> From: Frank Manola [mailto:fmanola@acm.org]
>> Sent: Saturday, April 11, 2009 7:49 PM
>> To: Costello, Roger L.
>> Cc: 'xml-dev@lists.xml.org'
>> Subject: Re: [xml-dev] XML design for workflow management?
>>
>> Roger--
>>
>> You talk about "workflow management data vice content data" and
>> present two approaches as if it's a given that these are two
>> kinds of
>> data that (a) are easily separable and (b) need to be separated.
>> Could you amplify on your example to explain this?  Personally, I'd
>> wonder about doing this separation, because it means your document
>> design reflects the requirements of a single workflow.
>> Suppose there
>> are multiple workflows that would process the claim at
>> various times?
>> How would you do the separation then?  Or suppose the workflow(s)
>> change(s) so as to require different routing data?   How many
>> different documents do you want to have to change?  Also, you
>> seem to
>> assume that the workflow software only needs to access the workflow
>> data, and the "tasks" only need to deal with "content" data.  But I
>> can easily imagine a "task", not just the workflow software, wanting
>> to look at, for example, location data.  What happens to your
>> scenarios if something like that is required?
>>
>> --Frank
>>
>>
>> On Apr 11, 2009, at 5:06 PM, Costello, Roger L. wrote:
>>
>> >
>> > Hi Folks,
>> >
>> > Consider an insurance claim for an auto accident. It contains
>> > information about a claim, including:
>> >
>> >   - date of the accident
>> >   - damage to the car
>> >   - police report
>> >
>> > The claim is routed - as defined by some workflow process - to
>> > appropriate people and applications for processing. Which
>> people and
>> > applications receive the claim depend on certain values of
>> the claim.
>> >
>> > For example, if the estimated amount to be paid on the
>> claim is less
>> > than a certain amount, a settlement offer is made to the
>> client. If
>> > the estimated amount is greater, then an assessor is assigned to
>> > investigate the claim, and which office is assigned depends on the
>> > location of the client. Thus, these are two of the values used to
>> > manage the claim:
>> >
>> >    - "estimated claim value" is used to determine
>> >      whether the claim should be routed to the "offer
>> >      settlement" task or the "send assessor" task
>> >
>> >    - "client location" is used to determine what
>> >      resources (i.e. which field office) should be
>> >      used by the "send assessor" task
>> >
>> > "estimated claim value" and "client location" are values used for
>> > workflow management. A workflow management system can use these
>> > values to route the claim and assign resources to tasks.
>> >
>> > How do you deal with workflow management data vice content data?
>> > More generally, how do you design XML documents that enable
>> workflow
>> > management?
>> >
>> > I can think of two approaches:
>> >
>> > 1. Header/Payload Approach (i.e. the SOAP approach)
>> >
>> > Store the workflow management values in a header section and the
>> > content in the body section. This approach requires the workflow
>> > management system to have the smarts to fetch the workflow
>> data from
>> > the header section. The tasks must have the smarts to fetch the
>> > contents from the body section. For example:
>> >
>> > <soap:Envelope
>> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
>> >    <soap:Header>
>> >        <workflow-data xmlns="http://www.auto-insurance.com";>
>> >            <estimated-claim-value>$200</estimated-claim-value>
>> >            <client-location>Denver, Colorado</client-location>
>> >        </workflow-data>
>> >    </soap:Header>
>> >    <soap:Body>
>> >        <claim  xmlns="http://www.auto-insurance.com";>
>> >            <ID>49303203-AAD</ID>
>> >            <type>auto</type>
>> >            <date-of-accident>April 9, 2009</date-of-accident>
>> >            <date-of-filing>April 11, 2009</date-of-filing>
>> >            <description>
>> >              Car failed to stop at stop sign and broadsided
>> >              the car.
>> >            </description>
>> >            ...
>> >        </claim>
>> >    </soap:Body>
>> > </soap:Envelope>
>> >
>> > 2. Separate Workflow and Content Documents
>> >
>> > The workflow data is placed in one document and the content
>> data is
>> > placed in a separate document. The two documents are connected via
>> > links. The workflow management system deals just with the workflow
>> > document. The tasks deal just with the content document.
>> For example:
>> >
>> > -----------------------------------------------
>> > Workflow Document (workflow-49303203-AAD.xml)
>> > -----------------------------------------------
>> >
>> >    <Workflow-Data href="claim-49303203-AAD.xml">
>> >        <estimated-claim-value>$200</estimated-claim-value>
>> >        <client-location>Denver, CO</client-location>
>> >    </Workflow-Data>
>> >
>> > -----------------------------------------------
>> > Claim Document (claim-49303203-AAD.xml)
>> > -----------------------------------------------
>> >
>> >    <claim xmlns="http://www.auto-insurance.com";
>> >           href="workflow-49303203-AAD.xml">
>> >        <ID>49303203-AAD</ID>
>> >        <type>auto</type>
>> >        <date-of-accident>April 9, 2009</date-of-accident>
>> >        <date-of-filing>April 11, 2009</date-of-filing>
>> >        <description>
>> >          Car failed to stop at stop sign and broadsided
>> >          the car.
>> >        </description>
>> >        ...
>> >    </claim>
>> >
>> >
>> > QUESTIONS
>> >
>> > 1. Are there other approaches than the two listed above?
>> >
>> > 2. What approach do you recommend?
>> >
>> > /Roger
>>
>>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>