Achieving Software Flexibility via Intelligent ... - Semantic Scholar

Proceedings of the 35th Hawaii International Conference on System Sciences - 2002

Achieving Software Flexibility via Intelligent Workflow Techniques Daniel D. Zeng

J. Leon Zhao

Department of MIS University of Arizona, Tucson, AZ 85721 [email protected]

Department of MIS University of Arizona, Tucson, AZ 85721 [email protected]

Abstract In this paper, we investigate innovative techniques of achieving software flexibility in a workflow environment. We believe that by incorporating workflow technology and intelligent agent techniques into modern information systems, software can be made more robust, more cost effective to maintain, and easier to change. In this paper, we present (1) an in-depth investigation of software flexibility issues, (2) an integrated system architecture that combines the workflow coordination mechanisms and the agent-based decision making capabilities, and (3) a framework to evaluate software architectures with emphasis on the cost implications of system flexibility. A prototype system illustrating the implementation of intelligent workflow concepts is also reported.

1.

Introduction

The past fifty years of software engineering can be seen as a continuous quest of developing software systems that are easier to design, cheaper to maintain, and more robust (Knoll and Jarvenpaa, 1994; Hale et al., 2000). Several milestones have been achieved in this endeavor, including data-oriented software architecture, object-oriented language, component-based software development, and document-based interoperability. Among these achievements, two important concepts are data independence and process independence. Data independence is a measure of the robustness of business applications when the data structures are modified. Relational database became dominant in the database market, mainly because it achieved significant data independence. Process independence is a measure of the robustness of business applications when the process model is redesigned. The drive towards more process independence has led to the proliferation of workflow systems in the software industry in the last few years. Very recently, most major software companies have either acquired or developed workflow components for integration into their existing software platforms. Workflow management helps achieve software flexibility by modeling business processes explicitly and managing business processes as data that are much easier to modify than conventional program modules. Workflow management systems enable reuse of process

templates, robust integration of enterprise applications, and flexible coordination of human agents and teams. Despite recent significant developments in workflow technology and its prevalent acceptance in practice, current workflow management systems still demand significant costs in system design and implementation. Furthermore, these systems are still lacking in their ability of handling exceptions and dealing with changes. In this paper, we study additional techniques based on intelligent agents to incorporate more flexibility in conventional workflow management systems. Our research goal is to further improve software flexibility by achieving more process independence. In the remainder of the paper, we first review relevant literature in software flexibility, flexible workflow systems, and intelligent agents in Section 2. We then propose a conceptual framework on software flexibility based on process independence in Section 3. In Section 4, we demonstrate how intelligent agent techniques can be incorporated into the workflow architecture to achieve high degree of software flexibility. In Section 5, we develop a cost model to evaluate three software architectures including conventional information systems, workflowbased information systems, and intelligent workflow systems. Section 6 summarizes our research contributions and outlines future research directions.

2. 2.1.

Literature Review Software Flexibility

Researchers have studied issues in the management of changing business processes from strategic, operational, and system perspectives (Bowers, Button, and Sharrock, 1995; Earl, 1994; Ellis and Rozenberg, 1995). Process changes can occur often. Many business processes are not well understood and difficult to formalize, leading to mismatches between the system specifications and real needs of the business. In addition, there are often exceptions to the basic routines of the business, requiring the system to be robust in order to handle process deviation from the norm. Nelson, et al. (1997) defines technology flexibility as the characteristics of technology that allow or enable adjustments or other changes to the business process. They proposed a measurement framework for technology flexibility that include such factors as modularity, change acceptance, and consistency in the structural flexibility

0-7695-1435-9/02 $17.00 (c) 2002 IEEE

Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS-35’02) 0-7695-1435-9/02 $17.00 © 2002 IEEE

1


dimension, and rate of response, expertise, and coordination of actions in the process flexibility dimension. Zhao (1998) proposed two related software flexibility concepts: system adaptability and system versatility. System adaptability is the capability to modify the system to cope with major changes in business processes with little or no interruption to business operations. System versatility (or system robustness) is the capability of the system to allow flexible procedures to deal with exceptions in processes and procedures. Most recently, Deiters, Goesmann, and Löffeler (2000) dealt with the issue of flexibility in technical, organizational, and human perspectives. They classify flexibility into four dimensions: process flexibility, interorganizational flexibility, flexible management and knowledge, and flexible task allocation. They further proposed conceptual solutions for achieving flexible workflow support. In this paper, we extend and unify those concepts of software flexibility and apply the results to the development of flexible process technology by means of intelligent workflow techniques.

2.2.

Flexible Workflow Systems

