ITANA Minutes, August 20, 2009

----------
ATTENDING

Jim Phelps, University of Wisconsin-Madison (chair)
Geoff Boushey, University of California Berkeley
Keith Hazelton, University of Wisconsin-Madison
Paul Hobson, Cardiff University
RL Bob Morgan, University of Washington
Piet Niederhausen, Georgetown University
Steve Olshansky, Internet2
Todd Piket, Minnesota State Colleges and Universities
Gary Prohaska, University of Washington
Rich Stevenson, University of Maryland University College
Sue Sharpton, University of Alaska
Dean Woodbeck, Internet2 (scribe)

----------
ACTION ITEMS

(AI) Jim Phelps will post the University of Washington's workflow requirements document on the ITANA wiki, along with a page to collect comments.

(AI) Keith Hazelton will develop an example of an enterprise workflow system, and add it to the workflow progression document on the wiki, based on his current experience implementing the Oracle access management system.

----------
CARRYOVER ACTION ITEMS

(AI) Keith Hazelton will develop a problem statement concerning the problem of the uncoordinated development of simultaneous/parallel workflow systems at Wisconsin.

(AI) Jim Phelps will add an enterprise workflow logical flow diagram to the wiki.

(AI) Jim Phelps will draft a statement of work for enterprise workflow, based on today's conversation.

----------
ENTERPRISE WORKFLOW @ U WASHINGTON

Gary Prohaska from the University of Washington joined the call to discuss his experience with researching enterprise workflow systems and gathering requirements from potential stakeholders. A draft "generic requirements" document was provided via the ITANA email list.

The research administration office at UWash had a homegrown workflow process, which they realized would not scale. There was also a faculty certification project underway on campus with an interest in a workflow solution. A project team formed to investigate potential enterprise workflow solutions, including gathering requirements and doing a proof of concept.

Washington had already implemented Kuali Student, so the project team was drawn to Kuali Enterprise Workflow (KEW) as a potential solution. The team spent about three months trying to integrate KEW but was ultimately unsuccessful, primarily because of the lack of stability of the code.

The project did, however, collect use cases from each of the identified six business domains, which enabled the development of the generic requirement document.

Because of continuing pressing demands, and the release of Kuali RICE 1.0, the project has been reopened, with one person focused on developing a proof of concept, using a sample travel expense voucher. Assuming success, the next step would be connecting this to the university's authorization system. The plan is to develop a set of roles and an organizational structure for those roles, to be integrated with the workflow.

(AI) Jim Phelps will post the University of Washington's workflow requirements document on the ITANA wiki, along with a page to collect comments

----------
ENTERPRISE WORKFLOW PROGRESSION

Piet Niederhausen reviewed the workflow progression that he added to the ITANA wiki. The document is intended as a high-level overview, allowing an institution to determine where it stands in terms of workflow, and outlining a progression for moving toward enterprise workflow. https://spaces.at.internet2.edu/display/itana/Workflow+progression

Piet developed a list of major components of a workflow solution, to provide an overview for a manager:

• Workflow development
• Workflow repository.
• Workflow engine
• Permissions, roles, groups, and identities
• User interfaces
• System interfaces
• Management processes

He also outlined three levels of workflow, from a single system within a single application, to an enterprise workflow system.:

1. Workflow within a business system
2. General purpose standalone workflow
3. Enterprise workflow

Gary Prohaska mentioned that there are also business systems with hidden workflow systems. That is, they have functions, for example, that will change a status, and there is an assumption that someone will take the next action, but there is no notification system. Keith Hazelton pointed out that there are likely other scenarios in the middle, between #1 and #3. Piet said that, perhaps, this should be presented as a grid, with the scenarios as the X axis and the components on the Y axis.

There was a discussion about the relationship between workflow systems and business processes and that, in fact, workflow is really a subset of a business management process. Piet said that most of the components of a successful workflow solution have to do with business management, not technology.

Keith Hazelton mentioned that Wisconsin is installing Oracle's access management product, which includes an approval process for role and privilege requests, so there is clearly a workflow system with a repository, some type of workflow engine, and system interfaces. He wonders where this would fit on the list of workflow scenarios. (AI) Keith will add a workflow scenario covering this situation to the workflow progression document on the wiki.

----------
FUTURE CALLS

Jim proposed discussions for future phone calls, including Paul Hobson to discuss the workflow national project and the eGov workflow initiative, both in the U.K. Background is available at these URLs:

http://www.productshare.org.uk/pp/publication/results.asp?categoryidproject=5747http://www.workflownp.org.uk/default.asp

He will also work at having someone from the Kuali KEN (enterprise notification system) project on a call in the near future.

----------
NEXT CALL

Thursday, September 3 2009, 2 p.m. (EDT) / 1 p.m. (CDT) / 11 a.m. (PDT)

  • No labels