[Favorite]Three levels of abstraction in Collaboration Workflow[NickMalik]
I've been thinking about the levels of abstraction that Martin Fowler defines in software development: a conceptual view, a specification view and an implementation view.
In creating a workflow, there are also three levels of abstraction.
Business Unit View: at this level, a work item can have threads in multiple, cooperating, business units. Communication between the workflow threads may be occasional, and will occasionally be required. However, the most typical workflows through business units is a single (primary) thread that can be reasonably easily understood and diagrammed. For example: Customer company issues a purchase order. Supplier company issues a shipment and an invoice. The shipment goes to the Customer company's receiving department. The invoice goes to the customer company's accounting department... etc. It's a simple graph with a few lines and coordinating components.
One key point for business unit collaboration is that the connecting lines are sometimes documents, but are often just messages. In this context, the difference between a document and a message is that a document stands as a complete encapsulation of a single business request, while a message requires the context of the business request to already exist. For example: a purchase order is, itself, a document. However, a request for status of a purchase order payment is a message.
Business Process View: at this level, a work item follows one and only one thread through a series of interacting steps. The process may begin with a message or document from another business unit, and may end with the generation of one or more messages to other business units. This is the level where audit requirements typically live, and is the primary focus of efforts at Business Process Reengineering. In this view, an item lives in a single stage. Events do not cause an item to move from one stage to another. Instead, the transition out of a stage is expressed as a boolean expression with a series of business rules. For example: the purchase order is approved for transmission to a supplier if it contains a signature from a member of the company whose purchasing authority meets or exceeds the dollar limit on the invoice and if the supplier is on the approved list. It is up to the process to meet the condition. It is not appropriate, at this level, to describe the criteria as a simple event (Joe approved the document).
Work Step View: at this level, an item exists in multiple states in a state machine or petri net. Events serve to move the work item from one state to another, and "gates" can be expressed in the graph showing things like: compensation logic, combination logic (all theads must complete before the item proceeds, etc), and time-related exception logic. This is the level of abstration that most workflow systems, and too many software developers, live at. We get so wrapped up in the details of how a message is read, and what occurs when it appears, that we can quickly and easily forget the existence of all other views.
I plan to expand on each of these views in upcoming blog postings