Researchers in workflow technology and management are concerned with developing flexible workflow systems. As stated by Klein, Dellarocas, and Bernstein (2000), “Workflow systems must be adaptive in order to effectively support today’s dynamic, uncertain, and errorprone collaborative work environments. … Workflow systems currently provide little support for adaptive processes. Most do not allow one to modify a process model once it has started executing. Exceptions are handled by attempting to include the workflow predefined conditional branches for all possible contingencies.” Several important directions are currently pursued by researchers to achieve workflow flexibility: • Exception handling: Fault tolerance is a key requirement in process support systems including workflow systems. Hagen and Alonso (2000) present a solution for implementing more reliable processes by using an exception handling technique as used in programming languages. • Dynamic model evolution: Dynamic workflow change requires the management of changing process models. For instance, Ellis and Keddara (2000) address the problem of unambiguously specifying process model changes, via a taxonomy of change modalities and a language for the unambiguous specification of procedural change. • Emergent process modeling: Another general approach for dealing with dynamic adaptation is based on partially specified process models and

depends on flexible enactment systems to refine and execute them at the runtime (Kumar and Zhao, 1999; Faustmann, 2000). In this paper, we build upon those basic ideas of dynamic workflow management and propose intelligent workflow techniques.

2.3.

Intelligent Agent Concepts

Intelligent agent technology is one of the fastest growing areas of research and system development in IT (Jennings, Sycara, and Wooldridge, 1998). Intelligent agents and multi-agent systems represent a new way of modeling many complex information management and decision tasks. Agents also represent a new computing environment for designing and implementing complex software systems (Joshi and Singh, 1999). Intelligent agents refer to autonomous software entities that can navigate heterogeneous computing environments and can, either alone or working with other agents, achieve user-delegated goals. There are clear contrasts between agents and traditional AI systems. Traditional AI systems have usually been designed to operate under a user's immediate control, while agents act autonomously, usually on their owners' behalf (Spector, 1997). Intelligent agents have been built in research labs (Maes, 1994) and for commercial applications (Etzioni and Weld, 1995), such as electronic mail handling agents, meeting scheduling agents, and Internet searching agents. However, most of the agents implemented are relatively simple and do not have all the features suggested in the literature. Currently, there are many open research topics dealing with intelligent agents including: planning with incomplete information (Etzioni and Weld, 1995), multiagent communication and coordination techniques (Sycara and Zeng, 1996), adaptive intelligence agents (Hayes-Roth, 1995; Decker and Sycara, 1997), and automatic generation of intelligent agents (Spector, 1997).

2.4.

Intelligent Agents for Workflow Systems

Intelligent agents have been used to achieve more flexibility in the modeling and enactment of workflows (Edmonds et al., 1994; Mahling, Craven, and Croft, 1995). Edmonds et al. (1994) studied a collaborative design problem involving participants with heterogeneous skills and suggested that multiagent systems can be deployed to support design with a range of functions when considered from a number of perspectives. Mahling, Craven, and Croft (1995) presented an overview of the evolution of their office work systems. Polyflow, the most recent generation of their office work systems, was designed as a goal-based workflow system that uses the power of goal-based knowledge representation to assist in planning, monitoring, and repairing workflows with emphasis on the users and their workgroups.

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


2


Sull (1998) proposed a distributed environment for managing lightweight workflow based on intelligent agents. Three types of agents were used, that is, the courier agent that handles the transition between two process states, the task agent that is to accomplish a task in collaboration with other human or intelligent agents, and the process agent that supervises a process instance on behalf of the process initiator. Singh and Huhns (1994) proposed to handle workflow exceptions based on an adaptive rule-based formulation using nonmonotonic reasoning. A multi-agent architecture was developed in the ADEPT (Advanced Decision Environment for Process Tasks) project (Jennings et al., 1996). ADEPT aims to design agent-oriented business process management by means of cooperating and autonomous agents.

3.

Modeling Software Flexibility

In this study, we focus on developing a methodology for achieving software flexibility by integrating workflow and intelligent agent techniques. For simplicity, we refer to the workflow systems that take advantage of intelligent agents to a significant extent as intelligent workflow systems. We conceptualize software flexibility in two levels, i.e., technology flexibility and system flexibility. By software flexibility, we refer to the ability of a software application to deal with exceptions to the process model at the runtime and to cope with periodic changes to the process model. By technology flexibility, we mean that software flexibility can be achieved by adopting the right combination of specific modeling paradigm, programming technique, software architecture, and development methodology. This level of flexibility is analogous to the combination of the structural and process dimensions proposed by Nelson et al. (1997), but with less emphasis on the organizational effects. By system flexibility, we include both system adaptability and system versatility discussed by Zhao (1998). The kinds of flexibility presented by Deiters et al. (2000) are classified mainly for developing particular types of workflow support functions. For instance, they separate process flexibility from flexible task allocation. In process flexibility, they studied how workflow modeling and enactment can be done to allow change of workflow models even during process execution. In flexible task allocation, they explore ways of assigning tasks to agents that are more robust. We coin the term of hierarchical process management. In a large-scale information system such as a B2B transaction processing system, the overall business process consists of many subprocesses, including interenterprise processes, intra-enterprise processes, inter-

