workflow_management_system

[moiz7070]

A workflow consists of a collection of activities, which support a specific business Process. Classical examples range from claim management in an insurance company to production scheduling in a manufacturing company to patient care management and support within a hospital. Workflow management is now emerging as a challenging application for active databases.
The Database and Information Systems group at Politecnico di Milano has been working on workflow management for several years, mainly in the context of the WIDE project. WIDE is an ESPRIT project, funded by the European Union, aiming at the development of an advanced and commercial strength workflow management system, integrating workflow management and advanced database technology. The work of the WIDE team at Politecnico focuses on the definition of a conceptual workflow model and language that combines the specification of workflows with access to external databases. A distinguished feature of our conceptual model involves the support for managing exceptional situations that may occur during workflow execution. We have analyzed the different types of exceptions, and we have developed a language, called Chimera-Exc, for defining and managing exceptional situations.
Chimera-Exc is a rule-based language, derived from the object-oriented database language Chimera, also developed at Politecnico within the IDEA project. Chimera-Exc rules follow the ECA paradigm: the event part defines the occurrence of a possibly exceptional situation, the condition verifies that the occurred event actually correspond to an exceptional situation that must be managed, while the action reacts to the exception. Chimera-Exc rules are sensitive to several types of events, including temporal, data, and external events; they can react to them (depending on the state of tasks, workflow instances, and WfMS control data) by modifying workflow data, by notifying messages to workflow agents, or by channging the execution states of tasks and workflow instances. Chimera-Exc rules are set-oriented, and are detached, i.e., they are executed in a separate transaction with respect to the triggering one. Within the WIDE project, we have developed a system, called FAR, that execute Chimera-Exc specifications; the FAR currently runs on top of ORACLE 7.3 and operates within a CORBA environment.
Further research directions involve the enhancment and refinement of a workflow design methodology, the definition of workflow models that enable semantic workflow interoperability and inter-organizational workflows, and the reuse of FAR as a detached rule processor to be used in generic contexts, outside the workflow domain.
List of topics:
• Conceptual Modeling of Workflows
• Management of Expected and Unexpected Exceptions
• Advanced Database Support for Workflow Management
• Semantic Workflow Interoperability and Inter-organizational Workflows
• Methodologies for Workflow and Exception Design
Workflow Management is an integral part of project and task management which affects those along the whole business and project chain. It is currently a hot topic in both industry and research. Workflow management applications span from Lotus Notes, a groupware, which resides close to the user and group collaboration level, to file and object configuration management applications such as ClearCase and Continuous/CM. Workflow is an especially important issue in a design environment as there are constant updates and editing as well as multiple engineers working on the same modules or files. With the recent emergence and deployment of the Internet and Intranets, an extra dimension of distributed processing and collaboration must be considered when designing the architecture of this new brand of applications. Through the research of workflow management applications, we hope to draw inspirations on the essential qualities and characteristics of workflow applications so as to allow us to design and implement one for our distributed design environment.
Detailed Description:
Evolution
Workflow systems have evolved greatly in the past two decades. First generation tools were mainly file-based version control applications such as Source Code Control System (SCCS), Revision Control System (RCS) and Concurrent Versions System (CVS) which supported a check-in/check-out model as well as simple branching. Archives store the contents (files) and meta data, such as user name, tags, comments, etc., for each version of the files.
Then came software configuration management tools, such as ClearCase and Continuus/CM. They provided file transparency and project repository as well as a more extensive versioning system, branching, merging, shared binaries and parallel development capabilities. While software configuration tools related more towards programmers and designers, groupware, exemplified by Lotus Notes, targeted more towards project and group collaboration. Groupware provides capabilities such as a sophisticated messaging system, document processing, database and search support, directory service and access security control.
Characteristics of Workflow Management Systems
After taking an in-depth look into existing applications, we have come up with a set of characteristics that we feel are desirable, if not essential, for a (distributed web-based) workflow management system.
These capabilities include:
• Version Control
• Build Management
• Process Management
• Workspace Management
• Tool Integration
• User Interface
Version Control
• Versioning all file system objects (text, image, binaries)
• Versioning directories, sub-directories and file system links
• Deltas to store and restore changes
• Audit trail of source changes
• Unlimited branching and branch labels
• Visual merging to resolve parallel development
• Parallel development (checkouts, locks)
• Project support (in addition to managing on a file basis)
Build Management
• Compatibility to existing Makefiles
• Automatic detection and generation of source dependencies
• Configuration editing (bill-of-materials)
• Binary Sharing
• Parallel development utilities (e.g. merge and diff)
• Parallel and distributed building
• Load balancing
• Identification of releases
• Recreation of previous releases
Process Management
• Triggers (pre- and post-event handlers)
• Lifecycle/Workflow stages and promotion
• Customizable process model
• Access control, registration and security
• User groups/roles
• Automatic notification of project personnel
Workspace Management
• Rule-based environment management
• Transparent access to controlled files and tools
• Working directories/views
Tool Integration
• Messaging system
• Documentation database and search
• Problem tracking
• Workflow templates
User Interface
• Web Interface (e.g. Java)
• Graphical user interface
• On-line help and documentation
• Application programming interface
Status
We are currently in the process of defining a research project, which involves developing a workflow management application. In addition to drawing from experiences in using and performing product and literature research on workflow applications, we will also try to follow the reference model and terminology endorsed by the Workflow Management Coalition.
The workflow application that we plan to implement should enhance managing the flow, collaboration and administration of projects, especially design, that are performed by people over the Internet with independent platforms and applications. It should also serve as an application for the WELD system as well as contribute to the Design Technology and Wide Area Networks fields of design of distributed design system.
Efficient workflow management :
Workflow management systems (WFMS) have been introduced to support the modeling, execution, and monitoring of business processes. We are investigating various strategies to make workflow management more efficient and robust. One such direction is outlined below.
Predictive workflow management
Workflow engines collect extensive logs of past process executions and make available rich current system status data. The logs are used for auditing and off-line analysis of the system behavior; the current status data are used by the system administrator to monitor current system behavior.
We propose to utilize this information for on-line predictions of future behavior of the system; we investigate ways to use these predictions to manage workflow better. To date, we have proposed to use predictions to minimize the number of escalations during execution of workflow instances; reduce the escalation-related costs when escalations cannot be avoided; and enrich the functionality of WFMSs.
Why Use Workflow Management?
Th aim of using workflow management is to provide a “one-stop-shop” for business printing, graphic services and office consumable items. They dedicated themselves to “partnering” with their clients, providing them with a single-source system for purchasing, managing and distributing these print and office consumables. Outsourcing these functions enables Workflow’s clients to save significant percentages of time and money on the process, rather than solely on the per-piece cost of the products themselves. Doing so allows them to decrease their overhead or re-allocate saved resources to their core business operations.
What is the Workflow Management Coalition?
The Workflow Management Coalition, founded in August 1993, is a non-profit, international organization of workflow vendors, users, analysts and university/research groups.
The Coalition’s mission is to promote and develop the use of workflow through the establishment of standards for software terminology, interoperability and connectivity between workflow products. Consisting of over 285 members, spread throughout the world, the Coalition has quickly become established as the primary standards body for this rapidly expanding software market.
Mission Statement
• Expand the workflow market through increasing awareness for workflow
• Decrease the risk of using workflow products
• Increase the value of customers’ investment with workflow technology
• Better process control - improved management of business processes achieved through standardizing working methods and the availability of audit trails
• Improved efficiency - automation of many business processes results in the elimination of many unnecessary steps.
• Improved customer service – consistency in the processes leads to greater predictability in levels of response to customers.
• Flexibility – software control over processes enables their re-design in line with changing business needs.
• Business process improvement - focus on business processes leads to their streamlining and simplification
Fitting the Workflow Management Facility into the Object Management Architecture:

