WORKFLOW MANAGEMENT - FROM CHAOS TO SYNERGY

Transcription

1 MANUFACTURING AND PROCESS CONTROL 293 WORKFLOW MANAGEMENT - FROM CHAOS TO SYNERGY Robert T. Leskovar, József Györkös, Ivan Rozman University of Maribor Faculty of Electrical Engineering and Computer Science; Institute of Informatics Smetanova 17; SI-2000 Maribor; Slovenia {RLeskovar, Gyorkos, I.Rozman}@uni-mb.si Abstract: Modern companies tend to maximize customer and employee satisfaction, respect their individuality, and maximize profit and minimize costs and risk simultaneously. They tend to define and optimize their processes, make them human centered and, especially bigger companies, spread their business (products and services) all over the world. Global enterprises and virtual organizations are showing up. The workflow technology, as an answer and a solution to these tendencies, pervades different application domains. Therefore demands for the efficient and robust workflow management system (WfMS) and for the interoperability of existing WfMSs and tools from different vendors are natural phenomena. The Workflow Management Coalition (WfMC), Object Management Group (OMG) and different individual researchers and developers have done much in this direction but there is no general and final solution, yet. Standard architectures are being built and different new methods are being developed which try to satisfy workflow-specific demands. New approaches include also application of intelligent agents and domain content languages on the basis of the Extensible Markup Language (XML). Keywords: Workflow Technology, Workflow Management Systems, Workflow Standards. 1 Introduction Organizations and companies in application domains such as banking, insurance, telecommunication, finance, health care and others have been using special centralized, tightly coupled information technology (IT) architectures, together with proprietary components and tools, for several years. These components and tools could be classified into several groups like document management, image processing, processing, groupware or project support tools. Such applications have greatly increased productivity and provided better services. Despite their success they have also drawbacks which are growing through the influence of distributed, heterogeneous environments where e-commerce and dynamic workflows are placed today. Major drawbacks are unadaptable, hard-coded business policies and information accesses. This is inadequate for today's dynamic business processes where activities and resource allocations have to change at run-time. Second major drawback is isolated application execution. Older applications were developed for the specific platform and operating system to solve specific problems. Occasionally they have used

2 MANUFACTURING AND PROCESS CONTROL 294 simple message exchange mechanisms but they were still isolated information and process islands. 2 Workflow Management Systems Workflow has been proposed to solve the problems mentioned in the introduction. It is intended to separate business process management logic from other application logic like database management systems did with the database logic. This omits the need to rewrite applications when changes in procedures occur. According to the definition, the workflow is the automation of a business process, in whole or part, during which resources, information or tasks are passed among participants for action, according to a set of procedural rules [WfMC-RM, 1998]. As business processes are automated, production can increase dramatically. A workflow system is used for this purpose, namely it is used to define, manage and execute workflows according to the computer representation of the workflow logic. The market for workflow has evolved from requirements across the whole IT industry, with a wide range of products focussed on one or more particular aspects of the overall workflow requirement. This multiplicity of products increases the need for standards within the industry to enable different products to work together and integrate within a consistent overall architecture. Through the global connectivity and e- commerce the world is becoming a huge organization with a spectrum of products and services it offers. Inside this organization there are thousands of departments with different purpose, products, knowledge, services and the IT infrastructure which enables implementation of these entities. Therefore the most needed standards are those for the interoperability of workflow systems. Let us take a look first at the general features of the workflow systems: understandable process definition representation a process definition consists of a network of activities and their relationships, starting and terminating conditions of the process, and information about the individual activities, such as participants, associated IT applications and data, etc. A workflow modelling tool as a part of the workflow system provides on one hand a graphical process view to non-programmers such as business analysts, re-engineering experts, end-users and others, and on the other hand a computer-understandable representation that is interpreted and executed. distributed, heterogeneous architecture workflow systems have to run on multiple platforms since business processes often span across multiple locations (distributed departments of a company, company and its subcontractors, etc.) which generally use different platforms. Because of this the workflow system often employs three-tier client/server architecture. Special stress should be laid on the effective event management service (as proposed in [Eder and Panagos, 1999]) since there are many events and groups of events in the business environment concerning management of time, IT and human resources and costs. data model we can classify workflow data in many ways. In the WfMC workflow reference model (see section 3.1) three kinds of workflow data have been identified: (i) workflow control data - the workflow enactment service