function processes, and intra-function processes. We refer to the modeling and execution of this process hierarchy as hierarchical process management. In the next section, we show that different information techniques such as workflow and intelligent agents can be applied to improve the technology flexibility and system flexibility at the various levels of the process hierarchy.

4. 4.1.

Intelligent Workflow Management Workflow-Based Flexibility

Workflow technology is becoming the cornerstone of the next generation of enterprise application systems because it enables better flexibility of software systems in several respects: • Specialization of components into functional and process components: The workflow model essentially captures the inter-component processes, using a component-based software development philosophy. In some ways, a regular component such as a database can be seen as a functional component, while the workflow engine can be considered as a process component. This is the essence of hierarchical process management. • The separation of process design and process execution: The workflow paradigm enables the separation of process design from process execution by managing a process model as a template that can be instanciated at the runtime. This makes it possible to isolate the change of processes to different levels of the process hierarchy, resulting in reduced process interdependence. As a result, changes to processes can be made faster and cheaper. • Interoperability between process components: Given two workflow-coordinated enterprise systems, the interoperability between the two enterprise systems is turned into the interoperability between two workflow engines. This helps improve the speed of establishing, redesigning, and executing the interenterprise processes, thus making the overall system more flexible when the business relationship between two enterprises undergoing changes.

4.2.

“Intelligent Agent”-Based Flexibility

Intelligent agent techniques can be applied to improve the flexibility of information systems because of its several inherent features, as is summarized below based on the literature discussed in Section 2: • Specialization: Intelligent agents can be programmed to follow special instructions with a specific goal from a generic architecture. This enables fast building of software components.

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


3


•

•

4.3.

Negotiation: Intelligent agents can negotiate with one another to exhibit versatile behaviors in the system that would not be possible through rigid procedures. Coordination: Intelligent agents can be used to build a collaborative community of agents (including both human and software agents) that is more flexible than the typical workflow model.

Component P Coordinating Agent C

Task Agent 1

Flexibility via Intelligent Workflow

We propose to combine the workflow-based flexibility and the agent-based flexibility to achieve significantly improved overall software flexibility. We refer to this endeavor as flexibility via intelligent workflow. This approach has the following properties. • Inter-enterprise flexibility can be achieved by interoperating workflow engines that each coordinates an intra-enterprise business process. • Intra-enterprise flexibility can be realized by means of the workflow management paradigm as aforementioned. • Inter-component flexibility is made possible by means of both workflow management and agentbased components. The next subsection illustrates how these three types of flexibility are achieved under the hierarchical process management paradigm we propose in this paper.

4.4.

Component Q

Hierarchical Process Management

Workflow Engine A

Workflow Engine B

Enterprise A

Enterprise B

Figure 1. Inter-enterprise process management. Figure 1 illustrates how workflow engines are used to link business processes between two enterprises. The interoperation between two enterprises requires a collection of such activities as advertisement of services, negotiation of contracts, and outsourcing of processes, which has been referred to as cross-flow (Ludwig and Hoffner, 1999). Dept. X

Dept. Y

Dept. Z

Figure 2. Inter-department process management. Figure 2 shows how to manage inter-department processes by modeling them under one or more workflow systems. An inter-department process is more stable than an inter-enterprise process because the relative stability of relationships and the close coordination and planning ability within the same enterprise.

...

Task Agent N

Figure 3. Inter-component process management. Inter-component process can be managed by integrating workflow components with intelligent agent components. As shown in Figure 3, the coordination process among a community of intelligent agents is more flexible than a regular workflow coordination process because the interactions between the coordinating agent and the task agents are achieved through flexible negotiation in a distributed manner based on a common agent language and program interface.

4.5.

A Prototype Intelligent Workflow System

