Managing Business Process Compliance Requirements Oktay Turetken1, Amal Elgammal1, Michael P. Papazoglou1, Willem-‐Jan van den Heuvel1 1European Research Institute in Service Science, Tilburg University,
Warandelaan 2 K731 5000LE, Tilburg, The Netherlands
Abstract: Ensuring compliance to laws, regulations, and standards in a constantly changing business and compliance environment is one of the major challenges the companies are facing today. Organizations have increasing need for systematic approaches to manage compliance throughout the business process lifecycle. In this paper, we present an integrated framework to capture and manage business process compliance requirements. We explain the key elements of compliance and introduce a set of patterns that assist the definition of frequently recurring compliance requirements constraining business processes. This approach enables the application of tools and methods for automated compliance verification and monitoring of business processes.
Keywords: Business Process Compliance, Compliance Requirement, Internal Control, Control Pattern
PRINTED VERSION at: Turetken, O., Elgammal, A., van den Heuvel, W-J., Papazoglou, M. (2012). “Capturing Compliance Requirements: A Pattern-Based Approach”. IEEE Software,
May/June 2012, pp. 29-36. http://dx.doi.org/10.1109/MS.2012.45
v1 –PrePrint Draft
1
1
Introduction
In today’s technology-‐centric environment, the ability to manage compliance to regulations, laws, and other imperatives has become a critical requirement for business success. Almost every aspect of running a business is governed with directives that enforce organizations to provide assurance to regulators, stakeholders, customers, and business partners that they have done their due diligence in establishing compliance to stated requirements. This necessitates an integrated set of policies, processes, and IT systems that are governed through internal controls. Internal controls are actions that contribute to the achievement of the organization's objectives regarding: (i) the effectiveness and efficiency of operations, (ii) the reliability of internal and external reporting, and (iii) compliance with applicable laws, regulations and internal policies [1]. Internal control becomes a highly pertinent business issue particularly after a series of large corporate scandals in early 2000s. As a response to these failures, governments, regulators, and standard setting groups issued various laws and regulations, such as Sarbanes–Oxley Act (SOX) [2], EU Directive 2008/30/EC (Euro-‐SOX) [3], and Basel III [4]. These directives assume continuously monitored and improved internal controls in place to provide reasonable assurance to the achievement of objectives including those concerning compliance. Many companies have taken steps to integrate internal controls with their business processes and enterprise application systems to address specific regulations. However, in most cases these efforts led to tailored and isolated solutions that involve hard-‐coded requirements across multiple systems. This scattered structure poses threats to the integrity and consistency of requirements [5]. It impedes the ability to adapt constantly changing business environment. Contemporary approaches to managing internal controls in business processes are rather fragmented and lead to reactive – rather than proactive – risk prevention. Existing tools (such as Oracle GRC Accelerators and SAP BusinessObjects GRC) are mainly offering solutions for monolithic applications (such as ERP systems) that pose difficulties for SOA environments. Compliance specifications and business process (BP) specifications should be decoupled as they are typically formulated by different stakeholders and have different lifecycles [6]. Decoupling involves defining and managing compliance information as a separate entity -‐starting from abstract
v1 –PrePrint Draft
2
constraints and their sources to concrete and organization specific rules and requires them to be linked to relevant process specifications and applications to enable round-‐trip traceability. Conceptual separation of compliance information and storing in a centralized location helps managing and independently evolving compliance requirements. Like business processes, these requirements also constantly change. A centralized compliance repository can assist in analyzing the impact of such changes by maintaining backward traceability to compliance sources and forward to the rules and applications that implement and enforce them. It helps avoiding duplicate implementation and handling of compliance information in different applications, thereby reducing maintenance costs [7]. Establishing a repository requires a uniform conceptual basis to accurately capture compliance information. This information comprises not only abstract concepts (such as compliance objectives), but also concrete rules that are expressed using formal languages. Formal specification of compliance rules paves the way for the automated and lifetime assurance of business process-‐ based systems. Partially or fully automating manual business process inspections and audits would significantly reduce the risk of violations, resulting in reductions on the overall cost of compliance. However, the complexity of the formalisms and concerns regarding their usability remain as significant obstacles for their widely adoption in practice. We consider using patterns as a viable approach to shield their complexity off from business and compliance experts and to facilitate the formal specification of these rules in the abstract. To address these problems, first, we propose a set of compliance management activities that integrates with the BP lifecycle. These activities guide organizations to identify and refine compliance requirements and to apply them in verifying and monitoring process compliance throughout the BP lifecycle phases. Second, aligned with these practices, we developed a conceptual model for a centralized compliance repository to capture compliance elements and cross correlate them with process specifications. This model also incorporates a set of compliance patterns for defining frequently recurring compliance requirements. Patterns help in generating formal rules to enable the application of automated tools for compliance verification and monitoring. To investigate the applicability of our solutions, we have developed a set of integrated software tools
v1 –PrePrint Draft
3
and employed them in two case studies that deal with real-‐life business processes of companies in two different industry sectors.
2
Business Process Compliance Management Framework
A compliance approach should embrace a preventive focus that considers compliance from the very early stages of business process design [6]. We followed a holistic approach for managing compliance throughout the BP lifecycle phases. Figure 1a provides insight into an operational view of the business process compliance management framework that we developed. The compliance management activities are based on the COSO Framework [8], which is accepted as the reference standard for establishing and assessing internal control systems in organizations [9]. Figure 1b shows the key concepts and their relationships that emerge from these activities and constitute the building blocks of the compliance repository. Figure 1c exemplifies these concepts. Objective Setting and Boundary Identification: This is the initial step to the understanding and establishment of the (compliance) objectives and the boundaries of acceptable conduct. The boundaries include both mandatory directives, such as laws and regulations (e.g., SOX, Basel III), and voluntary sources, such as industry best practices, standards (e.g., ISO 9000, ISO/IEC 27000 series), internal and external policies, and business partner contracts. From compliance perspective, key concepts in this phase are directives (compliance sources) and compliance requirements. To govern the courses of actions in organizations, directives express compliance requirements at various abstraction levels. A compliance requirement is a constraint or assertion that prescribes a desired result or purpose to be achieved by factoring actions or control procedures in processes [10]. A requirement can be prescribed in the form of abstract constraints or control objectives such as the ones specified by COBIT framework [11]. Business Process Analysis & Design: BP lifecycle starts with the analysis of existing process and the design of ‘to-‐be’ processes taking into account various factors, such as business objectives, architectural frameworks, industry best practices, and compliance requirements [12]. The processes can be modeled using a process
v1 –PrePrint Draft
4
definition notation, such as BPMN, followed by the construction of detailed-‐level executable business process and service specifications using, for instance, languages such as WS-‐BPEL or XPDL. Our framework assumes a generic model for business processes. It considers processes designed as a collection of process elements that contain key concepts, such as activities, events, business objects, roles and organizational units. Risk Assessment & Response: A risk-‐based approach is fundamentally necessary in understanding the inherent uncertainty involved in pursuing organizational objectives. Taking into consideration the compliance objectives and the current design of business processes, it is essential to identify, assess and prioritize the key events that can compromise business process compliance. The likelihood and the impact of risks are analyzed, which together designate how important a particular compliance requirement is to the organization. Response actions to deal with non-‐compliance are planned as contingencies. Control Definition and Implementation: Controls are key to decrease the likelihood of a (compliance) risk to materialize. They mitigate risks to provide reasonable assurance to the fulfillment of compliance requirements. At this stage, compliance experts (internal auditors) may work together with legal experts and business process domain experts, as analyzing risks over processes and defining necessary controls require not only compliance but also business domain knowledge. Controls can be grouped into various categories. One such categorization distinguishes between preventive and detective controls. Preventive controls help to keep violations from occurring. Examples include authorizations, segregation of duties, and prior supervisory approval. Detective controls, on the other hand, often produce information regarding an occurred violation to help understand its causes. Examples are management reviews, exception reports, and reconciliations. Regarding the point of application, controls are also categorized as process, technical, and physical [13] Process controls apply policies and practices over business processes. Authorizations, approvals, inspections, segregation of duties are examples of such controls. Technical controls involve the use of devices or systems mainly for authentication, encryption, identification or security purposes. Physical controls are instituted mainly to guard critical assets. v1 –PrePrint Draft
5
Business processes are typically subject to both preventive and detective process controls. Automated assurance of these controls is at utmost important, as manual controls are usually expensive to design and test in the long run [14]. A viable approach is to formally define rules for process controls to enable automated verification and monitoring of business processes that are implemented in enterprise systems. Formalizations should be applied only for those controls that can be checked effectively through automated verification activities. A control rule is usually specified in the form of ‘if-‐then’ statements consisting of a set of conditions followed by one or more conclusions. Business process elements and their attributes are the building blocks of the conditions and conclusions in rules. For example, a control for checking ‘customer loan requests above 1 million $ to be approved by supervisors’ can be formally specified using Linear Temporal Logic (LTL) as: “G(Loan.Amount> 1.000,000 $ → F(ApproveLoan.Role(Supervisor))” BPM Lifecycle & BP Compliance Management Activities
Key Elements exemplified for the "Loan Approval" Process
Key Elements of the Compliance Repository
c.source
Objective Setting & Boundary Identification
Compliance Source (Directive)
originate Compliance Requirement from
/Objective
compromise
Risk Assessment & Response
Define/ Implement Controls
compromise
Risk
implement,
Control Rule formalize refer/use
Preventive Design-time Compliance Verification
c.req/obj
Fraud/ misuse
fulfill
Control
have
Process Element
Process
have
have
"VerifyBankingPrivilege" & "Check rule CreditWorthiness" activities should be performed by different users. Formal Statement: G((VerifyBanking Privilege.User(User1)→ G(¬ (CheckCreditWorthiness.User(User1))
Preventive Runtime Compliance Monitoring
Business Process Monitoring & Optimization
Detective Offline Comp. Analysis & Monitoring
Process Element Instance
risk
Financial loss
risk
Loan granted with inadequate level of assurance
prevent,detect, mitigate implement, formalize
"VerifyBankingPrivilege" & "Check CreditWorthiness" activities should be assigned to different roles. Formal Statement: G(VerifyBanking Privilege.Role(Role1) → G(¬(Check CreditWorthiness.Role(Role1)))
control
Customer bank privilege verifications are segregated from credit worthiness checks Credit worthiness of customers requesting loans above 1M $ are checked by the Clerk Supervisor
refer/use have p.element
Business Process Execution
Duties should be adequately segregated
originates from
risk
prevent, detect, mitigate
Business Process Analysis & Design
COBIT PO4.11 ISO/IEC 27002 - Sec. 10.1.3
Process Instance
CheckCredit Worthiness
process
Loan Approval
VerifyBanking Privilege
Figure 1.
(a) BP Lifecycle and BP Compliance Management Activities, (b) Key Elements of the Compliance Repository, (c) Examples for the key elements
v1 –PrePrint Draft
6
Preventive Design-‐time Compliance Verification This activity is key to ensure that business processes progressing to execution are ‘compliant by design’. It mainly involves the static verification of process specifications against formal control rules. The rules employed at this stage are preventive in nature and involves only those that can be checked during design-‐time phase of the BP lifecycle. Examples include rules regarding the (control) flow of processes, such as activity sequencing. Business Process Execution: Once the process specifications are verified against compliance, tested, and reach a steady state, they are deployed and executed. Preventive Runtime Compliance Monitoring Compliance verification of process models during design-‐time is not always possible, as some rules may require variable instantiations or runtime information that are not available at design-‐time. Like design-‐time verification, runtime compliance monitoring is preventive aiming to detect violations before they occur. Hence, during runtime the process executions are often suspended preventing violations to arise. Business Process Monitoring & Optimization: Process executions are subsequently monitored for their performance by tracking the progress of individual process instances. Inefficiencies are analyzed and improvement actions are developed to achieve increased performance. Detective Offline Compliance Analysis and Monitoring Following a detective approach, offline compliance analysis and monitoring complements prior assurance activities (design-‐time and runtime) to provide a lifetime guarantee for business processes. This activity mainly involves the analysis of process execution data to detect possible violations and trends. Findings are presented on monitoring dashboards in the form of compliance performance indicators. If monitoring indicates deviations from (compliance) objectives, corrective adjustments of process definitions might be necessary. This, in turn, brings organization back to the initial stages of process analysis & design, and risk assessment & response.
v1 –PrePrint Draft
7
The assurance activities (design-‐time, runtime and offline) depicted in Figure 1a employ only automated verification and monitoring practices that are enabled through formal specifications of rules. However, not all requirements over business processes can be formally specified. Manual controls that involve full or partial human intervention might be necessary for these cases. For instance, checking the quality of a particular document may involve a manual control.
3
Process Control Patterns
Formal specification of rules for automated compliance assurance offers great value to business process compliance. However, complexity of formal languages and inherent usability problems pose significant difficulties for end-‐users. We developed process control patterns to help compliance and business experts to specify semi-‐formal representations of process controls and to generate formal rules that are used for subsequent compliance verification and monitoring activities. Process control patterns are high-‐level domain-‐specific templates used to represent desired properties that apply to process specifications [10]. For instance, the expression ‘Receive_Invoice LeadsTo Make_Payment’ uses the LeadsTo pattern to express a control that requires ‘Make_Payment’ to follow ‘Receive_Invoice’ activity. Expressions are built using patterns and process elements (such as activities, data objects, roles, etc.), their attributes, or conditions based on them. To address the specification of complex controls, expressions can be combined and nested via Boolean operators (e.g., and, or, xor). In order to discover patterns for recurring types of controls, we analyzed a wide range of regulations, standards and frameworks, and worked on diverse compliance requirements through case study conducts. We also investigated works (such as [15-‐17]) on the specification of various requirements on business processes. In identifying patterns, we focused on preventive process controls that can be applied for automated design-‐time compliance verification and runtime monitoring. The patterns that we defined are listed in Table 1. We distinguished four types of patterns:
v1 –PrePrint Draft
8
•
Occurrence patterns address rules concerning the existence of process elements. For example, ‘Approve_Order Exists’ expression indicates a rule mandating ‘Approve_Order’ activity to occur in the process specification.
•
Order patterns involve rules concerning mainly the behavioral aspect of process specifications.
•
Resource patterns address authorizations, assignments and segregation of duties requirements. For example, ‘Create_Order SegregatedFrom Approve_Order’ expression specifies a segregation of duties rule to indicate that these activities must be performed by different roles and users (actors).
•
Time patterns are used with Order and Occurrence patterns to address time-‐related requirements over processes. For example, ‘‘Receive_Invoice LeadsTo Make_Payment Within 5(days)’.
Pattern categories are also grouped into basic and advanced to distinguish patterns that are commonly used and those that are less frequent and typically addressing complex controls.
Advanced Advanced
Order
Basic
Occurrence
Basic
Pattern *
Description*
P Exists
P must exist in the process specification
P Absent
Process specification must be free of P
P Universal
P must occur/be valid throughout the specification
P CoExists Q
If P is present then Q must also be present
P CoAbsent Q
If P is absent then Q must also be absent
P Exclusive Q
If P is present then Q must be absent and vice versa.
P CoRequisite Q
Either P and Q must be present together or absent together
P MutexChoice Q
Either P or Q must be present but not any of them or both of them
Q Precedes P
P must be preceded by Q
P LeadsTo Q
P must be followed by Q
P XLeadsTo Q
P must immediately be followed by Q
P PLeadsTo Q
P and Q should occur and must occur sequentially
P ChainLeadsTo (Q, T)
P must be followed by a Q and T
(P, S) ChainLeadsTo Q
P and S must be followed by a Q
Q ChainPrecedes (P, S) P and S must be preceded by Q (Q, T) ChainPrecedes Q P must be preceded by Q and T
v1 –PrePrint Draft
9
Basic Advanced
Resource
Time
Pattern *
Description*
P PerformedBy Q
Activity Q must be assigned to (performed by) Role P
P SegregatedFrom Q
Activities P and Q must be performed by different roles and users
P USegregatedFrom Q
Activities P and Q must be performed by different users
P BondedWith Q
Activities P and Q must be performed by the same role and user
P RBondedWith Q
Activities P and Q must be performed by the same role but different users
(P, Q, S) M-‐Segregated
Activities P, Q, and S must all be performed by different roles and users
(P, Q, S) M-‐USegregated Activities P, Q, and S must all be performed by different users (P, Q, S) M-‐Bonded
Activities P, Q, and S must all be performed by the same role and user
(P, Q, S) M-‐RBonded
Activities P, Q, and S must all be performed by the same role but different users
Within k
Used with order patterns to denote a given P to happen within k time units. E.g.: ‘P LeadsTo Q Within k’ indicates that P must be followed by Q within k time units.
After k
Used with order patterns to denote a given P to happen after k time units. E.g.: ‘P LeadsTo Q After k’ specifies that P must be followed by Q after k time units.
ExactlyAt k
Used with order and occurrence patterns to denote a given P to happen exactly at time k. E.g.: ‘P Exists ExactlyAt k’ indicates that P must occur at time k, starting from the initial state of the process instance.
* Given P, Q, S, and T as states representing process elements, their attributes or conditions based on them (e.g.: ‘Loan.Amount > 100.000’).
Table 1.
Process Control Patterns
A pattern-‐based expression exhibits a generic nature and can be transformed into a set of formal statements based on a mapping between patterns and appropriate formal languages. We selected Linear Temporal Logic (LTL) and Metric temporal logic (MTL) as formal languages, mainly due to their expressive power and widespread use in research and practice to address problems in different domains. MTL provides the support to formalize expressions that use Time patterns, as LTL lacks support for such properties. For each pattern, we developed a mapping to LTL/MTL statements to automatically generate corresponding formal statements. An expression ‘Create_Order SegregatedFrom Approve_Order’ can generate the following LTL statements that can be used as input to compliance verification and monitoring: •
F(Create_Order): To check whether ‘Create_Order’ activity exists in the specification.
•
F(Approve_Order): To check whether ‘Approve_Order’ activity exists in the specification
•
G(Create_Order.Role(Role1) → G(¬(Approve_Order.Role(Role1)))): To check whether two activities are assigned to different roles
v1 –PrePrint Draft
10
•
G(Create_Order.User(User1)→ G(¬(Approve_Order.User(User1)))): To check whether two activities are performed by different users
4
Implementation and the Case Studies
To help ascertaining the soundness of the concepts and approaches we described in this paper, we developed and integrated a set of software applications implementing these concepts and employed the toolset in two case studies. The Toolset Implementation: Figure 2 shows a high-‐level architectural view of some key software components of the toolset, depicting their data relationships between them. The Compliance Requirements Manager (CompRM) component is a web-‐based application (accessed through http://eriss.uvt.nl/compas) for defining, storing and managing compliance elements in the Compliance Repository. The Compliance Rule Manager is a standalone application used for building graphical representations of pattern-‐based expressions and automatically generating corresponding formal statements. It retrieves the process elements that are used in building the pattern-‐based expressions from the Business Process Repository. Compliance Rule Manager Business Process Elements
Control Definitions
(Preventive) Design-time Compliance Verification Manager
Pattern-based Expressions & Formal Control Rules
Compliance Verification Results Formal Control Rules (in LTL/ MTL)
Business Process Repository
Business Process Models & Elements
Compliance Elements (reqs., risk, controls, etc.)
Compliance Requirements Manager
Formal Check Results
Verification Handler
Compliance Repository Business Process Specifications (in BPEL)
Dashboard (Design-time)
BP SPecification (in Promela Lang.)
Selected Formal Control Rules (in LTL/MTL) & BP
SPIN Model Checker
Specifications (in Promela)
WSAT for Model Transformation
Figure 2.
v1 –PrePrint Draft
A general architectural view of the toolset components
11
Case Studies: We selected case studies in the e-‐business and banking domains due to the strict and diverse regulations applied in these sectors. The case study in the banking environment involved ‘loan processing’, while the second case study was performed within an Internet reseller company and covered processes, such as order processing, invoicing, payments, ledger maintenance, and delivery. The case studies gave valuable opportunity to observe the application of the compliance management approach depicted in Figure 1a and the use of the toolset we developed. We also tested the expressiveness of the patterns in capturing control rules originating from real life requirements. The processes covered in the case studies were constrained by (in total) 59 high-‐level compliance requirements of different concerns (such as segregation of duties, information processing, authorizations, etc.) and originating from ISO/IEC 27000 (2009), Sarbanes-‐Oxley (2002) and internal policies. The team involved in the case studies comprised three compliance and two business experts, who worked together and followed our approach to identify risks and define controls to be employed on the processes. Using the Rule Manager they developed graphical pattern-‐based expressions for the controls. The approach followed by the case study team resulted 127 controls. The participants used the web-‐based CompRM tool to store and manage these concepts. The participants were able to express 90 controls (out of 127) using the Rule Modeller tool. Remaining 37 controls were either technical controls (involving rules regarding data encryption and retention) or detective process controls that cannot be expressed using patterns, as patterns are design to express preventive process patterns. In particular, the concerns relevant to control-‐flow, data, resource and temporal aspects of processes were accurately expressed with patterns. Figure 3(a) presents a screenshot of the user interface of the Rule Manager. The generated rules for the same examples that are transferred to the compliance repository are shown in Figure 3(b). Although we didn’t conducted empirical tests on the usability of the Rule Manager, initial feedback from the case study participants suggest that the graphical environment and automated
v1 –PrePrint Draft
12
transformation features of the Rule Manager would bring about significant increases on the degree of the efficiency and usability over the use of formal languages.
(a) Figure 3.
(b)
(a) A screenshot from the C. Rule Manager:
(b) Generated compliance rules to be transferred to the compliance repository
Our research and development work is ongoing in several directions to enhance and support the entire framework. The validation of the proposed concepts, and the usability and efficacy of the tools should further be intensified by their application on various case studies and empirical tests on prospective users. Compliance entails different aspects and requires knowledge of various domains. Future case studies should also consider further evaluating the efficacy of the solutions in different domains (such as health, safety, environment, etc.) to better address their unique requirements.
Acknowledgements The authors gratefully acknowledge PricewaterhouseCoopers (NL), Thales Services (FR), and other COMPAS Project Partners for their effort in providing and participating in the case studies and scenarios, and their valuable contributions.
v1 –PrePrint Draft
13
References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]
Canadian Institute of Chartered Accountants, "Guidance on Control," 1995. SOX, "Sarbanes-‐Oxley Act of 2002, U.S. Congress," 2002. Directive 2008/30/EC: Amd. to 2006/43/EC on statutory audits of annual accounts and consolidated accounts, 2008. Bank for International Settlements, "BaselII: International Convergence of Capital Measurement and Capital Standards: A Revised Framework," 2004. T. Meservy, C. Zhang, E. T. Lee et al., “The Business Rules Approach and Its Impact on Software Testing: A Case Study,” IEEE Software, vol. PrePrint, 2011. S. Sadiq, G. Governatori, and K. Namiri, “Modeling Control Objectives for Business Process Compliance,” in Business Process Management, Brisbane, Australia, 2007, pp. 149-‐164. C. Zhang, T. Meservy, E. T. Lee et al., “An Exploratory Case Study of the Benefits of Business Rules Management Systems,” in ICIS Proceedings, 2009. COSO, "Internal Control – Integrated Framework. The Committee of Sponsoring Organizations of the Treadway Commission," 1994. PCAOB, "Auditing Standard No. 5: An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements, Release No. 2007-‐005A," Public Company Accounting Oversight Board (PCAOB), 2007. O. Turetken, A. Elgammal, W.-‐J. v. d. Heuvel et al., “Enforcing Compliance on Business Processes through the use of Patterns,” in European Conference in Information Systems (ECIS), Helsinki, Finland, 2011. COBIT, "Control Objectives for Information and related Technology -‐ COBIT, 4.1. IT Governance Institute.," 2007. M. P. Papazoglou, and W.-‐J. v. d. Heuvel, “Business process development life cycle methodology,” Commun. ACM, vol. 50, no. 10, pp. 79-‐85, 2007. OCEG, "GRC Capability Model, Ver 2.0. Open Compliance and Ethics Group," 2009. IT Governance Institute, IT Control Objectives for Sarbanes-‐Oxley, 2nd Ed., 2006. C. Wolter, and A. Schaad, “Modeling of Task-‐Based Authorization Constraints in BPMN,” in Business Process Management (BPM) 2007, 2007, pp. pp. 64–79. V. Gruhn, and R. Laue, “Specification Patterns for Time-‐Related Properties,” in 12th Int’l Symposium on Temporal Representation and Reasoning, USA, 2005, pp. 198-‐191. M. Dwyer, G. Avrunin, and J. Corbett, “Property Specification Patterns for Finite-‐State Verification,” in 2nd International workshop on Formal Methods on Software Practice, USA, 1998, pp. 7-‐15.
v1 –PrePrint Draft
14
Author Biographies OKTAY TURETKEN is currently a researcher at the European Research Institute in Service Science (ERISS), Tilburg University. He holds a Ph.D. in Information Systems. His research focuses mainly on business process management, governance, risk and compliance, project management, and software measurement & prediction. Contact him at
[email protected]. AMAL ELGAMMAL is finishing her Ph.D. in Information Management at the ERISS, Tilburg University. She has been awarded for the best masters thesis at Cairo University in 2007. Her main research interests include Business process verification, business process compliance management, service-‐oriented computing, business process monitoring and auditing, and service engineering. Contact her at
[email protected]. MICHAEL P. PAPAZOGLOU is the chair of the Computer Science Department at Tilburg University. He’s also the scientific director of the ERISS and the EC’s Network of Excellence, S-‐Cube. His research interests include service-‐oriented computing, Web services, large-‐scale data sharing, business process management, and federated information systems and distributed computing. Papazoglou has a PhD in microcomputers systems engineering from the University of Dundee, Scotland. He’s a Golden Core Member and a Distinguished Visitor of the IEEE Computer Society. Contact him at
[email protected]. WILLEM-‐JAN VAN DEN HEUVEL is a full professor in computer science at the Department of Information Systems, Tilburg University, managing director of the ERISS, and program director of the Erasmus Mundus Joint-‐Degree Master Program on Service Science. His main research interests revolve around (cloud) service engineering, service governance, performance analytics of software-‐ enabled service networks, and business transaction management. Contact him at
[email protected].
v1 –PrePrint Draft
15
