by Tom Baeyens IntroductionIf database systems are like a respected, wise man telling a clear story, then workflow must be a bunch of spoiled brats shouting their own truth at each other. With this statement I would like to point out that workflow management systems are at the very initial phase of the technology hype curve. We are heading for some exciting times in this area. To illustrate this, we can make the comparison with relational database management systems (RDBMS). When talking about an RDBMS in a software development team most people will get the picture and shake their heads slightly up and down confirming they understand what you're saying. When using workflow terminology, the same crowds will shake their heads similarly but this time, every person will have a very different picture.
Figure 1: Workflow vs. RDBMS positioned in the hype-curve One of the observations that form the basis of this statement is the overwhelming number of concepts used. None of the numerous specs and tools in this area is similar. Of course, they tend to overlap but it usually takes a dictionary and an extended concept mapper to compare any 2 of those. A topic that certainly deserves to be included in an introduction about workflow is the relation between workflow and business process management (BPM). The term workflow is used to denote a series of related interactions between people and a computer system. Workflow is more often heard in developer communities. Sometimes, the meaning of workflow is being restricted to the different screens of a user interface. Business process management (BPM) has a broader scope. Where workflow is more often used in a technical context, BPM has a broader scope. It implies also the non-technical issues like analysis, organisational impact, from the viewpoint of a manager. First I start with explaining what workflow management systems are. Then, the advantages of business process management are covered. Next is an explanation of why the workflow market looks confusing at first sight. The main conclusion will be that selecting a workflow management system is the hardest task companies have to face. To give you a solid basis for this task, the core section of this article defines the four layers of a process definition. It describes the common workflow & BPM concepts in a neutral language. At the end, a guided tour along the specs and tools is added. What is a WFMSDefinitionsA workflow management system (WFMS) is a software component that takes as input a formal description of business processes and maintains the state of processes executions, thereby delegating activities amongst people and applications. To get started, lets define the basic terminology: a process definition and a process instance. A process definition is a formal description of a business process or procedure. A process instance is one execution of a process definition. So far so good. But when going one level deeper, we need to be very careful of the language we use. The way to express the steps within a process still hasn't found a common ground yet. That is the major difference between the specs and tools for workflow and BPM.
Another important responsibility of a WFMS is maintaining context information for each process execution. A process context variable -or variable for short- is a variable associated with a process instance. E.g. the start-date of a holiday request, the key of a record in the database, a reference to a document in the document management system, ... Usually the process definition declares the process context variables. Then, at process instance creation time, the variables are instantiated. All mature WFMSs have customisable variable types. Target usageOne option is to use a WFMS as an enterprise application integration (EAI) platform. Currently, in most enterprise environments, the IT infrastructure has various heterogeneous applications and databases running in an intranet. Typically, these applications have a clear purpose when they are introduced in the organisation. Examples are customer management, document management, supply chain, order entry, billing, resource planning... Let's call them dedicated applications. Each of these dedicated applications contain knowledge about the business processes they have to support. The enterprise fits these automated processes of the software components into their overall non-automated business processes. Once such dedicated applications are installed and running, opportunities arise for new feature requirements that span over multiple applications. Enterprise application integration (EAI) is the discipline of implementing software requirements that involve multiple dedicated applications. Sometimes this is only data exchange that requires the implementation of a communication channel between two applications. Dedicated applications incorporate a number of business processes hard coded in the software. You could say that you buy a set of fixed, automated business processes. A WFMS on the other hand has got no prior knowledge of the domain. A WFMS takes a description of a business process as input and manages the executions of the process instances. That makes it much more flexible then dedicated applications but you have to do the effort to create a formal description of the business process. That is why WFMS and dedicated applications are complementary. A WFMS can be used to manage the overall process. As a rule of thumb, you could say use a dedicated application if it supports the processes you need. The first way to use a WFMS that was discussed here is to tie together all dedicated applications and create an EAI-platform with it. A second option where a WFMS delivers high added value is for the development of workflow software that has a lot of people-related tasks. For this purpose, most WFMSs have a very convenient mechanism of creating forms for tasks. This target usage is especially productive in organisations focussing on ISO or CMM certification. Instead of documenting the procedures in a text format, a WFMS allows you to create automated support (e.g. by means of a web-application) of the procedures that are modelled as process definitions. The third option is to embed a workflow engine inside another application. Remember from the first option that dedicated application incorporate a set of fixed business processes for a specific domain. The companies that develop the dedicated applications, can embed workflow engine software inside of their software. The workflow engine is in this case only used as an application component, hiding it from the application users. The main reason for embedding a workflow engine inside an application is for reuse (not reinventing wheels & hot water) and maintainability of the application software. The case for workflowIntroducing workflow in an organisation delivers benefits on the software development level as well as the business level.Easy developmentA workflow management system will ease the development and even more the maintenance of standard enterprise software.
Business process management (BPM)Before you can automate your business processes, the toughest but mostly rewarding task is analysing them and creating a formal description. e-workflow.org has a nice description about the business benefits gained by this analysis.
I think they even missed the most important reason to start using a WFMS: improved support for iterative development. If the business process part of a software system is not easy to change, organisations tend to spend a lot of effort in business process analysis and hope they'll get it right first time. Well sadly enough that is seldom the case as in any software development project. A WFMS makes it easy to deploy new versions of business processes. As a consequence the use of a WFMS enables more efficient and risk-reduced development because the business process software can be developed in an iterative way. Missing linkI really believe a WFMS is the missing link in enterprise development. First of all I want to state that the default way of incorporating business process logic into enterprise software is scattered approach. This means that the logic of the business process is spread over various systems like the EJB-container, database-triggers, message broker and the likes. No need to mention that this leads to software that is not maintainable. As a consequence, these organisations will think of changing their business process software only as a last resort. They often prefer to change their processes to the software. This argument also applies to a larger extend ERP software packages. In a second attempt, suppose we are aware of this problem and really want to centralize all code related to one process. This is fine for one business process, but if you implement multiple processes, you see duplication of code that manages state and process variables. Then in a third approach we could extract the duplicated code and put it in a central library. Well, ... that is actually a WFMS so don't bother implementing it yourself and choose one from the list below.A closer lookWFMS interfacesA WFMS takes process definitions as input. For the moment, think of a process definition as a UML activity diagram, a UML state diagram or a finite state machine. Examples are submitting an expense note, asking a holiday, requesting a quote, ... Then, the WFMS maintains the state and context of the executions of these process definitions. For this, it needs to be informed of state-changes. The state changes of the process executions can be logged for monitoring purposes.
Figure 2: Interfaces of a WFMS
The 4 layers of a process definitionIn the next part, I try to answer the question "What is the content of a process definition?" This synthesis is based on principles and concepts that are used in the models of various specs & tools. It reflects the common ground between most of these models. The content of a process definition can be sliced into 4 different layers: state, context, programming logic and user interface.The state layerThe state layer of a business process is all about expressing states and control flow. Control flow in standard programming languages is derived from Von Neuman architectures. There it defines the sequence of instructions that have to be executed. This control flow is determined by the order in which we write the instructions, if-statements, loop-statements, and so on. The control flow in a business process is basically the same. But instead of using an instruction as the basic element, the basic element in a business process is a state. A state (also known as wait-state) in a process specifies a dependency upon an external actor. The meaning of a state is like "Now system X or person Y has to do something. Wait here until an external trigger of that actor signals the completion of the task." A state defines a dependency on a result provided by an external party. A typical example of a state is an approval step. A state in a process definition also specifies which actor the execution depends on. The names given to these actors correspond with the notion of swimlanes in an activity diagram. With this information the WFMS can extract tasklists, which is the most common feature amongst WFMSs. As said before actors can be people or systems. For the states that require a human actor, the person has to be calculated at runtime by the WFMS. The dependency from a WFMS on the organisational data originates from this calculation. A very interesting article on this topic is 'Organizational Management in Workflow Applications' mentioned in the further reading section. The control flow of a process definition is a set of states combined with the relations between the states. The logic between the states specifies which execution paths run concurrent and which are exclusive. Concurrent paths of execution are modelled with forks and joins, while exclusive paths of execution are modelled with decisions and merges. Note that in most models, every state has an implicit merge in front of it. Often UML activity diagrams are used to model business processes. While it is an intuitive and widespread notation, a major problem poses in the diagram interpretation. In UML activity diagrams, no distinction is made between a state and an action (see 'Why the term 'activity' should be banned) They are both modelled as activities. The lack of this distinction (referred to as the lack of a state concept) is the most heard criticism by the academic community on UML activity diagrams. A second problem with UML activity diagrams was introduced in UML version 2.0. When multiple transitions arrive in an activity (read state), previous versions specified a default merge interpretation. The 2.0 version changed this to a default join, which requires synchronization. In my opinion, the graphical part of UML activity diagrams can still be used to model the state-layer of business processes on the condition that the semantics of these 2 constructs are changed as follows:
During process execution, a token is the pointer used by a WFMS to keep track of the current state of a process. This corresponds to the notion of program counter in Von Neuman architectures. When a token arrives in a state, the token is assigned to the external party for which the WFMS is waiting for. The external party can be a user, a group, or a computer system. Let's define an actor as a user or a system that acts upon the execution of a process. The assignment of an actor to a token is the only occasion where the WFMS needs to access the organisational data. This assignment allows the WFMS to extract task lists. The context layerA process context variable -or variable for short- is a variable associated with a process instance. Process variables allow a process developer to store data during the lifetime of the process instance. Some WFMS's have a fixed set of types, while in other systems, its possible to define your own custom types. Note that variables can also be used to store references. A variable could reference e.g. a record in a database or a file on a network drive. When to use references typically depends on whether other applications use the referenced data. Another interesting aspect related to process variables is how a WFMS turns data into information. Workflow is all about orchestrating the tasks and data between various heterogeneous systems across an organisation. For the human tasks of a business process, the WFMS collects the relevant data-items from the other involved systems like e.g. SAP, databases, CMR-system, document management system. In each human step of the business process, only the relevant data-items are shown that are collected and calculated from these heterogeneous systems. By presenting only relevant data-items, data that resides on the disparate systems is transformed and presented as information. The programming logic layerRecall that an action is a piece of programming logic to be executed by the WFMS upon a specified event that occurs during process execution. With programming logic we mean a piece of software in binary or in source format, in any programming or scripting language. The programming logic layer combines all these pieces of software with the information that specifies on which events these pieces of software need to be executed. Examples of programming logic for integration are sending an email, sending a message on a message broker, fetching data from an ERP-system and updating a database. The user interface layerWhen an actor triggers the end of a state, usually that is the event where data is fed into the process variables. E.g. in the holiday example, when a boss signals to the WFMS that the state 'evaluation' is done, the boss provides the value 'approved' or 'disapproved' into the process. Some WFMSs allow to specify for each state what data can be fed into the process and how it should be stored into the process variables. From that information a user interface form can be generated to signal that requests information from a user. To see an example of a generic webapplication that allows actors to submit generated forms based upon a process definition, you can visit the jBpm online demo.The workflow landscapeExecutional processes versus a WFMSA recent trend in the BPM community is the convergence of specifications about executional business processes. The approach promoted by XLANG, WSFL and BPML converged into BPEL. BPEL is based on interactions (message exchanges). BPEL is defined in the context of a service-oriented architecture. One of the prerequisites is that the services to be addressed are described in a WSDL declaration. BPEL then specifies an XML grammar that can be seen as a programming language to combine control flow with calls to the services defined in WSDL. I see three main differences between the approach taken in executional business processes and state based workflow management systems:
Academic communityThe academic community has the longest track record of involvement with workflow that dates back from the late seventies. The current trend in the research community considers petri nets as the mother of all process definition languages. For petri nets a wide variety of advanced analysis techniques have been described and last year I had the privilege of meeting professor Petri in person at the 2003 conference on Business Process Management. One of the best pieces of research that is made accessible and understandable for a large audience is workflow patterns. Workflow patterns compared a number of workflow management systems and expressed the common process modelling concepts in terms of petri nets.Open source projectsFinally we are getting down to the links of real workflow management systems. This is where the difficult task starts of choosing one. Actually you should be happy: coping with making a choice is better then having no choice at all :-) One of the goals of this article was to explain the basic concepts of workflow so that you are better equipped to perform the selection process. But I realize that comparing workflow systems is one of the most challenging tasks at this moment for software architects. The 3 sources for composing this list were my previous article, the list of Carlos E Perez, and another list by Topicus.
Commercial vendors
Tool catalogs
SpecificationsMichael zur Muehlen has made this fine overview presentation about all the workflow related specifications. I agree with John Pyke and Wil van der Aalst that the standards defined for workflow are still a work in progress. Another argument that points in that direction is the huge amount of overlapping specifications out there. In my opinion, the multitude of specifications and the limited adoption of each of those specifications are because of limited common knowledge about the primitives. You see: workflow is a subject from which you get easily distracted. The distraction occurs when workflow related concepts get mixed up with complementary technologies or concepts. To give a very concrete example: workflow is completely complementary to web-services. You could expose the interface to access a WFMS as a web-service, but its definitely a bad idea to presume that a WFMS *always* has to be accessed through a web-service interface. Some specifications make this presumption. Apart from web-services, other often occurring distractions include email, inter-business communication, web-applications & organisational structure. The first standardisation effort in workflow was the Workflow Management Coalition (WfMC). The WfMC started in 1993. A very interesting publication of the WfMC is the reference model. It defines the interfaces between a workflow management system and other actors. Another piece of work is the XPDL specification. XPDL defines an XML schema for specifying the declarative part of a workflow. In my opinion, the reference model and XPDL are the best specifications
ConclusionI have shown in this article that the workflow market is still young and wild but that there are already solid tools out there:
The conclusion we can extract from all this is that
I hope that I have stimulated your interest in workflow and gave you on the right background for making an effective comparison. Further reading
ThanksA special thanks for Gustavo Maciel Dias Vieira and Jef Vanbockryck for their valuable feedback on the draft versions of this article.
|
The state of workflow
最新推荐文章于 2024-10-10 13:58:41 发布