Views
Workflow is a broad area that is a requirement of nearly every application and service. For this reason, it is essential to bound what one means by workflow. The participants pointed out that workflow is a many-to-many problem that affects almost every “higher-level” use case, as well as program to program interactions. There are production requirements for enterprise interoperability in both the DM and KS projects. There are many consumers of workflow, and many different workflow systems, including the Kuali Enterprise Workflow Engine. It was not clear whether there are many similar workflow systems for a given kind of work, as opposed to many different kinds of workflow services for many different kinds of workflow requirements
Barry Walsh and others contrasted process-to-process workflow, which is relatively more straightforward, bounded, and understood, with workflow that involves human intervention, which is less well defined. Barry also made a corollary distinction between workflow that provides an auditable process and workflow that enables an outcome. The former emphasizes the deterministic repeatability of a procedure; whereas the latter emphasizes the goal-driven flexibility of multiple paths to a solution.
Various participants pointed out that there is a Workflow OSID, and there is the Kuali Enterprise Workflow Engine. Other workflow engines and approaches, such as BPEL are available and applicable.
Specific use cases for workflow interoperability did not emerge during the discussion, although it was clear that workflow systems are needed. Scott Thorne distinguished reusability from interoperability; namely, a project may want to adopt (integrate / reuse) a specific workflow engine, or it may want to solve a many-to-many problem using boundary abstractions such as the OSIDs?.
Workflow solutions depends on solutions to many other requirements; e.g., identity management, messaging, content protection, presentation, etc.
The sense of the meeting seemed to be that workflow is a different interoperability challenge from those involved in repositories, grading and identity management.
Interested Parties in further work on Workflow: George Ward indicated that the DM will be implementing workflow and will have a preliminary service available by late summer. Lance Speelmon and Barry Walsh indicated that IU would have limited availability in the next few months,
Barry Walsh and others contrasted process-to-process workflow, which is relatively more straightforward, bounded, and understood, with workflow that involves human intervention, which is less well defined. Barry also made a corollary distinction between workflow that provides an auditable process and workflow that enables an outcome. The former emphasizes the deterministic repeatability of a procedure; whereas the latter emphasizes the goal-driven flexibility of multiple paths to a solution.
Various participants pointed out that there is a Workflow OSID, and there is the Kuali Enterprise Workflow Engine. Other workflow engines and approaches, such as BPEL are available and applicable.
Specific use cases for workflow interoperability did not emerge during the discussion, although it was clear that workflow systems are needed. Scott Thorne distinguished reusability from interoperability; namely, a project may want to adopt (integrate / reuse) a specific workflow engine, or it may want to solve a many-to-many problem using boundary abstractions such as the OSIDs?.
Workflow solutions depends on solutions to many other requirements; e.g., identity management, messaging, content protection, presentation, etc.
The sense of the meeting seemed to be that workflow is a different interoperability challenge from those involved in repositories, grading and identity management.
Interested Parties in further work on Workflow: George Ward indicated that the DM will be implementing workflow and will have a preliminary service available by late summer. Lance Speelmon and Barry Walsh indicated that IU would have limited availability in the next few months,