We have developed a prototype system to demonstrate the technological feasibility of integrating software agent technology with off-the-shelf workflow packages. Our objectives are to identify potential system integration challenges and to gain insights on the implications of a flexible workflow system in the management of changing business processes. This system provides a detailed illustration of how an intelligent workflow system based on inter-component process management (see Figure 3) can be engineered. In this section, we first briefly describe the application scenario in which the prototype system is situated. We then present the system architecture and related implementation issues. Although the underlying implementation framework based on which our prototype system was developed is generic, the implementation context is a real-world application that facilitates software adoption in a university setting. Working with the staff members of the instructional support group (ISG) of a large university and a group of students, we cataloged the current practice, elicited user requirements, and acquired necessary domain-specific knowledge. One of the primary roles of the ISG is to assist faculty in deciding which instructional software tool(s) best suits their needs. This recommendation process can be complex, due to the specialized needs of many faculty members and the wide range of available instructional software packages. A major source of the decision complexity stems from the fact that many of the tools have overlapping capabilities. For example, many of the tools provide communication capabilities (e.g., student-to-student, student-to-instructor, student-group), but the capabilities differ from tool to tool (e.g., whether the faculty can set up a filtering and approval

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


Task Agent 2

Component T

4


mechanism for student postings). The characteristics and attributes of one tool may work well in some situations, and may not work well in others. Similar situations exist for other types of desired instructional support such as Web-based access to course-related materials, online practice and self-tests, online quizzes and exams, etc. In the current practice, a Web-based system collects faculty requests. One or more members of the technical staff of the ISG analyze these requests, come up with recommendations, and then discuss these recommendations with the requesting faculty members. The whole process is typically iterative since request refinements and additions are common when the ISG staff members present their recommendations with the requesters. It is highly desirable that this time-consuming, error-prone, and potentially expensive (with respect to resources that the ISG has devoted to this software recommendation task) can be automated or at least facilitated by an intelligent software system. From a user’s perspective, the goal of our prototyping effort is to develop a “virtual recommendation agent” that understands the capabilities of the available software packages, proactively communicates with the user to elicit their requirements, and makes sensible suggestions based on the user requests. As discussed in Section 4, different software system architectures are possible to develop this virtual recommendation agent. It could be built as a hard-wired conventional software system using any of the common programming environments such as Java. It could be developed as a standalone workflow application based on commercial workflow engines such as Oracle Workflow. It could be developed as a standard knowledge-based system using some knowledge-based system shells. In our implementation, instead of relying on any of the abovementioned relatively well-studied architectures, we choose a hybrid, novel architecture combining workflow and intelligent agent technologies to achieve high degrees of system flexibility and extensibility.

Web-based Front End

JAVA Servlets

Coordinating Agent

Oracle Workflow

Oracle 8i Database

M ySQL Repository

Recomm ending Agents

Figure 4. Major Components of the Prototype

Figure 4 shows the major components of the prototype system and the high-level system architecture design. In our system, Oracle Workflow is used to model and implement the business logic behind the task of recommending instructional software. This logic reflects the real work process used by the ISG. Using a commercial workflow system simplifies system development and maintenance significantly because that it provides a built-in graphical CASE environment and that it helps eliminate lots of low-level transaction-oriented coding tasks. To achieve higher levels of data and process independence among various system components and to enable high degrees of extensibility (e.g., when additional software packages become available), we separate the domain knowledge on available instructional software and matching rules used to intelligently matching user requests with available software capabilities and encapsulate them in an agent-based system implementation framework, which runs independently of the workflow module. The workflow module and the agent module communicate with each other using KQML, a widely-used agent communication protocol (Petrie, 1996), and they work collaboratively to serve the user needs. The main processing logic of the prototype system is captured by the following sequence of steps: • User requirements are gathered via a Web page. • The workflow process is initiated upon the receipt of the request submission. • The recommendation task is forwarded to the coordinating agent. • The coordinating agent works with recommending agents to process user requests. • The results are returned by the coordinating agent to the workflow module. • The workflow module routes the results back to the Web interface. Motivated by developing a system that can scale and can handle changes and future updates easily, the agent module of our prototype is implemented as a distributed, multi-agent based system. As illustrated in Figure 4, Collaborating Agent functions as a getaway between the agent module and the workflow module. It receives recommendation requests from the workflow module, coordinates with a collaborative collection of agents each of them specializing in a particular software product, resolves conflicts, and then sends back recommended solutions to the workflow module in the form of KQML messages. Figure 5 illustrates the high-level design of multi-agent coordination in our implemented prototype. A blackboard architecture is used to record all user requests. When a user request is posted to the blackboard in the order received, it becomes a “job,” associated with a time stamp and an ID number for tracking and evaluation purposes. When a job is taking too long to process, the Coordinating Agent will investigate and re-assign the job, if necessary.

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


5


Request Interception

Event Monitoring

Knowledge Repository

Task Allocation

Task Announcement

Database Connectivity

Recommending Agents