3 MANUFACTURING AND PROCESS CONTROL 295 maintains internal control data to identify the state of individual process or activity instances and to support other internal status information; (ii) workflow relevant data used by both the application and workflow management system; and (iii) application data - used by the workflow application only. user model user model specifies each user's role and thus separates the roles (specifications of capabilities needed to perform a task) from the physical resources, which may change during the workflow enactment. Specific resources that have the required capabilities will be assigned to the task at the process execution time. Often the user model is represented by the organizational structure in the organizational directory. 3 Standards that enable interoperability of Workflow Management Systems 3.1 Workflow Management Coalition and The Workflow Reference Model In August of 1993 major corporations formed a Workflow Management Coalition (WfMC), a non-profit international organization of workflow vendors, customers and analysts with the charter to address the problem of standardization regarding the interoperability of workflow systems and components. The WfMC has identified five functional interfaces to a workflow service as part of its standardization program the Workflow Reference Model (figure 1) [WfMC-RM, 1998]. Specifications of these interfaces represent a firm, general workflow system architecture without implementation constraints regarding workflow service. The core of the Workflow Reference Model is the workflow enactment service. It is a software service that may consist of one or more workflow engines in order to create, manage and execute workflow instances. Applications may interface to this service via the Workflow Application Programming Interfaces (WAPI). Figure 1: The WfMC's Workflow Reference Model

4 MANUFACTURING AND PROCESS CONTROL 296 A variety of different tools may be used to analyse, model, describe and document a business process. Interface 1 defines a common interchange format, which supports the transfer of workflow process definitions between separate products and workflow service. Interface 1 includes a common meta-model for describing the process definition and a textual grammar for the interchange of process definitions (Workflow Process Definition Language - WPDL) and APIs for the manipulation of process definition data. Interface 2 specifies standard workflow management Application Programming Interfaces (API) - WAPI. With the support of these interfaces in workflow products developers can implement front-end applications that need to access workflow services. Interface 3 defines an interface mechanism between workflow management systems and any other application. This mechanism is based on the so-called Tool Agents that can handle the application control and information exchange. They can communicate with applications by using DDE commands, by protocols like OLE or CORBA or any other concept. The suggested interface defines the way a Tool Agent can be used by a workflow application, e.g. a worklist handler or the workflow engine; it does not define a direct application control mechanism. Interface 4 provides an abstract specification that defines the requests and responses that two or more workflow engines must exchange to be capable of supporting processes that interoperate across a network. WfMC has also defined a binding that gives concrete type definitions and message formats for the realization of the abstract specification, using Internet with MIME encoding as the transport mechanism. At the 1998 AIIM show in Anaheim (California), there was a major press event illustrating the capabilities of this interface in a live interoperability demonstration. Specification of the interface 5 specifies what information needs to be captured and recorded from the various events occurring during a workflow enactment. It does not define how the data is stored, but what information is to be gathered and made available for analysis. The purpose of this interface is the ability to use one monitoring application with different workflow services from different vendors. 3.2 Object Management Group and the Workflow Management Facility The submission to the Object Management Group's (OMG) Workflow Request For Proposals from a consortium of 19 companies, backed by 23 potential users of the specification, including the Workflow Management Coalition, is known as the Workflow Management Facility (WMF) [OMG-WMF, 1998]. Ever since it has been published in 1995, 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 [Schulze, 1997]. The Workflow Management Facility specification uses the ISO Interface Definition Language (IDL) to define its core interfaces. By means of these interfaces the workflow engine can be plugged as a component in the different workflow environments and interact with other business objects. The reality is not so simple, though, but firstly it is important that the facility is standardized and adopted.

