Using the Viable System Model to Derive Methods for Developing Principles of Enterprise Architecture

Home , Business operations, Capacity management, Error, Problem management, Security management, Service management

Mohammad Esmaeil Zadeh B.Sc., M.Sc. (Electronic Engineering)

A thesis submitted in partial fulfilment of the requirements for the degree of Doctor of Philosophy at the School of Engineering and Information Technology, the University of New South Wales, Canberra, Australia

2014

[this page is intentionally left blank]

To my beloved family:

Sousan, Bahar and Parsa

iii

Mohammad Esmaeil Zadeh 2014

[this page is intentionally left blank]

Mohammad Esmaeil Zadeh 2014

Abstract

Principles play an important role in Information Management (IM); this can be seen from the different principle-based IM standards, such as ISO/IEC 38500 for IT Governance. Also, in the various definitions of Enterprise Architecture (EA), principles are regarded as a pivotal element. However, despite advances in the definition and usage of principles, the EA discipline still suffers from some fundamental limitations, such as the lack of guidelines for developing a generic set of principles and a theoretical basis for developing them.

Assuming enterprises as viable systems, this research aims to suggest a set of design principles based on the concepts of cybernetics, especially those embedded in the Viable System Model (VSM). Stafford Beer formulated the VSM as a blueprint for designing organisations that are able to survive and thrive in a changing environment. The concepts of the VSM can be used for designing viable organisations, and hence also be used as the methods for developing principles of EA and IM.

The structure of this thesis is established on the Design Science Research methodology, which is generally based on the iterative “build” and “evaluate” processes. Following the steps of this methodology and after the initial phases of determining the problem and objective, the artefact which is a set of VSM-based design principles is developed. This artefact could be used as methods in proposing comprehensive principles, or in checking the coherency of a set of principles.

As for the evaluation step, the artefact is evaluated by mapping against an existing set of principles, generating a set of principles for an Australian government department, checking the comprehensiveness of the set of principles in another Australian agency, and finally proposing a set of principles for the IT Infrastructure Library (ITIL) as a non- EA application. All of these works are validated by professionals in different ways.

The contributions made by this research include: using cybernetic concepts to generate a set of principles and to check the coherency of existing sets of principles, improving EA

Mohammad Esmaeil Zadeh 2014

by the new definition and application of principles, and proposing a set of principles for ITIL. These outcomes are published as some conference and journal papers.

Mohammad Esmaeil Zadeh 2014

Keywords

Enterprise Architecture, Principles, Values, Cybernetics, Viable System Model (VSM), Information Management (IM), Information Technology (IT), Information Systems (IS), IT Governance, Viable Governance Model (VGM), TOGAF, COBIT, ITIL.

vii

Mohammad Esmaeil Zadeh 2014

[this page is intentionally left blank]

viii

Mohammad Esmaeil Zadeh 2014

Acknowledgement

I would like to express my sincere thanks to my principal supervisor, Dr. Edward Lewis, and late co-supervisor, Dr. Gary Millar, for their wisdom and understanding, exchange of ideas, and their guidance in all aspects of my work, providing me great help on various topics. In working with them, I found what it means to be a “good supervisor”.

I also would like to thank the professionals helping me in the evaluation part of this thesis, particularly Anna Yang, Christopher Thorne, Peter Lambert, Justin Gasparre and all itSMF members who attended in the survey in this thesis. I need also to sincerely thank Mrs. Salwah Kirk for proof-reading this thesis.

I am very grateful to Iran’s broadcast company for providing me with the opportunity for studying in this doctorate program.

I would like to thank all staff and friends in the School of Engineering and Information Technology and in UNSW-Canberra for their support and help, and in Australia – office workmates and everyone I meet regularly on my way to work, particularly my friends Dr. Reza Sayyah Jahromi, Dr. Alireza Abbasi, Dr. Weiping Zhu, and Dr. Sa’id Tehrani-Nasab.

I would like to thank my dear colleagues and friends for helping me throughout my way: Saber El-Sayed, Mohsen Habibi Tehrani, Faizal Kasmani, Amr Ghoneim, Theam Foo Ng, Shirli Wang, Ahmed Fathi, Mohamed Mabrok, Nastaran Nemati, Mehdi Hussain, Md. Shihanur Rahman, Eman Sayed, Irman Hermadi, George Leu, Hafsa Ismail, Andrey Kirsanov, Natalia Derevyanko, Ayman Ghoneim, and Nizami Jafarov.

Finally, a special thank you must go to my family, for their love, patience, sacrifice and encouragement during my PhD research work, and for putting up with a pre- occupied, and often absent, husband and father. I must also thank my parents, whose constant faith and support have made me the man I am and who can never be properly repaid.

Mohammad Esmaeil Zadeh 2014

[this page is intentionally left blank]

Mohammad Esmaeil Zadeh 2014

Originality Statement

‘I hereby declare that this submission is my own work and to the best of my knowledge it contains no materials previously published or written by another person, or substantial proportions of material which have been accepted for the award of any other degree or diploma at UNSW or any other educational institution, except where due acknowledgement is made in the thesis. Any contribution made to the research by others, with whom I have worked at UNSW or elsewhere, is explicitly acknowledged in the thesis. I also declare that the intellectual content of this thesis is the product of my own work, except to the extent that assistance from others in the project's design and conception or in style, presentation and linguistic expression is acknowledged.’

Signed ......

Date ......

Mohammad Esmaeil Zadeh 2014

[this page is intentionally left blank]

xii

Mohammad Esmaeil Zadeh 2014

‘I hereby grant the University of New South Wales or its agents the right to archive and to make available my thesis or dissertation in whole or part in the University libraries in all forms of media, now or here after known, subject to the provisions of the Copyright Act 1968. I retain all proprietary rights, such as patent rights. I also retain the right to use in future works (such as articles or books) all or part of this thesis or dissertation.

I also authorise University Microfilms to use the 350 word abstract of my thesis in Dissertation Abstract International (this is applicable to doctoral theses only).

I have either used no substantial portions of copyright material in my thesis or I have obtained permission to use copyright material; where permission has not been granted I have applied/will apply for a partial restriction of the digital copy of my thesis or dissertation.'

Signed ......

Date ......

Authenticity Statement

‘I certify that the Library deposit digital copy is a direct equivalent of the final officially approved version of my thesis. No emendation of content has occurred and if there are any minor variations in formatting, they are the result of the conversion to digital format.’

Signed ……………………………………………......

Date ……………………………………………......

xiii

Mohammad Esmaeil Zadeh 2014

[this page is intentionally left blank]

xiv

Mohammad Esmaeil Zadeh 2014

Preface

Years ago, when I finished my Masters degree in electronic engineering, I had the opportunity to continue my study in a doctorate program. However at that time, I was not satisfied completely with my education because I felt that what I had done thus far was purely theoretical. I did not have a proper understanding about what I had studied and how I could apply it to fulfil the needs of the real world. Therefore, I preferred to leave the academic environment to get some experience in professional jobs. I worked in different sectors of industry for several years, in technical, executive or managerial positions. During these years, especially as part of my executive positions in Information Management (IM), I was challenged by many problems that I could solve using my previous knowledge, personal interest, hard work, and innovative ideas in the work. However, there were unsolved issues too.

I realised that I could not solve these problems with my current knowledge. Although during these years of professional jobs I was in touch with new scientific achievements as part of my duties, the rapid growth of knowledge in these fields of science necessitated a more serious action from me. Therefore, I decided to come back to academic environments to expand my knowledge in order to find solutions for these problems. This time I knew what I must learn.

However, returning to the academic area after several years of professional jobs, specifically as a high-ranking manager, was not so easy. The situation would be harder when considering my new conditions, such as getting older, having a family that needed me, and moving to a new country. Moreover, I found that the related field of science had dramatically changed since I left the university. Therefore, I needed to review my previous knowledge and study basic courses in the new fields of science, to get ready for the new program.

I started my PhD program by working in the field of data networks and video streaming, as it was highly related to my last job position as a director in the Data Communication Department of a broadcast company. However after a short time, I found that this topic was not satisfying my needs. I needed to work in a subject that was not limited to a

Mohammad Esmaeil Zadeh 2014

narrow field of technology. Therefore I changed my field of study to a wider area of Information Systems (IS) and Information Technology (IT) management.

Most of the issues for whose solution I was looking were about the broader range of management of IT in general, and IT governance in particular. The university that I had joined had a good background in this field with a group working in IT governance and Enterprise Architecture (EA). Based on the cybernetic concepts, especially those embedded in the Stafford Beer’s Viable System Model (VSM), the group had developed a new model for the corporate governance of IT, the Viable Governance Model (VGM). This background could provide me with the opportunity of having experienced supervisors in these fields.

My intention in this program was to deploy cybernetics as the theoretical basis, with the achievements gained in the group in developing the VGM, the new findings in the academic and professional literature, my background in professional jobs and familiarity with the existing problems, to start researching solutions for these problems. By doing so, I could gain valuable knowledge that is useful for my future practice, and moreover, I could contribute its results to human knowledge for use by other professionals.

With the growing application of EA in organisations, this field of IM had been regarded as an interesting topic in academic and professional societies. On the other hand, there are a lot of principle-based standards and frameworks in IM. The pivotal role of principles in these standards and the wide application of these standards in practice were motivations for me to check the current status of principles in EA and select it as the topic for my research.

Therefore after a comprehensive review of the literature and consulting with my supervisors, I decided to continue the work that has been done in developing the VGM and extend it to propose a systematic way for developing EA principles (EAPs). Hence the topic chosen for this research is defined as:

Using the Viable System Model to Develop Principles of Enterprise Architecture and Information Management

xvi

Mohammad Esmaeil Zadeh 2014

As it is explained later, this study starts with investigating the EAPs, but as the research goes on and the capabilities of this approach are made clear, it shows the capability of being extended to other fields of IM too.

Thesis outline

The structure of this thesis is based on the Design Science Research (DSR) methodology. First of all in Chapter 1 and Chapter 2, the need for action and what we already know about the subject are studied by reviewing the literature about principles of IM and EA. Then as a theoretical basis for this research, cybernetic and the VSM concepts are reviewed in Chapter 3. This chapter also refers to the VGM as the application of the VSM in corporate governance of IT. Following on from there, the DSR as a structural basis for conducting this research is explained in Chapter 4. Then Chapter 5 designs the artefact of the DSR, which is a set method for developing EAPs in the form of design principles.

The rest of this thesis is the evaluation of the designed artefact. As the first case, Chapter 6 maps the set of design principles against an existing set of principles to check their applicability compared with available principles. In Chapter 7, the design principles are evaluated in two other practical cases. First they are deployed as guidelines to generate a set of principles for an Australian government department. Then they are used to check the coherency of a set of principles for another Australian government agency. The results of these two test cases are validated by professionals of these two organisations. These validations confirm the usability and usefulness of this approach in practice.

Chapter 8 studies the design principles in relation to other IM frameworks, such as the Control Objective for Information and Related Technologies (COBIT) for IT Governance and the IT Infrastructure Library (ITIL) for IT service management. The processes of these two frameworks are mapped against the design principles in order to check if they can be deployed as the Implication part of principles. Based on this mapping, the design principles are used to propose a set of principles for ITIL, as a final and non-EA application of these methods in other IM systems. Finally, Chapter 9 concludes this thesis by providing a summary of the work and achievements, identifying the restrictions and contributions, and outlining possible future directions for the research.

xvii

Mohammad Esmaeil Zadeh 2014

Publications

As a final notice, it should be noted that some parts of this thesis have been submitted to different conferences and journals, or presented in seminars. Thus far, the list of publications is:

Journal Papers:

- Esmaeil Zadeh, M., Millar, G., & Lewis, E. (2012b). Reinterpreting the TOGAF Enterprise Architecture Principles Using a Cybernetic Lens, Journal of Enterprise Architecture, May, 8(2), 9-17.

- Esmaeil Zadeh, M., Lewis, E., & Millar, G. (2012c). Enterprise Architecture Principles as Values, Journal of Enterprise Architecture, August, 8(3), 24-34.

Conference paper:

- Esmaeil Zadeh, M., Millar, G., & Lewis, E. (2012a). "Mapping the Enterprise Architecture Principles in TOGAF to the Cybernetic Concepts - An Exploratory Study," 45th Hawaii International Conference on System Sciences, HICSS, pp. 4270-4276.

- Esmaeil Zadeh, M., Lewis, E., Millar, G., Yang, Y., & Thorne, C. (2014). “The Use of Viable System Model to Develop Guidelines for Generating Enterprise Architecture Principles”, Paper submitted to SMC2014 conference (accepted).

Seminar:

- Esmaeil Zadeh, M. 2013. “The development of Principles for ITIL”. Presentation for a quarterly seminar of the ACT branch of the itSMF on Wednesday, 2 October 2013 at the Commonwealth Scientific and Industrial Research Organisation (CSIRO) Discovery Centre in Canberra.

Other publications are being prepared and will be submitted as conference and journal papers after the submission of this thesis.

xviii

Mohammad Esmaeil Zadeh 2014

Table of Contents

Abstract ...... v

Keywords ...... vii

Acknowledgement...... ix

Originality Statement ...... xi

Authenticity Statement ...... xiii

Preface ...... xv

Thesis outline ...... xvii

Publications ...... xviii

Table of Contents ...... xix

List of Figures ...... xxix

List of Tables ...... xxxi

List of Abbreviations...... xxxiii

Chapter 1 Need for Action ...... 1

1.1 Introduction ...... 1

1.2 Value of principles in Information Management ...... 1

1.2.1 Principles in Enterprise Architecture ...... 1

1.2.2 Principles in other frameworks of information Management ...... 2

1.3 Limitations of the development of principles ...... 3

xix

Mohammad Esmaeil Zadeh 2014

1.4 The Viable System Model (VSM) ...... 4

1.5 Conclusion...... 6

Chapter 2 Enterprise Architecture Principles ...... 7

2.1 Introduction ...... 7

2.2 Review of current literature ...... 7

2.3 Definition of principles in Enterprise Architecture ...... 10

2.3.1 Scope of EA ...... 11

2.3.2 Definition of EA...... 13

2.3.3 Architecture representation ...... 15

2.3.4 How EAPs are defined now ...... 16

2.3.4.1 Current definitions of principles ...... 16

2.3.4.2 Sets of principles ...... 17

2.3.4.3 Problems with current definition ...... 19

2.3.5 How EA principles should be defined ...... 19

2.3.5.1 Values ...... 19

2.3.5.2 Definition of a required value...... 21

2.3.5.3 Types of values ...... 21

2.3.5.4 Principles as values ...... 22

2.3.5.5 Resultant definition of EAPs ...... 23

2.4 Derivation of principles ...... 24

2.4.1 How EAPs are derived now ...... 24

Mohammad Esmaeil Zadeh 2014

2.4.2 Problem with current derivation ...... 27

2.4.3 How EAPs should be derived ...... 27

2.5 Application of principles ...... 28

2.5.1 How EAPs are used now ...... 28

2.5.2 How EAPS should be used ...... 28

2.6 Gap between what we need to know and what we do know ...... 31

2.7 Research objective...... 31

Chapter 3 Theoretical Basis ...... 35

3.1 Introduction ...... 35

3.2 Cybernetics ...... 35

3.2.1 Variety ...... 36

3.2.2 Requisite Variety ...... 37

3.3 The Viable System Model ...... 38

3.3.1 Viability ...... 40

3.3.2 Recursion ...... 41

3.3.3 Black box ...... 42

3.3.4 Organisational principles ...... 43

3.4 Systems of the VSM ...... 44

3.4.1 System 1- Operation ...... 44

3.4.2 System 2 - Coordination ...... 46

3.4.3 System 3- Control ...... 49

xxi

Mohammad Esmaeil Zadeh 2014

3.4.4 System 4 - Intelligence ...... 52

3.4.5 System 5 - Policy ...... 55

3.5 Critiques of the VSM ...... 58

3.6 The VGM ...... 58

3.7 Conclusion...... 60

Chapter 4 Methodology ...... 61

4.1 Introduction ...... 61

4.2 Research in IS ...... 61

4.3 Design as a research method (DSR) ...... 64

4.4 DSR approaches ...... 68

4.4.1 DSR common steps ...... 70

4.4.2 Balancing rigour and relevance ...... 72

4.4.3 Theory in the DSR ...... 75

4.4.4 Generating knowledge ...... 76

4.4.5 Summary of the models ...... 77

4.5 Using DSR in this research ...... 79

4.6 Conclusion...... 81

Chapter 5 Developing Design Principles ...... 83

5.1 Introduction ...... 83

5.2 How to derive design principles ...... 83

5.2.1 The VSM and EA ...... 83

xxii

Mohammad Esmaeil Zadeh 2014

5.2.2 Structure of proposed principles ...... 84

5.3 VSM-based generic design principles ...... 87

5.3.1 Requisite Variety ...... 87

5.3.2 Viability and Recursion...... 88

5.3.3 Black box ...... 88

5.3.4 Value creation and Value preservation ...... 89

5.3.5 Balancing cohesion versus autonomy ...... 89

5.3.6 Service units ...... 90

5.3.7 Core IT ...... 91

5.3.8 Coordination ...... 91

5.3.9 Resource management ...... 92

5.3.10 Performance ...... 92

5.3.11 Audit ...... 92

5.3.12 Adaptation ...... 93

5.3.13 Ethos ...... 93

5.3.14 Governance ...... 94

5.3.15 Compliance ...... 94

5.4 The use of proposed design principles as methods in practical cases ...... 95

5.4.1 Customisation ...... 97

5.4.2 How these methods could be used ...... 99

5.5 Conclusions ...... 99

xxiii

Mohammad Esmaeil Zadeh 2014

Chapter 6 Principles of TOGAF ...... 101

6.1 Introduction ...... 101

6.2 Example set of EAPs in TOGAF ...... 102

6.2.1 Sets of EAPs...... 102

6.2.2 Principles in TOGAF ...... 102

6.3 Classification of TOGAF’s business principles ...... 103

6.3.1 Principle 1: Primacy of Principles ...... 104

6.3.2 Principle 2: Maximize Benefit to the Enterprise ...... 104

6.3.3 Principle 3: Information Management is Everybody’s Business ...... 105

6.3.4 Principle 4: Business Continuity ...... 105

6.3.5 Principle 5: Common Use Applications ...... 106

6.3.6 Principle 6: Service Orientation ...... 106

6.3.7 Principle 7: Compliance with Law ...... 106

6.3.8 Principle 8: IT Responsibility ...... 107

6.3.9 Principle 9: Protection of Intellectual Property ...... 107

6.3.10 Summary of the discussions ...... 107

6.4 Mapping TOGAF’s principles to the proposed design principles ...... 108

6.4.1 Principle 1: Primacy of Principles ...... 109

6.4.2 Principle 2: Maximize Benefit to the Enterprise ...... 109

6.4.3 Principle 3: Information Management is Everybody’s Business ...... 109

6.4.4 Principle 4: Business Continuity ...... 110

xxiv

Mohammad Esmaeil Zadeh 2014

6.4.5 Principle 5: Common Use Applications ...... 110

6.4.6 Principle 6: Service Orientation ...... 111

6.4.7 Principle 7: Compliance with Law ...... 112

6.4.8 Principle 8: IT Responsibility ...... 113

6.4.9 Principle 9: Protection of Intellectual Property ...... 113

6.4.10 Summary of the mappings ...... 114

6.4.10.1 Relationship matrix ...... 114

6.4.10.2 Other principles of TOGAF ...... 115

6.5 Validation ...... 118

6.5.1 Modifications inspired from available EAPs ...... 118

6.5.2 Modifications inspired from feedback ...... 118

6.6 Improving the principles set of TOGAF ...... 120

6.7 Conclusions ...... 120

Chapter 7 Validation of the Proposed Guidelines in Practical Cases ...... 123

7.1 Introduction ...... 123

7.2 The use of guidelines for proposing EAPs ...... 123

7.2.1 Cloud Computing in the ATO ...... 124

7.2.2 Developing policies ...... 124

7.2.3 Customisation of the design principles ...... 125

7.2.4 Procedure for developing ATO’s principles ...... 125

7.2.5 Validation of the results ...... 127

xxv

Mohammad Esmaeil Zadeh 2014

7.3 Using the guidelines as a diagnosing tool ...... 128

7.3.1 The DSTO guiding principles ...... 128

7.3.2 Common deficiencies in a set of principles ...... 130

7.3.3 Mapping the IM&T principles against the design principles ...... 130

7.3.4 Results of the diagnosis...... 133

7.3.4.1 Missing principles ...... 133

7.3.4.2 Other weaknesses ...... 134

7.3.5 Evaluation ...... 135

7.4 Conclusion...... 135

Chapter 8 Principles and Other Frameworks ...... 137

8.1 Introduction ...... 137

8.2 List of IT activities ...... 138

8.2.1 COBIT ...... 139

8.2.1.1 COBIT 5 process model ...... 140

8.2.1.2 Good practices ...... 141

8.2.2 ITIL ...... 144

8.2.2.1 ITIL framework ...... 144

8.2.2.2 ITIL service lifecycle ...... 144

8.2.2.3 Services in ITIL ...... 146

8.2.2.4 ITIL processes ...... 146

8.2.2.5 ITIL functions ...... 146

xxvi

Mohammad Esmaeil Zadeh 2014

8.3 Mapping COBIT and ITIL processes against design principles ...... 147

8.3.1 The procedure for mapping ...... 147

8.3.2 The result of mapping ...... 153

8.3.3 Vertical mapping ...... 154

8.4 Developing principles for ITIL ...... 157

8.4.1 Possible uses of principles in ITIL ...... 158

8.4.2 Proposed set of principles for ITIL ...... 159

8.4.3 Evaluation of the proposed principles ...... 159

8.4.3.1 The survey ...... 159

8.4.3.2 Feedback ...... 162

8.5 Conclusion ...... 163

Chapter 9 Conclusions and Future works ...... 165

9.1 Introduction ...... 165

9.2 Summary ...... 165

9.3 Meeting the objective and needs ...... 167

9.4 Contributions of this study ...... 168

9.5 Limitations ...... 169

9.6 Future works and research directions ...... 171

9.7 Conclusions ...... 173

References ...... 175

Annex 1 ITIL Principles Questionnaire ...... 187

xxvii

Mohammad Esmaeil Zadeh 2014

Annex 2 Summary of the Responses to ITIL Questionnaire ...... 191

Annex 3 Example Set of Architecture Principles in TOGAF ...... 197

xxviii

Mohammad Esmaeil Zadeh 2014

List of Figures

Figure 2-1- The EA mandate within an organisation and its associated value (ACS, 2012) ...... 12

Figure 2-2- Classification of areas of application of principles ...... 18

Figure 2-3- Greefhorst and Proper (2011) conceptual framework for motivating EAPs ...... 26

Figure 2-4- Generic process for handling architecture principles (Greefhorst & Proper, 2011) 30

Figure 3-1- The concept of variety, amplifier and attenuator (Beer, 1985) ...... 37

Figure 3-2- The Viable System Model (VSM) (Beer, 1985) ...... 39

Figure 3-3- The VGM – structural elements (Millar, 2009) ...... 59

Figure 4-1- Research methods in the IS, (Niglas, 2001) ...... 62

Figure 4-2- Available forms of science (Lewis, 2013) ...... 63

Figure 4-3- The DSR methodology process model (Peffers et al. 2007) ...... 71

Figure 4-4- The conceptual framework for IS research (Hevner et al. 2004) ...... 73

Figure 4-5- Design Science Research cycles (Hevner, 2007) ...... 74

Figure 4-6- Vaishnavi and Kuechler (2007) model for DSR ...... 77

Figure 4-7- The overall Design Science Research roadmap (Alturki et al., 2011) ...... 78

Figure 6-1- Relations between the VSM-based design principles and some concepts of the EA ...... 116

Figure 8-1- COBIT 5 principles (ISACA, 2012a) ...... 139

Figure 8-2- COBIT 5 governance and management key areas (ISACA, 2012a) ...... 140

Figure 8-3- COBIT 5 process reference model (ISACA, 2012b) ...... 143

Figure 8-4- The ITIL service lifecycle (ITIL, 2011b) ...... 145

Figure 8-5- ITIL v3 (2011) processes and functions ...... 147

xxix

Mohammad Esmaeil Zadeh 2014

[this page is intentionally left blank]

xxx

Mohammad Esmaeil Zadeh 2014

List of Tables

Table 2-1- List of publications about EAPs ...... 9

Table 2-2- List of Publications that address EAPs indirectly ...... 10

Table 2-3- Classification of values ...... 22

Table 4-1- Comparison between DSR and routine design (Alturki et al., 2012) ...... 68

Table 4-2- Design Science Research guidelines (Hevner et al., 2004) ...... 75

Table 5-1- Recommended format for defining principles (TOGAF, 2012) ...... 85

Table 5-2- Summary of the VSM-Based design principles ...... 96

Table 6-1- Classification of business principles in TOGAF based on the types of values ...... 104

Table 6-2- Mapping TOGAF’s business EAPs to VSM-derived EAPs...... 108

Table 6-3- Mapping matrix of TOGAF’s business principles to the design principles ...... 115

Table 6-4- the relationships between design principles ...... 117

Table 7-1- The ATO’s EAPs and the corresponding design principles ...... 126

Table 7-2- The DSTO IM&T guiding principles ...... 129

Table 7-3- Mapping the DSTO’s IM&T principles against the design principles ...... 131

Table 8-1- Mapping COBIT processes against the VSM-based design principles ...... 149

Table 8-2- Mapping ITIL processes against the VSM-based design principles ...... 151

Table 8-3- An example of mapping design principles against the COBIT processes ...... 155

Table 8-4- An example of mapping design principles against the ITIL processes ...... 156

Table 8-5- The proposed principles for ITIL ...... 159

Table 8-6- Mapping ITIL process against the proposed principles for ITIL ...... 161

xxxi

Mohammad Esmaeil Zadeh 2014

[this page is intentionally left blank]

xxxii

Mohammad Esmaeil Zadeh 2014

List of Abbreviations APO Align, Plan and Organise ATO Australian Taxation Office BAI Build, Acquire and Implement CIO Chief Information Officer COBIT Control Objectives for Information and related Technology CSIRO Commonwealth Scientific and Industrial Research Organisation DSR Design Science Research DSS Deliver, Service and Support DSTO Defence Science and Technology Organisation EA Enterprise Architecture EAP Enterprise Architecture Principle EDM Evaluate, Direct and Monitor FEA Federal Enterprise Architecture ICT Information and Communications Technology IM Information Management IM&T Information Management and Technology IP Intellectual Property IS Information Systems ISACA Information Systems Audit and Control Association ISMS Information Security Management System IT Information Technology ITIL Information Technology Infrastructure Library ITSM Information Technology Service Management itSMF Information Technology Service Management Forum MEA Monitor, Evaluate and Assess RACI Responsible, Accountable, Consulted or Informed SOA Service Oriented Architecture SOE Service Oriented Enterprise SLR Systematic Literature Review SMART Specific, Measurable, Actionable, Relevant and Timely S&T Science and Technology TOGAF The Open Group Architecture Framework

xxxiii

Mohammad Esmaeil Zadeh 2014

VGM Viable Governance Model VSM Viable System Model UNSW University of New South Wales

xxxiv

Mohammad Esmaeil Zadeh 2014

Chapter 1 Need for Action

1.1 Introduction

Usually any research starts from investigating its need for action and the relevance of the topic for practice, which covers the issues of why the subject is important and if there is a need to work in this field. This chapter covers this part of my research, which is about the development of principles of Enterprise Architecture (EA) and other Information Management (IM) frameworks. For this purpose, the importance of principles in EA and IM are studied first. Then by reviewing part of the literature in EA and some other frameworks of IM, current problems in the development and application of principles in these disciplines are reviewed. As the main needs for action, these limitations constitute the main motivation in doing this research. A comprehensive study of the current situation of principles in IM, including their definition, derivation, classification and usage, requires a more detailed study of the literature and is addressed in Chapter 2.

1.2 Value of principles in Information Management

Principles have been shown to be very important in different aspects of IM. The main usage of principles is in EA (Lewis, 2013). In this section, the importance and usage of principles in EA are briefly reviewed first. Following that, the role of principles in other frameworks of IM is addressed.

1.2.1 Principles in Enterprise Architecture

During recent years, Enterprise Architecture has been becoming a popular approach in aligning the resources of the enterprise to its business objectives, (Lankhorst, 2009; Lewis, 2013; Niemi, 2007; OptLand et al., 2008; Radeke, 2010; TOGAF, 2012), More completely, as Lewis (2013) explains, Enterprise Architects align the resources that make up a capability of the enterprise to the strategic objectives of the enterprise; integrate the resources across the work systems; and attune the resources to the politics and policies of the enterprise.

There are a lot of publications discussing about the application and value of EA, different understandings and schools of thought about it, and the different approaches

Mohammad Esmaeil Zadeh 2014

and frameworks for its successful implementation. In these literature, different definitions can be found for EA (e.g. ISO/IEC/IEEE 42010, 2010; TOGAF, 2012; FEAF, 2001; Lewis, 2013), showing different views about this discipline and different roles it plays in designing organizations. Some of these definitions are addressed in more details in Chapter 2. The most authoritative definition of architecture is that proposed by ISO/IEC/IEEE 42010 (2010): “The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution”. This definition has also been adopted by The Open Group Architecture Framework (TOGAF, 2012), as an important source of advice about the use of EA: “The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.”

These definitions highlights that principles are an essential component of any architecture framework. More specifically, the literature supports the view that principles are essential components of an EA (Aier 2011; Proper et al. 2010; Stelzer 2010; Haki & Legner 2012). Some researchers even opine that principles are the main element in the definition of EA. Boar defines IT architecture as “a set of principles, guidelines, and rules that guides an organization through acquiring, building, modifying, and interfacing IT resources throughout the enterprise” (Boar 1994). Hoogervorst (2009) posits that “architecture is a coherent and consistent set of principles and standards”. Greefhorst and Proper (2011b) regard principles as the “cornerstone of EA”.

All of these works show the importance of principles in EA, and clarify why Enterprise Architecture Principles (EAPs) have become an important area of research in recent years.

1.2.2 Principles in other frameworks of information Management

Principles are also used, or could be useful, in other IM frameworks. There are some principle-based standards and frameworks for IT and other disciplines, such as ISO/IEC 38500 for corporate governance of IT (ISO/IEC, 2008) and ISO 31000 for Risk Management (ISO, 2009). As an example, ISO/IEC 38500 consists of six principles for the corporate governance of IT. Other frameworks and standards usually refer to this standard and its principles as a reference. In these frameworks, principles can be used to change them into principle-based, which means that instead of worrying about the detail

Mohammad Esmaeil Zadeh 2014

of how things have to be done, principles do tell you what the desired outcomes of actions are but free you to achieve them however you wish.

Principles are also used in COBIT, although it is not a principle-based framework. Principles in COBIT are mainly for developing this framework, not to make it principle- based, such as ISO/IEC 38500.

Principles might be used in IT risk management as well. ISO 31000 (ISO, 2009) is a principle-based standard that provides principles and generic guidelines on risk management in general. ISO/IEC 27000 (ISO/IEC, 2012) is part of a growing standard series for Information Security Management Systems (ISMS). This standard has some principles, although it is not a principle-based standard either.

ITIL (2011a, b, c, d, e) has been shown to be a very powerful and largely accepted framework for IT Service Management (ITSM). Principles seem to be important in ITIL too, as they are mentioned in the description of nearly all of its sections and processes; however, there are no principles actually listed as such in this framework.

1.3 Limitations of the development of principles

In spite of the importance of principles in IM, this notion is still in its infancy and suffers from some limitations, which are mainly about their definition, development, classification, and usage in EA and IM (see e.g. Fischer et al., 2010; Aier et al., 2011; Proper & Greefhorst, 2010, Greefhorst & Proper, 2011; Stelzer, 2010; Haki and Legner, 2012).

Fischer et al. (2010) argue that the concept of architecture principles has not received a lot of research attention. Proper and Greefhorst (2010) in their study on formulation and use of architecture principles, mention that there is a need to better understand their essence. Stelzer (2010) in reviewing different studies related to EAPs, formulates his own definition and identifies the following limitations:

• The lack of an appropriate definition for EAP

• The lack of a theoretical basis for developing them

• The lack of a set of generic EA design principles

Mohammad Esmaeil Zadeh 2014

Aier et al. (2011) in their review of the definitions of principles, argue that while design representation issues like meta-modelling or notations have been discussed in EA literature, design activity issues and design principles in particular are often neglected. More recently, Haki and Legner (2013) in their review of the literature about EA principles, confirm that architecture principles are still perceived as an underexplored topic in EA management research. They also state that current literature is still vague about what can be considered as suitable EA design and evolution guidance principles and lacks empirical insights regarding their role and usefulness in practice.

The limitations of principles exist in other IM frameworks too. As mentioned in previous section, in spite of the importance of principles in ITIL, COBIT, and IT Risk Management, these IM frameworks does not have a set of principles as such. In these frameworks, principles can be used to change them into principle-based. As mentioned before, this means that principles are used to specify the desired outcomes of actions, leaving organisations to achieve them however they wish. Principles can also be deployed in these frameworks as a measuring tool to assess the performance or quality of their IM services. In this application, the principles are used as a basis to check the compliance of units and individuals to these frameworks and the maturity of the organisation in the related aspects.

1.4 The Viable System Model (VSM)

After knowing about the current limitations in the development of IM principles, it is now the time to find a proper theoretical foundation to overcome these limitations. The concepts of system thinking and cybernetics, especially those embedded in the Viable System Model (VSM), have been shown to be powerful tools in designing viable organisations. The VSM is explained in more details in Chapter 3 as the theoretical basis for this research. In this section, it is shown that the VSM has already been used in EA and IM in several studies, and therefore, can be suitable as a theoretical basis for this research.

The VSM is a blueprint or template for designing viable organisations (Beer, 1984; Hoverstadt, 2008). Similarly, in some earlier definitions, EA is regarded as the blueprint for the architecture of an organisation; for example:

Mohammad Esmaeil Zadeh 2014

“EAs are blueprints for systematically and completely defining an organization’s current (baseline) or desired (target) environment.” (FEA 2001)

In fact, the VSM is a blueprint for what functions should be present in a viable system, while EA is a blueprint on how an organisation should be developed. Given the potential overlap between these two concepts, the VSM may prove to be a useful theoretical foundation for developing EAPs. This approach is in line with the differentiation between functional and constructional requirements and principles as described by Dietz (2006, 2008).

As it is shown in Section 3-6, the VSM is used in IT management discipline to formulate the Viable Governance Model (VGM) for the corporate governance of IT. Beside this, the use of VSM as a suitable theory to investigate different facets of EA has recently been raised in a few academic and professional studies.

Hoverstadt (2008), in a systemic approach to studying organisations, integrated mainstream management ideas with the system ideas underpinning the VSM. He used the VSM to model the organisation in order to understand and diagnose the enterprise.

Looking for a holistic and integrated management of the different concepts in EA, Buckl et al. (2009) approached the topic of EA management from a cybernetic point of view. Their research is primarily concerned with the how the VSM could be used to establish a system for managing an EA.

Graves (2009) used the VSM to investigate Service-Oriented Architecture (SOA), extending the concepts to all aspects of the enterprise to create the Service-Oriented Enterprise (SOE). He advocated extending EA frameworks beyond IT systems to the enterprise. Graves used systems theory, and especially the VSM, to improve the design and delivery of business services. He regarded services as viable systems and showed that using VSM concepts can be of direct benefit in providing simplicity and consistency in service design.

These studies, together with some observations in the academic and professional literature (such as Kandjani et al., 2013; Kandjani & Bernus, 2013; or the discussion in Linkedin under the topic: Could VSM and Enterprise Architecture (EA) be a happy

Mohammad Esmaeil Zadeh 2014

marriage? (Linkedin, 2014)), indicate that the VSM may be a useful model to explore the field of EA. However, none of the above studies used the VSM as a conceptual framework for developing principles of EA and IM, and therefore, it would be a novel idea to find out whether the VSM can be used as the theoretical basis in this research.

1.5 Conclusion

This chapter started our journey by specifying the need for action for doing research in the field of principles in IM. As a summary it was shown that principles are an important element in the development and implementation of EA, and this importance has brought their concept into prominence in recent years. It was also explained that principles are, or could be, very useful in other frameworks of IM as well, such as in COBIT, ITIL and IT Risk Management. However, despite the effort made in academic and professional literature, the notion of principles in IM is still in its infancy and suffering from some fundamental deficiencies. There are a large number of principles in different sources introduced as EAPs but there are no established criteria for their classification or for checking their validity. The source of these problems can be related to the ambiguity in the definition of EAPs and the lack of a theoretical basis for developing and classifying them. Work is needed to overcome the current limitations in the definition and formation of EAPs. Moreover, there is still a lack of a set of generic EAPs and a theoretical basis for developing them. This problem also exists in the actual implementation and application of EAPs and there is a need for guidelines for putting principles into practice. All of these imply need for a systematic consideration of principles in IM.

Later on, by investigating the use of VSM in IM and EA, it was shown that the concepts of cybernetic and the VSM can be a suitable theoretical basis to be used in the development of principles.

In the next chapter, the journey is continued by reviewing the position of principles in EA as the main application of principles in IM. In this review, the need for a systematic study of principles is continued by exploring what their current status is, what their ideal status should be, the gap between current and ideal situation and finally, what can be done to overcome the gap between these two. Later on in Chapter 9, this study is expanded to other common frameworks of IM.

Mohammad Esmaeil Zadeh 2014

Chapter 2 Enterprise Architecture Principles

2.1 Introduction

In Chapter 1 it was shown that the context of principles is important in IM, and there is a need for further study in this field. The next step in doing this research is to study current literature about the topic in more details, in order to discover what is already known about it. Since the main application of principles in IM is in Enterprise Architecture (EA), this study is started by investigation of Enterprise Architecture Principles (EAPs) to obtain a better perception of them, determine the span they must cover, and see if there is a better way to structure them. For this purpose, by doing a Systematic Literature Review (SLR) first, the existing literature about (EAPs) is determined and classified for future use.

Then variety in existing definitions of EA is examined and a new definition is given to clarify its scope more precisely. From there, the definition, derivation, and use of EAPs are discussed, in order to better understand them and the problems in which they are involved. After that, by introducing the concept of values a new definition of EAPs as values is proposed. This definition enables the use of works in the field of values and governance to classify principles as the basis for their systematic derivation and application. In later sections, the same study is carried on for the derivation and implementation of EAPs, followed by a summary of the gap between what we know and what we should know in the definition, derivation, formulation, classification and usage of EAPs. As it is shown, this gap is the main motivation for doing this research and forms its need for action, based on which, the chapter is concluded by defining the research question and the research objective.

2.2 Review of current literature

Following the common Systematic Literature Review (SLR) methodologies such as Webster and Watson (2002), Tranfield et al. (2003), Higgins et al. (2003), Vom Brocke et al. (2009), or the more recent one, Okoli and Schabram (2010), the current literature in

Mohammad Esmaeil Zadeh 2014

the field of EA principles has been reviewed. The review started with identifying its need and a small scoping study for acquiring a broad idea of available literature, relevant search engines, appropriate keywords, etc. The scope of this review was determined as EA discipline and its related fields. The set of keywords deployed for carrying out this search included the terms: principles, (Enterprise) Architecture principle, and design principle. Along with the popular Google Scholar search engine, different resources, databases and magazines in the University of New South Wales (UNSW) Canberra library, as well as related search engines such as The ACM Guide, IEEE Explore, CiteSeerX, Emerald and EA conferences were also searched. The search was not restricted to academic publications in order to include the professional viewpoints and to prepare a comprehensive list of literature from academic and professional resources. Moreover, after finding a related article, its references were also checked for their relevance to the search topic.

The list of related publications, after excluding unrelated publications such as those about principles in general, those addressing principles in other disciplines, or the articles that used the term principles in other meanings (such as fundamentals) were excluded.

The final results are summarised in Table 2-1 and Table 2-2, showing two groups of literature about EAPs. Table 2.1 lists the first group addressing EAPs principles directly, and are mainly from academic literature. The second group, shown in Table 2-2, are those about other aspects of EA in general, but addressing principles too.

The results of this SLR are to a large extent compatible with those that outlined by previous similar works (Fischer et al. 2010; Stelzer, 2010; Winter & Aier, 2011; Greefhorst & Proper, 2011; Haki & Legner, 2012). These results, which are used and cited in this thesis, show that the number of related, up-to-date resources is very few, and nearly all of them emphasise the importance of EAPs and acknowledge that this discipline is still in its infancy with little known about it.

Mohammad Esmaeil Zadeh 2014

Table 2-1- List of publications about EAPs

Author(s) Title 1 Richardson et al. (1990) A principles-based enterprise architecture: Lessons from Texaco and Star Enterprise 2 Van Bommel et al. Giving meaning to enterprise architectures: Architecture (2006) principles with ORM and ORC 3 Lindstrom (2006) On the syntax and semantics of architectural principles 4 Weiss (2006) Developing Effective Enterprise Architecture Principles 5 Schultz (2007) Architecture principles: Creating the foundation for robust architecture 6 Van Bommel et al. Architecture principles – A regulative perspective on (2007) enterprise architecture 7 OptLand & Proper Impact of principles on enterprise engineering (2007) 8 Fischer et al. (2010) What is an enterprise architecture design principle? Towards a consolidated definition 9 Stelzer (2010) Enterprise architecture principles: literature review and research directions 10 Proper & Greefhorst The roles of principles in enterprise architecture (2010) 11 Proper & Greefhorst Principles in an enterprise architecture context (2011) 12 Greefhorst & Proper A practical approach to the formulation and use of (2011a) architecture principles 13 Winter & Aier (2011) How are enterprise architecture design principles used? 14 Greefhorst & Proper Architecture Principles: The Cornerstones of Enterprise (2011b) Architecture. 15 Aier et al. (2011) Construction and evaluation of a metamodel for enterprise architecture design principles 16 TOGAF (2012) The Open Group Architecture Framework, TOGAF Version 9.1 17 Haki & Legner (2012) Beyond EA Frameworks: Towards an Understanding of the Adoption of Enterprise Architecture Management 18 Haki & Legner (2013) Enterprise Architecture Principles in Research and Practice: Insights from an Exploratory Analysis.

Mohammad Esmaeil Zadeh 2014

Table 2-2- List of Publications that address EAPs indirectly

Author(s) Title 1 Boar (1994) Practical Steps for Aligning Information Technology with Business Strategies 2 Armour et al. (1999) A big-picture look at enterprise architectures 3 FEA (2001) A Practical Guide to the Federal Enterprise Architecture 4 Wilkinson (2006) Designing an ‘adaptive’ enterprise architecture 5 Janssen and Kuk (2006) A complex adaptive system perspective of enterprise architecture in electronic government 6 Winter and Fischer Essential layers, artifacts, and dependencies of enterprise (2007) architecture 7 Hoogervorst (2008) Enterprise architecture: Enabling integration, agility and change 8 Chen et al. (2008) Architectures for enterprise integration and interoperability: Past, present and future 9 Schekkerman (2008) Enterprise Architecture Good Practices Guide: How to Manage the Enterprise Architecture Practice. 10 Nightingale (2009) Principles of enterprise systems 11 Hoogervorst (2009) Enterprise architecture: Enabling integration, agility and change 12 ISO/ IEC/IEEE 42010 Systems and Software Engineering - Architecture (2010) Descriptions 13 PEAF (2011) Product: Governance: Principles, Pragmatic EA Framework 14 Foorthuis et al. (2012) Compliance Assessments of Projects Adhering to Enterprise Architecture 15 Lewis (2013) Layrib: Planning Viable Systems

2.3 Definition of principles in Enterprise Architecture

Since John Zachman (1987) articulated Enterprise Architecture (EA) and its extended EA (Sowa & Zachman, 1992), as frameworks for Information System (IS) Architecture, this discipline has significantly evolved and the definition, scope, and guidance for EA have likewise been modified (EABOK, 2004). The initial Zachman’s framework is based on a matrix of entities, which can be used to describe particular perspectives and

Mohammad Esmaeil Zadeh 2014

relationships (Zachman, 1987). His work provides a formalised approach to understanding the complex interrelationships between the many different components of an information technology system, the business processes it supported and the business drivers behind it (ACS, 2012). Since then, many frameworks and methods have evolved and its scope has broadened (ACS, 2012). Schekkerman (2008) provides a review of some of the main frameworks and different interpretations about this discipline, which result in having various definitions of EA in the academic and professional literature.

This ambiguity reflects also in the skills, experience and knowledge required by an Enterprise Architect (ACS, 2012), demanding a need for a structured approach to manage the major set of assets and business capabilities that are embedded within not just a technology portfolio but a portfolio of enterprise capabilities (Weill & Broadbent, 1998).

Although the main aim of this thesis is not to enter into the different approaches in defining EA, it seems necessary to have a general view about EA and its definitions available in the literature. In this section, before trying to find a proper definition of EA, we study the scope of EA to show that how this discipline has evolved. This will also help us in defining EA, so as to find what EA is about and what it covers.

2.3.1 Scope of EA

There is an ambiguity in the literature about the scope of EA. The field of EA is continuously evolving. Some of the definitions of EA (and architecture) do not contain any mention of Information Technology (e.g. ISO/IEC/IEEE, 2010 and FEA, 2001). It can be taken that these uses of EA apply to any or all resources in the enterprise. Moreover, there is a move to regard EA as the planning of all resources, including people, not just information technology (Lewis, 2013). This move makes what was initially proposed as EA to be known nowadays as Enterprise IT Architecture (Perks & Beveridge, 2003), in order to distinguish it from the more recent use of EA to cover a wider area.

There is a general consensus in the literature that the nature of EA is evolving, although differing perspectives or levels of maturity are expressed (ACS, 2012). Figure 2-1 expresses a view of EA maturity indicating this evolving nature of EA. As a result the

Mohammad Esmaeil Zadeh 2014

range of skills that an Enterprise Architect requires should be broader than EA as pure enterprise-wide IT architecture (shown at B in Figure 2-1). Maybe the best definition of the scope of EA is given by the SFIA (2011) as: “the creation, iteration, and maintenance of structures such as enterprise and business architectures that embody the key principles, methods and models that describe the organisation’s future state, and that enable its evolution to that state. This creation typically involves the interpretation of business goals and drivers; the translation of business strategy and objectives into an “operating model”; the strategic assessment of current capabilities; the identification of required changes in capabilities; and the description of inter-relationships between people, organisation, service, process, data, information, technology and the external environment.”

Figure 2-1- The EA mandate within an organisation and its associated value (ACS, 2012)

As a final reminder, it must be noticed that although EA is regarded as the planning of all resources under the control of an organisation, it does NOT cover all its IM aspects, such as IT governance or IT Risk Management. EA might overlap with other IM frameworks in many aspects, but it should not be considered as another general management approach.

Mohammad Esmaeil Zadeh 2014

2.3.2 Definition of EA

There are many definitions of Architecture and Enterprise Architecture (EA) in the academic and professional literature. Some commonly used definitions can be found in TOGAF (2012), ISO/IEC/IEEE (2010), FEA (2001), and Gartner (2012). This wide range of definitions shows different views about this discipline, different roles it plays in designing organisations and its evolution over time.

It is strange that some standard organisations do not have a clear definition of EA. The Open Group Architecture Framework (TOGAF), as an important source of advice about the use of enterprise architecture, is an obvious example. In the latest version of TOGAF (2012) the terms Enterprise and Architecture are defined separately, but there is no specific definition for Enterprise Architecture.

TOGAF (2012, p. 25) defines enterprise as “The highest level (typically) of description of an organization and typically covers all missions and functions. An enterprise will often span multiple organizations”. The enterprise has a wider scope than the structure of an organisation. It can be said that while an organisation is bounded by rules, roles and responsibilities, an enterprise is bounded by visions, values, and commitments (Graves, 2012). In another point of view, an enterprise is “an entity able to control its resources” (Schekkerman, 2008, p. 31).

Architecture is also defined in TOGAF (2012, p. 20) as:

1- A formal description of a system, or a detailed plan of the system at component level, to guide its implementation.

2- The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

The second definition emphasises three items: elements (also known as components or resources), relationships, and principles. The first definition, which referred to the ISO/IEC/IEEE 42010 (2011) Standard, expresses the main function of architecture as description of a system. It must be noted that the title of the ISO/IEC/IEEE 42010 standard is Architecture Description. In the latest draft of this Standard, the term ‘description’ in the definition of Architecture has been replaced by concepts or

Mohammad Esmaeil Zadeh 2014

properties, to differentiate Architecture from Architecture Description. The current definition of Architecture in this standard is (ISO/IEC/IEEE, 42010: 2010):

Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.

Here architecture is regarded as something that exists. Every system has architecture even if that architecture is not written down. It is the architecture description, the topic of the Standard, which provides the description. In fact, an EA is described in a set of models, arranged into views; according to guidance about their representation through viewpoints. Taking these definitions as a foundation, our definition of EA for the purpose of this paper will be:

An Enterprise Architecture is the set of all resources under the control of an organisation, their relationships, and the principles underlying the design and evolution of these relationships.

It must also be mentioned that EA can be used to mean a discipline as well. That is, while EA can be regarded as a structure of things, EA as a discipline describes what Enterprise Architects do to design and describe an EA. The term Enterprise Architecting is used by Nightingale and Rhodes (2004, p. 6) as an important activity “which is unique from enterprise engineering”. Our definition of EA as a discipline is based upon planning (Lewis, 2013):

Enterprise Architecture is the discipline of planning to align, integrate, and attune the resources of the enterprise so their use is effective, efficient, and acceptable.

In addition to what EA is targeting (to align, integrate and attune resources), this definition indicates the role of key values (effectiveness, efficiency and acceptability) in the planning process. The relation between values and principles will be discussed later on in this section.

These two definitions of EA cover the first motivation of this paper, which is to emphasise that the scope of EA is the planning of all resources under the control of an enterprise.

Mohammad Esmaeil Zadeh 2014

2.3.3 Architecture representation

Often, an Architecture is confused with an architecture description, as Ross et al. (2006, p.47) say “Many companies attack the enterprise architecture exercise with lots of drawings and analysis of both existing and hoped-for systems capabilities. But massive analytical efforts do not focus resources on what matters. The key to effective enterprise architecture is to identify the processes, data, technologies, and customer interfaces that take the operating model from vision to reality”. In fact, box-and-arrow drawings alone are not architectures; rather, they are a starting point, architecture includes behaviour of components (Bass et al., 2012). The most succinct description of Architecture Representation comes from Lewis (2013, p23). I can do no better than use his words:

“The description, usually in the form of diagrams, is a model of the architecture. The documentation can be a verbal description of how the components work together or it can be a set of diagrams showing the links between components, in various degrees of granularity. Various diagrams are used to represent the different perspectives of the stakeholders in the enterprise system, be they buyers or builders.

In more formal, established Enterprise Architecture practices, these diagrams are constructed according to an agreed ‘viewpoint’. The viewpoints are developed to best represent the concerns of the stakeholders. They are equivalent to the legends on a map, showing what the symbols mean. They can be in different formats and different scales, according to the needs of the readers of the map.

The specific models (or products or artefacts), constructed according to the viewpoints, are often gathered into views. A specialist builder might need several models in a systems or an operational view, so they can see all of the relevant relationships.

An architecture description is used to communicate

• The buyers’ needs to the designer

• The designers’ ideas to the specialist builders.

Mohammad Esmaeil Zadeh 2014

So, somewhere between these two communications, we need to convert the needs into build ideas. That is where designing fits in - and the principles guiding the design.”

This interpretation of the Architecture Description is consistent with the ISO/IEC/IEEE 42010 (2010) definition of architecture mentioned before, to differentiate it from the concept of Architecture.

2.3.4 How EAPs are defined now

Most of the EA definitions highlight that principles are an essential component of any architecture framework. In some definitions of EA, principles are not included explicitly, but they are regarded as part of the elements of the organisation (Schekkerman, 2008). Some other researchers support the view that principles are essential components of an Enterprise Architecture (Aier et al, 2011; Greefhorst & Proper, 2011; Stelzer 2010). Greefhorst and Proper (2011) regard principles as the cornerstone of enterprise architecture. Some researchers even opine that principles are the main element in the definition of EA. Boar (1994, p. 91) defines IT Architecture as “a set of principles, guidelines and rules that guides an organization through acquiring, building, modifying and interfacing IT resources throughout the enterprise”. Hoogervorst (2009, p. 128) goes further and posits that “architecture is a coherent and consistent set of principles and standards”.

Accordingly, as principles are important in Enterprise Architecture, it is necessary to be clear about what they are and how they can be derived.

2.3.4.1 Current definitions of principles

Flowing from the debate concerning EA, there are several different definitions for EAPs (see e.g. Aier et al., 2011; Greefhorst & Proper, 2011; Stelzer, 2010). Different authors proffer their own definitions based on their intended purpose for formulating EAPs. Lindstrom proposes a reference model for IS/ICT responsibilities and relates this model to architecture principles, exemplified by some principles such as interoperability and data quality. She asserts that EAPs are needed to avoid enterprise systems that are “wild-grown” (Lindstrom, 2006). She also proposes a set of guidelines to define and manage architecture principles. Stelzer (2010) reviews the different studies related to

Mohammad Esmaeil Zadeh 2014

EAPs and formulates his own definition: “Enterprise architecture principles are fundamental propositions that guide the description, construction, and evaluation of enterprise architectures” (ibid., p. 19). Aier et al. (2011) study different approaches to defining EAPs and propose a meta-model for defining them.

TOGAF, in the beginning of its chapter about EAP, defines principles as: “general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission” (TOGAF, 2012, p. 235). Meanwhile, in its definitions chapter, an Architecture Principle is defined as: “A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale and a measure of importance” (TOGAF, 2012, p. 22).

Greefhorst and Proper (2011) assert that EA is an integral part of the governance of an enterprise and its transformation. As any normative principle limits the freedom in designing an artefact, the authors emphasise that architecture principles limit the design freedom too. They regard EAPs as pillars that support the transition from strategy to design. Based on this viewpoint, these authors define an architecture principle as:

“A design principle included in an architecture. As such, it is a declarative statement that normatively prescribes a property of the design of an artefact, which is necessary to ensure that the artefact meets its essential requirements.” (Greefhorst & Proper 2011, p. 44)

In this definition, principles prescribe a property of the design of an artefact, and that the artefact must meet its essential requirements. These features are essential requirements in the new definition of EAPs, which will be given in this section.

2.3.4.2 Sets of principles

Some sources propose sets of EAPs as references to be used by practitioners. Usually, they give only some examples of EAPs, not a complete set to cover all aspects of the EA. In our search for collecting the existing sets of EAPs, we found that a commonly used collection of EAPs is the example set in TOGAF (2012), which is usually adapted and customised by organisations to meet their specific requirements. Another collection is the set documented in the US Government's Federal Enterprise Architecture (FEA, 2001). Greefhorst and Proper (2011) also propose a set of principles based on an

Mohammad Esmaeil Zadeh 2014

extensive study of real-world architectures. In our search for finding samples of existing EAPs, we have also collected hundreds of lists of principles. These principles range from high-level enterprise-wide principles to very specific technical prescriptions concerning networks and databases. Beside the fact that the scope and diversity of the range of principles could be the result of different views that different people have in different situations, it also might be a consequence of the lack of standard, universal definitions of EA and EAPs (Esmaeil Zadeh et al., 2012a).

Just as there is ambiguity in using the term architecture, so there is ambiguity in the use of architecture principles. In different sources, many principles are proposed as EAPs. However, much work is needed to classify, and so tidy, the existing principles (Stelzer, 2010). As an example, Figure 2-2 illustrates such a classification schema, which is derived from the investigation on the existing principles. It summarises the different uses of principles in an enterprise. Examples of principles can be found in each area, including the overlapping areas. For example, the principles in ISO/IEC 38500 (ISO/IEC, 2008) are about the corporate governance of IT, which lie in the area between IT principles and governance principles. Although existing EAPs can be assigned to different sections of this figure, most of them must be positioned as enterprise IT architecture principles; including different sub-areas such as principles of application, data, technology, or security.

Figure 2-2- Classification of areas of application of principles

Mohammad Esmaeil Zadeh 2014

2.3.4.3 Problems with current definition

Apart from the variety and diversity in the definitions of (EA) principles, what can be concluded apparently from the given definitions is that each of them specifies some aspects of the work, and none of them can cover all the mentioned features of EAPs and their important role in the definition of EA. These definitions also suffer from inability to be used as a basis for the systematic derivation of a set of comprehensive principles. Furthermore, the existing definitions are not a suitable basis for categorising existing principles, and more importantly, checking whether a set of principles are complete and comprehensive. There is a need, therefore, for a new definition that integrates all the features of EAPs into a complete, comprehensive and compact definition. Moreover, if this definition uses the outcomes of related fields of IS, it may be possible to use those fields for the development and classification of EAPs. In the next section, after explaining values and different issues about them, a new definition of EAPs as values will be proposed.

2.3.5 How EA principles should be defined

From the preceding description of principles, it can be observed that they guide the design of resources so that they are integrated efficiently and aligned effectively with the organisation's needs. They are guides for sound behaviour - they are values. They describe what is required for the ideal system. Any shortfall in a principle is a risk (Lewis, 2013).

2.3.5.1 Values

In the literature, values are usually understood as important and enduring beliefs and ideals shared by the members of a culture about what is good or desirable or what is not (Business Dictionary, 2012). According to Boar (2001, p. 146), “values describe what the business believes in”. He mentions that values are important for success as the root system for staff behaviour and the basis for autonomous action and decision-making.

Values have great application in defining the strategy and strategic planning of an organisation. These values, also known as core values, prescribe the attitude, behaviour, and character of an organisation (Kaplan & Norton, 2008). The importance of values in decision-making is also emphasised by Keeney (1992), as the very focus of thinking. In

Mohammad Esmaeil Zadeh 2014

his opinion, values are what we care about, and therefore, should be the driving force for decision-making. He asserts that values are indicated by ethics, desired traits, characteristics of consequences that matter, guidelines for action, priorities, value trade- offs, and attitudes toward risk.

The word ‘value’ is also used in a more limited but related sense in IT governance. Value creation and value preservation are regarded as the primary purpose of a system of governance (Lewis & Miller, 2010). Value delivery is one of the focus areas of IT governance (ITGI, 2007). Within the VAL IT (2006, p. 10) framework, value has a quantitative definition: “… the total life-cycle benefits net of related costs, adjusted for risk and (in the case of financial value) for the time value of money”. However, it is also mentioned that the nature of value can be different for different types of enterprises and in some cases, such as for the non-for-profit enterprises, value may be non-financial (such as improvement in the quantity and quality of services to beneficiaries of charities). The replacement of VAL IT, COBIT 5 (ISACA, 2012a), emphasises that the governance objective is stakeholder value creation.

Keeney (1992) proposes values as principles for evaluating the actual or potential consequences of action and inaction, of proposed alternatives, and of decisions. Here, values are regarded in the sense of evaluation, not the more limited sense of moral values. This use of values is close to the concept of requirements in requirement engineering (Robertson & Robertson, 2006), and therefore, may be referred to as required value. Required values are used to describe what is wanted from systems ideally. Values can be expressed as a single word (e.g. Accountability) or as an imperative expression (Be Honest!) or as a complete sentence (Clients can determine their entitlement to benefits without reference to a member of staff).

The Institute of Value Management (IVM, 2012) posits that “the concept of Value is based on the relationship between satisfying needs and expectations and the resources required to achieve them.”

Tweedie (2007) claims that mistakes in values are responsible for expensive remedies or complete failures of system. Over 50% of Information Systems are deemed to be unsuccessful (Standish Group, 1994; subject to the criticisms of Evaleens & Verfoef, 2010), because they were over time, over budget, or under expectations. Failures in time

Mohammad Esmaeil Zadeh 2014

or budget reflect problems of project management, which can be made complicated by shifts in user values, or requirements creep. Failures in expectations can be caused by values being determined inadequately in the first place, or by changes occurring in values, often as users gain experience with the capabilities of Information Systems.

One of the factors for the success of a system is the set of values that reflects, as much as possible, the wishes and wants of the range of people influencing the system plan or influenced by the plan. Determining values is not about getting values right; it is about getting the right values. With inappropriate values, you can make a Type III error: Provide A Good Solution to the Wrong Problem (Lewis, 2013).

In this paper, values are a complete, precise, and accurate list of the needs of all of the people involved in the planning process (Lewis, 2013). These needs could be for a system that provides support for well-defined, concrete functions. The needs could be for a system that does not exceed a budget. Finally, the needs could be for a system that is comfortable to use. That is, values describe the effectiveness, efficiency, and acceptability of a system.

2.3.5.2 Definition of a required value

The intent of a required value is to describe the ideal - what is wanted from the best system. Values form the objectives of the system and the constraints determining how the system will be planned. Our preferred definition is:

A description of performance that is necessary to ensure that the operation of a system achieves its goals, meets the wishes of all those concerned, or uses its assets efficiently.

2.3.5.3 Types of values

The description of values given earlier shows that there are many types of values, which are classified in several ways in the literature. However, there is a classification of value that incorporates all of these different types. This classification is shown in Table 2-3, where the values are grouped as six fundamental questions (Lewis, 2013).

As emphasised in the application of values in strategic planning, the value of a plan (such as an EA design) should be judged according to three outcomes: achieving effectiveness for the enterprise, meeting the wishes of those influenced by or influencing

Mohammad Esmaeil Zadeh 2014

the plan, and being efficient in the use of resources. A shortfall in any one of these outcomes will lead to difficulties in implementing the plan– they are risks (Lewis, 2013).

Table 2-3- Classification of values

Fundamental Type Attribute Question

Achieve – Capability – providing required features Will it work? effective in what is done Capacity – providing required amounts Will it work enough?

Will people be Wishes – Suitable – conform to formal rules acceptable in allowed to use it? how things are Satisfactory – conform to informal Will people want to done practices, pleasing use it?

Efficient – Sufficient – providing enough resources Can we afford it? minimising for the task resources whilst Safe – not wasting resources in recovering still being Is it safe? effective from mistakes or disasters, security

2.3.5.4 Principles as values

If the aforementioned discussions about principles and values are compared, many similarities can be found in their definitions, sources, applications, and usage. Sometimes, they are used interchangeably. Some sources use values to define principles (Greefhorst & Proper, 2011); some use principles for the definition of values (Keeney, 1992).

Principles are values. Both words can mean required behaviour (as in strategy) and both can mean having high standards of moral or ethical behaviour (as in policy for acceptable behaviour). However, these words are often used as if they are separate things. Here they are used to mean the same thing; in that principles are a particular type of value - ones that are set up to apply in most cases, regardless of changes in stakeholders or in pressures upon them from the external circumstances and internal conditions. Based on this, a new definition of principles can be given as:

Principles are values that generally apply.

Mohammad Esmaeil Zadeh 2014

Values, and hence principles, have different priorities and they can conflict, because they represent the wants of different points of view. As do principles (see Section 2.3), values reflect the external circumstances and internal conditions of an enterprise. Accordingly, what might be pertinent for one organisation at one point of time might not be pertinent for some other organisation or at another time. However, they are expressed generally enough to provide a guide to sound behaviour in most organisations most of the time.

By this definition, principles are the values forming the edicts (or official orders) that control how we should act in general. They could be generally applicable constraints upon behaviour so that it is effective, efficient and acceptable. This means that discussions about the types of values can be used to classify principles under the general titles of effectiveness, acceptability and efficiency (Table 2-3).

2.3.5.5 Resultant definition of EAPs

EAPs are principles of EA, or principles for the architecture of the enterprise. Therefore, the above definition of principles can be customised for EAPs as:

EAPs are values that generally apply to the architecture of an enterprise

This definition uses the terms of architecture, enterprise, and values, which have already been defined. However, it does not consider the difference between an architecture and its design as described. It can be expanded further by applying the previous discussions about EAPs, specifically by using their main purpose for the design.

Some authors debate the differences between architecture and design (Greefhorst & Proper, 2011; Hoogervorst, 2009; Nightingale & Rhodes, 2004), but as Aier et al. (2011) mention, it is accepted that design is the main purpose of principles, such that sometimes they are regarded as Enterprise Architecture Design Principles. As mentioned in Section 2.3, EAPs have a pivotal role in the design and development of organisations. This role is clearly obvious in the definition of EA by Hoogervorst (2009, p. 291): “a coherent and consistent set of principles and standards that guides enterprise design”. They are bridges from strategy to design, specifically for constraining the design freedom in organisational transformation (Greefhorst & Proper, 2011). Also in the definition of architecture in TOGAF, the purpose of principles is implicitly mentioned as governing

Mohammad Esmaeil Zadeh 2014

the design and evolution of the component and relationships. Based on this, and the definitions of EA, a more detailed definition of EAPs will be:

EAPs are values that generally apply to the design and development of the architecture of an enterprise.

As explained before, definition and classification of principles are part of their development, and therefore, this new definition constitutes the first step in the development of EAPs. This definition covers the important items in the definitions given by the various authors, while it brings together different views about principles, values, and their related fields: helping planners and architects to have a better understanding about the notion of EAPs and to use the advances that have been made in the field of values for the development and classification of EAPs.

Moreover, regarding principles as values enables EAs to check which are missing and to determine which should be emphasised in a set of EAPs. As an example of the use of this definition of EAPs, in Chapter 6 it will be shown that the business principles in the example set of TOGAF (2012) can be classified based on the types of values explained in Table 2 -3. A more detailed investigation of the usability and usefulness of this new definition of EAPs are left to be done as a future study.

2.4 Derivation of principles

2.4.1 How EAPs are derived now

TOGAF (2012) notes that a good set of principles will be founded in the beliefs and values of the organisation. TOGAF proposes that architecture principles be developed by the enterprise architects, in conjunction with key stakeholders, and are approved by the Architecture Board, which is “typically a group of executives responsible for the review and maintenance of the overall architecture” (TOGAF, 2012, p. 553). Some authors also propose developing procedures for the creation, implementation and use of EAPs (Greefhorst & Proper, 2011; Weiss, 2006).

The alignment between architecture and implementation of the Target Architecture with business strategies and visions is an important key in defining principles in TOGAF. Specifically, the following sources for developing the architecture principles are

Mohammad Esmaeil Zadeh 2014

highlighted: enterprise mission and plans, enterprise strategic initiatives, external constraints, current systems and technology, and computer industry trends. Proper and Greefhorst (2011) also assert that architecture principles are motivated from the goals and objectives embedded in the strategy. They propose the following types of drivers for the formulation of architecture principles: goals and objectives, values, issues, risks, constraints, and potential rewards (Greefhorst & Proper, 2011). Accordingly, EAPs are derived from business objectives and, as will be seen, other values. Figure 2-3 shows their conceptual framework for motivating architecture principles. As this figure clearly indicates, their work is mainly about classifying principles and testing their types, rather than deriving them systematically.

Mohammad Esmaeil Zadeh 2014

Figure 2-3- Greefhorst and Proper (2011) conceptual framework for motivating EAPs

Mohammad Esmaeil Zadeh 2014

2.4.2 Problem with current derivation

As part of the literature review, we have searched for existing sets of EAPs, and we have found and collected hundreds sets of them. Although there are many lists of principles, it is not clear where they come from. Theoretically, they come from heuristics based upon experience or theory and this is why these lists are incoherent and disorganised. This also goes back to the fact that there is not a theory for deriving them. There is still the strong need for a theoretical basis for deriving a set of EAPs systematically, and checking their completeness and comprehensiveness.

2.4.3 How EAPs should be derived

As mentioned before, principles play an important role in design and decision-making in different aspects of the organisation. Developing a good set of principles is fundamental in EA, as it will redirect behaviour in the enterprise (Weiss, 2006). On the other hand, “a poor set of principles will quickly become disused, and the resultant architectures, policies, and standards will appear arbitrary or self-serving, and thus lack credibility” (TOGAF, 2012, p. 237). It is important that EAPs are clearly formed so they can be used properly.

In the literature, there are several specifications for a good set of principles. TOGAF emphasises that principles should be few in number, future-oriented, and endorsed and championed by senior management. A good set contains principles that are understandable, robust, complete, consistent, and stable. Schultz (2007) also mentions that in designing principles the following criteria must be kept in mind: simplicity, consistency of interpretation, relevancy, stability, flexibility, and granularity. Greefhorst and Proper (2011) summarise different lists as the SMART criteria: specific, measurable, achievable, relevant, and time framed. They mention that in addition to the criteria for individual architecture principles, a set of principles must also be representative, accessible, and consistent. None of these authors proposes a systematic approach for checking an EAP or a set of EAPs against these criteria.

Besides the criteria for the quality of EAPs, it is advocated that EAPs be represented in a common format. Most of the literatures agree in the description of principles as follows:

- Name - an easily remembered, specific, essence of the principle

Mohammad Esmaeil Zadeh 2014

- Statement - succinct description of the rule that can be used in the same format (i.e. without change) by most organisations

- Rationale - benefits of using the principle, in business terms; including relationships with other principles and priorities between principles

- Implications - resources required to carry out the principle; consequences of using the principle (beyond benefits)

Some other sources also suggest the addition of measures (Lindstrom, 2006), metrics (PEAF, 2011), or key actions (Hoogervorst, 2008) to the structure of principles. Greefhorst and Proper (2011) also use type of information and quality attributes in the representation of their example set of EAPs.

There is a need for EAPs to be formed according to many criteria but, as yet, there is no approach for doing so.

2.5 Application of principles

2.5.1 How EAPs are used now

Although the role of EAPs in designing organisations is becoming clearer, their actual implementation has not been considered appropriately in the literature (Greefhorst & Proper, 2011) and very few organisations consistently apply and manage them (Aier et al, 2011). There are some suggestions for the use of principles for assessing compliance of projects adhering to EA (Foorthuis et al, 2012) but there is a need for guidelines for putting principles into practice. The literature is very weak about the proper application of principles and this implies the need for systematic work in this field also.

2.5.2 How EAPS should be used

Developing a good set of principles is insufficient without proper acceptance and usage of them. Principles can be used in the governance (that is, control) of both the

Mohammad Esmaeil Zadeh 2014

development and implementation of the architecture (Weiss, 2006). During the development process, principles are needed to guide the development, maintenance and use of the EA (Weiss, 2006). The second use of EAPs is during the implementation of EA, as a guiding foundation for the design and development of the systems within the architecture. In both cases EAPs can be used as a means for suggesting remedies to design risks or as a means for measuring performance. They are used in different levels of the organisation: as a foundation for strategy, in developing policies, and in forming measures.

The use of principles as the foundation of strategy is best described in Broadbent and Weill (1997). They define maxims as statements that indicate a practical course of conduct to be chosen, derived from the corporate strategic planning. Their maxims can be used as the basis for making strategic decisions about IT infrastructure. They are guiding desired, strategic behaviour for the business. From them, managers can bring out maxims for the use of IT; that is, the principles for IT strategy and, in turn, the EA that enables the strategy.

Some other applications of EAPs are in the development and implementation of the reference architecture, assessment of the architecture compliance, decision-making, product selection, and balancing the usage of conflicting requirements (Weiss, 2006). Principles can also be used to guide the development of policies (Petersen, 2004). They must be used during projects and design as part of the EA assurance process (Weiss, 2006). Principles can be used as a foundation for supplying guidance, constraints, best practices, and criteria in decision making (Schultz, 2007). Moreover, in the governance of decisions, principles can define the control attributes of the decision-making process (Schultz, 2007).

Principles can also be de-composed into more detailed measures. The measures should become lead indicators; that is, they should describe as precisely and accurately as necessary whether a system will perform as required and whether business goals are met (Lewis, 2013). In this way, principles can be used to evaluate proposals for strategy or check that policies are being followed.

Some principles apply in some circumstances, but not in others. Principles can conflict with each other. In some circumstances one principle applies; in another circumstance its

Mohammad Esmaeil Zadeh 2014

opposite could be more pertinent. Accordingly, the priorities for principles should be set with the particular internal conditions and external circumstances of the system in mind. Greefhorst and Proper (2011) also assert that conflict between EAPs should be detected during the selection stage, and be handled by the use of priorities.

In addition to where principles are used, it is also important to know how they are applied. Based on their conceptual model and real-world experiences, Greefhorst and Proper (2011) also propose a valuable practical process for handling architecture principles. The process, shown in Figure 2-4, starts with the determination of the drivers, which are the foundation for architecture principles, followed by the subsequent sub- processes in which the architecture principles themselves are determined, specified, classified, validated and applied. They are also used as the primary enablers for an effective architecture governance to determine whether projects comply with the architecture. The final sub-process intends to handle changes to the architecture, which may restart the initial sub-process.

Figure 2-4- Generic process for handling architecture principles (Greefhorst & Proper, 2011)

Mohammad Esmaeil Zadeh 2014

2.6 Gap between what we need to know and what we do know

This chapter started our journey by specifying the need for action and reviewing the existing literature in the field of EAPs. As a summary of what has been realised up to now, the existing literature shows that EAPs are an important element in the development and implementation of EA, and this importance has brought their concept into prominence in recent years. However, despite the effort made in academic and professional literature, this notion is still in its infancy and suffering from some fundamental deficiencies. There are a large number of principles in different sources introduced as EAPs but there are no established criteria for their classification or for checking their validity. The source of these problems can be related to the ambiguity in the definition of EAPs and the lack of a theoretical basis for developing and classifying them. Work is needed to overcome the current limitations in the definition and formation of EAPs. Moreover, there is still a lack of a set of generic EAPs and a theoretical basis for developing them. This problem also exists in the actual implementation and application of EAPs and there is a need for guidelines for putting principles into practice. All of these imply need for a systematic consideration of principles.

2.7 Research objective

Based on what has been reviewed and the gap between what we know and what we should know about the definition, derivation and implementation of EAPs, it can be concluded that the main question in this research would be:

Is there a theoretical basis for systematic development of EAPs, and principles of IM in general?

At the first glance, this research question seems to be a Yes-or-No question. However, as explained in this chapter, the process of development includes definition, derivation, formulation, classification, and usage of principles. Therefore, considering this question as a research question for a PhD program implies answering the following questions too:

- What theoretical basis is suitable to address different aspects of developing principles of IM?

Mohammad Esmaeil Zadeh 2014

- Why this theoretical basis is selected for this research?

- How can this theoretical basis be deployed to develop principles?

- How can the resultant method be tested and validated?

Therefore, these questions lead to the following more complete question:

How can a theoretical basis be found and deployed for systematic development of EAPs, and principles of IM in general?

Since the main application of principles in IM is in EA, this chapter investigated the context of principles of EA in more details by reviewing what is known about them and what limitations they suffer from. As a start to overcome these limitations, new definitions of EA were presented. These definitions cover the new ideas about EA, which is the planning of all resources in an organisation. After that, we studied different issues in the cluttered field of EAPs and related them to the concept of values. Based on this, a new definition of EAPs was proposed. The new definition shows the capacity to overcome some of the problems from which EAPs have been suffering.

The new definition shows how some concepts of governance and architecture overlap, and therefore, it can be used as a foundation for discussing the relation between governance and EA. In addition, the results of the more developed theories of governance can be used in developing EAPs.

It is now the time to check whether these propositions can be a foundation for applying sound theories, such as cybernetics, in developing a categorised, cohesive set of EAPs.

If principles are values, then they can be derived in the same way as values. That is, they can be based upon the analysis of effects of external circumstances and internal conditions, including the concerns of stakeholders, upon the performance of a system (Lewis, 2013), such as an EA. This analysis should draw upon the cybernetic concepts of control, feedback, requisite variety, and recursion, as suggested by Esmaeil Zadeh et al. (2012b). That is, cybernetics could provide a basis for deriving EAPs. Therefore, we can define the research objective of this thesis as:

Using cybernetic concepts to develop methods for deriving a set of comprehensive EAPs.

Mohammad Esmaeil Zadeh 2014

From these statements of the research question and research objective, it can be concluded that the actual goal of this thesis is to find methods for developing a set of principles of EA and IM, using the concepts of cybernetics, particularly those embedded in the VSM. A more detailed discussion about methods as the final artefacts of this research is presented in Chapter 4.

Based on this objective, in the next chapter, we will review the concepts of cybernetics, especially the Stafford Beer’s Viable System Model (VSM) as the theoretical basis for this research.

Mohammad Esmaeil Zadeh 2014

[this page is intentionally left blank]

Mohammad Esmaeil Zadeh 2014

Chapter 3 Theoretical Basis

3.1 Introduction

In previous chapters it was mentioned that the EA discipline suffers from lack of a theoretical basis to develop a set of generic principles. Aiming to use the cybernetic concept as the theoretical basis for deriving EAPs, in this chapter some concepts of cybernetics, especially those embedded in the Stafford Beer’s Viable System Model (VSM), are explained. System thinking and the VSM have been shown to be powerful tools in designing viable organisations. The VSM is a blueprint or template for designing viable organisations (Beer, 1984; Hoverstadt, 2008). Similarly, in some earlier definitions, EA is regarded as the blueprint for the architecture of an organisation; for example:

“EAs are blueprints for systematically and completely defining an organization’s current (baseline) or desired (target) environment.” (FEA 2001)

As it is shown in Chapter 1, the VSM is recently used in EA and IM disciplines in several pieces of works. However, none of the above studies used the VSM as a conceptual framework for developing principles of EA and IM. Therefore, the main concepts of cybernetics and the VSM are explained here to find out whether the VSM can be used as the theoretical basis in this research.

3.2 Cybernetics

Originally, cybernetics is defined as the science of communication and control in animals and machines (Wiener, 1948). In the managerial context, the emphasis of this

Mohammad Esmaeil Zadeh 2014

word shifts onto the word governance (Beer, 2002). That is, in contemporary usage, cybernetics refers more broadly to the study of control and communication in systems, including socio-technical systems such as organisations. When applied to organisational systems, it is referred to as the science of effective organisations (Hilder, 1995). Skyttner (2005) provides a comprehensive list of the most common principles of cybernetics and system thinking. Among these principles, Ashby’s law of requisite variety (Ashby, 1956) is very influential in organisation theory (Beer, 1979; Hilder, 1995; Millar, 2009).

3.2.1 Variety

The term “variety” is used in system science as a measure of complexity (Christopher, 2007). To handle the complexity of something, we need to know the parts and relations constituting it, or the number of behavioural distinctions we make in it (Espejo & Reyes, 2011). In a system, variety measures complexity by counting the number of possible states within it (Beer, 1985). In practice, it may not be possible to precisely count all the possible states of the environment; however, the concept of complexity can be expressed by comparative statements (e.g. a high variety environment), or can be manipulated by probabilistic methods (Christopher, 2007).

The variety of a system depends on the context in which it is embedded, and also on who is observing that system (Hilder, 1995). Contemporary organisations are embedded in complex, dynamic environments. Therefore, in order to cope with substantial variety, organisations need variety attenuators to reduce or filter the variety arising from the environment (Hilder, 1995). On the other hand, the organisation needs to deploy variety amplifiers to amplify its own variety, in order to increase its influence over the environment. Figure 3 -1 highlights the three essential elements of the VSM: environment, operations and management, each embedded within the other. In this figure the circle and the attached square represent operation and its local management functions respectively. The environment cloud, which is not known completely by the system, is represented by the cloud, in which the organisation (system) is embedded. “Since management is embedded in its operations, most of its interaction with the environment is via its operations (Beer, 1979). Management may also have direct channels to the environment (dotted line), but these links are for the purposes of adaptation rather than

Mohammad Esmaeil Zadeh 2014

regulation” (Millar, 2009, p.40), and therefore is connected to the management by a dashed line to show their indirect transaction.

Figure 3-1- The concept of variety, amplifier and attenuator (Beer, 1985)

3.2.2 Requisite Variety

Based on the concept of variety is Ashby’s Law of Requisite Variety, which states that: “Control can be obtained only if the variety of the controller is at least as great as the variety of the situation to be controlled” (Ashby, 1956). In short, only variety can absorb (or destroy) variety (Ashby, 1956). When applied in an organisational context, the law stipulates that an organisation must exhibit sufficient capacity (variety) to match the potential environmental states that may impact its purpose (Millar, 2009). An organisation lacking the requisite variety to deal with relevant environment variety would be unable to respond and adapt to unforeseen shifts in the environment. As a consequence, the organisation’s long term viability would be put in jeopardy (Beer, 1985).

Ashby’s Law of Requisite Variety is a very potent principle in cybernetics and especially in deriving the VSM. Once understood, this law is usually said to be obvious (Hilder, 1995). However, this law must be considered precisely in designing units and

Mohammad Esmaeil Zadeh 2014

their relationships in a viable organisation, rather than being regarded only as a statement of a law of nature.

3.3 The Viable System Model

Applying the laws and principles of cybernetics, especially the Law of Requisite Variety, to the design of effective organisations, Stafford Beer formulated the VSM as a blueprint for designing organisations that are able to survive and thrive in a changing environment (Beer, 1972, 1979, 1984, 1985). The VSM is a “neurocybernetic model” (Leonard & Beer, 1994, p. 47): which “draws upon research on the human nervous system, especially on the brain”. The VSM integrates into a coherent framework an array of cybernetic concepts, including: feedback, communications, variety, recursion, viability, autonomy, autopoiesis, self-regulation, self-organisation, and learning (Millar, 2009).

The model comprises five main functions or systems: Policy, Intelligence, Control, Co-ordination, and Operations. Beer labelled these management functions Systems 5 to 1 respectively. A sixth function, Audit, is labelled 3* to indicate that it is a sub-system of System 3. These six functions (or systems) are linked through a series of communication channels or information flows. The VSM is schematically represented in Figure 3 -2 and will be explained throughout the following sections of this chapter.

Mohammad Esmaeil Zadeh 2014

Figure 3-2- The Viable System Model (VSM) (Beer, 1985)

The five systems of the VSM represent the five invariant functions of a viable organisation; they do not necessarily represent discrete organisational groupings or units. This means that the VSM is a structure of functions, not titles (Christopher, 2007). Two or more functions may be carried out by the same individual or unit. However, they MUST be carried out if the organisation is to remain viable (Hilder, 1995). This also requires that every element of the system be aware of when it is working in its home system and when it is working in another system. “The VSM gives us an excellent guide for clarifying what needs to be done, and where. Titles and job assignments follow from that” (Christopher, 2007, p76).

Before going through the different systems of this model, there are some general concepts that must be considered. These concepts, which are fundamental in the construction of viable systems, are Viability, Recursion and Black Box.

Mohammad Esmaeil Zadeh 2014

3.3.1 Viability

As described above, VSM is based on the concept of viability - maintaining separate existence; surviving on its own (Beer, 1979). The first purpose of any system, including business systems, is to maintain viability; to continue to exist in its environment (Christopher, 2007).

Although survival is a precondition of the achievement of other more meaningful organisational purposes, it should not be interpreted in the limited sense of merely existing. An organisation is not brought into being by its creators for the sole purpose of surviving (Millar, 2009), but to achieve “some purpose or outcome that is meaningful to its original founders or current stakeholders” (Christopher, 2007, P39). The purpose of a viable business system is to create and keep customers by offering products and service values satisfying and exceeding their expectations (Christopher, 2007, P59): “Purpose might be stated in terms of market position, some level of organization development, some level of quality/productivity, some level of innovation, some basic level of profitability. However stated, purpose needs an emphasis on creating value for customers.”

The purpose (what we do) also defines the identity (who we are), as Hilder (1995, p41) emphasises: “The ability to maintain identity is related to the fact that self- organizing systems have purposes. These purposes provide the framework for their maintenance of identity. Lack of purpose is usually indicative of the impending collapse of a self-organizing system.” Effectively, the identity was the purpose and you could understand one by knowing the other (Hoverstadt, 2008, p251): “For all practical purposes, managers could take identity for granted as long as they understood the purpose of their organization. This approach goes back to Aristotle – ‘I am what I do’.”

The criterion of viability implies that an organisation be able to sustain its existence in a changing environment through its capacity to learn and adapt (Beckford, 2002). This means that in order to survive the organisation needs the capacity to maintain its stable operation over time (that is, to respond to familiar disturbances), and also the capacity to respond to unanticipated situations (Espejo & Reyes, 2011). Organisations are considered to be viable if they are ultra-stable, that is capable of adapting appropriately

Mohammad Esmaeil Zadeh 2014

to their chosen environment, or adapting their environment to suit themselves (Hoverstadt, 2008). Beer (1981, p.239) asserted that an organisation based on the VSM has the “mechanisms and opportunities to grow and to learn, to evolve and to adapt – to become more and more potent in its environment”. In fact in an increasingly competitive, complex world, surviving should not be construed in the narrow sense of merely existing: surviving involves learning, adapting, and growing (Lewis & Millar, 2010).

3.3.2 Recursion

Another defining feature of VSM is its recursive nature. Stafford Beer’s Recursive System Theorem states that: “in a recursive organizational structure, any viable system contains, and is contained within, a viable system” (Beer, 1981, p.228). This means that the VSM has a fractal structure, in which systems are made of sub-systems that have the same generic organisational characteristics (Hoverstadt, 2008). For example, a large company is typically composed of strategic business units that are viable systems in their own rights, and is embedded within an industry which is also a viable system (Millar, 2009).

This fractal structure of the VSM helps the organisation to better deal with the complexity of both its environment and its own activities (Hoverstadt, 2008). In fact, the recursive structure of the VSM “provides a vast attenuator of the huge variety in the structure and operations of any large company” (Christopher, 2007, p.20).

Since the embedded, or contained, viable systems are precise replicas of the containing viable system, they have the capacity to deal with the complexity inherent in their “local” environments, which are sub-sets of the environment of relevance to the containing system (Millar, 2009). That is, the embedded system attenuates the variety that needs to be managed at the next higher level of recursion. Furthermore, by putting in place “local” management, the variety of the organisation is amplified with respect to its environment (Jackson, 2003). In recursive structures, therefore, most of the complexity is managed locally in each of the components and only a small residual complexity is required to be handled by senior management (Espejo & Reyes, 2011).

Mohammad Esmaeil Zadeh 2014

The fractal structure allows us to model and understand organisations of any size in any industry sector and of any degree of complexity (Hoverstadt, 2008). In these structures the same mechanisms are replicated at each level and in each of the sub- systems and sub-sub-systems that we revealed in the unfolding of complexity (Hoverstadt, 2008). Therefore, by distributing responsibilities and accountabilities throughout the organisation, and using individuals’ talents and capabilities, recursive structures enhance problem solving at all structural levels and “ensure that each autonomous unit at each structural level is fully aware of the short, medium and long terms” (Espejo & Reyes, 2011, p85). This also means that decision-making is a multi- level activity and allows strategy to be built up through the organisation as a series of conversational processes between different levels (Hoverstadt, 2008).

3.3.3 Black box

Usually the senior managers are unable to obtain information about all the possible states (variety) of the embedded systems, for which they are ultimately responsible. Therefore, they cannot intervene within lower level operations (Christopher, 2007) or as Skyttner (2005, p.79) expressed: “command of total information is seldom possible or even desirable”.

The question now arises: how can senior management effectively manage the embedded system? The answer lies in the cybernetic concept of the “black box”. This concept, when used in conjunction with that of recursion, provides a potent recipe for managing organisational complexity. Stafford Beer’s First Regulatory Aphorism states: “It is not necessary to enter the black box to understand the nature of the function it performs” (Beer, 1979, p40). In general, all those who are outside an operational unit, including the higher management and the environment, don’t have the requisite variety to handle the variety of operation of that unit. Therefore, they do not need to know exactly how the things are done inside the black box; they just need to know what goes into it –resources (people and capital), materials inputs, purpose, and information-, what goes out of it, and what the relations between the inputs and the outputs are (Christopher, 2007).

Mohammad Esmaeil Zadeh 2014

3.3.4 Organisational principles

Intending to develop a ‘science of organization’, Stafford Beer sets down “the principles that underpin all organizations, and create viability, which is the capacity to exist and thrive in sometimes unpredictable and turbulent environments” (Hoverstadt, 2008, p27). Stafford Beer developed the VSM based on the Law of Requisite Variety. In Diagnosing (Beer, 1985), Stafford Beer uses only the law of Requisite Variety and deductive reasoning to derive the VSM and all other organisational principles (Millar, 2009). In this thesis, there is no need to go through the details of deriving these principles. However, they are listed below for future reference:

The First Principle of Organisation: “Managerial, operational and environmental varieties, diffusing through an institutional system, tend to equate; they should be designed to do so with minimal damage to people and to cost” (Beer, 1979, p.97)

The Second Principle of Organisation: “The four directional channels carrying information between the management unit, the operation and the environment must each have a higher capacity to transmit a given amount of information relevant to variety selection in a given time than the originating sub-system has to generate it in that time.” (Beer, 1979, p.99)

The Third Principle of Organisation: “Wherever the information carried on a channel capable of distinguishing a given variety crosses a boundary, it undergoes transduction; and the variety of the transducer must be at least equivalent to the variety of the channel.” (Beer, 1979, p.101)

The Fourth Principle of Organisation: “The operation of the first three principles must be cyclically maintained through time without hiatus or lags.” (Beer, 1979, p.258)

It is very important to note that these principles of organisation are intended to provide guidelines for the practical design of human organisations, rather than being statements of a law of nature (Hilder, 1995).

Mohammad Esmaeil Zadeh 2014

3.4 Systems of the VSM

3.4.1 System 1- Operation

The fundamental operation(s) within a viable system is referred to as its System 1: “In very brief, the first subsystem of any viable system consists of those elements that produce it. ... These elements are themselves viable systems” Beer (1981, p. 14). That is, System 1 is at the core of the model and consists of embedded systems that actually perform the activities of the system-in-focus (Millar, 2009). Since this system “implements” the system-in-focus it is also referred to as the “Implementation” function (Millar, 2009). By producing products and services at different levels of aggregation, System 1 units contribute directly to the value chain of the organisation, which implements its overall purpose (Espejo & Gill, 1997). Therefore, these primary activities, implied by the organisation’s identity, deliver the product or service that the organisation exists in order to provide (Hoverstadt, 2008). Without System 1, there would be no reason for the organisation to exist (Hilder, 1995).

System 1 also includes the managements of its operations (Christopher, 2007). It does not include senior management, which should be considered as a set of services to System 1 (Hilder, 1995). In the VSM, the senior management comprises Systems 2 to 5 and is called meta-system, shown by the large dotted square in Figure 3 -2. A meta- system is one that sits above a system in the hierarchy of control; that is, it is the control system of the system of interest (Flood & Carson, 1993).

There may be more than one System 1 in the organisation. The number of System 1 units depends on the nature of the particular organisation under investigation (Millar, 2009). This is the start of the modelling process to unfold the “primary activities” of the organisation (Hoverstadt, 2008) which leads to determining System 1 units (Christopher, 2007). The best way to determine what constitutes System 1 units is to consider what the system does (i.e., its purposes) and then to identify the units that directly “do” these activities (Brocklesby et al., 1995). It is a common mistake to simply identify the departments listed on the organisational chart (e.g., IT, Sales, Engineering, etc.) as the operational units. As Christopher (2007, p.46) says: “Defining these viable businesses involves much more than selecting boxes from the traditional organisation chart. A

Mohammad Esmaeil Zadeh 2014

viable business system: (1) offers products and services to customers in the marketplace, (2) has an operations structure for providing and marketing those products and services, (3) has the management needed for the above.”

In developing the Viable System Model of the company, defining the System 1 units becomes a task for top management that requires a lot of thinking, creativity, and testing (Christopher, 2007). In order to determine System 1 units, the primary activities of the organisation must be determined, and broken down into their constituent sub-activities (Hoverstadt, 2008). These sub-systems are responsible for carrying out the value-adding tasks of the system-in-focus. (Espejo & Gill, 1997) The unfolding process is generally stopped at the point where a small team of people is responsible for a complete work task (e.g. a manufacturing cell). In theory at least, an operational unit could be extracted from its containing system and still survive in its given environment (Brocklesby et al., 1995). The VSM is a recursive model. This recursive nature of viable systems necessitates that operational units are granted maximum autonomy. Operational units exhibit all the features of the VSM, and therefore possess the capacity to self-organise (adapt) and self-regulate in response to environmental disturbances (Millar, 2009). In short, “the viable system 1 has the capability to exist on its own. But it doesn’t exist on its own. It is a part of the total company, with many interrelationships that make the company much more than the sum of its parts” (Christopher, 2007, p.46).

Therefore, we would expect to see most viable systems, at whatever structural level they occur, containing further sub-systems as a way to help them handle the complexity of their environments (Christopher, 2007). System 1 units are given the capacity to absorb much of the variety exhibited by their local environments, and therefore they should be granted the freedom to respond to environmental changes according to their own priorities (Jackson, 2003). This helps the meta-system to cope with the amount of variety that reaches it. The only restriction that should be imposed on the autonomy of the System 1 units is that they must operate in a way that is consistent with the purposes of the whole organisation. Without this restriction, the organisation would lose coherence, and would fracture. In the VSM, control and autonomy are not opposites: the absorption of a subset of the environmental variety by the operational units makes the control of organisational outcomes possible (Espejo, 1989).

Mohammad Esmaeil Zadeh 2014

It must be noted that not all departments listed on the organisational chart are operational units; there are some other units that are not part of the value chain but support the main activities of the organisation, i.e. the activities of the operational units. These units (such as IT, finance, human resource, etc.) are called Service units (Beer, 1979) or Support functions (Espejo & Reyes, 2011). Support units are different from business units in two ways: (a) they do not exist to make a profit, they exist to help business units; and (b) their customers are almost always internal (Kaplan & Norton, 2006).

Care must be taken in differentiating operational units from service units. Identifying System 1 units is often problematic. Beer (1979, p.120) devotes considerable attention to the topic of how to identify operational elements since “it turns out in practice to offer the worst problems, and the most traps to intending users” of the VSM. The key in distinguishing Operational units from Service units is “viability”. By definition, embedded operational units must be viable systems in their own right; that is, capable of separate existence. On the other hand, Service units facilitate the activities of Operational units, and should not be nominated as a contained viable system. As an example, the IT department of a manufacturing firm may provide an essential service, but it does not implement the purpose of the organisation. The purpose of a manufacturer is to manufacture products, not operate information systems. The IT department facilitates operations; it does not “do” them (Millar, 2009). Given that the IT department is not an operational unit, it cannot be a viable system in its own right (Beer, 1985). As a general rule, common services that contribute to the synergy of operational units are always representative of System 3 functions (Beer, 1979).

3.4.2 System 2 - Coordination

System 2 is represented in Figure 3 -2 with triangles directing from the operational units toward higher–level management. This system, as an important regulator, provides four important functions: coordinating the action of System 1 units, budgeting and budgetary control, transducing the information flowing from System 1 units to higher- level management, and communicating corporate parameters and monitoring compliance (Christopher, 2007). Among these functions, the most important one is Coordination,

Mohammad Esmaeil Zadeh 2014

which is the main mechanism to ensure that balance between the autonomy of the subsystems and the cohesion of the whole system is achieved.

As mentioned in the previous section, System 1 units must be granted the maximum degree of autonomy provided that organisational cohesion is maintained (Espejo, 1989). “Given their freedom, operational units possess considerable flexibility in how they respond to the demands of their environments. When an operational unit uses its independence to maximise its performance, it may adversely impact other units. Examples of these conflicts might occur when two operational units compete for the same external customer or the same internal resource (Millar, 2009).

Stafford Beer (1985) had a comprehensive discussion about how these conflicting interests among the System 1 units may result in the system becoming unstable and starting to “oscillate”. A mechanism must be found to dampen the oscillations. In the VSM, System 2 performs the “anti-oscillatory” function by providing operational units with the mechanism to ensure that different activities don’t conflict with one another (Hoverstadt, 2008). This system, through its communications channel with the System 1s, anticipates and eliminates potential conflicts, and resolves them when they do happen (Christopher, 2007).

System 2 is the facilitator and the tie-breaker in resolving these conflicts. If an authority is needed, there is System 3 (Christopher, 2007). The coordination mechanism may be provided by senior management (next level of recursion/ meta-system). However, the meta-system does not command the requisite variety to resolve the inter- elemental conflict by issuing orders down the central command axis (Beer, 1985). Furthermore, any attempt to do so would constrain the freedom enjoyed by the operational units and limit their ability to respond effectively to their environments (Beckford, 2002).

On the other hand, coordination by self-adjustment is a high variety function which reduces the residual variety that must be managed by the other elements of the meta- system (Espejo, 1989). Moreover, by supporting self-regulation, this option preserves local autonomy, as Espejo and Gill (1997, p.3) say: “The more teams can share common standards, approaches and values, the greater the chances that spontaneous lateral

Mohammad Esmaeil Zadeh 2014

communication will occur, resulting in less ‘re-invention of the wheel’ and more chance of synergy. The stronger these lateral links, which are of both a technological and human nature, the less the requirement for management to attempt to impose control from above and the greater the sense of autonomy and empowerment experienced by the subsumed primary activities”.

System 2 works closely with System 3 and can be considered as embedded in System 3 (Christopher, 2007). It is very unlikely that senior management has requisite variety to dictate the operation of System 2. Most of this needs to be organised by the management of the System 1 operations. In fact, in real organisations, a lot of System 2 activity takes place informally, over lunch or in the pub after work. Co-ordination mechanisms can be very simple, but extremely powerful and are often taken for granted (Hoverstadt, 2008). Hoverstadt (2008, p. 29) also lists the typical co-ordination mechanisms as: “common standards, protocols, operations / production scheduling, and as well as these formal mechanisms, common language and shared cultures that ease communication between operational units can be important as can mutual agreement between units. All these are designed to smooth problems between operational units, and to prevent the activities of one disrupting those of another.”

A lack of comprehension of this important fact can lead to serious errors on the part of senior management. They can easily disrupt the operation of their organisation by discouraging the informal links which enable it to run smoothly. “Where co-ordination mechanisms fail, we find problems such as: process bottlenecks, failed production planning, turf wars between departments, conflicting messages to customers (internal or external), and appeals to higher management to sort the mess out” (Hoverstadt, 2008, p.29).

System 2 is also responsible for assuring System 1 compliance with corporate parameters. Corporate parameters prescribe those matters that need to be done in the same way in all System 1 units (Christopher, 2007) in order to keep things running smoothly and prevent disruptions. The corporate parameters include the corporate chart of accounts, corporate policy on ethical behaviour, the corporate parameters for compliance reporting, and other company policies such as the use of the company name

Mohammad Esmaeil Zadeh 2014

and trademarks (Christopher, 2007). System 2, by controlling the compliance of System 1 units with these corporate parameters, keeps things running smoothly and prevents disruptions, limits the amount of variety that reaches higher level managements, and makes the VSM much more than the sum of its parts.

3.4.3 System 3- Control

In the VSM, System 2 has the very important function of providing mechanisms to ensure that the activities of System 1 units don’t conflict with one another. However, this system is not responsible for the overall control of System 1 elements and operations, since its function is one of coordination, not control.

The everyday control of System 1 units by senior management is named by Stafford Beer as System 3. System 3 is responsible for internal and immediate control of the organisation (Hilder, 1995). It directs the ‘inside and now’ - all aspects of current operations to achieve desired results (Christopher, 2007). System 3 has the overall responsibility to see that the System 1 operations perform as expected (Christopher, 2007). That is, System 3 is responsible for “the internal and immediate functions of the enterprise: its ‘here-and-now’, day-to-day management” (Beer, 1985, p.86). These operations include: marketing and sales, budgeting, quality and productivity, human resources, engineering, and accounting. In addition to the inside and now, these functions also work at times in System 4 which is responsible for the outside and future of the corporation.

In fulfilling its control function, System 3 is in charge of maintaining the “cohesion” of the organisation. System 3 must integrate the operational elements into a cohesive whole (Espejo, 1989), so that the total system performs better than the sum of its parts acting independently (Skyttner, 2005). Espejo and Reyes (2011, p.98) argue that cohesion is one of the main mechanisms for viability in any organisation, and must be balanced against the autonomy of operational units: “For a collective to become an organization they need to achieve cohesion.... Cohesion requires aligning individual and collective interests. This alignment does not imply that individuals and their collective have the same interests and purposes, but that however different these might be, the implementation of individuals’ purposes produces the purposes collectively ascribed to

Mohammad Esmaeil Zadeh 2014

the organization.” The cohesion mechanism is very important in reaching structural alignment while keeping the autonomy of sub units, and therefore, this mechanism is for solving the long-lasting problem of centralisation and decentralisation.

To fulfil its synergistic role, System 3 has the overall responsibility of directing and controlling the operation of System 1 units’ management. Since System 3 lacks the variety (capability) to intercede in lower level operating decisions, it views the company’s viable System 1 units as black boxes and leaves operating decisions to the these systems (Christopher, 2007). That is, when the role of System 3 is conceived as fundamentally synergistic, only minimal meta-systemic intervention in elemental autonomy is needed (Beer, 1979). System 3 exerts control mainly using the vertical command channels shown in Figure 3 -2 as vertical lines going through systems of the VSM. One of these channels is the ‘Resource Bargain’ which is the most fundamental function of System 3, and is at the heart of the balance between control and autonomy” since it determines which activities are done and which are not (Mingers & Rosenhead, 2001, p.272). The Resource Bargain includes a clear definition of what the System 1 does, and its boundaries, its resources, its purpose, its goals, and its performance measures (Christopher, 2007).

In this kind of indirect management, senior management controls the actions of operational management partly through striking a bargain in which local management agrees to achieve certain objectives in exchange for a share of the resources (e.g., capital) available to the total system. That means that in collaboration with the management of System 1 units, System 3 reviews the Resource Bargain and reaches agreement on key short-term objectives and performance measures in the key performance areas that determine business success.

On the other hand, System 3 measures the performance of System 1 units’ operation by monitoring their reports and checking them against the agreed objectives. This means that in exchange for the resources provided, operational management must be accountable to senior management for their actions. Local management use the return channel of the resource bargaining loop to transmit reports of their activities. Given that senior management is unable to deal with the entire variety generated by the set of its

Mohammad Esmaeil Zadeh 2014

embedded systems, these reports must be highly summarised. The resource bargaining process must be participative, rather than coercive, since the arbitrary imposition of resource allocations and performance targets will increase the likelihood of implementation failure (Hoverstadt & Bowling, 2002).

System 3 also supervises the coordination activities of System 2 (Hilder, 1995) and is responsible for the anti-oscillatory functions of this system (Beer, 1985). System 3 collaborates with System 2 to assure coordination and to prevent or resolve any conflicts among the System 1 units. System 2 is the regulator; a facilitator, a tie-breaker, and at times needs an authority, which is System 3, for decisions resolving conflicts between the System 1 units (Christopher, 2007).

Fulfilling its control mechanism, System 3 may also need to directly monitor the operations of System 1, to ensure that System 1 management is not, either by accident or by design, “pulling the wool over their eyes” (Hilder, 1995). To do this, they may send task forces into the operations to carry out spot checks, audits, etc.

This is a very effective technique for maintaining System 3’s requisite variety. Stafford Beer refers to these direct monitoring operations as System 3* (Three-Star). Its purpose is to provide System 3 with assurance that the highly filtered information provided by operational management accurately reflects the true state of operations. To be effective, System 3* must satisfy three design principles. First, it must be sporadic and infrequent, since routine and regular audits relinquish much of the variety they generate (Beer, 1985). Second, it must be an openly declared mechanism to avoid concerns about “big-brother” tactics (Espejo & Gill, 1997). Direct access to the operations of System 1 elements should be with the approval of local management (Beer, 1979). Third, it should only link two adjacent levels of recursion to avoid a complete breakdown in trust (Espejo & Gill, 1997). System 3 is responsible for the design and operation of System 3*. System 3* has a highly specific role; namely to “top up” the requisite variety of System 3 by informing it of the true state of operations (Millar, 2009). Therefore, any corrective actions that are identified by a particular audit must be transmitted to the operational unit through the “corporate intervention” channel, not the audit channel (Beer, 1979).

Mohammad Esmaeil Zadeh 2014

3.4.4 System 4 - Intelligence

System 3 is in charge of keeping cohesion, in order to make a collection into a cohesive entity or an organisation. The organisation as modelled so far is only capable of dealing with immediate concerns (Hilder, 1995). However, another mechanism is needed that supports the organisation’s co-evolution with agents in its environment (Espejo & Reyes, 2011). This is the capacity of a viable system to adapt to disturbances in its external environment that threaten its internal stability:

“But it is not enough for the collective to become a cohesive whole to maintain viability; in addition this cohesive whole must be adaptive to changes in its environment. This is the hallmark of viability and a necessary condition to transform the collective into an organization. An effective enterprise is one that not only ‘does things right’ but is also able to find the ‘right things to do’. Moreover, a responsible enterprise is one that finds ethical means to do the right things. Capacities for adaptation and sensitivity to the eco-system are normally associated with the enterprise’s normative and strategic levels of management” (Espejo & Reyes, 2011, p.105).

In the VSM this function is the main task of System 4, labelled as “Intelligence” and is charged with managing the “outside-and-then”. It must be noted here that references to stability and adaptability must be understood within the context of the recursive nature of the VSM. Thus the ability to adapt (i.e., intelligence) is distributed throughout the layers of organisational recursions (Millar, 2009). At the lower level of recursion, the operational units are also fully formed viable systems and therefore their management units must also possess an intelligent function that enables them to adapt to disturbances in their local environments, which is a subset of the total environment. However, each System 1 unit does not have the capability to handle the total environment of the organisation because the total environment is greater than the sum of the environments of its embedded viable systems (Beer, 1979), which belongs to a higher level of recursion (Beer, 1985). Therefore there is a need for a System 4, which has an understanding of the total environment, to fulfil the Intelligence function of the whole organisation.

Mohammad Esmaeil Zadeh 2014

The VSM distinguishes between two aspects of the larger environment that require different responses from System 4 (Millar, 2009). The interaction between the system and its environment is shown in Figure 3 -2 by two lines, referred to as Alpha and Beta loops to show their bi-directional nature. The “Alpha” loop is the wider, accepted environment in which managerial interest is general and largely reactive (Millar, 2009). The Beta loop is the “problematic” environment, in which managerial interest is specific and innovative (Beer, 1979, p.227). The problematic environment is that subset of the total environment that determines the future viability of the organisation (Millar, 2009). In this domain, the organisation must be alert to novelty in the environment, and must act innovatively in order to shape the future (Beer, 1985). In system science (Christopher, 2007), innovation is a characteristic of viable systems. Innovation is also an essential strategy for on-going business success. The VSM and system thinking help make innovation happen (Christopher, 2007; Hoverstadt, 2008).

The corporate System 4 functions include: research and development, strategic planning, innovation, finance, market research, projects, and environmental relations (Christopher, 2007). This same list of functions is also the list of functions of the System 4s at lower levels of recursion, for their operating units. At lower levels of recursion there may not be organisation units for many of these functions. Instead they may be individual assignments or parts of individual assignments. However structured, the functions are essential at all levels of recursion (Christopher, 2007).

In addition to the functions listed above, people in the System 3 functions of marketing, quality and productivity, human resources, engineering, and finance and accounting, when working on “outside and future” will be working in System 4 (Christopher, 2007). Collectively, these activities endow the organisation with the creative faculty to “visualize alternative futures, and invent them” (Beer, 1979, p.243). Furthermore, the intelligence function, particularly through its market research and public relations activities, is responsible for projecting the identity of the organisation into its environment (Espejo & Gill, 1997).

System 4 has a strong, collaborative linkage with System 3, called System4/System3 Homeostate (Christopher, 2007). This is mainly because intelligent adaptation cannot be

Mohammad Esmaeil Zadeh 2014

achieved without an understanding of the organisation as it currently exists (Hilder, 1995). Just as the future has strong connections with the past, System 4 (with responsibility for outside and future) maintains strong connections with System 3 (with responsibility for inside and now) (Christopher, 2007), or tomorrow emerges from today. Proposals for adaptation must be formulated in consultation with System 3, to balance the creative drive of the intelligence function by the realities of the organisation and to avoid System 4 dictating strategies that are unworkable or unproductive (Millar, 2009). Thus, there is the need for extensive communications between Systems 3 and 4. This very rich interaction that needs to exist between these two functions is indicated in Figure 3 -2 by the thick curved arrows between System 3 and System 4. This loop is different from the low variety central command channel connecting the two systems directly, as this channel lacks the capacity needed to handle this “huge variety” (Beer, 1979, p.252).

In fact, System 4 cannot do its job of intelligent adaptation without containing a model of the whole organisation, and its environment. The quality of this internal model is crucial to the capability of the organisation to adapt to change (Hilder, 1995).

Derived from the Law of Requisite Variety, the Conant-Ashby Theorem simply states that every regulator must contain a model of the system being regulated (Beer, 1979). The model used to regulate a system must exhibit the requisite variety to deal with all possible states of the system; otherwise the system could enter into a state that is beyond its capacity to comprehend and thus control. One of the key uses of the VSM is as an aid to designing the model of the organisation and its environment for System 4 (Hilder, 1995).

In order to provide the organisation’s “apparatus of adaptation” (Beer, 1979, p.101), System 4 provides the corporation with the capacity to adapt, through three “functions” (Lewis & Millar, 2010):

• sensing the current environment and contemplating possible futures (using the alpha and beta loops respectively);

Mohammad Esmaeil Zadeh 2014

• making sense of the corporation’s purpose and value proposition in a turbulent world (using models of the enterprise and its environment); and

• thinking strategically about what direction the corporation should steer to adapt to an unknown and unknowable future (using the System 3 – System 4 loop).

System 4 through these functions can do work that is essential for continued company success into the future, as described above. System 4 monitors the VSM to assure that all is working as desired, and does the environmental scanning, corporate planning, R&D, and innovation to assure the changes needed for creating the desired future for the company. At all levels of recursion, System 4 has the same functions for each of those business units (Christopher, 2007).

3.4.5 System 5 - Policy

System 5 is the overall policy making entity in the VSM (Beer, 1979). As mentioned before, strategic decision-making is a process of matching current reality, which is within System 3’s cohesion management, to future needs or objectives, which is handled by System 4’s intelligence (Hoverstadt, 2008), However, The two subsystems are dedicated to functions that are concerned with different environments and time spans. Hence, there is a need for a fifth, and final, subsystem – System 5, or “Policy”, to provide balance between the two and give closure to the organisation.

The role of System 5 as the company’s top homeostat in solving the possible conflicts between the outside and future considerations of System 4 and the inside and now considerations of System 3 is very important to ensure that the System 3 /System 4 loop does not enter into uncontrolled oscillation (Beer, 1979). Failure to adequately structure these conversations results in a high failure rate for decisions (either not implemented, or fail on implementation) (Christopher, 2007). This will bring about either an organisation that pursues unrealistic strategies or an organisation that lacks the capacity to adapt (Millar, 2009).

In considering this rule of System 5, it must be noted that in fact System 5 cannot deploy sufficient variety to absorb the combined variety of Systems 3 and 4. On the other hand “policy making must be a low variety process” (Espejo, 1989, p.84). This can

Mohammad Esmaeil Zadeh 2014

be done by delegating much of the policy-making authority of System 5 to Systems 3 and 4. In this case Systems 3 and 4 work as effective attenuators to reduce the complexity and bring it within the range of the response capacity of System 5 (Espejo & Reyes, 2011). Systems 3 and 4 must also provide information about their current states in a language understandable by System 5. System 5’s role is therefore simplified to that of monitoring the System 3 – System 4 interaction. However, System 5 must still possess the sufficient requisite variety to regulate the System 3 – System 4 loop (Millar 2009). A failure to do so would place “policy makers in the invidious position of deciding issues that are beyond their competence” (Espejo & Reyes, 2011, p.106) and would result in inadequate decisions and loss of accountability for the organisation’s policies.

If the System 3 – System 4 loop is working well, there may be little for System 5 to do. Under such circumstances, System 5 may enter into a state of “lethal calm” – a condition in which “sleep turns into coma; and coma becomes death” (Beer, 1979, p.406). Consequently a special signal called the “algedonic” signal is needed to awaken System 5 in the event of a potential disaster developing, that requires its immediate attention (Millar, 2009). The algedonic signal is represented in Figure 3 -2 by the hatched line departing the System 1 to System 3 channel and flowing directly to System 5.

Organisations which do not clearly distinguish between System 3 and System 5 are inherently unstable (Hilder, 1995). In the VSM, System 5 is in charge of the executive direction and leadership of the organisation (Christopher, 2007). In his book, Unchaining the Chain of Command, Paul Rubinyi (1998), describes twenty functions of System 5 executive leadership. Compared to the role of System 3 (which performs many executive functions in relation to operations), System 5 (as the executive direction of the company) “is responsible for the company’s most important executive decisions—determining company structure and management principles. Structure defines the company, its purpose, and its boundaries; establishes company goals and performance measures; and provides the needed resources. Management principles determine how the structure will be managed” (Christopher, 2007, p75).

System 5 has also the responsibility to see that all the functions of System 5, System 4, System 3, System 2, and the System 1s are structured and functioning (Christopher,

Mohammad Esmaeil Zadeh 2014

2007). This can also be seen as the role of governance, ensuring that the organisation has all the mechanisms that it needs to ensure both its internal cohesion and efficiency and also its ongoing fit with its environment (Hoverstadt, 2008).

System 5 supplies logical closure to the viable system and connects to the next level of recursion (Hilder 1995). Without this closure the embodied elements of the collective may “remain as a group of people but may fail to achieve the status of an organisation” (Espejo, 2011, p. 899). This role of System 5 effectively defines the identity and ethos of the organisation - its personality and purpose (Hilder, 1995). Above and beyond System 5 lies only the next level of recursion: the system-in-focus is now complete, self- sufficient.

With closure comes identity (Millar, 2009). The viable system is a self-contained whole possessing both purpose and personality. Therefore, this role of the policy function is to understand and manage the organisation’s identity – not just its values, but what it is, what it exists for, who its stakeholders are and how it relates to them (Hoverstadt, 2008). In establishing the organisation’s purpose, System 5 must define its “business areas and their meaning in a particular context” (Espejo, 1989, p.84).

Since System 5 closes the viable system, above and beyond System 5 lies only the next level of recursion. This defines another role of System 5, which is how it fits into the larger environment, the compliance: “It is to understand how the organization fits into the larger system of which it is a part. For a department, this is a matter of understanding the larger organization and its politics. At the corporate level, it is the reason we have non-exec directors and join industry bodies.” (Hoverstadt, 2008, p. 36). The Australian Standards AS3806 (AS, 2006, p.4) explains Compliance as an outcome of an organisation meeting its obligations: “An effective organization-wide compliance program will result in an organization being able to demonstrate its commitment to compliance with relevant laws, including legislative requirements, industry codes, organizational standards as well as standards of good corporate governance, ethics and community expectations. An organization’s approach to compliance should be shaped by its core values and generally accepted corporate governance, ethical and community standards.”

Mohammad Esmaeil Zadeh 2014

Every organisation has an ethos which comes from System 5, the overall policy making entity in the organisation (Hilder, 1995). This ethos is the set of values and beliefs that underpin its philosophy of existence (Beckford, 2002), and provides the overall character and personality of the organisation (Christopher, 2007). Beer (1985, p.125) characterised ethos as a “variety sponge of gigantic capacity” since it discouraged many “non-conforming” alternatives from being proposed for deliberation by the System 3 - System 4 loop. System 5 “sets the overall policy and ethos of the organization; it also ensures that the organization has an identity and that this is known and acted upon” (Mingers & Rosenhead, 2001, p.274). Therefore System 5 provides the leadership for making the structure, management principles, and character happen (Christopher, 2007).

3.5 Critiques of the VSM

As a final notice, it must be mentioned that although the VSM has shown considerable strengths in dealing with complex organisations, it has been the subject of some specific criticisms too (e.g. Checkland, 1980; Ulrich, 1981, 1987). Considering whole issues around strengths and weaknesses of the VSM is beyond the scope of this thesis. However, it is worth to mention one of these criticisms (which is listed under the category of epistemology) is that the VSM underplays the purposeful role of individuals in organisations (Ulrich, 1981), and thus results in failing to consider the social and political dimensions of organisations (Checkland, 1980). It is an essential fact that the component parts of organisations are human beings, “who can attribute meaning to their situations and can therefore see in organizations whatever purposes they wish and make of organizations whatever they will” (Flood & Carson, 1993, p.89). The role of people and politics is very essential in IS and especially in EA (Lewis, 2013), but the VSM has shown to be weak in dealing with this role. This limitation is reflected in the design principles based on the VSM in this thesis, and will be called out as future works in the Chapter 9.

3.6 The VGM

The Viable Governance Model (VGM) adapts the VSM to one aspect of organisational control, namely IT governance (Millar, 2009). The corporate governance of IT is defined in the ISO/IEC 38500 as “the system by which the current and future use

Mohammad Esmaeil Zadeh 2014

of IT is directed and controlled” (ISO/IEC, 2008, p. 3). Given that governance is concerned with mechanisms for directing and controlling organisations, and cybernetics is the science of communication and control (Wiener, 1948), the VSM should prove to be a useful foundation for developing a model of IT governance. By selecting the corporation as the system-in-focus of the VSM, the VGM formulated in that work is a model for the governance of IT at the corporate level.

Figure 3 -3- The VGM – structural elements (Millar, 2009)

The VGM, shown in Figure 3 -3, could explain and organise a theoretical model that encapsulates all the elements of IT governance into a single, coherent framework. This model is used to formulate a series of design propositions or principles that may be used to guide the design and implementation of specific IT governance arrangements. The VGM specifies the invariant sub-systems of an effective system of IT governance, together with the design principles to be followed when implementing a particular system. In defining the VGM, value creation and value preservation (or risk management) are the basis for the theory of organisation viability, and therefore, their

Mohammad Esmaeil Zadeh 2014

realisation is the primary purpose in the VGM. A set of the most important design propositions for IT governance in VGM is given in (Lewis & Millar, 2010).

A key benefit of the VGM is the alignment between IT and the business that it encourages. The VGM emphasises that the IT function should be modelled as a service unit, not an operational unit (i.e., an embedded viable unit), unless IT is part of the organisation’s value chain. That is, if the corporation is in the business of providing information services or IT support services to external organisations, then those elements of the corporation that provide those services should be modelled as embedded, operational units.

However, care must be taken in using the concepts of the VGM for developing principles in other fields of Information Systems (IS) and especially the EA. For example, there is a move to regard Enterprise Architecture as the planning of all resources, including people, not just information technology (Lewis, 2013). This fact must be considered when using the IT governance concepts, and specially the VGM, in the context of EA.

3.7 Conclusion

Aiming to establish a theoretical basis for deriving a set of principles for EA and other Information Management systems, in this chapter an overview of the main concepts of the VSM was provided. The review has shown that cybernetics and the VSM give us a framework that improves management in any company, any business, and any organisation organised for a purpose (Christopher, 2007). The VSM has a lot to say about structure and how the organisation works. It was also shown that the VGM adapts the VSM to one aspect of organisational control, namely IT governance.

Recalling from the Introduction section, the potential overlap between the concepts of EA and the VSM, the VSM/VGM can now be examined as a useful theoretical foundation for developing EAPs. It is now the time for choosing how this research should be done, and therefore in the next chapter different methodologies for doing this research will be studied to find how the objective of this research can be achieved.

Mohammad Esmaeil Zadeh 2014

Chapter 4 Methodology

4.1 Introduction

After determining the research questions and objectives in Chapter 1 and Chapter 2, and knowing about the theoretical basis in Chapter 3, it is now the time to determine a suitable methodology for conducting this research. Since this research has a qualitative nature, a qualitative methodology is expected to be suitable for it too. In this chapter we study different possible approaches in reaching the objectives, and choose the best methodology for conducting the research.

4.2 Research in IS

Information Systems (IS) has a multi-disciplinary nature and therefore a diversity of philosophies and research approaches is employed by IS studies (Galliers & Land, 1987; Shanks et al., 1993). Most of the literatures in Information System research agree on the fact that this new field of study mainly uses the achievements of other disciplines, such as economics, computer science, and the social sciences to solve problems (e.g. Hevner et al., 2004; Peffers et al., 2007; Gregor, 2007). Usually these problems are at the intersection of people, organisations, and technology (Davis & Olson, 1985; Lee, 1999; Hevner et al., 2004).

This multi-disciplinary nature of IS is reflected in a lot of research methods in IS, and maybe the diagram presented by Niglas (2001), shown in Figure 4 -1, can give us a good overview of the range and extent of different methods available in IS research. In this diagram, she extends the Tesch (1990) types of qualitative research into a three- dimensional diagram, in which the quantitative-qualitative continuum is shown from left to right, and the philosophy-methodology continuum from top to bottom. She also illustrates the mutual relationships and influences of different research paradigms on a 2- dimensional paper by extending the second dimension to both sides from the centre. So, on the final scheme the second dimension goes from top/bottom to the centre.

Mohammad Esmaeil Zadeh 2014

Figure 4-1- Research methods in the IS, (Niglas, 2001)

Mohammad Esmaeil Zadeh 2014

In spite of the wide range of accompanying disciplines that causes this wide range of research methods, a characteristic that distinguishes IS from other fields is the use of artefacts in human-machine systems (Gregor & Jones, 2007). That is, IS is a discipline which is at the intersection of knowledge of the properties of physical objects (machines) and knowledge of human behaviour: “Research in the information systems field examines more than just the technological system, or just the social system, or even the two side by side; in addition, it investigates the phenomena that emerge when the two interact” (Gregor & Jones 2007, p.313).

Moreover, As Galliers and Land (1987) mention, the IS discipline is considered to be an applied discipline and therefore its research findings should be applicable in the “real world”. Peffers et al. (2007) also emphasise that IS is an applied research domain which seeks to construct useful artefacts in order to solve problems and guide professionals who do the work in the real world. This is consistent with the idea of the available forms of science, shown in Figure 4 -2, for the socio-technical systems (Lewis, 2013). This diagram shows that the science for socio-technical systems is at the intersection of natural science, or positivist (Galliers & Land, 1987), social science, or interpretivist (ibid.), and practical science.

Practical Science: engineering, medicine, education

For socio- technical systems Natural Science “Social” or Human (Positivist): Science physics, (Interpretivist): experiments, archeology, statistics history, sociology

Figure 4-2- Available forms of science (Lewis, 2013)

Mohammad Esmaeil Zadeh 2014

Hevner et al. (2004) also mention that for effective and efficient implementation of IS within an organisation, further knowledge should be acquired which is at the confluence of people, organisations, and technology. They characterise much of the research in the IS discipline by two complementary but distinct paradigms: behavioural science and design science (March & Smith, 1995). The behavioural science paradigm has its root in natural science and seeks to develop and verify theories that explain or predict human or organisational behaviour, or as Simon (1996, p.1) says: it is a “body of knowledge about some class of things in the world (nature or society) that describes and explains how they behave and interact with each other”.

On the other hand, the design-science paradigm seeks to extend the boundaries of human and organisational capabilities by creating new and innovative artefacts (Hevner & Chatterjee, 2010). This research method, which has recently received considerable attention and authority (Gregor, 2006; Hevner et al., 2004, March & Smith, 1995), is explained in more detail in the next section.

4.3 Design as a research method (DSR)

As explained before, IS is an applied research domain which seeks to construct useful artefacts in order to solve problems and guide professionals who do the work in the real world. Based on this, Hevner et al. (2010, p.11) argued that the DSR paradigm “is highly relevant to information systems (IS) research because it directly addresses two of the key issues of the discipline: the central, albeit controversial, role of the IT artefact in IS research (Weber, 1987; Orlikowski & Iacono, 2001; Benbasat & Zmud, 2003) and the perceived lack of professional relevance of IS research (Benbasat & Zmud, 1999; Hirschheim & Klein, 2003)”. They argued that design science research combines a focus on the IT artefact with a high priority on relevance in the application domain. Therefore, the DSR supports a pragmatic research paradigm that calls for the creation of innovative artefacts to solve real-world problems.

Most of the literatures in the related fields acknowledge that Simon (1969) is considered influential in the use of design as a research method in IS. Based on Simon’s observation, design is suitable for IS research because: “... the design aims to change the current status into the desired status. IS aims to build systems that help people to achieve

Mohammad Esmaeil Zadeh 2014

the desired status. Thus, DSR and IS have the same intention, making DSR suitable for IS research” (Alturki et al., 2012, p.311).

In contrast to behavioural science, design science will focus on the design of artefacts (Gregor and Jones, 2007; Hevner et al., 2004; Peffers et al., 2007), that is, “It seeks to create innovations that define the ideas, practices, technical capabilities, and products through which the analysis, design, implementation, management, and use of information systems can be effectively and efficiently accomplished” (Hevner et al., 2004, p.76). DSR is knowledge about artificial objects constructed by human beings in order to satisfy certain preferred goals (Alturki et al., 2012).

While the natural sciences are concerned with explaining how and why things are, design science would be concerned with how things ought to be (Simon, 1969), or as Van Aken (2004) states: Behavioural Science is “what is” (explaining the causality) and DSR is “what can be” (to develop design knowledge that is used in constructing solutions). In other words, compared to behavioural science (which has a descriptive nature), design science research is an outcome-based research methodology, which focuses on the development and performance of designed artefacts with the explicit intention of improving the functional performance of the artefact (Van Aken, 2004). That is, design theory gives explicit prescriptions (guidelines or principles) for constructing an artefact (Gregor, 2006). This characterisation of design theory is also shared by Walls et al. (1992, p.37), who wrote: ”design theory is a prescriptive theory based on theoretical underpinning which says how a design process can be carried out in a way which is both effective and feasible”. Therefore, DSR can be regarded as a prescription-driven program, rather than a description-driven one (Van Aken, 2004).

Alturki et al. (2012, p. 314) summarises some other points of views about the differences between behavioural science and DSR: “While the former concentrates mainly on an analysis to discover the components of an existing system, design focuses on a synthesis to shape these components (Walls et al., 1992). DSR looks ahead to create possibilities by producing artefacts, but Behavioural Science looks back to explain the past through constructs, theories, and laws (Purao, 2002). DSR is characterised by knowing through making and Behavioural Science by knowing through observing

Mohammad Esmaeil Zadeh 2014

(Purao, 2002). Behavioural Science aims “at the exploration and validation of generic cause–effect relations”; and DSR aims “at the construction and evaluation of generic means–ends relations” (Winter, 2008, p470).”

The normative or prescriptive nature of the theory is a distinguishing feature of the DSR (Gregor, 2006). In fact it is motivated by solving problems, in which prescriptions are of a heuristic nature (Van Aken, 2004). Design science research is sometimes called “improvement research,” and this designation emphasises the problem-solving or performance-improving nature of the activity (Kuechler & Vaishnavi, 2008). The other feature of DSR is that it is based on pragmatic validation, to justify the belief that the problems are always context related: “The prescription is to be used as a design exemplar. A design exemplar is a general prescription which has to be translated to the specific problem at hand; in solving that problem, one has to design a specific variant of that design exemplar” (Van Aken, 2004, p.227).

It must be noted that while DSR is different from behavioural science research, they also complement each other in IS research (Gregor, 2002a; Hevner et al., 2004; Van Aken, 2004), and in some cases, they must interact with each other (Gregor & Jones, 2007; Walls, 1992, March and Smith, 1995; Goldkuhl and Lind, 2010). Hevner et al. (2004, p. 80) explain the logic behind this as: “The goal of behavioural science research is truth. The goal of design science research is utility. As argued above, our position is that truth and utility are inseparable. Truth informs design and utility informs theory. An artefact may have utility because of some as yet undiscovered truth. A theory may yet be developed to the point where its truth can be incorporated into design. In both cases, research assessment via the justify/evaluate activities can result in the identification of weaknesses in the theory or artefact and the need to refine and reassess. The refinement and reassessment process is typically described in future research directions.”

Within the IS discipline, many design activities have been extensively studied, formalised, and become normal or routine. Design-science research in information systems addresses what are considered to be wicked problems (Hevner et al., 2004, p.81), “which are characterized by:

Mohammad Esmaeil Zadeh 2014

- unstable requirements and constraints based upon ill-defined environmental contexts - complex interactions among subcomponents of the problem and its solution - inherent flexibility to change design processes as well as design artefacts (i.e., malleable processes and artefacts) - a critical dependence upon human cognitive abilities (e.g. creativity) to produce effective solutions - a critical dependence upon human social abilities (e.g., teamwork) to produce effective solutions”

The concept of wicked problems is initially introduced by Rittel and Webber (1973). However, it must be emphasised that DSR has been used to explore more than wicked problems in IS.

An important issue in using the DSR is its difference from routine design or system building. The difference is in the nature of problems and solutions (Peffers et al., 2007). Routine design is defined as the act of creating an explicitly applicable solution to a problem by using existing knowledge (Peffers et al., 2007). In fact in routine design, existing knowledge is used to solve organisational problems, and is usually based on the existing best practice artefacts (ibid). On the other hand, “design-science research addresses important unsolved problems in unique or innovative ways or solved problems in more effective or efficient ways” (Hevner et al., 2004, p. 81). In doing so existing knowledge can be used, but usually the required knowledge does not exist, and hence, the DSR can be applied to contribute to the knowledge. Therefore, producing knowledge is believed to be the main distinction between DSR and routine design. Besides, The DSR is used for a class of problems, rather than a particular problem for specific organisations and stakeholders (Van Aken, 2004). Table 4 -1 (Alturki et al., 2012) summarises the comparison between the DSR and routine design.

Mohammad Esmaeil Zadeh 2014

Table 4-1- Comparison between DSR and routine design (Alturki et al., 2012)

Design Science (DS) Routine Design (RD) General solution Specific solution Produces new knowledge (novelty) Uses the current/existing knowledge Unknowns (not known) things in the Design is known (replication) planned design Does not contributes to the knowledge Contributes to the knowledge base (a base development of scientific knowledge) (An application of scientific knowledge) Solve unaddressed important problems in Solve problems using existing knowledge a new and effective way Technology Invention Technology Application Addresses abstract or a class of problems Addresses a particular problem for a for a class of organizations and specific stakeholders organization and stakeholders How to resolve a type of problems Solve one case only

4.4 DSR approaches

Based on what was explained in the previous section, “Design science research involves the design of novel or innovative artifacts and the analysis of the use and/or performance of such artifacts to improve and understand the behavior of aspects of Information Systems” (Vaishnavi & Kuechler, 2004, p.1). This procedure will lead to “contributing new knowledge to the body of scientific evidence” (Hevner & Chaterjee, 2010, p. 5). The DSR is in fact an engineering research methodology, although it is not restricted to engineering nowadays (Hevner & Chaterjee, 2010). Design activities are central to most applied disciplines (Hevner & Chaterjee, 2010).

Although there are several understandings about the processes and outputs of DSR in the IS research community (see e.g., McKay & Marshall, 2005; Peffers et al., 2007; Vaishnavi & Kuechler, 2007; Walls et al., 1992), generally it is based on the “build” and “evaluate”, or develop and justify, processes (Hevner et al., 2004, p.78). Reliance on creativity and trial-and-error search are characteristic of such research efforts. That is, in this research method, based upon theory and according to the objectives for solving a

Mohammad Esmaeil Zadeh 2014

problem, something (an artefact) is built (designed). Then this thing is tried in real cases to see if it is better than what exists already. This whole process supports the theory that led to the design. It can be concluded that DSR goes beyond the design of products or processes; it leads to new knowledge of what works, in socio-technical systems (Lewis, 2013).

The enacted forms of the two central design research activities (“develop” and “justify”) depend on the type of IS artefact selected for study (Millar, 2009). Hevner et al. (2004, p. 83) define artefacts as: “innovations that define the ideas, practices, technical capabilities, and products through which the analysis, design, implementation, and use of information systems can be effectively and efficiently accomplished”. They argue that this definition of the artefact is consistent with the concept of IS design theory as used by Walls et al. (1992) and Markus et al. (2002) where the theory addresses both the process of design and the designed product.

As the output of this research method, four artefacts are identified to address heretofore unsolved problems (Hevner et al., 2004). These artefacts are constructs, models, methods, and instantiations (March & Smith 1995). They are evaluated with respect to the utility provided in solving those problems. Constructs provide the language in which problems and solutions are defined and communicated. Models use constructs to represent a real-world situation—the design problem and its solution space. Models aid problem and solution understanding and frequently represent the connection between problem and solution components, enabling exploration of the effects of design decisions and changes in the real world.

Methods define processes. They provide guidance on how to solve problems; that is, how to search the solution space (Brinkkemper, 1996; Bucher et al., 2007). These can range from formal, mathematical algorithms that explicitly define the search process to informal, textual descriptions of “best practice” approaches, or some combination.

Instantiations show that constructs, models, or methods can be implemented in a working system. They demonstrate feasibility, enabling concrete assessment of an artefact’s suitability for its intended purpose. They also enable researchers to learn about the real world, how the artefact affects it, and how users appropriate it. In some literature

Mohammad Esmaeil Zadeh 2014

(e.g. Takeda et al., 1990 “better theories” is also mentioned as the output of the DSR, meaning that in designing an artefact, the DSR can contribute to theory building in a similar way to experimental methods.

Iivari et al. (1998, p.175) also observed that design artefacts “may be either purely conceptual artefacts (models, frameworks, and procedures) or more technical artefacts with a ‘physical’ realization (e.g., software)”.

In the following sections of this chapter, some of the most common approaches of the DSR are explained to see which one is more suitable for this research.

4.4.1 DSR common steps

Figure 4 -3 shows a typical process for the DSR (Peffers et al., 2007). Usually the first step in research is the definition of a research problem, which could be of a theoretical or applied nature. Resources required in this stage include knowledge of the problem and the importance of its solution. The second step is to determine the objective for a solution of what is possible and feasible. The objective can be either quantitative or qualitative. The core stage in DSR is the design and development stage in which the artefact is created. This artefact could be each of the outputs that were previously described, including constructs, models, methods, or instantiations. In the demonstration stage, the use of the artefact is demonstrated to solve one or more instances of the problem. This could involve its use in experimentation, simulation, case study, proof, or other appropriate activity. This stage requires effective knowledge of how to use the artefact to solve the problem.

Mohammad Esmaeil Zadeh 2014

Figure 4-3- The DSR methodology process model (Peffers et al. 2007)

Mohammad Esmaeil Zadeh 2014

Another very important step in DSR is evaluation. In this stage the functionality of the artefact in solving the problem will be measured. The main resources for evaluation are knowledge of relevant metrics and analysis techniques. Depending on the nature of the problem venue and the artefact, evaluation could take many forms, but it has a close relation to the objectives defined in the second stage. Based on these objectives, evaluation could be quantitative or qualitative. At the end of this stage, the researchers can decide whether to iterate back to the design step to try to improve the effectiveness of the artefact or to continue to the next step which is communication to diffuse the resulting knowledge. In this stage of the work, we communicate the problem and its importance, the artefact, its utility and novelty, the rigour of its design, and its effectiveness to researchers and other relevant audiences.

Peffers at al. (2007) also note that although the DSR is a sequentially structured method, it can be started at almost any step, based on the nature and venue of the research. The sequence that was described above refers to a problem-centred approach. Similarly it can be objective-centred, started by an industry or research need. A design and development-centred approach would result from the existence of an artefact and would use it as a novel solution for the explicit problem. The same approaches exist for starting from other stages of the DSR.

4.4.2 Balancing rigour and relevance

Hevner et al. (2004) argue that in any DSR it is important to maintain a balance between the efforts spent in constructing and evaluating the evolving design artefact. In another word, this method should balance between the research’s requirements (rigor) and professionals’ needs (relevance) (Alturki et al., 2012).

Based on this, Hevner et al. (2004) present the conceptual framework for understanding, executing, and evaluating IS research, as shown in Figure 4 -4, which is claimed to be a combination of behavioural-science and design-science paradigms

Mohammad Esmaeil Zadeh 2014

Figure 4-4- The conceptual framework for IS research (Hevner et al. 2004)

Figure 4 -5 also borrows this framework and overlays a focus on three inherent research cycles: “The Relevance Cycle bridges the contextual environment of the research project with the design science activities. The Rigor Cycle connects the design science activities with the knowledge base [KB] of scientific foundations, experience, and expertise that informs the research project. The central Design Cycle iterates between the core activities of building and evaluating the design artefacts and processes of the research” (Hevner, 2007, p.88). Furthermore, Hevner posits that these three cycles must be present and clearly identifiable in a DSR project.

Mohammad Esmaeil Zadeh 2014

Figure 4-5- Design Science Research cycles (Hevner, 2007)

The whole research usually starts in the Relevance Cycle by defining the business needs and “the problem space (Simon, 1996) in which reside the phenomena of interest” (Hevner, 2004, p. 79). Framing research activities to address business needs assures research relevance. The Relevance Cycle also defines acceptance criteria for the ultimate evaluation of the research results to check if the design artefacts improve the environment and how this improvement can be measured.

Given such an articulated business need, IS research is then conducted in the Design Cycle by building and evaluation of artefacts designed to meet these identified needs. Moreover, the research assessment via the justify/evaluate activities can result in the identification of weaknesses in the theory or artefact and the need to refine and reassess.

In the Rigor Cycle: “The knowledge base provides the raw materials from and through which IS research is accomplished” (Hevner et al., 2004, p. 80). Rigor is achieved by appropriately applying existing foundations and methodologies.

The contributions of behavioural science and design science in IS research are assessed as they are applied to the business need in an appropriate environment, and as they add to the content of the knowledge base for further research and practice. “A justified theory that is not useful for the environment contributes as little to the IS literature as an artefact that solves a non-existent problem.” (Hevner et al., 2004, p.81)

Mohammad Esmaeil Zadeh 2014

Hevner et al. (2004) also establish seven guidelines for understanding, executing, and evaluating the research in IS as illustrated in Table 4 -2.

Table 4-2- Design Science Research guidelines (Hevner et al., 2004)

In describing their approach, Hevner (2007, p.91) emphasises the importance of the balance between these cycles: “Pragmatism is a school of thought that considers practical consequences or real effects to be vital components of both meaning and truth. Along these lines I contend that design science research is essentially pragmatic in nature due to its emphasis on relevance; making a clear contribution into the application environment. However, practical utility alone does not define good design science research. It is the synergy between relevance and rigor and the contributions along both the relevance cycle and the rigor cycle that define good design science research.”

4.4.3 Theory in the DSR

Shirley Gregor investigates the nature of theory in IS research and proposes a taxonomy for classifying IS theories (2002a, 2002b, 2006, 2009). One of the five types

Mohammad Esmaeil Zadeh 2014

of IS theory distinguished by the taxonomy is a “theory for design and action”. Gregor (2006) proposes a design and action theory, referred to as ‘Type V’ in her IS taxonomy of theories. Gregor and Jones (2007) consider this type to be highly influential in the IS discipline because it helps professionals who work with IS. Especially in Gregor (2009), she argues that building artefacts is essential to theorising and derives seven principles for creating knowledge in IT disciplines as: (i) artefact system centrality; (ii) artefact purposefulness; (iii) need for design theory; (iv) induction and abduction in theory building; (v) artefact construction as theory building; (vi) interior and exterior modes for theorising; and (viii) issues with generality. From there she claims implicitly that consideration of these principles will improve knowledge creation and theorising in design disciplines.

4.4.4 Generating knowledge

Vaishnavi and Kuechler (2007), in a model which is an adaptation of the computable design process model developed by Takeda et al. (1990), emphasise that knowledge contribution needs to be a key focus of the DSR.

In this model, all design begins with Awareness of a Problem that comes from multiple sources, and results in a proposal for a new research effort. From there, “Suggestions for a problem solution are abductively drawn from the existing knowledge or theory base for the problem area (Pierce, 1931). An attempt at implementing an artefact according to the suggested solution is performed next. This stage is shown as Development in Figure 4 -6. Partially or fully successful implementations are then Evaluated (according to the functional specification implicit or explicit in the suggestion). Development, Evaluation, and further Suggestions are often iteratively performed in the course of the research (design) effort. The basis of the iteration, the flow from partial completion of the cycle back to Awareness of Problem, is indicated by the Circumscription arrow. Conclusion indicates termination of a specific design project” (Vaishnavi & Kuechler 2004, p.10).

Mohammad Esmaeil Zadeh 2014

Figure 4-6- Vaishnavi and Kuechler (2007) model for DSR

The authors explicitly mention that this model is basically similar to most other DRS process models, though some phases may be different, merged or broken. However, the emphasis here is on a detailed process for generating design science knowledge.

4.4.5 Summary of the models

Figure 4 -7 (Alturki et al, 2011) summarises the different approaches to give the most complete overview of the DSR process.

Although DSR has emerged as an important approach in IS research, it still necessitates more effort to reach maturity as a research paradigm and to be well accepted by IS researchers. A holistic approach for the conduct of DSR in IS is yet to be confirmed (Alturki et al., 2012). Gregor and Hevner (2013, p. 337) also state: “We contend that DSR has yet to attain its full potential impact on the development and use of information systems due to gaps in the understanding and application of DSR concepts and methods.” While there are many methodological guidelines for DSR available, there is debate on their completeness and validity too (Alturki et al., 2012).

Mohammad Esmaeil Zadeh 2014

Figure 4-7- The overall Design Science Research roadmap (Alturki et al., 2011)

Mohammad Esmaeil Zadeh 2014

4.5 Using DSR in this research

As was explained in the previous chapters, the main objective of this thesis is to define methods for deriving a set of comprehensive principles of Information Systems, and in particular, of Enterprise Architecture. This objective falls within the broader socio-technical perspective of the IS discipline. Therefore, a research method is needed that handles technology, design, its social implications, dynamic interactions between several factors, and feedback between factors. These are the specifications of DSR which is at the intersection of people, organisations and technology. It advocates using the literature to suggest the parameters for the design of an artefact, which is a set of management guidelines, and then testing its usefulness and usability. The adoption of design science by elements of the management research community (e.g. Van Aken, 2004) supports the proposition that design science is applicable to the design of management artefacts such as management practices.

From another point of view, the nature of this research is the design of something, rather than choosing one thing among some options. The aim of this research is to develop, or design, methods for developing principles. This means that the nature of this research is to design artefacts, in this case methods, to solve existing problems. As mentioned, research such as this - which is the deliberate creation of a means to solve a particular class of problem (in contrast to seeking clarification on something that ‘is’)- is design science research (Gregor & Jones, 2007; Hevner, et al., 2004; March & Smith, 1995; Peffers, et al., 2008; Kuechler & Vaishnavi, 2008; Walls, et al., 1992; 2004).

In explaining DSR in previous sections, it was mentioned that this research method is suitable for wicked problems (Hevner et al., 2004). Because of the similarity of the current research with the characteristics of wicked problems, including the requirements and constraints of this research, its interaction with the solution, the required flexibility to change design process and design artefacts, and more importantly the critical dependence upon human cognitive abilities (e.g. creativity) and human social abilities (e.g., teamwork), DSR would be the best method for this research.

In fact, in choosing a suitable research methodology, it must be considered that the aim of this research is to improve practice, rather than theory. This research has an

Mohammad Esmaeil Zadeh 2014

applied nature. The artefact of this research should be used in professional societies; therefore the evaluation part of the DSR could be done in real cases by skilled professionals.

In conducting this research, nearly all explained approaches of the DSR could be used. For example, adopting the DSR approach given by Hevner et al. (2004), the following steps can be recognised in this research:

- Problem awareness and business needs: Initial understanding of the field of EA, principles, and values through existing literature. This step is mentioned in Chapter 1 and Chapter 2.

- Rigour: Getting information about cybernetics and especially the VSM and VGM as the theoretical basis for designing the artefact. This step is explained in Chapter 3.

- Design: Proposing a set of design principles based on the VSM, which will be used as methods, in the form of guidelines, for developing principles for EA and IS in general. That is, the development activity involves the design of a set of guidelines using theoretical constructs drawn from several reference disciplines including cybernetics, organisation theory, and complexity theory, requirements engineering. This step is studied in Chapter 5.

- Evaluation: Validation of these methods by evaluating their usability and usefulness in real cases. These practical steps are explained in Chapters 6, 7, and 8. As part of this validation, a survey is also carried out and explained in Chapter 8 to check the usability and usefulness of these artefacts in other Information Management frameworks. These chapters also describe how the results of these evaluations are reflected in the proposed methods to fulfil the iterative nature of the DSR, as suggested by Sonnenberg and Vom Brocke (2012).

- Contribution: Conclusion, publishing the results and adding to the knowledge base. This final step is explained in Chapter 9.

Since its introduction, the DSR has been used in many fields of information systems (Peffers et al., 2007), yet use of this methodology in developing principles of IS and EA

Mohammad Esmaeil Zadeh 2014

can be a novel idea, which could result in considerable contributions to these fields of knowledge.

Based on what explained up to now, this research is about using the VSM in developing principles of EA and other IM frameworks. In Chapter 2 it was mentioned that this research is trying to answer how a theoretical basis, here the VSM, can be used to develop EA and IM principles. The output of this research is, therefore, the way we can develop principles, which lies under the category of methods in the potential artefacts of the DSR. In simpler words, this thesis is aims to find methods of developing principles of EA and IM, using the concepts of cybernetics, especially those embedded in the VSM. This proposition is consistent with the literature in what a method is and how to build methods (e.g. Brinkkemper, 1996; Bucher et al. 2007; Ralyte, 2007).

4.6 Conclusion

In this chapter, after reviewing different research methods in IS discipline, the DSR as a suitable methodology for conducting this research was explained. The DSR has many characteristics that make it suitable for this research. Among several comprehensive models or processes for conducting design research, the Hevner et al. (2004) approach is selected as the basis of different steps of this research.

Fulfilling this approach, in the next chapter the first version of the artefact, which is a set of design principles based on cybernetic concepts, will be developed. These design principles will be used as the methods, in the form of guidelines, for developing principles, and in the following chapters, their performance will be evaluated in real cases to check their usability and usefulness.

Mohammad Esmaeil Zadeh 2014

Chapter 5 Developing Design Principles

5.1 Introduction

In previous chapters it was shown that recent definitions of Enterprise Architecture (EA) emphasise that the scope of this discipline is now the planning of all resources under the control of an enterprise, not just IT resources. Also, most of these definitions of EA emphasise that Enterprise Architecture Principles (EAPs) are an essential component of any architecture framework. However, the EA discipline still suffers from some fundamental limitations, such as the lack of guidelines for developing a generic set of principles and a theoretical basis for developing them. In Chapter 3 it was concluded that the VSM is a powerful tool for designing viable organisations. Fulfilling the Design step of DSR methodology described in Chapter 4, this chapter proposes the methods for developing a set of comprehensive principles by suggesting a set of design principles based on the concepts of cybernetics, especially those embedded in the VSM. These principles are fundamental requirements for any viable systems, and therefore must be complied with by the organisation in order to remain viable. The suggested design principles can be used as methods, in the form of guidelines, in proposing, developing, and evaluating a set of comprehensive EAPs. Then, the chapter continues the development process by explaining how they are customised in practical applications.

5.2 How to derive design principles

5.2.1 The VSM and EA

As it was mentioned before, there is an overlap between some definitions of EA as the blueprint for the architecture of an organisation and the VSM as a blueprint of a viable organisation. Moreover, it was shown that the VSM has recently been used to investigate different aspects of EA in some academic and professional studies. The VSM has also been used to develop a model for corporate IT governance, the VGM. All these

Mohammad Esmaeil Zadeh 2014

reasons lead to the conclusion that the VSM/VGM may prove to be a useful theoretical foundation for developing EAPs.

A viable system has some fundamental requirements that can be put together as a set of design principles. In order to be viable, a system must comply with these principles. On the other hand, EAPs are values that generally apply to the design and development of the architecture of an enterprise. If we consider an enterprise as a viable system, then the design principles of viable systems should be regarded as the design principles for the enterprise, i.e. its EAPs.

The VSM as the theoretical basis of this work was described in Chapter 3. In this chapter, the main concepts of the VSM are repeated briefly, and based on each concept, a design principle is proposed as a guideline for developing principles of EA. All of these principles are derived based on the requirement that the organisation is viable. In other words, if an enterprise wants to be viable, it must address these design principles somehow in their set of EAPs.

5.2.2 Structure of proposed principles

It is advocated to have a standard way of defining principles, and therefore, in developing these design principles, the common format for principles given by TOGAF (2012) is used. As explained in Chapter 2, TOGAF uses a format for the description of principles. This format consists of a name, a statement, a rationale, and a set of implications. Table 5 -1, quoted exactly from TOGAF (2012), shows the template for an EAP and the description of its fields.

The Name and Statement are the essence of the principle and must be clear, understandable and unambiguous (TOGAF, 2012; Greefhorst & Proper, 2011). Besides these two parts, each principle should have associated Rationale and Implications statements, “both to promote understanding and acceptance of the principles themselves, and to support the use of the principles in explaining and justifying why specific decisions are made” (TOGAF, 2012, p.236).

The Rationale is the justification for having the principle (TOGAF, 2012), or the reason for its existence (Greefhorst & Proper, 2011). In their discussion of the

Mohammad Esmaeil Zadeh 2014

importance of the Rationale statements, Greefhorst and Proper (2012, p. 72) mention that all stockholders need to understand the rationale to accept the principle and to support its implementation and use: “Designers need to understand the rationale before they accept that they must adhere to it. ...Management needs to understand the rationale since they sponsor the architecture; they will be involved in escalations and need to support the architecture principle when deviation is at hand”.

Table 5-1- Recommended format for defining principles (TOGAF, 2012)

Name Should both represent the essence of the rule as well as be easy to remember. Specific technology platforms should not be mentioned in the name or statement of a principle. Avoid ambiguous words in the Name and in the Statement such as: ‘‘support’’, ‘‘open’’, ‘‘consider’’, and for lack of good measure the word ‘‘avoid’’, itself, be careful with ‘‘manage(ment)’’, and look for unnecessary adjectives and adverbs (fluff).

Statement Should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar from one organization to the next. It is vital that the principles statement be unambiguous.

Rationale Should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of information and technology principles to the principles governing business operations.

Also describe the relationship to other principles, Rationale and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision.

Implications Should highlight the requirements, both for the business and IT, for carrying out the principle — in terms of resources, costs, and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to: ‘‘How does this affect me?’’ It is important not to oversimplify, trivialize, or judge the merit of the impact. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analyzed.

Mohammad Esmaeil Zadeh 2014

The Rationale should highlight the business benefits of adhering to the principle too (TOGAF, 2012). Usually these benefits are expressed in qualitative terms, although quantitative benefits should be mentioned when known (Greefhorst & Proper, 2011). The Rationale also highlights the relationship to other principles, and the priority of that principle in the case of having conflict between principles.

Implications are primarily concerned with issues related to the use of the EAPs, rather than the justification for them (TOGAF, 2012). Implications address organisation- specific aspects of the EAPs (Greefhorst & Proper, 2011), and may have some recommendations about who owns an EAP and who is responsible for it being maintained or deactivated. They provide an outline of the key tasks, resources, and potential costs to the enterprise of following the principle (TOGAF, 2012); they also provide valuable inputs to future transition initiative and planning activities. Greefhorst and Proper (2012, p.72) express the role of Implications as:

“The implications describe the state that exists when the architecture principle statement is successfully implemented/enforced. It drives the behavior that is expected from people in order to comply to the architecture principle. Implications are formulated in a similar form as the statement, but can also be references to more detailed architecture principles. One may also consider describing the undesired behavior that is an implication of the architecture principle (what people should not do), as well as the negative consequences (the disadvantages of choosing for the architecture principle). The implications are typically the most organization-specific elements of architecture principles. They show the most important consequences of the architecture principles in the organization. More specifically, they show what is necessary and sufficient (and thus essential) to attain the architecture principle. It is also where architecture principles can be made specific and measurable (if the statement was not already in this format) in the sense that they show the concrete impact. This helps the reader understand the impact on its own work. It is important not to oversimplify, trivialize, or judge the merit of the impact. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analyzed.”

Mohammad Esmaeil Zadeh 2014

In our set of design principles, the Name and Statement are chosen to represent the corresponding VSM concept unambiguously. Similarly the Rationale statements are derived from their related VSM concepts and show the theoretical reason for the existence of the related principle.

The Implication statements of the principles are the most problematic parts in this approach. The lack of a systematic approach in defining EAPs reflects in their Implications too. While I was studying the existing principles to collect a list of Implication statements, I found that these statements are the most scattered part of EAPs, and there is no systematic way of listing them. Most of these statements are not complete, sometimes they are duplicated, and most importantly, they don’t cover all IT activities in the organisations. The Implication statements are therefore left blank in this step. In Chapter 8, in proposing a set of principles for ITIL (2013), it will be shown that the list of IT processes in COBIT (ISACA, 2012a) and ITIL could be good candidates for listing Implication statements in EAPs.

5.3 VSM-based generic design principles

5.3.1 Requisite Variety

In Chapter 3 it was mentioned that Ashby’s Law of Requisite Variety is a very potent principle in cybernetics and especially in deriving the VSM. In short, it states simply that only variety can absorb (or destroy) variety. When applied in an organisational context, the law stipulates that an organisation must exhibit sufficient capacity (variety) to match the potential environmental states that may impact its purpose. An organisation lacking the requisite variety to deal with relevant environment variety would be unable to respond and adapt to unforeseen shifts in the environment.

In Diagnosing (Beer, 1985), Stafford Beer uses only the law of Requisite Variety and deductive reasoning to derive the VSM and all other organisational principles. The other principles in this chapter flow from this fundamental law, and therefore, this law is regarded as the preeminent design principle here:

Design Principle: Requisite Variety: Control can be obtained only if the variety of the controller is at least as great as the variety of the situation to be controlled.

Mohammad Esmaeil Zadeh 2014

5.3.2 Viability and Recursion

As described before, the VSM is based on the concept of viability - maintaining separate existence; surviving on its own (Beer, 1979). In order to remain viable, or to survive, there are laws and principles that must be complied with. Moreover, the VSM is a recursive model, which means all of its subsystems must also be viable, and therefore, must comply with the same invariant principles as the containing system too. Therefore, as the principles of viable systems are used to derive a set of principles for EA, these principles must apply to all organisational units within the enterprise.

Design Principle: Viability: Viability (survival) is the ultimate goal of the enterprise.

Design Principle: Recursion: All embedded organisational units of the enterprise must comply with these principles.

5.3.3 Black box

As it was explained in Chapter 3, the senior managers are usually unable to obtain information about all the possible states (variety) of the embedded systems, for which they are ultimately responsible, and therefore, they cannot intervene within lower level operations (Christopher, 2007). The question now arises, how can senior management effectively manage the embedded system? The answer lies in the cybernetic concept of the “black box”. This concept, when used in conjunction with that of recursion, provides a potent recipe for managing organisational complexity (Millar, 2009). Stafford Beer’s First Regulatory Aphorism states: “It is not necessary to enter the black box to understand the nature of the function it performs” (Beer, 1979, p40). In general, all those who are outside an operational unit, including the higher management and the environment, do not need to know exactly how the things are done inside the black box; they just need to know what goes into it, what goes out of it, and what the relations between the inputs and the outputs are (Christopher, 2007).

Design Principle: Black box: What is important for those using the services of any organisational unit is its interfaces (input and output) and the relation between them, rather than how the function is performed.

Mohammad Esmaeil Zadeh 2014

5.3.4 Value creation and Value preservation

Based on the viability principle, it is essential to comply with the laws and principles of the VSM to remain viable, or to survive. Stafford Beer emphasises that surviving should not be interpreted in the narrow sense of merely existing; it involves learning, adapting and growing (Beer, 1981). Organisations must add some value to remain viable or, as The IT Governance Institute mentions, “continuous growth and survival in the highly competitive global environment are the ultimate goals of value creation” (ITGI, 2005, p35). Here the concept of viability is related to the concept of “value” and value creation. Beside value creation, value preservation (or risk management) is another important principle to help ensure that the organisation’s current survival is not endangered. Thus, value creation and value preservation are the ultimate sources of organisation viability (Lewis & Millar, 2010).

Design Principle: Value creation: All resources in the organisation are directed and controlled to achieve viability through the creation of value that is meaningful to key stakeholders.

Design Principle: Value preservation: The ongoing survival of the organisation is preserved by managing the risks that impact its value proposition.

5.3.5 Balancing cohesion versus autonomy

System 1 is the fundamental unit that actually performs the work of the viable system. It is made up of all the operations that do the things that justify the existence of the system. As the VSM has a recursive nature, all operational units in VSM are viable systems in their own, and therefore, are capable of maintaining separate existence. This principle requires that they must be given the maximum autonomy, as far as they comply with the goals of the larger system to which they belong. Autonomy of operational units promotes greater responsiveness and flexibility (Peterson, 2004) and helps the organisation realise the potential of its people (Jackson, 2000). Autonomous units have the freedom to adapt to their local environments and, therefore, attenuate the variety that needs to be handled by the higher level management (Espejo & Reyes, 2011).

Mohammad Esmaeil Zadeh 2014

One of the main objectives of the VSM is to ensure that the enterprise as a whole delivers more than the sum of its parts (Skyttner, 2005). An enterprise may be a collective of autonomous units. The autonomy of the operational units, if unchecked, may lead to organisational chaos. For a collective to become an organisation, it needs to achieve cohesion. The only restriction for the autonomy of the operational units is that they must operate in a way that is consistent with the purposes of the whole organisation: “Cohesion requires aligning individual and collective interests” (Espejo & Reyes, 2011, p98). Without this restriction, the organisation would lose coherence and fracture. In the VSM, System 3 must integrate and align the operational elements into a cohesive whole (Espejo, 1989).

Design Principle: Autonomy: Operational systems (Business units) are granted the maximum degree of autonomy consistent with the constraint of maintaining organisational cohesion.

Design Principle: Cohesion: Synergies across the various business units are exploited to ensure that the enterprise as a whole delivers more than the sum of its parts.

5.3.6 Service units

Two questions need to be considered: where to incorporate the IT department and what is its relation to the recursive system of the VSM? Can it simply be considered as an operational unit embedded within the corporation? Beer states that operational units are those capable of separate existence, those that implement the purpose of the organisation (Beer, 1979). Some other units (e.g. IT, human resource, and finance) help operations, but they do not do them. These units must not be considered as operational units, they are service units. Service units are those that facilitate the operation of System 1 units and cannot be viable systems on their own.

The use of the term “service unit” should not be construed to mean that the IT department does not have a strategic role to play within the enterprise. Within the VSM, System 4 (Intelligence) is responsible for the formulation of the organisation’s strategic direction based on an analysis of the changing, external environment (for example, disruptive technologies and business models) and its internal operations (for example,

Mohammad Esmaeil Zadeh 2014

existing IT capabilities and constraints). Beer advocated the use of a “management centre” in which key executives, including the Chief Information Officer (CIO), come together to make important decisions about the future of the enterprise. Within the management centre “IT issues” are conceived as “business issues”.

Design Principle: IT/Business alignment: The primary purpose of the IT function is to enable the enterprise achieve its business objectives through the delivery of proper services.

5.3.7 Core IT

The exception to modelling the IT department as a service unit occurs when the IT function provides services directly to external customers in fulfilment of the enterprise’s purpose (for example, cloud computing vendor). In these organisations, IT is a core function and must be regarded as a System 1 or business operations unit; it must be viable in itself. This IT function is part of the organisation’s value chain, also providing a service but to an external customer.

Design Principle: Core IT: Where IT is part of the organisation’s value chain then it is an operational unit and must comply with all the EA principles.

5.3.8 Coordination

The autonomy of operational units implies that they must strive to maximise their own value. However, in doing so, they may get in each other’s way. To prevent this situation and to promote organisational synergies through cooperation and healthy competition, some coordination mechanisms must be established to make maximum alignment and integration among business units. System 2 (Coordination) consists of the various policies, rules, and standards that ensure that operational units act cohesively and not counterproductively.

Design Principle: Coordination: Organisational synergies are promoted through coordination of the activities of the enterprise and business-unit groups.

Mohammad Esmaeil Zadeh 2014

5.3.9 Resource management

In the VSM, resource management and performance management constitute the resource bargain channel, which is an important regulatory function of system 3. This channel is in charge of getting the strategies formulated by the System 3- System 4 interaction and then issuing the operational plans needed for controlling and monitoring the operational units (Millar, 2009). These plans include the agreed outcomes, as well as the resources required to achieve them. All resources must be allocated to maximise synergies and realise business values in an effective, efficient and acceptable manner.

Design Principle: Resource management: Resources are allocated by corporate executives in such a way as to maximise business value.

5.3.10 Performance

In the reverse direction of the bargaining channel, the operational units report their achievements against the agreed plan(s) and, therefore the senior executives can measure their performance on achieving their assigned objectives. As explained in Chapter 3, this performance management is necessary in such an extent that is proper for controlling the activities of operational units and holding the business units accountable for their agreed commitments.

Design Principle: Performance: The performance of the subsidiary units is monitored properly against their agreed objectives.

5.3.11 Audit

System 3 must directly and independently monitor the operations of operational and service units, in order not to be deceived, either intentionally or accidentally, by the management of these units (Millar, 2009). This monitoring can be done by sporadic and infrequent audit mechanisms. Audit (system 3*) is used to provide additional feedback on the true state of operations within the operational units. This additional feedback can be used to improve the variety that is needed by the executives to monitor and control the function of these units. It is essential that all functions in the organisation, including those of service units, be audited to provide corporate leaders with assurance that the

Mohammad Esmaeil Zadeh 2014

allocated resources are being used effectively and efficiently to create and preserve business value (Lewis & Millar, 2010). Of course, Audit requires Performance Management. These principles do sometimes couple with each other.

Design Principle: Audit: The enterprise is able to independently monitor (audit) the performance of its subsidiary units.

5.3.12 Adaptation

The cohesion principle specifies the necessary requirement for a collective to become an organisation. However, in a changing environment, becoming a cohesive whole is not enough for a collective to remain viable (Espejo, 1989). The cohesive whole must also be capable of adapting to changing pressures and demands of its environment. Without an adaptation capability, organisations fail to be viable. To be adaptable, organisations must understand the environment in which they are embedded. An effective enterprise is one that not only ‘does things right’ but is also able to find the ‘right things to do’ (Espejo, 1989, p105). In the VSM, System 4 fulfils the “Intelligent” function in the organisation that is necessary for adapting to the changing environment through three functions: sensing, sense making, and strategic thinking.

Design Principle: Adaptation: The enterprise is enabled to adapt to its changing environments.

5.3.13 Ethos

System 5 effectively defines the identity and ethos of the organisation - its personality and purpose.

Viable organisations are self-organising systems and so have the capability to maintain their identity regardless of their environmental pressures or internal changes. What keeps the identity is the relationship between the components, not the components themselves. As Hilder (1995, p16) explains, viable systems are able to maintain their identity because they are purposive: “This ability to maintain identity is related to the fact that viable systems have purposes. These purposes provide the framework for their

Mohammad Esmaeil Zadeh 2014

maintenance of identity. Lack of purpose is usually indicative of the impending collapse of a self-organizing system”.

Design Principle: Identity: The enterprise demonstrates to internal and external stakeholders a consistent identity, which represents its purpose and ethos.

5.3.14 Governance

System 5, also known as the Multi-node, is the ultimate decision making unit in the organisation. All information processing and decision-making loops within the enterprise are closed in System 5. As an example, System 5 monitors the System 3 - System 4 homeostat, which maintains the balance between the management of “inside-and-now” and the management of “outside-and-then” (Beer, 1979). The main responsibility of System 5 in strategic decision-making is fulfilled by the governing body.

Here ‘governing body’ means an entity in the organisation that has the governance authority. It might be just a person, such as the owner of a small business or a group of directors in a large corporation. As in the other aspects of the VSM, what is important is the function that must be done, not how it is done.

Structurally, the governing body must have the requisite variety to control the variety of the organisation (Lewis & Millar, 2010). This requirement is a fundamental conclusion of the Law of Requisite Variety, which is the basis for all other principles as well.

Design Principle: Governance: The governing body, as the ultimate decision- making body within the enterprise, assumes responsibility for the governance of the enterprise.

5.3.15 Compliance

As stated previously, the VSM is a recursive system and so all viable systems are part of a larger viable system. Therefore, all policies formulated by the organisation must be in accordance with the laws and policies of the wider system in which it is embedded. In other words, to remain viable, an enterprise must comply with the laws, legislations, regulations, and social responsibilities related to the use of resources imposed by the

Mohammad Esmaeil Zadeh 2014

wider system, otherwise it would lose its legitimacy and therefore its right to exist. In the VSM, the corporate intervention function ensures that subsidiary units comply with relevant legal, regulatory, and ethical requirements (for example, privacy and security). Specifically, System 5 is in charge of ensuring compliance with the wider systems in which the corporation is embedded. Beside this, the corporate centre (consisting of System 3 and its sub systems, System 3* and System 2) is charged with monitoring the organisation compliance with applicable laws, regulations and policies.

Design Principle: Compliance: The enterprise, as a whole, complies with legislative, regulatory, and societal obligations, and established policies.

5.4 The use of proposed design principles as methods in practical cases

Table 5 -2 summarises the list of design principles derived based on the concepts of the VSM. Here it must be mentioned that the list of design principles was initially somehow different from the existing set shown in this table. The current list is the outcome of several iterations of the DSR methodology, resulting in modifications of principles according to the feedback received from practical applications, reviews from submitted conference and journal papers and the feedback of professionals working in the target organisations. The initial list and details of changes are not stated here to avoid duplication; however, some of the key points will be mentioned in the next chapters during the evaluation part of the thesis.

These design principles are the general principles for viability of a system, and an organisation in particular. As explained before, these design principles - if customised according to the needs and priorities - can be used as methods, in the form of guidelines, for deriving EAPs. However, in using these guidelines in practical cases, some points must be noted which are explained in this section.

Mohammad Esmaeil Zadeh 2014

Table 5-2- Summary of the VSM-Based design principles Name Statement Requisite Control can be obtained only if the variety of the controller is at least as great as the 1 Variety variety of the situation to be controlled. 2 Viability Viability (survival) is the ultimate goal of the enterprise. 3 Recursion All embedded organisational units of the enterprise must comply with these principles. What is important for those using the services of any organisational unit is its 4 Black box interfaces (input and output) and the relation between them, rather than how the function is performed. Value All resources in the organisation are directed and controlled to achieve viability 5 Creation through the creation of value that is meaningful to key stakeholders. Value The ongoing survival of the organisation is preserved by managing the risks that 6 Preservation impact its value proposition. Operational systems (Business units) are granted the maximum degree of autonomy 7 Autonomy consistent with the constraint of maintaining organisational cohesion. Synergies across the various business units are exploited to ensure that the enterprise 8 Cohesion as a whole delivers more than the sum of its parts. IT/Business The primary purpose of the IT function is to enable the enterprise achieve its business 9 alignment objectives through the delivery of proper services. Where IT is part of the organisation’s value chain then it is an operational unit and 10 Core IT must comply with all the EA principles. Organisational synergies are promoted through the coordination of the activities of the 11 Coordination enterprise and business-unit groups. Resource Resources are allocated by corporate executives in such a way as to maximise business 12 Management value. The performance of the subsidiary units is monitored properly against their agreed 13 Performance objectives. The enterprise is able to independently monitor (audit) the performance of its 14 Audit subsidiary units. 15 Adaptation The enterprise is enabled to adapt to its changing environments. The enterprise demonstrates to internal and external stakeholders a consistent identity, 16 Identity which represents its purpose and ethos. The governing body, as the ultimate decision-making body within the enterprise, 17 Governance assumes responsibility for the governance of the enterprise. The enterprise, as a whole, complies with legislative, regulatory, and societal 18 Compliance obligations, and established policies.

Mohammad Esmaeil Zadeh 2014

5.4.1 Customisation

Derivation of these design principles is part of the methods for developing EAPs. The process of developing principles includes their customisation too. In fact in applying these methods, it must be noted that not all of the design principles need to be used to develop a set of EAPs for a specific organisation. Principles have different priorities and they can conflict, because they represent the wants of different points of view. The choice of principles reflects the external circumstances and internal conditions of an enterprise. Accordingly, what might be pertinent for one organisation at one point of time might not be pertinent for some other organisation or at another time. However, they are expressed generally enough to provide a guide to sound behaviour in most organisations most of the time (lewis, 2013). This is also consistent with TOGAF (2012) which emphasises that principles are inter-related, and need to be applied as a set: “Principles will sometimes compete; for example, the principles of ‘accessibility’ and ‘security’ tend towards conflicting decisions. Each principle must be considered in the context of ‘all other things being equal’. At times a decision will be required as to which principle will take precedence on a particular issue.”

Greefhorst and Proper (2012, p.71) also express the same meaning when they state that “Architecture principles are not meant to be used as laws, since an architect cannot oversee all detailed consequences. As a result, deviation from architecture principles is always an option, provided the organizational structure is in place to govern and manage these deviations (not to say that it should be taken lightly).”

Moreover, the concepts of the VSM are highly inter-related. Usually most of these concepts can be deduced from other concepts. Therefore, the resultant design principles are also inter-related, as explained above, and might be redundant.

As a summary, Greefhorst and Proper (2010, p. 77) list the relationships between principles as:

“Realization: links an architecture principle with a more concrete architecture principle (or other artifact) that (partially) realizes it.

Mohammad Esmaeil Zadeh 2014

Specialization indicates that an architecture principle is a specialization of another architecture principle.

Conflict indicates that an architecture principle (partially) conflicts with another architecture principle.

Association models a relationship between architecture principles that is not covered by another, more specific relationship.”

These relationships must be considered carefully in developing EAPs to avoid duplicated or contradicted principles. Some of these relationships will be observed in next chapters during the Evaluation phases of this research. As it was mentioned before, the role of the Rationale statement is very important in resolving these kinds of issues in defining EAPs.

It is also important to keep the number of EAPs to a reasonable number by deleting unnecessary principles and merging some redundant ones into more comprehensive EAPs. TOGAF (2012, p. 238) recommends that the number of principles should be limited because “Too many principles can reduce the flexibility of the architecture”. TOGAF (2012) recommends limiting the number of principles to between 10 and 20 as many organisations prefer to define only high-level principles.

Another important point in this usage is the translation of the generic principles into a language that is understandable by the users, rather than expressing the principles in more formal academic language. TOGAF (2012, p. 237) mentions that “A good set of principles will be founded in the beliefs and values of the organization and expressed in language that the business understands and uses.” In describing the requirement for the Statement of a principle, Greefhorst and Proper (2012, p. 71) also recommend: “Use terminology that is recognized by all those affected by the principle, which is preferably documented explicitly […]. Prevent the use of technological (IT) terms when they are not necessary.” In customising a generic principle, the generality of that principle may be lost, but it will be made more suitable to be followed by the different stakeholders of the organisation.

Mohammad Esmaeil Zadeh 2014

5.4.2 How these methods could be used

These methods, or guidelines, or principles for defining principles, could be used in different ways in the derivation of a set of EAPs. Firstly, in an organisation that wants to start to derive its EAPs, these guidelines help professionals find the concerns and motivations for EAPs and determine what a comprehensive set of EAPs should include. Alternatively, this set of principles can be customised for that specific enterprise, which means that different sections are emphasised, de-emphasised, or deleted based on the priorities of that enterprise. The customisation of principles can be realised in the Implication statements of EAPs. In the statement of principles, the implication section is primarily concerned with issues related to the implementation of the principles (TOGAF 2012), and address organisation-specific aspects of the principles (Greefhorst & Proper, 2011).

These guidelines can also be used as a diagnosing tool. For those organisations that have already developed their EAPs, these guidelines could be used to check that the EAPs are coherent and comprehensive. This objective can be reached by mapping their principles against these guidelines. Based on this mapping and the priorities of the organisation, any shortage or redundancy in the set of EAPs can be specified, and a more effective and efficient set of EAPs can be obtained.

There are some limitations in the use of VSM as the basis for providing ‘meta- principles’: One example of these limitations is the aforementioned weakness of the VSM in dealing with the role of people and politics in organisations, which is an important part of EA. This limitation demands further research into other sources of cybernetic principles to compensate for it.

5.5 Conclusions

This chapter presented a set of design principles based on the concepts of Stafford Beer’s Viable System Model. The results are based on previous studies that examined using the VSM in the corporate governance of IT, with some modifications to include recent developments about the scope of EA to cover all resources in the organisation, not just IT. All the essential concepts of the VSM were examined in order to formulate a

Mohammad Esmaeil Zadeh 2014

comprehensive set of principles. These principles can be regarded as the main requirements for viability in designing organisations and can be used as guidelines in developing EAPs.

After designing the artefact, which is a set of methods described in the DSR, in the following step (the Evaluation step) the validity of this artefact in real cases will be examined. Since the DSR has an iterative nature, the ‘design – validation’ process may be repeated several times for any specific cases. This will be done in the following chapters by mapping them against an available set of EAPs, and checking their performance in practical cases.

100

Mohammad Esmaeil Zadeh 2014

Chapter 6 Principles of TOGAF

6.1 Introduction

In Chapter 2, after reviewing the limitations of the current definitions of EA and EAPs, new definitions were proposed to cover the latest ideas about EA and its scope, and to emphasise important items in the definitions of EAPs given by the leading authors. The EAPs were defined as values that generally apply to the design and development of the architecture of an enterprise, in which a value is defined as “a description of performance that is necessary to ensure that the operation of a system achieves its goals, meets the wishes of all those concerned, or uses its assets efficiently”. It was also mentioned that this definition could be used for classification of a given set of EAPs based on the work done in the field of values, enabling practitioners to check the completeness and consistency of that set of principles.

Moreover, in Chapter 5, as the Design step in the DSR methodology and based on the VSM concepts, a set of methods, in the form of guidelines, was proposed that can be used to derive EAPs. After the Design of the artefact, it is now the time for its Evaluation, the next step in the DSR methodology. Based on the specifications of the DSR explained in Chapter 4, this methodology is an iterative methodology, meaning that the results of the Evaluation step are also used to modify the designed artefact. This means that aside from the validation of the applicability of the artefact, the Evaluation step is also important in the build process. In this chapter, as the first evaluation case, the proposed design principles are mapped against the existing principles. For this purpose the business principles of TOGAF (2012) are chosen as a test bed to examine the definition of EAPs and the proposed set of guidelines. The result of this study could

101

Mohammad Esmaeil Zadeh 2014

demonstrate how useful and usable these proposals are, how close these design principles are to existing EAPs, and how these design principles should be modified to show themselves to be like practical EAPs.

6.2 Example set of EAPs in TOGAF

6.2.1 Sets of EAPs

The most widely used source for EAPs is TOGAF (Lewis, 2013), which is available on The Open Group website (TOGAF, 2012). TOGAF describes these exemplar set as the starting point in the definition of EAPs. These principles are usually adapted and customised by organisations to meet their specific requirements. However, there are other collections of EAPs, such as the set documented in the US Government's Federal Enterprise Architecture (FEA, 2001). Greefhorst and Proper (2011, p.153) have also proposed a set of principles based on an extensive study of “real-world architectures”. These principles range from high-level enterprise-wide principles to very specific technical principles concerning networks and databases. In our study, we have also collected our own set, based upon searched resources, which consists of over 200 principles; also ranging from high-level business principles to very detailed technical prescriptions. As explained in Chapter 2, one reason for the scope and diversity of the range of these principles can be a consequence of the lack of standard, universal definitions for EA and EAP.

As the main goal of this research is to establish whether cybernetic concepts can be used to explicate EAPs established in practice, this chapter will limit its focus to TOGAF’s EAPs, which may be considered as an exemplar for other collections.

6.2.2 Principles in TOGAF

TOGAF defines EAPs as: “general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission” (TOGAF, 2012). TOGAF notes that a good set of principles will be founded in the beliefs and values of the organisation. They provide a firm foundation for making architecture and planning decisions, framing policies, procedures, and standards, and supporting resolution of contradictory situations.

102

Mohammad Esmaeil Zadeh 2014

The alignment between business objectives and IT capabilities is an important element in defining principles in TOGAF. Specifically the following sources for developing the architecture principles are highlighted: enterprise mission and plans, enterprise strategic initiatives, external constraints, current systems and technology, and computer industry trends. TOGAF emphasises that principles should be few in number, future-oriented, and endorsed and championed by senior management. A good set contains principles that are understandable, robust, complete, consistent, and stable. TOGAF defines each EAP in a standard representation that includes: name, statement, rationale, and implications.

TOGAF Version 9.1 specifies a set of 21 sample principles categorised according to four domains: business, data, application and technology. The complete list of EAPs is available in the Open Group website (TOGAF, 2012) and is replicated in Annex 3. The details of this analysis are limited only to the high level EAPs drawn from the business domain due to the constraints of a single chapter of this thesis.

6.3 Classification of TOGAF’s business principles

As an example of the use of the new definition of EAPs, the nine business principles in the example set of TOGAF (2012) are classified based on the types of values explained in Chapter 2. In order to facilitate reading the results, the name, statement and rationale of each principle, as defined by TOGAF, are presented. The Statement and Rationale of each principle are quotes from TOGAF. The implications sections of TOGAF’s principles, which are primarily concerned with the implementation and organisation- specific aspects of the principles, are not examined here. The results are shown briefly in Table 6-1, and the way they reflect the main value types of acceptability, effectiveness and efficiency are described here. It must be noted that one principle may refer to more than one attribute.

103

Mohammad Esmaeil Zadeh 2014

Table 6-1- Classification of business principles in TOGAF based on the types of values

Business Principle in TOGAF Type of value

Principle 1. Primacy of Principles Acceptability - suitable

Principle 2. Maximize Benefit to the Enterprise Effectiveness - capability or Efficiency

Principle 3. Information Management is Effectiveness - capability Everybody’s Business

Principle 4. Business Continuity Efficiency - safe

Principle 5. Common Use Applications Efficiency - sufficient

Principle 6. Service Orientation Efficiency - sufficient

Principle 7. Compliance with Law Acceptability - suitable

Principle 8. IT Responsibility Efficiency - Effectiveness

Principle 9. Protection of Intellectual Property Efficiency - safe

6.3.1 Principle 1: Primacy of Principles

Statement: These principles of information management apply to all organizations within the enterprise.

Rationale: The only way we can provide a consistent and measurable level of quality information to decision-makers is if all organizations abide by the principles.

Type of Values: Acceptability. The main principle in a set of principles considers what people are allowed to use and what not to use. In fact, acceptability is about how things are done. In Table 2-3, this principle reflects suitability, or conforming to formal laws.

6.3.2 Principle 2: Maximize Benefit to the Enterprise

Statement: Information management decisions are made to provide maximum benefit to the enterprise as a whole.

Rationale: This principle embodies ‘‘service above self ’’. Decisions made from an enterprise-wide perspective have greater long-term value than decisions made from any particular organizational perspective. Maximum return on investment requires

104

Mohammad Esmaeil Zadeh 2014

information management decisions to adhere to enterprise-wide drivers and priorities. No minority group will detract from the benefit of the whole. However, this principle will not preclude any minority group from getting its job done.

Type of Values: Efficiency or Effectiveness. The main aim of an efficient system is to minimise resources whilst still being effective. Although this principle refers to benefits, presumably in meeting its objectives, it also involves gaining maximum benefit from any investments; that is, being efficient. The implications include changing the way things are done (possible acceptability), setting priorities (effectiveness), and sharing applications (efficiency). That is, there are several values covered in the implications – indicating that this principle is perhaps not properly formed.

6.3.3 Principle 3: Information Management is Everybody’s Business

Statement: All organizations in the enterprise participate in information management decisions needed to accomplish business objectives.

Rationale: Information users are the key stakeholders, or customers, in the application of technology to address a business need. In order to ensure information management is aligned with the business, all organizations in the enterprise must be involved in all aspects of information environment. The business experts from across the enterprise and the technical staff responsible for developing and sustaining the information environment need to come together as a team to jointly define the goals and objectives of IT.

Type of Values: Effectiveness. In order to provide the required features, all organizations must participate in decision making, so that the system becomes effective. This principle is in response to the question “will it work?” and ensures that the system has the capability to achieve its objectives.

6.3.4 Principle 4: Business Continuity

Statement: Enterprise operations are maintained in spite of system interruptions.

Rationale: As system operations become more pervasive, we become more dependent on them; therefore, we must consider the reliability of such systems throughout their design and use. Business premises throughout the enterprise must be provided with the

105

Mohammad Esmaeil Zadeh 2014

capability to continue their business functions regardless of external events. Hardware failure, natural disasters and data corruption should not be allowed to disrupt or stop enterprise activities. The enterprise’s business functions must be capable of operating on alternative information delivery mechanisms.

Type of Values: Efficiency. The system must have enough resources to achieve its goals and objectives in any conditions. This principle prescribes the capability and, especially the capacity, for a system to maintain its operation in arduous conditions.

6.3.5 Principle 5: Common Use Applications

Statement: Development of applications used across the enterprise is preferred over the development of similar or duplicative applications which are only provided to a particular organization.

Rationale: Duplicative capability is expensive and proliferates conflicting data.

Type of Values: Efficiency. Again this principle supports efficiency, avoiding wasting resources for duplicative applications, resulting in an affordable system.

6.3.6 Principle 6: Service Orientation

Statement: The architecture is based on a design of services which mirror real-world business activities comprising the enterprise (or inter-enterprise) business processes.

Rationale: Service orientation delivers enterprise agility and Boundaryless Information Flow.

Type of Values: Efficiency. Efficiency is about doing the thing right, or performing in the best possible manner with the least waste of time and effort. This principle does refer to agility (low response time) and easy information flows, which implies efficiency.

6.3.7 Principle 7: Compliance with Law

Statement: Enterprise information management processes comply with all relevant laws, policies, and regulations.

Rationale: Enterprise policy is to abide by laws, policies, and regulations. This will not preclude business process improvements that lead to changes in policies and regulations.

106

Mohammad Esmaeil Zadeh 2014

Type of Values: Acceptability. This principle checks that the system conforms to formal laws, and whether it is suitable for people to use them.

6.3.8 Principle 8: IT Responsibility

Statement: The IT organization is responsible for owning and implementing IT processes and infrastructure that enable solutions to meet user-defined requirements for functionality, service levels, cost, and delivery timing.

Rationale: Effectively align expectations with capabilities and costs so that all projects are cost-effective. Efficient and effective solutions have reasonable costs and clear benefits.

Type of Values: Efficiency and Effectiveness. This is a broad principle which determines what the IT function must achieve (capability and capacity), and how to achieve it (sufficiency and safety). Perhaps it could be more cleanly expressed, avoiding mixing two values, so that performance against it can be measured unambiguously.

6.3.9 Principle 9: Protection of Intellectual Property

Statement: The enterprise’s Intellectual Property (IP) must be protected. This protection must be reflected in the IT architecture, implementation, and governance processes.

Rationale: A major part of an enterprise’s IP is hosted in the IT domain.

Type of Values: Efficiency. A feature of an efficient system is to avoid wasting resources in recovering from mistakes or loss. In this case, the loss is intellectual property, which can involve expensive human capital.

6.3.10 Summary of the discussions

This exemplar study shows how the proposed definition of EAPs, and regarding them as values, helps in better analysing and classifying them. Value is a concept which is usually used in governance, while principle is mostly used in architecture. The new definition might also be used to show whether some concepts of governance and architecture overlap, and whether it can be used as a foundation for discussing the relation between governance and EA. In addition, the results of the more developed theories of governance can be used in developing EAPs

107

Mohammad Esmaeil Zadeh 2014

6.4 Mapping TOGAF’s principles to the proposed design principles

In this section, the nine TOGAF business-domain principles are each examined in turn, to see how they can be related to cybernetic concepts; and to determine to which design principles they refer. In order to avoid repeating the description of the TOGAF’s principles, only the names of the principles are presented here. For each principle, an analysis of how the principles can be mapped to the concepts of cybernetics and our design principles is given. The mapping may not be one-to-one; that is, one fundamental cybernetics concept may have explanatory power for one or more EAP. Based on the results of the analysis, one or more design principle/s derived from the VSM will be proposed.

Table 6-2 shows a summary of the comparison between the EAPs of TOGAF and the related design principles. The following paragraphs give the analyses of these TOGAF business principles through the concepts of cybernetics or VSM/ VGM.

Table 6-2- Mapping TOGAF’s business EAPs to VSM-derived EAPs

EAPs (Business) - TOGAF Design Principles - VSM

1. Primacy of Principles Recursion

2. Maximize Benefit to the Enterprise Cohesion, Value Creation

3. Information Management is Everybody’s Business Cohesion, Coordination

4. Business Continuity Viability, Value Preservation

5. Common Use Applications Cohesion, Coordination

6. Service Orientation IT/Business Alignment, Core IT

7. Compliance with Law Compliance, Audit

8: IT Responsibility IT/Business Alignment, Core IT

9: Protection of Intellectual Property Value Preservation

108

Mohammad Esmaeil Zadeh 2014

6.4.1 Principle 1: Primacy of Principles

The VSM is based on the concept of viability. That is, to remain viable and thus to survive, an organisation must comply with the laws and principles embodied in the VSM. Furthermore, because the VSM is a recursive model, all the subsystems of a viable system must comply with the same invariant principles as the containing system. Therefore, if the principles of cybernetics are used to derive a set of principles for EA, these principles must apply to all organisations within the enterprise.

Design principle: Recursion: All embedded organisational units of the enterprise must comply with these principles.

6.4.2 Principle 2: Maximize Benefit to the Enterprise

This principle can also be mapped to the concept of viability. Stafford Beer stated that “the viable system is a system that survives. It coheres; it is integral” (Beer, 1979). That is, the enterprise and its embedded business units or service units must act in a coherent and integrated manner. Furthermore, when describing the embedded organisational units, Beer noted that one of the primarily purpose of the enterprise is to “get the most out of … [the sub-units] … as the systemic machinery can deliver” (Beer, 1979). That is, the VSM seeks to ensure that the whole is more than the sum of its parts by exploiting organisational synergies. Therefore, decisions related to information management should optimise value (benefits) at the enterprise level, rather than business-unit level.

Design principle: Cohesion: Synergies across the various business units are exploited to ensure that the enterprise as a whole delivers more than the sum of its parts.

Design principle: Value Creation: All resources in the organisation are directed and controlled to achieve viability through the creation of value that is meaningful to key stakeholders.

6.4.3 Principle 3: Information Management is Everybody’s Business

The Viable System Model provides multiple mechanisms for ensuring both the horizontal and vertical integration of the enterprise. Vertical integration is ensured through the recursive nature of the model, which facilitates the negotiation of objectives and resources between management units at different layers of recursion. Horizontal

109

Mohammad Esmaeil Zadeh 2014

integration is facilitated through the coordination function, which requires sub- organisational units at the same recursive layer to negotiate and coordinate their activities such that they collectively optimise the enterprise as a whole. Consequently, the VSM promotes the participation of all relevant major organisational units in key management decisions, including those related to the management of IT. The VGM details the specific mechanisms that may be used for the governance of IT within a complex, multi-tiered enterprise.

Design principle: Cohesion: Synergies across the various business units are exploited to ensure that the enterprise as a whole delivers more than the sum of its parts.

Design principle: Coordination: Organisational synergies are promoted through the coordination of the activities of the enterprise and business-unit groups.

6.4.4 Principle 4: Business Continuity

A viable system is one that is able to survive and thrive in its given environment. An important cybernetic concept embedded in the VSM is that of homeostasis. Homeostasis refers to the capacity of a system to maintain certain key parameters (e.g., cash flow in the case of a commercial enterprise) within a defined range despite disturbances or shocks in the environment. That is, a viable system has mechanisms in place to absorb and recover from disturbances in its environment. Within the VGM, the viability of an organisation is realised through two concepts: value creation and value preservation (Millar, 2009). Provided the organisation continues to contribute value to its environment (that is, external stakeholders), despite disruptive influences, its survival is assured. In the context of IT, value preservation, or risk management, encompasses the objectives of business continuity.

Design principle: Viability: Viability (survival) is the ultimate goal of the enterprise.

Design principle: Value Preservation: The ongoing survival of the organisation is preserved by managing the risks that impact its value proposition.

6.4.5 Principle 5: Common Use Applications

As discussed previously, one of the key objectives of the VSM is to ensure that the enterprise as a whole delivers more than the sum of its parts. That is, the VSM seeks to

110

Mohammad Esmaeil Zadeh 2014

exploit synergies across its component parts through the functions of cohesion (System 3) and coordination (System 2). Within the IT domain, synergies or savings are realised through the use of common applications, as limited skills and resources being shared across the enterprise. In terms of variety engineering, the complexity of the internal environment is significantly reduced through reduction in the number of disparate and incompatible systems that need to be built, operated and maintained. Within the business domain, synergies are realised through the sharing of business processes and data.

Design principle: Cohesion: Synergies across the various business units are exploited to ensure that the enterprise as a whole delivers more than the sum of its parts.

Design principle: Coordination: Organisational synergies are promoted through the coordination of the activities of the enterprise and business-unit groups.

6.4.6 Principle 6: Service Orientation

In Service Oriented Architecture (SOA) terminology, enterprise services are divided into different categories such as business, data, software, applications and technology services, which are in continuous interaction with each other to improve the management of services in order to create values for the organisation. (Chung & Chao, 2007; Erl, 2008; Lankhorst, 2009; Nurcan et al., 2009; ITIL, 2011a). Van Bon et al. (2012) also emphasise that IT Service Management (ITSM) goes beyond technology to the management of quality of services provided to end customers. These works show clearly that the concept of service orientation is nowadays much beyond the traditional understanding of web services or software services, and is fundamentally realised upon organisational business services.

In the VSM, Stafford Beer made a clear distinction between operational units and service units (Beer, 1979). Operational units comprised the embedded organisational units that were viable systems in their own right. Within an enterprise, the operational units would be the component business units. Service units were organisational groups or departments that existed to provide a service to operational units and their component sub-systems. These include groups such as finance, marketing and human resources. One organisational group that Beer clearly identified as a service unit was the IT department (Beer, 1985). That is, the IT department existed to provide a service to the

111

Mohammad Esmaeil Zadeh 2014

enterprise and its embedded operational units. Therefore, when developing the architecture it is appropriate to design it as services that reflect the business activities that it enables and supports.

There is an exception to this general treatment of IT as a unit providing ‘commodity’ services. In some organisations, IT is a core function. As an example, in Nolan and McFarlan’s (2005) definition, IT is ‘strategic mode’ or core if there is immediate loss of business from its absence within 60 seconds. That is, the information services is what the organisation provides, such as for cloud computing vendors or cyber security firms. In this case, IT is a System 1 or business operations unit; it must be viable in itself. This IT function is directly part of the value chain, also providing a service but to an external customer (“means of delivering value to customers …” OGC, 2007).

Design principle: IT/Business alignment: The primary purpose of the IT function is to enable the enterprise achieve its business objectives through the delivery of proper services.

Design principle: Core IT: Where IT is part of the organisation’s value chain then it is an operational unit and must comply with all the EA principles.

6.4.7 Principle 7: Compliance with Law

An enterprise is just one link in a chain of recursive systems. A business, for example, can be viewed as being contained within a broader industrial or national system, depending on the perspective of the interested observer. Therefore, to remain viable an enterprise must comply with the laws and regulations of its wider systems, otherwise it would lose its legitimacy and therefore its right to exist. Within the VSM, system 5 is responsible for promulgating policy statements that require the enterprise to comply with the objectives and constraints imposed by the broader systems in which the enterprise is embedded. As a critical part of the enterprise, information management processes must also comply with these policy statements. Within the VSM, System 3* (audit) is charged with monitoring the organisation compliance with applicable laws, regulations, and policies.

Design proposition: Compliance: The enterprise, as a whole, complies with legislative, regulatory, and societal obligations, and established policies.

112

Mohammad Esmaeil Zadeh 2014

Design proposition: Audit: The enterprise is able to independently monitor (audit) the performance of its subsidiary units.

6.4.8 Principle 8: IT Responsibility

As discussed above, the commodity IT function must be regarded as a service unit, not an operational unit. The IT department is not an independent “viable” unit because its purpose is to facilitate the operations of other organisational units. Tasked with the responsibility for owning and operating IT processes and infrastructure, it must accomplish its assigned responsibility with the objective of providing solutions that satisfy the needs of the business in a manner that is both effective and efficient. The IT function should be governed at the lowest level with sufficient requisite variety, co- ordinated for efficiency through enterprise-wide policies.

Design principle: IT/Business alignment: The primary purpose of the IT function is to enable the enterprise achieve its business objectives through the delivery of proper services.

Design principle: Core IT: Where IT is part of the organisation’s value chain then it is an operational unit and must comply with all the EA principles.

6.4.9 Principle 9: Protection of Intellectual Property

Viability encompasses the twin concepts of value creation and value preservation. Viability is maintained through the governance mechanisms, as reflected in the VGM. Within a contemporary organisation, a considerable amount of value may be attributed to its Intellectual Property (see e.g. IP Australia, 2014; Andriessen, 2004; Klein, 2009), which is hosted within its IT domain. If IT is more than a service unit because it is part of the enterprise’s value chain (that is, it is core or strategic) then it is a viable system in its own right and so its resources, such as the IP it embodies, should be protected through the architecture of a viable system. Therefore, to preserve this value, the IP of the enterprise must be adequately protected through architecture, implementation, and governance.

Design principle: Value Preservation: The ongoing survival of the organisation is preserved by managing the risks that impact its value proposition.

113

Mohammad Esmaeil Zadeh 2014

6.4.10 Summary of the mappings

It must be noted that the design principles derived in Chapter 5 are highly inter-related. Some principles can be drawn from other principles, some are complementing each other, and some are contradicting. Therefore, each EAP might be related to one or more design principles. Some of these relationships are illustrated in this section.

6.4.10.1 Relationship matrix

The many-to-many relationships in TOGAF and VSM-based design principles can be better demonstrated by the relationship matrix of Table 6-3. In this table, the TOGAF’s principles are put in the rows and the design principles in columns. The row numbers refer to the number of the related TOGAF principle, and the column numbers refer to the number of the design principle in Table 5-2. The cells of this table demonstrate the mapping, with the V, H, M, and L show very high extent, high extent, medium extent, and low extent relationships. The cells with the V entries are those concluded previously in Table 6-2.

Based on the result of this table, it can be concluded that those columns without a V or H are the VSM-based design principles that are not regarded seriously in the example set of TOGAF’s business principles. More specifically, the principles of Autonomy, Resource Management, Performance, and Identity do not have a mapped equivalent in this table. These principles are referred to partially in some of the TOGAF’s principles, marked as M in the table. However, stronger and more specific statements are needed to emphasise the importance of these principles.

114

Mohammad Esmaeil Zadeh 2014

Table 6-3- Mapping matrix of TOGAF’s business principles to the design principles

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Align.

Audit

Identity

Core IT

Viability

Cohesion

Recursion

Black Black Box

Autonomy

Adaptation

Governance Compliance

Performance

Coordination

RequsiteVar.

IT/Bus.

Resource man. Resource

Value CreationValue Value PreservationValue

1 Primacy of Principles M H V L L L L H L L L L L L L L M H

2 Maximize Benefit to the M M M L V L L V M M M L L L M L L L Enterprise

3 Information Management M L H L L L L V H M V M L L M L L L is Everybody’s Business

4 Business Continuity M V L L L V L L L M L L M L H M L L

5 Common Use Applications M L L L L L L V L L V M L L L L L L

6 Service Orientation M L L H L L M L V V M L L L H M L L

7 Compliance with Law M L L L L L L L M M L L L V M L H V

8 IT Responsibility M M L M M L M L V V M L M L M L L L

9 Protection of Intellectual M L L L L V L L M M L M L L M M L M Property

6.4.10.2 Other principles of TOGAF

As an exemplar summary of the mapping, Figure 6-1 shows the schematic relations between the proposed design principles to current concepts in EA. It should be noted that this diagram is only a schematic diagram to show how the different concepts of cybernetics and the EA might be related, not to show that these concepts are equivalent in a one-to-one basis.

115

Mohammad Esmaeil Zadeh 2014

Figure 6-1- Relations between the VSM-based design principles and some concepts of the EA

This figure illustrates that, based on the Law of the Requisite Variety and its resultant organisation’s principles, how the proposed design principles are concluded. These design principles are represented by blue rectangles in this figure. The green rectangles show the IT/IS concepts and their relationship to the VSM-based design principles. The solid and dashed arrows show the direct and indirect relation between these concepts respectively.

Figure 6-1 can be helpful for two main purposes. Firstly, and as the main usage for mapping purposes, it shows to what design principle an existing EAP can be mapped and how to find a VSM-Based equivalent for an EAP. Secondly, This figure shows, based on the relationships between design principles, how they might be related to each other, such as how some of them can be concluded from the others, and in the case of the requirement for reducing the number of principles, how some of these principles can be merged into more general principles.

116

Mohammad Esmaeil Zadeh 2014

These conclusions about the relationships between the design principles are illustrated in Table 6-4 for simplicity. The letters H and M in this table show the high and medium dependencies of the related principles. On the other hand a letter O indicates that the design principles are opposite to each other, meaning that in practice one of them wants to contradict another one. This table is derived based on the concepts of the VSM explained in Chapter 3, and their rationales are not repeated here to avoid duplication.

Table 6-4- the relationships between design principles

EAP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 1 Requisite Variety √

2 Viability H √

3 Recursion H H √ 4 Black Box H H H √ 5 Value Creation H H H M √ 6 Value Preservation H H H M M √ 7 Autonomy H H H H M M √ 8 Cohesion H H H O M M O √ 9 IT/Business alignment H H H H M M O M √ 10 Core IT H H H H H M M M H √ 11 Coordination H H H O M M O H H M √ 12 Resource Management H H H M M M M M M M M √ 13 Performance H H H M M H M M M M M O √ 14 Audit H H H M M M M M M M M M H √

15 Adaptation H H H M M M M O M M M M M M √

16 Identity H H H H M H M M M M M M M M M √ 17 Governance H H H M M H M M M M M M M M M M √ 18 Compliance H H H M M M O H M M M M M M M M H √

117

Mohammad Esmaeil Zadeh 2014

6.5 Validation

6.5.1 Modifications inspired from available EAPs

As it was mentioned before, the DSR is an iterative methodology, meaning that the result of the design phase is changed - maybe several times - according to the results of the evaluation phase. In fact, based on comparison with existing EAPs, the design principles have been modified several times, and the final list of guidelines in Chapter 5 is the result of several iterations during the evaluation phase of the DSR methodology. As an example of the changes, at the beginning of the design phase, the principles of ‘Value Creation’ and ‘Value Preservation’ were only a single principle of ‘Value’:

Design principle: Value: All resources in the organisation must be directed and controlled to achieve viability through the creation and preservation of value that is meaningful to key stakeholders.

However, after several iterations, this principle had to be divided into two new principles, because these two main concepts of viable systems cover many concepts of the EA and therefore, should be emphasised separately.

6.5.2 Modifications inspired from feedback

Besides the modifications motivated by the comparison of the design principles with existing EAPs, there have been other modifications based on the feedback received from presenting them to related professionals. The outcomes of this study have been published as different peer-reviewed conference and journal papers. The first part, which is classifying TOGAF principles according to the types of values, was published in the Journal of Enterprise Architecture, or JEA (Esmaeil Zadeh et al., 2012c), which is a peer-reviewed journal for professionals and academics in the field of EA.

The second part, mapping TOGAF’s principles against the design principles, is published in the HICSS conference (Esmaeil Zadeh et al., 2012a) and with some modifications in the Journal of EA (Esmaeil Zadeh et al., 2012b). Again, these results have been examined by academics and professionals. This examination is part of the validation and publication cycle in the DSR methodology, and the valuable comments and feedback of the reviewers have also been used in modifying the design principles. Some examples of these modifications are explained here:

118

Mohammad Esmaeil Zadeh 2014

1- In the initial list, there was not any principle for Audit. Based on the recommendation of a reviewer, this important principle has been found to be missing in the mapping for principle 7 of the TOGAF set. From there, this important design principle has been added to the design principles set.

2- The initial Name of the design principle 9 was ‘Commodity IT as a service unit’ to distinguish it from the design principle ‘Core IT’. Again based on the recommendation of a reviewer of a submitted paper, it was changed to ‘IT as a service unit’, and then to ‘IT is a service’, to emphasise the strategic role of IT in organisations and the importance of it in gaining competitive advantage. After some other modifications, the current Name of this principle became ‘IT/Business Alignment’ to represent the role of IT as a service unit to support the main operations of the enterprise and to be aligned with the activities of the business units.

3- Initially, the design principle of ‘Resource Management’ included only the IT resources of the organisation. However after the new definition of EA (and based on a valuable comment by a reviewer) this principle has been modified to represent all resources in the organisation.

4- There were also some modifications to the new definitions of EA and EAPs. The current statement of the definition is the result of some modifications based on the comments of the reviewers. In the first version of the definition, there was an ambiguity between different applications of Enterprise Architecture and Enterprise Architecting. Initially they had been regarded as ‘EA as a noun’ and ‘EA as a verb’. However a reviewer of a submitted paper pointed out that although they have different meanings, both of these forms are nouns: that is, EA as a structure of things, and EA as a discipline, respectively. This comment resulted in the modification of the definitions of EA given in Chapter 2.

5- There have been some comments about the mappings too. As an example, Principle 2 of TOGAF, ‘Maximize benefits to the enterprise’, can be mapped to the principle of (sub) Optimisation, as suggested by a professional in this field, which is also validated by the experts in cybernetics (Edward Lewis and Gary Millar, personal communication, 4 February 2012). However, as this principle is

119

Mohammad Esmaeil Zadeh 2014

a concept of Coupling Theory (Lewis, 2013), and not the VSM, it was not included in the design principles set, leaving it as a proper subject for future research.

Based on similar feedback from academic and professional reviewers, there have been other minor modifications, which have been discussed thoroughly for their acceptance and validation. These modifications have been reflected in the set of design principles in Chapter 5. Furthermore, there will be other changes based on the practical cases that will be mentioned in the next chapters.

6.6 Improving the principles set of TOGAF

As a final point it should be noted that the principle set of TOGAF is brought into this framework as an example set only. However, the results of this study can be used to upgrade this set into a more comprehensive and coherent set to be used by Enterprise Architects. This can be done by adding new principles or modifying existing principles to cover the design principles which are missing in Table 6-3, combining principles that refer to the same design principle, and deleting very specific or low level principles. Since the main aim of this chapter is to study the applicability of the proposed design principles to an existing set of EAPs, and not to improve the TOGAF’s principle set, the shortages of this example set are not studied in detail here and can be left as a potential title for further studies.

6.7 Conclusions

This chapter analysed the sample business principles of TOGAF according to the proposed definition of EAPs and the VSM-based design principles. This mapping was part of the evaluation phase of the DSR methodology. Although there is not a one-to-one correspondence between the two sets of principles, the results show that the TOGAF business principles could be examined and interpreted using the design principles.

This study has found that the principles of cybernetics can establish a suitable theoretical foundation for developing a cohesive set of EAPs, for structuring and classifying them, and for determining whether a set of EAPs is consistent, comprehensive and complete.

Moreover, the result of this mapping has been very helpful in translating the proposed design principles to match the IT/IS terminology, which has been used in the iterations

120

Mohammad Esmaeil Zadeh 2014

of the DSR to modify the initial design principles, making them compatible to the existing EAPs.

In the following chapters these design principles will be used as guidelines for proposing, evaluating, and complementing EAPs in practical cases.

121

Mohammad Esmaeil Zadeh 2014

122

Mohammad Esmaeil Zadeh 2014

Chapter 7 Validation of the Proposed Guidelines in

Practical Cases

7.1 Introduction

In deriving the VSM-based design principles in Chapter 5, it was mentioned that they can be used in different manners in proposing, developing, and evaluating a set of principles for an organisation. These design principles can be used as guidelines to propose a comprehensive set of EAPs. They can also be used as a diagnosing tool to check the coherency and completeness of a set of principles.

As the second and third cases of the validation in the DSR methodology, this chapter examines these applications of the design principles in two Australian government Departments.

The results of these studies have been validated by different professionals working in these Departments during several iterations. Moreover, the results of modifications have been reflected in the final list of the design principles too.

7.2 The use of guidelines for proposing EAPs

As mentioned before, the VSM-based guidelines - if customised according to needs and priorities - can be used to propose a set of comprehensive EAPs for organisations. As explained in Chapter5, the process of customisation consists of translation of the generic principles into a language that is understandable by the users and keeping the number of EAPs to a reasonable number by deleting unnecessary principles and merging some redundant ones into more comprehensive EAPs.

In this section, these design principles are used as guidelines to generate a set of customised EAPs for the Australian Taxation Office (ATO). As it will be explained, these EAPs will be used in developing policies for using Cloud Computing in the ATO.

123

Mohammad Esmaeil Zadeh 2014

7.2.1 Cloud Computing in the ATO

Trying to give better services to its customers, the ATO has been revising its EAPs to be more flexible in dealing with new technologies, especially Cloud Computing (Mell & Grance, 2011). Cloud computing is claimed to have many benefits for organisations to support internal and external users and customers (ISACA, 2012c). In order to maximise its benefits, Cloud Computing must not be considered as just a replacement for internal technology solutions. As suggested by ISACA (2012c), Cloud Computing must be planned as a strategic enabler rather than as an outsourcing arrangement or a technical platform. This fundamental concept implies a revision in the organisational EA principles to include Cloud Computing, its benefits and risks, and the concerns that must be considered in its implementation. This revision should include two types of principles: the modified EA principles that justify and motivate the use of Cloud Computing, as well as the principles that consider the requirements for the successful use of Cloud Computing in the organisation. The new set of EA principles must address current issues in the development and use of Cloud Computing.

7.2.2 Developing policies

As the aim of this study is the development of a set of EAPs for the ATO, the topic of Cloud Computing and the procedure for developing policies for using it are not examined in detail here. The development of policies for the use of Cloud Computing in the ATO was done by a team of experts in the ATO, in which I was in charge of developing EAPs. However, it is worth mentioning that this field of IT/IS study is still in its infancy and, based on our Structured Literature Review (SLR), there are not many articles about developing policies in a structured approach, and therefore it could be a proper subject for further research.

Just as an overview, the approach followed by the team in developing policies is as follows: first the ATO’s EAPs were developed based on the generic set of guidelines, the ATO’s business environments, and the recommendations of sound practice given by ISACA (2012a) and the Australian Government Information Management Office (AGIMO, 2011). These EAPs, customised for the special needs of the ATO, are currently being used as the titles for developing policies for the use of Cloud Computing in that organisation. Based on these policies, the business units seeking to make use of

124

Mohammad Esmaeil Zadeh 2014

Cloud Computing then develop their own practices and procedures that are appropriate for their particular circumstances yet comply with the EAPs.

7.2.3 Customisation of the design principles

As mentioned in Chapter 5 for the application of design principles, it must be noted that these design principles need to be customised, which means that different sections are emphasised, de-emphasised, or deleted based on the priorities of that organisation. In other words, not all the design principles need to be used for a specific organisation or for a specific time period. Based on the priorities, requirements, points of view, and external and internal conditions of the enterprise, some principles are selected to provide a guide to sound behaviour most of the time. It is also important to keep the number of EAPs to a reasonable number by deleting unnecessary principles and merging some redundant ones into more comprehensive EAPs.

Moreover, in the case of the ATO, the most emphasised part of the customisation was the translation of the design principles into a language that is understandable by the users, rather than expressing the principles in more formal academic language. This step requires getting familiar with the terminology used in this organisation, and getting them familiar with the terminology used in the design principles. These objectives are gained by various meetings and negotiations with other members of the team, especially with Dr. Yinan (Anna) Yang, the senior Enterprise Architect and Director of eStrategy and iCapability of the ATO.

7.2.4 Procedure for developing ATO’s principles

Based on what was explained previously for the derivation of EAPs and the customisation of the guidelines, the following steps have been followed for the initial set of ATO’s EAPs. First of all, the design principles were presented to the team to introduce the basis of the work to them. Then their concerns and priorities were extracted, which also includes the recommendations of sound practices for implementing Cloud Computing in the literature. Then after a series of meetings and negotiations, seven main EAPs were chosen as the ATO’s new EAPs to satisfy their priorities and concerns. Table 7-1 shows the resultant customised EAPs, endorsed by the practitioners in the ATO, as well as the corresponding initial VSM-based design principles.

125

Mohammad Esmaeil Zadeh 2014

Table 7-1- The ATO’s EAPs and the corresponding design principles

ATO’s EAP EAP’s Rationale Design Principle 1 Compliance: The ATO, as a The ATO is obligated to comply with a range of legislative Compliance whole, must comply with provisions and data and information protection to safeguard legislative, regulatory and business systems and operational environments that interacts government policy with stakeholders. This restriction must not preclude obligations. business process improvements that lead to changes in internal policies and regulations. 2 Business-Driven: Business The ATO is committed to serve its stakeholders and Value benefits and outcomes should communities by optimising business benefits. This includes Creation be the primary drivers for the both tangibles such as Operational Expenditure and Capital use of services and products in Expenditure; and intangibles such as agility, reliability, the ATO. accessibility, scalability, stakeholder confidence and community trust. 3 Service Consistency: What is Services are presented to consumers in a consistent and Black Box important for those business cohesive manner. This means that consumers should only processes using the services of need to present a piece of information to the ATO once. another business line is its Similarly, they must see consistent information no matter interfaces (input and output of what service or channel they are accessing at the time. In information / data) and the using a service, a consumer should not need to know how a relation between them, rather service is delivered. This principle results in the sub- than how the function is principles of service orientation, channel independence, performed. single and consistent face of ATO, and accountability. 4 Sound Governance: The The ATO must implement relevant governance mechanisms Performance ATO must utilise sound to ensure conformance and performance (e.g. supportability, internal quality and reliability and better integration of services) that deliver the performance management to best outcomes to its stakeholders. serve its stakeholders. 5 Risk Management: The ATO When striving to create business benefits, the ATO must Value must ensure that potential ensure that it manages the risks to achieving it objectives, and Preservation risks and threats are identified, the opportunities to that enhance their achievement. understood and treated. 6 Cohesion: All ATO resources Supporting groups must provide the resources that the Cohesion (including IT) must be aligned business lines need to achieve their objectives, without delay to the business objectives and or waste. The business lines must be able to work together so integrated so that its that their actions are mutually compatible. Accordingly, the operations are efficient (low supporting groups and business lines must be able to share delay or error). knowledge (expertise and information) about what resources are needed and how they should be used. 7 Future Capability Building: The ATO must be capable of adapting to new technologies Adaptability The ATO, as a progressive and technology expectations. As the priorities and agency, needs to adapt and requirements of the consumers change, services must be advance its organisational capable of evolving and adapting to meet changing capability to meet new and functionality and capacity needs whilst minimising the risk changing business needs and and impact of change to the service. better serve its communities.

126

Mohammad Esmaeil Zadeh 2014

7.2.5 Validation of the results

The principle set in Table 7-1 is the outcome of team work, constituting professional members of the ATO, directed by Christopher Thorne, and the UNSW Canberra academic members, supervised by Dr. Edward Lewis.

It should be emphasised that these EAPs are the result of several reviews in the design and evaluation cycle of the DSR. At each review, the customised EAPs were given to skilled professionals whose feedback was used to modify the set of design principles. This feedback was mainly from the team of EA experts in ATO leading by Christopher Thorne, and particularly Dr. Anna Yang. In this test case, most of the feedback was reflected in the translation of the design principles into the ATO’s terminology. The important points of the feedback mainly helped in filling the relationships chart of Figure 6-1, which is also useful in grouping or combining principles. However, some of the feedback was used to modify the set of design principles too. As an example, the design principle of Performance was initially in this form:

Design Principle: Quality and Performance Management: The performances of the subsidiary units are monitored properly by the corporate executives against their agreed objectives.

But the professionals of the ATO commented that based on the new thoughts in the governance of organisations, this measurement is not limited to being done only by corporate executives. Therefore the term ‘by the corporate executives’ in the principles was deleted, and the current statement of this design principle has been agreed. The name of this design principle has also been changed to Performance, in order to include all aspects of quality and performance measurement in a brief Name. This kind of feedback has been reflected in the list of guidelines as iterations of the Evaluation cycle of the DSR.

The proposed EAPs are undergoing further work and will be used as policy headlines for the use of Cloud Computing in the ATO (Anna Yang, personal communication, 4 May 2013).

127

Mohammad Esmaeil Zadeh 2014

7.3 Using the guidelines as a diagnosing tool

As the third validation case, the design principles are used as guidelines to investigate an existing set of principles. This can be the validation of the second application of the guidelines, which is their usage as a diagnosing tool. That is, for those organisations that have already developed their EAPs, these guidelines can be used to check that the principles are coherent and comprehensive. Their existing principles can be mapped against these guidelines, and - based on the priorities of the organisation - the missing or redundant EAPs can be extracted, forming a more effective and efficient set of principles.

7.3.1 The DSTO guiding principles

For this purpose, after negotiating with authorities in the Defence Science and Technology Organisation (DSTO), their set of ongoing architecture principles was selected as the test bed for checking the usefulness and usability of the proposed guidelines. At that time, this organisation was developing its strategic plan, which is a four-year strategy for Information Management and Technology (IM&T) capabilities within DSTO. It takes into account a range of external factors and DSTO’s strategic objectives, with the vision of being a world leader in defence science and technology (S&T). Part of this plan is the IM&T guiding principles, which provide guidance on the way IM&T needs to work and operate to achieve its objectives in a science-focused and resource-constrained environment. Table 7-2 is a summary of these principles. When I started to work with this team, they had already developed these principles, and I could use the guidelines only to check the resultant principles. The Name field in Table 7-2 is put in the right column because in the initial list, this field was not included in the principles set. The Name field is a very important part of the definition of principles, which is used to remove any ambiguity in understanding the main concerns of a principle. It shows what part of the principle is important and what the emphasis of the sentence is. Moreover, in the case of mapping, it helps determine which concept of the guidelines it refers to.

The literature also supports the importance of the Name field in the clarification of principles. TOGAF (2012) states that the Name should represent the essence of the rule. Greefhorst and Proper (2010, p. 73) also suggest first formulating other fields of the

128

Mohammad Esmaeil Zadeh 2014

principle, including the statement, rationale and implications, because “Once one knows what to express, and why it is necessary to comply, it becomes easier to produce a catchy phrase as a name that really conveys the intended meaning.” After addition of the names, the new list became more understandable and the objective and intent of each principle is now obvious at the first glance.

Table 7-2- The DSTO IM&T guiding principles

No. Guiding Principle Name

IM&T investment and service delivery are to support S&T collaboration, 1 Supports S&T innovation and DSTO’s strategic priorities.

IM&T services are to be delivered as enterprise-level services, unless 2 Enterprise specifically exempted for S&T requirements.

IM&T services are to balance security and flexibility while meeting S&T 3 Secure and minimum security requirements.

IM&T services are to be high quality and modern, with adoption of 4 Modern commercial version “n-1” or better wherever possible.

IM&T services will leverage leading commercial and Defence services, 5 such as cloud and high performance computing, mobile platforms and Leading wireless networks.

IM&T services will utilise commercial best-practice or defence standards 6 Best-practice wherever possible.

IM&T service delivery is to be aligned to enterprise directions, including 7 Aligned shared services, unless specifically exempted for S&T requirements.

Data, information and knowledge are to be managed and leveraged for 8 Shared sharing and reuse.

Software/hardware reuse is preferred to software/hardware purchase, 9 Reused which is preferred to in-house development.

10 IM&T funding, assets, services and staffing are to be transparent. Transparent

IM&T staff will be highly talented professionals supported with 11 Professional appropriate training and development as managers of IM&T for S&T.

129

Mohammad Esmaeil Zadeh 2014

7.3.2 Common deficiencies in a set of principles

During our study of existing sets of principles, we found that usually there might be different types of limitations:

- Some important principles might be missing. In some cases important principles might not be proposed because their application is not foreseeable in the beginning. Some other principles might be ignored because they seem to be very simple and obvious statements, while they actually are necessary and even obligatory for the organisation.

- Some principles might be duplicated, which means that they refer to the same theoretical concept or organisational concern. These principles can be merged to save in time and space, and to be applicable in more comprehensive situations.

- Some principles might be very low level and are not applicable for broader ranges. By using more general and comprehensive sentences, principles can cover more concerns and situations. In fact, in some cases, principles are expressed in such a low-level way that they resemble only as the Implication parts of a principle, rather than a principle by itself.

- Some principles refer to more than one concept, which causes some difficulties in their implementation and evaluation. If a principle refers to several values, in practice it will be difficult for practitioners to measure its effectiveness and efficiency. As was mentioned earlier, some resources mention that a principle must follow the SMART qualities, that is: Specific, Measurable, Achievable, Relevant, and Time-Framed. Referring to more than one concern violates a principle being specific and measurable, and even achievable.

7.3.3 Mapping the IM&T principles against the design principles

Before doing the diagnosis test, it was emphasised to the professionals of the DSTO that the aim of this report is not to assess the work done by them in the derivation of these principles. Rather, this mapping is just a comparison of their principles with those derived by the cybernetic approach. Therefore, this report does not intend to show that

130

Mohammad Esmaeil Zadeh 2014

the existing principles are weak or unusable, though it could be a basis for modifying them to become a more comprehensive and compact set of principles. On the other hand, the final result of this test, if endorsed by their practitioners, could be regarded as a validation of usability and usefulness of this approach in diagnosing a set of principles.

As the first step, the IM&T principles have been mapped against the set of guidelines to see which design principles they refer to. The result of this mapping is shown in Table 7-3 along with the comments for each one. As expected, it was not a one-to-one mapping, meaning that any of these principles might refer to one or more design principles. Moreover, there are other design principles that are not mentioned in this mapping. This is also because the set of design principles is highly redundant, and not all of them need to be used in a set of principles. Therefore, based on the concerns, priorities, and technical capabilities of this organisation, only the related design principles are selected for this mapping.

Table 7-3- Mapping the DSTO’s IM&T principles against the design principles

IM&T No. Design Principle(s) Comments Principle 1 Supports S&T Value Creation Not comprehensive enough 2 Enterprise Cohesion Could be more general Should be more comprehensive to 3 Secure Value Preservation include other aspects of risk management 4 Modern Performance Partly as an Implication 5 Leading Adaptation Partly as an Implication Performance/ Two different concepts 6 Best-practice Compliance Could be expressed as Implications 7 Aligned IT/Business Alignment - Cohesion/ Resource 8 Shared Could be more general Management Resource Management/ 9 Reused Could be more general Cohesion

10 Transparent Performance An Implication

Performance/ Resource 11 Professional - Management

131

Mohammad Esmaeil Zadeh 2014

The following comments can be given for each item of this table:

1- Principle 1: This principle is an obvious example of the importance of the Name field in the definition of principles. Without the name field, it is not clear exactly that this principle focuses on which part of its statement (i.e. ‘to support’, or ‘collaboration’ or ‘innovation’ and so on). On the other hand, adding the Name field has made it clear that the main goal of this department is to support DSTO’s values, which determines how to create values for this organisation.

2- Principle 2: This principle emphasises the delivery of services in an enterprise- wide priority, which resembles the principle of Cohesion.

3- Principle 3: Security is an essential part of risk management, or value preservation. Therefore this principle refers to the design principle of Value Preservation.

4- Principle 4: This principle determines a quality aspect of the services given by the IT&M. However, the Statement of this principle is not general and refers to more specific cases.

5- Principle 5: Innovation and looking for new and leading services are samples of Adaptation. Again the statement of this principle is very limited for specific cases and times, and therefore suffers from the lack of generality.

6- Principle 6: This principle determines the quality of IM&T services, and refers to the design principle of Performance.

7- Principle 7: Regarding the IT function as a service unit requires that this function acts as a support unit. This principle refers to the design principle of IT/Business Alignment.

8- Principle 8: Sharing resources is a principle that refers to the design principles of both Resource Management and Cohesion. In this specific case, it talks about the data, information and knowledge resources, and using them in a cohesive manner.

132

Mohammad Esmaeil Zadeh 2014

9- Principle 9: This principle specifies the priorities of providing resources for the organisation, and therefore refers to the design principle of Resource Management. However, it also addresses the integration of resources, which is an aspect of Cohesion.

10- Principle 10: An important factor in the process of performance measurement is the transparency of the activities of any organisation. This principle is again an aspect of the design principle of Performance.

11- Principle 11: Technical staffs are important resources in any organisation. This principle clarifies the quality of these resources in the organisation, and therefore could be mapped to the principles of Performance or Resource Management.

7.3.4 Results of the diagnosis

The results of this mapping were sent as a report to Peter Lambert, Deputy Chief Defence Scientist of the DSTO, to be assessed and used by their development team. The analysis of this mapping also includes important comments and suggestions that are explained here.

7.3.4.1 Missing principles

As the results of this mapping show, some important principles seem to be missing in this list. The following comments can be given about these principles:

1- An important principle which is usually part of a set of Architecture principles in nearly all kinds of organisations is “Compliance”. This concept is weakly referred to in principle 6 as defence standards, but it should be more comprehensive to demonstrate the compliance with legislative, regulatory, societal obligations, and established enterprise policies.

2- Principle 3 (as part of the design principle of Value Preservation) can be expanded to underpin “Risk Management”, rather than just security. In this case, it might include all aspects of security, as well as Intellectual Property (IP), Access Control, Business Continuity, and so on.

3- Another principle could be added to cover the Service Consistency (or Black Box) nature of the services. The aim of this principle is to show that in providing

133

Mohammad Esmaeil Zadeh 2014

services, only the output and the quality of the services are important, rather than how they are performed. In the professional literature (especially for the governmental departments), this principle results in the very common principles of ‘Channel Independence’, ‘Single Point of Contact’, ‘Technology Independence’, and even ‘Accountability’. Using this principle is highly dependent on the priorities and the nature of the services of IM&T.

4- The other interesting principle could be derived from the design principle of Autonomy, which in this case emphasises the ‘Subsidiarity Principle’ for granting the maximum level of autonomy to operational units while maintaining their organisational cohesion. It is the key to solving the problem of centralisation and decentralisation in organisations. In practice this generic principle provides the flexibility of delegation of authority to operational units and outsourcing, and can be a justification of using new technologies such as Cloud Computing.

7.3.4.2 Other weaknesses

Beside the principles that are missing, this set of principles also suffers from the following deficiencies:

1- Some of these principles (e.g. principles 5 and 6) are not at the level of a principle; they can be regarded as the implications of more general principles.

2- Some principles (e.g. principles 1 and 6) are a mixture of different issues; and therefore in practice it will be difficult for practitioners to measure their effectiveness and efficiency.

3- Some pairs of principles (e.g. principles 4 and 10, as well as principles 8 and 9) are duplicated statements of the same generic principle.

4- Some of these principles (e.g. principles 4, 5, 8, 9, and 10) should be expressed in a more general and rigorous format, with the current statements as their Implication parts.

If the structure of principles in TOGAF (Name, Statement, Rationale, Implications) is used as the template for representation of principles, some principles can be defined in a more general sense with more comprehensive

134

Mohammad Esmaeil Zadeh 2014

statements, and then in the implication part they can be expanded and explained to cover more objectives. As an example, there can be a principle for quality/performance such as:

Quality (/Modern): IM&T services are to be high quality and modern, with their performance to be measurable.

Then the principles 4, 6 and 10 (and maybe 11) can be regarded as its implications. Similar work can be done for some other principles too, in order to keep their number reasonable.

7.3.5 Evaluation

After sending the report of this diagnosis to the relevant authorities of the DSTO, the feedback received from them indicates that they have been happy with the results of this analysis and will use these comments in the revision of their strategic plan (Peter Lambert, personal communication, 14 Jun. 2013). This positive feedback indicates the usefulness of these guidelines as a useful tool in the diagnosis of a set of principles.

7.4 Conclusion

In this chapter, the design principles derived based on the VSM were used as the guidelines for proposing and diagnosing sets of principles.

First, the proposed set of design principles was customised for deployment in an Australian government Department, primarily for developing a set of policies for implementing Cloud Computing. The result of this work emphasises the importance of customisation and the fact that the set of generic design principles must be precisely translated into a vocabulary that is meaningful to the users. In the second test case, the set of design principles is used to check the completeness and comprehensiveness of an existing set of principles. In both cases, the results support the usefulness and usability of the design guidelines in proposing, developing, and evaluating a set of principles for an organisation, and therefore, could be regarded as validation of the designed artefact in the DSR methodology.

The implication sections of the EAPs still need more attention. As no systemic work could be found to derive the implication parts of principles, some mechanisms must be

135

Mohammad Esmaeil Zadeh 2014

formulated to provide a set of comprehensive and non-redundant set of implications for each EAP. One option is to map COBIT 5 (ISACA, 2012b) or ITIL (2013) processes to the corresponding design principles derived in this paper. In the next chapter, this topic will be studied in more detail.

136

Mohammad Esmaeil Zadeh 2014

Chapter 8 Principles and Other Frameworks

8.1 Introduction

Based on the recommendations of TOGAF, there are four parts in the presentation of principles: the Name, Statement, Rationale, and Implications. Up to this point, the Implication part of the principles has not been investigated in this research. This part of the principles has not received proper attention in the literature either. In TOGAF (2012)’s definition, the Implications part of the principles includes resources required to carry out the principle and the consequences of using the principle (beyond benefits). They address organisation-specific aspects of the EAPs (Greefhorst & Proper, 2011).

In order to find a comprehensive list of Implications for a set of EAPs, we need to know the list of all IT activities (or IT processes) in organisations, and allocate each of them to the related principles. The main sources for listing IT processes are the Control Objectives for Information and related Technology (COBIT; ISACA, 2012a) and the IT Infrastructure library (ITIL, 2013). These two frameworks are the most-widely used frameworks for IT governance and IT Service Management (ITSM), respectively.

As will be explained, the main motivation behind this chapter has been the examination of COBIT and ITIL processes as the Implication parts of principles. However, after starting the study and based on the initial findings, the role of principles in these frameworks, specifically in ITIL, is discovered to need more attention. Principles seem to be important in ITIL, as they are mentioned repeatedly in the description of it; however, there are no principles actually listed as such in this framework. Therefore, this could be the main motivation to expand the application of the VSM-based design principles from EA to other fields of IT management, such as ITSM.

It is worth of noting that both COBIT and ITIL have some references to EA. COBIT 5 has a process for managing EA (APO03). It refers also to EA and architecture principles in the description of “service capabilities enabler” (ISACA, 2012a, p. 83). ITIL also talks about EA, for example in its service design principles (ITIL, 2011b). There is an overlap between EA and service strategy (Lewis, 2013). There are also some publications regarding the relationships between ITIL and EA frameworks such as

137

Mohammad Esmaeil Zadeh 2014

TOGAF (e.g. Thorn, 2007; Vicente 2013a, 2013b; Sante & Ermersj, 2009). All of these works could be regarded as the similarities between EA and other IT management fields such as IT governance and ITSM. These similarities could be regarded as the motivation for using the COBIT and ITIL frameworks in the EA discipline, specifically in proposing the Implication parts of principles, which has not been done yet.

This chapter contains two main parts. In the first part, after a short introduction about the COBIT and ITIL frameworks, the list of processes in these two frameworks is mapped against the VSM-based design principles. The results of these mappings could demonstrate how and to what extent these processes can be used as the implication parts of the principles. It could also examine whether COBIT and ITIL processes are coherent and comprehensive, and which parts of this framework have received less attention, according to the theoretical basis used in this research.

Based on the results of the first part, the second part of this chapter intends to discover the role of principles in COBIT and ITIL and to find whether it is possible to propose a set of principles for ITIL too. This part could also be regarded as another validation of the applicability of the set of guidelines in proposing principles for other IT management disciplines. The results of this approach are given to the professionals in the (ITSM) field as a survey, and the feedback I used as a validation step in the DSR methodology.

8.2 List of IT activities

As a dominant business framework for the governance and management of enterprise IT, COBIT provides a comprehensive process model for IT (ISACA, 2013). Other frameworks or standards typically cover only a sub-set of processes (e.g. development, security, etc.). There is also a comprehensive framework for IT skills – The Skills Framework for the Information Age (SFIA, 2011) which provides recognisable descriptions of the professional skills required by people working in IT. This framework may be of some help in getting familiar with the IT professional skills needed in an organisation. However, it is more about the skills, rather than the processes.

ITIL also provides a comprehensive list of IT services in organisations (ITSM, 2013; Van Bon et al., 2012), which has some commonalities with COBIT. These two frameworks, as the very popular frameworks for IT activities in current organisations,

138

Mohammad Esmaeil Zadeh 2014

could be regarded as the main sources for listing IT activities. In this section, these two frameworks are introduced briefly.

8.2.1 COBIT

COBIT 5, published by the IT Governance Institute and the Information Systems Audit and Control Association (ISACA), is a framework for developing, implementing, monitoring and improving IT governance and management practices (ISACA, 2012a). The following paragraphs, extracted from COBIT (ISACA, 2012a; 2012b), briefly explain this framework.

As a comprehensive framework that assists enterprises in achieving their objectives for the governance and management of enterprise IT, COBIT 5 “helps enterprises create optimal value from IT by maintaining a balance between realising benefits and optimising risk levels and resource use. COBIT 5 enables IT to be governed and managed in a holistic manner for the entire enterprise, taking in the full end-to-end business and IT functional areas of responsibility, considering the IT-related interests of internal and external stakeholders. COBIT 5 is generic and useful for enterprises of all sizes, whether commercial, not-for-profit or in the public sector” (ISACA, 2012a, p. 13).

Figure 8-1- COBIT 5 principles (ISACA, 2012a)

COBIT 5 is built on five basic principles (shown in Figure 8 -1) for governance and management of enterprise IT: “Together, these five principles enable the enterprise to

139

Mohammad Esmaeil Zadeh 2014

build an effective governance and management framework that optimises information and technology investment and use for the benefit of stakeholders” (ISACA, 2012a, p. 14).

8.2.1.1 COBIT 5 process model

COBIT 5 is not prescriptive, but it advocates that enterprises implement governance and management processes such that the key areas are covered, as shown in Figure 8-2. An enterprise can organise its processes as it sees fit, as long as all necessary governance and management objectives are covered. Smaller enterprises may have fewer processes; larger and more complex enterprises may have many processes, all to cover the same objectives.

Figure 8-2- COBIT 5 governance and management key areas (ISACA, 2012a)

COBIT 5 includes a process reference model that represents all the processes normally found in an enterprise relating to IT activities, offering a common reference model understandable to operational IT and business managers: “The proposed process model is a complete, comprehensive model, but it is not the only possible process model. Each enterprise must define its own process set, taking into account the specific situation” (ISACA, 2012a, p. 32).

140

Mohammad Esmaeil Zadeh 2014

In COBIT, processes are one of the seven enabler categories for governance and management of enterprise IT. A process is defined as ‘a collection of practices influenced by the enterprise’s policies and procedures that takes inputs from a number of sources (including other processes), manipulates the inputs and produces outputs (e.g. products, services)’ (ISACA, 2012b, p. 19).

The process model shows stakeholders and goals of the processes. Stakeholders could be internal and external, whose responsibility levels are documented in charts that show who is Responsible, Accountable, Consulted or Informed (RACI). External stakeholders include customers, business partners, shareholders and regulators. Internal stakeholders include board, management, staff and volunteers.

Process goals are defined as ‘a statement describing the desired outcome of a process. An outcome can be an artefact, a significant change of a state or a significant capability improvement of other processes’ (ISACA, 2012b, p.19). They are part of the goals cascade, i.e., process goals support IT-related goals, which in turn support enterprise goals. Process goals can be categorised as: Intrinsic goals, contextual goal, or accessibility and security goals.

At each level of the goals cascade, hence also for processes, metrics are defined to measure the extent to which goals are achieved. Metrics can be defined as ‘a quantifiable entity that allows the measurement of the achievement of a process goal. Metrics should be SMART—Specific, Measurable, Actionable, Relevant and Timely’.

Moreover, each process has a life cycle too, which is “defined, created, operated, monitored, and adjusted/updated or retired”.

8.2.1.2 Good practices

COBIT 5 in its process reference model describes process’ internal good practices in growing levels of detail: practices, activities and detailed activities.

Practices, for each COBIT 5 process, provide a complete set of high-level requirements for effective and practical governance and management of enterprise IT. They are: “Statements of actions to deliver benefits, optimise the level of risk and optimise the use of resources”.

141

Mohammad Esmaeil Zadeh 2014

Activities are the main actions to operate the process and defined as ‘guidance to achieve management practices for successful governance and management of enterprise IT’. They provide the how, why and what to implement for each governance or management practice to improve IT performance and/or address IT solution and service delivery risk.

Detailed activities are further guidance that may be needed in sufficient level of detail for implementation of activities. They are usually obtained from specific relevant standards and good practices (such as ITIL or ISO/IEC 27000, 2012), or developed in the COBIT 5 product family itself.

External good practices can exist in any form or level of detail, and mostly refer to other standards and frameworks. Users can refer to these external good practices at all times, knowing that COBIT is aligned with these standards where relevant, and mapping information will be made available.

One of the guiding principles in COBIT is the distinction made between governance and management, and therefore, COBIT subdivides its processes into two main areas of Governance processes and Management processes. The governance domain contains five governance processes, within each process Evaluate, Direct and Monitor (EDM) practices are defined.

The management area contains four domains of Align, Plan and Organise (APO), Build, Acquire and Implement (BAI), Deliver, Service and Support (DSS), Monitor, Evaluate and Assess (MEA). Each domain contains a number of processes. Figure 8-3 shows the complete set of 37 governance and management processes within COBIT 5.

142

Mohammad Esmaeil Zadeh 2014

Figure 8-3- COBIT 5 process reference model (ISACA, 2012b)

143

Mohammad Esmaeil Zadeh 2014

8.2.2 ITIL

The Information Technology Infrastructure Library (ITIL) is part of a suite of best- practice publications for IT service management (ITSM) that focuses on aligning IT services with the needs of business. The following paragraphs, extracted from the ITIL publications (ITIL, 2011 a, b, c, d, e), describe briefly this framework and its processes.

8.2.2.1 ITIL framework

ITIL is the most-widely accepted approach to ITSM in the world (ITIL, 2013). It provides a cohesive set of best practices, drawn from the public and private sectors internationally. It provides a practical, no-nonsense framework for identifying, planning, delivering and supporting IT services to the business (ibid).

ITIL advocates that IT services must be aligned to the needs of the business and underpin the core business processes. It provides guidance to organisations on how to use IT as a tool to facilitate business change, transformation and growth (Cartridge et al. 2007).

ITIL is not a standard that has to be followed; it is guidance that should be read and understood, and used to create value for the service provider and its customers. However, ITIL underpins ISO/IEC 20000 (ISO/IEC, 2011), the International Service Management Standard for IT service management, although there are some differences between the two frameworks. This means that while ISO/IEC 20000 is a standard to be achieved and maintained, ITIL offers a body of knowledge useful for achieving the standard. (ITIL, 2011b)

While ITIL describes processes, procedures, tasks and checklists that are used by an organisation for establishing integration with the organisation's strategy, they are not organisation-specific. ITIL allows the organization to establish a baseline from which it can plan, implement and measure. It is used to demonstrate compliance and to measure improvement (ITIL, 2011a).

8.2.2.2 ITIL service lifecycle

In its current form (known as ITIL 2011 edition), The ITIL framework is based on the five stages of the service lifecycle as shown in Figure 8-4: “ The service lifecycle uses a

144

Mohammad Esmaeil Zadeh 2014

hub-and-spoke design, with service strategy at the hub, and service design, transition and operation as the revolving lifecycle stages or ‘spokes’. Continual service improvement surrounds and supports all stages of the service lifecycle. Each stage of the lifecycle exerts influence on the others and relies on them for inputs and feedback. In this way, a constant set of check and balances throughout the service lifecycle ensures that as business demand changes with business needs, the services can adapt and respond effectively” (ITIL, 2011b, p.3). ITIL provides a core publication containing best- practice guidance for each stage in an integrated approach, as required by the ISO/IEC 20000 standard specification. This guidance includes key principles, required processes and activities, organisation and roles, technology, associated challenges, critical success factors and risks. The service lifecycle uses a hub-and-spoke design, with service strategy at the hub, and service design, transition and operation as the revolving lifecycle stages or ‘spokes’. Continual service improvement surrounds and supports all stages of the service lifecycle.

The five core guides map the entire ITIL Service Lifecycle, beginning with the identification of customer needs and drivers of IT requirements, through to the design and implementation of the service into operation and finally, on to the monitoring and improvement phase of the service (ITIL, 2013).

Figure 8-4- The ITIL service lifecycle (ITIL, 2011b)

145

Mohammad Esmaeil Zadeh 2014

8.2.2.3 Services in ITIL

Services are a means of delivering value to customers without requiring the customer to own specific costs and risks. Based on this, Service Management is defined as a set of specialised capabilities for delivering value to customers in the form of services.

ITIL is regarded as a good practice framework. Good practices are practices which have gained wide acceptance and adoption. In short, Good Practices have withstood the test of time. Good Practices may come from a number of sources including: Standards, Public frameworks, Academic research, and Proprietary knowledge (ITIL 2011a).

8.2.2.4 ITIL processes

Processes are defined in ITIL as structured sets of activities designed to achieve a specific objective. ITIL addresses a number of specific processes associated with each lifecycle phase, but also discusses processes in terms of their generic structure consisting of (ITIL, 2011a, 2011b):

- Process Control, such as process policies, ownership, documentation, and review programs, etc.

- The Process itself including process steps, procedures, work instructions, roles, triggers, metrics, inputs, and outputs.

- Process Enablers such as resources and capabilities required to support the process.

8.2.2.5 ITIL functions

In addition to the processes, ITIL has several functions which are self-contained subsets of an organisation, intended to accomplish specific tasks. A function is a team or group of skilled people, and the tools or other resources they use to carry out one or more service lifecycle processes and activities. Whereas processes help organisations accomplish specific objectives - often across multiple functional groups - functions add structure and stability to organisations (ITIL 2011a). Functions generally map fairly directly to the organisational chart of an organisation and are usually supported by budgets and reporting structures. Processes, by contrast, typically do not have budgets and reporting structures. ITIL v3 (2011) describes the following functions: service desk,

146

Mohammad Esmaeil Zadeh 2014

technical management, IT operation management, and application management. The whole 26 processes and 4 functions of ITIL v3 (2011) is illustrated in Figure 8-5.

Figure 8-5- ITIL v3 (2011) processes and functions

8.3 Mapping COBIT and ITIL processes against design principles

8.3.1 The procedure for mapping

The work in this study was motivated by the need to investigate the Implication parts of principles. Based on what has been done for the ATO, and as a further step in developing policies, it was necessary to complete the Implication parts of their proposed EAPs. For doing this, we needed to know the list of all IT activities (or IT processes) in this organisation. Since the ATO uses COBIT and ITIL for its IT governance and service

147

Mohammad Esmaeil Zadeh 2014

management, it was a worthwhile idea to check the processes in these two frameworks as potential candidates for listing this part of the principles.

The study started with mapping COBIT processes to the design principles, in order to see as the Implication part of which principle they can be allocated. The result of this mapping is illustrated in Table 8-1 in an ANNL (Lewis, 2013) format. Each row of this table represents a process of COBIT, and the numbers in each cell indicate to what extent this process could be used as the Implication of the related principle.

Table 8-2 also demonstrates a similar study for ITIL processes. In these two tables, the red numbers 7 to 9 indicate the high vulnerability of the process to be used as the Implication of that design principle, with a 9 showing that this principle is the main candidate for that process. The orange numbers 5 and 6 indicate that this process could also be used as the Implication of that principle, but to lower extents. The green numbers 2 and 3 indicate that the process has less relation to the related principle, maybe not suitable for that principle.

The first three principles of Requisite Variety, Viability and Recursion are usually the super set of principles, on which the other design principles are based. These principles are necessary in our list of design principles to complete the set, but they might not be used directly in a customised set of principles.

The rationale behind this mapping, which is not entirely given here for brevity, is similar to what was done for the TOGAF principles and is very obvious from the details of the processes, their name and category, their sub-processes, and their goal and objectives. As an example, the COBIT process APO13 Manage Security is examined here to show how this table is formed.

COBIT 5 (ISACA, 2012b, p.11) defines its Manage Security process as “Define, operate and monitor a system for information security management”. The purpose of this process is to “keep the impact and occurrence of information security incidents within the enterprise’s risk appetite levels” (ibid). This process apparently is about managing risk in the organisation, which is part of the design principle of Value Preservation in our list of design principles, and hence got the number of 9 in the mapping table. However, and as we explained about the relationships between design

148

Mohammad Esmaeil Zadeh 2014

principles, it could also be related to some of other design principles. For example, the sub-process APO13.01 asks for establishing and maintaining an Information Security Management System (ISMS), to enable secure technology and business processes “that are aligned with business requirements and enterprise security management” (ISACA, 2012b, p.113). This statement clearly nominates this process as a proper candidate for the design principle of IT/Business alignment. Similar conclusions can also be reached for the design principles of Value Creation, Cohesion, Core IT, Coordination, Resource Management, Performance, Audit, Adaptation, Governance and compliance. Therefore the related weights for these design principles in the table are 5 or 6. On the other hand, there are few references in this process to the design principles of Black Box, Autonomy and Identity, and therefore they receive a number 3.

Table 8-1- Mapping COBIT processes against the VSM-based design principles

1 1 1 1 1 1 1 1 1 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 EAP

1 Requisite Variety √

2 Viability √ 3 Recursion √ 4 Black Box √ 5 Value Creation √ 6 Value Preservation √ 7 Autonomy √ 8 Cohesion √ 9 IT/Business alignment √ 10 Core IT √ 11 Coordination √ 12 Resource Management √ 13 Performance √ 14 Audit √

15 Adaptation √ 16 Identity √ 17 Governance √ 18 Compliance √

COBIT

149

Mohammad Esmaeil Zadeh 2014

1 1 1 1 1 1 1 1 1 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 EVALUATE, DIRECT AND MONITOR

(EDM) EDM01 Ensure Governance Framework 1 6 6 5 5 3 3 5 3 7 5 3 3 5 6 5 5 9 6 Setting and Maintenance 2 EDM02 Ensure Benefits Delivery 6 6 5 5 9 3 5 3 5 5 3 5 5 5 5 3 7 5 3 EDM03 Ensure Risk Optimisation 6 6 5 3 3 9 3 3 5 5 3 5 7 7 5 3 6 6 4 EDM04 Ensure Resource Optimisation 6 6 5 3 3 5 3 5 5 5 5 9 5 5 5 3 6 5 5 EDM05 Ensure Stakeholder Transparency 6 6 5 5 3 3 5 3 9 5 5 3 7 6 3 3 6 7 ALIGN, PLAN AND ORGANISE (APO)

APO01 Manage the IT Management 6 6 6 5 5 3 3 3 5 9 5 5 5 3 3 5 5 6 6 Framework 7 APO02 Manage Strategy 6 6 5 5 5 5 5 5 9 7 5 5 5 5 7 5 6 5 8 APO03 Manage Enterprise Architecture 6 6 5 5 5 5 5 5 7 5 5 9 5 5 5 5 3 5 9 APO04 Manage Innovation 6 6 5 3 5 5 3 3 5 5 3 5 5 5 9 3 3 2 10 APO05 Manage Portfolio 6 6 5 5 5 5 3 3 9 7 3 7 7 6 7 3 5 3 11 APO06 Manage Budget and Costs 6 6 5 3 7 5 3 3 5 5 3 9 6 5 3 3 6 5 12 APO07 Manage Human Resources 6 6 5 3 3 5 3 5 5 5 3 9 5 5 5 3 5 3 13 APO08 Manage Relationships. 6 6 5 5 5 5 5 5 9 5 5 5 5 5 5 3 5 3 14 APO09 Manage Service Agreements 6 6 5 7 3 3 5 3 9 5 5 3 7 7 5 5 5 3 15 APO10 Manage Suppliers 6 6 5 5 5 9 5 3 7 5 5 5 7 7 6 3 5 7 16 APO11 Manage Quality 6 6 5 5 5 5 3 3 5 5 3 3 9 7 3 5 5 5 17 APO13 Manage Security. 6 6 5 3 6 9 3 3 5 5 5 5 6 6 5 3 5 6 18 APO12 Manage Risk 6 6 5 2 5 9 2 3 5 5 5 3 5 5 5 3 5 6 BUILD, ACQUIRE AND IMPLEMENT

(BAI) 19 BAI01 Manage Programmes and Projects 6 6 5 3 6 6 3 5 7 6 5 5 5 5 9 2 5 3 20 BAI02 Manage Requirements Definition. 6 6 5 5 5 5 5 5 9 5 5 5 3 3 6 2 5 5 BAI03 Manage Solutions Identification 21 6 6 5 5 5 5 5 5 9 5 5 5 5 5 5 2 3 5 and Build 22 BAI04 Manage Availability and Capacity. 6 6 5 5 5 6 5 3 5 5 3 6 9 7 6 5 5 3 BAI05 Manage Organisational Change 23 6 6 5 3 5 5 3 3 6 5 6 3 5 5 9 3 3 5 Enablement. 24 BAI06 Manage Changes 6 6 5 3 5 9 3 3 6 5 5 5 5 5 7 3 5 5 BAI07 Manage Change Acceptance and 25 6 6 5 3 6 6 3 5 6 5 5 3 6 6 9 3 3 5 Transitioning 26 BAI08 Manage Knowledge. 6 6 5 3 5 5 3 5 5 5 5 2 3 3 9 2 7 3 27 BAI09 Manage Assets. 6 6 5 3 6 9 3 5 5 5 5 7 5 5 3 3 3 6 28 BAI10 Manage Configuration. 6 6 5 3 5 6 3 3 9 5 3 5 5 5 2 3 5 6 DELIVER, SERVICE AND SUPPORT

(DSS)

150

Mohammad Esmaeil Zadeh 2014

1 1 1 1 1 1 1 1 1 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 29 DSS01 Manage Operations. 6 6 5 5 5 6 3 3 9 5 5 5 6 6 2 3 3 6 DSS02 Manage Service Requests and 30 6 6 5 5 5 6 5 2 9 5 5 3 5 5 2 3 3 3 Incidents. 31 DSS03 Manage Problems. 6 6 5 5 2 9 2 3 5 5 3 5 7 6 5 2 5 3 32 DSS04 Manage Continuity. 6 6 5 6 5 9 5 2 5 7 5 5 7 7 3 5 5 5 33 DSS05 Manage Security Services. 6 6 5 3 2 9 3 3 5 5 5 5 6 6 5 2 5 7 34 DSS06 Manage Business Process Controls. 6 6 5 3 3 9 3 7 6 5 3 3 5 5 3 3 8 5 MONITOR, EVALUATE AND ASSESS

(MEA) MEA01 Monitor, Evaluate and Assess 35 6 6 5 5 5 6 3 3 6 6 3 6 9 9 5 3 6 7 Performance and Conformance MEA02 Monitor, Evaluate and Assess the 36 6 6 5 3 3 5 5 6 5 5 5 3 9 9 3 2 8 7 System of Internal Control MEA03 Monitor, Evaluate and Assess 37 6 6 5 3 3 5 3 3 5 5 3 3 5 6 6 5 6 9 Compliance with External Requirements

Table 8-2- Mapping ITIL processes against the VSM-based design principles

1 1 1 1 1 1 1 1 1 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 EAP

1 Requisite Variety √

151

Mohammad Esmaeil Zadeh 2014

1 1 1 1 1 1 1 1 1 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 15 Adaptation √ 16 Identity √ 17 Governance √ 18 Compliance √

ITIL

Service Strategy:

Strategy Management 1 6 6 5 5 5 5 5 5 9 5 5 5 5 5 6 5 5 3 for IT Services Service Portfolio 2 6 6 5 5 5 5 5 5 9 5 5 5 5 5 5 5 5 3 Management Financial Management 3 6 6 5 5 5 5 5 5 6 5 5 9 5 5 5 5 5 6 for IT Services 4 Demand Management 6 6 5 5 5 5 5 5 5 5 5 5 5 5 9 5 5 3 Business Relationship 5 6 6 5 5 5 5 5 5 9 5 5 5 5 5 5 5 5 3 Management Service Design:

6 Design Coordination 6 6 5 5 5 5 5 7 5 5 9 5 5 5 5 5 5 5 Service Catalogue 7 6 6 5 5 5 5 5 9 5 5 5 5 5 5 3 5 5 5 Management Service Level 8 6 6 5 5 5 5 5 5 5 5 5 3 9 7 5 5 5 5 Management 9 Availability Management 6 6 5 5 5 9 5 3 5 5 3 5 5 5 5 5 5 3 10 Capacity Management 6 6 5 5 3 3 5 5 5 5 5 7 9 6 5 5 3 3 IT Service Continuity 11 6 6 5 5 5 9 5 2 5 5 3 3 5 5 5 5 5 2 Management Information Security 12 6 6 5 3 3 9 3 2 3 3 3 3 5 5 5 3 5 3 Management 13 Supplier Management 6 6 5 5 6 5 3 2 5 5 3 5 9 7 5 2 5 6 Service Transition:

Transition Planning and 14 6 6 5 3 5 5 3 5 5 5 5 7 5 5 9 3 5 3 Support 15 Change Management 6 6 5 3 5 7 3 5 5 5 5 5 5 5 9 3 5 3 Service Asset and 16 Configuration 6 6 5 5 5 9 3 6 5 5 5 5 6 5 5 3 6 5 Management Release and Deployment 17 6 6 5 5 5 5 5 5 5 5 5 5 9 7 5 5 5 5 Management Service Validation and 18 6 6 5 3 5 5 3 3 5 5 3 3 9 9 5 2 5 5 Testing

152

Mohammad Esmaeil Zadeh 2014

1 1 1 1 1 1 1 1 1 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 19 Change Evaluation 6 6 5 3 9 7 3 3 5 5 3 3 5 5 5 3 5 5 20 Knowledge Management 6 6 5 3 5 5 3 3 5 5 3 5 7 6 9 5 3 5 Service Operation:

21 Event Management 6 6 5 5 3 7 5 5 5 5 5 3 9 7 7 3 5 5 22 Incident Management 6 6 5 5 5 9 5 5 5 5 5 5 7 7 2 3 5 5

23 Request Fulfilment 6 6 5 5 5 7 5 5 7 5 5 5 9 7 5 3 5 5

24 Problem Management 6 6 5 5 5 9 5 5 5 5 5 3 7 7 5 3 3 6 25 Access Management 6 6 5 5 3 9 5 5 5 5 5 5 6 6 3 3 5 5 Continual Service

Improvement (CSI): The seven-Step 26 6 6 5 5 5 9 5 5 5 5 5 5 7 7 5 5 6 5 Improvement Process

8.3.2 The result of mapping

In considering these tables, it should be noted that these mappings do not aim in relating processes to design principles in a one-to-one correspondence, they rather intend to suggest that as the implication part of which principle these processes can be deployed.

The results show that each process can be regarded as the Implication part of at least one, and in some cases more than one, principle. Therefore it helps to find the proper Implications for a principle, if that principle is used in the set of principles of the specific organisation. In practice, choosing to what principle a process is allocated depends on the principle set chosen for the organisation during the customisation. In this case the table helps in selecting the proper principle for each process based on the priorities indicated in the tables.

As an example and based the result of this table, the following Implications can be assigned as the potential Implications of the principle of Value Preservation:

- COBIT processes: EDM03 Ensure Risk Optimisation, APO12 Manage Risk, APO13 Manage Security, APO10 Manage Suppliers, BAI09 Manage Assets, BAI06 Manage Changes ,DSS06 Manage Business Process Controls, DSS04 Manage Continuity, DSS05 Manage Security Services, and DSS03 Manage Problems

153

Mohammad Esmaeil Zadeh 2014

- ITIL processes of: Availability Management, IT Service Continuity Management, Information Security Management, Change Management, Service Asset and Configuration Management, Change Evaluation, The seven-Step Improvement Process, Incident Management, Request Fulfilment, Problem Management, Access Management, and Event Management.

Table 8-1 and Table 8-2 might also be used to check the comprehensiveness and coherency of COBIT and ITIL frameworks. This means that based on the concepts of viable system, these tables might help in discovering the areas in COBIT and ITIL which are not regarded appropriately. By finding these weaknesses we can find how to modify these frameworks, how some of the processes can be merged or regarded as a subset of another process, and how some processes can be simplified or strengthened. They can also be used as a basis for discovering the relationships between COBIT and ITIL processes. Since these suggestions are beyond the scope of this thesis, they are not investigated in this chapter, but they can be regarded as suitable ideas for future works.

8.3.3 Vertical mapping

The mapping could be also done in a vertical way by considering each design principle individually. Here we consider each design principle separately, and check that to what extent the COBIT or ITIL processes can be related to that specific design principle as its Implication part. This study is done for two design principles of Black Box and Performance as examples, and the results are shown in Table 8-3 and Table 8-4. The results are interesting in the way that they show each design principle can be related to nearly all processes. Similar results might also be achieved by performing these mapping for other design principles. This conclusion is the main motivation for extending the application of the design principles to other IT fields, which is explained in details in the next section.

154

Mohammad Esmaeil Zadeh 2014

Table 8-3- An example of mapping design principles against the COBIT processes

Black Performance Box EVALUATE, DIRECT AND MONITOR (EDM)

1 EDM01 Ensure Governance Framework Setting and Maintenance 9 8 2 EDM02 Ensure Benefits Delivery 10 9 3 EDM03 Ensure Risk Optimisation 8 8 4 EDM04 Ensure Resource Optimisation 9 7 5 EDM05 Ensure Stakeholder Transparency 10 10 ALIGN, PLAN AND ORGANISE (APO)

6 APO01 Manage the IT Management Framework 10 9 7 APO02 Manage Strategy 10 10 8 APO03 Manage Enterprise Architecture 10 10 9 APO04 Manage Innovation 9 9 10 APO05 Manage Portfolio 9 9 11 APO06 Manage Budget and Costs 8 6 12 APO07 Manage Human Resources 8 6 13 APO08 Manage Relationships. 10 10 14 APO09 Manage Service Agreements 10 10 15 APO10 Manage Suppliers 10 9 16 APO11 Manage Quality 10 10 17 APO13 Manage Security. 10 10 18 APO12 Manage Risk 9 9 BUILD, ACQUIRE AND IMPLEMENT (BAI)

19 BAI01 Manage Programmes and Projects 9 9 20 BAI02 Manage Requirements Definition. 10 10 21 BAI03 Manage Solutions Identification and Build 10 10 22 BAI04 Manage Availability and Capacity. 10 10 23 BAI05 Manage Organisational Change Enablement. 10 10 24 BAI06 Manage Changes 10 10 25 BAI07 Manage Change Acceptance and Transitioning 10 9 26 BAI08 Manage Knowledge. 9 9 27 BAI09 Manage Assets. 10 10 28 BAI10 Manage Configuration. 10 10 DELIVER, SERVICE AND SUPPORT (DSS)

155

Mohammad Esmaeil Zadeh 2014

29 DSS01 Manage Operations. 10 10 30 DSS02 Manage Service Requests and Incidents. 10 10 31 DSS03 Manage Problems. 10 9 32 DSS04 Manage Continuity. 10 10 33 DSS05 Manage Security Services. 9 9 34 DSS06 Manage Business Process Controls. 10 9 MONITOR, EVALUATE AND ASSESS (MEA)

MEA01 Monitor, Evaluate and Assess Performance and 35 10 10 Conformance MEA02 Monitor, Evaluate and Assess the System of Internal 36 10 10 Control MEA03 Monitor, Evaluate and Assess Compliance with Ext. 37 10 10 Requirements

Table 8-4- An example of mapping design principles against the ITIL processes

Black Box Performance

Service Strategy:

1 Strategy Management for IT Services 10 10

2 Service Portfolio Management 10 10

3 Financial Management for IT Services 8 7 4 Demand Management 10 8 5 Business Relationship Management 10 10 Service Design:

6 Design Coordination 10 10 7 Service Catalogue Management 10 10 8 Service Level Management 10 10 9 Availability Management 10 10 10 Capacity Management 10 10 11 IT Service Continuity Management 10 10 12 Information Security Management 0 9 13 Supplier Management 10 9 Service Transition:

14 Transition Planning and Support 9 9 15 Change Management 10 10

156

Mohammad Esmaeil Zadeh 2014

16 Service Asset and Configuration Management 10 10

17 Release and Deployment Management 10 10 18 Service Validation and Testing 10 10 19 Change Evaluation 10 10 20 Knowledge Management 8 8 Service Operation:

21 Event Management 10 8 22 Incident Management 10 9

23 Request Fulfilment 10 10

24 Problem Management 10 9

25 Access Management 10 10 Continual Service Improvement (CSI):

26 The seven-Step Improvement Process 10 10

8.4 Developing principles for ITIL

The results of the previous section indicated how the IT processes in ITIL and COBIT might be categorised as the Implication parts of the principles. Briefly, these mappings show that:

- Each COBIT and ITIL process can be deployed as the implication part of at least one principle

- Each design principle might be related to all COBIT and ITIL processes.

The fact that the COBIT and ITIL processes can be covered by the set of design principles will raise the question of whether we can propose a set of principles to represent these frameworks, specifically the ITIL.

ITIL has been shown to be a very powerful and largely accepted framework for ITSM. Principles seem to be important in ITIL too, as they are mentioned in the description of nearly all of its sections and processes; however, there are no principles actually listed as such in this framework.

There are some principle-based standards and frameworks for IT and other disciplines, such as ISO/IEC 38500 for corporate governance of IT (ISO/IEC, 2008), ISO/IEC 42010 for EA (ISO/IEC, 2010), and ISO 31000 for Risk Management (ISO, 2009). As an

157

Mohammad Esmaeil Zadeh 2014

example, ISO/IEC 38500 consists of six principles for the corporate governance of IT. Other frameworks and standards usually refer to this standard and its principles as a reference. In these principle-based standards and frameworks, instead of worrying about the detail of how things have to be done, principles do tell you what the desired outcomes of actions are but free you to achieve them however you wish.

8.4.1 Possible uses of principles in ITIL

Principles are guides about what is good practice in most circumstances and conditions. In ITIL, principles can be considered from two main aspects. First, they can change ITIL into a principle-based framework. In that case, there will be a set of principles for ITSM, and the resultant processes and their details can be regarded as their Implications in different levels of granularities. This means that the set of processes completes the principles during the organisation-specific customisation of these principles.

Principles can also be deployed in ITIL as a measuring tool to assess the performance or quality of IT services. In this application, the principles are used as a basis to check how the units and individuals comply with the processes and how mature the organisation is in regards to its ITSM. This means that in representing the ITSM of the organisation by a set of principles, you might be able to check the ITSM’s maturity of the organisation by using this set of principles.

The question now is how a set of comprehensive principles can be developed for ITIL. The proposed set of VSM-based principles is very generic and can be modified for other information management systems as well. Moreover, as the results of the mappings show, these design principles are highly related to the processes in ITIL and could be deployed for representation of these processes. We need only to customise them, which means to select the most related principles, merging some of them, ignoring the less related ones, and changing them into the language suitable for ITSM. In fact, based on the confirmation of the mappings, we are extending the approach that was carried out for EA to other fields of IM.

158

Mohammad Esmaeil Zadeh 2014

8.4.2 Proposed set of principles for ITIL

After investigating the main concerns of the ITIL and consulting with ITSM professionals (Justin Gasparre, personal communication, 10 September 2013), the nine principles listed in Table 8-5 have been chosen for ITIL as a sample set. These principles can represent almost all aspects of ITIL, with the capability of covering the other design principles.

Table 8-5- The proposed principles for ITIL

All resources in the organisation are directed and controlled to 1 Value Creation achieve viability through the creation of value that is meaningful to key stakeholders. Value The ongoing survival of the organisation is preserved by 2 Preservation managing the risks that impact its value proposition. What is important for those using the services of any organisational unit is its interfaces (input and output) and the 3 Black box relation between them, rather than how the function is performed. Synergies across the various business units are exploited to 4 Cohesion ensure that the enterprise as a whole delivers more than the sum of its parts. The primary purpose of the IT function is to enable the IT/Business 5 enterprise achieve its business objectives through the delivery alignment of services that fit for purpose. Resource Resources are allocated by corporate executives in such a way 6 Management as to maximise business value. The performances of the subsidiary units are monitored 7 Performance properly against their agreed objectives. 8 Adaptation The enterprise is enabled to adapt to its changing environments The enterprise, as a whole, complies with legislative, 9 Compliance regulatory, and societal obligations, and established enterprise policies.

8.4.3 Evaluation of the proposed principles

8.4.3.1 The survey

As has been emphasised several times in this thesis, the Evaluation phase of the DSR methodology has significant importance in measuring the functionality of the artefacts in

159

Mohammad Esmaeil Zadeh 2014

solving the problem. As the last verification of the DSR in this research, these proposed ITIL principles are evaluated by experienced professionals in order to determine their accuracy and applicability in practice. For this purpose, professional members of the IT Service Management Forum (itSMF, 2013) were chosen to evaluate them through a survey. A short questionnaire about the possible use of principles in ITIL was prepared (Annex 1), and the application for ethics approval was granted (Approval number A-13- 33). The results of the mapping, along with the proposed principles for ITIL and the short questionnaire have been sent to their representative, Mr Justin Gasparre, the programme organiser of the ACT branch seminar of the itSMF. He proposed to have a meeting with me and my supervisor Dr. Edward Lewis on Friday, 18 September 2013 at 10 am. In this meeting, the intentions and background of the work were explained to him. After some suggestions for modifying the principles and the mapping table, the final list of ITIL principles and the questionnaire were finalised. As an example, Justin was interested in using the principle of Black Box in the list of ITIL principles, although it was not included initially in the proposed list. However, he emphasised customising this principle into the proper language for ITIL in future works.

It was also decided that for simplicity, the limited mapping of principles against the ITIL processes, as shown in Table 8-6, is given to the professionals. In this table, the H, M, and L show high, medium, and low compatibilities respectively. As for the previous tables, the horizontal line shows that this process can be most likely used as the implementation of each principle. The vertical line shows that for a specific principle, which processes could be used as the concerns (requirements) of that principle.

As an introduction to the survey, the structure of the work, and the theory and rationale behind it, were explained to the participants in the survey during a presentation. The presentation was given during the quarterly seminar of the ACT branch of the itSMF on Wednesday, 2 October 2013 at 2 pm in the Commonwealth Scientific and Industrial Research Organisation (CSIRO) Discovery Centre in Canberra, which about 30 members of the itSMF attended. It was also emphasised in this presentation that the main aim of this research is to evaluate the usability and usefulness of principles in ITIL, and that the results of this survey are going to be used only for academic purposes.

160

Mohammad Esmaeil Zadeh 2014

After the presentation, the questionnaires were distributed. Some members had comments and questions about the approach, that were discussed in the meantime..

Table 8-6- Mapping ITIL process against the proposed principles for ITIL

1 2 3 4 5 6 7 8 9

EAP

1 Value Creation √

2 Value Preservation √

3 Cohesion √

4 Black Box √

5 IT/Business alignment √

6 Resource Management √

7 Performance Management √

8 Adaptation √

9 Compliance √

ITIL

Service Strategy:

1 Strategy Management for IT Services M M M M H M M M L 2 Service Portfolio Management M M M M H M M M L 3 Financial Management for IT Services M M M M M H M M M 4 Demand Management M M M M M M M H L 5 Business Relationship Management M M M M H M M M L Service Design:

6 Design Coordination M M H M M M M M M 7 Service Catalogue Management M M H M M M M L M 8 Service Level Management M M M M M L H M M 9 Availability Management M H L M M M M M L 10 Capacity Management L L M M M H H M L 11 IT Service Continuity Management M H L M M L M M L 12 Information Security Management L H L L L L M M L 13 Supplier Management M M L M M M H H M Service Transition:

14 Transition Planning and Support M M M L M H M H L 15 Change Management M H M L M M M H L 16 Service Asset & Configuration Management M H M M M M M M M 17 Release and Deployment Management M M M M M M H M M

161

Mohammad Esmaeil Zadeh 2014

18 Service Validation and Testing M M L L M L H M M 19 Change Evaluation H H L L M L M M M 20 Knowledge Management M M L L M M H H M Service Operation:

21 Event Management L H M M M L H H M 22 Incident Management M H M M M M H L M 23 Request Fulfilment M H M M H M H M M 24 Problem Management M H M M M L H M M 25 Access Management L H M M M M M L M Continual Service Improvement (CSI):

26 The seven-Step Improvement Process M H M M M M H M M

8.4.3.2 Feedback

The questionnaire was sent out to about 30 members of the itSMF, and 21 members returned their responses. Annex 2 contains a summary of the responses collected. Most feedback shows that the professionals were happy about the use of principles in ITIL, both as a basis to change it into a principle-based framework, or as a measuring tool to assess the performance of the services. As a sample, Justin Gasparre, the programme organiser of the ACT branch seminar of the itSMF, in his main feedback said approvingly that: “The principles look good; particularly those described in the Cybernetic Based Design Guidelines” (personal communication, 2 Oct. 2013).

Moreover, the feedback returned from the survey shows that the respondents had positive opinions about the usability of the approach and the proposed principles, with some comments about possible modifications, which are listed here briefly:

- Limiting the number of principles: most of the feedback encouraged limiting the number of principles. The ideal suggested number was not determined unanimously, but on the average it was recommended to be between three to six principles.

- The need for changing the language: some of the respondents emphasised on changing the language of the principles into the common vocabulary used in the ITSM.

- Some editing and comments: Aside from changing the language, there have also been some comments about possible modifications to the proposed principles.

162

Mohammad Esmaeil Zadeh 2014

- The work needed to change the ITIL framework: the main drawback of using principles in ITIL was about the efforts needed for changing it and its publications. Preparing a new version of the framework requires a lot of resources and effort and takes a long time, especially if it is supposed to change the structure of the framework into a principle-based one. Moreover, the changes must be precisely validated to avoid introduction of non-standard principles. There is also a need for preparing organisations for the changes, including new training for professionals and other staff.

On the whole, the results of this study show the possible applicability of the proposed design principles to other fields of IT management. More detailed results can be achieved in future studies in this subject.

8.5 Conclusion

Aiming to study the Implication parts of principles, this chapter investigated the COBIT and ITIL processes and related them to VSM-based design principles. The processes in these two frameworks have been mapped against the principles in different ways. Moreover, a set of principles has been proposed for the ITIL based on the design principles. These principles could be used either to change ITIL into a principle-based standard or as a measuring tool to evaluate the performance and quality of services in this framework.

The results of this study have been evaluated by experienced professionals of the itSMF through a survey (Annex 2). In short, this evaluation shows positive feedback from the respondents about the usefulness and usability of the approach, with some comments for modification and future works. This feedback is regarded as part of the Evaluation phase of the DSR methodology, specifically in a non-EA field of information management.

The next chapter will summarise all the conclusions along with other comments and possible future works for this research.

163

Mohammad Esmaeil Zadeh 2014

[this page is intentionally left blank]

164

Mohammad Esmaeil Zadeh 2014

Chapter 9 Conclusions and Future works

9.1 Introduction

This chapter concludes our journey by summarising the work done in this thesis, examining whether the research needs and objective are met, specifying the contributions made by this study, and addressing the limitations this research had. The chapter will be concluded with some directions for future research.

9.2 Summary

This study aims to define a set of methods, in the form of guidelines, for defining principles of IM, and EA in particular, systematically. The thesis started by investigating the need for action and what we already know in Chapter 1 and Chapter 2. In these chapters, the EA discipline is studied and new definitions are presented to cover the new ideas about EA, which is the planning of all resources in an organisation. After that, different issues in the cluttered field of EAPs are investigated to see its current status and limitations.

Based on this, a new definition of EAPs is proposed that relates them to the concept of values, mainly to overcome the problems from which EAPs have been suffering. As a summary, Chapter 1 and Chapter 2 conclude that the concept of principles in the EA discipline suffers from some limitations, which necessitate guidelines for developing a generic set of principles and a theoretical basis for developing them.

Chapter 3 reviews the concepts of the VSM in order to establish the theoretical basis for this research. It is also shown that the VGM adapts the VSM to one aspect of organisational control, namely IT governance. The review shows that system science and the VSM give us a framework that improves management in any organisation and has a lot to say about structure and how the organisation works, and therefore, could be used as a useful theoretical basis for defining principles for EA, and other IM systems.

165

Mohammad Esmaeil Zadeh 2014

In Chapter 4, after reviewing different research methods in the IS discipline, the DSR as a suitable methodology for conducting this research is explained. The DSR is an iterative methodology that is generally based on the “build” and “evaluate” processes. Among several comprehensive models or processes for conducting the DSR, the Hevner et al. (2004) approach is selected as the basis of this research. The outline of this thesis is also based on different phases of this methodology. It is also explained that the output of this research lies in the category of methods in the potential artefacts of the DSR.

Following these steps and fulfilling the Design step of the DSR methodology, Chapter 5 proposes a set of VSM-based design principles that are fundamental requirements for any viable systems, and therefore must be complied with by the organisation in order to remain viable. The suggested design principles, if customised according to the needs and priorities of the organisation, can be used as methods, in the form of guidelines, in proposing, developing, and evaluating a set of comprehensive EAPs.

Since the Evaluation step of the DSR has significant importance in measuring the functionality of the artefact in solving the problem, the results of this research must be evaluated properly in some test cases. As the first try, Chapter 6 analyses the sample business principles of TOGAF according to the proposed definition of EAPs and the VSM-based design principles. Although there is not a one-to-one correspondence between the two sets of principles, this study finds that the principles of cybernetics could establish a suitable theoretical foundation for developing a cohesive set of EAPs, for structuring and classifying them, and for determining whether a set of EAPs is consistent, comprehensive and complete. The comparison between existing EAPs and the proposed design principles is also helpful in translating the proposed design principles to match the terminology used in the IT discipline. This iterative feature of the DSR methodology is very useful in modifying the initial design principles to make them compatible with the existing EAPs.

Following this step, and as the second and third Evaluation cases of the DSR, in Chapter 7 the proposed design principles are used as the guidelines for proposing and diagnosing sets of principles in practical cases. First, the proposed design principles are

166

Mohammad Esmaeil Zadeh 2014

deployed as guidelines to propose a comprehensive set of EAPs for the ATO. The result of this study emphasises the importance of customisation, and more specifically, translation of the design principles into a vocabulary that is more meaningful to the users. In the second case, the design principles are used as a diagnostic tool to check the coherency and completeness of the IM&T set of principles of the DSTO. The results of these studies are validated by different professionals working in these organisations during several iterations. In both cases, the results support the usefulness and usability of the design guidelines in proposing, developing, and evaluating a set of principles for an organisation, and therefore, could be regarded as validation of the designed artefact in the DSR methodology. Moreover, the suggested modifications are reflected in the final list of the design principles as the feedback in the DSR methodology.

Finally, and as the last Evaluation of the designed artefact in the DSR methodology, Chapter 8 applies the guidelines in non-EA disciplines. Aiming to study the Implication parts of principles, this chapter investigates the COBIT and ITIL processes and relates them to the VSM-based design principles. The processes in these two frameworks are mapped against the design principles in different ways. Based on the results of these mappings, in the second part of this chapter, the VSM-based guidelines are used to propose a set of principles for ITIL. These principles could be used either as a foundation to change ITIL into a principle-based standard or as a measuring tool to evaluate the performance and quality of services in this framework. This study could be a non-EA application of the proposed principles in other IM fields. The results are also evaluated by professional members of the itSMF through a survey, and the feedback is used in the modification of the design principles.

9.3 Meeting the objective and needs

In Chapter 1 it is investigated that the field of EAPs needs guidelines for developing a generic set of comprehensive principles and a theoretical basis for developing them. Based on this investigation, and the gap between what we know and what we should know about the definition, derivation and implementation of EAPs, Chapter 2 set the main question in this research as:

167

Mohammad Esmaeil Zadeh 2014

Is there a theoretical basis for systematic development of EAPs and principles of IM systems in general?

From there, the research objective of this study is defined as:

Using Cybernetic concepts to develop methods for deriving a set of comprehensive principles of EA and IM

Using the DSR methodology and evaluated in different ways by professionals, the achieved results of this thesis indicate that cybernetic concepts, especially those embedded in Stafford Beer’s VSM, can be regarded as a suitable theoretical basis for developing EAPs and other IM principles. Moreover, the set of VSM-based design principles has demonstrated potential functionalities in proposing, developing, and evaluating a set of comprehensive principles, and therefore, can be deployed as methods for the development of EAPs and principles of other IM systems. This means that the main objective of the research, which is finding methods as the artefacts of the DSR, is met also.

9.4 Contributions of this study

The main contribution of this study is the set of VSM-based design principles that are used as methods, in the form of guidelines, for generating a generic set of comprehensive principles for EA and other IM systems. As a way of deriving principles based on the cybernetics and specifically the VSM, this set of design principles has been practically shown to be capable in generating a set of generic principles and in checking the coherency of existing sets of principles, and therefore, are regarded as the DSR methods to answer the question of how a set of EAPs or IM principles are developed or checked for their comprehensiveness.

Besides this, the improvement of EA through principles is another contribution of this study. It is mentioned in Chapter 1 that principles are a pivotal element in the definition and application of EA. The new definitions of EA and of EAPs as values, as well as the use of the guidelines in checking the coherency of a set of EAPs and the use of ITIL and COBIT processes as the Implications of principles, are innovative outcomes that can improve EA in practice. These unique works are beyond the previous works

168

Mohammad Esmaeil Zadeh 2014

done in this discipline, as reviewed in Chapter 2, and can be regarded as the contributions of this thesis and a foundation for future studies and research.

Another important contribution of this study is the application of cybernetics in a new way. In this thesis, the VSM concepts are used in the EA and IM disciplines. In Chapter 1 it is stated that the EA discipline has used the concepts of cybernetics and system thinking in a few studies. However, using cybernetics to propose principles for EA is a novel idea that is put into practice in this research.

The test cases in this thesis can also be regarded as a practical validation of the VGM. The VGM applies the VSM to IT governance, and since its introduction, it has not been tested in experimental cases yet. Since the design principles in this thesis are based on the work done in the preparation of the VGM, the application of the guidelines in practical cases of this thesis validates the functionality of the VGM too.

Finally, the last contribution of this thesis is the introduction of a set of principles for ITIL, which is a non-EA application of the guidelines in other IM fields. There is not a set of structured principles in ITIL actually, in spite of their importance in this framework. The study shows that the set of guidelines could be a proper basis for developing principles in ITIL, which is again a valuable contribution of this thesis.

9.5 Limitations

The main limitation of this research is inherited from the theoretical model used as a basis for it. In Chapter 3 it was stated that the VSM, in spite of its strength and capabilities in dealing with complex organisations, is the subject of some criticism. An important example of the limitations of the VSM is its failure to fully consider the “component parts” from which the sub-systems of the model are constructed: human beings. In another word, the VSM underplays the purposeful role of individuals in organisations, which results in the failure to consider the social and political dimensions of organisations. This limitation might have affected the proposed guidelines too, although it is not reflected in the feedback received during the Evaluation cases. This issue could be a proper topic for future works, as will be explained in more detail in the next section.

169

Mohammad Esmaeil Zadeh 2014

As explained in Chapter 4, IS is an applied research domain that seeks to construct useful artefacts in order to solve problems and guide professionals who do the work in the real world. Usually these problems are at the intersection of people, organisations, and technology. These two facts are the cause of another limitation in this research. This thesis has a practical nature, in which the concepts of theory must be applied in real situations that are not totally under the control of the researcher. During the practical cases in this research, it was found that people working in professional jobs are usually very busy with their ordinary duties and do not have time for academic research. Moreover, and as I myself had experienced during years of working in different sectors of industry, in technical environments this issue is harder since technical staff usually prefer technical works rather than executive or managerial ones. This research encountered a lot of delays because of the long waiting time for getting responses from the target practitioners. In a limited time of a PhD program, this delay has caused a major limitation in the number of trial cases, in which only two Australian federal organisations were tried as the test bed for validating these artefacts, demanding the need for testing the results of this research in more organisations inside and outside Australia.

In short, problems of these types, which are a combination of academic science and practical technology, usually involve some circumstances that are not totally under the control of the researcher. Solving these problems usually requires more time and cooperation from the practitioners, and in the limited time of a PhD program it is very difficult to find more experimental results.

Another limitation of this research is inherited from the theoretical model used as a basis for it. In Chapter 3 it was stated that the VSM, in spite of its strength and capabilities in dealing with complex organisations, is the subject of some criticism. An important example of the limitations of the VSM is its failure to fully consider the “component parts” from which the sub-systems of the model are constructed: human beings. In another word, the VSM underplays the purposeful role of individuals in organisations, which results in the failure to consider the social and political dimensions of organisations. This limitation might have affected the proposed guidelines too, although it is not reflected in the feedback received during the Evaluation cases. This

170

Mohammad Esmaeil Zadeh 2014

issue could be a proper topic for future works, as will be explained in more detail in the next section.

9.6 Future works and research directions

In order to extend the considerable achievements of this research, several ideas could be regarded as its future directions too.

The first suggestion is related to the theoretical basis deployed in this thesis. As explained before, the VSM is the subject of some criticism, such as its aforementioned weakness in dealing with the role of people and politics in organisations. The importance of the role of these parameters in EA and other IM systems demands further research into other sources of cybernetic concepts to compensate for this limitation of the VSM.

From a more general point of view, it could be stated that the VSM is only one branch of cybernetics, which is mainly based on the Law of Requisite Variety. System thinking and cybernetics have more general laws and principles. Another avenue for further research is to investigate other laws and principles of system thinking and cybernetics for defining a more comprehensive and effective set of design principles.

In this way, it might be possible to define some super set of principles, based on which the other design principles are concluded. The same concept of this idea is illustrated in the Figure 6 -1 and Table 6 -4 of Chapter 6, on a limited scale. In other words, we can define a hierarchy of values, starting from this super set of principles, flowing through the design principles and continuing into the processes and procedures and activities, in different levels of detail. In this case, in practice the practitioners can refer to this structure at the level of detail that is needed for their requirements and circumstances.

The work that has been done for ITIL principles could also lead to other directions for the future of this research. The results of Chapter 8 indicate that the proposed design principles could be deployed as the principles for ITIL. However, there is a need for customising these principles, merging them into a more limited number of principles, and translating them into the common language used in the ITSM discipline. Also, these

171

Mohammad Esmaeil Zadeh 2014

results should be evaluated practically by applying them in test cases, such as using them to measure the maturity of an organisation in its ITSM.

The same work can also be done for COBIT. The existing principles in COBIT are mainly for developing this framework, not to make it a principle-based one. Therefore, it could be a good idea to develop a set of principles for this framework based on the methods given in this thesis.

This suggestion can be extended to other fields of IM, such as IT risk management too. ISO 31000 (ISO, 2009) is a principle-based standard that provides principles and generic guidelines on risk management in general. ISO/IEC 27000 (ISO/IEC, 2012) is part of a growing standard series for Information Security Management Systems (ISMS). This standard has some principles, although it is not a principle-based standard either. The outcomes of this research could be used to check these principles and change them into a coherent set. Furthermore, they might be deployed as a basis for relating this series of standards to the general risk management standard of ISO 31000, in order to help establish harmony between the standards.

In Chapter 6 the example set of principles in TOGAF is mapped against the proposed design principles. Besides the conclusions of this chapter as the Evaluation phase in the DSR methodology, it is also shown that the definition of EAPs as values, and the set of VSM-based guidelines, could be used to check the coherency of this example set and to modify it into a reference set to be used by EA practitioners. This objective might be achieved by adding new principles or modifying existing principles to cover the design principles that are missing, combining principles that refer to the same design principle, and deleting very specific or low-level principles in a future study.

Following this approach, and based on the outcomes of Chapter 8, this principle set of TOGAF can be completed by using the processes of COBIT and ITIL as their Implications. This proposal could also be regarded as a foundation for bringing TOGAF and COBIT/ITIL frameworks together. Moreover, the new definition of EAPs as values in Chapter 2 shows how some concepts of governance and architecture overlap and how the results of the more developed theories of governance can be used in developing

172

Mohammad Esmaeil Zadeh 2014

EAPs. All these suggestions might be used as a foundation for discussing the various ideas about the relation between IT governance and EA.

In Chapter 1 it is shown that the literature is very weak about the proper application of principles and demands for systematic works in this field. It is explained that developing principles is not enough without proper implementation of them. In line with this topic, in Chapter 7 it is observed that defining policies for the use of IT and IS has not been studied systematically, and therefore, the final suggestion could be the application of principles as headlines in the development of policies for the use of IT and IS in organisations.

9.7 Conclusions

This chapter summarises the work that has been done in this thesis. Based on this summary and the explanations given, this thesis has met the needs and objective of the research. Within the constraints of a PhD program, the thesis also has made considerable unique contributions to human knowledge, specifically in the IM, EA and cybernetic disciplines, as shown in the outcomes of this study that have been published as conference and journal papers, with even more yet to come.

173

Mohammad Esmaeil Zadeh 2014

174

Mohammad Esmaeil Zadeh 2014

References

ACS. (2012). Discussion Paper: Enterprise Architecture Certification, Inspiring Success, October. Retrieved 30 Jan. 2013 from Australian Computer Society: www.acs.org.au. AGIMO. (2011). “Cloud Computing Strategic Direction Paper: Opportunities and applicability for use by the Australian Government”, version 1.0, April. Retrieved 5 April 2013 from: http://agimo.gov.au/. Aier, S., Fischer, C., & Winter, R. (2011). “Construction and Evaluation of a Meta- Model for Enterprise Architecture Design Principles”. 10th International Conference on Wirtschaftsinformatik, Zurich, Switzerland. Alturki, A., Bandara, W., & Gable, G.G. (2012). Design science research and the core of information systems. Design Science Research in Information Systems. Advances in Theory and Practice. (pp. 309-327): Springer. Alturki, A., Gable, G.G., & Bandara, W. (2011). A design science research roadmap. Service-Oriented Perspectives in Design Science Research. (pp. 107-123): Springer. Andriessen, D. (2004). Making sense of intellectual capital: designing a method for the valuation of intangibles. Routledge. Armour, F.J., Kaisler, S.H., & Liu, S.Y. (1999). A big-picture look at enterprise architectures. IT Professional 1(1), 35–42. AS. (2006). “AS3806: Australian Standard Compliance Programs”, 2nd edition, Sydney, Australia. Ashby, W.R. (1956). An Introduction to Cybernetics. London: Chapman & Hall. Bass, L., Clements, P. & Kazman, R. (2012). Software Architecture in Practice, 3rd edition, Addison-Wesley. Beckford, J. (2002). Quality (2nd ed.). London: Routledge. Beer, S. (1972). Brain of the Firm. London: Allen Lane and Penguin Press. Beer, S. (1979). The Heart of Enterprise. Chichester: John Wiley & Sons. Beer, S. (1981). Brain of the Firm (2nd ed.), Chichester: John Wiley & Sons. Beer, S. (1984). The Viable System Model: Its Provenance, Development, Methodology, and Pathology. The Journal of the Operational Research Society, 35(1), 7-25. Beer, S. (1985). Diagnosing the System for Organizations. Chichester: John Wiley & Sons. Beer, S. (2002). What is cybernetics? Kybernetes, 31(2), 209-219. Benbasat, I., & Zmud, R.W. (1999). Empirical research in information systems: the practice of relevance. MIS quarterly, 23(1), 3-16.

175

Mohammad Esmaeil Zadeh 2014

Benbasat, I., & Zmud, R.W. (2003). The identity crisis within the IS discipline: Defining and communicating the discipline's core properties. MIS quarterly, 27(2), 183-194. Boar, B. H. (1994). Practical Steps for Aligning Information Technology with Business Strategies. New York: John Wiley & Sons. Boar, B. H. (2001). The art of strategic planning for information technology. New York: John Wiley & Sons. Brinkkemper, S. (1996). Method engineering: engineering of information systems development methods and tools. Information and software technology, 38(4), 275- 280. Brocklesby, J., Cummings, S., & Davies, J. (1995). Demystifying the Viable Systems Model as a Tool for Organisational Analysis. Asia-Pacific Journal of Operational Research, 12(1), 65-86. Bucher, T., Klesse, M., Kurpjuweit, S., & Winter, R. (2007). Situational Method Engineering. In Situational method engineering: fundamentals and experiences (pp. 33-48). Springer US. Buckl, S., Matthes, F., & Schweda, C. M. (2009). “A Viable System Perspective on Enterprise Architecture Management”. In SMC 2009: IEEE International Conference on Systems, Man and Cybernetics, pp. 1483-1488. Business Dictionary. (2012). Retrieved 22 Mar. 2012, 2012, from http://www.businessdictionary.com/definition/values.html. Cartlidge, A., Hanna, A., Rudd, C., Macfarlane, I., Windebank, J., & Rance, S. (2007). An introductory overview of ITIL V3. The UK Chapter of the itSMF. Checkland, P. (1980). Are Organisations Machines? Futures, 12(5), 421-424. Chen, D., Doumeingts, G., Vernadat, F. (2008). Architectures for enterprise integration and interoperability: Past, present and future. Computers in Industry, 59(7), 647– 659. Christopher, W.F. (2007). Holistic Management: Managing What Matters for Company Success. Hoboken: John Willey & Sons. Chung, J. Y., & Chao, K. M. (2007). A view on service-oriented architecture.Service Oriented Computing and Applications, 1(2), 93-95. Davis, G.B., & Olson, M.H. (1985). Management Information Systems: Conceptual Foundations, Structure and Development (2nd ed.), New York: McGraw-Hill. Dietz, J. (2006). Enterprise Ontology- Theory and Methodology. Springer Berlin Heidelberg. Dietz, J. (2008). Architecture: building strategy into design. Academic Service, The Hague. EABOK. (2004). Guide to the (Evolving) Enterprise Architecture Body of Knowledge. Draft, A Project of The MITRE Corporation, Editor Dr. Paula J. Hagan, Erl, T. (2008). SOA: principles of service design (Vol. 1). Upper Saddle River: Prentice Hall.

176

Mohammad Esmaeil Zadeh 2014

Esmaeil Zadeh, M., Millar, G., & Lewis, E. (2012a). “Mapping the Enterprise Architecture Principles in TOGAF to the Cybernetic Concepts--An Exploratory Study”. 45th Hawaii International Conference on System Sciences, (HICSS), 4270-4276. Esmaeil Zadeh, M., Millar, G., & Lewis, E. (2012b). Reinterpreting the TOGAF Enterprise Architecture Principles Using a Cybernetic Lens. Journal of Enterprise Architecture, May, 8(2), 9-17. Esmaeil Zadeh, M., Lewis, E., & Millar, G. (2012c). Enterprise Architecture Principles as Values, Journal of Enterprise Architecture, August, 8(3), 24-34. Espejo, R. (1989). The VSM revisited. In R. Espejo & R. Harnden (Eds.), The Viable System Model: Interpretations and Applications of Stafford Beer's VSM (pp. 77- 100). Chichester: John Wiley & Sons. Espejo, R. (2011). “Epistemological considerations of VSM case studies”. Paper presented at the 2011 IEEE International Conference on Grey Systems and Intelligent Services (GSIS), pp. 899-901. Espejo, R., & Gill, A. (1997). The Viable System Model as a Framework for Understanding Organizations. Phrontis Limited & SYNCHO Limited, Retrieved 21 Apr. 2012 from http://www.phrontis.com. Espejo, R., & Reyes, A. (2011). Organizational Systems: Managing Complexity with the Viable System Model. Berlin: Springer-Verlag. Evaleens, J., & Verhoef, C. (2010). The Rise and Fall of the Chaos Report Figures, IEEE Software, Jan/ Feb, 27(1), 30–36. FEA. (2001). A Practical Guide to the Federal Enterprise Architecture, Version 1.1. Retrieved 30 Mar. 2013, from http://www.gao.gov/. Fischer, C., & Gregor, S. (2011). Forms of reasoning in the design science research process. Service-Oriented Perspectives in Design Science Research. (pp. 17-31): Springer. Fischer, C., Winter, R., & Aier, S. (2010). “What is an Enterprise Architecture Design Principle?” In: Lee, R. (ed.) Computer and Information Science 2010. SCI, vol. 317, (pp. 193–205), Springer, Heidelberg. Flood, R. L., & Carson, E. R. (1993). Dealing with Complexity: An Introduction to the Theory and Application of Systems Science (2nd ed.). New York: Plenum Press. Foorthuis, R., Hofman, F., Brinkkemper, S. and Bos, R., (2012). Compliance Assessments of Projects Adhering to Enterprise Architecture, Journal of Database Management (JDM), April-June, 23(2), 44-71. Galliers, R. D., & Land, F. F. (1987). Choosing Appropriate Information Systems Research Methodologies. Communications of the ACM, 30(11), 900-902. Gartner. (2012). Retrieved 23 Apr. 2012, from http://www.gartner.com/it- glossary/enterprise-architecture-ea/. Goldkuhl, G., & Lind, M. (2010). A multi-grounded design research process. Global Perspectives on Design Science Research. (pp. 45-60): Springer,

177

Mohammad Esmaeil Zadeh 2014

Graves, T. (2009). The Service-Oriented Enterprise: Enterprise Architecture and Viable Services. Tetradian Books. Graves, T. (2012). The enterprise as story, The role of narrative in enterprise- architecture. Colchester, England: Tetradian Books. Greefhorst, D., & Proper, E. (2011a): “A Practical Approach to the Formulation and Use of Architecture Principles”. In the 15th IEEE International Enterprise Distributed Object Computing Conference Workshops, EDOCW, pp. 330-339. Greefhorst, D., & Proper, E. (2011b). Architecture Principles: The Cornerstones of Enterprise Architecture. Springer-Verlag Berlin and Heidelberg GmbH & Co. K, Gregor, S. (2002a). Design Theory in Information Systems. Australian Journal of Information Systems, (Special Issue), 14-22. Gregor, S. (2002b). A Theory of Theories in Information Systems. In S. Gregor & D. Hart (Eds.), Information Systems Foundations: Building the Theoretical Base, 1- 20. Canberra: Australian National University. Gregor, S. (2006). The Nature of Theory in Information Systems. MIS Quarterly, 30(3), 611-642. Gregor, S. (2007). Design theory in information systems. Australasian Journal of Information Systems, 10(1). Gregor, S. (2009). “Building theory in the sciences of the artificial”. Proceedings of the 4th international conference on design science research in information systems and technology, (p. 4), May 7–8, Malvern, PA. Gregor, S., & Hevner, A.R. (2013). Positioning and presenting design science research for maximum impact. Management Information Systems Quarterly, 37(2), 337- 355. Gregor, S., & Jones, D. (2007). The Anatomy of a Design Theory. Journal of the Association for Information Systems, 8(5), 312-335. Haki, M. K., & Legner, C. (2012). “New Avenues for Theoretical Contributions in Enterprise Architecture Principles-A Literature Review”. In Trends in Enterprise Architecture Research (TEAR) and Practice-Driven Research on Enterprise Transformation (PRET), 182-197. Springer Berlin Heidelberg. Haki, M. K., & Legner, C. (2013). “Enterprise architecture principles in research and practice: insights from an exploratory analysis”. Proceeding of the 21st European Conference on Information Systems, ECIS 2013. Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design Science in Information Systems Research. MIS Quarterly, 28(1), 75-105. Hevner, A.R. (2007). A Three Cycle View of Design Science Research. Scandinavian journal of information systems, 19(2). Hevner, A., & Chatterjee, S. (2010). Design science research in information systems. Springer. Higgins, J.P.T., & Green, S. (2006). Cochrane Handbook for Systematic Review of Interventions. Edn. 5.0.1. The Cochrane Collaboration (4).

178

Mohammad Esmaeil Zadeh 2014

Hilder, T. (1995). The Viable System Model, Cavendish Software Ltd. Hirschheim, R., & Klein, H.K. (2003). Crisis in the IS Field? A Critical Reflection on the State of the Discipline. Journal of the Association for Information Systems, 4, 237-293. Hoogervorst, A.P. (2009). Enterprise Governance and Enterprise Engineering: Springer Verlag. Hoverstadt, P. (2008). The Fractal Organization: Creating Sustainable Organizations with the Viable System Model, John Wiley & Sons. Hoverstadt, P., & Bowling, D. (2002). Modelling Organisations Using The Viable System Model. Retrieved 28 Apr. 2013, from http://www.fractal-consulting.com. Iivari, J., Hirschheim, R., & Klein, H. K. (1998). A Paradigmatic Analysis Contrasting Information Systems Development Approaches and Methodologies. Information Systems Research, 9(2), 164-193. IP Australia. (2014). “Value of IP rights”. Australian government IP Australia. Available at http://www.ipaustralia.gov.au/understanding-intellectual- property/why-use-ip/value-of-ip-rights/ cited 20 Aug. 2014. ISACA. (2012a). COBIT 5: A Business Framework for the Governance and Management of Enterprise IT. ISACA: Information Systems Audit Control Association, Retrieved 15 May 2013 from: www.isaca.org. ISACA. (2012b). COBIT 5 Enabling processes. ISACA: Information Systems Audit Control Association, Retrieved 15 May 2013 from: www.isaca.org. ISACA. (2012c). “Guiding principles for Cloud Computing Adoption and Use”, An ISACA Cloud Computing Vision Series White Paper, Retrieved 15 May 2013 from: www.isaca.org. ISO. (2009). ISO 31000: Risk Management - Principles and Guidelines. Geneva: International Standards Organisation (ISO). ISO/IEC. (2008). ISO/IEC 38500: Corporate governance of information technology. Geneva: International Organization for Standardization (ISO). ISO/IEC. (2011). ISO/IEC 20000-1: 2011 Information Technology - Service Management - Part 1: Service management system requirements. ISO: International Standardization Organisation, Retrieved 7 Jun. 2013 from http://www.iso.org/. ISO/IEC. (2012). ISO/IEC 27000: Information technology - Security techniques - Information security management systems - Overview and vocabulary (E) Geneva: International Organization for Standardization (ISO). ISO/IEC/IEEE. (2010). ISO/IEC/IEEE 42010: Systems and Software Engineering - Architecture Descriptions, International Organization for Standardization, Geneva: International Organization for Standardization (ISO). ITGI. (2005). Governance of the Extended Enterprise: Bridging Business and IT Strategies. Hoboken, NJ: John Wiley & Sons.

179

Mohammad Esmaeil Zadeh 2014

ITIL. (2011a). ITIL Service Strategy, 2011 edition, Author: Cannon, D., TSO: The Stationery Office, London. ITIL. (2011b). ITIL Service Design, 2011 edition, Author: Hunnebeck, L., TSO: The Stationery Office, London. ITIL. (2011c). ITIL Service Transition, 2011 edition, Author: Rance, S., TSO: The Stationary Office, London. ITIL. (2011d). ITIL Service Operation, 2011 edition, Author: Steinberg, R., TSO: The Stationary Office, London. ITIL. (2011e). ITIL Continuous Service Improvement, 2011 edition, Author: Lloyd, V., TSO: The Stationary Office, London. ITIL. (2013). Official ITIL website. http://www.itil-officialsite.com/ cited 30 Dec. 2013. itSMF. (2013). itSMF: The IT Service Management Forum Australia. From https://www.itsmf.org.au/, cited 14 Sep. 2013. IVM. (2012). The Institute for Value Management, http://www.ivm.org.uk/ cited 28 Mar. 2012. Jackson, M.C. (2000). Systems Approaches to Management. New York: Plenum Publishers. Jackson, M. C. (2003). Creative Holism: Systems Thinking for Managers. Chichester: John Wiley & Sons. Janssen, M., & Kuk, G. (2006). “A Complex Adaptive System Perspective of Enterprise Architecture in Electronic Government”. Presented at the 39th Hawaii International Conference on System Sciences (HICSS), Hawaii. Kandjani, H., Bernus, P., & Nielsen, S. (2013). “Enterprise architecture cybernetics and the edge of chaos: Sustaining enterprises as complex systems in complex business environments”. In IEEE 46th Hawaii International Conference on System Sciences (HICSS), pp. 3858-3867. Kandjani, H., & Bernus, P. (2013). “Sustaining Information Systems as a Discipline: Towards an Evolving Theory of Information Systems Discipline”. In the Proceeding of PACIS 2013 (Paper 263). Kaplan, R. S., & Norton, D. P. (2006). Alignment: Using the Balanced Scorecard to Create Corporate Synergies. Boston: Harvard Business School Press. Kaplan, R. S., & Norton, D. P. (2008). Mastering the management system. Harvard Business Review, 86(1), 62-77. Keeney, R. L. (1992). Value-focused thinking: A path to creative decision making. London: Harvard Univ. Press. Klein, D. A. (2009). The strategic management of intellectual capital. Routledge. Kuechler, W., & Vaishnavi, V. (2008). On theory development in design science research: anatomy of a research project. European Journal of Information Systems, 17(5), 489-504.

180

Mohammad Esmaeil Zadeh 2014

Kuechler, W., & Vaishnavi, V. (2012). A Framework for Theory Development in Design Science Research: Multiple Perspectives. Journal of the Association for Information systems, 13(6). Lankhorst, M. (2009). Enterprise Architecture at Work: Modelling, Communication and Analysis, 2nd edition, (The Enterprise Engineering Series), Springer, Berlin, Germany. Lee, A. (1999). Inaugural Editor’s Comments. MIS Quarterly 23(1), March, v-xi. Leonard, A., & Beer, S. (1994). The systems perspective: Methods and models for the future. AC/UNU Millennium Project. Lewis, E. (2013). Layrib: Planning Viable Systems: http://www.layrib.com/, cited 30 Jan. 2012 Lewis, E., & Millar, G. (2010). The Viable Governance Model: A Theoretical Model for the Corporate Governance of IT. International Journal on IT/Business Alignment and Governance (JITBAG), 1(3), 19-35. Lindstrom, A. (2006). “On the Syntax and Semantics of Architectural Principles”. in Proceedings of the 39th Annual Hawaii International Conference on System Sciences, HICSS '06, 178b-178b. Linkedin. (2014). Could VSM and Enterprise Architecture (EA) be a happy marriage? Available at http://www.linkedin.com/groups/Could-VSM-Enterprise- Architecture-EA-3680613.S.115132855, cited 24 August 2014. March, S. T., & Smith, G. F. (1995). Design and natural science research on information technology. Decision Support Systems, 15(4), 251-266. Markus, M.L., & Majchrzak, A. (2002). A design theory for systems that support emergent knowledge processes. MIS Quarterly, 26(3), 179–212. McKay, J., & Marshall, P. (2005). “A Review of Design Science in Information Systems”. Paper presented at the 16th Australasian Conference on Information Systems. Sydney, Australia, 29 November-2 December. Mell, P., & Grance, T. (2011). The NIST definition of cloud computing (draft). NIST special publication, 800(145), 7, Retrieved 15 May 2013 from http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf . Millar, G. (2009). The Viable Governance Model: A Theoretical Model of IT Governance within a Corporate Setting. DIT Unpublished doctoral dissertation, University of New South Wales, Canberra. Mingers, J., & Rosenhead, J. (2001). An Overview of Related Methods: VSM, System Dynamics, and Decision Analysis. In J. Rosenhead & J. Mingers (Eds.), Rational Analysis for a Problematic World Revisited (2nd ed., pp. 267-288). Chichester: John Wiley & sons. Niemi, E. (2007). “Enterprise Architecture Stakeholders - a Holistic View”. In the proceeding of AMCIS 2007, vol. 41, pp. 2–9. Nightingale, D. (2009). “Principles of enterprise systems. Presented at the Second International Symposium on Engineering Systems”. MIT, Cambridge.

181

Mohammad Esmaeil Zadeh 2014

Nightingale, D. J., & Rhodes, D. H. (2004). “Enterprise systems architecting: Emerging art and science within engineering systems”. In MIT Engineering Systems Symposium, March. Niglas, K.(2001).”Paradigms and methodology in educational research”. European Conference on Educational Research, ECER2001. Lille, 5–8. Retrieved 30 Feb. 2013 from http://www.leeds.ac.uk/educol/. Niglas, K. (1999) Quantitative and Qualitative Inquiry in Educational Research: is there a paradigmatic difference between them? Paper given at ECER 1999 in Lahti. Paper is available electronically in Education-line: http://www.leeds.ac.uk/educol/ Nolan, R., & McFarlan, F. (2005). Information Technology and the Board of Directors, Harvard Business Review, 83(10), 1-10 Nurcan, S., & Schmidt, R. (2009). “Service Oriented Enterprise-Architecture for enterprise engineering introduction”. In 13th IEEE Enterprise Distributed Object Computing Conference Workshops, EDOCW 2009. (pp. 247-253). OGC. (2007). ITIL V3 Glossary of Terms and Definitions, v01, Office of Government Commerce (now UK Cabinet Office). Okoli, C., & Schabram, K. (2010). A Guide to Conducting a Systematic Literature Review of Information Systems Research. Sprouts: Working Papers on Information Systems, 10(26). Retrieved 8 Mar. 2010 from http://sprouts.aisnet.org/10-26 OptLand, M., & Proper, E. (2007). “Impact of principles on enterprise engineering”. Presented at the 15th European Conference on Information Systems. Opt Land, M., Proper, H., Waage, M., Cloo, J., & Steghuis, C. (2008). Enterprise Architecture – Creating Value by Informed Governance. ser. Enterprise Engineering Series. Springer, Berlin, Germany. Orlikowski, W., & Iacono, C. (2001). Research commentary: desperately seeking the ‘IT’ in IT research: a call for theorizing the IT artifact, Information Systems Research, 12(2), 121-134. PEAF. (2011). Product: Governance: Principles, Pragmatic EA Framework (PEAF, Version 2.0.4), Retrieved 23 Apr. 2012 from http://www.pragmaticea.com/. Peffers, K. (2008). Editorial: IS Research Using Theory from Elsewhere. Journal of Information Technology Theory and Application (JITTA), 9(2), 2. Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A Design Science Research Methodology for Information Systems Research. Journal of Management Information Systems, 24(3), 45-77. Perks, C., & Beveridge, T. (2003). Guide to Enterprise IT Architecture, New York, Springer Verlag. Petersen, R. (2004). A Framework for IT Policy Development. EDUCAUSE Review, 39(2), 54-55. Peterson, R. (2004). Crafting Information Technology Governance. Information Systems Management, 21(4), 7-22.

182

Mohammad Esmaeil Zadeh 2014

Principia Cybernetica. (2012). Principle of Suboptimization: http://pespmc1.vub.ac.be/ASC/PRINCI_SUBOP.html, cited January 30, 2012. Pierce, C. S. (1931). Collected Papers. Harshorne, C. and P. Weiss, Eds. Cambridge, MA, Harvard University Press, (1931 - 1935). Proper, E., & Greefhorst, D. (2010): The Roles of Principles in Enterprise Architecture, Trends in Enterprise Architecture Research, (Vol. 70, 57-70): Springer Berlin Heidelberg. Proper, E., & Greefhorst, D. (2011). Principles in an Enterprise Architecture Context, Journal of Enterprise Architecture, 7(1), 8-16. Purao, S. (2002). “Design research in the technology of information systems: Truth or dare”, Unpublished Working Paper, Atlanta. Retrieved 18 Nov. 2013 from http://purao.ist.psu.edu/working-papers/dare-purao.pdf. Radeke, F. (2010). “Awaiting Explanation in the Field of Enterprise Architecture Management”. Presented at the Americas Conference on Information Systems (AMCIS 2010), Lima, Peru. Ralyté, J., Brinkkemper, S., & Henderson-Sellers, B. (Eds.). (2007). “Situational Method Engineering: Fundamentals and Experiences”. Proceedings of the IFIP WG 8.1 Working Conference, 12-14, September 2007, Geneva, Switzerland (Vol. 244). Springer. Richardson, G., Jackson, B., & Dickson, G. (1990). A Principles-Based Enterprise Architecture: Lessons from Texaco and Star Enterprise. MIS Quarterly 14, 385– 403. Rittel, H. W., & Webber, M. M. (1973). Dilemmas in a general theory of planning. Policy sciences, 4(2), 155-169. Robertson, S., & Robertson, J. (2006). Mastering the Requirements Process. Addison- Wesley. Ross, J. W., Weill, P., & Robertson, D. C. (2006). Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Boston: Harvard Business School Press. Rubinyi, P. (1998). Unchaining the Chain of Command. Menlo Park, California: Crisp Publications. Sante, T. V., & Ermersj, J. (2009). TOGAF 9 and ITIL v3, Two Frameworks Whitepaper. Getronics Consulting, OGC, Retrieved 28 Nov. 2013 from http://www.best-management-practice.com/. Schekkerman, J. (2008). Enterprise Architecture Good Practices Guide: How to Manage the Enterprise Architecture Practice. Trafford. Schultz, M. (2007). Architecture principles: Creating the foundation for robust architecture. Retreived 23 Apr. 2012 from http://www.ibm.com/developerworks/library/ar-archprinc/. SFIA. (2011). Skills Framework for the Information Age: SFIA v5. SFIA Foundation.

183

Mohammad Esmaeil Zadeh 2014

Shanks, G., Rouse, A., & Arnott, D. (1993). “A Review of Approaches to Research and Scholarship in Information Systems”. Paper presented at the 4th Australian Conference on Information Systems. Brisbane, Australia. Simon, H.A. (1996). The sciences of the artificial. MIT press. Skyttner, L. (2005). General Systems Theory: Problems, Perspectives, Practice (2nd ed.). Singapore: World Scientific Pub Co Inc. Sonnenberg, C., & vom Brocke, J. (2012). “Evaluations in the science of the artificial– reconsidering the build-evaluate pattern in design science research”. In Design Science Research in Information Systems. Advances in Theory and Practice (pp. 381-397). Springer Berlin Heidelberg. Sowa, J. F., & Zachman, J. A. (1992). Extending and formalizing the framework for information systems architecture. IBM Systems Journal, 31(3), 590-616. Standish Group. (1994). The Chaos Report 1994. Retrieved 21 August 2010 from http://www.standishgroup.com/sample_research/chaos_1994_1.php. Stelzer, D. (2010). “Enterprise Architecture Principles: Literature Review and Research Directions”. Paper presented at the Service-Oriented Computing. ICSOC/ServiceWave 2009 Workshops (pp. 12-21), Springer Berlin Heidelberg. Takeda, H., Veerkamp, P., Tomiyama, T., & Yoshikawam, H. (1990). Modeling design processes. AI Magazine, 11(4), 37-48. Tesch, R. (1990). Qualitative Research: Analysis Types and Software Tools. London: The Falmer Press. Thorn, S. (2007). TOGAF™ and ITIL®. Document No. (W071). The Open Group. TOGAF. (2012). The Open Group Architecture Framework, TOGAF Version 9.1. Retrieved 15 May 2013 from: http://www.opengroup.org/togaf/ Tranfield, D.R., Denyer, D., Smart, P., Bedfordshire, M.K., & Cranfield, M.K. (2003): Towards a methodology for developing evidence-informed management knowledge by means of systematic review. British Journal of Management, 14(3), 207-222. Tweedie, D. (2007). “Keep it simple, stupid, Ken Spencer Memorial Lecture”, Financial Reporting Council, University of Melbourne, 5 March. Retrieved 29 Apr. 2012 from www.frc.gov.au/reports/other/Ken_Spencer_2007.asp. Ulrich, W. (1981). A Critique of Pure Cybernetic Reason: The Chilean Experience With Cybernetics, Journal of Applied Systems Analysis, 8, 33-59. Ulrich, W. (1987). Critical heuristics of social systems design. European Journal of Operational Research, 31(3), 276-283. Vaishnavi, V., & Kuechler, W. (2004). “Design research in information systems,” last updated October 23, 2013. Retrieved 30 Nov. 2013 from http://www.desrist.org/design-research-in-information-systems/ Vaishnavi, V., & Kuechler, W. (2007). Design science research methods and patterns: innovating information and communication technology. CRC Press,

184

Mohammad Esmaeil Zadeh 2014

VAL IT. (2006). Enterprise Value: Governance of IT Investments, The ITGI Val IT Framework. Retrieved 7 Jul. 2010, from http://www.itgi.org. Van Aken, J. E. (2004). Management Research Based on the Paradigm of the Design Sciences: The Quest for Field-Tested and Grounded Technological Rules. Journal of Management Studies, 41(2): 219-246. Van Bommel, P., Hoppenbrouwers, S., Proper, H.A., & Weide, T.P. (2006). “Giving Meaning to Enterprise Architectures: Architecture Principles with ORM and ORC”. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM 2006 Workshops. LNCS, vol. 4278, (pp. 1138–1147). Springer, Heidelberg. Van Bommel, P., Buitenhuis, P., Hoppenbrouwers, S., & Proper, E. (2007). “Architecture principles – A regulative perspective on enterprise architecture”. Presented at the 1st International Workshop on Enterprise Modelling and Information Systems Architectures, EMISA. Van Bon, J., De Jong, A., Kolthof, A., Pieper, M., Tjassing, R., van der Veen, A., & Verheijen, T. (2012). Foundations of IT service management. Van Haren. Vicente, M., Gama, N., & da Silva, M. M. (2013a). Modeling ITIL business motivation model in archimate. Exploring Services Science, 86-99, Springer Berlin Heidelberg. Vicente, M., Gama, N., & da Silva, M. M. (2013b). Using ArchiMate and TOGAF to Understand the Enterprise Architecture and ITIL Relationship. Advanced Information Systems Engineering Workshops, 134-145. Vom Brocke, J., Simons, A., Niehaves, B., Niehaves, B., Reimer, K., Plattfaut, R., & Cleven, A. (2009). “Reconstructing the giant: on the importance of rigour in documenting the literature search process”. Proceeding of the ECIS 2009, (pp. 2206-2217), Verona. Walls, J. G., Widmeyer, G. R., & Sawy, O. A. (1992). Building an Information System Design Theory for Vigilant EIS. Information Systems Research, 3(1), 36-59. Walls, J.G., Widmeyer, G.R., El Sawy, O.A. (2004). Assessing information system design theory in perspective: How useful was our 1992 initial rendition. Journal of Information Technology Theory and Application, 6(2), 43-58. Weber, R. (1987). Towards a theory of artifacts: a paradigmatic base for information systems research, Journal of Information Systems 1(1), 3-20. Webster, J., & Watson, R.T. (2002). Analyzing the past to prepare for the future: Writing a literature review. MIS Quarterly 26(2), 13–23. Wiener, N. (1948). Cybernetics. New York: John Wiley & Sons. Weill, P., & Broadbent, M. (1998). Leveraging the New Infrastructure: How Market Leaders Capitalize on Information Technology. Boston: Harvard Business School Press. Weiss, D. (2006). “Developing Effective Enterprise Architecture Principles”, Gartner for Leaders Series, ID Number: G00142389. Wilkinson, M. (2006). Designing an ‘adaptive’ enterprise architecture. BT Technology Journal 24(4), 81–92.

185

Mohammad Esmaeil Zadeh 2014

Winter, R. (2008): Design science research in Europe. European Journal of Information Systems, 17(5), 470-475. Winter, R., & Fischer, R. (2007). Essential Layers, Artifacts, and Dependencies of Enterprise Architecture. Journal of Enterprise Architecture 3, 1–12. Winter, R., & Aier, S. (2011). “How are Enterprise Architecture Design Principles Used?” Presented at the The 15th IEEE International EDOC Conference Workshops, Trends in Enterprise Architecture Research (TEAR), Helsinki. Zachman, J. A. (1987). A framework for information systems architecture. IBM Systems Journal, 26(3), 276-292.

186

Mohammad Esmaeil Zadeh 2014

Annex 1 ITIL Principles Questionnaire

Introduction

This survey is part of a research program at the UNSW Canberra in order to study the applicability of system thinking and cybernetics, especially the Viable System Model (VSM) in information systems.

As part of this research, a set of methods, in the form of guidelines, guidelines have been proposed that can be used to derive a comprehensive and complete set of principles for any information management system. Adopting the format used by TOGAF for the representation of principles (Name, Statement, Rationale and Implication), the results of this study show that the IT processes in ITIL and COBIT can be categorised as the implication parts of the Enterprise Architecture principles.

ITIL has shown to be a very powerful and largely accepted framework for IT Service Management (ITSM). However it does not have a set of principles based on which the professionals implement and measure the quality of its processes.

The proposed set of cybernetic-based guidelines is very generic and can also be modified for other information management systems as well. As an illustration, a set of principles for the ITIL has been attached. These principles have also been mapped against the ITIL processes in order to find that each process can be used as the implementation part of these principles. The results of this mapping have shown that:

- Each ITIL process can be used as the implication part of at least one principle

- Moreover, each ITIL processes can be related to all principles. This result may lead to the possibility of the representation of ITIL processes by a set of principles.

These results must be evaluated by experienced professionals in order to determine their accuracy and applicability in practice, and therefore, your responses to this survey will be an important contribution to the development of Service Management practice.

For further queries about this study, kindly please contact me at the following address.

187

Mohammad Esmaeil Zadeh 2014

Thanks very much.

Mohammad Esmaeil Zadeh

Room 160, Building 15, SEIT, UNSW Canberra (ADFA)

Northcott drive, Canberra, ACT, 2600

Email: [email protected]

Tel.: 0434198024

For queries about the ethics of this survey, you can contact Dr. Stephen Coleman at: [email protected].

Questions:

The main aim of this survey is to evaluate the accuracy, applicability and usefulness of a set of principles in ITIL by experienced IT professionals. The answers will be used only for academic purposes and will be analysed anonymously. The time you spent and the scrutiny you had in answering these questions are highly appreciated. You can also write your comments about each principle on the attached pages too.

Personal Information:

1- Name (optional):

3- Occupation: Managerial  / Professional 

Technical / Non Technical 

4- Organisation:

In your organisation, can you regard IT as the main output of the organisation  or just as a service unit to facilitate the operation of other units 

5- Years of work experience in IT and ITSM:

6- Years of work experience with ITIL: 7- Do you have an ITIL certificate?

188

Mohammad Esmaeil Zadeh 2014

Use of principles in ITIL

8- What do you think about the use of principles for ITIL? If not a good idea, why?

9- If yes, how many principles do you think should be normally used? Which aspects of SM do you think are the most important ones to be highlighted in ITIL principles?

10- What do you think in general about changing ITIL to a principle-based ITSM?

11- What do you think about changing ITIL structurally to a principle-based one and using current processes as their “Implication” parts?

12- What do you think about keeping the current form of ITIL and using principles only to measure the performance and quality of services?

About the proposed set of principles (attached)

13- To what extent do you think that each of the following principles must be included in the ITIL principles? Strongly Moderately Moderately Strongly Comments/ Neutral Agree Agree Disagree Disagree Suggestions Value Creation: Value Preservation: Black box: Cohesion IT/Business alignment Resource Management: Performance Adaptation: Compliance:

189

Mohammad Esmaeil Zadeh 2014

14- To what extent do you think that the name (title) of each principle is proper? Strongly Moderately Moderately Strongly Comments/ Neutral Agree Agree Disagree Disagree Suggestions Value Creation: Value Preservation: Black box: Cohesion IT/Business alignment Resource Management: Performance Adaptation: Compliance:

15- To what extent are you happy with the statement of the principles? Strongly Moderately Moderately Strongly Comments/ Neutral Agree Agree Disagree Disagree Suggestions Value Creation: Value Preservation: Black box: Cohesion IT/Business alignment Resource Management: Performance Adaptation: Compliance:

16- Do you think this set of principles is enough to represent all concerns in ITIL? If not what aspect of SM is missing in it?

17- What are the strengths and weaknesses of these principles?

18- To what extent do you agree with the result of mapping (attached), you can also write your comments about each of them on that paper too.

19- Any suggestions for making these set of principles better?

190

Mohammad Esmaeil Zadeh 2014

Annex 2 Summary of the Responses to ITIL Questionnaire

In this Annex a summary of the responses to the ITIL questionnaire is presented. The questionnaire was distributed to 30 members of the itSMF, among which 21 members responded. The questions are repeated here to facilitate reading. The answers to those questions which ask for numbers are given in front of them. Some of the returned responses are complete, and some are partially answered. A “-“ in the response field shows that some of the applicants do not answer that particular question. Personal information:

1- Name (optional): -

3- Occupation: Managerial: 4 / Professional: 7

Technical: 6 / Non-Technical: 4

4- Organisation:

In your organisation, can you regard IT as the main output of the organisation: 4, - or just as a service unit to facilitate the operation of other units: 10, -

5- Years of work experience in IT and ITSM: 15+, 14, 40, 3, 25, 25, 17, 2, 1, 22, -

6- Years of work experience with ITIL: 6, 5, 8, 8, 3, 16, 10, 17, 7, -

7- Do you have an ITIL certificate? 9

Use of principles in ITIL

8- What do you think about the use of principles for ITIL? If not a good idea, why?

It is a good idea- as a guidance.

Principles have heuristically developed over time with ITIL implementations.

Principles will vary for the organisation based on its business objectives/outcomes; there must be some generic principles, others subject to the organisation’s circumstances

The current theoretical foundation have been applied retroactively applied to experience resulting in a hodge-podge,

191

Mohammad Esmaeil Zadeh 2014

9- If yes, how many principles do you think should be normally used? 6, 5-10, 3-6, the fewer the better, -

Which aspects of SM do you think are the most important ones to be highlighted in ITIL principles? Principles 1, 3, 4, 5, 9, -

Most of the respondents posit that this question requires further study and investigation in the aspects of the ITIL

10- What do you think in general about changing ITIL to a principle-based ITSM?

It could be good as an example/appendix to have-

It doesn’t go far enough to replace current ITIL

Would reduce the effect of people interpreting ITIL

Needs a lot of work and time, relearning, has negative reactions,

11- What do you think about changing ITIL structurally to a principle-based one and using current processes as their “Implication” parts?

Could be a major change to ITIL, v4 would be a lot of work

Sounds like it may be significantly different and require significant re-learning- this may necessitate calling it something else

12- What do you think about keeping the current form of ITIL and using principles only to measure the performance and quality of services?

This may be a better use of the principles to tie them to an already well known framework.

KPI based models are subject to too much abuse by managers who don’t understand the underlying machinery

192

Mohammad Esmaeil Zadeh 2014

About the proposed set of principles (attached)

13- To what extent do you think that each of the following principles must be included in the ITIL principles?

Strongly Moderately Moderately Strongly Comments/ Neutral Agree Agree Disagree Disagree Suggestions Value Creation: xxxxx xxxxx Value Preservation: xxxx xxxxx Black box: xxxx xxxxx Cohesion xxxx xxx IT/Business alignment xxxxx xx x Resource Management: x xxxxxx xx Performance xxx xxxxx x Adaptation: xxxx xxx xx Compliance: xxxxx xx xx x

14- To what extent do you think that the name (title) of each principle is proper?

Strongly Moderately Moderately Strongly Comments/ Neutral Agree Agree Disagree Disagree Suggestions Value Creation: xxx xxxx x xx Value Preservation: xxx xx xx xx Black box: xx xx xx xxx x Cohesion xxx xx xx x IT/Business alignment xxxx xxxx Resource Management: xxx xxxxx Performance xx xxx xxxx Adaptation: xx xxxxx xx Compliance: x xxxxx xx

15- To what extent are you happy with the statement of the principles?

Strongly Moderately Moderately Strongly Comments/ Neutral Agree Agree Disagree Disagree Suggestions Value Creation: xx xxxxx Value Preservation: xx xxxxx x x Black box: xxxx xxxx xx Cohesion xxx xxxxx x IT/Business alignment xxx xxxx xx x Resource Management: xx xxxx xx x Performance xxxx xxxx x Adaptation: xxxx xxxx Compliance: xxxx xxxx

193

Mohammad Esmaeil Zadeh 2014

16- Do you think this set of principles is enough to represent all concerns in ITIL? 10, -

If not what aspect of SM is missing in it?

Core IT, Audit, Continuous improvement

17- What are the strengths and weaknesses of these principles?

High level principles are easy to understand but don’t always explain things well enough for everyone

Provide direction and focus back to business

They need to be refined to 3-6

Relationships between principles

Adaptation needs to be considered further

Unsure, need to see how they can be implemented into day to day – practical application

18- To what extent do you agree with the result of mapping (attached), you can also write your comments about each of them on that paper too.

Very good

Good idea for transition to a principle-based framework

Almost

Highly

To some extent

The mapping is essentially correct

Reasonable

19- Any suggestions for making these set of principles better?

Black box should cover Modularity.

Cohesion could be replaced by Holism.

ITIL deliberately ignore the law of requisite variety, this is an area that should be fixed.

194

Mohammad Esmaeil Zadeh 2014

Black Box and cohesion are better stated as the balance between Modular and Holistic models

Performance and Value Preservation are also the ends of a spectrum

Some are too wordy- e.g. Value preservation

Require good understanding of language to gauge what they really mean

They must be generic.

The number of principles should be fewer in action.

It would be difficult to have changes in ITIL.

The translation is very important and should be considered in future works.

195

Mohammad Esmaeil Zadeh 2014

[this page is intentionally left blank]

196

Mohammad Esmaeil Zadeh 2014

Annex 3 Example Set of Architecture Principles in TOGAF

TOGAF’s example set of principles consists of 21 principles which are divided into four categories of business principles, data principles, application principles, and technology principles. This Annex is exactly a replication of the example set of architecture principles in TOGAF (2012, pp. 239-250).

197

Mohammad Esmaeil Zadeh 2014