Indiana University’sWorkflow Experiences

Brian McGoughManager Systems Integration

(IU)Kuali Lead Architect

A bit of History

• Workflow first introduced at IU in our legacy FIS system

• Around 2000 management decided to separate workflow from individual applications and make it a service that all applications could integrate with

• Since then workflow evolved to become known as KEW

Workflow Usage at IU

• Currently used for routing and approval of mediated enterprise transactions in:– Purchasing– Human Resources– Timekeeping– Electronic Research Administration

• Altogether over 1.5 million workflow transactions since implementation at IU in 2003

• Also the defacto workflow engine for– Kuali Financial System– Kuali Research System

KEW the product

• Very generic workflow engine at its core– Handles simple and complex routing scenarios– Based on defining Nodes in a routing path– Nodes are responsible for one thing: doWork()– Clusterable, Scalable, Reliable

• Primarily used in Administrative realm for enterprise transactions

• However, potentially applicable for all kinds of workflow related problems, managing processes, and dispatching of work (could potentially be used in grid types of scenarios to dispatch and perform work)

Key points

• Very generic and reusable across different problem domains

• For user related workflow a single action list for the user

• For process tracking, a single audit trail and searching mechanism for processes

• Route log to keep track of where it has been and where it is going