5 MANUFACTURING AND PROCESS CONTROL 297 The Workflow Management Facility has been adopted in the beginning of 1999 by the OMG. It is a great accomplishment for both the OMG and WfMC members since it achieves the goal of being able to build large-scale, stable and easy to maintain applications in a controlled manner, according to opinions of working groups' members. 3.3 Internet Engineering Task Force and the Simple Workflow Access Protocol In May 1998 a working group was set up to develop a Simple Workflow Access Protocol (SWAP) for use over the Internet. Workflow services provide sequencing of other services, and thereby need a way to start an external generic asynchronous service, and to be told when it completes. SWAP uses the Internet Uniform Resource Identifier (URI) of a process definition to generate process instances, retrieve instance states and for other requests. The process originator may provide the process instance with the URI of an observer. When the process instance is completed it will send an HTTP request back to this URI in order to notify the originator. This allows the originator to be put to sleep, freeing up operating system as well as network resources while waiting for the process instance to complete. Because the service generates a unique process instance object for every invocation of the service, many invocations can be performed at the same time, a very important feature when the service may take several weeks to complete, as is sometimes the case in the long-running Internet applications. SWAP uses W3C's Extensible Markup Language (XML) to provide parameters for the messages sent using the HTTP protocol. Request responses are also encoded using XML. Agreement on the final specification of this protocol is expected in Technologies of influence 4.1 Agent technology applied to the workflow environment Agents have characteristics that are synergetic to circumstances in the organisation [Jennings et al., 1997]. Most important are: (i) distributed, autonomous behaviour for distributed problem solving; (ii) social skills for information sharing, coordination and negotiation; and (iii) responsiveness to changes for unpredictability in the business process and proactively taking of opportunities. Since such agents employ knowledge repository and various reasoning and planning mechanisms they can contribute to the optimization of the workflow and consequently of the business process in the organisation. This may improve the maturity and overall quality of the business process. Another important aspect of agents is adaptability to the demands and individual characteristics of users. They can act as personal assistants (manage schedules, adaptively search for specific information, etc.) and allow humans concentrate on creative work. 4.2 Using Extensible Markup Language as the basis of the workflow language Today there is a trend in different communities to create their common languages on the base of The Extensible Markup Language (XML) [W3C-XML, 1999]. XML makes

6 MANUFACTURING AND PROCESS CONTROL 298 it much easier to develop and deploy new task or domain specific markup, enabling the automation, parsing and processing of such data. It provides its documents (data collections) with the attributes of extensibility, defined structure and validation. Therefore it would be probably useful to define a standardized workflow description language on the basis of XML. In the workflow world there are already many approaches to describe workflow data in XML - in the section 3.2 we have seen how SWAP employs XML; [Eder and Panagos, 1998] expressed intention to use XML for workflow-specific data; etc. XML parsers are already built in some Web browsers. This means that users of a workflow system will be able to connect to the system from any location using the browser and exchange their task information without the need for other applications and tools (they can effectively use notebooks or even PDAs when participating in a workflow). 5 Conclusion Workflow technology is going to pervade through different application domains and, consequently, impact the whole information society. It has many advantages and potentials over traditional, legacy systems but it can also integrate with them. Companies can cooperate effectively by using this technology and this is also the working attitude of the groups and individuals in the next millennium. Competition does not produce such results as the synergy of cooperating environments. It is important that the Object Management Group and the Workflow Management Coalition shape common standards. By the end of 1999 it is expected to see first compliant products from member vendors. The workflow technology is relatively new and pretty sophisticated and needs further research regarding implementation aspects, like distributed task execution and transaction processing. It is useful to integrate it with new, emerging technologies, like Extensible Markup Language, intelligent agents and the new generation of middleware. References [Eder and Panagos, 1999] Eder, J. and Panagos, E. (1999). Towards Distributed Workflow Process Management. Workshop on Cross-Organisational Workflow Management and Co-ordination. San Francisco. California. [Jennings et al., 1997] Jennings, N.R.. Faratin, P.. and Johnson, M.J. (1997). Agentbased business processes management. The IBS Research Group. Intelligent business systems. [OMG-WMF, 1998] Object Management Group. (1998). Workflow Management Facility Revised Submission. [Schulze, 1997] Schulze, W. (1997). Fitting the Workflow Management Facility into the Object Management Architecture. OOPSLA [W3C-XML, 1999] World Wide Web Consortium. (1999). Extensible Markup Language,

7 MANUFACTURING AND PROCESS CONTROL 299 [WfMC-RM, 1998] Workflow Management Coalition. (1998). The Workflow Reference Model and Specifications of its interfaces.