Figure 5. Design of Agent Coordination Mechanisms. We assume an “open” operating environment where recommending agents are distributed over the network and can appear and disappear dynamically. To deal with these openness issues, agent registration and monitoring are necessary. All Recommending Agents that are ready to serve the user requests will register their presence and capabilities before they can be assigned a request by the Coordinating Agent. When a Recommending Agent known to the system goes off-line for any reason, the Coordinating Agent will nullify its registration so subsequent jobs are not assigned. In addition, the Coordinating Agent checks the workload of all registered Recommending Agents and assigns the job to the agent with the least amount of work. All software recommendations made by the Recommending Agents are posted to the blackboard. This allows the Coordinating Agent to review and merge the responses before returning them to the Workflow module. Also, should the Coordinating Agent itself go off-line for any reason, all outstanding jobs can still be recovered from the blackboard. As of the writing of this paper, the prototype system has been fully functional. We are in the process of evaluating its usefulness and effectiveness, particularly in light of the ease of expanding the system functionality and exception handling, in a real operating environment. We hypothesize that the built-in software flexibility enabled by the workflow and agent modules described above will result in significant reduction in software maintenance. A case study is being planned for future research. In the next section, we present a general framework to evaluation software system architectures, focusing on the potential cost impacts of software flexibility.

5.

A General Framework for Evaluating Software Architectures

maintenance cost because a more flexible software system helps reduce maintenance cost in several ways. First, a software system developed with the intent of being flexible is capable of handling certain exceptions in an automated manner, which in turn cuts back the effort and resources that have to be invested to deal with these exceptions by both the software users and the system development and maintenance personnel. Second, in today’s competitive marketplace, an enterprise typically goes through frequent changes in its ways of dealing with their customers and suppliers. Also, its internal business processes often experience incremental improvements and occasionally drastic modifications. Many of these business process changes, both internal and external, entail changes in software specification and requests for added functionality, which are among the major sources of software maintenance cost. A flexible software system provides a viable alternative in dealing with these types of software maintenance costs since it is easier and more cost-effective to reconfigure and reassemble software components to meet changes in user requirements. Different software technologies and system architectures deliver different levels of software flexibility. In this section, we present some preliminary results of our research aimed at developing a general cost-based framework to help organizations make decisions on which software technology or system architecture should be adopted given the characteristics of their business operating environments. In this framework, we concentrate on software flexibility as the main point of reference when comparing several major software architectures that are readily available or on the horizon for the organizations to enable their business process automation. In our analysis, we focus on the total cost of software development and maintenance over the software life cycles. Three possible system architectures are considered in our study: a) a conventional information system in which no workflow or intelligent agent techniques will be used, b) a workflow-based information system, and c) an intelligent workflow system that combines workflow and intelligent agent techniques. In this section, we first present a general cost-based framework developed to facilitate optimal choice of software system architecture. We then discuss the three architectures under investigation and offer some descriptive insights regarding the value of built-in software flexibility, enabled by workflow and software agent technologies. Several important factors that are not captured in our current framework will be discussed in Section 6.

Software maintenance cost often constitutes a 5.1. An Evaluation Framework significant part of the total cost associated with The general framework consists of three parts. The first developing and operating a software system during its life part is concerned with the modeling of user requests and span. Software flexibility has major impact on software maintenance needs. The second part discusses various types

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


6


of costs associated with initial system development and on-going maintenance activities driven by changing user requirements, added functionality, and software bugs. The third part of the model captures the maintenance decisions that the organization has to make. 5.1.1. Maintenance Requests In the literature, two types of maintenance generation processes have been proposed (Mookerjee and Tan, 1999; Chan et al., 1996). One is based on continuous maintenance, where software maintenance is performed on a continuous basis. The other is based on periodic maintenance due to considerations such as economies of scale, and system degradation. To the best of our knowledge, all existing models treat these two types of request generation mutually exclusively. In real-world applications, however, both maintenance types co-exist. For significant new feature additions due to changes in business logic critical system failures, or major deviations from design specifications, software maintenance is typically performed on a realtime basis. Other minor feature requests and bug fixings do not warrant immediate attention and therefore are being handled periodically. In our model, these two types of requests are being explicitly handled by different mechanisms. Note that the generation of these maintenance requests is independent of the underlying software infrastructure. Also, the modeling of these requests is independent from how they are being handled. Whenever appropriate, we use the standard request generation schemes, which have been proposed in the literature (e.g., Boehm, 1981; Banker et al., 1993; Mookerjee and Tan, 1999). We assume that the “critical” requests, referred to as Type I requests thereafter, occur according to an Poisson process with time-dependent arrival rate λ1 (t ) , where t is the time elapsed since the initial production use of the system. The second type of “noncritical” requests, called Type II requests, follows a similar random process with the following arrival rate:

maintenance cost, and opportunity cost of waiting times while the system is being maintained. Initial development cost includes all the costs incurred during the initial system development and testing phase. Examples of such costs are: general hardware and software infrastructure investment, software development training, costs associated with initial system analysis and design, system implementation, debugging, and testing. 0

We use C a to denote all the cost associated with the initial system development using the software architecture a. Software maintenance cost is also closely correlated with the underlying software architecture and related implementation platform. We adapt the standard cost models in the software engineering literature regarding software maintenance in our evaluation framework. Specifically, we consider all the maintenance costs incurred over the planning horizon T . A period is defined as the time between two adjacent type II maintenance activities. We use N i to denote the number of type I requests that th

