Minutes - ITANA Meeting - July 23, 2009

----------------------
*Attending*

Jim Phelps, University of Wisconsin-Madison (chair)
Marina Arseniev, University of California Irvine
Michael Daly, University of Michigan
Tom Dopirak, Carnegie Mellon
Scotty Logan, Stanford University
Bob Morgan, University of Washington
Piet Niederhausen, Georgetown University
Benn Oshrin, Rutgers University
Todd Piket, Minnesota State Colleges and Universities
Ron Theilin, University of Chicago
Bruce Vincent, Stanford University
David Walker, University of California Davis
Ann West, Internet2
Dean Woodbeck, Internet2 (scribe)

----------------------
Action Items

Piet Niederhausen and Marina Arseniev will add problem statements to the wiki.

Jim Phelps will create a template on the wiki to provide a standardized way to create problem statements.

----------------------
Carryover Action Items

(AI) Jim will work with Bob Morgan to have someone from Washington on a future ITANA call to discuss their work.

----------------------
*Enterprise Workflow*

The new Enterprise Workflow page on the ITANA wiki provides a place to list resources on the topic. Workgroup members are encouraged to add sites of interest, or to post them to the email. list. https://spaces.at.internet2.edu/display/itana/Enterprise+Workflow

Jim will add an item to the wiki to capture methods used to capture complex business processes so that the steps can be reproduced at a later date. This is particularly important for infrequent tasks, like year-end responsibilities.

Piet suggested adding a section to the workflow wiki page to list the problems/challenges of implementing an enterprise-wide system.

The group discussed problem statements in the area of enterprise workflow. Two have been sent to the email list (one from Jim and one from David Huth from the University of Utah). Piet and Marina both agreed to add problem statements; Jim will create a template on the wiki to provide a standardized way to create these documents.

Marina talked about some activity at the University of California Irvine around workflow. UC Irvine uses a portal in which users can aggregate tasks from different campus workflow systems.

Marina also discussed the importance of having a tool that will diagram workflow. UC Irvine uses Autonomy workflow, which has made a significant difference in helping business units and process owners understand processes. Process owners can see the workflow, look at the bottlenecks, and determine how to optimize the process based on the metrics. The tool generates diagrams, shows decision points and responsible parties, and tracks time. This particular tool also allows for running a process simulation.

Piet offered another way to look at this discussion - that workflow is, at least in part, a maturity model around the enterprise. An assessment of this maturity includes a discussion about what needs to be in place in order to implement and operate a workflow system. He suggested building more information on this topic in the wiki.

Jim did an assessment of workflow at the University of Wisconsin almost seven years ago. The outcome was that workflow is not something you buy or build, but something that matures out of a robust middleware environment. In terms of the human elements, there has to a willingness to cooperate, despite having perhaps used different systems in the past. One of the things Wisconsin found, for example, was that it took 31 days to assign someone a net ID. Streamlining this means having only one or two workflows rather than many.

Both UC Irvine and Georgetown are attempting to develop a strawman for a centralized campus workflow system, but finding something that scales is difficult.

Multiple campus hierarchies present another challenge. For example, there is a hierarchy based on HR information, but there are also hierarchies based on the source of funding for positions, and a separate academic organizational chart that may differ from the HR chart. Trying to manage all of those in one system is daunting.

This led back to a discussion about the prerequisites required to document enterprise workflow. See (and add to) the list on the enterprise workflow wiki page:https://spaces.at.internet2.edu/display/itana/Enterprise+Workflow

There was a discussion about whether a portal is a necessary prerequisite for enterprise workflow, as it can serve as a central place to aggregate tasks from various workflow systems. However, a portal can also be viewed as a notification mechanism, much like email or other means (RSS feeds or pushing notices to Outlook, for example). So, the important concept is to have a central task notification method. One of the strongest arguments for an enterprise workflow system is having a central place that tracks tasks to be completed, tasks in queue, etc.

This relates to a discussion from the last call concerning standard formats for status messages - when a task needs action, when it has been placed on hold, or when something has been rejected. Jim has some information about such single points of access and will post them to the wiki. On the email list, there was some discussion about Kuali KEN, which has a standardized messaging process.

The conversation moved to BPEL (Business Process Execution Language). Some wiki pages concerning BPEL seem to have good information, including:http://en.wikipedia.org/wiki/BPELhttp://en.wikipedia.org/wiki/Comparison_of_BPEL_engines

At issue, however, is that BPEL is generic and, in general, there does not seem to be a standard, in terms of sending/receiving messages.

David Walker mentioned that the University of California has discussed how workflow applications might be federated (which is another argument for a common format).

There was also a discussion as to whether there are other groups interested in workflow, perhaps an EDUCAUSE constituent group. There doesn't' seem to be a group within EDUCAUSE, but ITANA members are encouraged to provide information if they know of groups associated with other organizations.

Another area of interest is whether there are different levels of workflow solutions. For example, are there entry-level solutions that may not have a lot of features, but are relatively easy to learn and implement? It would also be interesting to document the entry points to such solutions. For example, if you are interested in a system of routing documents, here is a way to do tht. If you are trying to do something related to identity management, here's a different way.

Another way to distinguish solutions may be their complexity. For example, do you want to implement something out of the box, or have a platform on which you can build? Using a web CMS project as an example, you could implement a small CMS, create a template, and put up some pages relatively quickly. You could also get a large solution and build business processes on top of that, which would take much longer.

This relates to maturity - so the analysis might be, if you need robust workflow in terms of routing documents, for example, this is the maturity level you need to have achieved.

Finally, there was some discussion about the difficulty of integrating vendor applications; and typically they don't integrate at all. Extracting workflows from such systems, for use in a broader system, can be difficult or impossible. It would be nice to work with a group like OASIS to develop standards to allow such integration.

*Next Conference Call - August 6, 2009 - 2 p.m. (EDT)*

  • No labels