Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Controls in business and IT : formalization and application Limonad, Lior 2013

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
24-ubc_2013_fall_limonad_lior.pdf [ 13.68MB ]
Metadata
JSON: 24-1.0102469.json
JSON-LD: 24-1.0102469-ld.json
RDF/XML (Pretty): 24-1.0102469-rdf.xml
RDF/JSON: 24-1.0102469-rdf.json
Turtle: 24-1.0102469-turtle.txt
N-Triples: 24-1.0102469-rdf-ntriples.txt
Original Record: 24-1.0102469-source.json
Full Text
24-1.0102469-fulltext.txt
Citation
24-1.0102469.ris

Full Text

Controls in Business and IT: Formalization andApplicationNot Every Thing is Under ControlbyLior LimonadB.Sc. Industrial Engineering and Management, Ben-Gurion University, 2001M.Sc. Information Systems Engineering, Ben-Gurion University, 2006A THESIS SUBMITTED IN PARTIAL FULFILLMENTOF THE REQUIREMENTS FOR THE DEGREE OFDoctor of PhilosophyinTHE FACULTY OF GRADUATE AND POSTDOCTORAL STUDIES(Business Administration)The University Of British Columbia(Vancouver)October 2013c? Lior Limonad, 2013AbstractControls in business are the means used to ensure business operations comply witha set of given rules, such as legal requirements, standards, and policies. Businesscompliance with regulations has gained particular importance due to the introductionof legislation to prevent business misconduct, such as the Sarbanes-Oxley Act of2002 in the U.S. One outcome is that controls are more widely used and are oftenrelated to Information Technology (IT), because IT systems are used to implementbusiness controls, and because the introduction of IT entails additional controlconcerns. Thus, control aspects should be an integral part of the analysis and designof information systems. Furthermore, information systems need to be examinedfor the completeness and correctness of their controls. Despite the importance ofcontrols, no general, well-formalized, framework is available to guide the analysisof control requirements, or the design of controls in systems.This work introduces a conceptual framework for controls, based on an ontolog-ical foundation. The framework is built upon the key notion of the control system,from which two complementary views were derived: the Enterprise View (EV)which conceptualizes control as a ?thing?, and the Process View (PV) which con-ceptualizes control as an ?action?. Based on these views, two concrete applicationswere developed to evaluate the correctness and usefulness of the underlying con-ceptual framework. A classification scheme, or a typology, was derived from theEV and can be used to manage control assets. The second application is a processmodeling grammar enrichment, which was derived from the PV and is designedto explicitly incorporate control activities in two alternative styles. Both proposedapplications were empirically evaluated, concluding their effectiveness in promotingbetter organizational compliance.iiPrefaceThe essence of the two views described in Chapter 2 and their correspondingapplications appearing in Chapter 3 were published in:? L. Limonad and Y. Wand. A Conceptual Model and Typology for Informa-tion Systems Controls. In proceedings of the 15th Americas Conference onInformation Systems, San Francisco, California, Aug. 2009.? L. Limonad and Y. Wand. Extending Business Process Models with Con-trols. In AIS Special Interest Group on Systems Analysis and Design(SIGSAND08), Provo, Utah, May 2008.I wrote both manuscripts and revised according to the comments given to me byProf. Yair Wand (co-author and my doctoral research supervisor).The empirical evaluation in Chapter 4 required the approval of the UBC Re-search Ethics Board for which ethics certificates H10-01649 and H09-03419 wereattained.iiiTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiiTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixGlossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiAcknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiDedication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv1 Introduction and Research Objectives . . . . . . . . . . . . . . . . . 11.1 About Control in Business . . . . . . . . . . . . . . . . . . . . . 11.2 Research Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 92 The Conceptualization of Controls in Business . . . . . . . . . . . . 112.1 Theoretical Foundations . . . . . . . . . . . . . . . . . . . . . . 122.2 Control as a System . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.1 The Enterprise View . . . . . . . . . . . . . . . . . . . . 192.2.2 The Process View . . . . . . . . . . . . . . . . . . . . . . 313 Application of the Theoretical Model . . . . . . . . . . . . . . . . . . 433.1 Process Model Enrichment . . . . . . . . . . . . . . . . . . . . . 44iv3.2 Control Typology . . . . . . . . . . . . . . . . . . . . . . . . . . 544 Exploring Alternative Representations of Control . . . . . . . . . . 634.1 Experimental Task . . . . . . . . . . . . . . . . . . . . . . . . . 684.2 Pilot Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . 704.3 Sample and Main Experimental Procedure . . . . . . . . . . . . . 724.4 Data Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.5 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.5.1 Multivariate Analysis of Covariance . . . . . . . . . . . . 844.5.2 Post-hoc Analysis . . . . . . . . . . . . . . . . . . . . . 854.5.3 Implicit versus Explicit Comparisons . . . . . . . . . . . 914.6 Conclusions of Empirical Results . . . . . . . . . . . . . . . . . . 945 Assessing the usefulness of the typology . . . . . . . . . . . . . . . . 1035.1 Dataset Preparation . . . . . . . . . . . . . . . . . . . . . . . . . 1055.2 Experimental Task . . . . . . . . . . . . . . . . . . . . . . . . . 1075.3 Delphi Round One . . . . . . . . . . . . . . . . . . . . . . . . . 1095.4 Delphi Round Two . . . . . . . . . . . . . . . . . . . . . . . . . 1115.5 Delphi Round Three . . . . . . . . . . . . . . . . . . . . . . . . 1135.6 Delphi Round Four - Final . . . . . . . . . . . . . . . . . . . . . 1155.7 Conclusions and Lessons Learned from the Delphi Experiment . . 1166 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1206.1 Research Summary . . . . . . . . . . . . . . . . . . . . . . . . . 1206.2 Contributions to Research . . . . . . . . . . . . . . . . . . . . . . 1226.3 Contributions to Practice . . . . . . . . . . . . . . . . . . . . . . 1236.4 Limitations of the Research . . . . . . . . . . . . . . . . . . . . . 1246.5 Future Research Directions . . . . . . . . . . . . . . . . . . . . . 126Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135A Enterprise View - Detailed Formalization . . . . . . . . . . . . . . . 136vB Experimental Results and Assumption Testing . . . . . . . . . . . . 141B.1 MANOVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141B.2 MANCOVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142B.3 Post-hoc Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 143B.4 Assessment of Analysis Assumptions . . . . . . . . . . . . . . . 145C Third-party Control Authorities . . . . . . . . . . . . . . . . . . . . 151D Process Model Enhancement - Experimental Materials . . . . . . . 153D.1 Student Registration Case . . . . . . . . . . . . . . . . . . . . . . 154D.2 Student Registration - Implicit Representation . . . . . . . . . . . 155D.3 Student Registration - Procedural Representation . . . . . . . . . 156D.4 Student Registration - Declarative Representation . . . . . . . . . 157D.5 Mortgage Application Case . . . . . . . . . . . . . . . . . . . . . 158D.6 Mortgage Application - Implicit Representation . . . . . . . . . . 159D.7 Mortgage Application - Procedural Representation . . . . . . . . 160D.8 Mortgage Application - Declarative Representation . . . . . . . . 161D.9 Questionnaire Booklet . . . . . . . . . . . . . . . . . . . . . . . 162D.10 BPM and Business Control - Training Slide Deck . . . . . . . . . 175E Control Typology - Experimental Materials . . . . . . . . . . . . . . 183E.1 Business Control Model Overview and Specification Brochure . . 184E.2 Business Control Data Sets - Training and Validation . . . . . . . 187E.3 Questionnaire - Round One . . . . . . . . . . . . . . . . . . . . . 195E.4 Control Typology - Training Slide Deck . . . . . . . . . . . . . . 197viList of TablesTable 1.1 Control interpretations . . . . . . . . . . . . . . . . . . . . . . 3Table 2.1 Clarification of terminology differences between my model andthe auditing literature . . . . . . . . . . . . . . . . . . . . . . 26Table 3.1 Notation used to formalize typology dimensions . . . . . . . . 55Table 3.2 Typology dimensions . . . . . . . . . . . . . . . . . . . . . . 59Table 3.3 An example for the classification of payroll system controls (ICis the payroll system unless otherwise indicated) . . . . . . . . 61Table 4.1 Descriptive statistics (prior to outlier omission) . . . . . . . . . 73Table 4.2 Student registration - treatment-wise descriptive statistics (priorto outlier omission) . . . . . . . . . . . . . . . . . . . . . . . 74Table 4.3 Mortgage application - treatment-wise descriptive statistics (priorto outlier omission) . . . . . . . . . . . . . . . . . . . . . . . 74Table 4.4 Sample - background knowledge (1-7 scale) . . . . . . . . . . 75Table 4.5 Domain comprehension (student registration) . . . . . . . . . . 76Table 4.6 Compliance comprehension (student registration) . . . . . . . 76Table 4.7 Domain problem-solving (student registration) . . . . . . . . . 76Table 4.8 Compliance problem-solving (student registration) . . . . . . . 77Table 4.9 Domain comprehension (mortgage application) . . . . . . . . 77Table 4.10 Compliance comprehension (mortgage application) . . . . . . 77Table 4.11 Domain problem-solving (mortgage application) . . . . . . . . 78Table 4.12 Compliance problem-solving (mortgage application) . . . . . . 78Table 4.13 Ease of use - reliability and validity . . . . . . . . . . . . . . . 78Table 4.14 Inter-rater reliability - cronbach?s alpha . . . . . . . . . . . . . 79viiTable 4.15 Descriptive statistics - (outliers omitted) . . . . . . . . . . . . 81Table 4.16 Student registration - treatment-wise descriptive statistics (out-liers omitted) . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Table 4.17 Mortgage application - treatment-wise descriptive statistics (out-liers omitted) . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Table 4.18 Manipulation-checks - actual representation versus post-test an-swers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Table 4.19 Testing treatment effect - student registration - adjusted-meancomparisons . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Table 4.20 Testing treatment effect - mortgage application - adjusted-meancomparisons . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Table 4.21 Summary of all significant post-hoc pair-wise comparisons -student registration . . . . . . . . . . . . . . . . . . . . . . . . 86Table 4.22 Summary of all significant post-hoc pair-wise comparisons -mortgage application . . . . . . . . . . . . . . . . . . . . . . 88Table 4.23 Student registration - adjusted-mean comparisons . . . . . . . 92Table 4.24 Mortgage application - adjusted-mean comparisons . . . . . . 93Table 4.25 Student registration - time comparisons . . . . . . . . . . . . . 93Table 4.26 Mortgage application - time comparisons . . . . . . . . . . . . 94Table 4.27 Summary of results . . . . . . . . . . . . . . . . . . . . . . . 95Table 5.1 Delphi experiment timeline . . . . . . . . . . . . . . . . . . . 104Table 5.2 Control specification attributes . . . . . . . . . . . . . . . . . 106Table 5.3 Round one results . . . . . . . . . . . . . . . . . . . . . . . . 110Table 5.4 Round two results . . . . . . . . . . . . . . . . . . . . . . . . 112Table 5.5 Round three results . . . . . . . . . . . . . . . . . . . . . . . 114Table 5.6 Round four results - typology validity . . . . . . . . . . . . . . 116Table 5.7 Fire door alarm - control specification . . . . . . . . . . . . . . 117Table E.1 List of controls (?training set?) . . . . . . . . . . . . . . . . . 187Table E.2 List of controls (?validation set?) . . . . . . . . . . . . . . . . 191viiiList of FiguresFigure 2.1 Bunge?s ontology - core concepts (static view) . . . . . . . . 15Figure 2.2 Ontological model . . . . . . . . . . . . . . . . . . . . . . . 17Figure 2.3 Control model as an ontological specialization . . . . . . . . 20Figure 2.4 Enterprise view . . . . . . . . . . . . . . . . . . . . . . . . . 21Figure 2.5 Basic concepts in the GPM . . . . . . . . . . . . . . . . . . . 33Figure 2.6 Course registration process . . . . . . . . . . . . . . . . . . . 35Figure 2.7 Process model extended with control . . . . . . . . . . . . . . 37Figure 2.8 Registration process enactment . . . . . . . . . . . . . . . . . 39Figure 2.9 Course registration process with control . . . . . . . . . . . . 40Figure 3.1 Declarative / procedural control representations . . . . . . . . 49Figure 3.2 Passenger?s identity verification . . . . . . . . . . . . . . . . 50Figure 3.3 Semantic structures . . . . . . . . . . . . . . . . . . . . . . . 52Figure 3.4 IIA control concerns . . . . . . . . . . . . . . . . . . . . . . 60Figure 4.1 Data exploration - box-plot for outlier removal . . . . . . . . 80Figure 4.2 Compliance comprehension (student registration) . . . . . . . 87Figure 4.3 Domain problem-solving (mortgage application) . . . . . . . 89Figure 4.4 Compliance problem-solving (mortgage application) . . . . . 90Figure 4.5 Ease of use (mortgage application) . . . . . . . . . . . . . . . 91Figure 4.6 Domain comprehension . . . . . . . . . . . . . . . . . . . . 98Figure 4.7 Compliance comprehension . . . . . . . . . . . . . . . . . . 99Figure 4.8 Domain problem-solving . . . . . . . . . . . . . . . . . . . . 100Figure 4.9 Compliance problem-solving . . . . . . . . . . . . . . . . . . 101Figure 4.10 Ease-of-use . . . . . . . . . . . . . . . . . . . . . . . . . . . 102ixFigure 5.1 Delphi questionnaire . . . . . . . . . . . . . . . . . . . . . . 108Figure B.1 BPMN Knowledge vs. Compliance Comprehension . . . . . . 149Figure C.1 Control enforcement using a third-party . . . . . . . . . . . . 152xGlossaryANOVA Analysis of VarianceBPMN Business Process Modeling NotationWW Wand-Weber, referring to the Wand & Weber?s adaptation of Bunge?s ontologyEV Enterprise ViewGPM Generic Process ModelGRC Governance, Risk Mitigation, and ComplianceIIA The Institute of Internal AuditorsIS Information SystemIT Information TechnologyMANOVA Multivariate Analysis of VarianceMANCOVA Multivariate Analysis of CovariancePV Process ViewUML Unified Modeling LanguagexiAcknowledgmentsMy genuine thanks go to my academic advisor, Professor Yair Wand. This work wasone of the most ambitious challenges I have ever embarked upon. I can definitelysay that without Yair?s guidance and persistent help, this work would not have beenaccomplished. I will forever be in debted to Yair, not only for his endless devotionin conveying a spirit of adventure with regards to my research, but perhaps moreimportantly, for doing so in a way that allowed me to accomplish this milestonein my own unique manner. Yair will soon retire, and I would like to take thisopportunity to wish him the best of luck, and many more years of health andenjoyment with his family. That said, I am not ready to release him from hiscommitment to collaborate on joint research in the future. He will simply be able toenjoy it all the more so.I would like to thank the other members of my supervising committee: Prof.Ron Weber, Prof. Andrew Burton-Jones, and Prof. Carson Woo. I would like tothank each personally for the effort and devotion in providing me, of their own freewill, with highly effective and professional advice, and directing me towards thesuccessful completion of this work.My sincere appreciation goes to the friendly members of the UBC Audit team:Michael Hartwick (director), Jean Change, and Sandra Woolley. The few monthswe spent together provided me with invaluable insight, and crucial input, whichturned out to be a significant portion of the findings in this work.Special thanks goes to the phenomenal MIS faculty and staff at the UBC SauderSchool: Prof. Izak Benbasat who admitted me to the program and later taught mewhat good research in MIS is all about; William Tan, the most talented lecturer andthe kindest person I have ever worked with; and Elaine Cho, whose expertise andxiicordial support as the PhD program administrator have been exceptional.My thanks also goes to Prof. Victoria Lemieux at UBC SLAIS for letting meexperiment with some of my core ideas while gaining additional experience inmodeling in the context of the financial domain.A special thank you to the new friends I acquired along the way, while living inVancouver: my colleague at the MIS program Michael Wufka, our dear friends Eliand Claudia Joseph, and Miri and Larry Garaway.My deepest gratitude goes to my beloved grandmother Ita Kaufman and to mydear parents Cila and Jacob Limonad for making this work possible and for theirendless love and support despite the remote distance. Likewise, I would like toexpress my appreciation to my in-laws Irit and Yehuda Ben-David.Finally, the most heartfelt and deepest thanks go to my dearest wife Sigal andto our precious son Yotam, who not only gave me endless amount of support, butmore importantly showed forgiveness for all the many hours and weekends I spentaway from our precious family. I know it was a long and arduous journey. It was alife-changing experience for all of us. I hope that now that it is over, we will be ableto devote more time to pursue the other plans we have set for ourselves in life. Yetit is crystal clear that without this support, it would have been impossible for me tocross the finish line.xiiiDedicated to my beloved grandmother Ita Kaufman,the last holocaust survivor in my family.xivChapter 1Introduction and ResearchObjectives1.1 About Control in BusinessThe notion of control in business is commonly intepreted as the internal control,which is derived from risk theory and adapted by accounting and auditing prac-tices [24]. According to this interpretation, control is a process (i.e., an activity)that is meant to ensure the effectiveness and efficiency of operations, reliabilityof financial reporting, and compliance with laws and regulations. However, thisinterpretation is one of many that cover the general idea of control in business. Forexample, according to [4] which is mainly focused on the ?control revolution? asa kind of a societal shift, the basic notion of control is considered as ?purposiveinfluence towards a predetermined goal.? [4, p. 7] This definition implies ?twoessential elements: influence of one agent over another, meaning that the formercauses changes in the behaviour of the latter, and purpose, in the sense that influenceis directed toward some prior goal of the controlling agent.? [4, p. 7] Inherent tothe notion of organization, control is described as essential, building on John VonNeumann?s perspective who was ?the first to argue that the difference between orderand organization is that the latter always includes ?purposive? or end-directedness.?[4, p. 35] More specific to business and government use of control, it is referred to asintellectual technology: ?the substitution of algorithms (problem solving rules) for1intuitive judgments. Intellectual technology is another manifestation of bureaucraticrationality...administration based not on intuitive judgment but on logical and sta-tistical rules and algorithms.? [4, p. 21] As part of the discussed control revolutionin the context of its use in business and governments, it is described to have beenevolved from originally being ?depended on personal relationships and face-to-faceinteractions; now control came to be re-established by means of bureaucratic or-ganization, the new infrastructure of transportation and telecommunications, andsystem-wide communications via the new mass media.? [4, p. 7]Overall, the term control is loaded with a plethora of sometimes inconsistentmeanings, stemming from various fields. Table 1.1 lists the various interpretationsof this concept, along with their sources. Unifying the similarities between theseinterpretations yields the following two distinct insights:? Control as a general notion can refer to either actions (i.e., control as a verb) orthings (i.e., control as a noun) in the organizational environment. For example,a fire-sprinkler and the requirement to change a password are both means ofcontrol. Both stem from risk considerations and compliance. For example,a fire-sprinkler is typically installed as part of safety regulations aimed atmitigating the risk of unexpected fire ignitions. Similarly, password-changingis typically required by information security policies set to govern informationprivacy and authorized actions. However, a fire-sprinkler is a thing (i.e., anoun) and password-changing is an action (i.e., a verb). This dichotomyrefers to the nature of the control means itself and not to its purpose, which,for example, might be associated with a business event, state, or asset. Suchaspects are considered later in this work as part of the development of abroader control typology.? In either form, whether action or thing, controls exist to ensure one or moreof the following business interests:? Governance - through the attainment of organizational objectives asreflected in internal policies, business rules, and organizational norms.Governance as a general business interest reflects all efforts devotedto achieving an alignment between operations and strategy [67, 68].2Source Control definitionControl SystemsTheory [13]A control system is an arrangement of physical compo-nents connected or related in such a manner as to com-mand, direct, or regulate itself or another.Control in Generaland Industrial Man-agement [18]Control consists of verifying whether everything occursin conformity with the plan adopted, the instructions is-sued, and principles established. Its object is to point outweaknesses and errors in order to rectify them and preventrecurrence.Risk Management[ISO/IEC Guidestandard 73:2002]Control/Safeguard risk reducing measures implementedby the organization to minimize or eliminate the likelihood(or probability) of a threat?s exercising a system vulnera-bility.Process ControlSoftware [38]The purpose of a control subsystem is to order events andregulate the value of the variables in the system to optimizethe achievement of the system.Accounting and Or-ganizational Theory(The IIA)Internal controls: A process, effected by an entity?s boardof directors, management, and other personnel, designedto provide reasonable assurance regarding the achievementof objectives in the following categories: a) Effectivenessand efficiency of operations; b) Reliability of financialreporting; and c) Compliance with laws and regulations.IT controls: Those processes that provide assurance forinformation and information services and help mitigate therisks associated with an organization?s use of technology.Information Sys-tems Control andAudit [74]A control is a system that prevents, detects, or correctsunlawful events.Table 1.1: Control interpretations3In this regard, control is a means to ensure alignment is achieved. Anexample for a control mechanism that reflects this concern is the periodiccounting of inventory levels conducted in retail stores. This action (i.e.,control) verifies that all supply operations perform adequately, ensuringthat all inventory levels meet customer demands, as per the businessobjective.? Compliance - through the adherence of all activities to business-imposedconstraints such as laws, regulations, and standards. This reflects thefact that the business is not an independent organism. The complexnature of the enterprise environment, recent worldwide events such asthe September 11 terrorist attacks in the U.S., and incidents of companymisconduct such as Enron and WorldCom, have led to a proliferationof legal acts (e.g., Sarbanes-Oxley Act [37]), regulations, standards,and best practices (e.g., COSO1, COBIT2, and ITIL3) to which compa-nies must adhere. Control plays an important role in ensuring that allexternally-imposed constraints are met. For example, a three-page formthat guides the maintenance, inspection, and testing of fire-sprinkler sys-tems is a control that adheres to the National Fire Sprinkler Association,Inc. (NFSA) 25 - Standard for Testing, Inspection, and Maintenance ofWater-Based Fire Protection Systems.? Risk mitigation to reduce the likelihood of any harm or damage to anyasset (e.g., financial or physical) or human being. This concern is part ofthe overall risk management effort, according to which risks reflect thepotential that a given threat will exploit the vulnerabilities of assets tocause loss, damage, or otherwise negatively affect the accomplishmentof business activities [32]. In this regard, controls are risk-mitigatingmeasures that should prevent, or at least reduce, the likelihood of a riskevent occurring, detect the occurrence of a risk event, minimize theimpact of a risk event, or transfer the risk to another business unit (e.g.,insurance). Elevator inspection is an example of a preventive control1www.coso.org2www.isaca.org3www.itil.org4action that reduces the probability of a malfunction occurring in theelevator, which could lead to a disaster.As the examples above demonstrate, there may be an overlap in the interestsaddressed by the different control mechanisms. For example, sprinkler inspectionsreflect both compliance and the mitigation of risks. In traditional business settings,the capacity of organizations to substantiate compliance, implement faithful gov-ernance, and mitigate risks is the target of auditing inspections [74]. As in [56],verification actions such as the checking of bills, and seeking of a second medicalopinion, are part of human rationality. In social environments avoiding such actionsis a pragmatic outcome replaced by the dependency on trust. In institutionalizedenvironments the level of reliance on trust is equivalent to the types of risk to whicha company feels vulnerable. However, all such checking, whether at the level ofindividuals, or of institutes, is referred to as audit.Control systems are mentioned as one of three areas audit depends upon: sam-pling, external expertise, and controls. As such, controls are considered as sub-stitutes for direct checking the objects of auditing. Such systems are consideredauditable objects as stated: ?If one can have confidence that a system exists to con-trol the completeness, accuracy, and validity of transactions between an organizationand its environment, then it is unnecessary to duplicate this work and look at thetransactions in detail. First order control exists in the organization and the externalaudit function acts as a second order control of the first order control system; auditis control of control.? [56, p. 82]Auditors focus on whether on not administrative controls have been well-designed and whether or not they are operating effectively. Traditionally, theseconcerns are governed by annual audit planning and review cycles. More recently,there has been an expressed desire to have such audit activities shift from followingan after-the-fact style of execution to a continuous type of auditing based on rapidresponse to organizational activities and updated information [1, 35]. The latterstyle requires organizations to adopt more innovative IT that is focused on detectingor investigating fraud, performing control self-assessments, monitoring compli-ance activities, and assessing risks; such systems can promote a more systematicmanagement of controls. A recent study of IT audits indicates that the current5reality remains far from attaining this vision, and the majority of organizations (59.8percent of the 138 organizations participating in the study) refrain from using suchsystems. A lack of software applicability to their domain was cited as the mostsignificant reason for this refrain [25]. In light of the current reality, the contributionof this work may be signified as an important step towards laying the conceptualgroundwork for the design and creation of tools to control asset management andprocess monitoring software.The importance of controls for governance, risk mitigation, and complianceGovernance, Risk Mitigation, and Compliance (GRC) is reflected in increased budgetcompanies are allocating for these three concerns. According to industry reports[27], in 2007, companies? overall spending on their governance, risk management,and compliance budget saw an 8.5 percent increase from the same investment in2006 and a similar increase was expected between 2007 and 2008. According toGartner research [14] focused on the market for software that supports corporategovernance, risk management, and compliance, the total software revenue forthis emerging market was expected to grow approximately 24 percent annually,rising to $1.3 billion in 2011. This increase was later evidenced in a 16.3 percentincrease to a total revenue of $3 billion for the financial performance, strategymanagement, and GRC applications market [46]. The importance of investingin GRC is now increasing sharply in light of the current economy. According toForrester Trends 2009 (Forrester Research, Inc. [45]), in reaction to the most recentcredit crisis, professionals responsible for GRC will play a major role in transformingthe corporate landscape to reduce the possibility of another such collapse. Morerecently, a report by the Carnegie Mellon CyLab [75], surveyed 108 respondents atthe board or senior executive level from Forbes. The CyLab 2012 survey concludedthat governance of enterprise security is still lacking in most corporations.Based on the above, and despite the lack of a single definition as evidencedin Table 1.1, it is clear that control is an integral part of the business. Moreover,to improve the efficiency and effectiveness of business operations, it is vital thatcontrol activities and control assets be clearly articulated, and become an integralpart of all other business analysis, design, and planning activities. The importance ofunderstanding the nature of control becomes even more crucial when conforming tothe view of organizations as sociotechnical systems. All organizations are sociotech-6nical systems [10], representing a combination of people and technology. Accordingto this view, organizational objectives are best met by the joint optimization of itssocial and technical aspects. IT is in the veins of almost every business infrastructureand intertwined with business activities. Thus, it is inevitable that control is alsocoupled with the IT applications of any organization. The nature of this interplaybetween IT and control originates in the different roles IT can play in organizationalsettings. These roles and the link between IT and control are discussed next.The term IT is probably even more loaded than control, especially in InformationSystem (IS) research. In sociotechnical systems, there are three ways to view the roleof IT [54]. IT can be considered in its most narrow definition as the technology sideof an IS [66] (i.e. IT as a tool), including hardware, databases, software, networks,and so forth. However, sometimes the term IT is used interchangeably with IS, orit may also be used in a broad way to describe a collection of systems, users, andmanagement for an entire organization (i.e., part of the sociotechnical system). Eachview implies a different link between IT and control in the business. The natureassociated with each view is as follows:1. IT as a tool - According to this view, IT is considered an engineered artefact(e.g., software and hardware), expected to do what its designers intended. Inthis view, IT may be used to help implement controls. This purpose is well-expressed in industrial best-practices and guidelines for the implementationof controls in the business (e.g., COBIT [33]).2. IT as an IS - According to this view, an IS is considered to be a representationof some corresponding domain, such as the business domain as in the contextof this work [73]. In this context, IS reflect control considerations and canbe used as the target of control processes to ensure that the business behavesas desired. As a representation of the organization, the state of the IS mayalso reflect the state of control activities. Thus, in this view, the IS can also beused as the target for auditing that is meant to verify that all controls are inplace and operate adequately.3. IT as a heterogeneous system - This view refers to IT as a part of the sociotech-nical system and the ensemble view mentioned in IS research [54], according7to which the IT artefact should be considered within a socio-economic context.As such, IT can be considered as a middleware in the context of controls. ITis responsible for promoting the establishment of communicative channels,safeguarding access to assets and sensitive information, authorizing and au-thenticating identity, accounting for information privacy and integrity, andorchestrating activities (e.g., a Workflow Management System [76]).Summarizing the three views above, the motivation for controls is twofold withrespect to IT. First, IT is used as an enabler to enforce control objectives in thebusiness and improve the effectiveness and efficiency of enforcement procedures.Second, the integration of IT into the business itself entails an additional needfor controls that ensure the adequate behaviour of all integrated IT artefacts. Forexample, from the view of IT as an Information System, a company may integrate anew payroll IS to ensure timely payments to all employees. This integration itselfrequires setting up data-backup procedures to ensure the integrity and continuity ofthe payroll IS.There are many other control mechanisms embedded within the organizationalenvironment such as: warning signs, fire alarms, template forms, reports, inspectionprocedures, and security measures. There are also specific IT-related controlssuch as: real-time error notification, input validation, exception handling, userauthentication, data backup, and the like. Being able to explicitly refer to controlconcerns and control mechanisms within the organization is implied by the needto demonstrate and justify compliance with regulations and standards, optimizeattainment of corporate goals, and minimize the associated risk. Without a clearunderstanding of the nature of controls in business, it is hardly possible to classifyexisting controls and related control concerns; to determine if sufficient controlmechanisms are in place; to analyze if there is efficient coverage or redundancyof controls; to determine and optimize the necessary resources to be allocated forcontrols; to integrate new controls into the business; to create tools and techniquesto deal with control concerns; and to communicate control considerations withinand outside the business environment. Despite this essence, there is no generallyaccepted well-defined notion of control in business, nor does there exist any analysisand design technique that can set the ground for the corresponding managerial8activities to deal with controls in organizational settings.1.2 Research ObjectivesSeeking to address fundamental research on the essence of control in business, thenature of this study is mainly exploratory. Its overarching goal is: (1) to suggesta clear conceptualization of the notion of controls in the business domain, andcomplementary to that, (2) to provide preliminary insight regarding the potentialgain from realizing such a conceptualization in practice. The latter is obtained bytwo empirical observations. Posed in terms of research questions, the two corequestions being focused on are:? ?What is a business-control??, and complementary to its definition,? ?How can this definition be used to derive concrete operational applications??Corresponding to this high-level goal, more concrete actionable objectives havebeen devised as follows:1. Construct and specify a well-defined conceptualization (definition) of thegeneral notion of control in business, and specifically unify it with the concreteview of IT controls.2. Demonstrate how the constructed formalization can be applied to the benefitof any organization that has to deal with the challenges discussed above (e.g.,GRC). This part includes two4 concrete applications being derived from thedeveloped conceptualization:(a) Development and evaluation of a concrete business process modelinggrammar that is extended with the capacity to express concrete processmodels (i.e., scripts) that include control activities.4My original research proposal also included a third application proposing a designated softwarearchitecture that automates control enforcement in business process execution. Due to scope limitation,it was decided jointly with my supervising committee to eventually omit it from being further evaluated.However, the core basis for this contribution was published in [41]9(b) Development and evaluation of a unified classification scheme (i.e., atypology) that can assist with the analysis, integration, and managementof business controls.The rest of this document is structured as follows: Chapter 2 describes the theo-retical foundations that were developed to define the notion of control in businesscorresponding to the first objective. Chapter 3 describes the two applications thatwere derived from the core concepts in the previous chapter. This includes an ex-tended Business Process Modeling Notation (BPMN) modeling grammar designed todescribe process models with controls, and a typology for analyzing controls assets.Each of the two applications has been systematically evaluated. A description ofboth assessments and their results and conclusions are included in Chapters 4 and 5,respectively. Chapter 6 details contributions and limitations of this research.10Chapter 2The Conceptualization ofControls in BusinessThis chapter summarizes the first contribution of this research work and aims toprovide a well-defined model that can be used to adequately describe the elementsin the business domain typically referred to as controls (i.e., controls as things), andtheir operations (i.e., controls as actions).The model itself may be considered the domain?s ontology, formally known as amaterial or regional ontology [31]. Such an ontology is an independent descriptionof concepts, their possible relationships, and corresponding axioms, all subjectto a certain domain of phenomena. According to this view, the different modelconstituents, such as the constructs, relationships, and constraints developed in thischapter, serve to reflect the various concepts, relationships, and axioms that underliethe domain of business controls. However, as described later in this chapter, I alsouse the notion of an ontology to provide a clear meaning for the different modelingconstructs. In this regard, I consider an ontology as being closer to the notion of afundamental theory, providing the categories and relations that appear across manydomains and which are, in principle, applicable to reality under any perspective.As described in the previous chapter, a holistic view of control typically refersto it in the organizational context as a system [74], comprising various controlcomponents; these components are aimed at ensuring that various business goals areattained. Considering the business domain as part of the real world, an ontology such11as the one devised and stipulated by Bunge [7] can provide the conceptual meaningsto the substantial constituents in this domain. Furthermore, in accordance with thisontological view, the analysis may be conceptually split between the investigation ofexistence, as the main focus of ontological studies, and the investigation of change,with substantial individuals ? ?being in a flux? [7]. This separation is also in perfectalignment with the aforementioned distinction between ?control as a thing? and?control as an action?. Similarly, this form of conceptual separation between thetwo perspectives has been adopted in existing modeling paradigms and methods.One of the most prominent in this regard is the Unified Modeling Language (UML)[53] for software. UML currently offers a family of 14 diagram types divided intotwo categories: structural (static) and behavioural (dynamic). In this work, I referto the static category as the Enterprise View (EV) and to the dynamic category asthe Process View (PV). Specifically, the enterprise view is focused on the natureof controls as business artefacts, and the process view is focused on the nature ofcontrols as business activities.The two views are not distinct; rather, they should be considered complementaryto one another when analyzing the domain. For example, a fire-sprinkler as acontrol mechanism can be considered as a thing installed to prevent fire fromspreading. The same control thing can also be considered a preventive action(i.e., ?to extinguish fire?) triggered by the event of a fire starting, yet ignorantof its materialized characteristics. This kind of abstraction breakdown is usefulin modeling (e.g., [36]). It serves to reduce the overall complexity in systemsanalysis and simplifies the interpretation of scripts (e.g., diagrams) by the differentstakeholders who might take part in it.The next section describes the theoretical foundations and the underlying defini-tion of control that will be used to elaborate extended formalizations for controls inboth views. The subsequent two sections describe each view and its correspondingmodel of control.2.1 Theoretical FoundationsIn this work, I use an ontological formalization to provide the semantic interpre-tations for controls and related terms. In general, ontology is the philosophical12discipline that studies the core elements and relationships that exist in a certainuniverse of discourse. More specifically, I use Bunge?s ontological view [7, 8] andits adaptation to IS modeling [69, 71?73]. This approach has been found suitablefor the following reasons:1. The concrete universe of discourse in this work is the organizational domainwhich includes the controls this work is intended to clarify. Bunge?s ontologyis capable of explaining the nature of existence in the real physical world, ofwhich all organizations are a part. Thus, it is expected that any real-worldphenomenon that exists inside the organizational domain, which is part of thereal world, can be described using Bunge?s ontological concepts.2. In its core, Bunge?s ontological model includes the concepts of ?state?, ?event?,and ?law?. These concepts encapsulate two essential capacities. First, Bunge?sontology is sufficiently equipped to describe control issues such as complianceand adherence to regulations, policies and standards since all can be viewed asspecial cases of laws. Second, it includes enough concepts to describe both thestatic and the dynamic perspectives of the real world. These two perspectivescan support the two views of the business domain that this research aims atformalizing. Consequently, it is also expected that Bunge?s ontology can beutilized to formalize each of these views.3. Part of the objectives of this research is to develop techniques or to enrichexisting ones with the ability to support the task of IS analysis and design whencontrol considerations are an inseparable concern. The Wand-Weber (WW)adaptation of Bunge?s ontology to IS modeling [69, 71?73] views informationsystems as a representation of some reality. Therefore, for the purpose ofIS analysis and design, any phenomenon in the real world that should berepresented by the IS is determined by its essence in the ontological view.Since Bunge?s ontology has already been found useful for this purpose, thereis already a considerable portion of the ontological formalism linked to IS.Thus, using Bunge?s ontology also contributes to research by enabling theextension of this knowledge and accumulating the missing parts that relate tocontrol considerations.13The following section details the parts in Bunge?s ontology that are relevant tothis research and the need to clarify the notion of control. According to Bunge, theworld is made of things that possess properties. Things can be composite or simple.In the ontological view, every part of a thing is also a thing itself. There are twoclassifications for properties. First, a property can be intrinsic to things, such asmass, or mutual to several things, such as properties shared through interactions(e.g., a student?s registration in a course). Second, for composite things, propertiescan be inherited or emergent. Properties in the ontological view are substantial.Their existence is independent of any observer. However, human beings tend toabstract the world through consciousness and their ability to associate things withcertain features. To enable this, things may be described by attributes, which arehuman representations of the inherent properties of things. Any subset of propertiesof a thing may be represented by zero, one, or more attributes (i.e., a many-to-manyrelationship). The realization of an attribute may be achieved by a time-valuedfunction or using a predicate. For example, the thing ?my-car? may be attributedthe color red either by a function color(my-car,now) returning the value ?red? orby the predicate color(?my-car?,?red?), which is expected to hold as long as thecorresponding substantial property of being red is possessed by my car.To clarify the views and the underlying ontological conceptualization, I use atechnique of meta-modeling. A meta-model is a popular technique, frequently usedto communicate the grammars and semantics of a modeling language or ontology(see next subsection). The constructs of a modeling language and their relationshipsare explained in the meta-model, a higher level modeling language, which in somecases utilizes the same modeling grammar of the described language. As noted byEvermann [16], a first attempt to produce a meta-model for Bunge?s ontologicalmodel was conducted by Rosemann and Green [58]. However, the meta-modelgenerated referred only to the static part of the ontology and not to the dynamicaspect. Evermann developed a more exhaustive model in [17]1. Due to the timing ofthis latter work, I initially began developing a model myself. After becoming awareof this related contribution, I validated and adjusted my model accordingly. Whiledoing so, I considered only the relevant subset of constructs needed as a basis for1For brevity, the entire model is actually not reported in the paper. I had contacted its author, JoergEvermann, who had sent me a copy of it. Unfortunately, it is not available as a public resource.14Figure 2.1: Bunge?s ontology - core concepts (static view)the conceptualizations developed in my work. In this work, I further elaborate therelevant part of Bunge?s ontology that adheres to the dynamics of a business processusing UML notation [www.omg.org]. The core part of the ontological conceptsdescribed earlier and their relationships are illustrated in Figure 2.1.An important ontological postulate relates to change in the world. As mentionedabove, according to the ontological view, all things are in flux and under continuouschange. To enable this dynamic view of the world, the ontology introduces the basicconcept of a state. The set of attribute values of a thing at a given time is termedthe state of that thing. Each attribute function (of time) is termed a state variable.In the ontological view, there are also interactions among things. An interactionamong things is defined in terms of their effects on each other?s states.When a thing changes one or more of its property values, humans perceivethis change as a change of state, termed an event. Events are either internal, andcaused by internal actions in the thing, or external, and caused by interactions with15other things. An important ontological determination is about the role of laws in theworld. This aspect is crucial to this work since it strongly relates to the challenge ofdealing with mechanisms aimed at ensuring adherence to various restrictions (e.g.,controls). According to the ontological view, there are four different types of statesa thing may be at. Any state is either stable or unstable and any state is either lawfulor unlawful. Not all states are possible and not all transitions can occur betweenstates. Correspondingly, some events are lawful and some are unlawful. The rulesgoverning possible states and state changes are termed state laws and transitionlaws, respectively. A state law is any restriction on the possible values of attributesin the corresponding universe of discourse. A transition law is any restriction on thepossible transformation between lawful states. State and event laws may be eitherthe reflection of nature?s restrictions or a reflection of human policies. Figure 2.2summarizes the ontological model presented in this section.16Figure 2.2: Ontological model172.2 Control as a SystemA basic definition for the general notion of control in business is needed in order todevelop a broad conceptualization of control in the enterprise and process views.Informally, controls are the things in the business that ensure everything proceeds asdesired and as required by some rules (e.g., internal policies). To better formulatethis definition, I adapt the basic definition of a control system from Wand and Weber[70, 74]. This definition relies on the same ontological foundations and is thereforewell-suited to the general view of the organization. According to this view, a controlsystem is defined as follows.Definition 1. A Control System is any system that either prevents, detects, orcorrects unexpected transitions (i.e., events) or unexpected states of another system.The word ?unexpected? in this definition is subject to two possible interpretations:it may refer to either ?unforeseen? states or events, or to ?undesired? ones, whichare foreseen but not desired. In this work, the latter interpretation is chosen (i.e.,?undesired?) as being the target for control since the former cannot be explicated ina concrete control system specification reflecting states or events that simply cannotbe anticipated.As mentioned in the opening to this chapter, the control model I developed,including both perspectives, may be considered a domain-specific ontology [31]with respect to the business control domain. Figure 2.3 illustrates this idea, showinghow the developed control model, including its two views of a control system,corresponds to the ontological conceptualizations. As illustrated, the Control Systemdomain is a part of the Substantial World, while each of its constituents can beconceptualized as specializations (i.e., types) of the higher ontological concepts.The focus in each of the two aforementioned views is also illustrated. For example,the EV focuses on the ?control thing? concept being conceptualized as a specifictype of a thing. In the subsequent section this view is further elaborated to clarifythe interplay between controls and other things that are also parts of the businessdomain. The PV focuses on the ?control action? concept being conceptualized as aspecific type of an event. Similarly, its related subsection further elaborates on the18correspondence between more specific control actions (i.e., prevention, detection,and correction) and other business operations.2.2.1 The Enterprise ViewThe EV of a control system [40] introduces a conceptual model for control thatclarifies the role of controls as things or artefacts in the organizational environmentand the nature of their relationships to other things that reside in the business. Tobegin a discussion of these things, I will first extend the underlying ontologicalmodel with the concepts: domain and domain behaviour; these concepts werepreviously formulated according to the same ontological view in [61, 63].A domain is a collection of things comprising a set of things and their interac-tions. The domain itself is not an ontological thing but a representation of a partof the world we want to model. A domain can be described in terms of its statevariables. A domain?s state is the combined state of the things in the domain. A(sub)domain is a part of the domain, modeled by a subset of the state variables ofthe domain. Logically, given a set of things, a domain is any specified projectionover the union of all things? state variables. The result of such a projection is asubset of the origin state variables.Formally, linked to the ontological foundations, a (sub)domain D is modeledin terms of a set of state variables XD =< x1...xn > where xk = fk(t) are attributefunctions. The set of possible states in the domain is denoted: SD = {< x1...xn >}.Changes in a (sub)domain can occur due to internal transformations, determinedby the domain transition laws of all things in it, and due to interactions with thingsoutside the (sub)domain. The latter are termed external events. When a domain statecan be changed by an internal transformation, it is termed unstable. If a domainstate can only be changed by interactions with an external thing it is termed stable.The behaviour of a (sub)domain is modeled as follows [69]:Definition 2. The behaviour of a domain D is the triad BD =< SD,ED,LD >, whereSD is a set of possible domain states (lawful states), ED is a set of relevant externalevents (i.e., not all events that might occur are of interest), and LD is a set of lawsdetermining internal domain transformations.In the context of a control system, it is important to clarify that the set of domain19Figure 2.3: Control model as an ontological specialization20Figure 2.4: Enterprise viewstates in the definition above comprises both desired and undesired states, all beinglawful with respect to the laws of nature.It is assumed that any domain that would not undergo changes to its states is notrelevant to this work since without change, control has no purpose. Correspondinglyit is assumed that:Assumption 1. Every domain state changes with respect to time.Additional formalizations and assumptions in this model are detailed in Appendix A.The following section describes the conceptual model of control in the EV. TheEV (illustrated in Figure 2.4) splits the organizational domain into three distinct(sub)domains: (1) a target domain, (2) an implementation component domain, and(3) a control domain.To clearly explain the role of each of the three sub-domains in the EV, we canlook at the simple example of a fire door and a self-closing spring. The purpose ofthe spring is to implement the policy that the door has to be closed when not beingused; this in turn reflects the need to comply with Occupational Safety and Health21Administration (OSHA) regulations2.The target domain is a part of the organization required to comply with certainrules (e.g., policies, regulations, and business rules). The implementation componentdomain is the organizational mechanism containing any combination of people andtechnology put in place to bring about the expected behaviour of the target domain.The control domain is the organizational mechanism that makes sure the behaviourof the implementation component domain is as expected. In our example, thetarget domain is the door, the implementation component domain is the spring,and a corresponding control domain may be an alarm system that is triggeredif the door remains open longer than a certain time. I now elaborate further onthe interplay between the target and the implementation component domains andthen discuss the implied justification for introducing a control domain. All thisanalysis is independent of IS. The model then includes a special case in which theimplementation component is an IS (see the subsection about IS Controls).For each of the three domains I also distinguish between expected behaviour,which indicates how the domain is expected to behave, and the actual behaviour. Inthe current example, the expected behaviour of the target domain is that the doormust remain shut unless forced open. This rule should be enforced by the spring,once the door and the spring are installed and attached properly; this is the expectedbehaviour of the implementation component. The actual behaviour of the doorindicates what really happens to it once the spring is in place. For example, it mightnot be shut completely because the spring is attached poorly or because the dooris jammed. Hence, the alarm (i.e., the control) in this case is installed to ensurethe door is eventually closed (i.e., the control?s expected behaviour) even in caseswhere the spring as the implementation component may fail to do so.The expected behaviour of the target domain is captured by the allowed statesand transformation laws, and reflects both laws of nature and organizational require-ments reflecting regulations, business policies, and norms. Except for the laws ofnature, all other laws cannot be guaranteed to hold in the actual behaviour of thetarget domain. To enforce these laws, additional mechanisms are often used. I termsuch a mechanism an implementation component. In the fire door example, the2http://www.osha.gov/comp-links.html22implementation component is the spring intended to shut the door after it has beenopened to comply with the safety regulation. Thus:Definition 3. An implementation component is defined as an artefact that is in-cluded in the target domain to bring about the desired behaviour of the targetdomain.The implementation component makes up a domain (IC) separate from thetarget domain in the EV model. For example, the fire door is the target domainand the spring is the domain of the implementation component. However, the twodomains must be connected. This means they can interact (i.e., ontologically),and therefore must have some mutual state variables. For example, the spring isattached to the door. In this example, the spring is one possible realization for animplementation component. Other realizations, not necessarily technological, arealso possible. For example, a specific employee can be appointed as responsible forensuring the door is shut and would be considered an implementation component.Being an artefact, the actual behaviour of the implementation component may bedifferent from its expected behaviour for several reasons:? Planning errors: Not all states and events (internal or external) of the targetdomain were considered (i.e., incomplete coverage or incorrect design).? Implementation errors: The actual behaviour of the implementation compo-nent is inconsistent with its expected behaviour as a result of some flaw in itsconstruction.? Operation errors: The use and operation of the new implementation compo-nent may not be as expected (specifically, it is subject to external events notplanned for).Due to such errors, the implementation component might fail to ensurethe target system behaves as expected. The purpose of a control system is toovercome this problem.23Among the various lessons learned in this work (see Chapter 4), it has beenobserved that, occasionally, there may be a tendency to misidentify the implementa-tion component. For example, in several scenarios while producing the data-set forthe empirical study, audit practitioners referred to the implementation componentitself as the ?control?. In the fire door example, the spring is not the control, ratherthe alarm is. Without the presence of an implementation component, there is noneed for control since there is simply no mechanism put in place to be responsiblefor realizing the expected behaviour in the target domain. The implications of anaudit framework that is not equipped to distinguish between an implementationcomponent and control could be detrimental. For example, in my own experience,I stumbled upon real circumstances in which it was assumed by the audit teamthat recruiting practices, which are perceived as a control, are a satisfactory meansto accommodate for the organizational objective to hire only management withleadership qualities. Yet, no actual means were put in place to check whether HRrecruiting practices indeed attained this objective. As a result, the developed modelhas been found to be very useful in assisting with the somewhat obvious, yet crucial,capacity to recognize a lack of control and to identify audit needs.The Control SystemThis section describes the essence of control systems in organizational settingsby building on the concepts presented in the previous section. I adapt the basicdefinition of control in the EV from [70, 74] (i.e., definition 1 on page 18).As concluded in the previous section, the motivation for the control system inorganizational settings is to ensure the correct behaviour of the implementationcomponent domain (e.g., the spring). Within this behaviour, I distinguish between:? Derived behaviour - the implementation component?s behaviour that is di-rected towards bringing about the expected behaviour of the target domain(e.g., the spring pushing the door closed whenever it is open).? Inherent behaviour - the implementation component?s behaviour that is notderived from the expected behaviour of the target domain (e.g., part of theinternal working of the spring).24This separation is useful not only to distinguish between two different controlresponsibilities, it also establishes the basis for a unique case in which the imple-mentation component is an IS. Similar to other components in the organizationalenvironment, the control system resides in its own domain: the control domain.Like all other domains, this domain is also associated with two behaviours: expectedand actual. Corresponding to the two behaviours of the implementation component,the expected behaviour of the control system also has a dual responsibility:? Compliance - ensuring the implementation component domain (i.e., thespring) achieves its expected behaviour, by checking that the actual behaviourof the target domain (i.e., the door) traverses only acceptable states and events.? Substantive - ensuring the inherent operation of the implementation compo-nent domain is as expected (i.e., all aspects not related directly to the targetdomain behaviour). This responsibility is aimed at making sure all implemen-tation components are materially complete, valid, and accurate. An examplewould be an inspection of the internal workings of the spring to verify that itis not ?creaky?.Compliance and Substantive Procedures in AuditingSimilar terminology is used in auditing literature when referring to auditing proce-dures. This mainly includes the following two procedures [24, 74]:? Compliance tests - tests of controls, including inquiries, inspections, observa-tions, and re-performance of control procedures to evaluate whether controlsare operating effectively.? Substantive tests - tests to detect irregularities at the assertion level. Typically,these tests may be focused on either the details of transactions (e.g., recordingof purchases and corresponding disbursements in journal and ledgers) or onthe details of account balances (e.g., comparing income statements againstthe balance sheet).The terminology used in this work is similar to the one used in auditing literature.The differences shown in table 2.1 are rooted in the distinction between the target25Concern My model Auditing literatureCompliance Ensured by controls that account for thedesired behaviour of the target domain.Ensured by tests of controls.Substantive Ensured by controls that account forthe proper internal working of the im-plementation component.Ensured by tests at the assertion level.Table 2.1: Clarification of terminology differences between my model and theauditing literaturedomain and the domain of the implementation component. This distinction betweenthe part of the enterprise expected to comply with certain regulations and the partintended to bring about the expected behaviour in the target domain is non-existentin the auditing literature. This distinction has the following consequences:1. There are apparently two means devoted to compliance: the implementationcomponent and the control. It is essential to emphasize that in this work, theimplementation component is not regarded as a means of compliance. Itsomission would simply entail not having the functionality that is required tobring about the expected behaviour in the target domain.2. Control is modelled as being responsible not only for compliance, but alsofor the adequate operation of the implementation components. In this work,this latter responsibility is termed the ?substantive? responsibility of control,and is directed towards the implementation component.3. A business control may be focused on either the behaviour of the targetdomain or on the behaviour of the implementation component. My modelcould definitely represent the case in which traditional ?substantive tests? inthe auditing literature consider their inspection targets (e.g., the balance sheet)as implementation components. Hence, such tests are regarded as substantivecontrols in my work. Such an interpretation could resolve the discrepancybetween my model and the auditing literature.Compliance is a primary motivator for the insertion of controls in business.Whether substantive aspects may be regarded as a secondary responsibility, and26to what extent they should be conformed to, may be subject to local judgement inorganizations. It is expected that ensuring the ?good health? of implementationcomponents, regardless of their functionality, is considered an integral aspect ofbusiness control. In my empirical evaluation of this model within real-life settings atThe University of British Columbia (UBC) Audit (as reported in Chapter 5), a fifthof the controls (i.e., 5 out of 25) that were arbitrarily identified as the underlyingdataset for the experimental procedure were classified as substantive in the sense ofthis work. The evaluation of the UBC Audit, and their feedback on my model, wasinstrumental in driving me to change the original terminology from ?functional? and?non-functional? to ?compliance? and ?substantive?.The responsibility for compliance can be achieved by monitoring the behaviourof the target domain (e.g., the fire door) and not of the implementation component(e.g., the spring). The behaviour of the implementation component can, in principle,serve as a proxy for that of the target domain (e.g., the position of the spring?s armrepresents whether the door is closed or not). However, its actual behaviour cannotbe guaranteed to be flawless and hence cannot be monitored instead of that of thetarget system. Monitoring only the implementation component may contradict theoriginal motivation for control: identifying errors in the target domain?s opera-tion. On the other hand, monitoring the target domain when the implementationcomponent is in place will also test if the latter behaves correctly. In a generalcontrol system, the focus is on the target domain and not on the implementationcomponent. This assumption can be relaxed only in cases where it is ensured thatthe implementation component is a faithful representation of the target domain orreplaces some of its functions. (See the next sub-section about IS Controls.) Thisgeneral view also reflects the principle of control dependability in safety criticalsystems [65]. Dependability is a property of a system (e.g., a control system) thatjustifies placing one?s reliance on it. When there is uncertainty about the capacity ofthe implementation component to stand as a proxy for the target domain, relyingon the implementation component undermines the dependability of the controlmechanism. An example would be a spring that was poorly attached to the door. Insuch a case, a control mechanism that monitors the behaviour of the spring insteadof the behaviour of the door cannot sense correctly whether the door is closed, andtherefore cannot be relied upon.27In the example above, a sensor that sounds an alarm when the door is open forlonger than a certain amount of time can make a valid compliance control system.Such a sensor is independent of the self-closing spring and operates based on thestate of the door (i.e., the target domain). However, the control model presentedhere does not rule out possible redundancy in either its implementation or controlmechanisms. That is, the same target domain can be associated with multipleimplementation components (e.g., a second spring installed on the other side of thedoor) and with multiple control mechanisms (e.g., an email notification informingoffice residents that the door was left open longer than expected). Such redundancyis typically subject to fault tolerance analysis, which might be determined locallyand derived from safety regulations.A control mechanism itself is a system that resides in its own domain. As withother domains, this domain has expected and actual behaviours. Since the controlsystem is an artefact, it is subject to the same types of errors as the implementationcomponent. This brings about the possibility of inconsistency between the expectedand actual behaviours - of the control. In organizational settings, this is the purposeof an audit compliance test: to determine whether the control mechanism put inplace is satisfactory. Audit compliance is beyond the scope of this work.Based on the original definition of a control system, it is also acknowledged thatcontrols in the EV can be preventive, corrective, or detective.IS Controls as a Variation of the General ConceptualizationIn this section the general notion of control is applied to IS by adopting the deepstructure view of an IS [73]. According to this view, an IS is an artefact intended torepresent some perceived aspects of a represented domain. This representationview entails the state tracking requirement, according to which the states andbehaviour of the IS should faithfully represent the states and behaviour of therepresented domain. Therefore, this view encompasses systems that monitor thepresent state of affairs in the organization (e.g., Transaction Processing IS), systemsthat aggregate information about past states (e.g., Management Reporting Systems),and systems that represent future states (e.g., Decision Support Systems). Therepresented domain can be either a concrete system or a conceived system. The28materialization of the representation is not necessarily attained by computerizedmeans. A representation that is realized by a paper-and-pencil book keeping makesa perfectly legitimate IS according to this view. Similarly, the realization of controlis not necessarily attained by computerized, or, more generally, technological means.In the context of the fire-door example, a person who is assigned the responsibilityto ensure that a fire door is closed makes a valid control mechanism that conformsto the EV model presented in this work.In the context of this work, I consider the IS as the implementation compo-nent. An example would be an organizational payroll system. The payroll systemis an implementation of the organizational activity of paying employees and issubject to rules such as government regulations and employment contracts. A non-computerized, alternative implementation could be the employment of a personwho is responsible for calculating salaries and depositing cash to the accounts ofall employees every month. Based on the earlier conceptualization of controls, thepayroll system is an implementation component intended to guarantee that the targetdomain payroll activities operate as required and that employees are indeed beingpaid according to the rules (i.e., regulations and employment contracts).As an IS, the payroll system should be able to represent, at any given time, dataabout past payments, the payable activities of each employee, salary calculationdetails for each employee, and all other details considered by the organizationto process salary payments. A good payroll system will account for the relevantexpected behaviour of the organization. That is, the system should ensure that allsalaries are paid as required by regulations and contracts. However, as mentionedabove, the payroll system is an artefact. As such, it may be subject to errors relatedto planning, implementation, and operation. Therefore, a control system should beput in place. The responsibility of such a control system will be twofold:? Compliance - verify that payroll operates as required (e.g., salary calculationsare correct and salaries are paid).? Substantive - verify all inherent aspects in the payroll system that are notderived directly from the payroll requirements (e.g., safety and security ofinformation, and correct system usage).29Based on the proposed model, the first responsibility should be enforced bycomparing the actual behaviour (e.g., statements issued by the bank that confirmpayments) and the expected behaviour (e.g., employment contracts). This kind ofcomparison is aimed at checking whether the payroll system (i.e., the implementa-tion component) conforms to its commitments (i.e., expected behaviour). Hence,this type of test is considered a ?compliance control?, which can be implementedfor example in the form of a computerized script that is triggered every month. Incontrast, another script could be initiated periodically to check for the existence ofweak passwords in the payroll system. This latter type of script would be considereda ?substantive control? since despite any revealed password weaknesses, the payrollsystem may still conform to its expected behaviour (i.e., transferring funds accord-ing to contract). Such verification is independent of the implemented payroll system.This requirement for independence exists regardless of whether there is a way toensure that the state of the payroll system (i.e., the implementation component)is consistent with the state of the target domain, which includes the employee?saccount, or not. Since the notion of representation is an inherent characteristic ofthe payroll system as an IS, the adequacy of such representation is expected to beenforced by the control system as part of its substantive responsibility. Therefore,in the general context of an IS as the implementation component, the compli-ance responsibility of the control system can be enforced through control ofthe IS itself, subject to having substantive control applied to the implementa-tion component (i.e., the ?perfect spring? metaphor). In such a case, it may beassumed that the payroll system is a faithful representation being enforced by thesubstantive responsibility of the control system. Consequently, the verification ofpayments can be validated by comparing information about payments in the payrollsystem with employees? contracts.Based on the above discussion, the general concept of control as described earlieris applied to the case of an IS Control System as follows: when the implementationcomponent is an information system, the actual behaviour of the implementationcomponent is expected to be a faithful representation of the actual behaviour of thetarget domain being subject to substantive control. Therefore, compliance controlscan be based on the IS.Correspondingly, the modified responsibilities of an IS Control System are:30? Compliance - ensuring that the IS achieves its expected behaviour in bringingabout the expected behaviour of the target domain, by checking that the actualbehaviour of the IS meets all acceptable states and events in the target domain.? Substantive - ensuring that the inherent operation of the IS is as expected:? Ensuring that the IS acts as a faithful representation of the target domain.Note: While faithful representation is a functional requirement of theIS, its enforcement is considered to be a substantive responsibility ofcontrol.? Checking that the inherent behaviours of the IS meet all of its inher-ent expected behaviours, in addition to being a representation. Thisaspect includes, in particular, all rules that are not part of the trackingrequirement (e.g., security and safety of data).2.2.2 The Process ViewThis section introduces the PV of a control system [39]. As in the case of the EV, thePV further extends the control model developed in this work by focusing on controlsas business activities (i.e., control actions). Therefore, the PV introduces controlactivities in the context of Business Processes (BP) to clarify their essence andsynchronization with business operations. To build on previous work, the PV uses anunderlying formalism of a Generic Process Model (GPM), previously developed bySoffer and Wand [61?63]. The GPM framework defines a process by its objectivesand dynamics without including implementation- and notation-related details (i.e.,notation independent). This is suitable to the development of the PV since it relieson the same ontological foundations (i.e., Bunge?s ontology), and as mentionedabove, has the capacity to model business dynamics. Thus, the PV model developedin this work extends the GPM framework with additional constructs to conceptualize,analyze, and design process structures that need to express control activities andadherence to process enactment constraints.31Extending the GPM with ControlsThe GPM relies on the same ontological foundations as the EV described above.However, since it is aimed at describing business processes, it focuses on theconcepts of ?state? and ?event?. This section explains the basic concepts in the GPMas formalized by the ontological view. The model is then extended (in the nextsection) with control-related concepts.A process, as defined by Soffer and Wand [62], is a sequence of unstable statesleading to a stable state. Based on the ontological definition, an unstable state is astate that must change and a stable state is one that can only change as a result of anexternal trigger. That is, it changes as the result of interaction with things locatedoutside the domain and out of its control enforcement responsibility. Another viewof a process in GPM is as an ordered set of activities [63]. In ontological terms anactivity is an internal event (i.e., a state transition) from an unstable state to a stablestate of a sub-domain, governed by certain transition law(s) (e.g., a lawful activityis governed by nature laws). The outcome stable state of one activity, which isstable within the sub-domain of the activity, may lead to an unstable state within adifferent sub-domain and thus trigger the enactment of a proceeding activity. Fromthe perspective of activities, the definition of a process may be simply rephrasedas ?a sequence of activities?. Notice that according to the definition of a process,the process itself is also an activity starting from an initial unstable state causedby an external trigger, and terminating in a stable state; this stable end-state isusually termed the goal of the process [63]. This relationship exposes the inherentcomposite structure of a process. Figure 2.5 illustrates all process-related conceptsaccording to the GPM. The diagram reflects the composite structure of a process,excluding the theoretical case in which a process as an activity is a member of itself.An activity is a refinement of the ?lawful event? concept; It is associated with anunstable state as its source state, and with a stable state as its target state. Thismodel is used as the basis to extend a process model with controls. The figurehighlights that state and event partitioning between lawful and unlawful is currentlydetermined only with respect to nature laws. Hence, an activity being a lawfulevent might still reflect a transition that fails to meet some other restrictions such asorganizational policies (i.e., the motivation for control).32Figure 2.5: Basic concepts in the GPMAn example of a business process that conforms to the GPM conceptualizationsis illustrated in Figure 2.6. The figure shows a possible configuration for the processof student registration for a course at a university. The hierarchical structure of thedomain is represented by the appropriate sets of state variables, which are associatedwith each process activity. Based on the definition of activity as a state transition(i.e., a lawful event), each activity is illustrated as a (sub)set of the state variablesaffected by the activity?s transformation from a stable state to an unstable state.As can be observed, two sequential activities may either share state variables33(e.g., activity1.1 and activity1.2 sharing s2) or there may be no overlap (e.g., ac-tivity1.2 and activity1.3). Overlap means that the next activity is triggered by itspreceding activity through some interaction between things. Thus, the shared statevariables are also the values of mutual properties of the things that interact. If thereis no overlap, the next activity is enacted as the result of an interaction with externalentities. For example, the ?GeneratingConfirmation? activity is triggered by thestudent who requests a confirmation for being registered in the course. The studentis external to the registration system domain and the student?s behaviour is not apart of the system domain.An important characteristic in the illustrated process is the relationship betweenstate variables of activities at different hierarchical levels. Any activity that is part ofa higher level activity, acts on a sub-set of state variables of the higher level activity.According to the IT Control Objectives for Sarbanes-Oxley [33], applicationcontrols are controls embedded in business process applications, such as large ERPsystems and smaller best-of-breed systems. There are various interpretations as tothe role of such controls in business processes. For example, Soffer and Wand [62]refer to the role of process validation, that is, the accountability for a process to reachall of its interim sub-goals and its final goal(s). Hung and Karlapalem [30] refer tocontrol as the activity of granting access permissions to resources during processenactment. According to the Workflow Management Coalition (WfMC) [76], anorganization that focuses on the advancement of business process managementin industry, control is the underlying engine that orchestrates the enactment of aprocess.The extension described in this section is based on the PV according to the GPMpresented above. Specifically, I also consider the existence of an IS that is intendedto faithfully represent the corresponding domain in which the process is executed;this represents a combination of the ?real? world and the IS. In the PV, the processdomain progresses through a sequence of states and may, at some point, reach astate that is undesired with respect to some policy or traverse through an undesiredtransition. Such violations may either reflect an undesired state or an undesiredtransition that occurs in the ?real? world. For example this might happen with apayment that exceeds the credit limit. Alternatively, the violation may happen withinthe IS as a result of a system error. Since information systems are subject to design,34Figure 2.6: Course registration process. The root process (i.e., activity1)?StudentRegistration? comprises three sequential activities: ?IdentityVali-dation?, ?AssigningToCourse?, and ?GeneratingConfirmation?. Activity1.2, which may also be seen as a process, is further decomposed into?CheckingVacancy? and ?Registration? activities. When the process isenacted, each activity affects its corresponding set of state variables,transforming its sub-domain from an unstable state to a stable state. Thesubset of all state variables (i.e., s1 to s5) that pertain to the enactment ofeach activity is listed on top of each activity box.implementation, and operation faults, flawed design or different implementationerrors may lead to violations of policies and might lead to inconsistency betweenthe IS and its corresponding domain. Similar to the EV, these violations require theinsertion of control mechanisms to either prevent, or at least detect and possiblycorrect, these inconsistencies during process execution.As in the EV, the basic notion of control is taken from Wand and Webber [70](i.e., definition 1 on page 18) and is integrated into the theoretical process model.According to this definition, controls are inserted into the business process to preventan enacted process from encountering any undesired state and any undesired eventonce a process has been initiated. Undesired states are lawful states (i.e., by nature35laws) that are excluded from the application domain according to some state-lawstatements (e.g., policies, business rules). For example, exposing private informationabout employees on a company?s public website would be considered an undesiredstate, regardless of the series of activities that may have led to it. Undesired eventsare lawful events that are excluded from the application domain according to someevent-law statements. For example, packaging products for immediate shipmentafter manufacturing, before conducting quality inspection, would be consideredan undesired event; here, the direct transition between ?post-manufacturing? and?pre-shipping? states is undesired. Therefore, within the business process, a controlshould be exercised whenever there is a risk of transitioning to an undesired stateor traversing through an undesired event. Such risk can be detected before or afteractivity execution. Therefore, the concept of control and the two correspondingspecializations for state control and event control are introduced into the illustratedGPM model as contextual activities. These activities are triggered either beforeor after business-related activities in the process. In the extended model, theinterpretation of the control notion is as follows:Definition 4. Control is a type of activity, triggered by other activities in the process,that is intended to prevent, detect, or correct undesired states or undesired eventsduring process execution in adherence to certain laws (e.g., policies, business rules,regulations).The extended model is illustrated in Figure 2.7. The arrows between controlsand activities (i.e., unidirectional visibility) designate the intention to keep existingprocess activities oblivious to the existence of control activities. Surely knowledgeof control in processes is crucial from a global point of view, for example to theprocess analyst or auditor. However, within the local perspective of each activity,lack of awareness can enable the insertion of control enforcement without havingto modify any of the existing activities; this conforms to the requirements for in-dependent control insertion (i.e., independence) as explained in Subsection 2.2.2.Traditionally, process sequencing may conform to one of two possible executionschemes [15]:orchestration using ?command and control? style, or choreographyusing event-driven style. The former scheme designates a mode in which processsequencing is facilitated by orchestrators, which are pre-specified, typically cen-36Figure 2.7: Process model extended with controltralized, flow controllers. The choreography scheme designates a mode in whichprocess sequencing is fully disseminated across activities, each having local flowcontrol responsibility. The aforementioned independence only applies in the case ofan orchestration scheme.Based on the extended process model, an exhaustive solution would be tointroduce controls whenever there is a state transition on every process enactment.That is, after any process activity, or before the next one, a corresponding controlactivity should be triggered. Specifically, the nature of the control activity is adichotomy that is further classified into two control activities. These activitiesshould take place either before each process activity to prevent it, or after theactivity to detect or correct it; these would represent ?state control? and ?eventcontrol?, respectively. This is to distinguish between control activities that verifythe outcome state of the previous activity, and control activities that verify the entiretransition event made by the previous activity. Considering the two control types asa single control activity, any process that is composed of a sequence of activities37can be uniquely transformed to include a sequence of control enforcements.For example, the process illustrated in Figure 2.6 will entail the followingsequence of control enforcement: < c1.1,c1.2.1,c1.2.2,c1.2,c1.3,c1 > (numbers cor-respond to activity numbers in Figure 2.6). After the execution of any activity inthe process, a corresponding control is triggered. This solution may be inefficientas it attaches a control to every activity, and activates it for every enactment of theactivity. Hence, I propose that controls be further reduced according to the processstructure. This is shown in the next section.Reducing control sequence in process executionThere is no assurance for having any commonality in sub-domains between twoactivities in which one precedes the other in a process. Two such activities that haveno shared properties between them are termed orthogonal activities. Orthogonalityreflects the fact that two activities may act upon different sets of state variables. Insuch cases, the second activity must be triggered by an external event affecting thesub-domain in which the activities occur. For example, activities 1.2 and 1.3 inthe given process example in Figure 2.6 demonstrate two activities in which oneprecedes the other but there is no shared state variables. Clearly, some activitieswithin the same level in the process hierarchical structure can be completely or-thogonal. It is possible to have no overlap between the sub-domains of any twosubsequent activities within the same level. In such cases, each of these activitiesrequires an independent enforcement of control. However, this separation betweenactivities does not exist along the vertical dimension, between any two activitiesthat are linked by a composition relationship in the process structure.For example, both activities 1.2.1 and 1.2.2 represent sub-domains that arecontained within the sub-domains of any of their higher level activities 1.2 and 1.This relationship between sub-domains at different hierarchical levels exposes aunique dynamic correspondence between the last activity in the execution sequenceof any sub-process and its parent activity. Terminating execution of the last activityin any sub-process entails termination of the execution of its parent activity. Thisdynamic correspondence is the result of the composition structure and was capturedby Wand and Weber in the notion of an induced event [70].38Figure 2.8: Registration process enactmentThis phenomenon is illustrated in Figure 2.8, which shows the state of allactivities in the demonstrated process during its execution. Whenever an activityexecution is initiated, the state line changes to an unstable state of the activity?s(sub)domain. Whenever the execution terminates, the state line returns to a stablestate. There are two cases of induced events in the diagram. The first takesplace when activity 1.2.2 terminates. At the same point in the process, the higherlevel activity 1.2 also terminates. Similarly, when activity 1.3 terminates, theentire process of activity 1 terminates. To eliminate redundancy in control, bothcontrols for activities 1.2.2 and 1.3 may be omitted since their sub-domain is alreadymonitored by a higher level of control. The resulting process model with all requiredcontrols is illustrated in Figure 2.9. All associated control mechanisms are denotedby the letter ?C? within a circle, each attached to its contextual activity. The overallsequence of controls required for this process is given at the bottom of the samefigure. This property of the extended process model (i.e., the ability to extract aunique control sequence) is extremely important as it allows separation betweenprocess enactment concerns and control enactment concerns.Controls can be ?upfolded? if the process model has a characteristic that I term39Figure 2.9: Course registration process with controlwell-formedness. Ontologically, well-formedness holds when there is a completesubsumption relationship between each activity and its descendent activities interms of their corresponding state and event spaces. By subsumption I mean thatevery state and event at a given level in the model is fully represented by statesand events at the next level. In addition, it is assumed that the same body oflegislation (e.g., laws, policies) applies at all hierarchical levels. Adhering to thisprinciple, it is implied that any unlawful state or event in a lower-level component isalways manifesting an unlawful state or event in all of its higher-level components.It is acknowledged that in practice, many real-world process designs have beenstructured in a way that is not well formed. Take the case of zero upfolding as themost extreme example, in which each process activity is accompanied by a control.Regardless of the degree to which control presence is reduced, it is still possible toderive a corresponding control sequence separate from all other business relatedactivities.Control Inclusion RequirementsAny solution for including controls should support the need to ensure all aforemen-tioned GRC concerns are adhered to, substantiate compliance, and mitigate risk. Inthe context of business processes in the PV, it would also be beneficial to have a40design that is independent of any concrete process structure. To satisfy these needs,and to make solutions for control inclusion more resilient to changes in the process?sregulative environment, this chapter concludes with a set of high-level requirementsthat can be followed when designing a concrete process architecture that is expectedto manifest compliance. The requirements are stated with respect to the ontologicalterminology constructed in this chapter, and hence are implementation-agnostic.An example for a software architecture using the notion of a third-party controlauthority that conforms to the presented requirements was further elaborated in[41] and is summarized in Appendix C. Different concrete process structures thathave been extended with control enforcement can be evaluated with regard to theserequirements to assess their quality. The requirements and their correspondingjustifications are as follows:1. Safety - to prevent, detect, or correct any execution violation (i.e., transitionto an undesired state or undesired event) at any possible point during processenactment. This requirement accounts for control completeness.2. Traceability - including two aspects: source and a set of regulations. First,controls should be introduced into the process such that if a violation occurs,there will be immediate traceability to the source of violation within theprocess; this is referred to as enactment-time traceability. Second, the enactedcontrol must reflect an identifiable and concrete set of regulations. This isa necessary requirement for assessing the severity of violation to see thedifference between the desired and actual states of affairs, and for finding aresolution to the violation.3. Flexibility - reflects the mere fact that the environment in which processes areexecuted tends to change frequently (e.g., legislation, business goals). Thishappens as the result of different external definitions regarding undesiredstates and events, and the need to adhere to different control and audit reg-ulations. Hence, the insertion of control into the process should not restrictprocess enactments to be compliant with only a single enforcement standardor organizational policy.4. Independence - has two aspects pertaining to design and enactment times.41With respect to design, independence reflects the degree to which new oradditional control actions may be introduced without affecting the existingstructure of the business process. With respect to enactment, independence re-flects the capacity to completely isolate the process enactment (i.e., executionof business related activities) from the enforcement of controls. Since controlenforcement often requires sequencing interventions that repeat, bypass, androll-back some business activities, independence can only be achieved whenflow control is decoupled from the orchestration of core process activities,as opposed to the choreography. When such decoupling exists, control inde-pendence can be beneficial in terms of having a smaller effect on the existingprocess structure, preferably without interfering with the existing processexecution engine. This requirement is not necessary to achieve process com-pliance, but satisfying it may reduce the resources and qualified personnelneeded to re-engineer existing process designs and control executions.42Chapter 3Application of the TheoreticalModelThe conceptualizations of the EV and PV views and their ontological formalismpresented in the previous chapter can help clarify the distinct phenomena of control.This chapter details my research effort to develop two applications that demonstratehow the two views can be used by any organization dealing with control considera-tions. In part, the two applications stand as a demonstration of correctness of thedeveloped control model. This chapter describes both applications in detail. Anevaluation of their usefulness is then described in the chapter that follows.The two applications described in the next sections are:? Process Model Enrichment - an extension to a concrete process modelinggrammar, using BPMN, to demonstrate the benefit of using an analysis modelthat explicitly represents control activities. The enrichment is derived fromthe ontological conceptualizations in the PV (see Section 2.2.2). All threerepresentation styles developed for grammar enrichment conform to the PVmodel part in which the representation of control should match its conceptu-alization as unique contextual activities that are distinguished from all otherbusiness activities. Furthermore, in the experiment that followed to assess thedefectiveness this application, control activities were structured and phrasedto reflect the concepts in the PV. The essence of this application was also43published in [39].? Control Typology - a unified classification scheme that is expected to enablethe identification, classification, and management of control assets in realorganizational settings. The typology was derived from the ontological con-ceptualizations in the EV (see Section 2.2.1). In the buildup of the typology,the terminology of the theory was used to produce the manifestation of levelsfor the different typology dimensions. The essence of this application wasalso published in [40].3.1 Process Model EnrichmentA common way to analyze business operations is the use of business process models,using techniques such as Petri-nets [55], BPMN [77], and EPC [59]. Despite theproliferation of business process modeling techniques, there is, as of yet, no existingmethod capable of explicitly representing control activities in process models.A closely related work was published by Muehlen and Indulska [79] to test thepotential in integrating between modeling grammars for business rules and modelinggrammars for business processes. The work compared the expressiveness of fourrule modeling specifications using Bunge?s ontology as a benchmark. Althoughrelated, this previous work gives even a stronger motivation to the derivation of thedescribed process model enrichment and its empirical evaluation for the followingreasons:? A significant motivator to the developed process enrichment is the fact thatthe key concept of ?control? is still missing in the context of common busi-ness process modeling grammars. The notion of ?control? is not explicatedin [79]. As implied from the conceptual model developed in the previouschapter, control is a key component underlying the desired correspondencebetween business process activities and business rules (i.e., ?laws?). This verybasic correspondence is also inherent in work by Schulz and Xueguang [43],according to whom a rule is theorized to entail a combination of actions andcontrols (i.e., rule? action(s)+ control(s)). As in the control model devel-oped in my work, if an action achieved by the implementation component44is expected to satisfy some rules about a target domain, controls are used toensure that it is so.? The work by Muehlen and Indulska [79] is sequenced in a bottom-up fashion(i.e., technical? conceptual), considering possible integration between ex-isting grammars to increase the overall expressiveness. My work focuses onfirst developing more specific conceptual grounds (i.e., what are the concretecompliance-related phenomena to be represented?) from which a revised con-ceptualization was then derived in a top-down fashion. Further, the conceptualanalysis in [79] relies on the basic application of the Bunge ontology to IS.Although the same ontological foundations are also applied in the essence ofthe framework derived in this work, the ontology is lacking control-specificconcepts such as the ones developed in the previous chapter. Hence, usingit without an extension to assess grammars cannot reveal deficiencies in ex-pressing business controls. An assessment using the control model developedin my work as a reference for grammar evaluation may actually increase thevalidity of this previous work.? The analysis in [79] is missing an empirical evaluation of the effectiveness ofthe proposed grammar integration.In light of the above, I developed a process model enrichment as a concreteapplication to the PV.Business process modeling grammars are used to produce conceptual models(i.e., scripts) of enterprise processes, which are traditionally used for communicationand understanding [49]. The better the quality of the conceptual modeling grammar,the better can may fulfill its role. Such quality, typically referred to as the grammar?sexpressiveness [72], can be determined based on its capacity to completely andaccurately represent all the ontological concepts underlying the correspondingdomain of interest. It is anticipated that existing process modeling grammarsthat suffer from reduced expressiveness may be inferior to grammars that areinformed with explicit control representations. This is due to construct deficit [72]a grammatical deficiency that reflects constructs missing in a grammar; the missingconstructs ultimately prevent the representation of certain ontological concepts such45as control activities. Most likely, when creating scripts to describe processes, such adeficit may result in analysts ignoring control considerations because controls cannotbe represented, or alternatively using the existing activity construct to also expresscontrol actions. According to Definition 4, such an interpretation is not inconsistent.However, compared with a grammar that is extended with the capacity to representcontrols explicitly, the latter solution results in a problem construct overload [72],exposing ambiguity in script interpretation. The following assumption is made withthe intention to enrich process modeling grammars:Assumption 2. Process modeling grammars that lack explicit control constructssuffer from construct overload when used in scripts to capture control-relatedrequirements.In this research work, I used the BPMN grammar to operationalize the suggestedextension. Although there is a proliferation of process modeling grammars, BPMNappears to be the most appealing. BPMN is an industry standard adopted by theObject Management Group1 since 2005, it is supported by many companies, andis employed in several modeling tools2. Furthermore, BPMN supports semanticextensions through annotations, the technique used for grammar extension. Thischoice was also supported by a survey on BPMN usage [57], reporting that a majorityof users (67%) consider annotations useful for complementing the graphical modelswith extra information such as the addition of textual descriptions. In the context ofthis work, it is also important to highlight another outcome of this survey concludingthat:?37% of participants had no need for representing business rules...becauseBusiness Process Diagrams are intended for business people who maynot have the experience to read more complicated diagrams, and thatthe organization wanted to start with simpler diagrams in order tofacilitate process understanding.?This reported experience seems to further promote the question of usefulness inenriched process modeling grammars, as explored in the following chapter.1omg.org2http://www.bpmn.org/BPMN Supporters.htm46Based on the PV model, I considered three competing realizations for integratingcontrols into an existing process modeling grammar: implicit, procedural, anddeclarative. The implicit representation stems from the conceptualization of controlas a refinement of the notion of process activity (i.e., ?control? as a type of ?activity?).This entails an implicit realization representing control activities, using the existing?activity? construct in the grammar. Consequently, it may be difficult to distinguish?regular? process activities from control activities (i.e., construct overload). The twoother representations, procedural and declarative, were designed to be grammaticallyexplicit and do not overlap with existing construct representations. The techniqueused to explicitly extend the grammar and the choice of two explicit representationsis discussed next.There are various ways to explicitly extend a modeling grammar with newrepresentations. For example, it is possible to augment the visual notation of thegrammar by adding new graphical symbols, as theorized by Moody [47]. However,my goal was to design a grammar that is rooted in the extended conceptualizationsdeveloped in the PV to clarify construct semantics, while minimizing its possibleinteraction with the constituents of the visual notation [47]. As opposed to the workby Moody [47], my intention was to focus on content rather than form. Consequently,I chose the technique of annotations as a conventional way for modelers to provideadditional information in models. Annotation is supported by most modelinggrammars and tools, and can be used to adjust the semantic interpretation of existingsymbols in the grammar without adding new ones (i.e., without any modificationsto the visual notation).I envisioned various model enrichment styles to enable concrete control repre-sentations in BPMN. Specifically, the following three dimensions were consideredas overlapping dichotomies for possible representations:? Activity vs. Annotation - represent control activities using the conventionalnotation in BPMN for process activities or using the mechanism of annotationsas the underlying notation machinery. A combination of the two is alsopossible.? Explicit vs. Implicit - making the notation used for the representation ofcontrols visually unique or shared with other notations.47? Procedural vs. Declarative - expressing the functionality of control activitiesusing verbs in either imperative (e.g., ?check X?) or declarative (e.g., ?X ischecked?) forms.A core part in the functional description of control is the ability to expresslawful states and events. Hence, in line with its definition, it may be presumed thata declarative representation is most suitable. Considering the possible combinationsof the above three dimensions, choosing a declarative style in the third possibilityalso implies overruling a representation as an activity (whether explicit or implicit).In both cases the wording of the declarative statement will be inconsistent withthe wording of other activities in a process diagram. Correspondingly, the twocombinations in which a declarative level is mixed with activity notations (i.e.,activity-explicit/implicit-declarative) were eliminated from consideration. Thecombination annotation-explicit-declarative, representing an annotation with adeclarative statement, was selected as the dominant candidate style for modelenrichment. However, representation of control activities as an annotated declarativestatement may also require an extensive level of cognitive effort. Interpreting theannotation as an activity and then the statement in it as the control?s objective,may undermine the anticipated dominance of this representation style. Therefore,a combination of activity-explicit-procedural, representing an annotated ?flagged?activity, was selected as another candidate style for the enrichment. Finally, thecombination activity-implicit-procedural (i.e., a non-marked activity) was selectedto represent the current state-of-affairs in process modeling, one in which thenotation is not enriched with a unique notation to express control activities.In short, two explicit control representation alternatives were devised as partof this work: annotation-explicit-declarative (?declarative?) and activity-explicit-procedural (?procedural?). Both representations were contrasted in the literaturein the fields of knowledge representation [78] in the effort to develop artificiallyintelligent (AI) systems that can capture, store, and apply knowledge in a human-likefashion. Procedural knowledge refers to the know-HOW aspect of knowledge and isconsidered to be tacit [2], whereas declarative knowledge refers to the know-WHATaspect of knowledge and can be easily verbalized as a set of facts. Consideringthese views, Figure 3.1 illustrates the two corresponding templates for explicit48representation of control activities in BPMN process diagrams. Figure 3.2 showscorresponding concrete examples for the three representations, using the case ofpassenger identity verification prior to boarding an aircraft. In a declarative style,the text in the control activity is phrased in a form that states the goal to be achieved(e.g., ?passenger?s ID is not on wanted list?), as implied from the policy. The term?goal? is used here to signify a certain state in the process that must hold at a givenpoint in time before or after activity execution. Its interpretation might be slightlydifferent from the conventional notion of a goal in BPM, typically denoting a stateto be held at process completion (e.g., [61, 63]). In a procedural style, the text inthe control activity describes the action to be taken to attain the goal. In our case,this would be ?check passenger?s ID against wanted list and call security if on list?.Figure 3.1: Declarative / procedural control representationsThe procedural representation uses the annotation mechanism in BPMN tomark activities that should be interpreted as control activities. The associatedannotation block states the corresponding policies being imposed. In the declarativerepresentation, each control activity is detailed within an annotation block, statingits context (before/after the annotated activity), the corresponding policies, and thegoal stated as a declarative statement.Despite the apparent theoretical benefit in using a modeling grammar that canexplicitly represent control activities in a business process, other considerations,such as grammar complexity and visual layout [47], may augment its effectiveness[20]. Specifically, ontological qualities are not necessarily sufficient to ensure thatscripts generated using a business process modeling grammar (e.g., BPMN) with49Figure 3.2: Passenger?s identity verificationexplicit control representation can be better understood than scripts generated usinga business process modeling grammar that is not equipped with explicit controlrepresentations. As explained by Gemino and Wand in [21], the ability of a grammarto convey information should also take into account cognitive considerations [44, 51].50To explain why an informed grammar is expected to be superior, its characteristicsshould be evaluated according to the mental model formed in the mind of itsintended users. This mental model, which internally encodes a script that followsa certain grammar, can only be verified through empirical evaluation. However,understanding this model is essential to establishing a theoretical link between thecharacteristics of the grammar and its performance when used.With respect to the grammatical extension, the semantic network theory [12] isa model that can possibly establish such a link. This theory is used in IS researchto evaluate the necessity of optional properties in modeling [5, 22] and to assessthe application of decomposition principles to UML diagrams [9]. This modelrefers to people?s semantic memory, which is considered the permanent repositoryof information used to comprehend and produce language, to reason, to solveproblems, and to make decisions [2].According to the model of the semantic network theory, concepts in the se-mantic memory are stored as nodes in a network, linked together by pathways thatspecify the relationships between the concepts. The mental activity of accessingand retrieving information from memory is considered a process for spreadingactivation across nodes in the network. The semantic network exists within a se-mantic space that maps between representations of concepts from previous eventsand representations of concepts that are primed by current stimuli. For example,our ability to understand or interpret a specific circle symbol in a BPMN diagramas a ?start event? depends on whether or not we have already been exposed to thisinterpretation in a previous experience. Therefore, in the context of this research,accuracy and efficiency in interpreting a given business process diagram might bethe result of the quality of mappings between its in-memory representation and allpreviously acquired meanings defined in the underlying grammar specification.Figure 3.3 illustrates an example of two simple process diagrams and their cor-responding mental models (i.e., semantic networks). Process A uses the grammar ofBPMN without the explicit extension of controls. Process B uses the same grammarwith the extension of annotated control activities associated with correspondingpolicies. Both process models include the activity ?Control B? as a result of ?PolicyD?. It is apparent that the semantic network of Representation B is more informa-tive than that of Representation A because the former shows more detail about51Figure 3.3: Semantic structures that correspond with process representations?Control B? being a control activity that adheres to ?Policy D?. Even if a reader ofRepresentation A is aware of ?Policy D? indicated in the diagram, inferring thiskind of association between a control activity and a corresponding policy based onthe representation alone, requires the retrieval of knowledge that is not presentedin the diagram and may not be possessed by the reader. A simple question in theform of ?which activities in the process are the result of Policy D?? can be used todemonstrate this difference.The semantic network theory can only provide support to the claim that theunderstanding of scripts that include explicit control representations may be supe-rior to the understanding of scripts that are not explicitly extended with controlrepresentations. However, determining which of the two explicit representations,declarative or procedural, is expected to yield better understanding, requires someadditional considerations. In part, the answer to this question may be guided byontological theory and the aforementioned notion of construct overload [72]. Thisis due to the fact that the proposed procedural representation, as opposed to thedeclarative one, has a significant overlap with the representation of an ordinaryprocess activity. Complementary to this explanation, it was theorized by Winograd[78] that understandability and communicability are two important strengths ofdeclarative representations, as opposed to procedural ones. Understandability isreflected in the relative simplicity of declarative statements, and communicability is52the result of its similarity to natural language communications that are also brokeninto statements. As these two strengths are also important for conceptual models, itis expected that a declarative representation will be better understood than a proce-dural one. To the best of my knowledge, none of the above theories have ever beenput to actual test with regard to the developed grammatical enrichment of processmodels or conceptual models in general. It is possible that despite all theoreticalfoundations being valid, the expected effect may be mitigated by other factors suchas script complexity and visual layout. Hence, an empirical assessment is requiredto determine which representations leads to better understanding in practice.I was restricted by the desire to limit the syntax of the enrichment to use onlythe feature of annotations in BPMN. As a result, the two unique representationsdesigned were partially inspired by the aforementioned work in the knowledgerepresentation [78], and to a certain extent by a creative attempt to solve the problemof explicit control representation. This act conforms to the spirit of design science[29] according to which:?...each new artifact created for that discipline or environment is anexperiment that poses a question to nature (Newell and Simon 1976, p114). Existing knowledge is used where appropriate; however, often therequisite knowledge is nonexistent (Markus et al. 2002). Reliance oncreativity and trial-and-error search are characteristic of such researchefforts. As design-science research results are codified in the knowledgebase, they become best practice. System building is then the routineapplication of the knowledge base to known problems.? [emphasisadded]Having no prior implementation or a solid cognitive theory to build on, it followsthat an evaluation is essential to validate the actual effectiveness of the newly devisedgrammars. As such, the empirical evaluation conducted should scientifically beconsidered part of an exploratory investigation rather than a confirmatory study.Such an evaluation is described in Chapter 4.533.2 Control TypologyThe control typology is suggested in this work as a tool to both analyze control needsand manage existing control assets. A typology is defined as a multidimensional andconceptual classification [3]. Successful classification depends on the identificationof its dimensions. Each type in the typology is designated by a combination ofspecific levels (or values) for each dimension. A typology can be evaluated bypopulating it with empirical cases from a set believed to be exhaustive. Thus,our development approach of the presented typology comprised two phases: first,a top-down generation of conceptual classes (e.g., IT Control types) based onthe conceptual model of the EV; second, validation by a bottom-up matching ofempirical cases from a practical domain (i.e., UBC Audit). The former is detailedhere and the latter is described in the next chapter.The typology developed comprises six dimensions. The dimensions are il-lustrated and summarized in Table 3.2. As illustrated in the EV, each controlmechanism is associated with a target domain - T - that is expected to comply witha certain rule. The mechanism is also associated with an implementation component- IC - that is put in place to bring about the required behaviour of the target domainT . Each of the two resides in its corresponding domain D, having its behaviour BD(as defined in Definition 2). The formal notation that is used in the explanations thatfollow is summarized in Table 3.1.With respect to the EV, the dimensions in the typology and their formal ontolog-ical grounds are as follows:1. Focus - designates what is expected to be monitored by the control mechanism:the target domain T or the implementation component IC. Subject to thecontrol?s responsibility (i.e., see next dimension) it may be determined whichof the two will actually be monitored by the control mechanism. Hence, aspart of its classification, the focus of control may be indicated as either T orIC. As previously mentioned, when the implementation component is an IS,the focus of control can be the implementation component, even when thecontrol?s responsibility is compliance.2. Responsibility - designates the responsibility of the control mechanism astheorized in the EV: compliance or substantive. Compliance is a valid classifi-54Notation DescriptionBT (E) The expected behaviour of the target domain.BT (A) The actual behaviour of the target domain.BIC(E) The expected behaviour of the implementation component.BIC(A) The actual behaviour of the implementation component.BIC(E)/T The expected behaviour of the implementation component that is notdirectly related to bringing about the behaviour of the target domain.BIC(A)/T The actual behaviour of the implementation component that is notdirectly related to bringing about the behaviour of the target domain.S(E) The set of all expected states in the domain monitored by the control.S(A) The set of all actual states in the domain monitored by the control.L(E) The set of all expected events in the domain monitored by the control.L(A) The set of all actual events in the domain monitored by the control.Table 3.1: Notation used to formalize typology dimensionscation for a control mechanism that is responsible for ensuring that the actualbehaviour of the target domain (i.e., BT (A)) matches its expected behaviour(i.e., BT (E)). Substantive is a valid classification for a control mechanismresponsible for ensuring that all aspects in the actual behaviour of the imple-mentation components that are not directly related to the bringing about ofthe expected behaviour of the target domain (i.e., BIC(A)?BIC(A)/T ) matchtheir expectations (i.e., BIC(E)?BIC(E)/T ). Originally, the two levels in thisdimension were termed functional and non-functional, respectively. Thisnaming was changed based on feedback given by the UBC Audit team asreported in next chapter.3. Objective - designates whether the control mechanism is designed to ensureeither desired states or desired transitions (internal/external) into its domainof focus (i.e., dimension 1). A valid classification for ?desired states? wouldbe any control mechanism designed to identify undesired states (i.e., identifys ? S(A)? s /? S(E)). A valid classification for ?desired transitions? would be55any control mechanism designed to identify undesired events. An undesiredevent may be either internal (i.e., identify e ? L(A)? e /? L(E), where e =<s,s? > |s? = L(s)), or external (i.e., identify e ? E(A)? e /? E(E)).4. Goal Type - designates whether the control mechanism is intended to enforcehard goals or soft goals. The two notions of goals were adopted from Sofferand Wand [62], being part of the GPM model. Hard goals reflect objectives thatmust be achieved in the target domain, and is being considered ontologicallyas a subset of the entire set of desired states (i.e., G? S(E)). Soft goals reflectvarious performance measures. A valid classification of hard goals would beany control mechanism that is designed to identify states in the target domainfrom which there is no sequence of transitions to the goal. For example, thismight be a warning notification for missing a contractual payment. A validclassification for the soft goals would be any control mechanism designed toimpose a certain ordering preference over the goal states. For example, thismight be an automatic recommendation between several possible actions tobe taken.5. Risk Functionality - drawn from Risk Management practice [6, 64], thisdimension designates whether the control mechanism is preventive, detective,or corrective. A control mechanism may be classified as preventive if it is in-tended to either reduce vulnerability (i.e., the possibility for an unsatisfactoryoutcome) or to mitigate a hazard (i.e., the potential damage). Ontologically,this means preventing the target domain from reaching an undesired stateor from traversing an undesired transition. A control mechanism may beclassified as detective if it is intended to monitor and identify vulnerabilitiesand hazards. Ontologically, this means detecting when the target domainreaches an undesired state or traverses an undesired transition. A controlmechanism may be classified as corrective if, following detection, all hazardeffects are either being removed or suppressed. Ontologically, this meansaltering the system back into a desired state if an undesired state or transitionis detected.6. Structure - this last dimension was adopted from traditional systems and56control theory [28] imposing an additional classification partitioning to dis-tinguish between open loop and closed loop control structures. The nameused for the two levels was changed to static and dynamic, respectively, givenfeedback from the UBC Audit team as reported in next chapter. A controlmechanism may be classified as static if there is no domain feedback betweenits input (e.g., sensors) and output (e.g., actuators). Ontologically, this meanscontrol detection relies on the state in the domain of its focus only prior toits own action. Pragmatically, any control mechanism with fixed trigger-ing would be considered a static control (e.g., wake-up alarm). A controlmechanism may be classified as dynamic if it has some sensing of its output.Ontologically, this means control detection relies on the state in the domainof its focus immediately after its own action (e.g., rain-sensing wipers).It was conjectured early in this work that the typology developed here can bea useful analysis tool for the classification of existing controls in actual businesssettings. It can also potentially be used to identify coverage, redundancy andsimilarity among different controls. This hypothesis has served as the basis forthe evaluation of the typology reported in the next chapter. However, prior tothe empirical evaluation, I performed a preliminary evaluation for correctness andcompleteness. The initial evaluation that is described here also appears in [40].57Dimension Level DescriptionFocus -?What is monitored by thecontrol mechanism??Target Domain The control monitors the behaviour of a ?target? domain. A tar-get domain is an organizational environment that is expected tocomply with certain rules (e.g., the ?fire door?).ImplementationComponent DomainThe control monitors the behaviour of an ?implementation com-ponent? domain. An implementation component domain is anorganizational environment that is responsible for bringing aboutthe behaviour of a target domain (e.g., the ?spring?).Responsibility Compliance(originally termed?functional?)Ensuring the implementation component achieves its objective(e.g., the ?spring? closes the door when not in use).Substantive(originally termed?non-functional?)Ensuring the inherent operation of the implementation component(e.g., the ?spring? is not squeaky).58Dimension Level DescriptionObjective State Monitored failures are states (i.e., instantaneous, such as identifi-cation of insufficient funds).Event Monitored failures are events (i.e., have duration, a transitionbetween states, such that prevention of wire transfers).Goal Type Hard The control ensures achievement of necessary objectives (e.g.,employment contract).Soft The control ensures improved performance measures (e.g., em-ployment satisfaction).Risk Functionality Preventive Reducing vulnerabilities or mitigating the hazards.Corrective Following detection, removing or suppressing all hazard effects.Detective Monitoring and identifying vulnerabilities and hazards.Structure Static(originally termed?Open loop?)The behaviour of the control is pre-fixed (e.g., a wake-up alarm).Dynamic(originally termed?Closed loop?)The behaviour of the control can change based on feedback fromthe monitored domain (e.g., a thermostat that adjusts itself basedon external temperature).Table 3.2: Typology dimensions59Figure 3.4: IIA control concerns (adapted from IIA - www.theiia.org)The proposed typology was evaluated for correctness and completeness usingan existing IT control framework published by IIA3. This framework, illustrated inFigure 3.4, establishes a hierarchy for different levels of concerns that should beenforced by IT controls. To represent all control concerns, I used the IIA frameworkto populate a concrete set of 16 IT controls in the context of the payroll system ex-ample (Table 3.3 illustrates 5 of these controls). The typology enabled classificationof each of the given IT control types according to all dimensions and was foundto cover the overall set of IT control types. Although the concrete classification ofeach control instance suffers from an experimenter?s bias, the typology was usefulin generating relevant classification questions. For example, it was able to identifywhether the responsibility of a control was compliance or substantive. Furthermore,all levels of all dimensions were instantiated by at least one control type. Therefore,the typology was found to be consistent with the IIA framework.3www.theiia.org60Control Sys-tem (PayrollSystem)IIA Layer Focus: Target-domain(T) /Implementation-Component(IC)Responsibility:Compli-ance(C) /Substan-tive(S)Objective:State(S) /Event(E)Goal-Type:Hard-Goal(HG)/ Soft-Goal(SG)Risk-Functionality:Detect(D) /Correct(C) /Prevent(P)Structure:Static(S) /Dynamic(D)UninterruptiblePower SupplyPhysical andEnvironmentalIC S (required toensure continu-ity not func-tionality)S (systemshould beoperational)HG (systemshould work)D,P: Detectionand preventionof voltagespikes andpower failureD (switchespower offbased on stateof system)A transactionlocking mecha-nismFinancial Con-trolIC C (preservescorrectness offunds transfer)E (preventswithdrawal incertain cases)HG (i.e.,ensures cor-rectness ofdata)P (i.e., preventswrong transac-tions)D (i.e., can rollback)User Authenti-cation and Au-thorizationFinancial Con-trolIC S (not requiredto ensure pay-roll functions)E (preventsunauthorizedchanges)HG (assuressystem onlyoperated asexpected)P (prevents ac-cess)S (validation isindependent ofsystem output)DesignMethodol-ogy IC: ThedevelopmentteamSystem Devel-opmentT (the de-velopmentenvironmentteam, tools, etc.)S (not neces-sary for devel-opment)S (project fail-ure)SG (a goodmethodol-ogy shouldlead to betteroutcome)P (intended toprevent projectfailures)D (contempo-rary methodsuse processbased onfeedback)Data backup ApplicationbasedIC S (improve sys-tem reliability)S (the state ofdata loss)HG (to assuredata are avail-able)C (recover incase of dataloss)S (fixed, basedon predefinedbackup plan)Table 3.3: An example for the classification of payroll system controls (IC is the payroll system unless otherwiseindicated)61After classifying each control by its typological levels, the effectiveness of theoverall set can be analyzed for possible missing controls or for redundant controls.Based only on the example in Table 3.3, it can be inferred that accountability forthe correctness of payments is weak; here, only one control exists to verify it.Moreover, there are no controls to account for efficient operation of the payrollsystem, since there is only one ?soft-goal? control that addresses the developmentprocess (i.e., design methodology). This is the type of analysis that can be doneusing the typology as a tool.As acknowledged, the preliminary evaluation detailed above was purely sub-jective and missing reliability measures. Also, it is based on only one framework(IIA), which is not guaranteed to be comprehensive. Correspondingly, I conducteda more rigorous empirical evaluation following a Delphi exercise [42]. Here theaim was to test the developed typology in realistic business settings and to furtherfine-tune its dimensions based on practitioners? consensus. The Delphi procedure issuitable for such circumstances being an iterative, structured, group communicationprocess aimed at converging towards a solution for a problem that may not be solvedanalytically. The empirical procedure is reported in the next chapter.62Chapter 4Exploring AlternativeRepresentations of ControlThe previous chapter presented two possible applications derived from the concep-tual model of control. One application was derived from the PV and the conceptual-ization of ?control as an activity? intended to ensure desired behaviour. Additionally,the conventional BPMN process modeling grammar was enhanced with controlspecific representations. The second application developed a unified classificationscheme, or typology based on the EV. Chapters 4 and 5 describe the efforts toassess the usefulness of these applications. Chapter 4 focuses on testing the sug-gested process model enrichment, while Chapter 5 focuses on the evaluation of thetypology.In light of the grammar enhancement suggested, this chapter describes theempirical evaluation conducted and its results. The objective of the experiment wasto test the usefulness of an explicit representation of control activities in businessprocess diagrams (i.e., scripts). For the purpose of the empirical study, two specificaspects of ?understanding? were considered: domain understanding and complianceunderstanding. Domain understanding refers to the user?s understanding of the corebusiness operations being illustrated in a process model. Compliance understandingis the capacity of the user to understand whether the business process adheres toa given set of business policies. Specifically, it was intended to examine if theenhancements (i.e., declarative and procedural) would result in better compliance63understanding when compared with the alternative of an implicit representation(i.e., control activities as regular activities). Considering the possible cognitiveadvantages of understandability and communicability associated with declarativerepresentations the experiment was also intended to compare between the twoexplicit representations and their effect on compliance understanding. The followingpropositions were made as the basis for the empirical study:Proposition 1: Scripts generated using a business process modeling grammar (e.g.,BPMN) that uses explicit control representations can facilitate better complianceunderstanding than scripts generated using a business process modeling grammarthat is not equipped with explicit control representations (i.e., traditional BPMN).? Proposition 1.1 (declarative vs. implicit): Process-compliance in scriptsgenerated using a business process modeling grammar (e.g., BPMN) thatuses declarative control representations can be better understood than scriptsgenerated using a business process modeling grammar that is not equippedwith explicit control representations.? Proposition 1.2 (procedural vs. implicit): Process-compliance in scriptsgenerated using a business process modeling grammar (e.g., BPMN) thatuses procedural control representations can be better understood than scriptsgenerated using a business process modeling grammar that is not equippedwith explicit control representations.? Proposition 1.3 (declarative vs. procedural): Process-compliance in scriptsgenerated using a business process modeling grammar (e.g., BPMN) that usesdeclarative control representations can be better understood than scripts gener-ated using a business process modeling grammar that uses procedural controlrepresentations.The selected dependent variable is also coupled with the type of task. Asdiscussed by Gemino and Wand [21], when assessing modifications to modelinggrammars, such as the one proposed in this study, we can assess its effectiveness ina process of script creation (a ?write? task) and in a process of script interpretation64(a ?read? task). Since the main concern in the proposed experiment was modelunderstanding as possibly predicted by the underlying ontological cognitive theories,an interpretation task was suitable to test the extent of effort associated with the gulfof evaluation [50]. This concept reflects the discrepancy between the conception ofthe domain from a model creator?s viewpoint (i.e., mental model) and the modelof the domain [21]. Therefore, using script interpretation as the selected task tomeasure understanding, the typical measures follow Mayer [44] and employ recall,comprehension, and problem-solving questions [e.g., 9, 22, 23, 60].Since all three enrichments developed in this work use the same grammar (i.e.,BPMN), and annotation is the technique used for extending it, I did not expectsignificant differences in the ability of readers to understand the syntax (i.e., recall).Furthermore, as summarized by Gemino and Wand [20], problem-solving is a moresensitive test than comprehension when comparing between grammars to test under-standability. This is perhaps because problem solving includes questions that gobeyond the information provided in the script. Hence, with respect to compliance, itis likely that problem solving would show differences in understanding. Comprehen-sion, which includes questions about the attributes of items and their relationships,seemed to be a good test of the structure of the mental model described in thesemantic network theory (i.e., concepts and relationships).As explained in the previous chapter, this research is exploratory. To test theabove propositions as the basis for the exploration, I rephrased and refined the propo-sitions into concrete hypotheses that include comprehension and problem-solvingquestions as the operationalization of domain understanding.The following hypotheses are the ones tested in the experiment:H1 (declarative vs. implicit): Compliance in scripts generated using DECLARATIVE-BPMN is better understood than in scripts generated using TRADITIONAL-BPMN(i.e., not extended).This includes two sub-hypotheses for the operationalization of compliance under-standing:65? H1.1: COMPLIANCE COMPREHENSION scores will be higher in declarative-BPMN representations than in traditional-BPMN representations.? H1.2: COMPLIANCE PROBLEM-SOLVING scores will be higher in declarative-BPMN representations than in traditional-BPMN representations.H2 (procedural vs. implicit): Compliance in scripts generated using PROCEDURAL-BPMN is better understood than in scripts that are generated using TRADITIONAL-BPMN.This includes two sub-hypotheses for the operationalization of compliance under-standing:? H2.1: COMPLIANCE COMPREHENSION scores will be higher in procedural-BPMN representations than in traditional-BPMN representations.? H2.2: COMPLIANCE PROBLEM-SOLVING scores will be higher in procedural-BPMN representations than in traditional-BPMN representations.H3 (declarative vs. procedural): Compliance in scripts generated using DECLARATIVE-BPMN is better understood than in scripts generated using PROCEDURAL-BPMN.This includes two sub-hypotheses for the operationalization of compliance under-standing:? H3.1: COMPLIANCE COMPREHENSION scores will be higher in declarative-BPMN representations than in procedural-BPMN representations.? H3.2: COMPLIANCE PROBLEM-SOLVING scores will be higher in declarative-BPMN representations than in procedural-BPMN representations.While it was hypothesized that the grammar enrichment will facilitate bettercompliance understanding, it was also important to evaluate whether the underlyingdomain understanding of business operations was impaired as a result of the enrich-ment. Hence, for each of the compliance hypotheses, I phrased a matching domain66understanding hypothesis. Of these, none were expected to be significant since thesame business process was used as the basis for all representation manipulations.Similar to the concrete measurements of compliance, I further split domain under-standing into domain comprehension and domain problem-solving.The following hypotheses were also tested in the experiment:H4 (declarative vs. implicit): Domain understanding in scripts generated us-ing DECLARATIVE-BPMN is better understood than in scripts generated usingTRADITIONAL-BPMN (i.e., not extended).This includes two sub-hypotheses for the operationalization of domain understand-ing:? H4.1: DOMAIN COMPREHENSION scores will be higher in declarative-BPMN representations than in traditional-BPMN representations.? H4.2: DOMAIN PROBLEM-SOLVING scores will be higher in declarative-BPMN representations than in traditional-BPMN representations.H5 (procedural vs. implicit): Domain understanding in scripts generated us-ing PROCEDURAL-BPMN is better understood than in scripts generated usingTRADITIONAL-BPMN.This includes two sub-hypotheses for the operationalization of domain understand-ing:? H5.1: DOMAIN COMPREHENSION scores will be higher in procedural-BPMN representations than in traditional-BPMN representations.? H5.2: DOMAIN PROBLEM-SOLVING scores will be higher in procedural-BPMN representations than in traditional-BPMN representations.H6 (declarative vs. procedural): Domain understanding in scripts generated us-ing DECLARATIVE-BPMN is better understood than in scripts generated using67PROCEDURAL-BPMN.This includes two sub-hypotheses for the operationalization of domain understand-ing:? H6.1: DOMAIN COMPREHENSION scores will be higher in declarative-BPMN representations than in procedural-BPMN representations.? H6.2: DOMAIN PROBLEM-SOLVING scores will be higher in declarative-BPMN representations than in procedural-BPMN representations.Since the application of all three representation styles yielded new forms ofprocess models, I designed the experimental procedure to inspect the usabilityaspect using measurements for ease-of-use adopted from Moore and Benbasat [48].4.1 Experimental TaskA conventional laboratory experiment was employed to check the effects of thevarious representation styles with respect to understanding and ease-of-use. Theexperimental task was designed to compare between three concrete representationsof control activities in business process models that use the notation of BPMN. Thisincludes the following representation styles (see Figure 3.2 on page 50):1. Implicit - Each control activity is denoted using the same notation used inBPMN to designate process activities.2. Explicit procedural - Each control activity is represented as an annotatedactivity. A procedural statement describing the control?s objective is giveninside the activity?s symbol and an annotation associates the activity with thecorresponding policy or policies that were imposed.3. Explicit declarative - Each control activity is represented as an annotationtext block associated with a regular activity in the process (i.e., the context ofthe control activity). The text within the annotation block specifies:? The policy or policies that were imposed.68? The contextual precedence of the control activity (before/after) withrespect to the associated activity.? A declarative description of the control activity indicating the goal(s) tobe achieved.A 2X3 (problem domain, type of control representation) between-subjectsmixed-design was employed as the basis for the experimental procedure to test thehypotheses noted in the previous section. To reduce the sample size and increaseexternal validity, each participant was given two question sets. Each set corre-sponded to one of the following problem domains: student registration - a processdescribing the processing of university applicants? course registration requests bythe faculty office; and mortgage application - a process describing the processingof mortgage requests by a mortgage company. Hence, mixed with the two cases,each participant was asked to respond regarding two different control representationstyles. Considering the intended sample of university students, it was expected thatparticipants would be more familiar with the first case than with the second.I decided not to include the case of no-control in addition to the three represen-tation styles that were considered for two reasons. Theoretically, it was assumedthat the business process described in the experimental task should reflect an orga-nization which already admits to the need to include business controls in order tocomply with some imposed policies. The no-control case is not independent of themanipulation of control representations. There is no meaning to the latter manip-ulation when there are no controls present in the process. Hence, it is impossibleto consider it as a separate factor in the design. Furthermore, it is unclear what wecould have learned from this, as the research question is related to controls, andnot to understandability of process models in general. Pragmatically, extending theexperimental treatment to include another level of (no) treatment in the manipulationwould either require an increase of sample size or a decrease in statistical power.For each case and control representation style, the materials developed for theexperiment included:1. A process model diagram illustrating the case.2. A corresponding textual narrative describing the case.693. A set of policies that should be adhered to, described using text.4. Sets of questions to measure the dependent variables, including: complianceunderstanding, domain understanding, and ease-of-use. Participants werealso asked to indicate their completion time for each question set.In addition to questions about the domain, the questionnaire administeredincluded screening questions about domain- and modelling-knowledge. It alsochecked that all participants had attended the required training. The subjects wererandomly assigned to on of the three treatment groups. All experimental materialsare given in Appendix D.4.2 Pilot ExperimentPrior to the main experimental procedure, a smaller group of students who previouslyparticipated in one of the IS related courses (COMM/BUSI 335 - InformationSystems Technology and Development) were invited by email to take part in apilot study. The goal of the pilot was to provide a preliminary indication for thepossible existence of any of the hypothesized effects, estimate the sample size, andfurther fine-tune the experimental instruments where required. As an incentivefor participation, each participant was offered a guaranteed amount of $30 andadditional $50 was offered to the top 25% of performers.Twenty-one students volunteered to take part in the pilot study. Prior to theexperimental procedure, all participants were given a one-hour training sessionon BPMN modeling and business controls. I served as instructor for the trainingsession, having had experience teaching BPMN modeling and being proficient withthe control model described in previous chapters. The training introduced the threecompeting representation styles for controls, without expressing any preferencetowards a certain representation. The slide-deck used for the training is enclosed inAppendix D.10.My work also included coding the pilot responses. The following is an examplefor a single problem-solving question scoring scheme:70Question: ?Which activities in the registration process reflectapproval and authorization??ScoreAnswer: ?Sign approval and send to student.? 1Answer: ?Sign approval and send to student.? and ?Forwardhandling to another secretary.?0.67Answer: ?Forward handling to another secretary.? 0.5Answer: otherwise 0After inspecting and evaluating the results, I performed a simple Analysisof Variance (ANOVA) to test whether treatment effects were apparent in the pi-lot. This analysis showed that in the student registration group, the treatmentsignificantly affected performance in both compliance comprehension (Mimplicit =6.71,Mprocedural = 8.43,Mdeclarative = 7.29,F = 2.78,p = .04,?2 = .24) and compli-ance problem-solving (Mimplicit = 4.50,Mprocedural = 5.98,Mdeclarative = 1.38,F =8.47,p = .002,?2 = .48), whereas in the mortgage application group, the treatmentsignificantly affected only performance in compliance problem-solving (Mimplicit =5.04,Mprocedural = 4.43,Mdeclarative = 2.24,F = 3.16,p = .03,?2 = .26). It is worthnoting that ?2 ranging between .24 and .48 is considered a large effect [11]. Theseresults provided early confidence for the conservative a-priori presumption of themedium-effect size used to calculate the sample-size. Nevertheless the directionwas not necessarily as expected, as seen in the mortgage application case.Aside from running the ANOVA test, individual question scores were inspected,tracing for outliers. This was aimed at eliminating questions for which the averagescore deviated more than three standard deviations from the accumulated meanscore of the corresponding measure. No such questions were found. Hence, thecomplete question set was preserved.Finally, prior to conducting the pilot, there were some doubts about possiblevariations in the wording for certain process tasks. For example, one deliberationwas ?Log-in to system? versus ?Verify PIN/Password?. As a result, two alternativeswere incorporated in the questionnaires and arbitrarily given to participants in thepilot. Performance scores in these particular questions were used to determine thepreferred wording.714.3 Sample and Main Experimental ProcedureFollowing a similar scheme to the pilot, a group of 60 students was asked totake part in the main experimental procedure. I presented the required trainingsession as an invited talk in COMM/BUSI 335. A significant number of attendeesvolunteered to take part in the experiment, with 54 out of 60 volunteering. Theremaining 6 participants were former students in COMM/BUSI 335, who hadbeen approached through email. A designated two-stage meeting was set witheach of these participants to enable both the required one-hour training and theadministration of the experimental task.As in the pilot, each participant received two question sets, one for the student-registration case and one for the mortgage-application. The mixed design yielded60 responses for each case, prior to the elimination of outliers as reported in thenext section. Descriptive statistics for the complete sample appear in Table 4.1, andtreatment-wise scores for each of the two cases are presented in Tables 4.2 and 4.3.The preliminary results of the mean comparisons are also indicated. P-values reflectone-tailed hypotheses, so the SPSS output for p-values is divided by two.72Variable StudentRegistration(n = 60)MortgageApplication(n = 60)t-testbetweendomains(1-tailed)Scale M SD Scale M SD t(118) Sig.Domain-CMP 0-7+ 4.50 1.54 0-7+ 5.18 1.45 2.51 .01**Compliance-CMP 0-8+ 6.28 1.56 0-7+ 5.01 1.55 4.45 .00**Domain-PS 0-9+ 6.05 1.49 0-10 4.50 1.63 5.45 .00**Compliance-PS 0-10 4.49 2.21 0-10 3.84 2.02 1.71 .05**Ease-of-use 1-7 4.81 .83 1-7 4.19 .66 4.53 .00**CMP time min. 10.34 5.12 min. 9.95 4.21 ?.451 .33PS time min. 18.62 6.45 min. 20.23 6.57 1.36 .09*Table 4.1: Descriptive statistics (prior to outlier omission) - CMP: Compre-hension, PS: Problem-solving, M - Mean, SD - Standard deviation, + -Range reflects maximal possible score after item elimination as a result ofthe reliability tests, ** - significant (p < .05), * - moderately significant(p < .1)Each participant was also asked to indicate their perceived level of knowledgein BPMN modeling and in the two problem domains. The results are shown inTable 4.4. Considering the reported knowledge in BPMN modeling and the overallcomprehension and problem-solving scores in Table 4.1, it was clear that theparticipants were inexperienced in process modeling. Furthermore, as expected,participants reported themselves as being better acquainted with student registrationthan with mortgage application. Consequently, the student registration group is alsoreferred to in this work as the ?high domain knowledge? group and the mortgageapplication group is referred to as the ?low domain knowledge? group. This was alsosupported by a significant difference in the self-reported perception of ease-of-use(t(118) = 4.53, p = .009) between the student registration case (M = 4.81,SD = .83)1SPSS takes into account the arbitrary order in which the two groups are entered in the computationof the t statistics, implying the direction of the effect indicated. Since the data was tested againstthe hypothesis H0: time-in-high-familiarity-case < time-in-low-familiarity-case (1-tailed), the actualresult indicated here reflects: (1) a reversed effect, hence the negative value, and (2) a significancelevel which was divided by half to reflect a 1-tailed effect. However, an effect that is NOT significant.73Variable IMP(n = 20)PROC(n = 20)DEC(n = 20)3-wayMANOVAM SD M SD M SD F(2,57) Sig.Domain-CMP 4.68 1.59 4.65 1.79 4.18 1.21 .66 .26Compliance-CMP 5.73 1.59 6.73 1.12 6.38 1.81 2.19 .06*Domain-PS 6.10 1.32 5.86 1.62 6.19 1.55 .26 .39Compliance-PS 4.19 2.23 4.72 2.56 4.58 1.89 .30 .37Ease-of-use 4.78 .76 5.01 .86 4.63 .84 1.09 .17BPMN MK 2.42 1.21 2.85 1.22 3.00 1.52 1.05 .18DK 6.13 .81 6.30 .75 6.08 1.14 .33 .36CMP time 11.40 6.50 10.58 4.52 9.05 3.90 1.09 .17PS time 19.80 7.68 19.21 6.39 17.20 5.02 .89 .21Table 4.2: Student registration - treatment-wise descriptive statistics (prior tooutlier omission) - IMP: Implicit representation, PROC: Procedural rep-resentation, DEC: Declarative representation, CMP: Comprehension, PS:Problem-solving, MK: Modeling knowledge, DK: Domain knowledgeVariable IMP(n = 20)PROC(n = 20)DEC(n = 20)3-wayMANOVAM SD M SD M SD F(2,57) Sig.Domain-CMP 4.93 1.22 5.28 1.60 5.35 1.53 .48 .31Compliance-CMP 5.05 1.76 4.97 1.24 5.00 1.69 .01 .49Domain-PS 4.37 1.67 4.26 1.92 4.86 1.26 .75 .24Compliance-PS 3.86 1.97 3.36 2.24 4.28 1.81 1.05 .18Ease-of-use 4.39 .77 4.23 .59 3.94 .55 2.51 .05**BPMN MK 2.42 1.21 2.85 1.22 3.00 1.52 1.05 .18DK 2.33 1.48 1.88 1.44 2.60 1.99 .98 .19CMP time 12.15 4.66 8.50 2.57 9.20 4.34 4.78 .01**PS time 21.60 7.37 21.10 6.87 18.00 4.92 1.81 .09*Table 4.3: Mortgage application - treatment-wise descriptive statistics (prior tooutlier omission) - IMP: Implicit representation, PROC: Procedural rep-resentation, DEC: Declarative representation, CMP: Comprehension, PS:Problem-solving, MK: Modeling knowledge, DK: Domain knowledge74BPMN knowledge Mortgage applicationknowledgeStudent registrationknowledgeM 2.76 2.27 6.17SD 1.32 1.66 .91Table 4.4: Sample - background knowledge (1-7 scale)and the mortgage application case (M = 4.19,SD = .66).4.4 Data ReliabilityThe following reliability tests were carried out to refine the internal consistency andthe effectiveness of the developed instruments.Comprehension and problem-solving instruments - Reliability was checked forthe four question sets used to measure comprehension and understanding. Theresults for overall and item-wise reliability scores in each question set are shown inTables 4.5 to 4.12. Some items were eliminated to increase the overall reliability ofeach instrument. Despite the somewhat questionable levels of reliability achieved,all comprehension and problem-solving constructs in this study are formative [19],as opposed to reflective constructs such as ease-of-use. This means that both thecomprehension and problem-solving questions were designed to cover the varioussyntactic and semantic components in the assigned process diagram such that it isthe composition of each question set which actually constitutes the correspondingconstruct2. As such, the items in each question set are not necessarily correlatedand removing items may affect the content validity of each corresponding construct.Therefore, the removal of items in each question set was restricted to a maximum ofthree items.2Due to the exploratory nature of this study, it is worth mentioning that exploratory factor analysiswas attempted, yielding multiple principal components (?3-5) for each construct. Yet, no conceptualgrounds could be attributed to the underlying items, increasing the confidence in the lack of relevanceof this test.75Round Cronbach?salphaCronbach?s alpha depending on items deletedCP1 CP2 CP3 CP4 CP5 CP6 CP7 CP8 CP9 CP101 .14 .36 ?.08 .05 .15 ?.05 .05 .20 .11 .12 .172 .36 n.a. .21 .31 .40 .22 .29 .44 .34 .37 .403 .44 n.a. .34 .40 .43 .30 .35 n.a. .44 .44 .50Corrected Item-Total CorrelationFinal .50 n.a. .36 .31 .22 .43 .21 n.a. .10 .10 n.a.Table 4.5: Domain comprehension (student registration) - instrument reliabil-ity adjustment - Items Removed: CP1,CP7,CP10Round Cronbach?salphaCronbach?s alpha depending on items deletedCP1 CP2 CP3 CP4 CP5 CP6 CP7 CP8 CP9 CP101 .43 .44 .39 .54 .26 .42 .33 .48 .37 .35 .412 .54 .52 .50 n.a. .41 .54 .48 .57 .49 .51 .51Corrected Item-Total CorrelationFinal .57 .20 .27 n.a. .49 .08 .37 n.a. .29 .26 .21Table 4.6: Compliance comprehension (student registration) - instrument reli-ability adjustment - Items Removed: CP3,CP7Round Cronbach?salphaCronbach?s alpha depending on items deletedPS1 PS2 PS3 PS4 PS5 PS6 PS7 PS8 PS9 PS101 .62. .59 .60 .59 .57 .65 .57 .61 .54 .63 .52Corrected Item-Total CorrelationFinal .65 .31 .27 .35 .40 n.a. .34 .25 .44 .19 .49Table 4.7: Domain problem-solving (student registration) - instrument relia-bility adjustment - Items Removed: PS576Round Cronbach?salphaCronbach?s alpha depending on items deletedPS1 PS2 PS3 PS4 PS5 PS6 PS7 PS8 PS9 PS101 n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a.Corrected Item-Total CorrelationFinal .77 .60 .50 .51 .28 .27 .53 .67 .47 .48 .07Table 4.8: Compliance problem-solving (student registration) - instrumentreliability adjustment - Items Removed: noneRound Cronbach?salphaCronbach?s alpha depending on items deletedCP1 CP2 CP3 CP4 CP5 CP6 CP7 CP8 CP9 CP101 .38 .35 .36 .32 .38 .28 .34 .35 .37 .37 .442 .44 .41 .43 .38 .43 .34 .41 .42 .44 .47 n.a.3 .47 .41 .45 .40 .45 .37 .43 .48 .49 n.a. n.a.Corrected Item-Total CorrelationFinal .49 .26 .18 .33 .21 .31 .27 .11 n.a. n.a. n.a.Table 4.9: Domain comprehension (mortgage application) - instrument relia-bility adjustment - Items Removed: CP10,CP9,CP8Round Cronbach?salphaCronbach?s alpha depending on items deletedCP1 CP2 CP3 CP4 CP5 CP6 CP7 CP8 CP9 CP101 .41 .43 .41 .39 .33 .37 .31 .43 .45 .42 .322 .45 .49 .44 .41 .39 .38 .34 .49 n.a. .48 .393 .49 n.a. .44 .45 .47 .41 .37 .55 n.a. .53 .42Corrected Item-Total CorrelationFinal .55 n.a. .31 .32 .14 .39 .50 n.a. n.a. .05 .32Table 4.10: Compliance comprehension (mortgage application) - instrumentreliability adjustment - Items Removed: CP8,CP1,CP777Round Cronbach?salphaCronbach?s alpha depending on items deletedPS1 PS2 PS3 PS4 PS5 PS6 PS7 PS8 PS9 PS101 n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a.Corrected Item-Total CorrelationFinal .56 .05 .22 .41 .16 .23 .34 .12 .53 .13 .34Table 4.11: Domain problem-solving (mortgage application) - instrument reli-ability adjustment - Items Removed: noneRound Cronbach?salphaCronbach?s alpha depending on items deletedPS1 PS2 PS3 PS4 PS5 PS6 PS7 PS8 PS9 PS101 n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a.Corrected Item-Total CorrelationFinal .72 .40 .46 .53 .30 .32 .56 .15 .46 .43 .21Table 4.12: Compliance problem-solving (mortgage application) - instrumentreliability adjustment - Items Removed: noneEase-of-use reliability and validity - The reliability and validity of the instrumentused to measure ease-of-use was assessed. The results are summarized in Table 4.13.The reliability level indicated by Cronbach?s alpha met the suggested toleranceof > 0.7, [52]. The result of confirmatory factor analysis indicated that threeof the items, 4, 5, and 6, loaded weakly on ease-of-use, possibly designating alatent construct. This is consistent with the wording in these items, which wasphrased in positive style, as opposed to the negative style used in the first threeitems. Considering this explanation together with the acceptable level of internalconsistency, no further adjustment was made.Variable Cronbach?s alpha Factor loadingsItem1 Item2 Item3 Item4 Item5 Item6Ease of use .76 .74 .90 .85 .30 .26 .13Table 4.13: Ease of use - reliability and validity78Case DomaincomprehensionCompliancecomprehen-sionDomainproblem-solvingComplianceproblem-solvingStudent-registration.99 .99 .89 .95Mortgage-application.99 .99 .93 .93Table 4.14: Inter-rater reliability - cronbach?s alphaInter-rater agreement - Rating of answers was done by two MIS PhD students.Each rater was also provided with an answer sheet, including recommended answersfor both comprehension and problem-solving questions. Both raters coded thecomplete set of responses. Inter-rater reliability was computed for each of the fourdependent variables. The reliability indicators are presented in Table 4.14. Overall,inter-rater reliability was high.Elimination of responses - Data exploration using boxplot analysis was conductedto determine outliers. The analysis concluded that three participants in the mortgageapplication group deviated in their domain problem-solving responses beyond 1.5times the inter-quartile range (?99.3% interval of a normal distribution). This isillustrated in Figure 4.1. These deviant responses were removed in the analysis. Nofurther outliers were observed in the data. Correspondingly, the revised descriptivestatistics and treatment-wise scores are presented in Tables 4.15 to 4.17.The removal of outliers yielded additional significant mean differences in themortgage application case. The results in the student registration case remained thesame. However, post-hoc tests showed that in the mortgage application case therewere no significant differences between any of the two explicit control represen-tations and the implicit one. (See details in Section 4.5.) Background knowledgein BPMN modeling was accounted for statistically in the analysis as a covariate(MANCOVA). Hence, all further analysis was conducted using the data that omitsthe identified outliers.79Figure 4.1: Data exploration - box-plot for outlier removal: box length equals50% of sample (i.e., inter-quartile range IQR=Q3-Q1), line within boxis sample median (i.e., Q2), whisker ends: top = Q3+1.5IQR, bottom =Q1-1.5IQRAwareness checks - To test whether the treatment was indeed perceived by theparticipants in the study, three post-test questions were employed. Post-test ques-tions 1,2, and 3 were designed as follows: one confirmatory Yes/No question thatcorresponds to each of the two concrete representations (i.e., procedural and declar-ative), and one more to confirm participants? awareness of the presence of controlrepresentation in general (i.e., explicit vs. implicit). Table 4.18 shows the resultsfor all three post-test questions. Overall, it may be concluded that participantswere not consciously aware of the given treatment. This is apparent because therewas no significant difference between those who responded positively and those80Variable StudentRegistration(n = 60)MortgageApplication(n = 57)t-testbetweendomains(1-tailed)Scale M SD Scale M SD t(115) Sig.Domain-CMP 0-7+ 4.50 1.54 0-7+ 5.11 1.44 ?2.20 .02**Compliance-CMP 0-8+ 6.28 1.56 0-7+ 4.94 1.56 4.63 .00**Domain-PS 0-9+ 6.05 1.49 0-10 4.29 1.38 6.64 .00**Compliance-PS 0-10 4.49 2.21 0-10 3.70 1.96 2.06 .02**Ease-of-use 1-7 4.81 .83 1-7 4.20 .67 4.36 .00**CMP time min. 10.34 5.12 min. 9.89 4.13 .51 .30PS time min. 18.62 6.45 min. 19.44 5.67 ?.73 .23Table 4.15: Descriptive statistics - (outliers omitted) CMP: Comprehension,PS: Problem-solving, + - Range reflects maximal possible score afteritem elimination, ** - significant (p < .05), * - moderately significant(p < .1)Variable IMP(n = 20)PROC(n = 20)DEC(n = 20)3-wayMANOVAM SD M SD M SD F(2,57) Sig.Domain-CMP 4.68 1.59 4.65 1.79 4.18 1.21 .66 .26Compliance-CMP 5.73 1.59 6.73 1.12 6.38 1.81 2.19 .06*Domain-PS 6.10 1.32 5.86 1.62 6.19 1.55 .26 .39Compliance-PS 4.19 2.23 4.72 2.56 4.58 1.89 .30 .37Ease-of-use 4.78 .76 5.01 .86 4.63 .84 1.09 .17BPMN MK 2.42 1.21 2.85 1.22 3.00 1.52 1.05 .18DK 6.13 .81 6.30 .75 6.08 1.14 .33 .36CMP time 11.40 6.50 10.58 4.52 9.05 3.90 1.09 .17PS time 19.80 7.68 19.21 6.39 17.20 5.02 .89 .21Table 4.16: Student registration - treatment-wise descriptive statistics (outliersomitted) - IMP: Implicit representation, PROC: Procedural represen-tation, DEC: Declarative representation, CMP: Comprehension, PS:Problem-solving, MK: Modeling knowledge, DK: Domain knowledge81Variable IMP(n = 19)PROC(n = 18)DEC(n = 20)3-wayMANOVAM SD M SD M SD F(2,54) Sig.Domain-CMP 4.87 1.22 5.08 1.57 5.35 1.53 .54 .29Compliance-CMP 4.95 1.75 4.86 1.26 5.00 1.69 .04 .48Domain-PS 4.15 1.37 3.80 1.37 4.86 1.26 3.15 .03**Compliance-PS 3.81 2.01 2.93 1.91 4.28 1.81 2.41 .05**Ease-of-use 4.41 .79 4.25 .60 3.94 .55 2.62 .04**BPMN MK 2.23 .89 2.94 1.25 3.00 1.52 2.26 .06*DK 2.39 1.49 1.83 1.51 2.60 1.99 1.03 .18CMP time 11.84 4.57 8.61 2.55 9.20 4.34 3.56 .02**PS time 20.68 6.30 19.72 5.70 18.00 4.92 1.13 .17Table 4.17: Mortgage application - treatment-wise descriptive statistics (out-liers omitted) - IMP: Implicit representation, PROC: Procedural repre-sentation, DEC: Declarative representation, CMP: Comprehension, PS:Problem-solving, MK: Modeling knowledge, DK: Domain knowledgewho responded negatively. Furthermore, most of the answers about the declarativerepresentation were interpreted as if the treatment was not given. This fact indirectlyaffected the overall perception of treatment as being non-existent, with explicitbeing the combination of procedural and declarative. Hence, the results in this studyshould be interpreted as though the participants were oblivious to the treatment.Most likely, this was not due to lack of attention by the participants, but rather lackof experience using BPMN, as evidenced in Table 4.4. It is very likely that anysignificant effect observed in the current results would become even more apparentwith users who are more experienced in BPMN. Clearly, users who are more skilledin recognizing the controls in the process model will be even more proficient indetermining process compliance.82ActualrepresentationPost-test question answersYes No t-test (2-tailed)M SD n M SD n t Sig.Declarative .48 .51 40 .53 .50 77 .59 .56Procedural .63 .49 38 .56 .50 79 -.76 .45Explicit .67 .47 78 .72 .46 39 .56 .58Table 4.18: Manipulation-checks - actual representation vs. post-test answers.See post-test questions in appendix D.9 on page 162 (page number 6 inenclosed questionnaire).4.5 Data AnalysisThe data analysis was conducted in a progressive manner, starting with a high-level Multivariate Analysis of Variance (MANOVA), combining all four dependentvariables and the perception of ease-of-use in a single run. This method controlsthe inflation of a type I error having multiple DVs jointly analyzed. As a fur-ther refinement, a second analysis adjusted for prior BPMN knowledge and priorknowledge in the corresponding case?s domain (i.e., Multivariate Analysis of Co-variance (MANCOVA)). The results are reported in Section 4.5.1. In line with theexploratory nature of this study and lack of prior experience in literature in thedomain of business control modeling, I considered both a conventional level of? = .05 as a significant effect (marked with ?**?), and a level of ? = .1 as a mod-erately significant effect (marked with ?*?). This allowed me to conclude that thetreatments may have still served to alter performance in less extreme circumstances.Section 4.5.2 reports the individual effect of each treatment level in caseswhere the treatment was found effective post-hoc. Appendix B.4 also includesa complementary section that reports the checking of all analysis assumptions,including normal distribution, homogeneity of variances, and covariate interactions.Section 4.5.3 details additional comparisons that were conducted to explorewhether, in general, there is a significant difference between implicit and explicitcontrol representation, combining the procedural and declarative variations into asingle group.834.5.1 Multivariate Analysis of CovarianceTables 4.16 and 4.17 summarize the results of MANOVA multivariate analysis to testthe effect of control representation on the four dependent variables and ease-of-use.A more detailed reporting of these results is included in Appendix B.1. MANOVAresults do not adjust for the possible interaction that the given treatment may havewith the effects of background modeling and domain knowledge. Hence, an adjustedMANCOVA analysis was used to test the effect of control representation while alsoaccounting for the possible effect of the aforementioned background factors. Theresults, including adjusted means, are presented in Tables 4.19 and 4.20. A moredetailed report of these results is included in Appendix B.2.Variable IMP(n = 20)PROC(n = 20)DEC(n = 20)3-wayMANCOVAM SD M SD M SD F(2,55) Sig. ?2pDomain-CMP 4.74 .35 4.64 .35 4.11 .35 .93 .20 .03Compliance-CMP 5.71 .35 6.76 .35 6.36 .35 2.32 .054* .08Domain-PS 6.11 .35 5.85 .34 6.20 .35 .28 .38 .01Compliance-PS 4.21 .51 4.76 .51 4.52 .51 .29 .37 .01Ease-of-use 4.79 .19 5.01 .19 4.62 .19 1.10 .17 .04Table 4.19: Testing treatment effect - student registration - adjusted-meancomparisons (Covariates evaluated at: Modeling Knowledge=2.76 andDomain Knowledge=6.17) - IMP: Implicit representation, PROC: Pro-cedural representation, DEC: Declarative representation, CMP: Com-prehension, PS: Problem solving84Variable IMP(n = 19)PROC(n = 18)DEC(n = 20)3-wayMANCOVAM SD M SD M SD F(2,52) Sig. ?2pDomain-CMP 5.00 .33 4.92 .34 5.37 .32 .56 .29 .02Compliance-CMP 4.96 .38 4.87 .39 4.98 .37 .02 .49 .00Domain-PS 4.24 .32 3.73 .32 4.83 .30 3.10 .03** .11Compliance-PS 3.87 .45 2.81 .46 4.34 .43 3.05 .03** .11Ease-of-use 4.45 .16 4.23 .16 3.93 .15 2.88 .03** .10Table 4.20: Testing treatment effect - mortgage application - adjusted-meancomparisons (Covariates evaluated at: Modeling Knowledge=2.73 andDomain Knowledge=2.29) - IMP: Implicit representation, PROC: Pro-cedural representation, DEC: Declarative representation, CMP: Com-prehension, PS: Problem solving4.5.2 Post-hoc AnalysisThis section reports the individual effect of treatment levels when, overall, it wasfound to have a significant effect, as indicated in Tables 4.19 and 4.20.Case I: Student Registration - A summary of all significant Sidak-corrected pair-wise comparisons for the case of student registration is reported in Table 4.21.Correspondingly, a plot for compliance-comprehension is illustrated in Figure 4.2.Although significance should be considered here with caution, the exploratorynature of this study implied that an ? level of .1 yielding a significant p-value is asound indicator for the observation of a true effect. There were no further significantpair-wise differences evident in the results for the student registration case.85Variable IMP PROC DEC (1-tailed)M SD M SD M SD pCompliance-CMP 5.71 .35 6.76 .35 .02 **5.71 .35 6.36 .35 .097 *Table 4.21: Summary of all significant post-hoc pair-wise comparisons - stu-dent registration86Implicit Explicit-procedural Explicit-declarativeM 5.71 6.76 6.36SD .35 .35 .35Figure 4.2: Compliance comprehension (student registration) - pair-wise com-parisons: significant between procedural and implicit, moderately signif-icant between declarative and implicit.Case II: Mortgage Application - A summary of all significant Sidak-correctedpair-wise comparisons for the case of mortgage application is reported in Table 4.22.Plots for the domain problem-solving, compliance problem-solving, and ease-of-useare illustrated in Figures 4.3 to 4.5, respectively. There were no further significant87pair-wise differences evident in the results for the mortgage application case.Variable IMP PROC DEC (1-tailed)M SD M SD M SD pDomain-PS 4.24 .32 4.83 .30 .09 *3.73 .32 4.83 .30 .01 **Compliance-PS 3.87 .45 2.81 .46 .06 *2.81 .46 4.34 .43 .01 **Ease-of-use 4.45 .16 3.93 .15 .01 **4.23 .16 3.93 .15 .08 *Table 4.22: Summary of all significant post-hoc pair-wise comparisons - mort-gage application88Implicit Explicit-procedural Explicit-declarativeM 4.24 3.73 4.83SD .32 .32 .30Figure 4.3: Domain problem-solving (mortgage application) - pair-wise com-parisons: significant between procedural and declarative, moderatelysignificant between declarative and implicit.89Implicit Explicit-procedural Explicit-declarativeM 3.87 2.81 4.34SD .45 .46 .43Figure 4.4: Compliance problem-solving (mortgage application) - pair-wisecomparisons: significant between procedural and declarative, moderatelysignificant between procedural and implicit.90Implicit Explicit-procedural Explicit-declarativeM 4.45 4.23 3.93SD .16 .16 .15Figure 4.5: Ease of use (mortgage application) - pair-wise comparisons: sig-nificant between declarative and implicit, moderately significant betweenprocedural and declarative.4.5.3 Implicit versus Explicit ComparisonsConsidering the scarcity of theory in prior literature about any concrete realiza-tions to represent controls in business processes, I conducted a simple comparisonbetween implicit and explicit representations. This also served to address the fun-91damental question about the potential benefit of having a concrete representation,regardless of whether the representation method is procedural or declarative. Forexplicit representations, I combined the groups of procedural and declarative rep-resentations. Tables 4.23 and 4.24 present the case-wise results of all the adjustedmean differences using MANCOVA to account for background domain knowledgeand BPMN modeling knowledge.Similarly, performance times for comprehension and problem-solving werecompared between the two groups (i.e., implicit vs. explicit). The results areindicated in Tables 4.25 and 4.26.Variable IMP(n = 20)EXP(n = 40)MANCOVA(1-tailed)M SD M SD F(1,56) Sig.Domain-CMP 4.74 .35 4.38 .25 .70 .20Compliance-CMP 5.70 .35 6.56 .24 4.00 .03**Domain-PS 6.11 .34 6.02 .24 .04 .42Compliance-PS 4.21 .51 4.64 .36 .48 .25Ease-of-use 4.79 .19 4.81 .14 .01 .46Table 4.23: Student registration - adjusted-mean comparisons (Covariates eval-uated at: Modeling Knowledge=2.76 and Domain Knowledge=6.17) -IMP: Implicit representation, EXP: Explicit representation, CMP: Com-prehension, PS: Problem solving92Variable IMP(n = 19)EXP(n = 38)MANCOVA(1-tailed)M SD M SD F(1,53) Sig.Domain-CMP 5.00 .33 5.16 .23 .16 .35Compliance-CMP 4.96 .38 4.93 .26 .003 .48Domain-PS 4.23 .33 4.32 .23 .04 .42Compliance-PS 3.85 .47 3.62 .33 .16 .32Ease-of-use 4.45 .16 4.07 .11 3.72 .03**Table 4.24: Mortgage application - adjusted-mean comparisons (Covariatesevaluated at: Modeling Knowledge=2.73 and Domain Knowledge=2.29)- IMP: Implicit representation, EXP: Explicit representation, CMP:Comprehension, PS: Problem solvingVariable IMP(n = 20)EXP(n = 40)MANCOVA(1-tailed)M SD M SD F(1,58) Sig.CMP time 11.40 6.50 9.79 4.23 1.31 .13PS time 19.80 7.68 18.18 5.74 .83 .18Table 4.25: Student registration - time comparisons - IMP: Implicit representa-tion, EXP: Explicit representation, CMP: Comprehension, PS: Problemsolving93Variable IMP(n = 19)EXP(n = 38)MANCOVA(1-tailed)M SD M SD F(1,55) Sig.CMP time 11.84 4.57 8.92 3.57 7.02 .01**PS time 20.68 6.30 18.82 5.30 1.39 .12Table 4.26: Mortgage application - time comparisons - IMP: Implicit rep-resentation, EXP: Explicit representation, CMP: Comprehension, PS:Problem solving4.6 Conclusions of Empirical ResultsConsidering the level of domain knowledge as a secondary treatment, the resultsof the experiment indicate a clear interaction between domain knowledge and typeof representation. These results also validate the work by Khatri et al. [34], whichconcluded that application domain knowledge has a significant impact on schema-based problem-solving tasks. This is visually demonstrated in Figures 4.6 to 4.9.Consistent with this interaction, the effect of control representation was different forthe two groups. Table 4.27 summarizes the results in the context of the hypothesestested.The significant findings indicated by the results are as follows:1. In the high domain knowledge group for the student registration case, bothtreatment styles for control representation effectively improve compliancecomprehension. The effect of procedural representation was stronger thanthe one of declarative representation. It is possible that when the domainis more familiar, the reader wants to know more regarding HOW controlsare implemented, an aspect which is better articulated by the proceduralrepresentation style. However, there was no statistically significant differencebetween the two explicit representation styles. This result was also consistentwith the overall effect of explicit control representation tested for in Section4.5.3. The results were consistent with hypotheses H1.1 and H2.1. Allremaining hypotheses were not corroborated. Most importantly, it can be94Variable Student Registration Mortgage ApplicationDEC>IMP PRO>IMP DEC>PRO DEC>IMP PRO>IMP DEC>PROCompliance-CMPWSD(+H1.1)SD(+H2.1)ND(H3.1)ND(H1.1)ND(H2.1)ND(H3.1)Compliance-PSND(H1.2)ND(H2.2)ND(H3.2)ND(H1.2)WSD(-H2.2)SD(+H3.2)Domain-CMPND(H4.1)ND(H5.1)ND(H6.1)ND(H4.1)ND(H5.1)ND(H6.1)Domain-PSND(H4.2)ND(H5.2)ND(H6.2)WSD(+H4.2)ND(H5.2)SD(+H6.2)Ease-of-useND ND ND SD(IMP>DEC)ND WSD(PRO>DEC)Table 4.27: Summary of results - ND: No difference, WSD: statistically sig-nificant difference when ? < .1, SD: statistically significant differencewhen ? < .05, +: corroborating the hypothesis, -: corroborating anhypothesis in opposite direction, CMP: Comprehension, PS: Problemsolving, IMP: Implicit representation, DEC: Declarative representation,PRO: Procedural representationconcluded that in the high domain knowledge group, control representationdoes not significantly affect performance in compliance problem-solving (i.e.,H1.2 and H2.2).2. In the low domain knowledge group for the mortgage application case, declar-ative control representation was found to yield significantly improved compli-ance problem-solving scores with respect to the procedural representation,supporting H3.2. The declarative representation also yielded better scoreswith respect to the implicit representation. However, this difference wasnot statistically significant (i.e., H1.2). Somewhat surprising with respectto H2.2, the procedural representation significantly impaired complianceproblem-solving performance. In fact, the same effect was consistent, al-though not always statistically significant, across all measurements. Thisindicated a potentially harmful impact of the procedural representation stylein low domain knowledge circumstances. This effect most likely obscuredthe overall effect of explicit control representation being tested for in Section4.5.3. Based on the results, it is possible that a declarative representation ofcontrol activities may be more suitable when there is low domain familiarity.95Since a declarative representation is in greater contrast to the representationof all other business related activities, it may make the business process itselfstand out. For users with less familiarity, it might be more important to simplydistinguish between core business activities and all other activities not directlyrelated to the attainment of the process?s operational goals (e.g., compliance).3. The results also indicate a significant improvement in domain problem-solvingfor the declarative representation (H4.1 and H6.2). This suggests that thedeclarative representation may actually facilitate better domain problem-solving performance. Moreover, it was apparent, although not always sta-tistically significant, that the declarative representation facilitates higherperformance scores across all measurements. One explanation may be that forusers with low domain familiarity, a declarative representation helps differen-tiate between control activities and other business activities. In the case ofproblem-solving, this would help the person focus on the business activities.4. Perception of ease-of-use was not significantly different between the treat-ments in the high domain knowledge group. However, in the low domainknowledge group, its perception was significantly different between the levelsof treatment such that the most effective treatment (i.e., declarative) got theworst ease-of-use score. Interestingly, although participants were not awareof the given treatment, it affected their ease-of-use perception.5. In most cases, no significant time differences were recorded. Regardlessof the statistical significance, performance times were mostly shorter in thedeclarative group. The exception was for compliance comprehension timein the low domain knowledge group, in which the procedural representationyielded the shortest time. This result also corresponds to the lowest score incompliance comprehension.In light of the above, it can be inferred as a general rule that a declarativerepresentation is the most effective choice when the task at hand requires the inter-pretation of process compliance. Although a procedural representation facilitatesbetter compliance comprehension when there is high domain familiarity, its possible96negative effect when there is no such knowledge disqualifies it as an effective repre-sentation means. Hence, it may be concluded that for readers with high domainfamiliarity, control assurance activities should be prescribed in a proceduralform; for readers with low domain familiarity, control activities should be pre-scribed in a declarative form. If the level of domain familiarity is not known,the representation of control activities is generally better comprehended whensuch activities are prescribed in a declarative form. Moreover, such activitiesneed to be made explicitly apparent and clearly differentiated from other operationalconcerns. This approach is expected to bring about a better understanding of processcompliance and a better understanding of the business operations themselves.It is also suggested that for low domain familiarity, some training could be givento possibly improve the perception of usability and the ease-of-use associated withthe declarative representation.97Figure 4.6: Domain comprehension98Figure 4.7: Compliance comprehension99Figure 4.8: Domain problem-solving100Figure 4.9: Compliance problem-solving101Figure 4.10: Ease-of-use102Chapter 5Assessing the usefulness of thetypologyThis chapter describes the research experiment conducted using a full-scaleDelphi procedure to fine-tune the dimensions of the typology and to further testits validity in real business settings. This was done bay using the control typologyapplication described in Chapter 3 as a classification tool for controls in the businessdomain.The experiment involved an engagement with the Internal Audit departmentat the University of British Columbia (UBC). Overall, this engagement spanned atime period of eight and a half months between November 24, 2009 and August 8,2010. The engagement comprised a series of four introductory and data preparationmeetings with the director of the department. This was followed by a four-roundDelphi procedure, and close collaboration with the director and two CertifiedAccountants who were also experienced senior audit staff. All of us served asmembers of the experimental ?advisory panel?.The overall timeline for all experimental activities is detailed in Table 5.1.The task, experimental instruments, and corresponding results for each of theexperimental rounds are reported in the following subsections. Examples for allexperimental materials are given in Appendix E.3.103Dates Activity Participants Deliverable24 Nov.2009Introductory meeting Department director,principal investigator12 Jan.2010Dataset compilation Department director,principal investigator,research adviserBusiness Controls- model overviewand specificationdocument26 Jan.2010Dataset compilation -cont.Department director,principal investigator1 Feb.2010Dataset compilation -finalizeDepartment director,principal investigatorControl dataset24 Feb. -10 Mar.2010Delphi Round 1 -meeting with advi-sory panel, consentsigning, controlmodel introduction,and dissemina-tion of 1st roundquestionnaireAdvisory panel, prin-cipal investigatorRound 1 forms4 Apr.- 7 Jun.2010Delphi Round 2 -meeting with advi-sory panel and dis-semination of 2ndround questionnaireAdvisory panel, prin-cipal investigatorRound 2 forms30 Jun.- 22 Jul.2010Delphi Round 3 -dissemination of 3rdround questionnaireAdvisory panel, prin-cipal investigatorRound 3 forms (fullagreement)24 Jul. -8 Aug.2010Delphi Round 4 - ty-pology verificationAdvisory panel, prin-cipal investigatorRound 4 formsTable 5.1: Delphi experiment timeline1045.1 Dataset PreparationBefore beginning the main experimental procedure, the advisory panel held a seriesof meetings devoted to identifying realistic business controls that are employedby the internal audit department at the University. These controls were part ofits responsibility to monitor policy compliance, effective risk management, andgood governance. This method for control discovery was attained in a series offour meetings with the director of the Internal Audit department. It was similarto the control self-assessment (CSA) technique [24], which is designed to gatherinformation about an organization by approaching those with the best workingknowledge of an area. In such settings, questionnaires and facilitated workshopsare used as a means for collecting information. This method was determined mostpractical because UBC is a centralized organization, with its offices located oncampus and a relatively small audit team.The first two meetings introduced the basic model of controls and the corre-sponding typology developed. Open discussions were used to determine whetherpreliminary adjustments were needed to make the model conceptualizations fitthe local institutional terminology and philosophy about the essence of businesscontrols. It was agreed that the set of specification attributes listed in Table 5.7 beinstantiated when specifying each individual business control identified. I produceda two-page brochure (see Appendix E.1) summarizing the key definitions and theseattributes, alongside some concrete examples to guide the specification of controlsand to help the panel in the remaining experimental procedure. I conducted twoadditional meetings with the department?s director to fully identify a set of 25business controls, each specified as an instance of the aforementioned attributes.The set of controls identified is detailed in Appendix E.2.105Attribute DefinitionName ofcontrolA brief general description of the control as viewed by stake-holders.Target The part(s) of a domain (e.g., an organization) or set of activitieswithin the domain whose behaviour should comply with therule.Rule A rule formalizing the required behaviour of the target.Goal Goal or objective the rule is intended to meet.Implementation The mechanism put in place to bring about the required be-haviour.Control The actual mechanism put in place to make sure the behaviourof the implementation conforms to the rule.Table 5.2: Control specification attributes1065.2 Experimental TaskA Delphi-like paper-and-pencil exercise was conducted to refine and test the pro-posed typology. The set of 25 business controls identified in the preliminary stepwas split into two subsets of 12 and 13 controls. The first subset of 13 controls wasused in the first 3 rounds to revise the typology, referred to as the ?training set?. Thesecond subset of the remaining 12 controls was used in the last round to assess thevalidity of the resulting typology, referred to as the ?validation set?. Each roundwas facilitated by a questionnaire booklet that was disseminated independentlyto each of the three members of the advisory board. The booklet included theaforementioned brochure and a questionnaire to be filled out. Participants wereinstructed to complete the task individually and not to consult each other regardingcontrol classification choices.Figure 5.1 illustrates the main instrument used to drive the experimental pro-cedure. In each round, each participant was given a questionnaire composed ofa classification matrix in which each row corresponded to a single control to beclassified, and each column reflected a single classification dimension, which wasfurther split according to all of its possible levels. Participants were given instructionto mark (using a ??? symbol) the level they find most suitable for each dimension.They were also asked to indicate the level of certainty for their selection using anumber between 1 and 5, with 5 being the highest. A legend page was attachedto the answer sheet, providing a short summary of all the dimensions and levelsaccording to which each business control could be classified.The answer sheet in rounds two through four was extended to include accumu-lated information, thereby allowing participants to reconsider their previous choicesand revise them if desired. This adheres to the Delphi method [42], which is aimed atfacilitating informed judgement and having individual experts criticize each other?sviews. All questionnaire cells besides the one used in the first round included asummary of the responses from the previous round, expressed in two values: (1)number of participants who chose each level for a given control in the previous iter-ation, and (2) a value, in brackets, indicating the average degree of certainty for thatselection. Items for which there was no full agreement appeared in shadowed cells.In addition, participants were given space for open-ended comments to explain: (1)10716 July 2013 Page 2 of 5   Dimensions 1   2   3   4   5   6   Suggest more/remove                    Levels Controls T IC F NF S E HG SG P D C OL CL  Example: User Authentication and Authorization __ __ ?_ 5_  __ __ ?_ 3_ __ __ ?_ 4_ ?_ 5_ __ __ ?_ 5_ __ __ __ __ ?_ 2_ __ __ Dimension 6 is not required? Control 1:  "A review of accounts reconciliation" __ __  __ __ __ __  __ __ __ __ __ __  __ __  __ __ __ __ __ __  __ __ __ __ __ __      3(5) 3(3.6)   3(4) 3(3.6)   3(4.6)   3(3.6)  Control 2: "Credit check of new customers" __ __ __ __  __ __  __ __ __ __ __ __  __ __  __ __ __ __  __ __  __ __ __ __ __ __      3(3.6) 3(3.6)   3(4) 3(4)  1(4) 2(3.5)   3(4)  Control 3: "Review of daily deposit slips" __ __  __ __  __ __  __ __ __ __ __ __  __ __  __ __ __ __  __ __ __ __ __ __ __ __     1(4) 2(4) 3(3.6)   3(4) 3(4)  3(4.3)    3(4)  Control 4: "Spending limits by position? __ __  __ __ __ __  __ __ __ __  __ __  __ __  __ __ __ __  __ __ __ __ __ __  __ __    3(3.3)  3(3.3)  3(3.3)  3(4)  3(4.3)   3(3.3)   Control 5 __ __  __ __  __ __  __ __ __ __  __ __ __ __  __ __ __ __  __ __ __ __ __ __  __ __    2(4.5) 1(5) 3(3.6)  3(4)  3(4)  3(2.6)   3(4)   Control 6 __ __  __ __  __ __  __ __ __ __  __ __  __ __  __ __ __ __  __ __  __ __ __ __  __ __    1(3) 2(4) 3(3.6)  1(4) 2(4) 3(4)  2(4) 1(4)  3(2.6)   Control 7 __ __  __ __ __ __  __ __ __ __  __ __ __ __  __ __ __ __  __ __ __ __ __ __  __ __    3(4)  3(3.6)  3(4)  3(4)  3(3.6)   3(4)   Control 8 __ __  __ __ __ __  __ __ __ __  __ __ __ __  __ __ __ __  __ __ __ __ __ __  __ __    3(3.6)  3(3.6)  3(4)  3(4)  3(3.3)   3(4)   Control 9 __ __  __ __ __ __  __ __ __ __  __ __ __ __  __ __ __ __  __ __ __ __ __ __  __ __    3(3.6)  3(3.6)  3(4)  3(4)  3(3.6)   3(4)   Control 10 __ __  __ __ __ __ __ __  __ __  __ __ __ __ __ __  __ __ __ __  __ __ __ __  __ __    3(4)   3(2.6) 3(3.3)   3(3)  3(3.6)  3(4)   Control 11 __ __  __ __ __ __  __ __ __ __  __ __ __ __  __ __ __ __  __ __ __ __ __ __  __ __    3(2.6)  3(3.6)  3(2.3)  3(3.6)  3(2.3)   3(3)   Control 12 __ __  __ __ __ __ __ __  __ __  __ __ __ __ __ __  __ __ __ __  __ __ __ __ __ __     3(3.3)   3(3.3) 3(3.3)   3(3)  3(3.3)   3(4)  Control 13 __ __  __ __ __ __  __ __ __ __  __ __ __ __  __ __  __ __  __ __ __ __ __ __  __ __    3(3.3)  3(3.6)  3(3.3)  2(3.5) 1(3) 3(5)   3(3.6)      Figure 5.1: Delphi questionnaire - T: Target domain, IC: Implementationcomponent, F: functional (i.e., compliance), NF: non-functional (i.e.,substantive), S: State, E: Event, HG: Hard-goal, SG: Soft-goal, P: Pre-ventive, D: Detective, C: Corrective, OL: Open-loop (i.e., static), CL:Closed-loop (i.e., dynamic)the reasons for changes in items that were previously in full agreement, and (2) thereasons for the choice made where there was no full agreement.1085.3 Delphi Round OnePrior to the dissemination of the first questionnaire, I conducted a one-hour trainingsession to clarify the underlying model of control, the previously developed typology,and the experimental procedure to be pursued. This training session was attendedby the three members of the advisory panel and was facilitated by the slide deck inAppendix E.4. Following the training session, attendees were asked to individuallycomplete the classification task at a time of their convenience. They were givena booklet that included: the answer sheet to be filled out, the set of controls to beclassified, and the aforementioned two-page brochure. I collected the completedanswer sheets and consolidated the choices into the next round?s questionnaire.A quantitative summary of the results from round one appears in Table 5.3.Partial exhaustiveness in the results was attributed to the fact that none of thecontrols were classified as having ?corrective? risk functionality. When I checkedthe nature of the controls in the training set, I observed that indeed there was no?corrective? mechanism in the set. Despite its zero population, the level was notdropped as this seemed to be a unique characteristic of the business settings. At theend of the first round, the analysis of responses indicated that seven cells were indispute between the participants.109Measure ValueClassification coverage - the average portion of controls in thecontrol set that were fully instantiated according to all dimen-sions100% (13/13)Typology exhaustiveness - the average portion of dimensionlevels that were populated by at least one control in the controlset92% (12/13)Reliability - the portion of cells in agreement between partici-pants91% (71/78)Average level of confidence (1-5 highest) 3.70Table 5.3: Round one results1105.4 Delphi Round TwoThe second round was facilitated by a questionnaire that had the aforementionedsummary from round one. Any cells still under dispute appeared highlighted. Thishighlighting was brought to the attention of the participants both in the question-naire?s instructions and verbally in a meeting prior to the dissemination of thedocuments to be filled out in the second round. Based on the summary presented,participants were informed that they may indicate their choice again for any item,but in particular for items for which there was no full agreement. In addition, partic-ipants could also indicate if they wished to add or omit either a level or a dimensionin a designated column, as a possible resolution to any of the existing rows underdispute. To eliminate selection bias, it was also clarified to the participants that theyare not being forced to agree with the majority opinion. Participants were allowed tomodify any of their previous choices. However, participants were asked to indicatethe rationale for their new choices when they made changes.A quantitative summary of the results from round two is summarized in Table 5.4.On average, each respondent decided to make 8.33 choice modifications out of 78,based on 13 controls with 6 dimensions each. As a result, at the end of round two,the cumulative responses indicated that only one cell remained in dispute amongthe participants. This was achieved while preserving a similar level of confidenceas in the previous round (i.e., 3.68). A review of all choice justifications providedsome interesting insights regarding the nature of certain typological dimensions.Specifically, it was observed that in certain circumstances, there is no clear cutdifference between the different levels of the ?control risk functionality? dimension(i.e., preventive, corrective, detective). For example, the ?daily reviewing of depositslips? control, which is aimed at preventing the physical theft of cash at variouspoints of sale, is only capable of detecting the loss of cash once the goal has beencompromised. However, the mere existence of such a control activity, which wasalso known to all related point of sales personnel at UBC, also serves as a preventivemechanism for the goal ?prevention of future cash losses?. Hence, it was concludedthat the same control mechanism can play various roles and can be associated withseveral organizational objectives. Moreover, the same control can be attributeddifferent concrete characteristics with respect to each of its goals.111Measure ValueClassification coverage - the average portion of controls in thecontrol set that were fully instantiated according to all dimen-sions100% (13/13)Typology exhaustiveness - the average portion of dimensionlevels that were populated by at least one control in the controlset92% (12/13)Reliability - the portion of cells in agreement between partici-pants98.7% (77/78)Average level of confidence (1-5 highest) 3.68Average number of choice modifications (out of 78) 8.33Table 5.4: Round two resultsIn addition to the above observation, advisory panel noted that the terminologyused in the material was difficult since it was not consistent with the conventionalterms used in the everyday application of auditing. As a result, we changed thewording used to designate the levels of two dimensions. The levels in ?controlresponsibility? were re-worded from ?functional? and ?non-functional? to ?com-pliance? and ?substantive?, respectively. Similarly, the levels in ?control structure?were re-worded from ?open loop? and ?closed loop? to ?static? and ?dynamic?,respectively. Aside from the wording issue, no comments were made regarding theneed to either omit or add any dimensions or levels.Despite the aforementioned changes in terms, an inspection of the results showedgood comprehension of the levels, as reflected by the justifications given for thevarious choices. This was also reflected in the convergence to only a single cellbeing under dispute after the second round.1125.5 Delphi Round ThreeSimilar to the second round, the third round was facilitated by a questionnairepresenting the accumulated results from round two, with the remaining cell indispute highlighted. All previous comments about choice justifications were addedto the material in an anonymous fashion. The instructions were also the sameas in round two. The wording was adjusted to accommodate for the terminologypreferences indicated by the participants in the previous round.At the end of the third round, a full consensus was reached after having justone of the participants change his classification choice. The results are summarizedin Table 5.5. A similar level of confidence was attained across all three rounds.No additional comments were made regarding the need to either add, modify, ordrop any of the dimensions or levels in the classification scheme. Reaching a fullconsensus was a clear indicator that we had completed the training session. Hence,the next round was devoted to validating the typology.113Measure ValueClassification coverage - the average portion of controls in thecontrol set that were fully instantiated according to all dimen-sions100% (13/13)Typology exhaustiveness - the average portion of dimensionlevels that were populated by at least one control in the controlset92% (12/13)Reliability - the portion of cells in agreement between partici-pants100% (78/78)Average level of confidence (1-5 highest) 3.68Average number of choice modifications (out of 78) 0.33Table 5.5: Round three results1145.6 Delphi Round Four - FinalAfter fine-tuning the typology in the first three rounds, the fourth round was in-tended to test the final reliability and effectiveness of the typology as a controlmanagement instrument. I used the same classification scheme as in the previousrounds. However, unlike all previous rounds, participants were given a fresh set ofcontrols to be classified. This set was the one initially identified as the ?verification?set. Correspondingly, the forms to be filled out did not indicate any accumulatedindicators from previous rounds. As in all previous rounds, each participant wasinstructed to individually classify each of the controls in the new set, and to indicatethe level of confidence in each of the marked cells. The results are summarized inTable 5.6.As can be observed, the demonstrated reliability, represented by inter-rateragreement, increased from 91% in the first round to 98.6%. Understandably, someof this increase can be attributed to the learning effect that resulted from participationin the previous rounds. However, this effect was mitigated by the independent workof the participants and also by the use of a new set of controls. Hence, having onlya single cell out of 71 being in dispute in the first classification attempt, and alsowithout having participants consult each other, reflects an impressive achievementin reliability. This was also supported by a relatively high level of confidence.Similar to the case of the training set, no ?corrective? controls were found in the?verification? set. It is very likely that such controls would be evident in businessenvironments of the type studied in this experiment (i.e., university administration).It is possible that the lack of appearance of such mechanisms can simply be attributedto the scarcity of such mechanisms in business settings, and a local cultural tendencyto prefer ?preventive? mechanisms over ?corrective? ones. It could also be thatcorrective actions are done elsewhere in the organization. Possibly, this shouldbe identified as a potential red flag within the particular organizational unit thatwas investigated. In any case, a finding of this nature shows the benefits that canbe gained from using the developed typology as a managerial tool; that is, theidentification of missing controls that may require additional attention.115Measure ValueClassification coverage - the average portion of controls in thecontrol set that were fully instantiated according to all dimen-sions100% (12/12)Typology exhaustiveness - the average portion of dimensionlevels that were populated by at least one control in the controlset92% (12/13)Reliability - the portion of cells in agreement between partici-pants98.6% (71/72)Average level of confidence (1-5 highest) 3.94Table 5.6: Round four results - typology validity5.7 Conclusions and Lessons Learned from the DelphiExperimentTable 3.2 in Chapter 3 illustrates the resulting typology dimensions and leveldescriptions that were converged on after the four rounds. This table was alsoused as a form of a ?cheat sheet? given to the participants as a synopsis of theclassification scheme in the final round. The final wording was adjusted to accountfor the local terminology, as this was the main concern expressed by the director ofthe Internal Audit department:?Some of the terminology used in the material is difficult for us becauseit is not consistent with the terms we use in everyday application ofauditing.?Nevertheless, the experiment showed the developed typology to be fundamentallyeffective. It was also indicated that:?This exercise has certainly made us [the Audit department] thinkmore deeply about what we really should be auditing [what are the?controls?].?The engagement with the Internal Audit department was also a great lessonshowing that the notion of control in practice is much broader and less formalized116Specification attribute ActualTarget domain Fire-doorRule Door should be closed unless in useGoal Prevent the spread of fireImplementation component A returning springControl A sensor installed on either the door or the returningspring to sound an alarm if door is open more than acertain amount of timeTable 5.7: Fire door alarm - control specificationwhen compared with the model developed in this work. In some cases, the itemsinitially suggested as controls were noted as implementation components, some ascontrols, and some as rules. They were all considered as different types of controls.This led to the conclusion that there should be a distinct difference between ?controldefinition? and ?control specification?. The former should explain the main essenceof controls while the latter is a broader specification that details all of the componentsthat should be listed as part of the control mechanism. Considering the exampleof a fire door with a returning spring, a control such as fire alarm may be definedas a mechanism that is put in place to bring about the desired behaviour of the firedoor. However, to eliminate the aforementioned confusion, its full specificationshould describe not only its corresponding target domain, but also the rule to beadhered to, the corresponding goal the rule is intended to meet, a description of theimplementation component, and of the control itself. An example for a specificationof the fire door alarm is detailed in Table 5.7.The same experience, as occurred while generating the control data set jointlywith the unit?s director, indicated that there is also a preferred order or method thatcould help practitioners explore organizational activities and identify the natureof each internal control. This can be more easily achieved when identifying thecomponents of a control in the following order: (1) the target domain, (2) thegoal, (3) the rule, (4) the implementation component, and (5) control mechanism.This was found to be the preferred order. However, several iterations may berequired to ensure that the various attributes correspond correctly. For example,117once the rule ?no self-payment is made without authorization? is specified, it maybe necessary to further restrict the specification of the target domain from ?financialsystem? to ?payment system?. Consequently, it may be required to further refinethe identification of the implementation component, example, from ?supervisorpayment approval? to ?One-over-one signature?, and so on. These inter-relationshipsbetween the attributes of a control specification help increase the confidence in thecorrectness of the specification. The identification process seems to be very flexiblewhen we begin to assign values to each attribute. However, when the specificationis completed for all attributes, its correctness will likely be self-evident as a resultof the relationships between the attributes.The entire Delphi exercise resulted in two complementary instruments: (1) a setof specification attributes (i.e., Table 5.7), and (2) the illustrated set of classificationdimensions that represent a ?control typology?. Based on the results in the fourthround, it was concluded that the administration of control assets within realisticorganizational settings can be highly effective when using these instruments inconcert. Supported by high measurements of coverage and exhaustiveness, thisstudy was able to indicate that the use of the instruments within real business settingscan facilitate the effective and efficient use of existing control assets. The impliedbenefits include the ability to systematically manage a repository of existing controlsand to promote the identification of new ones in response to changes in policies andregulations in the organization. Designated information systems can be constructedfor easy maintenance of such business control repositories.In a final conversation with the unit?s director, it was noted that a small set ofprototypical control instances could serve as a benchmark to facilitate higher qualityclassification. This may be generalized to imply that in any particular domain, it isrecommended that prior to the deployment of the typology, a fairly restricted set ofcontrols that pertain to key concerns and major risks should be produced and usedlater as a ?golden standard?. Hence, the concrete controls in such domain/industry-specific prototypical directories of controls can be one of the streams identified forfurther research.Although it is highlighted here that formal control specification can help inidentifying missing controls, or explaining the motivation for existing ones, thespecification of controls in real settings sometimes remains flexible to allow for118judgment by the auditor who checks them. For example, an ?independent review?is still not fixed regarding whether it checks that the IC is operating (i.e., hard goal)or that it is operating adequately (i.e., soft goal). This is something for the auditorto find out during the audit process.119Chapter 6Conclusion6.1 Research SummaryMain Ideas? Control is a system, modeled as a set of controls, which are conceptualized aseither things or activities that interact with some other part(s) in the businessdomain (the target domain) to ensure its desired behaviour conforms to allbusiness-imposed expectations.? Control in business is motivated by three concerns: governance, risk, andcompliance.? Information Technology (IT) can be used to enforce control objectives. How-ever, IT itself may require its own unique controls.? An Information System (IS) can be used as the target of a control when itfaithfully represents some other part(s) in the organization.? The control model was defined using ontological concepts as a means to giveclear semantics to the newly developed concepts pertaining to the Enterpriseand Process views.? The developed model distinguishes between the implementation componentthat is intended to bring about the desired behaviour of the target domain,120and the control itself, which is intended to ensure this behaviour adheres tocertain laws.? To ensure adherence, control responsibility may be either compliance, whichensures that the behaviour of its target adheres to certain laws, or substantive,which ensures that the internal working of the implementation component isadequate.? From a process perspective, the model distinguishes between business activi-ties and control activities.? A business process model, illustrating a sequence of business activities, canbe derived from a set of control activities, which can then be enforced using athird-party control authority.Main Findings? To facilitate better comprehension of business process compliance, for userswho possess high domain familiarity, control activities should be modeledin a procedural form. Otherwise, control activities should be modeled in adeclarative form.? For users who possess low domain familiarity, a declarative form also pro-motes deeper understanding of the business process itself.? Business controls can be effectively classified according to the followingdimensions: focus, responsibility, objective, goal-type, risk functionality, andstructure.? The description of business controls was found useful when specified byseveral attributes. These include the control?s name, its target domain, therule being adhered to, the goal motivating the rule, and the correspondingimplementation component.? The entire control model was successfully validated by two applications:process model enrichment and control typology.121As mentioned in the introductory chapter, I started this work with the followingobjectives: (1) suggesting a clear conceptualization of the notion of control in thebusiness domain, and complementary to that (2) providing preliminary insightsregarding the potential gain from applying the developed conceptualization inpractice.With respect to the first objective, a fundamental control model has been devel-oped in Chapter 2. It was anchored in prior literature and has its semantics groundedin formal ontological concepts.With respect to the second objective, and to test the validity and usefulness ofthe developed conceptualizations, each of the model views was further refined intoa corresponding concrete application as presented in Chapter 3. This was followedby empirical testing, as reported in Chapters 4 and 5.The evaluation of the process model enrichment makes it possible to concludethat an explicit (declarative) representation of control activities has the highest like-lihood of promoting better compliance understanding. However, the effectivenessof the explicit representation was also found to be dependent on the person?s degreeof familiarity with the problem-domain.The assessment of the typology developed demonstrated its pragmatic effec-tiveness. It provided the linguistic terminology required to investigate businesscompliance with respect to a given repository of control assets, and helped identifymissing controls. This experience has also contributed to the assessment of thecompleteness of the developed model. Aside from ontological expressiveness, noother theory is available to determine model completeness. Hence, model com-pleteness was evaluated empirically. Completeness was attained both by giving theparticipants the option to either add or remove dimensions as much as they see fit,and by checking coverage and exhaustiveness in each of the Delphi rounds.6.2 Contributions to ResearchOf my research outcomes, the most significant contribution is the control modeldeveloped. From a scientific point of view, the developed model can be referredto as a control-specific ontology. The model is centered around conceptualizinga control-system as a set of controls that interact with the other elements in the122business domain to ensure all business operations conform to all business-imposedexpectations. The control system is then further conceptualized with respect to twocomplementary views, which clarify the role of business controls when conceivedas either materialized control system constituents (i.e., control as a ?thing?) or as be-havioural control system constituents (i.e., control as an ?action?). As demonstratedin this work, the control model itself can be employed to facilitate the assessmentand augmentation of existing modeling grammars, and to provide the underlyingterminology for analyzing control assets. Furthermore, the work itself contributes tothe existing body of knowledge in IS dealing with ontological applications. Specifi-cally, this work demonstrates the usefulness in exploiting ontological theories toderive concrete grammars that are applicable to realistic settings in the businessdomain.Having a clear theoretical foundation can drive further development of toolsand techniques that help manage the diversity of IT and business controls. Thedeveloped model provides terminology to facilitate effective communication acrossthe various parties involved in the investigation, management, and operation ofbusiness controls. Consequently, it can help promote the development of cross-industry standardization and tools to better cope with the burden of complianceimposed by regulators. As demonstrated in this work, the two complementary viewscan be used as the basis for innovative applications. Concrete applications can bedeveloped to ensure that administrative controls were well-designed and deployedacross the business, and to monitor the conformance of on-going business operationsto regulations.6.3 Contributions to PracticeCorresponding to the view of controls as ?actions? (Process View), this work ex-plored three alternatives to extend the conventional BPMN process modeling tech-nique to include the specification of such controls. Each such representation style isin itself a contribution to practice. The typology developed corresponding to theview of controls as ?things? (Enterprise View), is another contribution.Overall, both empirical experiences provide evidence for the internal validity ofthe control model developed and its usefulness. Model validity was demonstrated by123the successful realization of the two applications in the context of realistic businessdata. Their usefulness was evidenced in the actual use of the developed applicationsby the two experimental audiences, novice and expert. In both cases, the controlmodel demonstrated its potential for use to derive new technologies, such as abetter process analysis tool and a unique control classification scheme. It wasclear from both empirical experiences that making business controls explicit aseither process activities or as unique assets, can promote the assurance of bettercompliance. Specifically, the developed conceptualizations were shown to providethe vocabulary currently missing to describe and analyze business controls in thecontext of other business elements, in order to assess compliance.The proposed extension to BPMN is a first attempt to formulate controls inbusiness process modeling. The empirical evaluation demonstrated the usefulnessof a modeling technique that explicitly incorporates control activities, and yielded aconcrete process modeling grammar that can be used by practitioners. A concreterepresentation style was also inferred given the level of expertise possessed by theusers. Since both extension styles used the annotation symbol for this purpose,all existing BPMN modeling tools can directly benefit from the proposed controlrepresentation without any further technical modifications.The contribution of the control typology described is twofold. Theoretically, itcan be considered a ?white box? refinement to the conceptualization of controls. Thetwo views, which consider the control notion from an external point of view (i.e., asa ?black box?), describe its purpose and link it to other organizational domains orprocess activities. Unlike these views, the typology is a further refinement aboutthe additional intrinsic characteristics of each control mechanism. Practically, as inthe case of the extended process grammar, the developed typology is expected tobe a tool that can help analyze control needs and to communicate and manage theinformation about organizational control assets. As such, it provides the conceptualbasis for a computerized system that can support the analysis of control assets.6.4 Limitations of the ResearchPossible criticism of this work may emerge from its exploratory nature resultingfrom the absence of previous research of fundamental theory. As such, the validity124of the proposed model is also subject to repeatable empirical investigations in thefuture, for which the conclusions in this work may be confirmed (or falsified). Fur-ther, its ontological foundations having strong roots in the materialistic perspectiveof reality may be lacking some additional characteristics about controls (e.g., social,emotional) that might be considered as being essential to its more accurate conceptu-alization in the future. This may have been shaped by the focus on high-level views(i.e., enterprise and process), while potentially leaving out more specific aspectsthat may have been relevant to the developed conceptualization. For example, theproposed conceptualization does not address performance and cost-benefit consider-ations related to adding controls. In practice, the insertion of controls into a processmay result in performance degradation (i.e., more actions in the process executed).It is also possible that some controls can be excluded based on risk, reliability, andcost-benefit considerations. As a result of such analyses, it may be concluded that itis worth extending the conceptualization further to distinguish between risk-criticaland regulatory controls.Both empirical studies can be criticized for lack of external validity. That is,the results in the empirical studies may be limited by the unique characteristicssuch as their participants, the particular domain of control focused on, the modelinglanguage employed (i.e., BPMN), the type of organization (i.e., a university), and itsparticular characteristics (e.g., a medium-size / centralized business unit). As such,the evaluation of the process model enrichment, which focused solely on BPMN, mayrequire future replications using alternative process modeling grammars. Similarly,the general applicability of the developed typology to other control types rooted indifferent business domains may be limited. In this regard, analogous to measures ofconstruct validity in the development of research models (e.g., structural equationmodeling), it appears to be more sensible to consider the typological dimensionsas formative indicators rather than reflective indicators. That is, the significance ofeach indicator may be subject to the local settings in which it was found to be a validantecedent. Practically, this means that any organization that decides to adopt thetypology as an analysis tool may be required to adjust it to its local environment first,identifying the relevance of its dimensions and their levels. However, the intendedexploratory nature of this work was aimed at gaining a preliminary understanding ofthe possible benefits that can be drawn from using the theoretical model developed.1256.5 Future Research DirectionsConsidering the exploratory nature of this work, it is acknowledged that its resultsprovide a solid ground for further confirmatory work in the domain of businessprocess compliance, with a focus on increasing its reproducibility in various businesssettings.Future work can be considered for three research streams. The first stream isconfirmation, including any quantitative or qualitative work aimed at empiricallytesting the developed model to better establish its internal and external validity.Possible routes may include attempts to repeat the empirical work conducted in thisstudy using different modeling grammars, such as Peti-nets or EPC. The researchcould approach users at different levels of expertise, geographies, organizations, orindustries. Since there are sometime differences in laws, standards, and regulationsamong countries, some insights may also be gained by switching between culturesor geographies. The second stream of future work involves refinement, includingfurther specialization and refinement of the developed conceptualization to includemore concrete aspects. For example, investigating the difference between controls indifferent industries (e.g., manufacturing vs. healthcare) may require some additionalconstructs the do not yet exist in the developed model. The third stream involvesapplication, including realizations of the developed model into other applicationdomains and organizational structures that can help further assess the usefulness ofthe developed model. For example, including controls in a software architecture andits implementation may reveal additional concerns that were not highlighted by thiswork. Unique organizational structures that establish a third-party control authoritycan be devised to better accommodate the potential risk associated with in-housecontrol management. Organizations dealing with the integration of control concernsinto the business may lack the required knowledge and resources for handling allimposed regulations. As stated - ?This risk is amplified when those responsible arenot experienced in the design and assessment of IT controls or lack the necessaryskill or management structure to identify and focus on the areas of most significantrisk? (The IT Governance Institute, 2006).I find it important to conclude this work with my own view of its scientificpositioning. Similar to the work by Grenon et al. [26], I would stress its nature126as being realistic, perspectivalistic, and fallibilistic. Realism entails that realityabout controls in business is a global concern, existing independent of the proposedconceptualizations. I also think that in many organizational circumstances, businesscompliance can be determined objectively. Perspectivalism entails that there existseveral, equally legitimate perspectives on reality. However, being subject to realism,some views may be deemed either invalid or not very useful. In order to determinewhich views are better than others, they should be confronted with reality throughscientific experiments, similar to the two applications empirically evaluated in thiswork. But, even views that are considered effective and useful at any point intime, are continuously subject to further refinements and fallibilism as technologyadvances and new knowledge is acquired. At the moment, my work is a firstattempt to devise useful foundations for the creation of such applications in thearea of business control. I hope it will provide the basis for additional, yet usefulapplications in the future.127Bibliography[1] AMERICAN INSTITUTE OF CERTIFIED PUBLIC ACCOUNTANTS (AICPA).Continuous Auditing - Research Report. Tech. rep., 1999. ? pages 5[2] ASHCRAFT, M. H. Cognition, 4th ed. Prentice Hall, NJ, 2005. ? pages 48,51[3] BAILEY, K. D. Typologies and Taxonomies: An Introduction to ClassificationTechniques. Sage Publications Inc, 1994. ? pages 54[4] BENIGER, J. R. The Control Revolution: Technological and EconomicOrigins of the Information Society. Harvard University Press, 1986. ? pages1, 2[5] BODART, F., PATEL, A., SIM, M., AND WEBER, R. Should the OptionalProperty Construct be Used in Conceptual Modeling? A Theory and ThreeEmpirical Tests,. Information Systems Research 12, 4 (2001), 384?405. ?pages 51[6] BOEHM, B. W. Software Risk Management: Principles and Practices.Software, IEEE 8, 1 (1991), 32?41. ? pages 56[7] BUNGE, M. Treatise on Basic Philosophy: Volume 3: Ontology I: TheFurniture of the World. Treatise on Basic Philosophy. Springer, 1977. ?pages 12, 13[8] BUNGE, M. A World of Systems, Treatise on Basic Philosophy: Volume 4.Ontology / Mario Bunge. Reidel, 1979. ? pages 13[9] BURTON-JONES, A., AND MESO, P. N. Conceptualizing Systems forUnderstanding: An Empirical Test of Decomposition Principles inObject-Oriented Analysis. Information Systems Research 17, 1 (Mar. 2006),38?60. ? pages 51, 65128[10] CHERNS, A. Principles of Sociotechnical Design Revisted. Human Relations(1987). ? pages 7[11] COHEN, J. A Power Primer. Psychological Bulletin 112, 1 (1992), 155. ?pages 71[12] COLLINS, A. M., AND QUILLIAN, M. R. Retrieval Time from SemanticMemory. Journal of Verbal Learning and Verbal Behavior 8, 2 (1969),240?247. ? pages 51[13] DISTEFANO, J. J., STUBBERUD, A. J., AND WILLIAMS, I. J. Schaum?sOutline of Feedback and Control Systems, 2nd ed. McGraw-Hill Professional,1997. ? pages 3[14] EID, T., AND CALDWELL, F. Finance and Audit GRC Software Market isExpanding. Tech. rep., Gartner Research, 2006. ? pages 6[15] ERL, T. Service-Oriented Architecture: Concepts, Technology, and Design.Prentice Hall service-oriented computing series from Thomas Erl. PearsonEducation, 2005. ? pages 36[16] EVERMANN, J. M. Using Design Languages for Conceptual Modelling: TheUML Case. Tech. rep., University of British Columbia, 2003. ? pages 14[17] EVERMANN, J. M. A UML and OWL description of Bunge?s Upper-LevelOntology Model. Software & Systems Modeling (2009). ? pages 14[18] FAYOL, H., AND GRAY, I. General and Industrial Management. Institute ofElectrical and Electronics Engineers, 1984. ? pages 3[19] FREEZE, R., AND RASCHKE, R. L. An Assessment of Formative andReflective Constructs in IS Research. In ECIS 2007 Proceedings (2007). ?pages 75[20] GEMINO, A., AND WAND, Y. Evaluating Modeling Techniques Based onModels of Learning. Communications of the ACM 46, 10 (Oct. 2003), 79?84.? pages 49, 65[21] GEMINO, A., AND WAND, Y. A Framework for Empirical Evaluation ofConceptual Modeling Techniques. Requirements Engineering 9, 4 (2004),248?260. ? pages 50, 64, 65[22] GEMINO, A., AND WAND, Y. Complexity and Clarity in ConceptualModeling: Comparison of Mandatory and Optional Properties. Data &Knowledge Engineering 55, 3 (2005), 301?326. ? pages 51, 65129[23] GEMINO, A. C. Empirical Comparisons of System Analysis ModelingTechniques. PhD Thesis, University of British Columbia (1999). ? pages 65[24] GERARDO, D. A. CISA Review Manual 2003. Information Systems Auditand Control Association, 2003. ? pages 1, 25, 105[25] GLOBAL AUDIT INFORMATION NETWORK (GAIN). 2009 IT AUDITBENCHMARKING STUDY. Tech. rep., The Institute of Internal Auditors,2009. ? pages 6[26] GRENON, P., AND SMITH, B. SNAP and SPAN: Towards Dynamic SpatialOntology. Spatial Cognition and Computation 4, 1 (2004), 69?104. ? pages126[27] HAGERTY, J. SOX Spending for 2006. Tech. rep., AMR Research, Boston,USA, 2007. ? pages 6[28] HEIJ, C., RAN, A. C. M., AND VAN SCHAGEN, F. Introduction toMathematical Systems Theory: Linear systems, Identification and Control.Birkha?user Basel, 2007. ? pages 57[29] HEVNER, A. R., MARCH, S. T., PARK, J., AND RAM, S. Design Science inInformation Systems Research. MIS Quarterly 28, 1 (2004), 75?106. ?pages 53[30] HUNG, P. C. K., AND KARLAPALEM, K. A Secure Workflow Model.Proceedings of the Australasian Information Security Workshop Conferenceon ACSW Frontiers 2003-Volume 21 (2003), 33?41. ? pages 34[31] HUSSERL, E. Logical Investigations. No. v. 1 in International Library ofPhilosophy. Taylor & Francis, 2001. ? pages 11, 18[32] ISACA, C. Review Manual 2007. 2007. ? pages 4[33] IT GOVERNANCE INSTITUTE. Cobit 4.0: Control Objectives, ManagementGuidelines, Maturity Models, 2005. ? pages 7, 34[34] KHATRI, V., VESSEY, I., RAMESH, V., CLAY, P., AND PARK, S. J.Understanding Conceptual Schemas: Exploring the Role of Application andIS Domain Knowledge. Information Systems Research 17, 1 (2006), 81?99.? pages 94[35] KOGAN, A., SUDIT, E. F., AND VASARHELYI, M. A. Continuous OnlineAuditing: A Program of Research. Journal of Information Systems 13, 2(1999), 87?103. ? pages 5130[36] KRUCHTEN, P. The 4 + 1 view model of architecture. IEEE Software 12, 6(1995), 42?50. ? pages 12[37] LANDER, G. P. What is Sarbanes-Oxley? McGraw Hill, 2004. ? pages 4[38] LEVESON, N. G. The Challenge of Building Process-Control Software.Software, IEEE 7, 6 (1990), 55?62. ? pages 3[39] LIMONAD, L., AND WAND, Y. Extending Business Process Models withControls. In AIS Special Interest Group on Systems Analysis and Design(SIGSAND?08) (Provo, Utah, May 2008). ? pages 31, 44[40] LIMONAD, L., AND WAND, Y. A Conceptual Model and Typology forInformation Systems Controls. In Proceedings of the 15th AmericasConference on Information Systems (San Francisco, California, Aug. 2009).? pages 19, 44, 57[41] LIMONAD, L., AND WAND, Y. Software Architecture to Assure ControlCompliance of Business-Processes. In AIS Special Interest Group on SystemsAnalysis and Design Workshop (Richmond, Virginia, 2009). ? pages 9, 41[42] LINSTONE, H. A., AND TUROFF, M. Delphi Method: Techniques andApplications. Addison-Wesley, 1975. ? pages 62, 107[43] MARCH, J., SCHULZ, M., AND XUEGUANG, Z. The Dynamics of Rules:Change in Written Organizational Codes. Stanford University Press, 2000. ?pages 44[44] MAYER, R. E. Models for Understanding. Review of Educational Research59, 1 (Jan. 1989), 43?64. ? pages 50, 65[45] MCCLEAN, C., TIAZKUN, S., MCNABB, K., AND DILL, A. Trends 2009:Governance, Risk, and Compliance Hit the Big Time, The Economic Crisis of2008 Makes GRC A Business Priority. Tech. rep., Forrester Research, Inc.,2008. ? pages 6[46] MCDONOUGH, B. Worldwide Financial Performance, Strategy Management,and GRC Applications 2011 Vendor Shares. Tech. rep., IDC, 2011. ? pages6[47] MOODY, D. The Physics of Notations: Toward a Scientific Basis forConstructing Visual Notations in Software Engineering. IEEE Transactionson Software Engineering 35, 6 (Nov. 2009), 756?779. ? pages 47, 49131[48] MOORE, G. C., AND BENBASAT, I. Development of an Instrument toMeasure the Perceptions of Adopting an Information Technology Innovation.Information systems research 2, 3 (1991), 192?222. ? pages 68[49] MYLOPOULOS, J. Conceptual Modelling and Telos. Conceptual Modelling,Databases, and CASE: an Integrated View of Information SystemDevelopment, John Wiley & Sons, New York, New York (1992), 49?68. ?pages 45[50] NORMAN, D. Cognitive Engineering. User Centered System Design (1986).? pages 65[51] NORMAN, D. A. The Design of Everyday Things, vol. 16. 2002. ? pages 50[52] NUNNALLY, J., AND BERNSTEIN, I. Psychometric Theory. McGraw, NewYork (1994). ? pages 78[53] OMG. Unified Modeling Language: Superstructure. OMG (2005). ? pages12[54] ORLIKOWSKI, W. J., AND IACONO, C. S. Research Commentary:Desperately Seeking the IT in IT ResearchA Call to Theorizing the ITArtifact. Information Systems Research 12, 2 (2001), 121?134. ? pages 7[55] PETRI, C. A. Communication with Automata: Volume 1 supplement 1. Tech.rep., DTIC Document, 1966. ? pages 44[56] POWER, M. The Audit Society: Rituals of Verification. OUP Catalogue(1999). ? pages 5[57] RECKER, J. C., INDULSKA, M., ROSEMANN, M., AND GREEN, P. HowGood is BPMN Really? Insights from Theory and Practice. 14th EuropeanConference on Information Systems (2006). ? pages 46[58] ROSEMANN, M., AND GREEN, P. Developing a Meta Model for theBungeWandWeber Ontological Constructs. Information Systems 27, 2 (2002),75?91. ? pages 14[59] SCHEER, A. W. ARIS?Business Process Frameworks. Springer, 1998. ?pages 44[60] SHANKS, G., TANSLEY, E., NUREDINI, J., TOBIN, D., AND WEBER, R.Representing Part-Whole Relationships in Conceptual Modeling: AnEmpirical Evaluation. In 23rd International Conference on Information132Systems: ICIS 2002 (2002), vol. 17, IEEE Educational Activities Department,pp. 89?100. ? pages 65[61] SOFFER, P., AND WAND, Y. Goal-Driven Analysis of Process ModelValidity. vol. 4, Springer. ? pages 19, 31, 49[62] SOFFER, P., AND WAND, Y. On the Notion of Soft-Goals in BusinessProcess Modeling. Business Process Management Journal 11, 6 (2005),663?679. ? pages 32, 34, 56[63] SOFFER, P., AND WAND, Y. Goal-Driven Multi-Process Analysis. Journal ofthe Association for Information Systems 8, 3 (2007), 175?202. ? pages 19,31, 32, 49[64] STONEBURNER, G., GOGUEN, A., AND FERINGA, A. Risk ManagementGuide for Information Technology Systems. NIST Special Publication (2002),800?830. ? pages 56[65] STOREY, N. R. Safety Critical Computer Systems. Addison-WesleyLongman Publishing Co., Inc. Boston, MA, USA, 1996. ? pages 27[66] TURBAN, E., MCLEAN, E., AND WETHERBE, J. Information Technologyfor Management: Making Connections for Strategic Advantage. Wiley, 1998.? pages 7[67] VAN GREMBERGEN, W. The Balanced Scorecard and IT Governance.Challenges of Information Technology Management in the 21st Century(2000), 1123. ? pages 2[68] VAN GREMBERGEN, W., AND DEHAES, S. Implementing InformationTechnology Governance Models, Practices, and Cases. IGI Pub, 2008. ?pages 2[69] WAND, Y., AND WEBER, R. An Ontological Analysis of Some FundamentalInformation Systems Concepts. In Proceedings of the Ninth InternationalConference on Information Systems (1988), pp. 213?226. ? pages 13, 19[70] WAND, Y., AND WEBER, R. A Model of Control and Audit ProcedureChange in Evolving Data Processing Systems. The Accounting Review 64, 1(1989), 87?107. ? pages 18, 24, 35, 38[71] WAND, Y., AND WEBER, R. An Ontological Model of an InformationSystem. IEEE Transactions on Software Engineering 16, 11 (1990),1282?1292. ? pages 13133[72] WAND, Y., AND WEBER, R. On the Ontological Expressiveness ofInformation Systems Analysis and Design Grammars. Information SystemsJournal 3, 4 (1993), 217?237. ? pages 45, 46, 52[73] WAND, Y., AND WEBER, R. On the Deep Structure of Information Systems.Information Systems Journal 5, 3 (1995), 203?223. ? pages 7, 13, 28[74] WEBER, R. A. Information Systems Control and Audit. Pearson Education,1998. ? pages 3, 5, 11, 18, 24, 25[75] WESTBY, J. R. Governance of Enterprise Security: CyLab 2012 Report.Tech. rep., Carnegie Mellon University & Jody R. Westby, 2012. ? pages 6[76] WFMC. Workflow Management Coalition Terminology & Glossary.Management 39, 3 (1999), 1?65. ? pages 8, 34[77] WHITE, S. A. Introduction to BPMN. IBM Cooperation (2004). ? pages 44[78] WINOGRAD, T. Frame Representations and the Declarative/ProceduralControversy. Representation and Understanding: Studies in CognitiveScience (1975), 185?210. ? pages 48, 52, 53[79] ZUR MUEHLEN, M., AND INDULSKA, M. Modeling Languages forBusiness Processes and Business Rules: A Representational Analysis.Information Systems 35, 4 (2010), 379?390. ? pages 44, 45134Appendices135Appendix AEnterprise View - DetailedFormalizationThe formalism described here is complementary to the enterprise view that isexplained in Chapter 2 comprising: the target domain T , the implementation com-ponent domain IC, and the control domain C.We denote the behaviours of the target domain and the implementation compo-nent by BT and BIC, respectively.Definition 5. The expected behaviour of the target domain is -BT (E) =< ST (E),ET (E),LT (E) >where:ST (E) are the acceptable states, ET (E) is the set of expected external events, andLT (E) is the set of transformations that can happen.Both sets ET (E) and LT (E) are in the form of < s? s? > |s,s? ? ST (E). InET (E), s is stable and the change is forced by an interaction with something outsidethe domain leading to an unstable state s?. In LT (E), s is unstable and a changehappens due to actions within the domain.Although ST (E) includes only acceptable states, it is also possible to describerequired states in the definition of BT (E). A required state sr is either a direct result136of an expected external event (i.e., ?s :< s? sr >? ET (E)) or an indirect outcomeof an external event reached through a sequence of internal transitions included inLT (E).In the context of the fire door example, ST (E) can include all positions andangles the door can be at as depicted in the door blueprint. ET (E) includes all directreactions of the fire door to external stimuli as described in the blueprint (e.g., thedoor being pushed from the inside). LT (E) includes all indirect reactions that willeventually change the state of the door to being closed as required by the OSHApolicy.Definition 6. The actual behaviour of the target domain is -BT (A) =< ST (A),ET (A),LT (A) >such that:ST (A) is the set of all actual states that can be observed, ET (A) is the set of allactual external events that can be observed, and LT (A) is the set of all internaltransformations that actually occur.We assume that everything that can happen over time will be eventually ob-served.The formalization of actual behaviour is based on the assumption of determinis-tic behaviour as follows:Assumption 3. The actual behaviour BT (A) is deterministic. That is, given aspecific initial state, if the same external stimuli occur, the system will always reachthe same state.The expected behaviour is captured by the allowed states ST (E) and transforma-tion laws LT (E), and reflects both laws of nature and organizational requirementsreflecting regulations, business policies, and norms. Except for laws of nature,all other laws cannot be guaranteed to hold in the actual behaviour of the targetdomain. To enforce these laws, additional mechanisms are often used. We termsuch a mechanism an implementation component. In the fire door example, theimplementation mechanism is the returning spring intended to shut the door after ithas been opened.137The implementation component comprises a separate domain (IC) than thetarget domain. However, the two domains are connected. This means that theycan interact and (ontologically) this means they have some mutual state variables.For example, the spring is attached to the door. We define the implementationcomponent:Definition 7. An implementation component is an artifact that is included in thetarget domain so that the combined behaviour will satisfy: ST (A) = ST (E) andLT (E)? LT (A).Note, the definition allows for additional transformation laws (specifically, thoserelated to the behaviour of the IC).In our example, the spring is one possible realization of an implementationcomponent. Other realizations, not necessarily technological, are also possible. Forexample, a policy that forces employees to ensure the door is shut.Similar to the target domain, the implementation component has two assignedbehaviours - expected and actual:Definition 8. The expected behaviour of the implementation component is -BIC(E) =< SIC(E),EIC(E),LIC(E) >Definition 9. The actual behaviour of the implementation component is -BIC(A) =< SIC(A),EIC(A),LIC(A) >The interpretation of each element in these definitions is the same as for thetarget domain.The implementation component is intended to ensure the correct behaviourof the target domain T . Hence, its expected behaviour should include a part thatreflects this behaviour. We term this the derived behaviour (denoted BIC(E)/T ). Forexample, whenever the door is open the spring is expected to push it back. As well,the implementation component has an inherent behaviour (BIC(E)?BIC(E)/T ). Anexample would be the internal working of the spring. Accordingly, we distinguishbetween:138? E IC(E)/T and LIC(E)/T external events and internal transitions of IC thatrepresent the expected behaviour of T .? E IC(E)?E IC(E)/T and LIC(E)?LIC(E)/T all external events and internaltransitions of IC not derived from the expected behaviour of T (i.e., inherentto IC).The insertion of the implementation component adds new external stimuli tothe behaviour of the target domain. These add events to ET (A) which are the resultof the interaction between the target and implementation domains, hence:Assumption 4. The insertion of an implementation component does not add any newevent to the target domain T that has no corresponding event in the implementationcomponent domain IC.Being an artifact, the actual behaviour of the implementation component mightbe different than expected, possibly failing to ensure the target domain behaves asexpected. The purpose of a control system is to overcome this problem.Similar to the implementation component, the control system resides in its owndomain - the control domain C. Like all other domains, the domain C is associatedwith two behaviours - expected and actual:Definition 10. The expected behaviour of the control system is -BC(E) =< SC(E),EC(E),LC(E) >Definition 11. The actual behaviour of the control system is -BC(A) =< SC(A),EC(A),LC(A) >The expected behaviour of the control system has a dual responsibility:? Compliance - ensuring that the implementation component achieves its objec-tive, by checking that the actual behaviour of the target domain BT (A) meetsall acceptable states and expected transitions in BT (E).139? Substantive - ensuring that the inherent operation of the implementationcomponent is as expected, namely, checking that BIC(A)?BIC(A)/T meetsall its inherent expected behaviour BIC(E)?BIC(E)/T (i.e., all aspects notrelated directly to the target domain behaviour).Conformance of the control system?s actual behaviour to its expected behaviouris the focus of audit which is beyond the scope of this model.140Appendix BExperimental Results andAssumption Testing?? - is used to highlight a significant result (i.e., p < .05)? - is used to highlight a moderately significant result (i.e., .05 < p < .1)B.1 MANOVACase I: Student Registration - The multivariate analysis of variance (i.e., MANOVA)showed that:1. The effect of control representation on domain-comprehension was not significant,F(2,57) = .66,MSE = 2.39, p = .26.2. The effect of control representation on compliance-comprehension was moderately significant,*F(2,57) = 2.19,MSE = 2.35, p = .06.3. The effect of control representation on domain problem-solving was not significant,F(2,57) = .26,MSE = 2.26, p = .39.4. The effect of control representation on compliance problem-solving wasnot significant, F(2,57) = .30,MSE = 5.02, p = .37.1415. The effect of control representation on ease-of-use perception was not significant,F(2,57) = 1.09,MSE = .68, p = .17.Case II: Mortgage Application - The multivariate analysis of variance (i.e., MANOVA)showed that:1. The effect of control representation on domain-comprehension was not significant,F(2,54) = .54,MSE = 2.10, p = .29.2. The effect of control representation on compliance-comprehension was not significant,F(2,54) = .04,MSE = 2.52, p = .48.3. The effect of control representation on domain problem-solving was significant,**F(2,54) = 3.15,MSE = 1.78, p = .03.4. The effect of control representation on compliance problem-solving wassignificant, F(2,54) = 2.41,MSE = 3.64, p = .05. **5. The effect of control representation on ease-of-use perception was significant, **F(2,54) = 2.62,MSE = .43, p = .04.B.2 MANCOVACase I: Student Registration - After adjusting for the effect of prior BPMN knowl-edge and knowledge in the domain of student registration, multivariate analysis ofcovariance (i.e., MANCOVA) showed that:1. The effect of control representation on domain-comprehension was not significant,F(2,55) = .93,MSE = 2.40, p = .20.2. The effect of control representation on compliance-comprehension was moderately significant,*F(2,55) = 2.32,MSE = 2.38, p = .05.3. The effect of control representation on domain problem-solving was not significant,F(2,55) = .28,MSE = 2.33, p = .38.1424. The effect of control representation on compliance problem-solving wasnot significant, F(2,55) = .29,MSE = 5.10, p = .37.5. The effect of control representation on ease-of-use perception was not significant,F(2,55) = 1.10,MSE = .70, p = .17.Case II: Mortgage Application - After adjusting for the effect of prior BPMNknowledge and knowledge in the domain of mortgage application, multivariateanalysis of covariance (i.e., MANCOVA) showed that:1. The effect of control representation on domain-comprehension was not significant,F(2,52) = .56,MSE = 1.97, p = .29.2. The effect of control representation on compliance-comprehension was not significant,F(2,52) = .02,MSE = 2.61, p = .49.3. The effect of control representation on domain problem-solving was significant,**F(2,52) = 3.10,MSE = 1.79, p = .03.4. The effect of control representation on compliance problem-solving wassignificant, F(2,52) = 3.05,MSE = 3.62, p = .03. **5. The effect of control representation on ease-of-use perception was significant, **F(2,52) = 2.88,MSE = .44, p = .03.B.3 Post-hoc AnalysisCase I: Student RegistrationCompliance Comprehension - The MANCOVA analysis showed that afteradjusting for the effect of background factors, the effect of control representationon compliance-comprehension was moderately significant, F(2,55) = 2.32,MSE = *2.38, p = .054.Consistent with the MANCOVA result above, Sidak-corrected post-hoc compar-isons indicated:1431. a significant difference between the score in the explicit procedural group **(M = 6.76,SD = .35) and the score in the implicit representation group(M = 5.71,SD = .35), p = .02.2. a moderately significant difference between the score in the explicit declara- *tive group (M = 6.36,SD = .35) and the score in the implicit representationgroup (M = 5.71,SD = .35), p = .097.There have been no further significant pair-wise differences evident in theresults.Case II: Mortgage ApplicationDomain Problem-Solving - The MANCOVA analysis showed that after ad-justing for the effect of background factors, the effect of control representation ondomain-problem-solving was significant, F(2,52) = 3.10,MSE = 1.79, p = .03. **Consistent with the MANCOVA result above, Sidak-corrected post-hoc compar-isons indicated:1. a moderately significant difference between the score in the explicit declara- *tive group (M = 4.83,SD = .30) and the score in the implicit representationgroup (M = 4.24,SD = .32), p = .09.2. a significant difference between the score in the explicit declarative group **(M = 4.83,SD = .30) and the score in the explicit procedural group (M =3.73,SD = .32), p = .01.There have been no further significant pair-wise differences evident in theresults.Compliance Problem-Solving - The MANCOVA analysis showed that afteradjusting for the effect of background factors, the effect of control representation oncompliance problem-solving was significant, F(2,52) = 3.05,MSE = 3.62, p = .03. **Consistent with the MANCOVA results above, Sidak-corrected post-hoc com-parisons indicated:1. a moderately significant difference between the score in the explicit procedu- *144ral group (M = 2.81,SD = .46) and the score in the implicit representationgroup (M = 3.87,SD = .45), p = .06.2. a significant difference between the score in the explicit declarative group **(M = 4.34,SD = .43) and the score in the explicit procedural group (M =2.81,SD = .46), p = .01.There have been no further significant pair-wise differences evident in theresults.Ease-of-use - The MANCOVA analysis showed that after adjusting for theeffect of background factors, the effect of control representation on ease-of-use wassignificant, F(2,52) = 2.88,MSE = .44, p = .03. **Consistent with the MANCOVA result above, Sidak-corrected post-hoc compar-isons indicated:1. a significant difference between the score in the explicit declarative group **(M = 3.93,SD = .15) and the score in the implicit representation group(M = 4.45,SD = .16), p = .01.2. a moderately significant difference between the score in the explicit declar- *ative group (M = 3.93,SD = .15) and the score in the explicit proceduralgroup (M = 4.23,SD = .16), p = .08.There have been no further significant pair-wise differences evident in theresults.B.4 Assessment of Analysis AssumptionsMain analysis in the process enrichment experiment was conducted using Multivari-ate Analysis of Co-variance (MANCOVA). As reported in this appendix, all of thefollowing test assumptions have been checked to ensure the analysis is valid:1. Independence of observations.2. Normal distribution of data.3. No correlations among covariates.1454. Homoscedasticity - i.e., homogeneity of variance across all groups of thetreatment.5. Homogeneity of regression slopes - i.e., the relationship between the covariateand the dependent variable should be similar across all groups of the treatment.Also, it is assumed that the relationship of the dependent variables to the independentvariables and the covariates is linear.Independence of observations was satisfied by the random assignment in experi-ment design. Supported by Q-Q plots, the data were normally distributed.Correlation between covariates (i.e., BPMN modeling knowledge and domainknowledge) was found to be very weak. In the student registration domain, corre-lation between modeling and domain knowledge was r = .05 and in the mortgageapplication domain, correlation between modeling knowledge and domain knowl-edge was r = .08. Hence, both covariates have been included in the analysis.Case I: Student RegistrationDomain Comprehension - Levene?s test, (F(2,57) = .25, p = .77) showed thatvariances between groups were homogeneous.Consistent with homogeneity of regression slopes, analysis of the interactionsbetween each covariate and the given treatment (i.e., control representation) con-cluded that none is significant, as follows:1. The relationship between domain-comprehension and prior knowledge inBPMN modeling did not depend on the type of control representation, (F(2,48) =.07, p = .93).2. The relationship between domain-comprehension and knowledge in the do-main of student registration did not depend on the type of control representa-tion, (F(2,48) = .41, p = .67).Compliance Comprehension - Levene?s test, (F(2,57) = 3.13, p = .051) showedthat variances between groups were homogeneous.Consistent with homogeneity of regression slopes, analysis of the interactionsbetween each covariate and the given treatment (i.e., control representation) con-cluded that none is significant, as follows:1461. The relationship between compliance-comprehension and prior knowledgein BPMN modeling did not depend on the type of control representation,(F(2,48) = .02, p = .98).2. The relationship between compliance-comprehension and knowledge in thedomain of student registration did not depend on the type of control represen-tation, (F(2,48) = .03, p = .97).Domain Problem-Solving - Levene?s test, (F(2,57) = .71, p = .50) showedthat variances between groups were homogeneous.Consistent with homogeneity of regression slopes, analysis of the interactionsbetween each covariate and the given treatment (i.e., control representation) con-cluded that none is significant, as follows:1. The relationship between domain problem-solving and prior knowledgein BPMN modeling did not depend on the type of control representation,(F(2,48) = .49, p = .62).2. The relationship between domain problem-solving and knowledge in thedomain of student registration did not depend on the type of control represen-tation, (F(2,48) = .25, p = .78).Compliance Problem-Solving - Levene?s test, (F(2,57) = .95, p = .40) showedthat variances between groups were homogeneous.Consistent with homogeneity of regression slopes, analysis of the interactionsbetween each covariate and the given treatment (i.e., control representation) con-cluded that none is significant, as follows:1. The relationship between compliance problem-solving and prior knowledgein BPMN modeling did not depend on the type of control representation,(F(2,48) = .48, p = .62).2. The relationship between compliance problem-solving and knowledge inthe domain of student registration did not depend on the type of controlrepresentation, (F(2,48) = .41, p = .67).147Ease-of-use - Levene?s test, (F(2,57) = .49, p = .62) showed that variancesbetween groups were homogeneous.Consistent with homogeneity of regression slopes, analysis of the interactionsbetween each covariate and the given treatment (i.e., control representation) con-cluded that none is significant, as follows:1. The relationship between ease-of-use and prior knowledge in BPMN model-ing did not depend on the type of control representation, (F(2,48) = .83, p =.44).2. The relationship between ease-of-use and knowledge in the domain of studentregistration did not depend on the type of control representation, (F(2,48) =1.62, p = .21).Case II: Mortgage ApplicationDomain Comprehension - Levene?s test, (F(2,54) = 1.74, p = .19) showedthat variances between groups were homogeneous.Consistent with homogeneity of regression slopes, analysis of the interactionsbetween each covariate and the given treatment (i.e., control representation) con-cluded that none is significant, as follows:1. The relationship between domain-comprehension and prior knowledge inBPMN modeling did not depend on the type of control representation, (F(2,45) =.47, p = .63).2. The relationship between domain-comprehension and knowledge in the do-main of mortgage applications did not depend on the type of control represen-tation, (F(2,45) = 2.06, p = .14).Compliance Comprehension - Levene?s test, (F(2,54) = 1.55, p = .22) showedthat variances between groups were homogeneous.Analysis of the interactions between each covariate and the given treatment(i.e., control representation) concluded that the relationship between compliancecomprehension and prior knowledge in BPMN modeling did depend on the typeof control representation, (F(2,45) = 3.58, p = .04). Therefore, the assumption of148Figure B.1: BPMN Knowledge vs. Compliance Comprehension - Implicit(left), Procedural (center), and Declarative (right) control representa-tions)homogeneity of regression slopes does not seem to hold for prior knowledge inBPMN modeling. This interaction was further visually investigated in scatter plotsfor each level of control representation separately. Plot results are illustrated in fig-ure B.1. It is apparent in the plot for the case of a declarative control representationthat the relationship between the covariate (i.e., BPMN modeling knowledge) andthe dependent variable (i.e., compliance comprehension) might not be consistentwith the two other representation types. However, such an inverse relationshipbetween BPMN modeling knowledge and compliance comprehension seems veryunlikely (i.e., higher knowledge in BPMN modeling leading to worse compliancecomprehension scores). Furthermore, the analysis of homogeneity of regressioncomputes regression slopes without an a-priori requirement to suppress the re-gression?s intercept (i.e., the expected mean value of Y when all X = 0). This isnot consistent with prior knowledge according to which poor BPMN modelingknowledge is most likely expected to yield poor compliance comprehension scores.The relationship between compliance-comprehension and the second covariate (i.e.,knowledge in the domain of mortgage applications) did not depend on the type ofcontrol representation, (F(2,45) = 2.37, p = .11). Therefore, since violation of theassumption of homogeneity of regression slopes is not necessarily visually evidentin the data for the aforementioned reasons, MANCOVA analysis was pursued.Domain Problem-Solving - Levene?s test, (F(2,54) = .09, p = .92) showedthat variances between groups were homogeneous.Consistent with homogeneity of regression slopes, analysis of the interactionsbetween each covariate and the given treatment (i.e., control representation) con-149cluded that none is significant, as follows:1. The relationship between domain problem-solving and prior knowledgein BPMN modeling did not depend on the type of control representation,(F(2,45) = 1.14, p = .33).2. The relationship between domain problem-solving and knowledge in thedomain of mortgage applications did not depend on the type of controlrepresentation, (F(2,45) = .57, p = .57).Compliance Problem-Solving - Levene?s test, (F(2,54) = .09, p = .91) showedthat variances between groups were homogeneous.Consistent with homogeneity of regression slopes, analysis of the interactionsbetween each covariate and the given treatment (i.e., control representation) con-cluded that none is significant, as follows:1. The relationship between compliance problem-solving and prior knowledgein BPMN modeling did not depend on the type of control representation,(F(2,45) = .73, p = .49).2. The relationship between compliance problem-solving and knowledge inthe domain of mortgage applications did not depend on the type of controlrepresentation, (F(2,45) = .50, p = .61).Ease-of-use - Levene?s test, (F(2,54) = 1.12, p = .33) showed that variancesbetween groups were homogeneous.Consistent with homogeneity of regression slopes, analysis of the interactionsbetween each covariate and the given treatment (i.e., control representation) con-cluded that none is significant, as follows:1. The relationship between ease-of-use and prior knowledge in BPMN model-ing did not depend on the type of control representation, (F(2,45) = .55, p =.58).2. The relationship between ease-of-use and knowledge in the domain of mort-gage applications did not depend on the type of control representation,(F(2,45) = .20, p = .82).150Appendix CThird-party Control AuthoritiesThis appendix describes a process control enforcement schema which promotesthe independence of control insertion. The main idea in this schema is to separatethe enforcement procedure of controls from the process enactment mechanismand delegate it to a third party, a control authority that can handle the diversityof regulations more effectively. Decoupling the enforcement procedure from thebusiness process and delegating this responsibility to an independent authority notonly satisfies regulations but also permits each party (i.e. the organization and thecontrol authority) to focus on performing tasks within their domain of expertise.In order to achieve the enforcement of control using a third-party control author-ity, the organization should register (once) its corresponding sequence of controlswith the third-party control authority (and in response is given an ?identifier code?for the registered process). After the registration, the control authority can be re-sponsible to track the execution of control for any enacted process. As illustrated infig. C.1 for the StudentRegistration process example, tracking is attained in threecommunication phases with the third-party authority:1. Synchronization - the organization delivers the ?identifier code? (previouslyreceived) to the control authority and is responded with a ?ticket? messageconfirming the execution of the process and leading to the first control pointto be reported in the process.2. Iterative tracking - at every control point in the process, the organization151Figure C.1: Process control enforcement using a third-party control authorityprovides the previous given ticket and reports a set of state variables valuesthat corresponds to the controlled sub-domain. The control authority thenverifies all state variables and the ticket. If all reported data are found incompliance, the control authority delivers back a new ticket leading to thenext control point to be reported.3. Termination - after all control points were reported and verified by the controlauthority, a process enactment compliance certificate with a unique enactmentidentifier is issued and delivered back to the organization.152Appendix DProcess Model Enhancement -Experimental Materials153D.1 Student Registration CasePage 1 of 1  THE UNIVERSITY OF BRITISH COLUMBIA Sauder School of Business 2053 Main Mall Vancouver, B.C. V6T 1Z2  Business Controls in BPMN Subject ID     Case A : Student Course Registration Instructions The following 2 pages describe the process of student course registration. The description has three components: (1) a narrative that describes the process, (2) a description of policies the process is expected to comply with, and (3) a diagram in BPMN that illustrates the full course registration process. Please refer to all three components when answering the questions. Feel free to alter your attention between the three components (description, policies, and the diagram) and the questions as much as you find necessary. Process Description A faculty member receives registration requests from course applicants (students). An applicant who wants to register in a course fills out a registration form and gives it to the faculty office. The received form is first checked to verify that the applicant is registered as an active student. The Faculty have special access to an internal web application to check the status of a student in the Financial System. If the student?s status is not "active", a rejection letter is immediately sent to the applicant.  If the student status of the applicant is "active", the next step is to check to see whether there is available space in the requested course and if the student has earned sufficient credit points to be enrolled in that course. The Faculty have a special Student Registration System to process the application. If there are insufficient student credit points, the registration system produces an immediate rejection, and a letter is sent to the applicant. If the course is full, the student?s details are added to a waiting list, and a corresponding notification is sent to the student. The handling of the wait- list is performed through a different process. When there is availability and the student has sufficient credit points for enrolment in the requested course, the student is immediately registered (the student?s details are added to the class list), and a registration approval receipt is produced and mailed to the student. This act terminates the registration process. General Policies 1. Avoid giving one person control over all stages of the process (Separation of Duties). 2. Information Technology must be secure (allowing people who are authorized to see data to see it, but stopping people who are not authorized) (IT security). 3. Support documentation (e.g. student correspondence) should include evidence of approval (Approval and Authorization).    154D.2StudentRegistration-ImplicitRepresentation155D.3StudentRegistration-ProceduralRepresentation156D.4StudentRegistration-DeclarativeRepresentation157D.5 Mortgage Application CasePage 1 of 1  THE UNIVERSITY OF BRITISH COLUMBIA Sauder School of Business 2053 Main Mall Vancouver, B.C. V6T 1Z2 Business Controls in BPMN Subject ID     Case B : Mortgage Application Instructions The following 2 pages describe the process of  a mortgage application. The description has three components: (1) a narrative that describes the process, (2) a description of policies the process is expected to comply with, and (3) a diagram in BPMN that illustrates the full course registration process. Please refer to all three components when answering the questions. Feel free to alter your attention between the three components (description, policies, and the diagram) and the questions as much as you find necessary. Process Description This case is about the fictitious Mor tgage Co. The company takes applications from potential customers, makes an assessment about whether or not to approve their application, and then either rejects the application or offers the applicant a mortgage. For simplicity, the details of the assessment process are not described here (the assessment is modeled as a collapsed sub-process). The process begins when a potential customer contacts Mortgage Co to ask for a mortgage application form. In response to that customer's request, Mortgage Co sends t he customer an application package including the form to complete. At the time the application package is sent, Mortgage Co also prepares to send the customer a reminder if Mortgage Co does not receive the application form back in seven days. Once the fill ed form is received, Mortgage Co proceeds to assess the application.  Of course, there are also cases in which customers inform Mortgage Co that they do not wish to proceed with the application. In such cases, Mortgage Co uses a digital archive (a database ) to record the details of that customer as a lost customer before terminating the process. Mortgage Co promises to respond with  either an offer or rejection within 14 days of the date of receipt of an application form. In support of this promise, the handling representative alerts the manager   10 days after receipt of the application IF the process has not been completed, and then every day thereafter. The manager can then also expedite the assessment. Also, if the decision is to reject the application, M ortgage Co uses a special database to archive all the details of th at rejected application. The assessment of each application leads to the decision to reject or accept the application and uses a special Mortgage IT System that assists the customer service  representative in determining whether an offer should be made or not. Based on that decision, the customer is mailed either a rejection letter (also archived) or an offer letter that details the conditions of the approved mortgage. General Policies 1. Establish suitable procedures for the authorization of transactions (Approval and Authorization). 2. Use access control software that allows only authorized personnel to access sensitive files (Safeguarding of Assets). 3. Use encryption software and prevent unau thorized disclosure of data (IT security). 4 . Include duplicate checking of calculations (Verification).  5 . Establish back -up procedures (Disaster Recovery). 158D.6MortgageApplication-ImplicitRepresentation159D.7MortgageApplication-ProceduralRepresentation160D.8MortgageApplication-DeclarativeRepresentation161D.9 Questionnaire BookletPage 1 of 13  THE UNIVERSITY OF BRITISH COLUMBIA Sauder School of Business 2053 Main Mall Vancouver, B.C. V6T 1Z2  Business Controls in BPMN Subject ID      [code for internal use:  SM ] Pre-test Questionnaire ? Have you taken or are you currently taking Comm 335 / BUSI 335?   ? yes ? no ? Did you participate in the above course lecture  on BPMN and Business Controls?       ? yes ? no Please continue only if you have answered yes to both of the above questions. Please answer the following questions: [Modeling Knowledge  ?next Q1-Q3] 1. To what extent do you have knowledge of BPMN concepts (such as activity, event, and gateway)? 1 Not at all 2 3 4 Somewhat 5 6 7 To a great extent 2. To what extent do you have experience with interpreting BPMN diagrams?  1 Not at all 2 3 4 Somewhat 5 6 7 To a great extent 3. To what extent do you have experience with creating BPMN diagrams? 1 Not at all 2 3 4 Somewhat 5 6 7 To a great extent [Knowledge in the domain of mortgage applications  ?next Q4  ?Q5] 4. In the last two years, to what extent have you had experience applying for a mortgage?  1 Not at all 2 3 4 Somewhat 5 6 7 To a great extent 5. To what extent do you have knowledge of mortgage application procedures?  1 Not at all 2 3 4 Somewhat 5 6 7 To a great extent [Knowledge in the domain of student registration  ?next Q6  ?Q7] 162Page 2 of 13  6. In the last two years, to what extent have you had experience registering for courses?  1 Not at all 2 3 4 Somewhat 5 6 7 To a great extent 7. To what extent do you have knowledge of student registration procedures in general - in academic institutions?  1 Not at all 2 3 4 Somewhat 5 6 7 To a great extent Instructions for Case A:  Please refer to the student registration process description (Case A). Using that description, answer the following 40 questions. Provide as many precise answers as possible. Please also fill out in the corresponding spaces the start time before you answer the questions, intermediate time after answering the first 20 questions, and the end time once have finished. These times will NOT be used to determine performance prizes.  Start time:__________________ The Questions for Case A:  [Order of questions was scrambled]  [Domain Comprehension Questions  ?next Q1  ?Q10]  1. [1] Does the process begin when a student sends a "registration form" to the faculty?  ? Yes ? No  2. [2] The "Student Registration System" is used as part of its purposes to check a student's status.  ? Yes ? No  3. [3] A student's credit points are verified by using the "Financial System".  ? Yes ? No  4. [4] The "Financial System" is accessed twice during execution of the process.  ? Yes ? No  5. [5] In a scenario where a student's status is "inactive", the "Student Registration System" is accessed once.  ? Yes ? No  6. [6] In a scenario where a student's status is "active", and there are sufficient credentials and a vacancy in the requested course, the "Course Registration Database" is accessed once.  ? Yes ? No  7. [7] In a scenario where a student's status is "active", and there are sufficient credentials and vacancy in a requested course, the "Student Registration System" is accessed twice.  ? Yes ? No  163Page 3 of 13  8. [8] In a scenario where a student's status is "active", and there are insufficient credentials, the "Waiting List Database" is accessed twice.  ? Yes ? No  9. [9] If there is a course vacancy, can the "deny request" activity be executed?  ? Yes ? No  10. [10] In a scenario where a student's status is found inactive, there are two activities that use the "Registration Form" as input.  ? Yes ? No   [Compliance Comprehension Questions  ?next Q11  ?Q20]  11. [11] Is there a control that ensures that not just one person is given control over all the process stages?  ? Yes ? No  12. [12] Is it possible that the whole process can be executed by the same person?  ? Yes ? No  13. [13] Is there more than a single control to ensure that one person is not given control over all process stages?  ? Yes ? No  14. [14] Is there a control to ensure that there will only be authorized access to the "Waiting List Database"?  ? Yes ? No   15. [15] Is there a control to ensure that only authorized access to the "Course Registration Database" is allowed?  ? Yes ? No  16. [16] Is it possible for a non-authorized person to access the "Waiting List Database"?  ? Yes ? No  17. [17] Is it possible for a non-authorized person to access the "Financial System"?  ? Yes ? No  18. [18] Is it possible for a non-authorized person to access the "Student Registration System"?  ? Yes ? No  19. [19] Is there a control to ensure there is clear evidence of approval (e.g., a signature/a stamp) on the "Rejection Notice"?  ? Yes ? No  20. [20] Is there a control to ensure there is clears evidence of approval (e.g., a signature/a stamp) on the "Registration Approval Notice"?  ? Yes ? No   Intermediate time:__________________ [Domain Problem-Solving Questions  ?next Q1  ?Q10]  164Page 4 of 13  1. [1] What is the outcome for the process if an applicant is an active student, but does not have sufficient credit points?                              2. [2] How many forms must be submitted by a student who wants to register for a course?                             3. [3] Overall, which computerized systems assist in the registration process if the applicant is eligible for registration?                             4. [4] How is the waiting list handled when there is a registration cancellation?                             5. [5] Is it possible for faculty to handle the student registration process from an area off campus (by using a web browser)? Please justify/explain your answer.                             6. [6] Overall, how many letters are sent to an applicant who is put on a waiting list?                             7. [7] Overall, how many letters are sent to an applicant who is enrolled in a course?                             8. [8] Describe the main process tasks in a registration scenario (a series of task activations) that leads to  a student receiving a ?ait list notification letter?                                            9. [9] At which point during the process should the applicant provide his or her registration preferences?                             165Page 5 of 13  10. [10] What happens during the registration process if a student is already enrolled in the requested course (the one that the student is seeking registration for)?                             [Compliance Problem-Solving Questions  ?next Q11  ?Q20]  11. [11] Which activities in the process reflect the segregation of duties?                              12. [12] Which activities in the registration process reflect IT security?                              13. [13] Which activities in the registration process reflect approval and authorization?                              14. [14] Do you think the registration process fully adheres to the segregation of duties policy? Why or why not?                                           15. [15] Does the registration process fully adhere to the IT security policy? Why or why not?                                            16. [16] Does the registration process fully adhere to the approval and authorization policy? Why or why not?                                            17. [17] How should the registration process be changed if segregation of duties is no longer a concern? (i.e., which activities can be removed)                             166Page 6 of 13  18. [18] How should the registration process be changed if IT Security is no longer a concern? (i.e., which activities can be removed)                             19. [19] How should the registration process be changed if approval and authorization are no longer a concern? (i.e., which activities can be removed)                             20. [20] Which activities in the registration process reflect the duty to retain records - maintaining documentation to substantiate transactions?                              End time:__________________ Post-test questions for Case A: [Awareness check  ?next Q1  ?Q3] The following 3 questions refer to the way information was presented to you in case A.  Please indicate your agreement or disagreement with the statement in each question.   1. The diagram I just used includes controls described by a "declarative" phrase. A "declarative" phrase describes the end goal to be achieved (but not how to achieve it). For example: "you should complete course with a good mark."  ? Yes ? No  2. The diagram I just used includes controls described by a "procedural" phrase. A "procedural" phrase describes how to do something (but not the end goal). For example: "do all assignments carefully and prepare well for the exam."  ? Yes ? No       3. The diagram I just used included special control symbols.  ? Yes ? No  The last 6 questions refer to your experience in using the BPMN diagram in case A.  Please indicate your degree of agreement with the following statements: [Perceived ease-of-use: next Q4  ?Q9 (adopted from (Moore, G.C. 1991) and adjusted for BPMN grammars)] 167Page 7 of 13  4. I believe the BPMN diagram I just used is too cumbersome to use.   1 Strongly disagree 2 3 4 Neutral 5 6 7 Strongly agree  5. Using the BPMN diagram just now required a lot of effort on my part.   1 Strongly disagree 2 3 4 Neutral 5 6 7 Strongly agree  6. Using the BPMN diagram just now was frustrating to me.   1 Strongly disagree 2 3 4 Neutral 5 6 7 Strongly agree  7. Using the BPMN diagram just now was clear and understandable.   1 Strongly disagree 2 3 4 Neutral 5 6 7 Strongly agree  8. Overall, I believe that the BPMN diagram was easy to use.   1 Strongly disagree 2 3 4 Neutral 5 6 7 Strongly agree  9. Using the BPMN diagram to answer the questions was easy for me.   1 Strongly disagree 2 3 4 Neutral 5 6 7 Strongly agree  Instructions for case B: Please refer to the mortgage application process description (Case B). Using the description of that process, please answer the following 40 questions. Provide as many answers as possible. Also, please fill out in the corresponding spaces your start time before answering, your intermediate time after answering the first 20 questions, and the end time once you have finished answering all the questions. These times will NOT be used to determine performance prizes.  168Page 8 of 13  Start time:__________________ Questions:  [Domain Comprehension Questions  ?next Q1  ?Q10]  1. [1] The mortgage application process begins when a customer sends an application form to the customer service representative.  ? Yes ? No   2. [2] The "Mortgage System" is used by the service representative to support the assessment of each mortgage application. ? Yes ? No   3. [3] The "Mortgage System" is used as part of its purpose to archive the details regarding lost customers. ? Yes ? No   4. [4] The "Rejected Applications" database is used to archive the details regarding rejected applications. ? Yes ? No   5. [5] The "Approved Applications" database is used to archive the details for approved mortgages. ? Yes ? No   6. [6] During the execution of the "assess and respond" sub-process, the "Mortgage System" is never accessed. ? Yes ? No   7. [7] After sending out a blank application form to the customer, there is no limit to the number of reminders that can be later sent out if no response is received. ? Yes ? No   8. [8] After archiving the details regarding a lost customer, a mortgage is offered. ? Yes ? No   9. [9] After archiving the details of a rejected application, no other activities need to be executed. ? Yes ? No   10. [10] In a scenario where an assessment was made after 12 days, overall 3 alerts will  be sent to the manager to expedite that process.  ? Yes ? No    [Compliance Comprehension Questions  ?next Q11  ?Q20] 11. [11] Is there a control to ensure that every mortgage offer is authorized (by a manager)?  ? Yes ? No   12. [12] Is there a control to ensure that every mortgage rejection is authorized (by a manager)?  ? Yes ? No   13. [13] Is there a control to ensure there is only authorized access to the "Lost Customers" database?  ? Yes ? No   14. [14] Is there a control to ensure there is only authorized access to the "Mortgage System"?  ? Yes ? No   169Page 9 of 13  15. [15] Is there a control to ensure there is only authorized access to the "Rejected Applications" database?  ? Yes ? No   16. [16] Is it possible for a non- authorized person to access the "Lost Customers" database?  ? Yes ? No    17. [17] Is it possible for a non- authorized person to access the "Mortgage System"?  ? Yes ? No    18. [18] Is there a control to prevent any unauthorized disclosure of mortgage application data?  ? Yes ? No   19. [19] Is there a control to ensure the correctness of calculations regarding the mortgage offer? ? Yes ? No   20. [20] In the case of a disaster, would it be possible to recover the data about lost customers?  ? Yes ? No     Intermediate time:__________________ [Domain Problem-Solving Questions  ?next Q1  ?Q10]  1. [1] Explain what happens if Mortgage Co does not receive an application form back.                             2. [2] How long could it take between the time a customer shows an initial interest in a mortgage and the time the details of that mortgage are archived?                             3. [3] In a given scenario where the "make assessment" activity was enacted, is it possible for the "archive details" activity (of a lost customer) also to be enacted in that same scenario? Please explain why or why not.                                           4. [4] In a given scenario where the "expedite assessment" activity was enacted, is it possible that the "send reminder" activity can also be enacted in that same scenario? Please explain why or why not.                                           5. [5] List all possible process outcomes for the customer (with corresponding deliverables to the customer). 170Page 10 of 13                                            6. [6] Is a response with an offer or rejection guaranteed within 14 days from the date of receipt of an application form?                             7. [7] Which computerized systems are used in a scenario that completes a mortgage offer being sent to the customer?                             8. [8] Which computerized systems are used in a scenario that completes a rejection letter being sent to the customer?                             9. [9] What happens if a mortgage offer cannot by verified by the manager?                             10. [10] Which computerized system is used to archive offered mortgages?                             [Compliance Problem-Solving Questions  ?next Q11  ?Q20]  11. [11] Which activities in the mortgage application process reflect approval and authorization?                             12. [12] Considering computerized resources to be part of the company's assets, which activities in the mortgage application process reflect the safeguarding of those assets?                             13. [13] Considering computerized resources to be part of the company's assets, which assets are NOT protected as entailed in the Safeguarding of Assets policy?              171Page 11 of 13                 14. [14] Which activities in the mortgage application process reflect the prevention of unauthorized disclosure of data?                              15. [15] Which activities in the mortgage application process reflect the need for a double- check of calculations?                              16. [16] Which activities in the mortgage application process reflect the need to establish back-up procedures?                             17. [17] Does the mortgage application process fully adhere to the Approval and Authorization policy?  How does it or how does it not?                                           18. [18] Does the mortgage application process fully adhere to the Safeguarding of Assets? How does it or how does it not?                                           19. [19] How should the process be changed if Safeguarding of Assets is no longer a concern? (i.e., which activities can be removed)                             20. [20] Does the process part that is executed by the customer service representative adhere to the segregation of duties policy (i.e., avoid giving one person control over all stages of a process)? Explain how it does or how it does not.                                           End time:__________________ 172Page 12 of 13  Post-test questions for Case B: The following 3 questions refer to the way information was presented to you in case B.  Please indicate your agreement or disagreement with the statement in each question.  [Awareness check  ?next Q1  ?Q3]  1. The diagram I just used includes controls described by a "declarative" phrase. A "declarative" phrase describes the end goal to be achieved (but not how to achieve it). For example: "you should complete course with a good mark."  ? Yes ? No  2. The diagram I just used includes controls described by a "procedural" phrase. A "procedural" phrase describes how to do something (but not the end goal). For example: "do all assignments carefully and prepare well for the exam."  ? Yes ? No       3. The diagram I just used included special control symbols.  ? Yes ? No  The last 6 questions refer to your experience in using the BPMN diagram in case B.  Please indicate your degree of agreement with the following statements: [Perceived ease-of-use: next Q4  ?Q9 (adopted from (Moore, G.C. 1991) and adjusted for BPMN grammars)] 4. I believe the BPMN diagram I just used is too cumbersome to use.   1 Strongly disagree 2 3 4 Neutral 5 6 7 Strongly agree  5. Using the BPMN diagram just now required a lot of effort on my part.   1 Strongly disagree 2 3 4 Neutral 5 6 7 Strongly agree  6. Using the BPMN diagram just now was frustrating to me.   1 Strongly disagree 2 3 4 Neutral 5 6 7 Strongly agree  173Page 13 of 13  7. Using the BPMN diagram just now was clear and understandable.   1 Strongly disagree 2 3 4 Neutral 5 6 7 Strongly agree  8. Overall, I believe that the BPMN diagram was easy to use.   1 Strongly disagree 2 3 4 Neutral 5 6 7 Strongly agree  9. Using the BPMN diagram to answer the questions was easy for me.   1 Strongly disagree 2 3 4 Neutral 5 6 7 Strongly agree              Thank you for participating in this study! Please hand over this booklet to the researcher in attendance.              174D.10 BPM and Business Control - Training Slide DeckThe following slide deck was used to give the required basic background knowledgeon BPMN and business-control. It was used in the 1-hour training session priorto the the experimental procedure that was conducted to test the effect of controlrepresentation in BPMN as described in chapters 3 and 4. The first part of thetraining was an introduction to process modeling, with a concrete focus on theBPMN notation. It was ensured that all symbols later utilized in the experimentaltask were also reviewed in the training. The second part was an introduction tocontrol in business processes, being focused on the notion of controls as businessactivities. The three alternative representation styles were introduced in the contextof a conventional ?goods ordering from supplier? process.175BUSINESS PROCESS MODELING ANDBUSINESS CONTROLSLior Limonad ?limonad@gmail.comSauder School of Business,UNIVERSITY OF BRITISH COLUMBIABP modeling and BP controls, June, 20101Credits: Yair Wand, Carson WooBP and ControlsAgenda ? Business Process Modeling (BPM)? BPMN Notation? Business Controls (BC)? BPM and BC integrationBP modeling and BP controls, June, 20102BUSINESS PROCESS MODELINGBP modeling and BP controls, June, 2010 3 Process ExampleNotes? An activity can cause events? Events may trigger activities? An event is considered instantaneous? An activity has a durationEventMy son is bornWater has brokenMy wife and I drive to:oPen?s+ospitDO My wife gives birthWe arrive at the WHEventEventActivity ActivityCommon Constructs in BPMLs? Processes are usually modeled as sequences of events and activities?DFtiYit\ ?eOePentDr\proFesses?An eve nt :? A notable occurrence at a specific point in time in which changes to the state of one or more objects occur or are triggeredAn ac tiv ity :? A mechanism by which some objects change their stateWhat is Business Process Modeling?BP - Modeli ng : provides businesses with the capability of defining and understanding their internal and external business processes through a Business Process Diagram. ? Enables to understand, communicate and document organizational procedures in a standard manner. ? Helps responding quickly to new situations by illuminating potential sources for delays and error.? A tool for process improvements -$FtuDO?$6,6?Ys([peFted?72%(?? Some methods (e.g. BPMN) also enable the generation of machine executable processes.176A Process View of the Business?Amounts to turning the organization on its head, or at least on its side." (Davenport 1993 p. 5)? The business attains its goals via business processes.? May span across the organizational structure, or even integrate several organizations that work together.A business process : A set of activities whose execution by the responsible agents (people, organizational units, or some devices) leads to a desired outcome (product or service) for a particular customer or market.? The activities in a business process are connected by:? Rules of order (sequencing)? Flows of physical entities and information? Note: An organizational fun ction is not a business process? Example: The Accounts Payables department vs. the Payment Process? Examples?HR IT Accounting Manufacturi ng Logistics Marke ting Enginee ringBusiness Process Diagrams (BPD)? BPDs are the artifacts in Business Process Modeling? A BPD is comprised of:? A set of modeling constructs. Each has a specified meaning in the EusinessproFessdoPDintDsNseYentsIOoZsdeFisions?? Each modeling construct is represented with a corresponding graphical symbols reFtDnJOesDrroZsspOitsDndMoins?? A set of rules for the construction of valid diagrams: e.g. a flow symbol precedes or follows  a task symbol? The combination of modeling constructs, symbols, meaning assignments, and rules is termed the Business Process Modeling Language (BPML)? 7KereDrePDn\FoPpetinJstDndDrdsto%30/s?<$:/?? BPMN, EPC, Petri-nets, WfMC, Activity Diagrams (UML), IDEF0,  ')'?Example : BPMN Spec.Rules (some exa mple s ):1. The beginning of every process is indicated by a start-event symbol.2. The end of every process is indicated by an end-event symbol.3. A sequence flow symbol can link between two consecutive activities or between an event followed by an activity or vice versa. Why not use natur a l langua ge (pla in te x t) ?Constructs Meaning SymbolActivity An activity is a generic term for work that company performs. Sequence Flow A Sequence Flow is used to show the order that activities will be performed in a Process.Event (start, end, intermediate) $neYentissoPetKinJtKDt?KDppens?during the course of a business process. These events affect the flow of the process and usually have a cause (trigger) or an impact (result). What is the benefit in using process models (i.e. diagrams)?? With respect to any encountered phenomenon, we create mental-models in our mind to understand, solve problems, come up with new ideas (creativity).? [Mayer, 1989, Ed. Research]? A review of a series of 20 studies in which a conceptual model was presented prior to a lesson (i.e. a scientific lecture).? In a set of 31 separate tests, the experiment has incontestably shown that for students who had been presented the conceptual models, there has been an improved recall of conceptual information, a decrease of verbatim retention, and an increase in creative solutions.BP Analysis: Activity Centric? W h a t happens?? Input - transformation? Output ?product / service ??YDOue?to?FustoPers?? Pre/Post - condit ions ??JuDrds?Dnd?FontrDFts?6/$s? Who /What is involved? Actors (usually people) ?participants vs. customers? Resources - teFKnoOoJ\PDteriDOsinIorPDtion?? How does it happen?? What actions are taken? What rules determine how things are doneBusiness P rocess Modeling Notation? BPMI (Business Process Management Institute) released Version 1 in May 2004? June, 2005 ?Merge with OMG? Aims? To provide a notation that is readily understandable by all business users? To provide a notation that can be converted into an ?e[eFutDEOe?proFessPodeO? BPMN is organized into two tiers:? A core set of elements (i.e. modeling constructs)? Flow Objects, Connecting Objects, Swimlanes, Artifacts? A specialization to the basic set of elements for specific purposes (see http://www.bpmn.org)177BPMN ?Flow Objects Event - soPetKinJtKDt?KDppens?durinJtKeFourseoIDEusinessprocess . These events affect the flow of the process and usually have a cause (trigger) or an impact (result). There are three types of events: Start, Intermediate, and End. BPMN - Flow Objects Activity - a generic term for work that company performs. An activity can be atomic or non-atomic (compound). The types of activities that are a part of a Process Model are: Process, Sub-Process, and Task. BPMN - Flow Objects Ga tew ay ?used to control the divergence (branching) and convergence (joining) of Sequence Flow.BPMN ?Connecting Objects ?Sequence Flow ?shows activities order?Message Flow - show the flow of messages between two participants  (represented as separate pools)?Associati on ?associates information with flow objects.BPMN - Swimlanes? Pool - represents a Participant in a Process (usually in the context of B2B situations ).?Lanes - a sub-partition within a Pool (organize and categorize activities ). BPMN - Artifacts? Data Object ?artifacts - what activities require to be performed and/or what they produce.?Text Annotati on - additional information.? Group ?a way to visually categorize a set of objects.178BPMN ?Putting them together BPMN ?Flows with Data objects and RolesBPMN ?Pools and Messages Universal Principles in BP Modeling? What matters are the con cep ts (i.e. con structs + mean ing)? Symbols stan d for conc ep ts, they are NOT concep ts? The exact symbols do not matter as long as? The diagrams is info rma tive? A clear legend is provided? Differen tiate s between different concepts? The use of symbols con sis tent? Example for a common mistake:? Same arrow type for? Control flows? Information flows? Links to organizational unitsBUSINESS CONTROLSA special type of activityBP modeling and BP controls, June, 2010 23 Business ActivitiesA list of activities:? Order of materials? Assemble a component according to plan? (nsureFoPponent?squDOit\testinJYsrequirePents? Pay salaries to employees? Validate supplier account numbers before payment? Signature approval on authorized payments? Do a credit check for potential customers? Invoice a customer for a provided serviceDisc ussi on : Are they all the same? BP modeling and BP controls, June, 201024179Example : Order goods from a supplier25? $ren?tZemissing something?? Hint: Consider a dishonest supplier.? Solution:? 3-way match policy.? How to show the solution?Controls in organizationsBP modeling and BP controls, June, 201026? Reasons for business actions (GRC):? G overnance ?attainment of organizational goals? Internal adherence ?policies, business rules, organizational norms? Risk mitigation ?no harm or damage is incurred (or at least chance is reduced)? Compliance ?all business imposed constraints are met? External adherence ?laws, regulations, standards? Caveat ? human actions may be imperfect!? 6oZeDddPDnDJePent?sPonitorinJDndDuditinJreODtedDFtiYities? We can split between:? ?5eJuODr?DFtiYities?intend d to add value to the overall process objective (i.e. GRC).e.g. turn right-turn signal on before making a right turn.? Other activities tKDtDresiPpO\intendedtoensuretKDtDOOotKer?reJuODr?DFtiYitiesJoDsdesired.eJOistentotKesoundoItKeFDr?sturn-signal b fore making a turn.? We term the second type ??&ontroO?Control - An activity triggered by other activities (in a process) that is intended to either prevent, detect, or correct undesired states or undesired events during process execution in adherence to certain policies.Controls in organizations ?cont.BP modeling and BP controls, June, 201027? Controls are also strongly intertwined with IT? IT implements controls ?e.g. access authorization? IT entails it own controls ?e.g. data backup? Conclusio ns : ? Control activities are part of business operations ? Controls should be explicitly represented in descriptions of business process (e.g. Business Process Diagrams)? Prob lem: There is yet no existing modeling method that is capable of explicitly representing control activities in process models ? Next slides show 3 alternative representations of business controls in BP modeling using BPMN notationControl Representation in BPMN? Remember: ?FontroO?isDspeFiDOt\peoIEusinessproFess?DFtiYit\?? Three grammatical representations to be considered:? Implicit ?FontroODsD?reJuODr?DFtiYit\? Explicit procedural ?control as an annotated activity.? Explicit declarative ?structured annotation text that specifies: (a) the context (i.e. before or after), (b) the corresponding policy, and (c) the control activity.BP modeling and BP controls, June, 201028Example : Order goods from a supplier? Use the activity symbol29Implicit Control Representation? Representation: use the same symbol that is used for activities.? Example: aircraft boarding? Security Policy 1: all suspects should be detained? Representation qualities?? E.g. easy to understand the context of the control activityBP modeling and BP controls, June, 201030180Example : Order goods from a supplier? Use the activity symbol+ annotationwith reference to the corresponding policy31Explicit Control Representation : Procedural? Representation: use the same symbol that is used Ior?reJuODr?DFtiYitiesDnDnnotDtiontKDtstDtestKecorresponding policy being adhered to.? Example: aircraft boarding? Security Policy 1: all suspects should be detained? Representation qualities?? E.g. easy to differentiate between controls and other activitiesBP modeling and BP controls, June, 201032Example : Order goods from a supplier? Use a structured annotation text block:? Policy? Context? Activity declaration33Explicit Control Representation : Declarative? Represent at ion: use structured annotation text that specifies: (a) the context (i.e. before or after), (b) the corresponding poOiF\DndFtKeFontroODFtiYit\?soEMeFtiYedeFODrDtiYestatement).? Example: aircraft boarding? Security Policy 1: all suspects should be detained? Representation qualities?? E.g. the context is better visualizedBP modeling and BP controls, June, 201034Summary? A BP diagram is a common technique for describing and understanding business operations.? Control considerations are part of business operations and of IT requirements.? Controls are intended to ensure that business operations execute as desired. This includes:? Attainment of business objectives?Compliance with external regulations?Mitigation of riskBP modeling and BP controls, June, 201035Which representation is better?? Three alternative control representations were illustrated:? Implicit? Explicit procedural?Explicit declarative? Disc uss ion: Which one do you think is better? Why??6tD\onePoreKourtoKeOpPeIindout?BP modeling and BP controls, June, 201036181BP modeling and BP controls, June, 201037182Appendix EControl Typology - ExperimentalMaterials183E.1 Business Control Model Overview and SpecificationBrochureBusiness Controls overview  Definition: Control (n.) - a mechanism intended to assure that a given domain behaves as desired.  Example: Fire door example - any mechanism that checks that the door is closed (i.e. the desired behaviour) unless in use.  In the above definition the given domain will be called the target domain (hence on the "target?)?  A mechanism means device, procedure, or a combination of devices and procedures.  Desired behaviour means that the behaviour complies with a given set of rules.  Rules reflect organizational goals (related to Governance, Risk reduction, or Compliance  ?briefly GRC).  Example: Fire door example - the rule is that the door should be closed at all time (unless in use). This rule is intended to meet the goal of preventing the spread of fire (risk mitigation).  The target domain behaviour is accomplished because a certain mechanism exists which brings about the actual behaviour of the domain:  Definition: Implementation Component (n.)  ?the mechanism intended to make the target domain behave as expected.  Example: Fire door example - a returning spring attached to the door.  Clarification about the difference between an implementation mechanism and control: An implementation component brings about the target domain behavior. A control is intended to assure this behavior is as desired.  The reason for introducing controls is because often the implementation does not bring about the desired behaviour.  Example: The fire door - the door may be jammed thus preventing the spring from closing it. The control would be an alarm that will sound if the door is open for more than a certain time.  Note: sometimes it is preferable to monitor the implementation component rather than the target.  Example: The fire door - the alarm sensor may be installed in the door frame or on the returning spring.   So far we have defined control in an abstract sense. The following is a specification of a control. 184For each control we need to specify the following: 1. Name of control. 2. The target. 3. The rule controlled for. 4. The goal the rule is intended to meet. 5. Description of the implementation (component). 6. Description of how the control works.   Specification of Controls   1.  Name of control - a brief general description of the control as viewed by stakeholders.  2. Target - the part(s) of a domain (e.g. an organization) or set of activities within the domain whose behaviour should comply with the rule. 3. Rule - a rule formalizing the required behaviour of the target. 4. Goal -  goal or objective the rule is intended to meet. 5.  Implementation - the mechanism put in place to bring about the required behaviour. 6. Control - the actual mechanism put in place to assure the behaviour conforms to the rule.  Eote? the ?ord ?mechanism? stands for devices, ?rocedures or combination of those. An organizational unit or a com?uter systems ?ill ?e considered a ?device? ?hile a descri?tion of a ?usiness ?rocess or how processing is done in software  ?a procedure.   Examples for control specifications   Name of control: Fire door alarm Specification Actual Comments Target Fire door  Rule Should be closed unless in use  Goal Prevent spread of fire  Implementation Returning spring  Control Sensor for open door to sound alarm if door open more than a certain time Installed on either the door or the returning spring 185 Name of control: One-over-One signature approval Specification Actual Comments Target UBC's payment system  Rule No self-payment is made without approval/appropriate authorization  Goal Prevent inappropriate payments  Implementation One-over-one signature approval (i.e., one administrative level higher) procedure for payments to individual (i.e., when requestor the same as payee).  Control Accounting clerk checks that a second signature exists by a person (at least) one level higher         186E.2BusinessControlDataSets-TrainingandValidationList of Controls ("Training Set")  Name of Control  A brief general description of the control as viewed by stakeholders  Specification  Target   The part(s) or set of activities whose behaviour should comply with the rule  Rule  A rule formalizing the required behaviour of the target Goal  The goal or objective the rule is intended to meet Implementation   The mechanism put in place to bring about the required organizational behaviour. Control  The actual mechanism put in place to assure the behaviour conforms to the rule. Comments 1 "A review of accounts reconciliation" Accounting system Accuracy of financial records  Fair financial reporting  Bank reconciliation (to a bank statement) verifiable control total, performed by an independent individual  Independent review of reconciliations by an individual who does not process the transactions  2 "Review of daily deposit slips"  Point of sale Requirement that two people be present and observing when cash is counted Protect assets from physical theft (cash)  Signing a deposit slip by the two observers A review of the deposit slip  3 "Travel processing review" Financial system All travel expense reimbursements be processed in a single transaction for one travel Prevent unauthorized travel reimbursements The use of a claim form in which all travel expenses should be claimed together Review of the claim form and attached receipts  4 "Credit check of Financial System Credit will not be extended to Prevent customer "bad debts" Do credit check prior to opening The financial clerk reads the  TableE.1187Name of Control  A brief general description of the control as viewed by stakeholders  Specification  Target   The part(s) or set of activities whose behaviour should comply with the rule  Rule  A rule formalizing the required behaviour of the target Goal  The goal or objective the rule is intended to meet Implementation   The mechanism put in place to bring about the required organizational behaviour. Control  The actual mechanism put in place to assure the behaviour conforms to the rule. Comments new customers" customers who do not have the ability to pay in a timely manner  an account receivable for a customer result of the credit check and evaluates the result before opening an account 5 "Pre-numbered receipts? Point of sale All transactions are properly receipted Prevent loss of incoming revenues for goods provided Having receipt numbers that are accounted for Receipt review to identify gaps in numbers? sequence  6 "Write-off approval" Accounting System Record customers inability to pay their debts Properly value assets (e.g. accounts receivable)   Write-off procedure to reduce accounts receivable to its net realizable value Management approval of accounts receivable write-offs  7 "spending limits by position? All expenditures Expenditure limits that correspond with level of authority Relate expenditures amounts with corresponding level of judgment Publication of authorization tables with amount restrictions for procurement at various levels of Central finance checks approval signatures per the policy (i.e. according to tables)   188Name of Control  A brief general description of the control as viewed by stakeholders  Specification  Target   The part(s) or set of activities whose behaviour should comply with the rule  Rule  A rule formalizing the required behaviour of the target Goal  The goal or objective the rule is intended to meet Implementation   The mechanism put in place to bring about the required organizational behaviour. Control  The actual mechanism put in place to assure the behaviour conforms to the rule. Comments positions 8 "journal entries support" Accounting System An explanation, signature, and supporting documentation for all journal entries Permit non routine adjustments of accounts balances  A form filled out by the authorized person requiring an explanation, a signature, and supporting documentation Review of the form by the data entry clerk  9 "pre-numbered cheques" Financial System All payments should be made with authorized cheques  Prevent unauthorized payments Payments are made with pre-printed, pre-numbered, that are signed by a signature plate Bank reconciliation review of payments to validate all cheque numbers  10 "monthly financial report" Financial System Appropriate action is necessary when operations deviate from plans Alignment between strategy and operation The review of a monthly financial report and investigation of variances from expected results Audit of the review This is a special case in which 'audit' is considered a control 11 "spreadsheet controls" Financial system All data collection applications should employ integrity procedures Maintain accurate financial records The use of a spreadsheet (protected cells, complicated Audit of spreadsheet This is a special case in which 'audit' is considered a 189Name of Control  A brief general description of the control as viewed by stakeholders  Specification  Target   The part(s) or set of activities whose behaviour should comply with the rule  Rule  A rule formalizing the required behaviour of the target Goal  The goal or objective the rule is intended to meet Implementation   The mechanism put in place to bring about the required organizational behaviour. Control  The actual mechanism put in place to assure the behaviour conforms to the rule. Comments formulas) control 12 "conflict of interest reporting" The whole organization Conflict of interests policy  Ethical behaviour of faculty and staff as an appropriate public institution  Annual reporting of potential conflicts Conflict of interest committee review of the report  13 ?strong passwords? Computerized systems (e.g. Payroll system) Access to each computerized system should be based on credentials (job position, authorization) Prevent unauthorized access to all computerized systems and data (fraud, error, breach of data security) System account password module activated on each entry Strong password validation   190List of Identified Controls ("Validation Set")  Name of Control  A brief general description of the control as viewed by stakeholders  Specification  Target   The part(s) or set of activities whose behaviour should comply with the rule  Rule  A rule formalizing the required behaviour of the target Goal  The goal or objective the rule is intended to meet Implementation   The mechanism put in place to bring about the required organizational behaviour. Control  The actual mechanism put in place to assure the behaviour conforms to the rule. Comments 1 "Testing of SIN algorithm" Payroll system Hire only real employees Prevent payments to non existent employees SIN software validation module Test the software according to SIN validity as published by "Service Canada"  2  "One-over-One signature approval" Payment system No self-payment is made without approval/appropriate authorization Prevent inappropriate payments One-over-one signature approval (i.e. one administrative level higher) procedure on payments to individuals (i.e. when requestor equals the payee) Accounting clerk checks that a second signature exists by superior  3 "Cash register grand total daily balancing" Point of sale The cash register daily Z total should match the total daily cash counted All cash receiving should be properly recorded and deposited to the Bank Checking the Z total to the deposit slip Assignment  of the checking procedure to the supervisor in the point of  TableE.2191Name of Control  A brief general description of the control as viewed by stakeholders  Specification  Target   The part(s) or set of activities whose behaviour should comply with the rule  Rule  A rule formalizing the required behaviour of the target Goal  The goal or objective the rule is intended to meet Implementation   The mechanism put in place to bring about the required organizational behaviour. Control  The actual mechanism put in place to assure the behaviour conforms to the rule. Comments sale 4 "Cash register display facing customer" Points of sale Recorded amounts for cash transactions should be reported to the customer  Prevent loss of incoming revenues for goods provided A visual display that presents the amount to be charged to allow the customer to observe the amount recorded  Customer?s complaint to management if the amount displayed does not match with payment 8, 9, 10 are examples for three different rules derived from the same goal 5 "Authorization of voids?  Point of sale Enable voiding of transactions Prevent loss of incoming revenues for goods provided Having cash registers programmed to process voids Supervisor approval for cash register voided transactions  6 "board approval of capital projects" Capital project expenditures All capital projects must be approved by the board Appropriate allocation of resources Board deliberations; Payment driven by board decision Someone in treasury checks minutes prior to any commitment  7 "Voucher package" Payment System No payment will be entered in accounts payable without evidence of matching ordering and receiving Ensure all good/service payments are legitimate (ordered, delivered, and authorized) Having a voucher package processed by a clerk Sending out monthly financial reports detailing payments to  192Name of Control  A brief general description of the control as viewed by stakeholders  Specification  Target   The part(s) or set of activities whose behaviour should comply with the rule  Rule  A rule formalizing the required behaviour of the target Goal  The goal or objective the rule is intended to meet Implementation   The mechanism put in place to bring about the required organizational behaviour. Control  The actual mechanism put in place to assure the behaviour conforms to the rule. Comments    each target department 8 "securing signature plates? Payment system All payments should be made with authorized cheques Prevent unauthorized payments Payments are made with pre-printed, pre-numbered, that are signed by a signature plate  Physical security and restricted access for signature plates Items 17, 18, and 19 are three different controls to the same implementation component 9 "physical security of cheques Financial System All payments should be made with authorized cheques  Prevent unauthorized payments Payments are made with pre-printed, pre-numbered, that are signed by a signature plate Physical security of blank cheques  10 "separation of duties" Accounting system Separation of incompatible functions (of duties) Prevent fraud and error in the accounting system Organizational charts and job description which formalize the separation of incompatible functions HR review of job description and organizational charts  11 "equipment inventory Equipment assets Records of purchase, transfer, and disposal should be maintained Safeguarding of assets A centralized equipment asset tracking system Annual inventory count of  193Name of Control  A brief general description of the control as viewed by stakeholders  Specification  Target   The part(s) or set of activities whose behaviour should comply with the rule  Rule  A rule formalizing the required behaviour of the target Goal  The goal or objective the rule is intended to meet Implementation   The mechanism put in place to bring about the required organizational behaviour. Control  The actual mechanism put in place to assure the behaviour conforms to the rule. Comments system" (computerized) equipment on site with comparison to recorded equipment purchases within the tracking system 12 ?hourly payroll processing? Payroll system Payroll for unionized employees should correspond with collective employment contracts  Efficient labour utilization Use of weekly timesheet to input payroll hours Supervisor review and approval of timesheets     194E.3 Questionnaire - Round One10 April 2012 Page 1 of 2  THE UNIVERSITY OF BRITISH COLUMBIA Sauder School of Business 2053 Main Mall, Vancouver, B.C. V6T 1Z2 Rese a rc h Que sti onnai r e - Itera ti on Num ber 1 A Typol ogy for IT and Busine ss Control s Please use the following table to classify each of the controls listed (i.e., rows) according to each of the dimensions (i.e., columns). For each dimension, please select (use a ??? sym?ol) the level that you think is most suitable in determining its nature. Below each selection please also indicate your selection certainty using a number between 1 and ? (? ? uncertain ? ? ? certain)? In each cell, the number shown in brackets indicates the collective selection of that cell by all study participants in the previous iteration. The first row is an example that shows how each row should be filled out.  * * * All dimensions and levels are explained in a legend below the table ***  Dimensions  1   2   3   4   5   6   Suggest more /remove                     Levels  Controls  T IC  F  NF  S E  HG  SG  P  D  C OL  CL   Example:  User Authentication and Authori zation  _ _  __  ?_  5_  _ _  _ _  ?_  3_  __  __  ?_  4 _  ?_  5_  __  __  ?_  5_  __  _ _  __  __  ?_  2_  __  __  Dimension 6 is not required ? Control 1 __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __     Control 2 __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __     Control 3  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __     Control 4  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __     Control 5  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __     Control 6  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __     Control 7  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __     Control 8  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __     Control 9  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __     Control 10  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __     Control 11  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __     Control 12  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __     Control 13  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __     19510 April 2012 Page 2 of 2  Legend  1. Dimension 1 - Control Focus - "What is monitored by the control mechanism ?"  a. T - Target domain: the control monitors the behaviour of a "target" domain. A target domain is an organizational environment that is expected to comply with certain rules (e.g., the "fire door"). b. IC - Implementation component domain: the control monitors the behaviour of an "implementation component" domain. An implementation component domain is an organizational environment that is responsible for bringing about  the behaviour of a target domain (e.g., the "spring"). 2. Dimension 2 - Control responsibility a. F - Functional: ensuring the implementation component achieves is objective (e.g., the "spring" closes the door when not in use). b. NF - Non-functional: ensuring the inherent operation of the implementation component (e.g., the "spring" is not squeaky). 3. Dimension 3 - Control objective a. S - State control: monitored failures are states (i.e., instantaneous - e.g., identification of insufficient funds). b. E - Event control: monitored failures are event (i.e., have duration, a transition between states - e.g., prevention of wire transfers). 4. Dimension 4 - Control goal type a. HG - Hard goal - the control ensures achievement of necessary objectives (e.g., employment contract). b. SG - Soft Goal - the control ensures improved performance measures (e.g., employment satisfaction). 5. Dimension 5 - Control risk functionality a. P - Preventive control - reducing vulnerabilities or mitigating the hazards. b. C - Corrective control - following detection, removing or suppressing all hazard effects. c. D - Detective control - monitoring and identifying vulnerabilities and hazards. 6. Dimension 6 - Control structure a. OL - Open loop - the behaviour of the control is pre-fixed (e.g., identity validation). b. CL - Closed loop - the behaviour of the control can change based on feedback from the monitored domain (e.g., a thermostat that adjusts itself based on external temperature). 196E.4 Control Typology - Training Slide DeckThe following slide deck was used in the first meeting with the audit team at UBC.This first session was devoted to teaching the audit team both about the controlmodel and the developed typology to ensure they can use it themselves, and alsoto lay out the intended Delphi procedure to be pursued. The classification matrixthat was used to facilitate data collection was carefully reviewed to ensure all teammembers understand how to use it.197NOT EVERY THING IS UNDER CONTROL  INCORPORATION OF BUSINESS CONTROLS INTO INFORMATION SYSTEMS ANALYSIS AND DESIGN Lior Limonad - lior.limonad@sauder.ubc.ca Advisor: Prof. Yair Wand  Sauder School of Business, UNIVERSITY OF BRITISH COLUMBIA A control model and typology evaluation ? Feb, 2010 1 Agenda A control model and typology evaluation ? Feb, 2010 2? Controls in business ? 7KenotionoI?FontroO? ? The Enterprise Model of Control ? Control typology ? Typology Evaluation (Delphi) ?&ontroO?inEusiness A control model and typology evaluation ? Feb, 2010 3? [Accounting & Auditing] a process that is meant to ensure effectiveness and efficiency of operations, reliability of financial reporting, and compliance with laws and regulations.  ? [Control Sys. Theory] an arrangement of physical components connected or related in such a manner as to command, direct, or regulate itself or another  ? [Risk Mgmt.] risk reducing measures implemented by the organization to minimize or eliminate the likelihood (or probability) of a threat's exercising a system vulnerability  ? [Industrial Mgmt.] verifying whether everything occurs in conformity with the plan adopted, the instructions issued, and principles established. It's object is to point out weaknesses and errors in order to rectify them and prevent recurrence Controls in organizations A control model and typology evaluation ? Feb, 2010 4? Informally: controls are the [things\activities] in the business that ensure that everything goes as expected and as required by some rules  ? Strongly intertwined with IT ? IT implements controls ? e.g. access authorization ? IT entails controls ? e.g. data backup ? Control considerations should be part of IT requirements ? Problem: not part of any Analysis & Design technique ? How can we ensure that: ? Are sufficient control mechanisms in place? ? Do existing mechanisms operate as required? Driving forces A control model and typology evaluation ? Feb, 2010 5? Why do we need controls? ? Governance ? attainment of organizational objectives ? Internal ? policies, business rules, organizational norms ? Risk mitigation ? no harm or damage is incurred (or at least chance is reduced) ? Compliance ? all business imposed constraints are met ? External ? laws, regulations, standards ? GRC adherence is ensured through auditing inspections ? Traceability: controls ? policies ? regulations ? What is missing? ? A well defined notion of controls - common terminology for business operations and controls, need for a systematic solution ? $?PDS?RIFRQWUROFRQFHUQV to support control management (implementation, audit, classification...)  ? Business process integration The Enterprise Model of Control A control model and typology evaluation ? Feb, 2010 6? An example ? $?fire door? ? 5uOe?7KedoorsKouOdEeNeptFOosed? (Occupational Safety and Health Adm.) ? Install a self-closing spring to comply  ? Control (n.) - a mechanism* intended to assure that a given domain behaves as desired. ? * A device, a procedure, or a combination of devices and procedures. ? How does it relate to the door? To the spring? ? What is the Control? 198The Enterprise Model of Control A control model and typology evaluation ? Feb, 2010 7? We split the Business Domain to: ? Target ? part of the business that has to comply with a given set of rules ? (JtKe?Iiredoor?doPDin ? Rule: Door should be closed unless in use ? Rules reflect organizational goals  ? Goal: Prevent spread of fire ? Implementation Component ? Control The Enterprise Model of Control A control model and typology evaluation ? Feb, 2010 8? We split the Business Domain to: ? Target ? part of the business that has to comply with a given set of rules ? Implementation Component - the mechanism intended to bring about the target domain behavior ? E.g. a returning spring attached to the door ? Control Caveat! The door may be jammed thus preventing the spring from closing it. The Enterprise Model of Control A control model and typology evaluation ? Feb, 2010 9? We split the Business Domain to: ? Target ? part of the business that has to comply with a given set of rules ? Implementation Component - the mechanism intended to bring about the target domain behavior ? Control - a mechanism intended to assure that a given domain behaves as desired ? E.g. an alarm if door is open  Note: sometimes it is preferable to monitor the implementation component rather than the target. A Control Typology A control model and typology evaluation ? Feb, 2010 10? 6 dimensions to assist in managing organizational controls (i.e. coverage, redundancy, and similarity). Based on the control model and its ontological basis. ? Dimensions: 1. Focus ? which domain is monitored by the control mechanism (IC / T)? (JtKe?sprinJ?,&YstKe?Iiredoor?7 2. Responsibility ?  1. functional ? the IC achieves is objective (e.g. the spring closes the door when needed) 2. non-functional ? assuring the inherent operDtionoItKe,&eJsprinJisn?tsqueDN\ 3. Objective ? 1. States ? e.g. identification of insufficient funds 2. Events (state transitions) ? e.g. prevention of wire transfers 4. Hard/Soft Goal ? what / how goals are achieved? E.g.  employment contract vs. employee satisfaction 5. Risk Mitigation ? preventive / detective / corrective? E.g.  transaction locking vs. e-mail notification vs. recover data from backup 6. Structure ? open loop / closed loop? E.g.  identity validation vs. AC thermostat that adjusts based on external temp. ? Preset/fixed vs. Reactive, responds to different feedback from the monitored domain Typology Evaluation ? Objective: Develop a 'stable' version of the control-typology to reach a consensus among business practitioners who are experienced with applying business controls  ? Procedure: Delphi-like iterative paper-and-pencil exercise (3-4 iterations): ? Individual classification of controls (by each participant) ?Consolidation of answers (by researcher) A control model and typology evaluation ? Feb, 2010 11Typology Evaluation ? Input: A dataset of 25 business controls ? Dataset split (learning set ? 13 / validation set - 12) ? 6tDrtpoint?tKeoretiFDOt\poOoJ\? ? 2-3 iterations using a classification matrix A control model and typology evaluation ? Feb, 2010 12199Typology Evaluation ? Last iteration ? using the final version of the combined matrix and the 'validation set'. A control model and typology evaluation ? Feb, 2010 13200

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.24.1-0102469/manifest

Comment

Related Items