take place during the i period. Then, the cost incurred during period i in connection with developing important new features and fixing critical bugs can be modeled as: i −1 1 Cai , I = cai , I ,1 N i + γ ai , I , 2 N i 2 + γ ai , I , 3 N i ∑ N j 2 j =0

At the right-hand side of the equation, the first term captures costs associated with the development of the requested new features, the second term reflects the cost of tuning the interactions among these newly developed components, and the third term represents the cost of integrating the new features into the existing system as a i , I ,1

whole (Mookerjee and Tan 1999). ca denotes the average cost of analyzing and implementing a new feature request. γ a

i ,I , 2

is the cost parameter related to integration

is the cost among the newly developed features. γ a parameter capturing the activity maintaining the whole α +1 system. β α To capture the learning effect on system development, t exp(− βt ) λ2 (t ) = M ∗ K ∗ Γ(α + 1) mainly as the result of productivity improvement when the where M measures the newly added complexities in system developers and maintenance personnel are the system, based on function points. α and β are becoming more familiar with the overall programming environment and the implementation platform, we further learning factors associated with the user. A lower model: value of α and a high value of β indicate a fast i −1 learning user. K denotes the average number of cai , I ,1 = γ ai , I ,1 exp( −θ a N j ) requests generated for each function point. j =0 5.1.2. Software Development and Maintenance where θ a is the learning rate when the software Costs under Different System Architectures architecture a is being used. We decompose the total software cost into three main The waiting cost for a maintenance request is the categories: initial development cost, software opportunity cost of waiting between the time when the i ,I , 3

∑

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


7


requests are made by the user and the time when the requests are being successfully dealt with. We treat waiting costs for the two types of requests separately. Based on the fact that type I requests are being processed on a continuous basis, we calculate Type I request waiting cost over the planning horizon T as follows. T

w1 ( PaI ) ∫ λ1 ( x )dx 0 I a

where P is the mean coding time for handling one critical maintenance request and w1 ( t ) is the cost (in the form of lost businesses or reduced productivity) of waiting t time units when a type I request is issued. Similarly, we calculate the mean Type II request waiting cost per period as follows:

∫

τ

0

w2 ( PaII + τ − x )λ2 ( x )dx II

where Pa is the average time needed to complete a requested task of type II under software architecture a , and τ is the time at which the next type II maintenance will start. 5.1.3. Software Maintenance Decisions Different types of software maintenance requests require different reactions from the software maintenance team. Due to the nature of Type I requests, immediate maintenance effort will take place after the requests are being made. On the other hand, in dealing with Type II requests, the software maintenance personnel has a choice with respect to the frequency of maintenance effort and the batch size. Timing and scheduling of type II maintenance activities can have significant cost impact on the total system maintenance cost, as being demonstrated in past research (Chan et al., 1996). For brevity, we will skip the discussions regarding how the software maintenance team makes optimal decisions on their maintenance schedules for type II requests. In the following discussions, we will assume that for a given software architecture, the software maintenance team will adopt the optimal maintenance policy given its knowledge about the business operating environment and related estimated cost parameters, which are system architecture-dependent.

5.2.

A Descriptive Comparison of the Three Architectures

Following the general framework presented in Section 5.1, we compare the three system architectures, namely, no-workflow, workflow, and workflow plus agent in light of varying degrees of software flexibility and potential cost impacts. In our framework, a certain software architecture is characterized by a set of cost parameters representing how much resource is required to develop

the system under the given architecture, and how quickly and cost-effective new feature requests and exceptions and bug-fixing can be handled during system maintenance. Due to the emerging and dynamic nature of workflow and software agent technologies, empirical data needed to perform a meaningful validation of the cross-architecture comparison is virtually nonexistent. While we are working on collecting such empirical evidence, we first present a high-level descriptive comparison of the three architectures by drawing experience from our development effort presented in Section 4.5 and from our knowledge on software engineering. The results of our analysis are summarized in Table 1. Although we believe that this table reflects the basic cost trade-offs of existing and emerging software technologies and corresponding implementation practice, we caution that it is highly speculative. The main point of our discussion is to demonstrate the process of using the framework developed in Section 5.1 to analyze software architecture alternatives and to provide a point of departure for follow-up studies. NoWorkflow Workflow/ workflow Agent 0 Medium Low High C a

r

High

Medium

Low

θa

Medium

Medium

High

rai , I , 2 , rai , I , 3 ,

High

Medium

Low

i ,I ,1 a

