A Phased Deployment of a Workflow Infrastructure in the Enterprise Architecture Raf Haesen1,2 , Stijn Goedertier1 , Kris Van de Cappelle3 , Wilfried Lemahieu1 , Monique Snoeck1 , and Stephan Poelmans2 1
Department of Decision Sciences & Information Management, Katholieke Universiteit Leuven, Belgium
[email protected] 2 Vlekho Business School, Belgium
[email protected] 3 KBC Bank & Insurance, Belgium
[email protected]
Abstract. Many organizations migrate to service-oriented architecture (SOA) since it caters for the demanded flexibility and reusability in information systems. Besides delineating appropriate business services, a mechanism for coordinating these services is needed to support business processes. The current state-of-the-art falls short in realizing that goal since existing standards and software packages tend to neglect existing enterprise architectures. Moreover they assume a central position in the architecture from which they control all services according to prescriptive process models, which makes them rather useless in a realistic setting. Therefore we introduce four dimensions to classify workflow engines that reflect the degree of support for the presented requirements. Subsequently we combine these dimensions to describe a phased roll-out of a solution that fulfills the requirements. That solution is currently deployed at KBC Bank & Insurance Group.
1
Setting the Scene
This paper presents some practical viewpoints on the introduction of workflow management as we derived them at KBC Bank & Insurance Group, hereafter called KBC. The financial group is one of the top three bank-insurers in Belgium with a key position in Central-Europe. It has chosen to adopt a SOA approach as an enterprise-wide architecture that is able to support the bank’s internal and external growth for the next decade. While most existing functionality is currently transformed into services, automated support for the coordination of these services is generally missing. KBC has set its eyes on workflow management as a key enabler of such coordination. At KBC, as in many organizations, enterprise systems are designed according to a layered architecture. When distributed systems where not yet feasible, all layers were present on one single back-end, such as a mainframe. In Fig. 1a, the presentation layer represents access to the business logic layer via a terminal. A. ter Hofstede, B. Benatallah, and H.-Y. Paik (Eds.): BPM 2007 Workshops, LNCS 4928, pp. 270–280, 2008. c Springer-Verlag Berlin Heidelberg 2008
A Phased Deployment of a Workflow Infrastructure
271
With the advent of Internet technology, browser-based clients could be installed virtually everywhere while still using the same mainframe. In order to ensure robustness and consistency, the mainframe continued to support the two-phase commit protocol of transactions. Therefore additional layers were added between the presentation and business logic layer to maintain session state during the execution of one activity that spans multiple transactions. On the one hand, the presentation logic layer maintains the screen flow, while on the other hand the assembling logic layer establishes the connections with the mainframe. These layers are typically realized using a web application server, which is illustrated in Fig. 1b. Business Component Presentation layer
Front−end (browser)
Presentation layer
Presentation logic layer Mid−tier (web application server)
Back−end (mainframe)
Business logic layer
Assembling logic layer
Back−end (mainframe)
(a)
Business logic layer
(b)
Fig. 1. Architecural layers
The construction of enterprise systems as presented in Fig. 1 clearly adheres to the principles of Component Based Development as presented by Herzum and Sims [1]. Indeed, each business component – itself being composed of distributed components – represents an integrated business concept that interacts as a whole with other business components. SOA goes one step further, in that it also governs interactions across the layers of each business component, by exposing the functionality in each layer as services [2]. This reasoning shows that it seems feasible to deduce services that encapsulate business data and associated business logic (called business concept services) and services that support single activity types (called activity services). Services that support the coordination of multiple consecutive activities are generally missing. These services are called workflow services. Workflow services are the main point of interest in the remainder of this paper that is structured as follows. Since it is important to clearly define all workflow relevant terms, these terms and their definition are summarized in section 2. Section 3 elaborates on the stringent yet realistic business requirements
272
R. Haesen et al.
concerning workflow management, for which current approaches do not offer a satisfying solution. Section 4 introduces four basic dimensions to classify workflow engines, which reflect the degree of support for the presented requirements. Subsequently, these dimensions are used in section 5 to derive a phased introduction of a workflow management system that satisfies the requirements. Finally, section 6 compares our results with some related work and section 7 presents some conclusions.
2
Relevant Terminology
The same workflow-related terminology is often used in many different contexts with different meanings. In this paper we provide a classification of workflow systems. It is therefore important to agree on the meaning of a number of terms that are relevant to workflow. Although the Workflow Management Coalition (WfMC) provides a good starting point [3], several definitions had to be modified for two reasons: firstly, the WfMC standards mainly focus on user-interfacing processes enacted by means of task distribution while they tend to neglect actor autonomy and straight-through processes, i.e. processes that do not require human interaction. Secondly, the definitions generally lack consistency since, for example, the definition of a term is often copied (sometimes with small modifications) in another definition instead of referring to that term. – A business process is a set of one or more activities that collectively realize a business objective or policy goal, normally within the context of an organizational structure defining organizational roles and relationships. – Workflow is the computerized facilitation or automation of a business process, in whole or in part. – An activity is the description of a piece of work that forms one logical step within a process. An activity may be a manual activity, which requires an actor, or an automated activity, which may require an actor (userinterfacing activity) or not (fully automated). – A process instance (activity instance) is the representation of a single enactment of a process (activity), including its associated data. Each instance represents a separate thread of execution of the process (activity), which may be controlled independently and will have its own internal state and externally visible identity, which may be used as a handle, for example, to record or retrieve audit data relating to the individual enactment. – A workflow participant is a resource (actor or system) that performs an activity instance. – An actor is a person who fulfills one or more organizational roles. – Workflow relevant data or context is data that is used by a workflow engine to determine the state transitions of a process instance and activity instance, for example during the evaluation of transition conditions or during workflow participant assignment. – Workflow control data is data that is managed by the workflow engine. Such data is internal to the workflow engine and is normally not accessible to applications.
A Phased Deployment of a Workflow Infrastructure
273
– Process instance state (activity instance state) is a representation of the internal conditions defining the status of a process instance (activity instance) at a particular point in time. Most workflow engines maintain such status information as part of their workflow control data. The process instance state can generally be derived from the state of the activity instances of which the process instance is composed. – A state transition is the change of one process instance state (activity instance state) to another process instance state (activity instance state). – A transition condition or process rule is a logical expression that decides whether a state transition can occur or not. – A work item or task is the representation of an activity instance to be processed by an actor. – An organizational role is a collection of attributes, qualifications and/or skills that can be used for authorization or to identify a specific party in a process. – A workflow engine is a software service or component that provides the run time execution environment for process instances. It interprets the process definition and interacts with workflow participants. – A workflow management system (WFMS) is a system that defines and manages workflows (build-time) and enacts these workflows by means of one or more workflow engines (runtime).
3
Business Requirements
At KBC, as in many information-intensive organizations, the introduction of a vast number of information systems, tools and frameworks creates a complex and heterogeneous environment. Nevertheless, this environment contains many valuable and expensive assets that can not be simply dismissed. We now elaborate on three requirements that are particularly prevalent in such a context. The first requirement encompasses process modeling flexibility while the latter two take an operational point of view. Firstly, it is generally impossible to model the exact control flow of many processes due to their complex nature. This certainly applies to unstructured processes in which interaction with human actors is required. It is rather complex to explicitly model a set of activities that can be performed in an arbitrary order by the actor. Moreover, it is not always possible to predict every event that might influence the process. On the other hand, structured processes, such as the ordering of office supplies, are suited to be explicitly modeled. Since straightthrough processes do not involve any human interaction but only information systems, explicit process models are appropriate to describe these kinds of processes as well. Secondly, an important yet seldom discussed topic about workflow management systems (WFMS) is the position they assume in the existing enterprise architecture. As discussed in section 1, an average information system already
274
R. Haesen et al.
contains – hopefully neatly separated – services that execute business logic, manage business data and offer support for the execution of activities. Nevertheless, a WFMS usually enforces the design of proprietary user interfaces. This is reasonable since the WFMS then has complete control over which data is entered during which activity. However the value of an in-house user interfacing framework is often too high to be abandoned. Moreover, third-party software packages (such as ERP and CRM packages) commonly cover multiple architectural layers of multiple business objects that also have to coexist with a WFMS. Finally, even if a WFMS can operate in a heterogeneous environment, it will still require a central position in that every activity must be coordinated by the engine. This way the workflow engine can successfully maintain the state of its process instances. Again, this is an undesired situation for two reasons: firstly it should also be possible to perform activities without being guided by a workflow engine, especially for unstructured processes. For example, a senior claim handler with many years of experience knows which activities he has to perform to handle a claim without the assistance of a workflow engine. The obligation to follow a predefined path of activities might even be counterproductive. A second reason reinforces the need to work outside the context of a workflow engine: an actor must be able to perform activities if the workflow engine (temporarily) fails. This allows the workflow engine to be installed on less critical machines with lower Service Level Agreements.
4
Positioning Workflow Management Systems
Existing workflow management systems fail to support the presented business requirements because of their particular view on the modeling and enactment of processes. This section proposes four basic dimensions that can be used to classify these views. On the basis thereof workflow management systems can be assessed. 4.1
Process Modeling Paradigm: Procedural Versus Declarative
In a classical procedural approach, a business process model is much like a script since it contains explicit, prescriptive information about how processes should proceed. The most prominent example of a prescriptive process description standard is BPMN [4], which mainly focuses on the temporal ordering of activities: the resulting process models (only) show when an activity can be executed, depending on preceding activities and some conditions. The main advantage of these process models is that they can easily be interpreted by humans. However, the disadvantage of these languages is that they assume an explicit, often over-specified process context that leaves no freedom to maneuver at execution time. Consequently, business processes need to be modeled explicitly to the greatest level of detail. In practice, the explicit modeling of business processes is a work of gargantuan proportions. In a declarative approach, business processes are modeled using declarative languages. Such languages contain descriptive information about the constraints
A Phased Deployment of a Workflow Infrastructure
275
that govern the activities in business processes. A minimal yet sufficient set of constraints leaves as much freedom as is permissible at execution time for determining a valid and suitable workflow. Instead of (over-)specifying when a condition must be evaluated, constraints are like invariants that should always hold. The general advantage of this approach is that known process constraints can be predefined at design time whereas requirements that cannot be anticipated are dealt with at runtime. On the other hand, it is generally not straightforward to check whether a set of constraints is complete and correct. 4.2
Degree of Centrality: Middleman Versus Optional
One of the key questions is to which degree the workflow engine will participate in the actual business processes. The two extreme options are the workflow engine as the middleman and the workflow engine as an optional component. A workflow engine behaves as a middleman if no change can occur in any system by any workflow participant without intervention of the workflow engine. Hence such an engine knows all process definitions, all possible events, all actors, all systems etc. Its main advantage is that everything is under control of the engine and no-one or no system can make mistakes or overrule business regulations or policies. On the other hand it has several disadvantages: firstly, many processes can not be managed by a middleman, because it is impossible to define every possible path, including all events that may impact a process. Secondly, many information systems can not participate in a controlled environment like this. Finally, the explicit modeling of all scenarios and exceptions makes the solution too expensive. Benefits will never reach the level of investments. A workflow engine is optional if it is perfectly possible to perform activities without informing or being guided by that engine. The decision to use the engine is left to the actor or may depend on the role of the actor. This option is superior since it does not restrict all access to the information systems to one central point. However, this type of engine is only capable of returning possible activities that can be executed. Other types of process rules that must be obeyed, such as authorization rules, must be moved to the activity (service) level since they are not automatically controlled by the engine. 4.3
Statekind: State-Unaware Versus Stateful Versus Stateless
A workflow engine can be state-aware or state-unaware. A workflow engine is state-unaware if it manages no process instances, but merely knows all process definitions. All information about a concrete process instance must be provided as input. A state-aware workflow engine on the other hand manages process instances. To do so, the engine can work in a stateful or stateless mode. A workflow engine is stateful if the state of process instances is maintained as part of the workflow control data, i.e. if it resides in the workflow engine itself. It is a huge challenge to keep the state in the workflow engine synchronized with reality. In fact, this is only possible for workflow engines that act as a middleman, i.e. when all activities are covered by the engine. This is impossible
276
R. Haesen et al.
when any business object, referenced by a process instance, can be changed by other instances or activities that might not be under control of the workflow engine. Moreover it is unlikely that it is possible to define all possible events, although this is the only way to ensure that the state is correct. A workflow engine is stateless if the state of process instances is derived from the state of business data, i.e. one or more business objects. Every time the workflow engine has to determine the next possible activities, it reconstructs the state through the use of business concept services. This can be seen as the extension of one of the key principles of the case handling paradigm [5] that states that an activity is completed if the associated mandatory data objects are entered. Although this approach allows the execution of activities outside the control of a workflow engine, it has some disadvantages. Firstly, the reconstruction of state can create serious performance issues. Assume for example that the workflow engine only knows the claim case ID. To reconstruct state it has to query all objects, damages, parties, etc. involved in this claim case to collect their attributes. Therefore it might be better to add “meta-state” to a business object that explicitly indicates the state of that object. For example, the state of an order (requested, shipped, paid, etc.) can be added as an attribute of order. On the other hand, this creates the danger of moving process information in the business objects, only for the sake of the process. This must obviously be avoided since it impedes process flexibility. Secondly, there is a concurrency issue: if multiple actors modify the same business object at the same time, then the system can be left in an inconsistent state. This issue is also identified in [6] as one of the drawbacks of the case handling paradigm. Existing commercial WFMS lock an entire case if one actor starts performing activities, which is a serious weakness. We refer the reader to [7] for a detailed discussion about stateless process enactment. 4.4
Degree of Activity: Active Versus Passive
A workflow engine plays a passive role if it contains a set of process rules that are executed upon a request, i.e. an external consumer takes the initiative to call the engine. It determines the next activities that can be executed together with their workflow participants, without actually invoking activities. A passive workflow engine needs state and context as input to execute the process rules. Optionally it can gather additional context by invoking some business concept services. A workflow engine has an active part if takes itself the initiative to enact processes. It makes sure that the processes are really being executed by actually invoking the activity services that require no human interaction. Moreover the engine can start the right activity service (i.e. show the right screens) when the actor selects an activity. Additionally, it takes care of the distribution of tasks for activities that require this.
A Phased Deployment of a Workflow Infrastructure
5
277
Discussion
As can already be deduced from the previous section, the presented dimensions to position workflow engines are not entirely orthogonal. The following principles and constraints can be summarized: – An optional workflow engine must be stateless. Since business objects are not exclusively managed by the engine, it must reconstruct the state of process instances when necessary. – A stateful workflow engine must act as a middleman. If the state of each process instance is part of the workflow control data, the engine must know everything that might change that state. – A stateless workflow engine embraces declarative process modeling. The fact that a stateless workflow engine derives its state from business objects is a declarative rule that constrains the enabling and completion of activities. – A workflow engine with an active part can (re)use a (state-aware) passive counterpart. Since the active part enacts processes by invoking applications and distributing tasks, it needs to apply process rules and it needs the state of running instances, hence it can use a potentially existing passive part. Now it is clarified how the dimensions can be combined, we summarize two combinations that represent two extreme kinds of workflow engine: – A workflow engine is “Big Brother” if it enacts procedural processes as a stateful and active middleman. The engine keeps the state of all its process instances, which is possible since it acts as a middleman. It becomes the central point in the existing architecture, since every activity, event and state change must be under control of the engine. Despite its disadvantages, this is where existing workflow management systems are to be positioned. – A workflow engine is an “Help assistant” if it is state-unaware passive. The engine does not interact with any system; it is only capable of returning next possible activities upon request. It is the responsibility of the actor to perform these activities by navigating to and invoking the right activity services. The workflow engine does not “see” what the actor is doing – state transitions within the workflow engine only occur after the actor has manually given feedback to the workflow engine. Its main advantage is its simplicity but its main disadvantage is that such an engine delivers very little added value. It is obvious that none of these options provide a satisfying solution. One of the aforementioned principles states that a workflow engine must be stateless to be optional, which was one of the business requirements (see section 3). Therefore KBC decided to deploy the following phased solution to create a workflow infrastructure that satisfies the business requirements. Each additional step requires more effort (implementation, changes to existing systems, etc.) but increases the usability of the infrastructure.
278
R. Haesen et al.
Phase 1. Create a state-unaware passive workflow engine: this component, which interprets the process rules, should at least be present. It is important to isolate these rules from the applications, since it increases process flexibility dramatically. The passive workflow engine should be placed on a back-end. Phase 2. Make the passive workflow engine state-aware: as already discussed, a stateless approach can not be avoided. However, given its disadvantages concerning performance, concurrency and maintenance, it should only be applied to processes that really require it. The state – whether explicitly kept or derived – is managed by business concept services and should consequently be positioned in the business logic layer. This component obviously uses the process rules component to consult the process definitions. Phase 3. Add an active component that supports user-interfacing processes: this component needs to integrate with the existing user-interfacing framework (UIF) that enables the execution of activities. The active component presents activities to the actor and starts the selected activity (service), i.e. it shows the right screens. Additionally, it invokes the appropriate activity services that do not require input from an actor. Since the UIF already contains backend connectivity and support for creating screen-flows, this component fits perfectly on the mid-tier. Phase 4. Extend the active component so that it also supports third-party systems: in a later stadium, the active component should be extended so it integrates with other packaged applications. Currently, an EAI framework enables back-end interactions using message-oriented middleware. In this phase the EAI framework should be extended in order to support new communication standards, such as the Web services stack [8]. In some parallel tracks, the other components of the workflow reference model of the WfMC [9] can be built, such as a task manager, administration tools, a history manager, monitoring tools, etc.
6
Evaluation and Related Work
The process modeling dimension is the primary dimension that draws the line between a process-driven and a process-aware SOA approach. Most researchers and commercial vendors consider a process-driven SOA approach [10,11,12]. In such an approach, services are generally seen as wrapped legacy systems, which are orchestrated using a prescriptive process description language, such as BPMN [4] or BPEL [13]. This paper clarifies the importance of a process-aware SOA approach, in which business processes are modeled using declarative languages. The fact that a stateless workflow engine derives its state from business objects is a declarative rule that constrains the enabling and completion of activities, which can be seen as an extension of the case handling paradigm [5]. Besides catering for an increase in process flexibility, this approach enables the decentralization of the WFMS and enables the execution of activities apart from the workflow engine. Other examples of declarative languages are the ConDec language [14]
A Phased Deployment of a Workflow Infrastructure
279
based on temporal logic and the PENELOPE language [15], which allows the expression of temporal deontic rules. Apart from case handling systems, commercial workflow management systems do not consider declarative business modeling and enactment. Instead, workflow engines are generally evaluated according to the support they provide for a set of control-flow, data, resource and exception patterns as they are identified by the Workflow Patterns initiative [16]. Moreover, the generally underexposed operational perspective [17] on workflow management presented in this paper shows that an existing enterprise architecture heavily influences the choice for a workflow management system.
7
Conclusion
This paper presented some viewpoints on the practical introduction of workflow management in an organization migrating to service-oriented architecture. The pre-existing valuable information systems, tools and frameworks form a heterogeneous environment that puts many yet justly constraints, which are not supported by existing workflow management systems: a WFMS should not become the single access point to all the other systems, an actor should be able to perform activities apart from the workflow engine, and for many processes it is practically impossible to model all activity constraints – such as scheduling, authorization, task distribution, etc. – in an explicit way. The Workflow Management Coalition proposes standards that neither elaborate on the potential existence of an enterprise architecture [9,3]. Therefore we proposed four dimensions to classify workflow engines that reflect the degree of support for the presented requirements. Based on the four dimensions, a phased roll-out of a workflow infrastructure was derived: firstly, a passive workflow engine should be built to interpret the processes rules. Secondly, that engine should be made state-aware, or more specifically, stateless to make the engine optional. Finally, an active component should be added that effectively enacts business processes by invoking the appropriate activity services.
Acknowledgements We gratefully thank Pieter De Bruyn and Frank Zwertvaegher for their valuable input during the workshops at KBC. This work was partially funded by the KBC-Vlekho-K.U.Leuven research chair on ‘Service and Component Based Development’ sponsored by KBC Bank & Insurance Group.
References 1. Herzum, P., Sims, O.: Business Components Factory: A Comprehensive Overview of Component-Based Development for the Enterprise. John Wiley & Sons, Inc., New York (2000)
280
R. Haesen et al.
2. Greenfield, J., et al.: Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. John Wiley & Sons, Chichester (2004) 3. WFMC: Workflow management coalition terminology and glossary. Technical Report WFMC-TC-1011, WorkflowManagement Coalition (1996) 4. Object Management Group: Business process modeling notation (bpmn) – final adopted specification. OMG Document – dtc/06-02-01 (February 2006) 5. van der Aalst, W.M.P., Weske, M., Gr¨ unbauer, D.: Case handling: A new paradigm for business process support. Data and Knowledge Engineering 53(2), 129–162 (2005) 6. Reijers, H., Rigter, J., van der Aalst, W.: The case handling case. International Journal of Cooperative Information Systems 12(3), 365–391 (2003) 7. Haesen, R., De Rore, L., Goedertier, S., Snoeck, M., Lemahieu, W., Poelmans, S.: Stateless process enactment. In: Pattern Languages of Programming (PLoP 2007) (accepted, 2007) 8. Fremantle, P., Weerawarana, S., Khalaf, R.: Enterprise services. Communincations of the ACM 45(10), 77–82 (2002) 9. WFMC: The workflow reference model. Technical Report WFMC-TC-1003, Workflow Management Coalition (1995) 10. Marks, E.A., Bell, M.: Service-Oriented Architecture (SOA): A Planning and Implementation Guide for Business and Technology. John Wiley & Sons, Inc., New York, USA (2006) 11. Papazoglou, M.P., Georgakopoulos, D.: Service oriented computing: Introduction. Communications of the ACM 46(10), 24–28 (2003) 12. OSOA: Service component architecture – assembly model specification. version 1.00 (March 2007), http://www.osoa.org 13. Leymann, F., Roller, D.: Modeling business processes with bpel4ws. In: N¨ uttgens, M., Mendling, J. (eds.) XML Interchange Formats for Business Processes, Marburg, GI, pp. 7–24 (2004) 14. Pesic, M., van der Aalst, W.M.P.: A declarative approach for flexible business processes management. In: Business Process Management Workshops, pp. 169–180 (2006) 15. Goedertier, S., Vanthienen, J.: Designing compliant business processes with obligations and permissions. In: Business Process Management Workshops, pp. 5–14 (2006) 16. van der Aalst, W.M.P., ter Hofstede, A.H.M., Kiepuszewski, B., Barros, A.P.: Workflow patterns. Distributed and Parallel Databases 14(1), 5–51 (2003) 17. Jablonski, S., Bussler, C.: Workflow Management. Modeling Concepts, Architecture and Implementation. International Thomson Computer Press, London (1996)