The OMG Workflow Management Facility:
The Common Facilities part of the Object Management Architecture (OMA) had a placeholder for an architectural component that "provides management and coordination of objects that are part of a work process" - the Workflow Facility.
In January 1997, the Object Management Group (OMG) established a workgroup to create and issue a Request For Proposals (RFP) for this Workflow Facility. After several meetings and intensive discussion, the group adopted a draft of the RFP at the OMG Technical Meeting in March 1997 (Austin/Texas). This draft has been presented to the OMG Architecture Board for approval at the OMG Meeting in Stresa/Italy. With some minor modifications, the final RFP has been issued on May, 9th 1997. The appointment of a workgroup to issue a Workflow Management Facility RFP overturned the Workflow Management Coalition’s initiative to submit their non-object-oriented technology through a fast-track process (RFC) without further discussion.
Essentially, the Workflow Management Facility RFP has two key requirements: Submissions shall provide a semantic definition of a workflow metamodel and specify a set of interfaces for workflow enactment.
The RFP states that the Workflow Management Facility "defines interfaces and their semantics required to manipulate and execute workflow objects and their metadata”. This means that the OMG starts from the assumption that in a CORBA environment, each workflow instance is realized as an individual object that exposes an interface.
Currently, the OMG is very active in finding the right boundaries between the Meta Object Facility (MOF), the Business Object Facility (BOF) and the Object Analysis and Design Facility (OA&DF). It has been decided to take the MOF as a foundation and reference point for all other facilities and this means that the Workflow Management Facility also has to integrate into this overall picture.
According to the usual 4-layer-architecture (see the diagram behind), below the metamodel layer comes the model layer, which in our case is the place for workflow schemas. A workflow schema is a specification of how workflows of a given type should be executed. An example could be a workflow schema for travel-reimbursement. According to the terminology used in the Workflow Management Facility RFP, a workflow schema is a composition of related meta-objects that together represent the semantics of workflows.
The variety of different types of meta-objects depends on the richness of the workflow metamodel. Hence, providing interfaces to create and manipulate workflow schemas is one of the major requirements of the Workflow Management Facility.
Finally, on the lower two levels there are two ways to implement the workflow instances. The first solution is the "classical way", where a generic workflow engine is employed to interpret the workflow schema at runtime in order to create and enact workflow instances. An alternative approach implements workflow instances as distributed objects. Different types of workflow objects need specific workflow object-servers that implement exactly the specified services. Hence, the workflow schemas may serve as a basis to generate skeleton implementations. Considering the 4-layer-architecture, both approaches are equally valid.
A workflow schema is a specification of how workflow of a given type should be executed. An example could be a workflow schema for travel-reimbursement. According to the terminology used in the Workflow Management Facility RFP, a workflow schema is a composition of related meta-objects that together represent the semantics of workflow. The variety of different types of meta-objects depends on the richness of the workflow metamodel. Hence, providing interfaces to create and manipulate workflow schemas is one of the major requirements of the Workflow Management Facility.
Finally, on the lower two levels there are two ways to implement the workflow instances. The first solution is the "classical way", where a generic workflow engine is employed to interpret the workflow schema at runtime in order to create and enact workflow instances. An alternative approach implements workflow instances as distributed objects. Different types of workflow objects need specific workflow object-servers that implement exactly the specified services. Hence, the workflow schemas may serve as a basis to generate skeleton implementations. Considering the 4-layer-architecture, both approaches are equally valid.
Four Layered diagram of work-flow management:

Conclusion:
There has been a proposed a conceptual model (on next page) for the OMG Workflow Management Facility that potentially covers all of the aspects of the RFP. The model is generic since it does not make many assumptions about the workflow metamodel. With the possibility to customize the workflow metamodel, it is also extendable. And finally, runtime-scalability is supported, because the number of workflow-servers, that is workflow schema implementations, may be adjusted with respect to growing requirements.