PaI , PaII Table 1: Comparing Three Software Architectures. We briefly discuss Table 1 and explain the rationale behind the given cost estimations. Consider the initial system development cost (the 2nd row of the table). Because of the built-in process automation and transactional support in workflow systems, combined with the strong CASE support, it takes a relatively small amount of effort to implement business applications with processes that are relatively straightforward. When no workflow systems are being adopted, developing the needed functionality would take significantly more efforts under the conventional IS development paradigm. From our experience, developing a system that uses both workflow and software agent technology turns out to incur the highest fixed set-up cost in the initial system development phase. This is partially due to the relative immaturity of agent technology and the lack of a commonly-accepted agent development environment. In addition, designing and implementing a flexible, generic communication protocol to integrate a workflow system and related software agents can be time-consuming and expensive. On the other hand, when the basic integration and collaboration infrastructure are completed, coding productivity will improve. Coupled with the increasing familiarity with agent-based system development (a relatively new set of system design and programming skills

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


8


to most system developers) through handing maintenance requests, we expect higher gains on productivity over time (see the fourth row of Table 1). Because of the built-in system flexibility and intelligence enabled by software agents, it is conceivable that all the cost parameters related to cost effectiveness and timeliness of handling both types of user requests during the system maintenance phase, are lower for the workflow/agent alternative. Cost savings can be enabled in several ways. First, during the execution, some process deviations may be viewed under the workflow and agent architecture as operable, whereas a rigid conventional system has to treat them as exceptions and programmer intervention is required. Second, the workflow/agent architecture enables higher-level data separation and better system modularity, which in turn decrease the dependence among system components (see the row i , I ,2

corresponding to ra

, rai , I ,3 ). Third, agent technology

workflow systems. This framework can serve as a theoretical basis for making potentially critical software architecture decisions facing virtually all IT adopters. In our future research, we are planning to conduct a case study to evaluate the implemented prototype in the context of recommending software packages. The system architecture examined in this paper represents an example of loose integration between the workflow and the agentbased system in that the agent module operates outside of the workflow system. We are currently conducting research towards tight integration between these two technologies. For instance, in a tightly integrated architecture, agent capabilities such as personalization, resource modeling, and conflict resolution will directly enhance the core functionality of a workflow engine. In the evaluation framework presented in Section 5, we focused exclusively on software maintenance and assume that during a software system’s life span, the underlying software architecture will remain the same. In today’s highly volatile software development environment, a model that tackles decisions concerning software replacement is desired. We plan to extend our model to deal with these software replacement issues with an emphasis on flexibility in our future research.

can easily extend the capabilities of a workflow system while taking the full advantage of commercially available workflow systems in terms of data management, message handling, and transaction processing. Based on this analysis, we hypothesize that it makes most economic and technological sense to adopt the workflow/agent architecture when the business References environments are volatile and constant changes have to be made to the software system. In more stable 1. Banker, R., Data, S., Kemerer, C., and Zweig, D., environments, a workflow system alone architecture “Software Complexity and Maintenance Costs,” might be preferred. In our ongoing research, we are Communications of the ACM, Vol. 36, No. 11, 1993. developing a simulation-based method to validate this 2. Boehm, B. “Software Engineering Economics,” Pretice hypothesis. Hall, 1981.

6.

Conclusions

In this paper, we investigated several innovative techniques of achieving software flexibility in a workflow environment. Next, we first summarize the research contributions of our work presented in this paper and then point out several future research directions. We motivated the study of software flexibility in the context of workflow management systems and discuss related modeling issues. We argue that a workflow system enhanced by intelligent agent technology under the general umbrella of inter-component process management provides a viable system implementation architecture to achieve high-level software flexibility. A proof-of-concept prototype system is presented, emboding the proposed system architecture design. We also presented a general evaluation framework which can be used to analyze the economic impacts of various types of software architectures with respect to total software cost. We offer some general technological and managerial insights as to the varying degrees of software flexibility and cost implications for conventional software, workflow systems, and the proposed intelligent

3.

Bowers, John, Graham Button, and Wes Sharrock, "Workflow from within and without", Proc. of the 4th European Conf. on CSCW, 1995.

4.

Chan, T. Chung, S., and Ho, T. “An Economic Model to Estimate Software Rewriting and Replacement Times,” IEEE Trans. On Software Engineering, Vol. 22, No. 8, August 1996.

5.

Decker, K.S. and Sycara, K. "Intelligent adaptive information agents". Journal of Intelligent Info Systems: vol.9, no.3 (Nov.-Dec. 1997) p239-60.

6.

Deiters, W., T. Goesmann, T. Löffeler, “Flexibility in Workflow Management: Dimensions and Solutions”, International Journal of Computer Systems Science and Engineering, Vol 15, No 5, September 2000, pp. 303-313.

7.

Earl, Michael J., “The new and the old of business process redesign”, Journal of Strategic Info. Systems, Vol 3, No. 1, 1994, pp. 5-22.

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


9


8.

9.

10.

11.

12.

13.

Edmonds, E.A., et al., "Support for collaborative research conference on Reinventing IS, March 24 - 26, design: agents and emergence", Communications of 1994, Alexandria, VA USA, Pages 1-14. the ACM, vol.37, no.7 (July 1994) p41-7. 21. Kumar, A. and Zhao, J. L. “Dynamic Routing and Operational Controls in Workflow Management Ellis, C. and G. Rozenberg, “Dynamic change within Systems”, Management Science, Feb. 1999, vol.45, workflow systems”, Proceedings of the COOCS 95, (no.2): 253-72. Milpitas, CA, USA, 1995. 22. Ludwig, Heiko and Yigal Hoffner, “Contract-based Cross-Organisational Workflows - The CrossFlow Ellis, C. and K. Keddara, “ML-DEWS: modeling Project”, Proceedings of the Workshop on Crosslanguage to support dynamic evolution within Organisational Workflow Management and Coworkflow systems.” Computer Supported ordination, San Francisco, USA, February 22, 1999. Cooperative Work: The Journal of Collaborative 23. Maes, P, "Agents that reduce work and information Computing, Aug. 2000, vol.9, (no.3-4): 293-333. overload", CACM, vol.37, no.7 (July 1994), p30-40, Etzioni, O. and D.S. Weld, "Intelligent agents on the 146. Internet: Fact, fiction, and forecast". IEEE Expert 24. Mahling, D.E., N. Craven, and W.B. Croft, "From vol.10, no.4 (Aug. 1995) p44-9. office automation to intelligent workflow systems", Faustmann, G. “Configuration for adaptation-a IEEE Expert, vol.10, no.3 (1995) p41-7. human-centered approach to flexible workflow enactment.” Computer Supported Cooperative Work: 25. Mookerjee V. and Tan, Y. “Optimal Software Maintenance and Replacement Policies,” Proceedings The Journal of Collaborative Computing, Aug. 2000, of Ninth Workshop on Information Technologies and vol.9, (no.3-4):413-34. Systems, 1999, December. Hagen, C. and G. Alonso, “Exception handling in workflow management systems.” IEEE Transactions 26. Nelson, K. M. et al., "Technology flexibility: conceptualization, validation, and measurement", on Software Engineering, Oct. 2000, vol.26, (no.10): Proceedings of HICSS97. 943-58.

14. Hale, J., Parrish, A., Dixon, B., and Smith, R. 27. Petrie, C. “Agent-Based Engineering, the Web, and Intelligence,” IEEE Expert, 1996, December. “Enhancing the Cocomo estimation models”, IEEE Software , Volume: 17 Issue: 6 , Nov.-Dec. 2000, 28. Singh, M. and Huhns, M. “Automating workflows for Page(s): 45 –49. service provisioning: Integrating AI and database 15. Hayes-Roth, B. et al. "A domain-specific software technologies,” IEEE Expert, Vol 9, No 5, 1994, p19architecture for adaptive intelligent systems," IEEE 23. TSE 21(4) (1995) p288-301. 29. Spector, L. "Automatic generation of intelligent agent 16. Jennings, N., Sycara, K., and Wooldridge, W. “A programs". IEEE Expert 12, 1 (1997) p3-4. roadmap of agent research and development,” Autonomous Agents and Multi Agent Systems, Vol 1, 30. Stohr, Edward A. and J. Leon Zhao, "A technology No 1, July 1998. adaptation model for business process automation", 17. Jennings, N.R. et al., "Agent-based business process Proceedings of HICSS97. management". International Journal of Cooperative 31. Sull, W. “A distributed environment for enabling Information Systems vol.5, no.2-3 (June-Sept. 1996) lightweight flexible workflows.” Proceedings of the p105-30. Thirty-First Hawaii International Conference on 18. Joshi, H. and Singh, M. Multiagent Systems on the System Sciences, Jan. 6-9, 1998, p. 355-64 vol.4. net. Communications of the ACM, Vol 42, No 3, 32. Sycara, K. and D. Zeng. "Coordination of multiple 1999. intelligent software agents". Intl. J. of Coop Info 19. Klein, M., C. Dellarocas, and A. Bernstein, Systems vol.5, no.2-3 (1996) p181-211. “Introduction to the special issue on adaptive workflow systems.” Computer Supported 33. Zhao, J. Leon, “Intelligent Agents for Flexible Cooperative Work: The Journal of Collaborative Workflow Systems”, Proceedings of the AIS Americas Computing, Aug. 2000, vol.9, (no.3-4):265-267. Conference on Information Systems, Baltimore, 20. Knoll, K. and S. L. Jarvenpaa, “Information Maryland, August 14-16, 1998. technology alignment or "fit" in highly turbulent environments: the concept of flexibility”, Proceedings of the 1994 computer personnel

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


10