Enterprise Governance and DEMO - ULisboa › downloadFile...Enterprise Governance and DEMO Towards a...

Enterprise Governance and DEMOTowards a reference method to guide the enterprise dynamics by

addressing DEMO’s competence, authority and responsibility notions

Miguel Henriques

Dissertation for the degree of Master in

Information Systems and Computer Engineering

Jury Committee

President: Ph.D. António Manuel Ferreira Rito da Silva

Adviser: Ph.D. José Manuel Nunes Salvador Tribolet

External Adviser Ph.D. Jan Hoogervorst

Evaluation Jury: Ph.D. Artur Miguel Pereira Alves Caetano

November 2010

AbstractThe lack of an organizational competence that embodies the capacity to continuously restrict, from a holistic point of

view, the undesirable strategic, design and operational plane freedom, leads to misalignment among these planes and

to the lack of coherence and consistency on how the enterprise is (re)arranged within each plane. The research aims

to exploit how this organizational competence labeled enterprise governance (EG) can use the enterprise ontological

models produced using DEMO, along with the prescriptive architecture notion, to deal with these problems which are

pointing out as one of the core reasons for the enterprise weak ability to be in a continuous process of transformation

for regaining synergies and facing undesirable changes. For this purpose, the research brings forward the current state-

of-the-art in the enterprise ontological modeling (in particular the Ψ-theory underlying DEMO), the governance themes

and the systemic theories regarding the enterprise dynamics. The findings of the research conducted are depicted in a

set of conceptual models and consolidated in a reference method for guiding the EG in defining a set of restrictions

(normative outputs) by means of DEMO models. The method outlines the importance of the EG in addressing DEMO’s

responsibility, competence and authority notions at the design level and ensure their correct execution at the operational

level. In this manner the enterprise can deal with ongoing organizational changes and security issues, while ensuring

that when it enters in a dysfunction state the appropriate mechanisms are activated for the enterprise to recover to a new

equilibrium state. The purposed method is applied and validated by using the ’DIAP inquiries direction’ practical case.

Keywords: Enterprise Governance, Enterprise Ontology, Enterprise Engineering, DEMO

2

ResumoA ausência de uma competência organizacional capaz de restringir de forma holística a liberdade empresarial associada

aos planos estratégico, de desenho e operacional, resulta na falta de coerência e consistência entre estes planos e na

forma como os elementos de uma empresa se encontram coordenados. A investigação realizada propõe explorar como

esta competência organizacional designada de Sistema de Governação Empresarial (EG) pode utilizar os modelos on-

tológicos definidos usando a metodologia DEMO, juntamente com a noção prescritiva de arquitectura, para lidar com os

problemas levantados, os quais são apontados como estando entre as principais causas da incapacidade de uma empresa

de se encontrar num processo contínuo de transformação de forma a lidar com mudanças indesejáveis. Para tal objectivo

são analisados neste documento, o estado actual da modelação ontológica da realidade organizacional (em particular a

teoria Ψ subjacente à metodologia DEMO), os temas de governação e as teorias sistémicas na abordagem das dinâmi-

cas empresariais. Os resultados da investigação são abstraídos num conjunto de modelos conceptuais e consolidados

num método de referência para guiar o EG na produção de um conjunto de restrições (outputs normativos) com base

nos modelos DEMO. O método ajuda o EG a abordar as noções DEMO de responsabilidade, competência e autoridade

ao nível do desenho e a garantir a sua correcta execução a nível operacional. Desta forma a empresa pode lidar com

as mudanças organizacionais e com questões de segurança, assegurando continuamente que quando esta entra num es-

tado de disfunção, são activados os mecanismos adequados para a empresa recuperar para um novo estado de equilíbrio.

O método proposto é aplicado e validado usando o caso de estudo ’Gestão e Direcção de Inquéritos do DIAP de Lisboa’.

Palavras-chave: Sistema de Governação Empresarial, Ontologia Empresarial, Engenharia Empresarial, DEMO.

3

Acknowledgments

I would like to express my gratitude to everyone who was part of my journey and contribute directly and indirectly

to complete my thesis work. First and foremost, my thanks go to my Mentor, professor Dr. José Tribolet, and to my

Adviser, professor Dr. Jan Hoogervorst.

Professor José Tribolet was a marvelous governing system! The guidance exercised throughout my research re-

stricted the undesirable freedom while ensuring the consistence and coherence of the thesis work, but at the same time

provided me free will to use my creativity and skills in creating my thesis world. I thank him for all the inspiration,

critical thinking, and for the very interesting discussions that allowed me to follow essential directions regarding my

solution proposal.

Professor Jan Hoogervorst always helped me in bringing rigor to my thesis content. I thank him for his incessant

support, guidance and patient towards my way of working, for provided me detailed and relevant suggestions, and the

severely needed formal ground for my thesis.

I would also like to thank and dedicate this thesis:

to Rui Henriques, my ancestral journey sharer;

to Elsa Henriques, my mother, and Rui Henriques, my father,for all their Love, Will and Sacrifice;

to my Guides, who incessantly taught me how to grub Life, to expand my consciousness and

to have the strength to approach this thesis with truth and dedication;

to José Soares and many other wonderful friends whose paths cross mine in a deep and irreversible way;

to the Life above.

4

List of Acronyms

AR Action Rule

ATD Actor Transaction Diagram

BPM Business Process Management

BPR Business Process Reengineering

C-acts Coordination acts

CAS Complex Adaptive System

CG Corporate Governance

CM Construction Model

CRUD Create, Read, Update, Delete

DSR Design Science Research

DEMO Design and Engineering Methodology for Organizations

DIAP Department of Investigation and Prosecution

DID DIAP Inquiries Direction

EA Enterprise Architecture

EE Enterprise Engineering

EG Enterprise Governance

EI Enterprise Integration

EO Enterprise Ontology

GS Governing System

GSDP Generic System Development Process

IAM Interaction Model

IS Information System

IT Information Technology

ITG Information Technology Governance

MP Public Ministry

ODE Organizational Design and Engineering

OM Ontologic Model

OSA Organizational Self-Awareness

P-acts Production acts

PM Process Model

PJS Portuguese Justice System

SM State Model

5

NotationWhile reading this dissertation, the reader will surely notice some structures apart from the usual text, figures and tables.

These new structures aim to better organize and emphasize the ideas to be expressed on this work so its content can be

easily assimilated by the reader.

Structural Definitions

The introduction of some relevant concepts are framed by a light gray box:

A definition is a passage describing the meaning of a concept.

Formalizations

Formal expressions usage are are framed by a light green box:

A formal language and a set of inference rules are used to derive (to conclude) one expression from one or more other

expressions (premises) antecedently supposed (axioms) or derived (theorems).

Action Rules

Production and coordination rules as well as other algorithms are illustrated in pseudo-code as exemplified below:

when inquiry creation/distribution of [inquiry] is stated

if the complaint information is complete

then if the inquiry can be typed

then inquiry creation/distribution of [inquiry] must be accepted

else inquiry delegation decision of [inquiry] must be requested

else creation/distribution of [inquiry] must be declined

6

Table of Contents

Index 1

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

I Universe Of Discourse

2 Thesis Context: Conceptual Foundation 5

2.1 Complex social-technical systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Systems Thinking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Self-awareness in complex adaptive systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 System integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 Functional and Constructional Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6 Design and Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.7 Enterprise Engineering and Organizational Design & Engineering Disciplines . . . . . . . . . . . . . . 11

2.8 System Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.9 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.10 Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.11 Summary of Thesis Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Thesis Problem 17

3.1 The application scenario - validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Limitations of traditional governance approaches and gaps in the still maturing organismic governance

approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3 The Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.4 The IV requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Thesis Statement 21

4.1 Research Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3 Research Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.4 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.5 Thesis Boundary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

7

II Findings

5 State-of-the-Art 26

5.1 System Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.1.1 Towards a method for modeling the enterprise ontology . . . . . . . . . . . . . . . . . . . . . . 29

5.1.2 Ontological Modeling with DEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2 System Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.3 System Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3.1 Governance themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6 Governance levels: governing system and the GSDP 42

6.1 Introducing the Governing System in the Generic System Development Process . . . . . . . . . . . . . 42

6.2 Governance levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

III Solution Design

7 Solution Basis 47

7.1 Enterprise System as a set of constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.2 Governance and DEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.2.1 Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.2.2 Competence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7.2.3 Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.2.4 Responsibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.3 An high-level framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

8 Bringing EG to DEMO 55

8.1 Towards an EG ontological model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

9 Solution Derivation 59

9.1 Towards a reference method for governing the enterprise dynamics with DEMO . . . . . . . . . . . . . 59

IV Validation

10 Hypothesis Validation 65

10.1 Case Study: DIAP - inquiries direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

10.2 Design artifact validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

10.3 Contributions revisited . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

10.4 Artifact completeness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

V Concluding Remarks

11 Discussion 80

8

12 Conclusion 81

12.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

VI Appendix.1 The way of working with DEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

.2 An approach to develop the Enterprise Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

.3 The Portuguese Justice System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

.4 Practical case - MP-DIAP Inquiries Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

.4.1 Description - Part I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

.4.2 Analysis - Part I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

.4.3 Description - Part II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

.4.4 Analysis - Part II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

.4.5 Description - Part III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

.4.6 Analysis - Part III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

.5 Normative outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

.6 Revisiting OSA notion and aligning this notion with governance . . . . . . . . . . . . . . . . . . . . . 96

bibliography 97

9

List of Figures

1.1 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 System construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Organized complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Stressing governance approaches according to a mechanistic and an organismic thinking . . . . . . . . 14

4.1 Research Methodology (DSR)- Social Science vs. Engineering Science . . . . . . . . . . . . . . . . . 22

4.2 Design Science Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.3 Artifact types in Social Science vs. Business Engineering vs. Design Science Research . . . . . . . . . 24

4.4 Thesis boundary: the three main themes to exploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1 Organizational object taxonomy by Fox et. al . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2 Relation among enterprise concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.3 Organizational modeling framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.4 The layered integration of an enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.5 Organization theorem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.6 The construction axiom and the notions of responsibility, authority and competence . . . . . . . . . . . 31

5.7 The generic transaction pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.8 The standard transaction pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.9 The abstraction axiom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.10 The ontological aspect models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.11 Ecological vs. Engineering Resilience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.12 Measuring system resilience: where resilience is a function of the area under the curve . . . . . . . . . 35

5.13 Process view of the relation between the governing system and the governed system . . . . . . . . . . . 36

5.14 Strategic Alignment Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.15 IT Governance and EA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.16 Enterprise Architecture Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.17 EG competencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.18 Relationship between the governance themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.1 The system design process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.2 The design governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.3 The system engineering process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.4 The engineering governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.5 Enterprise program and project portfolio governance in the GSDP . . . . . . . . . . . . . . . . . . . . 44

6.6 Governance levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

10

7.1 Emotional competence model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.2 Competence governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.3 Authority governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.4 Responsibility governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.5 Stressing the relation between Enterprise Governance, Ontological models and Architecture . . . . . . 54

8.1 The governance of the enterprise - Interstriction Model . . . . . . . . . . . . . . . . . . . . . . . . . . 58

9.1 Theorems of the research conducted that serve as the basis for the development of the method . . . . . 59

9.2 Ontological models can be obtained by reverse engineering the implementation models . . . . . . . . . 60

9.3 Exemplification of a DEMO model for the library case - interstriction model . . . . . . . . . . . . . . . 60

9.4 Definition of the enterprise architecture to guide the enterprise detailed design . . . . . . . . . . . . . . 61

9.5 Area of responsibility for actor role A01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

9.6 AR01 associated to the actor role registrar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

9.7 AR02 associated to the actor role registrar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

10.1 Interstriction Model: Actor Transaction Diagram of MP-DIAP and Production Banks . . . . . . . . . . 67

10.2 State Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

10.3 Reference framework for architecturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

10.4 Main enterprise design domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

10.5 Areas of responsibility for actor roles A01, A02 and A06 . . . . . . . . . . . . . . . . . . . . . . . . . 73

10.6 Road-map to guide the implementation of the EG and normative outputs within our reference method . 77

1 Legend of the Organization Construction Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

2 Legend of the State model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3 The Enterprise Governance Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4 The Portuguese Justice System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5 Overflow chart with the transaction and abstraction axiom - part 1 . . . . . . . . . . . . . . . . . . . . 90



8 Transaction Pattern: process model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

9 Organizational Self-awareness and Enterprise Governance . . . . . . . . . . . . . . . . . . . . . . . . 96

11

List of Tables2.1 Architecture example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Principle example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Mechanistic perspective vs. Organismic perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1 Governance-related requirements for guiding the enterprise system . . . . . . . . . . . . . . . . . . . . 20

4.1 The guidelines purposed by Hevner to guide Design Science Research . . . . . . . . . . . . . . . . . . 23

5.1 Authority, responsibility and competence notions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2 Different perspectives on the notion of enterprise function . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.3 Corporate Governance, IT Governance and Architecture Governance perspectives and limitations . . . . 37

6.1 intra-system governance levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.2 Inter-system governance levels for the enterprise system . . . . . . . . . . . . . . . . . . . . . . . . . 46

8.1 Transaction Result Table for the EG interstriction model . . . . . . . . . . . . . . . . . . . . . . . . . 58

9.1 Examples of architecture principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

9.2 Illustrative set of responsibility and competence principles for actor role A01 (Registrar) . . . . . . . . 62

9.3 Definition of authority rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

10.1 Transaction Result Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

10.2 DID areas of concern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

10.3 Illustrative set of competence and responsibility principles . . . . . . . . . . . . . . . . . . . . . . . . 70

10.4 Competence domains for each actor role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

10.5 Matrix for defining assignment rules for actor A06 regarding the different sections of DIAP . . . . . . . 71

10.6 Illustrative set of ’need-to-do’, ’need-to-know’ and ’need-to-audit’ for creating authority rules . . . . . 73

10.7 DIAP Inquiries Direction CRUD matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

10.8 Method Contributions revisited . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

10.9 Evaluation of artifacts completeness against the IV initial requirements . . . . . . . . . . . . . . . . . . 79

11.1 Research questions and respective findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

1 Bank Contents Table - fact banks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

2 Examples of architecture notion in practice for DID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

12

1Introduction

There are two mistakes one can make along the road to truth,

not going all the way,

and not starting

– Buddha

In a world of growing business dynamics, high rates of technological advances and organizational changes, enterprises

need to be effectively and continuously (re)designed and (re)engineered in order to achieve strategic and operational

success. Hence, our research will be developed around the enterprise development theory1 supported by the Enterprise

Engineering discipline and the subsequent change dynamics approached in the still maturing discipline of Organizational

Design & Engineering (ODE).

In this context, we address two interrelated problems. First, the lack of integration among the various enterprise

elements resulting from the lack of a governance competence responsible for restricting the undesirable design freedom

and/or inadequate modeling techniques that enable to master the enterprise complexity at the design level. Second, the

incapacity to deal with the enterprise dynamics at the operational level. This can be a consequence of the first problem

in the sense that if essential enterprise aspects are not addressed at the design level, they cannot be properly managed

over time at the execution plane. Moreover, governance mechanisms to ensure the successful transition from what is

designed to what is occurring at the execution plane and to continuously guide the enterprise operation remains essential

to deal with undesirable changes and increase resilience.

These problems are interrelated since enterprise design and enterprise operation must be mutually aligned over time

in the sense that changes at the operation level must be immediately addressed at the design level (collateral impacts,

resolution) and changes at the design level must be operationalized. Both, enterprise design and enterprise operation

must be aligned with the enterprise strategy. Put another way, enterprises cannot effectively, from a holistic point of

view, (1) build the strategy into design, (2) build design into operation, (3) handle exceptions that cause dysfunction

and continuously perform improvements [Eberhardt Rechtin, 1999, Ackoff, 1999]. Therefore, enterprise aspects are not

addressed by thinking in the enterprise as an organic whole and thus, they are not integrated in a consistent and coherent

manner. Consequently, the enterprise will not be able to operate as a unified system and the strategy implementation will

tend to fail [Kotter, 1995].

We argue that there are two interrelated main reasons behind this problem. First reason, the enterprise does not have

the ability to apply in practice the design theory from the enterprise engineering discipline. Consequently, enterprises

cannot master the enterprise complexity and thus, cannot (re)arrange the enterprise elements in a coherent and consis-

tent manner [Dietz, 2008]. For this purpose, we outline two important concepts underpin the enterprise engineering

1Enterprise development theory perceives an organization as an artifact. The development process of the organization artifact comprises the

enterprise (re)design, (re)engineering and implementation processes, as well as its subsequent operation

1

discipline that are integrated in the GSDP (Generic System Development Process) and that should be used to mastering

the enterprise complexity: (1) architecture which restricts the undesirable design freedom in the form of design princi-

ples and standards [Hoogervorst & Dietz, 2008], and (2) ontology which provides a coherent, consistent, comprehensive

and yet concise conceptual model of the system designed that is fully independent of implementation [Dietz, 2008]. To

model the enterprise ontological models we outline the (re)designing and (re)engineering methodology for organizations

(DEMO) which is based on the ψ-theory [Dietz, 2006].

And second reason, the absence of an organizational competence that should guide at the enterprise-wide level this

enterprise development process and subsequent changes in order to ensure the correct use of this theory [Garud et al., 2008].

Professor Hoogervorst in [Hoogervorst, 2009] named this guiding competence enterprise governance. Defining an ex-

plicit and accepted governance model is arguably one of the most important steps to identify and implementing successful

(re)design or (re)engineering initiatives. The governance is the vehicle through which the enterprise stakeholders can

participate for guiding and achieving an integrated construction model [Henriques et al., 2010b].

The governance of the on-going organizational dynamics is a theme still in maturing. These dynamics can be

classified regarding its origin in proactive changes which result from perceiving opportunities of improvement and

reactive changes that have origin in exceptions that cause dysfunction [Aveiro, 2009]. Regarding the impact of changes

on the system functioning, we can outline resilience when the system can compensate potentially disruptive perturbation

and propagating dysfunction when a perturbation has undesirable collateral impact. It is out of this thesis scope to

analyze how such changes are detected. In particular, the detection and handling of reactive changes was researched in

[Aveiro, 2009].

The focus of this thesis is to analyze the importance of the enterprise governance in defining ontological models and

using the underlying notions of competence, authority and responsibility to guide the management of such enterprise

dynamics. Therefore, we will bring together the ψ-theory (which combines the knowledge from ontological works, the

language/action perspective, logic and systems theories) and the organismic theories associated to governance themes.

1.1 Motivation

Literature indicates that the lack of coherence and consistency among the various components of an enterprise is the

core reason for strategic failures [Kotter, 1995, Pettigrew, 1998, Dietz & Hoogervorst, 2007]. Moreover, it is estimated

that between 70% and 90% of strategic initiatives such as total quality management, business process re-engineering, six

sigma among others tend to fail [Kaplan & Norton, 2004, Dietz & Hoogervorst, 2007, Smith & Fingar, 2003]. Authors

have been pointing out that such failures in most cases result from inadequate strategy implementation and not primarily

from weak strategy formulation (we refer the reader to [Hoogervorst, 2009, Dietz & Hoogervorst, 2007]). The ability

to continuously and successful implement new strategies is related with the ability of the enterprise to be more resilient

to hazards. Since enterprises are highly complex systems, design guidance exercised in a holistic manner is required

during strategy implementation to achieve coherence and consistency among enterprise components and increase their

resilience to hazards.

Unfortunately, this notion of guidance is still not practiced at the enterprise-wide level. Furthermore, the term

governance is often associated with executive or senior management and a ’mechanistic’ perspective (top-down, control

oriented). Within that perspective, there is no, or inadequate attention for the main concerns of the enterprise governance,

2

in particular the enterprise design. An organismic perspective on the enterprise governance is needed to master the

enterprise organized complexity. Within this perspective, the enterprise governance consists in an integrated whole of

knowledge, skills and technology that should rest on the individual competencies of the employees that constitute the

human part of the competence [Hoogervorst, 2009].

However, it remains unclear how the enterprise governance should guide and deal with the daily enterprise dynamics.

In highly dynamic environments, such as the business world, an enterprise is never a static entity. Some industries will

be more stable than others, but nevertheless, an enterprise that remains exactly the same over time will eventually

erode its potential to achieve its purpose. In an ever changing environment, a system must also change in response to

that environment in order to retain its advantage. This has interesting implications for an enterprise hit by disaster. It

implies that the enterprise should not aim to recover and rebuild itself to be the same as it was before disaster struck,

but should recover to a new equilibrium, where it will regain synergy with its external environment. Such aspects are

obliging enterprise to be designing as flexible systems capable to deal with disasters. These concepts need to be properly

addressed when addressing the operation and construction of governing systems.

Moreover, ontological modeling techniques have been identified as essential to leverage and clear define a set of

enterprise concepts. It is still lacking in literature an analysis how these concepts retrieved from the ontological models

can support and improve the definition of governance outputs.

1.2 Contribution

It is expected that this thesis helps enterprises to effectively govern its dynamics by:

• motivating to the importance of mastering the enterprise complexity from a holistic point of view by means of

ontological models and prescriptive outputs;

• understanding the role of the enterprise governance in guiding the enterprise dynamics;

• bringing more awareness to the functioning of organizations by modeling the enterprise essence;

• highlighting the importance of an organismic perspective on the enterprise governance resting on the individual

competencies of the enterprise actors;

• bridging the notions of authority, responsibility and competence with the governance outputs;

• providing a set of guidelines for enterprises to define in a holistic manner a set of restrictions and the subsequent

impact;

• understanding the role of governance in dealing with undesirable changes and addressing enterprise resilience;

• providing a set of insights in how to develop a governance competence in terms of its behavior and its construction;

A set of documents and presentations were produced within the scope of our research with the purpose of raising

awareness in the scientific community as well as in the professional market:

• two articles regarding the research conducted were submitted for two conferences: INFORUM 2010 [Henriques et al., 2010a]

and CAPSI 2010 [Henriques et al., 2010b]. The articles were accepted and published in the respective confer-

ences. A presentation regarding the articles was also conducted for both conferences;

• a presentation was performed in January 2010 for the POSI course (Postgraduate course in Information Systems)

where the main theme was the systemic conceptual foundations of professor Dietz (the integration of architecture,

3

ontology and design notions in the GSDP);

• it was produced a document with a set of recommendations and opinions for the consultative version of “Principles

for enhancing corporate governance” for the Basel Committee on Banking Supervision;

• it was written a document with detailed analysis of the Portuguese Justice System (PJS) in the context of the

modernization of the PJS. The document is composed by an analysis of the scope and current situation of the PJS,

an analysis of a governing system for the PJS which comprised the identification of governance levels in the PJS,

the governance structure, the committees and groups (roles, competences, authority), among other governance

issues;

• among other collaborations in developing presentations and other documents in the context of the modernization

of the Portuguese Justice System;

1.3 Thesis Structure

Accordingly to Fig.1.1, this thesis is divided into five logical parts.

Figure 1.1: Thesis Outline

First part, Universe Of Discourse, provides a solid conceptualization of the thesis context, deepens the thesis problem

and subsequent requirements, introduces the hypothesis, and depicts the research methodology and artifacts.

Second part, Findings, analyzes existent contributions on the field of study regarding (1) the notion of ontology and

subsequent enterprise modeling, (2) the system dynamics, and (3) the governance themes.

Third part, Solution, identifies the threads that connect the enterprise governance with DEMO ontological models,

describes a set of models regarding the role of the enterprise governance in guiding the enterprise dynamics (based on

the notions of competence, authority and responsibility) and exploits how they can answer to the thesis hypothesis. The

findings are consolidated in a high-level framework and then the enterprise governance competence is modeled with

DEMO. Based on the research conducted a reference method is presented and illustrated.

Fourth part, Validation, validates the thesis artifact by using the observational and the descriptive method within

design science research methodology; the evaluation methods are used with the “DIAP inquiries direction” practical

case and assessed against the initially defined set of requirements to demonstrate the artifact’s utility.

Finally, Concluding Remarks, answers to the set of research questions elaborated in the first part of the document,

summarizes the main conclusions of the research and presents possible lines of though for expanding this work in the

future.

4

IUniverse OfDiscourse

2Thesis Context:

Conceptual Foundation

through the atom of the physicist, through man,

through the energising Life of a planet, up to the Logos,

and on to some greater scheme in which even our God has to find His place.

– Alice Bailey, The Consciousness of the Atom

The systemic approach to problems focuses on systems taken as a whole, instead of their parts taken individually.

Several actors have been arguing that the only effective way to study an enterprise is by approaching an enterprise as

a system, since the emergent properties of a system cannot be understood by analyzing the components of the system

in isolation [Ackoff, 1999, Hoogervorst, 2009, Eberhardt Rechtin, 1999, Weinberg, 2001]. According to this approach,

system development and subsequent changes should be treated from a holistic point of view.

2.1 Complex social-technical systems

According to a structural perspective, system is defined as

[System] a set of interacting entities (or elements) which form an integrated whole [Ackoff, 1971, Dietz, 2008].

By “integrated whole” [Dietz, 2008] is meant that each element in the system is connected to every other system ele-

ment, directly or indirectly, and that there is a boundary that embodies a set of relationships which are differentiated from

relationships within external elements (elements from the environmental set) and from relationships between elements

of the set and of the environmental set. Moreover, no subset of elements is unrelated to any other subset. However,

a structural perspective can be impractical when used to analyzed systems with a high number of interdependencies

(complex systems) and thus, an interpretative perspective may be needed to deal with such complexity. Within this per-

spective, a complex system can be interpreted by means of its behavior, norms, values, among other cognitive aspects.

This interpretative perspective is particularly important to deal with socio-technical systems such as organizations.

Now that the notion of system was clarify, we are able to formalize it. Our formalization is based on the notation

proposed by Professor Dietz in [Dietz, 2008], where C represents the system composition (a set of atomic elements), E

represents the system environment (a set of elements from the same category of C elements that are not contained in

the system composition but that act on are acted upon by elements of the composition), P represents the products that

are brought about by the elements in composition for the benefit of the elements in environment, and S represents the

system structure.

5

System Sys = < C, E, P, S >

E = {Eli : Eli 3 C ∩ Eli ∈ Ca(S ) ∩ rel(Eli, El j ∈ E),∀i ∈ N}

P = {prod(Eli, El j) : ELi ∈ C ∩ El j ∈ E}

S = {restr(Eli, El j) : ELi ∈ C ∩ El j ∈ E}

where Elx is an atomic element, Ca(S ys) the category of system Sys, rel(Elx, Ely), interaction between two elements, prod(Elx, Ely)

the products brought by element x for the benefit of element y, and restr(Elx, Ely) the influencing bonds among two elements

From this formalization we can outline two important notions:

System construction =C ∪ E ∪ S (see figure 2.1 [Dietz, 2008])

System operation ={activity(Eli) : Eli ∈ (C ∪ E)∀i ∈ N} (the collective activity of the elements of composition and environment).

Figure 2.1: System construction Figure 2.2: Organized complexity

This formalization presents a static view of a system, to introduce the notion of time within a system (behavioral

view) we need to introduce a set of complementary concepts defined according to [Ackoff, 1971]. The state of a system

is the set of relevant properties that a system has at a certain moment of time.A system event is a change in the state of

the system over a period of time of specified duration. Dynamic systems are those to which events occurs, whose state

changes over time. Enterprises are highly dynamic systems operating in a highly dynamic environment. We outline two

different kinds of events according to its antecedents: (1) reactive events comprising reactions and responses which are

events caused by other events, and (2) pro-active events comprising actions which are self-determined or autonomous

events. These are system events whose antecedents are of interest. We will use the term behavior to refer to the system

events whose consequences are of interest. Behavior is a system event which initiates other events [Ackoff, 1971].

Note that reactions, responses and actions may themselves constitute behavior. Furthermore, a process is a sequence of

behavior that constitutes a system and has a goal-producing function [Ackoff, 1971].

2.2 Systems Thinking

These systemic approaches view organizations as a set of interdependent elements interacting in order to achieve a

specific purpose. In [Daft, 2006] organizations are described as designed “goal-directed social entities deliberately

structured activity systems linked to the external environment”. Enterprise is used in this report as the overall concept

to identify businesses, organizations, companies or institutions [Hoogervorst, 2009]. Through the distinction between

organization and business as, respectively, the construction and function perspectives on enterprises, the following way

of thinking about enterprises becomes logical and feasible. Furthermore, an alliance or network of enterprises can be

considered a new enterprise at the network level. Enterprise is defined as

6

[Enterprise] (1) a goal-seeking system, (2) intentionally designed by (3) a set of interacting human (4) behaving

according to “assigned authority and corresponding responsibility against a common background of social norms and

values”.

The humans behavior (explicit reality) is the main generator of the enterprise contexts (implicit reality), and at the

same time their behavior is also shaped by the contexts they generated. The implicit reality is something that can be an-

alyzed and theorized by knowing the processes that generate this reality (explicit reality) [Magalhães & Tribolet, 2005].

For instance, to understand the river swirls phenomenon (implicit reality), we need first to understand its generator

processes which can be found in the fluid dynamics of the river (explicit reality).

Since enterprises have a high level of interdependencies, they are considered complex systems. These interdepen-

dencies have an intentional relation (are organized). Therefore, the enterprise issues can be classified as problems of

organized complexity [Weinberg, 2001]. These problems are particularly challenging because analytical methods cannot

deal with this kind of complexity and statistical methods are not adequate to deal with such organization (see figure

2.2). As we will see further on this document, the notions of ontology and architecture underlying the enterprise engi-

neering discipline purpose to deal with the enterprise design by harnessing the system complexity. While the enterprise

governance will be required to bring the desired order (improve the intentional relation) among the elements which will

be manifested in the enterprise design.

2.3 Self-awareness in complex adaptive systems

The adaptiveness of a system is its ability to modify itself or its environment when there is a change which reduces its

efficiency in pursuing one or more goals [Ackoff, 1971, Ackoff, 1999].

Adaptiveness of a system is the ability to change from statet− > state(t+1) where∑m

i=1 PiEi j at t+1 >∑m

i=1 PiEi j at t (regarding the

production of specific outcome to the environment from system Products P),

when∑m

i=1 PiEi j at t <∑m

i=1 PiEi j at t-1 (production of an outcome was negatively affected).

where∑m

i=1 PiEi j is the system efficiency regarding the production of a particular outcome O j to the environment (the efficiency is

related with the different ways - course of actions - that a system can select to produce an outcome, Pi is the probability of the system

selecting a course of action and Ei j the probability that this course of action will produce a particular outcome O j to the environment)

Adaptations occur when a system modifies itself or the environment by reacting/responding to an external or internal

change. For instance, enterprise efforts to promote favorable regulations or legislation to face the new entrances in the

sector (other-other adaptation) or decrease in revenue (self-other adaptation), or when an enterprise changes an internal

service flow to face the service level competition (other-self adaptation) or staff reduction (self-self adaptation). In order

to perform these adaptations successfully, enterprise should consider the information about its previous states, events

and adaptations. An enterprise may be approached as complex adaptive system (CAS), since it has an its unpredictable

future and emergent order (not predetermined) and it is in a continuous learning process where the enteprise adjusts its

states by reacting or respond to changes.

The enterprise actors are the main responsible to perform such adaptations and thus, they are the basic building

blocks of the CAS. Furthermore, the actors’ actions should be the starting point to understand the enterprise reality,

since their actions are the generator processes of the enterprise contexts [Magalhães & Tribolet, 2005].

The actor’s actions do not happen casually, they are highly affected by the decisions and choices of the enterprise

7

managers, the culture and values of the enterprise, as well as emotional and rational communication clues embedded

in the enterprise language [Magalhães & Tribolet, 2005]. The language is the enabler of system’s changes by providing

interpretative contexts with factual information. The access to this information by the enterprise and its actors allow the

enterprise to act in a more intelligent manner and thus, help the enterprise to face the future uncertainties and ensure its

survival. However, despite of the available information, the enterprise still does not know what’s happening at a moment

at time from a holistic point of view [Zacarias et al., 2007]. This happens because enterprises are complex systems with

a large number of processes executing in parallel, and they cannot effectively master this complexity and convert the

existing information into intelligence [Magalhães & Tribolet, 2005].

An enterprise actor must know the processes for which he is responsible, but he does not know what is happening

in the enterprise as an organic whole. However, the enterprise reality is constructed by the activity of all its mem-

bers. Therefore, an enterprise should know what each actor is doing at a moment at time and how such individual

behavior contributes to the enterprise behavior [Magalhães & Tribolet, 2005]. This means that the enterprise should

have self conscience. This is the essential notion behind the organizational self-awareness (OSA) concept introduced in

[Magalhães & Tribolet, 2005].

In [Zacarias et al., 2007] OSA is characterized along two dimensions, the individual and the organizational one.

The individual dimension refers to the individual members capacity to understand their role in the organization, their

procedures and to know the enterprise as a whole. The organizational dimension refers to the combination of all the

individuals consciences, procedures and resources within an enterprise that enable the enterprise to know what its actors

are doing at a certain point in time and understand the reasons of their operation from a holistic point of view. Organi-

zation self-awareness is maximized when these two dimensions are aligned. OSA is critical to the enterprise integration

and thus, to its ability to be agile and perform adjustments [Magalhães & Silva, 2009]. We define OSA as the:

[OSA] understanding of (1) individual and (2) collective processes whereby (3) tacit knowledge is combined with (4)

real-time information (5) to assimilate the enterprise reality and (6) articulate appropriate points about it.

The process of capturing the enterprise reality enhances OSA for which the sensemaking process is crucial. Sense-

making is the process of structuring and assigning with meaning unknown contexts and/or actions [Weick, 2001]. There-

fore, sensemaking enables OSA which gives the enterprise the power to know itself. How to capture the structural and

dynamic aspects, routines and decision-making processes, formal and informal sides of the enterprise reality? By mod-

eling is possible to abstract the reality by capturing the relevant properties of the enterprise state and representing them

in a language easier to manipulate and understand.

2.4 System integration

System integration is perceived as the bringing together of all the subsystems into one system and ensuring that this

behaves as an unified system. When the system in cause is the enterprise system approached from a holistic point

of view we can use the term enterprise integration. Enterprise integration occurs when there is a need in improving

interactions between people, systems, applications, services, departments, among other aspects. In fact there are a vast

number of enterprise aspects that should be addressed in order to maximize integration. Hence, it is required approaches

and mechanisms that can harness such complexity.

In [Vernadat, 2002] is provided a broader definition of Enterprise Integration (EI) stating that EI “consists in break-

8

ing down organizational barriers to improve synergy within the enterprise so that business goals are achieved in a

more productive and efficient way”. Similarly, in [Li & Williams, 2005] EI is percieved as the coordination of all

enterprise aspects working together in order to achieve the business mission. Hence, EI deals with all the domains

of the enterprise treated as a whole system in order to provide “the right information at the right place and at the right

time”[Kosanke et al., 1999]. In this report enterprise integration (EI) is about:

[Enterprise integration] addressing all the enterprise aspects in a holistic manner and ensuring that they are coherent

and consistent in order to maximize the efficiency of the enterprise functioning (optimization) and its ability to respond

to (internal or external) changes (adaptability) so that business goals are achieved in a more efficient way over time

Enterprise Integration = f(t) = is the ability to MAX(∑m

i=1 PiEi j ∩ adaptability) by stressing the interactions between all the

enterprise aspects; where MAX(∑m

i=1 PiEi j) is the system optimization and∑m

i=1 PiEi j is the system functioning efficiency (we refer

the reader to previous formalization of adaptability and function efficiency)

Note that adaptability and efficiency often vary in inverse proportion in the sense that more adaptability may come at the price of

efficiency and thus, enterprise integration is about to maximize and balancing these two variables which depends on the specific

interests/strategies of each enterprise at a particular time.

When we refer to enterprise integration, we are primarily concern with two basic requirements: coherence and

consistence. Coherence in linguistics is what makes a text semantically meaningful by means of a source which provides

logical tense structure. Similarly, in our context coherence means that system elements have a common source (e.g. the

enterprise mission). By consistence is meant that system elements do not contradict. Detect inconsistency among the

enterprise elements is a complex process and there is still lacking in literature design artifacts that can guide such process.

The production of consistent “principles” at the enterprise-wide level is essential to deal with consistency among the

enterprise elements. Coherence and consistence are two important concepts to identify lacking of integration (if one of

these two qualities fails then the system is not integrated), however they are not sufficient. This happens because there

are unlimited (quality) levels of integration.

Considering the enterprise complexity, we cannot proof that the current enterprise state provides the best ability for

the enterprise to operate as an unified system. Hence, after approaching consistency and coherence among the enterprise

elements, it is important to critically evaluate if there is any way to improve the enterprise functioning. This can be

done by approaching the enterprise in a holistic manner and maximizing (1) communication (data and information ex-

changes at system level), (2) cooperation (inter-operation at application level) and (3) coordination (timely orchestration

of processes at business level). EI ultimate goal is, therefore, to enhance overall efficiency and adaptability.

EI is strongly related with the notion of organizational self-awareness presented in the previous section in the sense

that the conscience how each enterprise subsystem (in particular humans systems) contributes to the organization as an

whole is essential to deal with undesirable changes and perform adequate (re)arrangements over time. In this report, we

argue that this holistic view of the enterprise and how each local system affects the global system is the responsibility of

the enterprise governance (this concept will be exploited further).

Moreover, EI can be approached from different perspectives and at various levels, such as, horizontal versus vertical

integration, intra-enterprise versus inter-enterprise integration, and business versus application versus physical integra-

tion, among others. It is important to note that EI domain is beyond the technological and management dimensions. It

has a strong organizational dimension and thus, an organizational competence integrating diverse knowledge and skills

should participate on the arrangements of the enterprise aspects in order to maximize integration.

9

2.5 Functional and Constructional Approach

In the previous sections we have been discussing the importance of enhancing organizational self-awareness in or-

der to increase integration by performing adjustments from a holistic point of view. These enterprise adjustments or

(re)arrangements involve two perspectives: the functional and constructional. The functional perspective, or external

view, concerns about the system behavior and performance. According to this perspective, given the system behavior

and operational conditions, it is expected to know what the system does and what external form it has. We are talking

about the teleological system notion (purpose of controlling system), where is used a black-box model to process the

input into an output [Dietz & Hoogervorst, 2007].

The constructional perspective is related to the ontological system notion (purpose of building and changing sys-

tems). It concerns how the system should be designed and built. A constructional model or white-box model is used to

know the internal operation of the system [Dietz & Hoogervorst, 2007]. During the system (re)arrangement the func-

tional perspective should precede the constructional perspective. First, we should focus on the external appearance and

behavior of the system. Once we are certain about the system functionality, and functional requirements are met, the

architecture can satisfy non-functional requirements. This is an iterative process.

2.6 Design and Engineering

Systems need to be purposely deployed in order to achieve their operational purpose. Design is used to refer to the delib-

erate constructional and functional (re)arrangements approached in the previous section that allow a system to achieve

its purpose [Dietz & Hoogervorst, 2007]. The notion of design used in this report is defined as

[Design] the production process of conceptual models of a system, which is divided in two consecutive phases:

function design and construction design [Dietz, 2008].

It is important to have in mind that many systems, in particular enterprises, are highly complex due to their high

level of interdependencies. Therefore, when we use constructional models to approach the system they should capture

the system construction at different levels of abstraction. At the “highest level” there is the ontological system model

and at the “lowest level” there is the implementation system model. The ontological model represents the essence of the

system. This concept will be further exploited.

The constructional activities performed since the highest abstraction level till the lowest abstraction level are collective

called engineering or detailed design.

Hence, the notion of engineering has a narrow scope in this report used to refer to a system development phase that starts

from the ontological model of the system and ends with its implementation model. What is the relation between design

and engineering? The design starts from an existing system and produces the construction models of the system that we

want to develop or change (object system). The engineering or detailed design is an orthogonal process to the design

process which starts with the constructional models produced by the design and it produces a set of subsequently more

detailed white-box models that can be implemented. The engineering process can be percieved as a subprocess of the

design notion with the slight difference that the engineering outputs are models that can be implemented. Ideally, the de-

sign process delivers an ontological model (ontological design), the highest level white-box model. And then this model

is engineered till the implementation model in order to allow the technological means assignment to the construction

elements of the system (implementation).

10

2.7 Enterprise Engineering and Organizational Design & Engineering Disciplines

Design and engineering should not be treated separately. However, currently there is no match between design and engi-

neering. In [Magalhães & Silva, 2009] the design and engineering disciplines are bringing together under the discipline

of Organizational Design and Engineering (ODE), where ODE is defined as

[ODE] “the application of social science and computer science research and practice to the study and implementation

of new organizational designs, including the integrated structuring, modeling, development and deployment of artifacts

and people”.

An important belief underlying ODE theory is that interventions (design and engineering activities) must occur

in short sequential cycles of observation-and-intervention. This methodology is essential in current dynamic environ-

ment. The authors go further and argue that intervening in long observation periods can lead to enterprise failures.

Therefore, enterprise flexibility is achieved by continuously aligning people and technology, harnessing and steering

the emerging outcomes. The ultimate goal of ODE is to improve the role of people, information and machine re-

sources in organizations in order to “build up the organization’s knowledge and intelligence in a sustainable fashion”

[Magalhães & Silva, 2009].

The design and engineering are also both concerned and matched in the enterprise engineering discipline. Professor

Dietz defines enterprise engineering (the discipline) as

[EE] “the whole body of knowledge and know-how regarding the development, implementation and operational use of

enterprises, as well as their practical application in engineering projects”[Dietz & Hoogervorst, 2007].

As we can notice, the term engineering in the ’enterprise engineering’ as well as in the ODE discipline label has a totally

different scope from the term engineering - the process - used in the system development. In [Dietz & Hoogervorst, 2007]

was clarified that the word engineering used in enterprise engineering discipline “has to be taken in a broad sense, like

it is used e.g., in Mechanical Engineering and in Industrial Engineering”. In order to achieve consistency and to avoid

fuzziness around the engineering notion, from now on the term ’engineering’ will be used with a narrow scope (defined

in section 2.5) with the only exception when it is used in the enterprise engineering discipline label (which would not

make sense to rename). Therefore, when we apply the term in a broader sense we will always clarify that we are talking

about the discipline and not the engineering process.

2.8 System Ontology

In a broader sense, ontologies are shared views of domains. They provide conceptualizations that are agreed upon by

participants in collaborative action and decision making. The explicit existence of such shared perspectives makes it pos-

sible for both people and and non-human agents to collaborate by ensuring that everybody makes the same distinctions

and uses the same terms with the same meaning.

The term ontology has its genesis in philosophy, in this field ontology deals with questions concerning what entities

exist or can be said to exist, and how these entities can be subdivided, grouped and related within a hierarchy. In systemic

approaches, ontology has a very similar connotation in the sense that it also represents entities, ideas, and events, along

with their properties and relations, according to a system of categories. A further analysis of the ontology notion and the

related works regarding enterprise modeling is done in state of the art chapter section 6.3.

11

The core meaning of system ontology in our thesis context, based on the standard set by DEMO (Design and Engi-

neering Methodology for Organizations), is

a model for describing the construction and operation of a system, and its construction is implementation independent

[Dietz, 2006].If the system in cause is the enterprise approached from a holistic point of view, we can use the term enterprise ontology.

An enterprise ontology satisfies the next five quality requirements (C4E): coherence, comprehensiveness, consistency,

conciseness and essence. The scientific root of DEMO is the ψ-theory which combines the knowledge from onto-

logical works of the philosopher Mario Bunge [Bunge, 1977], the language/action perspective [Austin, 1976], logic

[Wittgenstein, 1984] and systems theories [Ackoff, 1999].

2.9 System Architecture

Architecture is an overloaded word used in different contexts with distinct and contradictory connotations. How-

ever, there is one common thing that links the architecture definitions mentioned in [Haren, 2005, Zachman, 1999,

IEEE1471, 2000, Dietz, 2008, Hoogervorst, 2009, Sousa et al., 2006], architecture cares about the system design.

In [Haren, 2005, IEEE1471, 2000, Sousa et al., 2006] architecture is perceived as a “blueprint” of the system con-

struction. In particular, in [IEEE1471, 2000] architecture is referred as “(...) a system embodied in its components, their

relationship to each other and to environment”. This is a descriptive approach of architecture. However, these references

also concern design guidance. In particular, [IEEE1471, 2000] refers to “(...) the principles guiding (system) design and

evolution”. This is a prescriptive approach of architecture. It has been discussed if architecture should integrate these

two approaches. However, integrate these two perspectives in one concept can lead to ambiguity and inconsistency.

Furthermore, in the enterprise context a descriptive approach (global design notion) is already possessed by means of

construction models. The relevant purpose of architecture is to provide guidelines during the system design and thus,

architecture concept need to evolve into an effective supporting tool.

Therefore, architecture concept in this report will be used only in a prescriptive manner, as

[Architecture] “a consistent and coherent set of principles and standards that guides the system design” by restricting

its undesirable freedom [Hoogervorst, 2009].A principle is a predefined design action comprising a statement, a rationale (principle reasoning), its implications and

the key actions that should be performed to fulfill the principle.

Enterprise Architecture have been used in literature with different connotations, and associated with different

enterprise areas, such as, Business Process Management and Quality Management. However, when we are talking about

EA we are dealing with the enterprise approached in a holistic manner. Therefore, EA cannot be approached or be too

focused on specific enterprise areas. We argued that the notion of architecture need to evolve into an effective supporting

tool (prescriptive notion) and thus, enterprise architecture notion will be used in this report as

[EA] the collection of design principles that address “systematic purposeful activities” from the core design domains of

an enterprise [Hoogervorst, 2009].EA plays a main role in guiding the system function and its developement process, in particular: the (1) enterprise de-

sign process, since it guides the construction of coherent and consistent constructional models; and the (2) engineering

process, since it guides the transition from ontological models to construction models that can be implemented.

12

Areas of concern support the principles choices and reasoning, and align the enterprise strategy with the design

process. Thinking in the ’car’ system example, some important area of concerns to address would be the car’s reliability,

safety, economy and maintainability. In the enterprise case, the areas of concern to address would be highly dependent

of the enterprise strategy and business. Overall, the areas of concern provide a reference context for the architecture

principles and standards. Another reference context to support the creation of principles is the design domains.

Design domains master the system complexity by dividing the design process in various domains which should

comprise a set of requirements and the respective design principles that should address each requirement. These domains

should be associated with the system function and construction perspectives. For the system ’car’, functional design

domains are, for example, lighting, heating, warning and steering. And constructional design domains would be the

parts that remain when the car is taken apart (e.g. engine, lamps, wheels).

For the enterprise system the main functional design domain is the business domain which comprises guidelines

for all the services and functional components available in an organization. The constructional design domains of the

enterprise should comprise the information domain which represents the physic and virtual entities of an organization,

the organization domain which specifies how the enterprise is organized to behavior, the application domain which

supports the business requirements and the technology domain which explicits how the technology will support all the

previous domains [Sousa et al., 2006].

Domains Areas of Concern

Domains SubDomains Flexibility Compliance

Business

Customers B1,B2

Partners B3

Rev. Model... B5,B6

Organization

Processes O1 O2

Culture O3,O4

Employees... O5 O6

Information ...

Application ...

Technology ...

Table 2.1: Architecture example

Principle

Statem.

[B3]

Partner’s agreements must be flexible enough to quickly adjust

to added-value customer’s requests and last minute orders

Rationale Industry dynamics appeal for a great responsiveness near the

customer. Hence, ability to quickly negotiate with its partners

is crucial for new just-in-time offers or to fill flights...

Impli

cations

User’s system must be able to accept specific requests from the

customer. Communication channels must be standardized

Key ac-

tions

Study of agreements compliances. Analysis of how to achieve

flexibility and speed in agreements. Pilots with partners to gain

experience and adjust the way of cooperate.

Table 2.2: Principle example

2.10 Governance

In the previous sections we analyze an enterprise from a systemic point of view, we introduce the design and engineering

processes and disciplines, as well as the role of the prescriptive architecture notion in restricting the undesirable freedom

of these two processes. The proactive governance over such aspects is critical to the success of the enterprise strategy.

The word governance derives from the Greek verb kubernao used for the first time by Plato meaning to steer. In

a broader sense the term governance has a similar connotation, used to express control, guidance or regulation over

something: a project, an area of an enterprise, the enterprise itself approached as an integrated whole or any other

system. Hence, governance can be exercised at different levels.

However, the term governance is often perceived as a sub-discipline of management. When we use the term man-

agement, we are concerned about a competence responsible for the execution of a certain activity. We can think in IT

management, the role of management here is to assure the effective delivery of IT products and services. When we use

13

the term governance, we are not concerned with the execution but with the guidance that enables the correct execution

of a certain activity. If we think in IT services delivery case, governance is concerned with the creation of principles,

frameworks, methodologies that can guide the effective services delivery.

Two fundamental different views on governance can be distinguished: (1) a mechanistic view, a dominant and

traditional perspective on governance, which can be related to deep-seated characteristics of Western thought; (2) an

organismic view which is reminiscent of the contrasting aspects of Eastern thought. The Western thought lies on three

essential aspects [Hoogervorst, 2009]:

• Reductionism: believes that complex system can be understood through knowledge about smaller parts and the

great the detail is achieved the greater understand can be produced;

• Rationalism: views reason as the main source of knowledge and the route to an objectively knowable world which

can be understood through intellectual and deductive thinking instead of sensory criterion;

• Determinism: holds that everything must have an identifiable cause (i.e. causal explanations for everything that

happens). It is possible to produce with the same actions a predefined result;

The mechanistic view is based on this reductionist, rationale and deterministic mindset where the enterprise is per-

ceived as a machine with employees as instrumental parts in a framework of minute division of labor, governed by a

managerial hierarchy with a relentless internal focus on control and measurement of production and distribution. The

traditional and formal planning process fits this mechanistic governance viewpoint where governance is directly related

with top-management and the governance outputs is specific (targets, budgets, business cases) so that the strategy can

be implemented [Hoogervorst, 2009]. Within the perspective we outline a set fallacies such as the lack of answers to

the core reason for strategic failures, denial (ignore) the fundamental internal and external complexity and related uncer-

tainty that is associated with enterprises and enterprising, and this mechanistic view does not address the importance of

employee involvement for enterprise performance and development.

As we have been outlining the behavior of a system cannot be predicted or even envisioned from knowledge of what

each component of a system does in isolation, since a complex system has emergent behavior that comes out of the

complex interaction of many participants which it is uncertain, no-linear and it has a large scale of interdependencies

[Ackoff, 1999, Hoogervorst, 2009, Eberhardt Rechtin, 1999, Weinberg, 2001]. According to [Daft, 2006] “as environ-

mental uncertainty increases, organizations tend to become more organic, which means decentralizing authority and

responsibility to lower levels, encouraging employees to take care of problems by working directly with one another,

encouraging teamwork, and taking an informal approach to assigning tasks and responsibilities”.

Figure 2.3: Stressing governance approaches according to a mechanistic and an organismic thinking

14

Since the mechanistic view on governance based on formal planning and control is not adequate to deal with chaos

and uncertainty, the focus on people and their creativity is essential to deal with such issues. Enterprise performance

does not follow from a mechanistic governance focus but from coherent and consistent design. This is the basis of the

organismic perspective where employee involvement is viewed as the essential source for ideas and renewal as well as

developing emerging initiatives at the “creative boundary”. The organismic perspective brought a shift from the focus

on “what is” to focus on“what could be” and from conformity to creativity. According to this organismic perspective

the governance is viewed as an organizational competence rests on personal competencies of employees (Enterprise

Engineer, Enterprise Architect, Business Architect, IT Architect). The differences between mechanistic and organismic

perspectives are analyzed in table 2.3 and figure 2.3 [Alberts & Hayes, 2006, Hoogervorst, 2009].

The widely discussed notions of corporate governance and IT governance are often related with a mechanistic view

associated only with board and senior management competence. Since enterprise strategy and design subjects transcend

the capabilities of the CG it can only be addressed within the overall scope of enterprise governance. The limitations of

these two governance approaches and why effect corporate and IT governance can only be arranged within the overall

context of enterprise governance will be exploited in the state of the art (see section 5.3).

The lack of unity between IT governance and Corporate Governance and the need to guide enterprise development in

a holistic manner led to a still maturing notion of Enterprise Governance (EG). EG has its origins in corporate governance

limitations. It resulted from the need to assure the interests of shareholders by concerning also strategic issues (and not

only compliance aspects), since strategic implementation is one of the main reasons for failures and consequently for

changes in share prices. Therefore, enterprise governance is essentially about conducting properly at the enterprise-wide

level in order to ensure success in the implementation of the enterprise strategy.

In line with the need of an organismic view on governance, the enterprise governance should not primarily concern

management-oriented activities such as planning, decision making, risk management, but is about developing a coherent

and consistent design. This focus on design is crucial for the strategic and operational success. This governance com-

petence responsible for the design guidance should integrate the various enterprise skills, knowledge and technology

(organizational competence). We will adopt the EG notion defined in [Hoogervorst, 2009]:

[Enterprise Governance] “the organizational competence for continuously exercising guiding authority over enterprise

strategy and architecture development, and the subsequent design, implementation and operation of the enterprise”

[Hoogervorst, 2009].

Mechanistic Perspective Organismic Perspective

Enterprise complexity can be mastered through knowledge about fun-

damental parts;

Enterprise reality can be objectively captured, measured and controlled;

Measurements define reality;

Events have identifiable causes that determine the state of affairs;

Cause and effect relationships can be established that enable a planned,

top-down control of enterprise performance;

Future is under intentional human control; strategy can be planned;

The more employees behave according to predefined tasks and perfor-

mance targets, the better enterprise performance

Enterprise behavior is emergent and cannot be defined from isolated parts;

Enterprise reality is socially constructed;

Cause and effect relationships vanish in complexity, dynamics, and the

associated uncertainty;

Enterprises are cognitive systems that learn and develop knowledge;

Enterprise strategy is not the result of planning but of learning (emergent);

Self-control and self-organization are essential for enterprise perfor-

mance, innovation and the capacity to change;

Employee involvement is crucial for dealing with complexity, uncertainty,

strategic transition barriers, and enterprise learning

Table 2.3: Mechanistic perspective vs. Organismic perspective

15

2.11 Summary of Thesis Context

The systemic approach to problems focuses on systems taken as a whole, instead of its components approached in

isolation. Within this view an enterprise is perceived as goal-seeking system, intentionally designed by a set of interacting

human beings behaving according to “assigned authority and corresponding responsibility against a common background

of social norms and values”. Analyzing a system by means of its interdependencies can be impractical when dealing with

complex systems such as enterprises. Interpreting the enterprise behavior, norms among other cognitive aspects to master

complexity and guide the design in a holistic manner is required during strategy implementation to achieve integration

among enterprise components. Architecture provides this design guidance by means of principles and standards.

We introduced the notion of design as the production process of conceptual models which can be approached at

different abstraction levels. The system design process comprises two different perspectives that should not be mis-

understood. The construction perspective deals with the system elements and their relations/interactions (construction

design). The functional perspective deals with the construction manifestations over the time (functional design). Ar-

chitecture can be seen as the bridge that enables to operationalize the functional and constructional perspective through

design guidelines that can be linked to the enterprise objectives and strategy.

The highest conceptual model resulting from the design is the enterprise ontology. In our context, enterprise ontol-

ogy is an independent-implementation model that describes the enterprise approached in a holistic manner. To ensure

integrated enterprise design we need principles and standards provided by enterprise architecture (EA) which provides

guidance from different design domains. EA also guides the transition from ontological models to construction models.

This means that EA also offers help to engineering activities which start from the ontological model, produce a set of

subsequently more detailed white-box models and end with the implementation model.

However, it still remains unclear who is the competence responsible to define the enterprise architecture and offer

other forms of governance for the enterprise to achieve strategic and operational success. For this we introduce two

different thinkings. Within enterprises the mechanistic thinking is relevant for creating and addressing the structural-

functionalistic enterprise foundation. This is a prerequisite for effective employee involvement, and the ability to ex-

ploit the organismic perspective on organizing and governance. The organismic thinking acknowledges and addresses

enterprise complexity, emergence, dynamics, uncertainty and design.

Enterprise performance does not follow from a mechanistic governance focus - planning, decision making, risk

management and accountability structures - but from coherent and consistent design. Since the enterprise strategy and

design subjects transcend the capabilities of the corporate governance and IT governance disciplines, they can only be

addressed within the overall scope of enterprise governance. The focus on design associated to the enterprise governance

is crucial for achieving integration among the enterprise components and subsequent agility, flexibility and optimization.

We argue that the governance should be perceived and established from the organismic perspective. Consisting

in an integrated whole of knowledge, skills and technology, whereby employees are viewed as the crucial core for

continuously exercising guiding authority over enterprise strategy and architecture development, and the subsequent

design, implementation and operation.

16

3Thesis Problem

It isn’t that they can’t see the solution,

it’s that they can’t see the problem

– G. K. Chesterton

This chapter introduces the main problem of our research. The definition of the thesis problem allows the reader

to understand the motivation underlying the thesis statement. This chapter is divided in three sections. Section 3.1

introduces the main problems regarding the practical case that will be used to validate the research artifacts. Section

3.2 summarizes why traditional governance approaches cannot effectively guide the enterprise dynamics and introduces

what is still lack in literature regarding the recent organismic governance approaches. Finally, Section 3.3, supported by

the previous sections, describes the main problem that we address in the thesis.

3.1 The application scenario - validation

To illustrate the thesis problem and to validate the subsequent design artifact, we propose the reader to look to the

Portuguese DIAP inquiries direction (DID) case (see Appendix 4), a sub-system of the Portuguese Justice System (PJS).

DIAP is the organization responsible for the repression and prevention of crime, being responsible for the prosecution

in the Lisbon district, inquiries direction relating to crimes occurring in areas belonging to different constituencies in the

District Court of Lisbon, and it represents the Public Ministry at the Court of Criminal Investigation in Lisbon.

In terms of inquiry direction, DIAP promotes a set of relationships with other external entities, establishing complex

and demanding streams of information (e.g. OPCs, Courts, Complainers etc.). The current major initiatives regarding

inquiries direction combined with growing users demand for justice procedures efficiency, together with considerable

advances in information technologies are driving efforts to align DIAP and external entities that need to share key pieces

of information at critical points in the justice process. For these initiatives to be successfully developed, enabling the

timely and efficient sharing of information within and between entities, they require a governance competence with the

vision, body of knowledge and authority to align the stakeholders energies and to guide the justice changes at the design

and operational level in a reactive and proactive manner.

We outline the following interrelated problems:

1. Inconsistency and incoherence among DIAP elements. This is clearly visible in the lack of coordination and

communication between internal and external entities (e.g. lack of coordination between OPCs, magistrates of the

MP, courts and other entities), resulting in long delays in conducting diligences and crime investigation.

2. Lack of attention to address at the design level aspects such as security issues, information access, roles and subse-

17

quent authorities (authorization and delegation processes), responsibilities and competences. Given the dynamic

nature of the DIAP, the on-going organizational changes and the critical information that some of DIAP’s actors

must have access, not addressing properly these aspects translates in the possibility to practice non-legal acts, to

assign roles to people with inadequate competence, to not assign properly information access to each role, among

others aspects. Moreover, there are no adequate security mechanisms and instruments to support audit procedures.

3. The PJS where DIAP is part of has not been treated as an organic whole. As a result, it lacks standards and

principles which should be devised from a global architecture framework to support the operation of all the justice

actors and the justice procedures. Consequently, there is no global supporting technological infrastructure leading

to misalignment among the information systems between the justice components.

4. Lack of a global vision in conducting changes initiatives and misalignment between the interest of the stakeholders

(e.g. conflict of interests between Courts magistrates, MP magistrates and justice officials). This is a result of

inadequate change management, where changes do not have associated an appealing and credible vision and

inadequate attention is paid to the change design before being implemented. A central competence to motivate the

stakeholders for the need and importance of changes in the Justice System is still lacking.

5. Regarding information, there is a lack of synchronization and harmonization of cross-sectional data, due to the

existence of multiple applications, themselves distributed in nature. Integrity and authenticity of the information

is not being addressed properly at the design level and it is still lacking audit processes to ensure that these issues

at the operational level conform what was defined at the design level. Moreover, current information is prisoner

of the software.

6. From a technological point of view several problems can be enumerated. We outline that systems were not

designed to support most of the features required by the agents of the JS in their relationship with each other, with

the information available throughout the system and with the Process. This results in inadequate functioning to

meet the operational needs of entities of the justice system.

7. Incapacity of DIAP to deal with the on-going changes and ensure the correct execution of specific areas of concerns

at the operational level which is a result from the lack of holistic construction models (resulting from weak or no

attention to design) and the lack of mechanisms to guide the engineering, implementation and on-going operation

processes.

The lack of an enterprise governance can be in the origin of (or be a solution path for) the above problems. A

governance competence is required for addressing the enterprise design process, restricting its undesirable freedom,

ensuring that this process is aligned with the enterprise strategy, ensuring the correct implementation of the outputs

resulting from the enterprise design process (a set of projects and programs), and establishing a set of normative outputs

to ensure alignment between enterprise operation and enterprise design and to guide the enterprise operation dynamics

by addressing the enterprise resilience to hazards.

3.2 Limitations of traditional governance approaches and gaps in the still maturing organis-

mic governance approaches

Following our thesis context description, the notion of governance at the enterprise-wide level has been associated

with the execution of management activities which deviates the governance from its main purpose which is to guide

18

the enterprise dynamics in a holistic manner. The focus on the enterprise design will allow to produce consistent and

coherent construction models of the enterprise and thus, is essential to maximize the enterprise integration.

Given the highly organized complexity of enterprises, a top-down, structural and management oriented governance

competence associated to a mechanistic perspective is not anymore adequate to govern the enterprise (we refer the reader

to section 2.9). We argue that a governance competence should be associated to an organismic perspective relying on

the diverse skills, knowledge, creativity and free will of the enterprise employees which is essential to restrict the highly

design freedom.

The recent governance approaches argue that the governing system should not only focus on compliance processes

but on all essential aspects from all the enterprise design domains that enable the enterprise to produce integrated con-

struction models. To approach the enterprise as an organic whole it is required a competence transversal to all the

enterprise domains and thus, an organismic governance approach whereby the enterprise collaborators are view as cru-

cial core the guide the enterprise design and subsequent operation.

However, it is still lacking literature that relates the role of the enterprise governance with the ongoing changes that

take place within the enterprise. As we reviewed in the thesis context, researchers have been arguing the importance of

this governing system in restricting the design freedom in the form of functional and constructional design principles

during the system development process. But, how can these principles guide the enterprise behavior when changes

occur? How can the enterprise governance guide the actors’ dynamics? How can the enterprise governance ensure that

when a change occur the impacts of the change will be properly concerned? How to ensure that the changes are guided

effectively in order to anticipate undesirable scenarios? How to control the dynamics of change in a proactive way?

Moreover, the notions of governance and ontology have not been properly bringing together in literature. Another

aspect that is still lacking in literature is a set of guidelines, reference models and methods that help the enterprise

governance to define a set of principles (guide the design process) and a set of rules (guide the operation dynamics).

3.3 The Problem

In this context, we address two interrelated problems. First, the lack of integration among the various enterprise elements

at the design level resulting from the lack of attention of the enterprise to its design process and/or the lack of governance

and modeling mechanisms that enable the enterprise complexity to be mastered from a holistic point of view. Put

another way, enterprises cannot effectively, from a holistic point of view, continuously build its strategy into design

while addressing main areas of concern.

Second, the incapacity to manage the enterprise dynamics at the operational level due to weak enterprise construction

models resulting from the previous problem and/or the lack of governance mechanisms to ensure the successful transition

from what is designed to what is occurring at the execution plane. Put another way, enterprises cannot effectively, from

a holistic point of view, build design into operation, handle exceptions that cause dysfunction and continuously perform

improvements, from a holistic point of view [Hoogervorst & Dietz, 2008, Ackoff, 1999]

These problems are interrelated since enterprise design and enterprise operation must be mutually aligned over time

in the sense that changes at the operation level must be immediately addressed at the design level (collateral impacts,

resolution) and changes at the design level must be operationalized. Both, enterprise design and enterprise operation

19

must be aligned with the enterprise strategy. The enterprise aspects must be addressed at all these levels, otherwise the

enterprise will not be able to operate as a unified system and the strategy implementation will tend to fail.

3.4 The IV requirements

Within the main problem of this thesis, we outline four underlying requirements triggered by the limitations of traditional

governance approaches when guiding the enterprise dynamics in the sense that these governance approaches do not

incorporate all these requirements and are ineffective in satisfying some of them. Also, emerging approaches are focused

on reduced subsets of those requirements. The four requirements underlying the thesis problem are depicted in table 3.1.

Note that this governance competence must also exercise governance over the enterprise strategy. However, since this

requirement has been successfully concerned in several governance approaches, we will focus in the alignment between

enterprise design and enterprise strategy which is comprised in the enterprise design requirement.

Moreover, the still maturing organismic governance approaches lacks artifacts (e.g. reference models and methods)

that allow the validation of these requirements. Therefore, there is space to develop new artifacts to support the opera-

tion of these governance approaches. Concluding, the problem of finding a governance approach to guide the enterprise

dynamics that solves these four requirements are relevant for ensuring the correct and continuously operation of the

enterprise system and it is still an open challenge. Here we begin our journey towards a governance approach to guide

the enterprise dynamics that satisfies these requirements.

Enterprise (Ontological) Design

process

The undesirable design freedom of the enterprise must be continuously restricted; the

enterprise design must be aligned with the enterprise strategy;

Enterprise (re)Engineering (or

Detailed Design) process

The governance competence must guide the process of detailing the constructional enterprise

models (from the ontological models to the implementation models)

Enterprise Implementation pro-

cess

The governance competence must define and guide a coherent and consistent set of projects

and programs to implement the enterprise constructional models (design implementation)

Enterprise Operation The on-going dynamics must be governed and the subsequent alignment between enterprise

operation and enterprise design

Table 3.1: Governance-related requirements for guiding the enterprise system

20

4Thesis Statement

Alice: Would you tell me, please, which way I ought to go from here?

The Cat: That depends a good deal on where you want to get to

Alice: (...) so long as I get somewhere.

The Cat: Oh, you’re sure to do that, if only you walk long enough.

– Lewis Carroll (Alice in Wonderland)

Chapters 2 and 3 provided us, respectively, the conceptual environment to understand the meaning of this hypothesis

and its importance. This chapter presents the research statement, methodology, artifacts, questions and scope.

4.1 Research Statement

Thesis Hypothesis: Enterprise ontological models defined with DEMO provide essential concepts that can be used

by the enterprise governance along with the architecture notion to restrict the design freedom and guide the

subsequent enterprise operation dynamics

This research aims to address how an enterprise can deal with the lack of consistence and coherence among its

elements at the design level and ensure its alignment with the always-changing operational plane by providing a set

of conceptual models and an underlying reference method for a governance competence to guide the enterprise design

process and subsequent operation by means of essential notions retrieved from the enterprise ontological models (which

are itself defined by the enterprise governance). The DEMO methodology will be used to model these ontological models

and thus, to validate our hypothesis (we refer to the following chapter).

The thesis purpose is aligned with the research that has been developed around the organizational engineering,

information systems, sociology and philosophy disciplines. The research brings together governance themes, ontological

modeling (in particular the ψ-theory), and systemic approaches (in particular the notion of resilience). It is still lacking

in literature reference models and methods to serve as a support to the enterprise governance for guiding the enterprise

dynamics by means of the enterprise ontology. Therefore, this thesis aims to provide such prescriptive artifacts to support

the governance of the enterprise dynamics in practice. These models and underlying method use the notions abstracted

with the ontological models to guide the detailed design and guide the subsequent enterprise operation dynamics.

4.2 Research Methodology

Information systems can be considered an “applied research discipline” since it often uses theories from diverse disci-

plines, such as social science, computer science, philosophy, among others to address problems at the intersection of IT

21

and organizations. The research methodology that we used throughout the thesis is the Design Science Research (DSR)

for IS which aims to overcome research paradigms, such as the tradition descriptive approach or the interpretive research

paradigms, where the outputs are often too much explanatory and it could be argued that they are not often applicable in

real practice problems [Peffers et al., 2007].

Design research is perceived as research paradigm that purposes to overcome the problems mentioned above by

creating artifacts that are applicable to real problems (designing). Given the explicitly applied character of IS practice

and the implicitly applied character of IS research, as part of the business academe, we adopt the design research

paradigm in order to explicit value on incrementally effective applicable problem solutions. In recent years several

researchers have succeeded in bringing design research into the IS research community, successfully making the case

for the validity and value of design science (DS) as an IS research paradigm and actually integrating design as a major

component of research [Peffers et al., 2007].

Figure 4.1: Research Methodology (DSR)- Social Science vs. Engineering Science

Figure 4.1 relates theory building, design research and solution engineering according to its outputs and disciplines

associate to each methodology (adapted from [Braun et al., 2005]). Design research starts from the theories deducted

with social science methods and it uses engineering science methods to produce generic/reference outputs that purpose

to solve a problem class. Then solution engineering will use these normative outputs produced by the design research

paradigm to solve real problems in practice.

To conduct our research we used two artifacts that purpose to guide our thesis according the design research

paradigm: (1) the reference model for the design science methodology according to [Carlsson, 2006] - see figure 4.2;

and (2) the seven guidelines purposed by [Hevner et al., 2004] disseminated in table 4.1.

Awareness of Problem phase may come from new industry trends or new developments in disciplines, and it results

in a Proposal for a new research effort. Immediately behind the proposal is the suggestion phase where should be

produced a tentative design (phase output) which should be an integral part of the Proposal. Suggestion is an essentially

creative step wherein new functionality is envisioned.The tentative design is implemented in the development stage. The

implementation techniques are highly dependent on the type of artifact to be constructed. An algorithm may require

construction of a formal proof, while the development of a reference method (our case) may require deductive work.

After the artifact is developed, it should be evaluated. Deviations from expectations, both quantitative and qualitative

are carefully noted and must be tentatively explained. That is, the evaluation phase contains an analytic sub-phase in

22

Figure 4.2: Design Science Research Methodology

which hypotheses are made about the behavior of the artifact. In DSR the evaluation phase results and additional

information gained in the construction and running of the artifact are brought together and fed back to another round of

Suggestion (the circumscription arrows of figure 4.2).The results of the evaluation phase are consolidated “written up”

at the Conclusion phase. The knowledge gained in the effort is frequently categorized as facts that have been learned

and can be repeatably applied/invoked and may well serve as the subject of further research [Carlsson, 2006].

Guideline Description

1: Design as an Artifact “DSR must produce a viable artifact in the form of a construct, a model, a method, or an instantiation”.

2: Problem Relevance “The objective of DSR is to develop technology-based solutions to important and relevant business problems”.

3: Design Evaluation “The utility, quality, and efficacy of a design artifact must be rigorously demonstrated via well-executed evaluation

methods”.

4: Contributions “Provide clear and verifiable contributions in the areas of the design artifact, foundations, and/or design methodolo-

gies”.

5: Research Rigor DSR “relies upon the application of rigorous methods in both the construction and evaluation of the design artifact”.

6: Design as a Search Pro-

cess

“ The search for an effective artifact requires utilizing available means to reach desired ends while satisfying laws in

the problem environment.”

7: Communication “DSR must be presented effectively both to technology-oriented as well as management-oriented audiences.”

Table 4.1: The guidelines purposed by Hevner to guide Design Science Research

4.3 Research Artifacts

According to [Hevner et al., 2004], the first guideline in conducting a design-science research is to address design as

an artifact. This artifact must be a construct (vocabulary and symbols), a model (abstractions and representations), a

method (algorithms and practices), or an instantiation (implemented and prototype systems). Figure 4.3 presents the

diverse artifact for the different research sciences (figure adapted from [Braun et al., 2005] and [Hevner et al., 2004]).

In order to proof or reject our thesis hypothesis three artifacts must be clearly conceived:

1. a high-level conceptual model that outlines the relation between the main concepts analyzed in this research

(enterprise governance, ontological and other construction models, enterprise design process and enterprise oper-

ation) in order to demonstrate the thesis statement;

2. a set of detailed conceptual models that explain in detail how the governance can retrieve from DEMO ontolog-

ical models a set of normative outputs to guide the enterprise dynamics;

23

3. a method to guide the enterprise governance in guiding the enterprise design and operation. This can be perceived

as meta-method to guide the enterprise dynamics since it will guide the EG in guiding the enterprise dynamics.

Figure 4.3: Artifact types in Social Science vs. Business Engineering vs. Design Science Research

4.4 Research Questions

To establish the path that will help us to analyze how the enterprise ontological models can help to govern the enterprise

dynamics, three questions need to be answered. (1) To what extent does the current research in the field of ontology

address the enterprise modeling in a holistic manner? (2) To what extent does the current research in the field of

governance address guidance at the enterprise wide-level? (3) How can the notions of ontology and time be bridged

in order to allow continuous governance over the enterprise dynamics? Additionally, it is important to analyze the

notions and design artifacts that already exist to support the EG in guiding the enterprise. (4) To what extent does

the current research address the issue of governance over the different enterprise semantic contexts? With the results

of the questions below, a fifth question needs to be answered. (5) What is the connection thread between DEMO and

Enterprise Governance? Finally, the lasts question proposes to address the contribution of our research. (6) How could

EG operation be tackled using the DEMO methodology?

4.5 Thesis Boundary

On one hand, enterprise engineering discipline outlines the importance of the role of construction models for (re)designing

enterprises, to support communication, information exchange and work monitoring activities and thus, addressing orga-

nizational self-awareness by leading to enhanced conditions for organizational agents to interact and make sense of their

environments. An essential aspect regarding the enterprise design is the need of an organizational competence to contin-

uously govern the design process. We identified that traditional governance approaches do not pay adequate attention to

the enterprise design. And, that the enterprise design subject transcends the capabilities of these traditional approaches

and thus, it can only be addressed within the overall scope of an organismic governance approach. The limitations of

governance regarding the design level and the other levels within the enterprise development process were used to derive

four requirements that this organismic governance approaches should be able to deal with.

On the other hand, the challenge is that every requirement identified must be able to deal with the on-going changes

24

affecting the enterprise in the sense that (1) the construction models resulting from design process need to capture the

static and dynamic aspects of the interactions of the enterprises’ agents, activities and resources and (2) changes in

the enterprise construction models must be correctly engineered and implemented. Unexpected problems, as stated in

[Weick, 2001] seems to be one of the drivers of change in organizations. In this manner, the governance competence must

exercised continuously guidance and deal with the enterprise dynamics in order to ensure timeless alignment between

the enterprise strategy, design and operation. Moreover, in the thesis hypothesis we purpose to validate the importance of

the ontology notion (the highest level construction model) in supporting this organismic governance approach in dealing

with the enterprise dynamics.

Therefore, there are three themes that will be carefully analyzed in the research state-of-the-art:

1. The ontology notion: the state of the art of modeling enterprise ontologies is analyzed (from the ontological work

of philosopher Mario Bunge and language/action perspective on conversation networks by Flores and Winograd

to the DEMO methodology); a brief reasoning why DEMO was chose for the research is presented as well as its

underlying theory (ψ-theory) and way of working;

2. The (enterprise) system dynamics: this section purposes to link the structure of an organization (ontology modeling

approach in ontology state of the art) with the behavior of agents within the organization and thus, we introduce

the ontology of time, exploit the notion of system function and the notion of system resilience. On-going changes

at the operational level and the consequent (re)design of the enterprise artifacts should be considered central issues

in modeling approaches that aim to have a representation of reality continuously updated and reflecting important

organizational knowledge;

3. The governance approaches: the role of a governance competence to master the enterprise complexity and to

guide the different semantic planes of the enterprise over time is an essential aspects for dealing with undesirable

changes and maximizing enterprise integration. In this section we introduce the different perspectives and subse-

quent limitations of the wide spread forms of governance - corporate governance, IT governance and architecture

governance - in order to understand the notion of enterprise governance and its relevance;

All the aspects that are not directly related with these themes are left out from the thesis scope. The state-of-the-art of

each one of these themes will be introduced in this second part of the thesis.

Figure 4.4: Thesis boundary: the three main themes to exploit

25

IIFindings

5State-of-the-Art

Your work is to discover your world

and then with all your heart give yourself to it

– Buddha

Part I introduced our universe of discourse, including an introduction to the different subjects of the thesis context

that are relevant to understand the whole document, the thesis context, thesis problem and subsequent requirement,

and thesis statement. In this chapter we perform a research in the fields outlined in the thesis boundary, which aim to

answer to the first three research questions: to what extent does the current research in the field of enterprise modeling,

governance and system dynamics address guidance over the enterprise dynamics in a holistic manner?

5.1 System Ontology

The ontology notion has been used in several disciplines1 as a form of knowledge representation about the world or

some part of it. Recapturing the ontology concept introduced in the UoD, ontology was first used in philosophy with the

intention to refer to the categories of things that may (or may not) exist in some domain. Disciplines that were dealing

with knowledge sharing used this notion to refer to a description of the concepts and relationships that can exist for an

agent or a community of agents.

In a broader sense, ontology can be perceived as a specification of a shared conceptualization. This specification

can be specified as a “linguistic artifact” which provides a shared vocabulary of essential concepts for discourse about a

subject domain and defines precisely the meaning of those concepts. Ontology can be specified in an informal manner

as a set of terms (concepts) and their definitions stated in a natural language. Or specified as a collection of axioms

and formulas described in a formal language. In this manner, ontologies provide the basis for semantic modeling of

subject domain. The notion of system ontology restricts this specification of a shared conceptualization to the system’s

domain. Hence, system ontology imposes a structure of the system domain and it constrains the possible interpretation

of terms. In our thesis context, the purpose of an ontology is the specification of a conceptualization for describing and

understanding the construction and operation of the enterprise system. Therefore, we will briefly describe the state of

the art of ontology in particular regarding enterprise modeling.

Philosopher and physicist Mario Bunge performed early a rigorous and comprehensive scientific study of system

ontology. In [Bunge, 1977] it was developed an ontological framework which articulates a set of high-level abstract

constructs that are intended to be a means of representing all real-world phenomena. His purpose was to define such

1The notion of ontology has been studied in information architecture, software engineering, system engineering, Semantic Web, artificial intelli-

gence, biomedical informatics, among others. The purpose of using the ontology notion differs from each domain to another

26

constructs by starting from the ontological traditions arising from the work of Aristotle, Leibniz, Aquinas, Spinoza,

Descartes, among others, and by bridging them with contemporary research and the rigor of mathematics. Bunge in-

tended of his ontology to be “both exact and scientific”. Later, in [Wand et al., 1999] was provided a rigorous definition

of several conceptual modeling constructs based on the ontological works of Mario Bunge, comprising a set of onto-

logical constructs (thing, property, attribute, functional schema, state, law, interaction, class, kind, and composition) to

understand the nature of a relationship. The motivation behind the research was to define precisely the meanings of the

conceptual modeling constructs in order for employing them effectively.

Ontological design for modeling enterprises has its genesis in the work of Flores who formulated a design theory for

organizational communication during her PhD and later introduce a way of creating commitments among participants

based on a phenomenology of work practice as conversation networks [Flores et al., 1988]. Flores based the model

development for ontological design in hermeneutics and Speech Act Theory.

Winograd extended Flores initial researches on cooperative work and exploited the “language/action perspective”

which provides an ontology that emphasizes the social activity by which “agents” generate the space of cooperative

actions in which they work, rather than the mental state of individuals [Winograd, 1988]. The basic idea is that social

activity is carried out by language and communication. In the same fashion, [Auramäki et al., 1988] present a method

for modeling offices as systems of communicative action through which people engage in actions by creating, modifying

and deleting commitments that bind their current and future behaviors.

An important knowledge field triggered by the works of Flores and Winograd works contribute for the process of

Interactive Management (IM) which comprises a set of methods that have been applied in large-scale social systems

design problems [Warfield & Cardenas, 2002]. In [Warfield & Cardenas, 2002] is presented a framework for communi-

cations and knowledge management in the form of an ontology for organizational design. The basis of this framework

is to facilitate members in group design by integrating pluralistic views among all the participants in the process of

establishing designs for complex system problems that cannot be resolved through conventional design processes.

Informal approaches for modeling enterprise ontologies have been influencing the way enterprises are analyzed. We

outline the early work of Mintzberg who distinguished five basic blocks of an organization and further distinguished five

different organization configurations that are encountered in practice [Mintzberg, 1983]. His “ontology” for modeling

organizations includes several mechanisms that together aim to achieving coordination among the enterprise elements,

like goals, positions, authority, communication and work processes. The different organization parts are distinguished

by the specific roles these parts play with the above means in improving coordination.

Figure 5.1: Organizational object taxonomy by Fox et. al

27

In [Yu & Mylopoulos, 1994] it was proposed a formal model for enterprise modeling which has been used to analyze

alternative process designs in business reengineering. The enterprise is approached as a set of social actors that are

intentional, having motivations and beliefs, evaluating their opportunities and vulnerabilities with respect to each other.

In [Fox et al., 1997] an enterprise is perceived as a set of constraints and it is presented a taxonomy for modeling

the enterprise ontology based on a set of restrictions defined descriptively. The research outlines the notions of role,

organization-agent, activity, goal, division, authority, skill, commitment, and communication link as the basis of the

organizational ontology. The relation among these concepts is depicted in figure 5.1 [Fox et al., 1997].

More recently, in [Sousa et al., 2006] there were presented three essential enterprise concepts to be modeled - activ-

ities, entities, and roles. The activities (verbs) comprise all the activities (services and functional components) available

in an organization. The (2) entities (names) represent the physic and virtual elements of an organization. And the (3)

roles are the observable behavior of an entity in the scope of particular interaction contexts.

Figure 5.2: Relation among enterprise concepts Figure 5.3: Organizational modeling framework

In [Zacarias et al., 2007] it was proposed a high-level framework to enhance OSA (see figure 5.3). In this research,

the three concepts presented above were extended with resources (inanimate entities), agents (animate entities) which

are organized in networks related to specific activities and resources named contexts (see figure 5.2). These concepts

are approached in three different layers. The (1) action layer captures agents interactions and defines a set of rules for

their actions; the (2) decision making layer defines rules to express when to use specific interaction strategies or patterns;

and the (3) change/learning layers addresses how such interactions change and the design processes associated to these

changes [Zacarias et al., 2007].

A group of researchers, professionals and professors join forces to develop a methodology to (re)design and (re)engineering

organizations named DEMO. The methodology is based on the ψ-theory which integrates the ontologic theories of Mario

Bunge, the language/action perspective (also approached by Flores and Winograd), systemic theories, among other dis-

ciplines. According to DEMO, the notion of ontology is centered in the commitments established in the communication

between social individuals (i.e. human beings). They enter and comply with commitments towards each other.

In [Dietz, 2008] a complementary view on the enterprise ontology is brought in the context of the Generic System

Development Process. Ontology is viewed as the ‘highest level” conceptual model producing by the enterprise design

process (functional and construction arrangements) which is full-independent of the enterprise implementation while at

the “lowest level” there is the implementation model [Dietz & Hoogervorst, 2007]. In this manner, we can differentiate

between ontological design which is the process that produces the ontological models and detailed design (or engineer-

ing) which is the continuous process of detailing the ontological models till producing the implementation models.

28

5.1.1 Towards a method for modeling the enterprise ontology

To validate our thesis hypothesis, we will use the DEMO methodology to model the enterprise ontology. DEMO is

a methodology for the (re)design and (re)engineering for organizations. According to DEMO, enterprise ontology as

its roots on ψ-theory and is perceived as a model for describing and understanding the enterprise construction and

operation which is fully independent of the way the enterprise is implemented. Moreover, an enterprise ontology should

be coherent, comprehensive, consistent, concise and it should only abstract the essence of the enterprise [Dietz, 2006].

Why DEMO? A problem in the engineering of ontologies is their evaluation. In [Fox et al., 1997] a number of

criteria have been proposed. It is important to note that evaluating and comparing methods to model the enterprise

ontologies does not belong to our thesis scope. However, we present a brief reasoning why we choose to use DEMO.

There is a wide set of formal (textual or visual) languages and respective frameworks/methodologies that can be used

to model enterprise ontologies (e.g. Common Logic, Dogma, IDEF5, OWL, among others). However, these languages

were not directly developed for the specific purpose of modeling an enterprise, since they can be used to model the

ontologies of any phenomena. Therefore, their broad scope make the resulting enterprise ontologies not concise (highly

descriptive since most of these language are derived or based on first-order logic), and its comprehensiveness is reduced

in comparison with ontologies resulting from methods that their strictly purpose is to model the enterprise reality and

that already define a set of enterprise concepts that can guide the ontological modeling.

In literature there are several techniques created with the purpose of modeling enterprises from Dynamic Enterprise

Modeling, Extended Enterprise Modeling Language, CIMOSA, Integrated Enterprise Modeling (IEM), TOVE Enterprise

Modeling, among others to Enterprise Architecture frameworks that also support modeling techniques, such as TOGAF.

It is not from the thesis scope to comparatively analyze these different modeling techniques, however we list a several

reasons why we choose DEMO to validate our hypothesis:

• None of the enterprise modeling techniques purpose a reduction of complexity as high as the one purposed by

DEMO (over 90% ). This topic is directly related with the concise and essence focus qualities of DEMO. As we

analyzed previously, mastering the enterprise complexity as an organic whole is one of the main pre-requirements

for properly governance;

• Most of these modeling techniques are not based in a strong well-formed theory. DEMO methodology is based

on a rigorous theory: the psy-theory which combines the knowledge from ontological works, language/action

perspective, logic and systems theories. This stands for coherence and consistence of the DEMO models;

• DEMO clearly defines three notions that we considered relevant in governing the enterprise dynamics (compe-

tence, authority and responsibility). Most of these notions are absent or not clear defined in others enterprise

modeling techniques;

• DEMO has been widely accepted in both scientific research and practical appliance. DEMO practical application

has been successful validated in several enterprises 2. An extensive ten year study executed with 28 projects

concluded that DEMO is a good method for the fast (re)design of organizations [Mulder, 2006].

• Demo has been used as a base for formalizing enterprise architecture and governance and for formalizing the

splitting and allying of enterprises 2. This makes a great choice since our scope is totally aligned with the purpose

of DEMO methodology and its research domain.

2DEMO Practical case studies and Publications [Retrieved from http://www.demo.nl/ in 1 July 2010]

29

5.1.2 Ontological Modeling with DEMO

This section will familiarize the reader with the most important concepts incorporated within the DEMO methodology,

first we will provide an insight about how an organization is approached by DEMO and then we will summarize the

background theory of DEMO (the ψ-theory).

In DEMO the organization of an enterprise is perceived as a social system having as active elements social indi-

viduals that behave “according to assigned authority and corresponding responsibility against a common background

of social norms and values” [Dietz, 2006]. An organization is a consequence of people’s purposes in the sense that

“organizations happen, and people act and interact in organizations, as a result of their interpretations” [Dietz, 2006].

As we outlined before, the ontology of a system is conceptually defined as the “understanding of its construction and

operation” completely independent of the way the system is implemented. Operationally, the ontology of a system is

“the ’highest’ level constructional model” of that system [Dietz, 2006]. The core elements in the ontological model of

an enterprise are actor roles, coordination and production acts and the respective facts.

Moreover, an enterprise is a heterogeneous system composed as the “layered integration of three homogeneous

systems” (figure 5.5) [Dietz, 2006]. All the three homogeneous systems belong to the category of social systems in

the sense that the elements are subjects that“ enter and comply with commitments towards each other”, it is only the

production that differs (with regard to the type of production, we refer the reader to Figure 5.4: B stands for Business, I

stands for Information and D stands for Data). In addition to this, Figure 5.5 is important because it indicates that there

is nothing above the B-organization of an enterprise: the B-organization is “the complete knowledge of the essence of

the enterprise; all the rest in only realization and implementation” [Dietz, 2006].

Figure 5.4: The layered integration of an enterprise Figure 5.5: Organization theorem

DEMO provides a methodology to model the enterprise ontology which represents the essence of an enterprise

in intellectual manageable way. The scientific root of DEMO is the Ψ-theory which combines the knowledge from

OER paradigm, language/aspect perspective (LAP), logic and systems theories, and two additional theoretical pillars

(Stamper’s Semiotic Ladder and Mario Bunge’s Ontology) [Dietz, 2006].

The Ψ-paradigm (Performance in Social Interaction) constitutes the essential difference between organizations and

information systems. It states that “the operational principle of organizations is the ability of human beings to enter

into and comply with commitments towards each other, collectively called social interaction”. The theory defines four

axioms and a theorem:

The construction axiom: An enterprise consists of actors performing productions acts (P-acts) to bring about the

enterprise mission and coordination acts (C-acts) to enter into and to comply with commitments. An actor is

defined as a person fulfilling an actor role and an actor role is defined as the “authority to perform a particular

30

type of P-acts and the corresponding C-acts”. The C-acts initiate and coordinate the execution of P-acts. The

result of successfully performing ’acts’ are ’facts’. Furthermore, regarding these acts two worlds are distinguished

the production world (P-world) and the coordination world (C-world). These two worlds constitute the enterprise

universe of discourse.

The operation axiom: For every type of C-act there is an action rule to guide enterprise actors in order to ensure that

they deal timely and adequately with their agenda (action plan).

The transaction axiom: P-acts and C-acts occur in “generic recurrent patterns” performed by two actors called transac-

tions (see figure 5.8 and 5.7) which comprise three phases: the order phase (O-phase) when the two actors attempt

to reach an agreement about the resulting P-fact (e.g. selling a good), the execution phase (E-phase) when the

executor produces the result (e.g., deciding to sell), and the result phase (R-phase) when the two actors attempt to

reach agreement about the established result. The actor who starts is called the initiator. The one who performs

the production act is the executor. Each transaction is either of the next three types: (1) embedded in some other

transaction, (2) customer transaction or (3) a self-activating transaction.

Figure 5.6: The construction axiom and the notions of

responsibility, authority and competence Figure 5.7: The generic transaction pattern

The abstraction axiom: Three human abilities play an essential role in performing C-acts: (1) forma is the ability to

produce and perceive sentences; (2) informa is the ability to formulate thoughts into sentences and to interpret

sentences; and (3) performa is the ability to engage into commitments of a C-act (ability for doing business).

The organization theorem: The organization theorem takes the advantages and benefits offered by the above specified

axioms and combines them into “one concise, comprehensive, coherent and consistent notion of enterprise, such

that the (white-box) model of this notion of enterprise may rightly be called an enterprise ontology” [Dietz, 2006].

As we approached before the organization of an enterprise is the heterogeneous system composed out of three

homogeneous systems: B-organization, I-organization and D-organization, where the D-organization supports the

I-organization and the I-organization supports the B-organization (see figure 5.5.

The common organizational theories and the Ψ-theory are related by the notions of responsibility, authority, and

competence. These notions help to explain why actors act. Competence defines the ability of someone to perform an act

(from the P or C world) and it becomes primarily manifested in the P-world (production acts) [Dietz, 2006]. In order to

be able to practice ones profession, it is necessary to be appointed or employed by a corporate body. Through such an

act, one gets the authority to practice. By responsibility is meant that one is expected to exert the granted authority in a

responsible way [Dietz, 2006]. This is naturally affected by enterprises’ and society’s norms and values.

In contrast to other modeling techniques that concentrate mainly on the function of the organization rather that on

its construction and operation, DEMO bases its approach on the construction (white-box) perspective. DEMO offers a

solid connection between the essence of an enterprise and its implementation and realization. Practical experiences have

31

Figure 5.8: The standard transaction pattern Figure 5.9: The abstraction axiom

Competence “The ability of a subject to perform a particular type of production act as well as the corresponding coordination

acts.”

Authority “The condition of being allowed to act.” It can be assigned to a subject through authorization and delegation.

Authority presupposes responsibility.

Responsibility “The quality of a subject to be committed to the coordination facts he or she has performed, as well as to

coordination acts that are addressed to him or her.”

Table 5.1: Authority, responsibility and competence notions

shown that DEMO is mostly used in combination with other modeling approaches like UML and Petri Nets. In DEMO,

the ontological model consists of four aspect models each having its corresponding diagram: the Construction Model

(CM) is the most concise model, it specifies the composition, the environment and the structure of an organization, it

comprises the identified actor roles, the identified transaction types and the information banks; the Action Model (AM)

enumerates the action rules that guide the actors in dealing with their agenda; the State Model (SM) indicates the lawful

states of the P-world and the C-world: the object classes, the fact types and the ontological coexistence rules; the Process

Model (PM) specifies the lawful sequences of events in the P-world and the C-world: the atomic process steps and their

conditional and casual relationships.

Figure 5.10: The ontological aspect models

The way of working with the models and their corresponding diagrams is the anticlockwise way as they are depicted

in figure 5.10. A detailed explanation of the different DEMO models and how to develop such models can be consulted

in Appendix 1.

32

5.2 System Dynamics

By system dynamics we considered how a system functions as a whole over time. It is of interest in this domain to

analyze how a complex system reacts when it enters in a state of dysfunction, and how it performs reactive and/or pro-

active transformations that aim to maximize the system functioning.In order to analyze how a system may react when

it is affected by hazards that can compromise its viability, we need to introduce (1) the ontology of time to capture the

system behavior, (2) the function notion of an (enterprise) system and the notion of system resilience.

The notion of time is represented as a continuous line where each point in time and each period in time (interval) are

described as the domain of discourse. We define relation ’<’ between two time points meaning that t < t′ if t is earlier

than t′. The “extended situation calculus” of [Reiter, 1991] allows us to address the notions of time line and situation

by assigning durations to situations. Intuitively, a model of the situation calculus axioms represents “a complete set of

alternative activity occurrences”. According to the situation calculus, there are three different objects: actions, situations,

and fluents. A situation is the result of a linear sequence of action occurrences. Hence, situations structure follows a tree

structure where “there exists an initial situation, and a function do(a, s) which represents the situation that results from

performing action a in situation s” [Fox et al., 1997]. Therefore, each branch that starting from the initial situation can

be understood as a hypothetical future. In this manner the situation calculus tree shows “all possible ways in which the

events in the world can unfold” [Gruninger et al., 2000].

The notion of a fluent is used to capture intuitions about the enterprise state, it represents some property of the world

whose value may change after an action have been performed. A fluent f is assigned to each situation s in the tree -

holds( f , s) - when fluent f is intuitively true in situation s. For a fluent to occur may require a set of preconditions which

hold at a particular situation. The relation pos(a, s) defines that “an action a satisfies its preconditions in situation s and

can therefore possibly occur” [Gruninger et al., 2000]. Moreover, to define complex aggregations of actions, it should

be identified subtrees of situations. Each subtree corresponds to different possible sequences of primitive actions which

occur whenever the complex action occurs.

By introducing the ontology of time we aim that enterprise models naturally co-evolve with the continuous change

at the execution plane of the enterprise. The conditional operators introduced (depending on pre-and post-conditions)

purpose to ensure that only valid structures can be built. But an important issue remains, whats the set of fluents that

an enterprise must follow? Put another way, how to maximize the enterprise functioning? In order to understand the

variables that we must concern when we analyze the enterprise function, we must need to understand the function notion.

The function notion may be approached from a static perspective (construction or white-box view) or from a be-

havioral perspective (black-box view). The function concept is often associated with the operation of a system. In

[Christensen & Bickhard, 2002, Aveiro, 2009] this concept was exploited against different knowledge fields. Starting

from these studies we depicted how the function concept is perceived in several domain (see table 5.2). As a result of

this review, we argue that the function concept restrictively associated with the behavior is limited in approaching the

normative aspects of the enterprise system and dealing with its on-going changes. Following the review of the research

conducted, we abstract four perspectives of the function notion. System function:

1. as a blue-print of the artifact (the structural properties of the entity or what is being done by the activity);

2. as the relationship between the artifact and other higher order artifacts with which the artifact i.e., to which entity

this entity belongs to or to which activity does this activity contribute;

33

3. as the expected norms (values) of the artifact that allow the artifact to be in a equilibrium state;

4. as the reasoning of the current design of a certain artifact, including what errors (unknown exceptions), conditions

or restrictions led to the design selection;

Discipline [Research:Description]

Enterprise

Engineer-

ing

[Dietz, 2008] : Function is perceived as a black-box model, where the function is specified in terms of the output

variables (which manifest it’s functional behavior) and their interrelationships with the input variables. A system

can be functionally decomposed in simpler systems with serve simpler functions, which, interrelated, serve the main

function of the main system.

IS[Kavakli & Loucopoulos, 1999] : Enterprise function as the a vertical perspective aggregating a set of activities of a

certain area of knowledge or of a certain organizational unit

[Kampfner, 2001] : Enterprise function associated to the notion of goal, control and report.

Sociology [Gingrich, 2003, Parsons, 1951] : Function notion to identify how different parts of each society contribute positively

to the operation or functioning of the system as a whole and explain the relationship of different parts of the system to

each other, and to the whole. It is introduced disturbances from the normal state of affairs, these disturbances trigger

adjustments in the various parts of society that return the society to a state of equilibrium. The concept “dysfunction”

is mentioned to understand conflicts in society; and the notion of “functional alternatives” is also mentioned as the

possibility of other different processes or parts of the system to provide the same needs as the one being analyzed.

Management[Applegate & McKenney, 1995] : Function as vertical perspective of an organization (matrix structure context).

[Paape, 2007] : Function as a coherent set of tasks, responsibilities, and authority. A function provides a common

goal for the activities undertaken.

Biology[Chauvet, 1993] : Regarding the function of a biological system, introduce the concept of “non-locality” resulting

from the hierarchy existent in a biological system, which means “a space property according to which the system

depends on mechanisms that are located elsewhere in the space”. Such distributed dependences in the several com-

ponents of a system may not be evident in a superficial analysis.

Table 5.2: Different perspectives on the notion of enterprise function

From this review, we argue that the function concept when approached to an organizational artifact should also incor-

porate certain normally expected values, the system norms, for certain vital properties of a system. The reasoning behind

this aspect is that when deviations from such norms occur, it implies a dysfunction state that can possibly compromise

the viability of the system. Hence, the enterprise norms can be perceived as a measuring rod to determine, by observing

organizational reality in a certain point in time, if the enterprise is in a state of normal functioning or dysfunction.

Moreover, the research conducted about the function notion approached by biology includes control, (re)generation

and selection mechanisms embedded in the operation of biological systems. In [Aveiro, 2009] it is purposed to incor-

porate similar mechanisms in the function perspective of the enterprise system. Specifying the diagnostics and actions

undertaken to discover, recover from the exception and solve it is also an important aspect of the function perspective.

Hence, we define the enterprise function as

[Enterprise Function] a holistic and integrative view of (1) operation, (2) norms and (3) change through (re)generation

operationalization and/or discontinuation of the enterprise system while handling detected changes or improvement

opportunities.

What brings about changes in the system state? Enterprises deal with uncertainties and unexpected events all the

34

time, where uncertainty presents both opportunities and risks. There can be distinguished two kinds of change. Proactive

changes involve actively attempting to change the system state. Enterprises that take a proactive approach to change try

to capitalize on potential future opportunities or to avoid potential future threats. Reactive changes occur when an

enterprise changes the system state after an opportunity or threat has already occurred.

How the system reacts to unexpected changes and how these changes will affect the system? Now we are concerning

how the system itself reacts when it is stressed and move from its equilibrium (stability). An important notion should be

defined regarding the behavior of a system after a change of its state occurred - resilience. Resilience is the system ability

to persist in a equilibrium state when a changes with negative impact occur [Dalziell & McManus, 2004]. Therefore, it

is related with the system’s ability to respond and recover from a disaster event.

The resilience concept was early proposed in [Holling, 1973] in the context of an ecological research to differentiate

between a system that is stable (persists in a state of equilibrium) and how a dynamic system behaves when it is stressed

and move from the equilibrium state. The scope of the term evolved to incorporate the qualities that enable a person,

community or organization to deal with, adapt to and recover from a disaster event [Buckle et al., 2000]. In literature the

term is widely use regarding two different disciplines: ecological resilience and engineering resilience (see table 5.11).

Discipline Description

Ecological

Resilience

Focus on maintaining existence of func-

tion. It is “the magnitude of disturbance

that can be absorbed before the system re-

structures” [Lance H. Gunderson, 2002]

Engineering

Resilience

Focus on efficiency of the system func-

tion. It is used to the speed of return to

the steady state following a perturbation

[Lance H. Gunderson, 2002]

Figure 5.11: Ecological vs. Engineering Resilience

Figure 5.12: Measuring system resilience: where

resilience is a function of the area under the curve

From an organizational perspective, it is interesting to question which type of resilience is aspired to. High engineer-

ing resilience implies maximizing the efficiency of systems and processes to return and maintain the system at its desired

state relatively easily and rapidly. Ecological resilience implies designing flexible systems and processes that continue

to function in the face of large disturbances, even though this may not maximize efficiency. Increasing the ecological

resilience of an organization would effectively increase the magnitude of consequences the organization could withstand

before suffering irreparable damage.

The point at which a disaster occurs is when a system is pushed from one state of relative stability or equilibrium into

another. The ease with which the system is pushed into this new state is a measure of its vulnerability, while the degree

to which they are able to deal with that change is a measure of their adaptive capacity [Dalziell & McManus, 2004].

The distinctions between vulnerability and adaptive capacity in relation to disaster events are summarized in figure 5.12.

This analysis lead us to define resilience as:

[Resilience] the ability of a system to continue to function to the fullest possible extent in the face of stress to achieve

its purpose, where resilience is a function of both the vulnerability of the system and its adaptive capacity.

35

5.3 System Governance

Governance was introduced in the UoD as the guidance that enables the correct execution of a certain activity. We

oppose to the often approach that the governance should be associated to a mechanistic perspective in the sense that a

governance based on managerial activities - formal planning, risk management and control - is not adequate to deal with

chaos and uncertainty. We argue that enterprise performance does not follow from this mechanistic governance focus

but from a coherent and consistent design, the focus on people and enterprise design is essential to deal with such issues.

In order to stress the relation between the governing system and the system dynamics of the governed or object

system, we draw a model based on [Alberts & Hayes, 2006] (The Command and Control Research Program within the

Office of the Assistant Secretary of Defense) that is presented in figure 5.13. The system real-plan (object system) is

where occur the events and interactions among the system entities that accomplish the governance outputs (guidance).

The system meta-plan (governing system) is where occur the events and interactions among the system entities that

purpose to guide the system real-plan. Lets briefly introduce the essential system processes presented in figure 5.13.

Figure 5.13: Process view of the relation between the governing system and the governed system

Control function evaluates the need of system adjustments and it performs these adjustments if they are within the

guidelines established by the governing system [Alberts & Hayes, 2006]. Control can be performed in many different

ways, but should always be consistent with the approach to governance.

Sensemaking consists of a set of activities in the social and cognitive domains that begins with the perception of

available information and ends prior to taking action(s) (execution) that are meant to create effects in the system design

domains [Alberts & Hayes, 2006]. Sensemaking can raise awareness of the system as a whole by means of constructional

models, in particular ontological models. The actions selection (decision-making processes) is part of the sensemaking

process and depends upon the governing system outputs, particularly guidelines about how interactions and informa-

tion distribution should be done. Understanding sensemaking in enterprise requires an understanding of individual and

collective processes by which tacit knowledge (e.g., culture, expertise, and experience) is combined with real-time infor-

mation to assimilate the enterprise reality and articulate appropriate points about it [Alberts & Hayes, 2006]. Therefore,

OSA is about making sense of sensemaking. Put another way, OSA can be perceived as meta-sensemaking. The gov-

erning system purposes to guide the sensemaking as well as the meta-sensemaking process.

5.3.1 Governance themes

Governance can be exercised at multiple levels and contexts within a system. It has been discussed in literature a wide

set of governance structures with distinct domains with their own disciplines and processes. First, we outline the widely

discussed notions of corporate governance and IT governance. The limitations of these two governance approaches will

36

be outlined and it will be understand why effective corporate and IT governance can only be arranged within the overall

context of enterprise governance. Moreover, the notion of architecture governance is depicted and it is explained why

such notion must be an integral part of the enterprise governance notion and not a subset of IT governance. Each one of

these governance domains may exist at multiple geographic levels (global to local) within the overall enterprise.

Governance Perspective Scope Limitations

Corporate

Governance

Narrow

perspective

Internal control, financial /economic

development focus, risk-oriented, su-

pervision;

Mechanistic view, heavily structurally. Inadequate atten-

tion to the enterprise strategy and design where such top-

ics must be framed and thus, an organismic perspective is

required.

Broad per-

spective

The scope of the narrow perspective

plus the development of an enterprise

strategy and associated enterprise de-

sign;

These subjects transcend the capabilities of the CG

discipline considerably (board and senior management)

and can only be addressed within the overall scope of

enterprise governance (organizational competence)

IT

Governance

Mechanistic

approach

ITG is the responsibility of “the board

of directors and executive manage-

ment” which focus on controlling the

formulation and implementation of

IT strategy and address its alignment

with the business strategy

Formal, control, top-down management driven perspec-

tive which is not adequate to deal with chaos and un-

certainty; Inadequate competence which should integrate

knowledge and skills from other domains and operational

and technical collaborators to deal with the IT alignment

aspects;

Organismic

perspective

ITG is an organizational competence

concerning IT architecture: IT enable-

ment (enabling the enterprise strategy

’bottom-up’) and IT alignment (sup-

porting the current enterprise strategy

’top-down’)

An organismic perspective of IT governance is not enough

to deal with all the enterprise design domains (beyond

IT and its alignment with business) and thus, this per-

spective should be perceived as a subset of the enterprise

governance.

Architecture

Governance

Managerial

perspective

Architecture governance as the

orientation and practice by which

enterprise architectures are controlled

and managed at an enterprise-wide

level. It is about implementing a

system of controls over the creation

and monitoring of all architectural

components and activities.

Inadequate attention to the prescriptive notion of architec-

ture. Governance not focus on the design process but on

controlling and management activities for the enterprise

architecture. Increase of bureaucratization (additional su-

pervision layer) which misleads to treat the symptoms of

the problem and not the cause (strategy, design and orien-

tation alignment)

Normative

perspective

Architecture governance as the com-

petence responsible for defining prin-

ciples and standards

Despite this view on architecture governance be essen-

tial to ensure a coherent and consistent design, other

governance mechanisms must coexist in order to ensure

the correct implementation of the EA (e.g. projects

portfolio governance) and to guide the dynamics of the

enterprise operation by means of rules. Hence, architec-

ture governance can be perceived as a central subset of the

enterprise governance

Table 5.3: Corporate Governance, IT Governance and Architecture Governance perspectives and limitations

37

5.3.1.1 Corporate Governance

Corporate Governance (CG) encompasses an internal and external perspectives which can be retrieved from the notion

provided by governance committees and authors [O’Donovan, 2003, Hoogervorst, 2009, Committee, 2006]. From an

internal perspective, CG concern control and risk management aspects that ensure that the enterprise exercise its respon-

sibility towards the shareholders. The internal control is focused towards financial/economic developments and the risks

associated to it within the enterprise. The CG external perspective is associated to the rules and legislation by which

internal control is effectuated.

These two perspectives are present in the CG definition provided by Gabrielle O’Donovan in [O’Donovan, 2003]

as “an internal system encompassing policies, processes and people, which serves the needs of shareholders and other

stakeholders, by directing and controlling management activities with good business savvy, objectivity, accountability

and integrity”. First, according to this definition CG concerns the interest of all the shareholders and it assures the

enterprise integrity (internal perspective). Second, it is used to refer to the processes, laws or rules by which businesses

are operated, controlled and regulated (external perspective).

These two perspectives of CG aim to overcome the problems raised by the two corporate governance crises in the

19th and 20th centuries. First crisis is associated with the agency problem where management did not acted in the interest

of shareholders. In order to overcome the first crisis, the focus on shareholder value was intensified (internal). However,

the corporate governance became to perform fraudulent activities to polish up the share values, leading to the second

crisis. Therefore, after these crises the corporate governance had to apply supervision mechanisms, external/internal

auditing, internal control over financial reporting, use of principles for accounting and financing in order to assure the

interest of all stakeholders and achieve integrity (external). This led to the compliance focus where corporate governance

debate has centered on legislative policy to deter fraudulent activities and transparency policy to verify the veracity of

auditing, which misleads executives to treat the symptoms of the problem and not the cause.

Therefore, we define CG as

[corporate governance] the internal arrangements for control and risk management that ensure that the enterprise

exercise its responsibility towards the shareholders, as well as the external rules and legislations that ensures the

accountability and integrity of how internal control is effectuated .Moreover, CG may be associated to a narrow or a broad scope. In a narrow perspective there is no attention to the

enterprise strategy and subsequent enterprise design. The Basel Committee approaches CG in a broader way since it

argues that the board should be appropriately involved in approving the bank’s strategy [Committee, 2006]. Further-

more, the Basel Committee advocates the focus of CG towards risk management, and responsibilities and compensation

policies definition and enforcement throughout the organization. However, their CG notion is still a mechanistic view

associated only with board and senior management competence. Enterprise strategy and design subjects transcend the

capabilities of the CG and can only be addressed within the overall scope of enterprise governance (we refer the reader

to [Hoogervorst, 2009]).

5.3.1.2 IT Governance

Information Technology Governance (ITG) deals with IT decisions and highlights their impact within the enterprise.

In particular, such decisions concern the alignment between business and IT ([Henderson & Venkatraman, 1999] de-

38

picted this aspect in a framework presented in figure 5.14). This strategic perspective is reflected in the definition

provided by the IT Governance Institute which defines IT Governance as “(...) the leadership and organizational struc-

tures and processes that ensure that the organization’s IT sustains and extends the organization’s strategies and objec-

tives” [ITGI, 2004]. This broader perspective on IT governance contrasts with other approaches that narrow this notion

to the focus on methodologies, models and framework that can guide IT decisions. Weill and Ross state that IT is

about “specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT”

[Weill & Ross, 2004].

IT Governance is perceived by IBM institute in a broader way as the way in which “leadership accomplishes the

delivery of mission-critical business capability using Information Technology strategy, goals, and objectives” in order to

strategic align goals and objectives of the business and the use of its IT resources [Mueller & Phillipson, 2007]. An im-

portant issue concerned by IBM is that IT Governance “disseminates authority to the various layers in the organizational

structures” within enterprise business, while ensuring prudent and appropriate use of that authority. The IT governance

disciplines and relationships between IT governance, the enterprise Foundation for Execution (enterprise ability to per-

form), the enterprise businesses capabilities (Enterprise Architecture), corporate strategy and EG are presented in figure

5.15 adapted from [Mueller & Phillipson, 2007]. The figure underscores the importance and role of IT governance as

being primarily responsible for the coordination and evolution of EA. However, as we will analyze the domains of EA

transcends the capabilities of IT Governance and thus, EA should be addressed by the enterprise governance competence

where IT Governance competence is perceived as a subset.

Figure 5.14: Strategic Alignment Model Figure 5.15: IT Governance and EA

Regarding how should be constituted the IT governance, the IT Governance Institute refers in its ITG definition to

“the board of directors and executive management” [ITGI, 2004]. This is a mechanistic governance view on ITG. It

is argued in [Hoogervorst, 2009] that this competence (mechanistic/top-down perspective) is not effective to deal with

ITG aspects, and it is advocated an organismic perspective (organizational competence) to exercises guidance over the

IT strategy and IT architecture development. The two different perspectives - mechanistic and organismic - on ITG are

depicted in table 5.3 as well as their limitations.

In this report, we will use the term IT governance to refer to

[IT governance] “the organizational competence that exercises guidance (governance notion) over the IT strategy and

IT architecture development which comprise the design, engineering, implementation and operation of IT systems”

[Hoogervorst, 2009].Since IT challenges are multidisciplinary and complex, it is required methodologies (models, frameworks, principles,

39

good practices) that can seize IT opportunities and guide their design, engineering and implementation (e.g. COBIT,

ITIL, CMM, ISO/IEC 27001). IT governance should be an integrated part of an enterprise-wide governing system, since

the enterprise design domains are beyond IT aspects and their alignment with the enterprise business.

5.3.1.3 EA Governance

Enterprise architecture governance is an emerging and still maturing form of governance. Literature have been approach

this notion in different manners, we outline two different perspectives in literature on architecture governance (within

each perspective other approaches can be distinguished):

• Architecture governance as the regulatory and management scheme for enterprise architecture:

– is the orientation and practice “by which enterprise architectures and other architectures are managed and

controlled” at an enterprise-wide level [Haren, 2005]. It is about “implementing a system of controls over

the creation and monitoring of all architectural components and activities” [Haren, 2005];

• Architecture governance as the competence responsible for the architecture prescriptive approach:

– architecture governance as the main subset of the enterprise governance, whereby the governance compe-

tence is for defining principles and standards [Dietz, 2008, Hoogervorst, 2009, Land et al., 2009];

Figure 5.16 stresses the relations between the enterprise strategy, enterprise architecture (purpose to guide the design

process) and the enterprise operation/execution. The enterprise governance is perceived as the main competence to

bring together all these components and ensure their alignment, and architecture governance as a subset of the enterprise

governance responsible for defining principles and standards to restrict the undesirable design freedom while ensuring

that these normative outputs are continuously aligned with the enterprise strategy.

Figure 5.16: Enterprise Architecture Governance

5.3.1.4 Enterprise Governance

The lack of unity between IT governance and Corporate Governance and the need to ensure success of the implementa-

tion of the enterprise strategy by guiding the enterprise strategy, enterprise architecture and the subsequent development

in a holistic manner lead us to a still recent and evolving notion of Enterprise Governance (EG).

The International Federation of Accountants defines EG as “the set of responsibilities and practices exercised by the

board and executive management with the goal of providing strategic direction, ensuring that objectives are achieved,

40

ascertaining that risks are managed appropriately and verifying that the organization’s resources are used responsibly”

[IFAC]. This definition approaches governance in a management perspective which we discussed above. Furthermore,

IFAC argues that the EG should deal with compliance (corporate governance), performance and responsibilities. And

that strategic and accountability issues are both treated by the EG competence.

Hoogervorst in [Hoogervorst, 2009] also integrates compliance and performance in his EG perspective. However,

his notion of EG differs in many aspects. He argues that enterprise governance does not primarily concern management-

oriented activities such as planning, decision making, risk management, but is about developing a coherent and consistent

design. This focus on design is crucial for the strategic and operational success.

Hoogervorst also argues that the competence responsible for the design guidance should integrate the various enterprise

skills, knowledge and technology (organizational competence), instead of a board and executive management compe-

tence advocated by IFAC. Furthermore, Hoogervorst highlights the need of a formal methodology for “realizing unity

between compliance and performance”. He defines enterprise governance as

[Enterprise Governance] “the organizational competence for continuously exercising guiding authority over enterprise

strategy and architecture development, and the subsequent design, implementation and operation of the enterprise”

[Hoogervorst, 2009].In order to achieve an integrate enterprise design, EG should be less about strict adherence to rules and risks manage-

ment, and more about guidance over the strategy development and subsequent design process. Focus on enterprise

design is essential for the enterprise to achieve the following crucial qualities in the current dynamic environment:

• Adaptability: “ability to respond rapidly to change requirements”

• Flexibility: “ability to adapt rapidly to change requirements”

• Integration: “ability to operate as an unified system”

• Optimization: “ability to continually improve the efficiency of processes”

Figure 5.17: EG competencies Figure 5.18: Relationship between the governance themes

Figure 5.18 presents the relationships between the three different governance perspectives within the enterprise

[Hoogervorst, 2009]. Both IT governance and corporate governance should be an integral part of enterprise governance.

Naturally, enterprise governance and corporate governance are dependent of IT systems and respective data to work

properly. Enterprise governance needs IT governance support in a broader sense, since enterprise development and

subsequent design is supported by information and communication technology. Corporate governance is concerned

with legislation, processes and policies in order to ensure the accountability and integrity of the enterprise (focus on

compliance) and compliance must be addressed in enterprise design. Hence, corporate governance must be an integral

part of enterprise governance.

41

6Governance levels:

governing system and theGSDP

Conscience reigns but it does not govern

– Paul Valery

6.1 Introducing the Governing System in the Generic System Development Process

Developing a system includes the activities that need to be executed in order to bring a new system or change an existing

system [Dietz, 2008]. The governing system will be introduced in the Generic System Development Process (GSDP) by

exploiting its relation with the processes of the system development (design, engineering, reverse engineering, imple-

mentation, and operation). We will briefly review the GDSP as long as the governing system will be evaluated in the

scope of each one of the GSDP processes, for a detailed explanation of the GSDP we refer the reader to [Dietz, 2008].

The GSDP involves two systems (see figure 6.1). (1) The object system (OS) is the system which will be developed,

the problem domain. (2) The using system (US) is the system that will use the object system functionality. For instance,

if we want to develop a decision making system (DMS): the DMS is the object system, while the using system would be

the administration department. Additionally, we introduce the governing system (GS) which governs the activities that

need to be performed in order to develop the OS.

Hence, the governing system is transversal to the whole system development process and it has an important role

guiding processes such as the design and engineering of the object system. In the case of DMS, the governing system

could be a specialized team that would participate in the development of the DMS by ensuring that the DMS would fulfill

the needs of the administration decision processes. Therefore, the governing system can be seen as a set of elements

interacting with the purpose to guide the development of the object system by starting on the using system. This is still

an initial and immature vision of the governing system which will evolve throughout this section.

System Design comprises the two design perspectives approached in the previous chapter: (1) function design and

(2) construction design (see figure 6.1) [Dietz, 2008]. In the GSDP, the function design starts from the construction of

the US and ends with a functional (black-box) model of the OS. This black-box model describes the external behavior

of the OS in terms of the US. The construction design starts with the black-box model and ends with a construction

(white-box) model of the OS.

However, the design freedom of designers is undesirable large and thus, it is required guidance to restrict their

42

freedom. This should be done by means of design principles1 (normative architecture notion) which should be defined

by the governing system. In the GSDP, design principles are split into functional principles which guide the function

design and constructional principles which guide the construction design (see section 2.4 and figure 6.2). Nevertheless,

functional and constructional principles should not be developed in the same fashion by the governing system. The

functional principles are often related to senior managers - individuals with strategic knowledge and vision that should

be able to define the external behavior of the object system (object system function). However, the knowledge to define

how such behavior should be constructed (internal perspective) transcends the competence of these individual, it requires

specialized competence from different sources and areas of the enterprise. Hence, constructional principles should be

defined by an organizational competence that embodies the knowledge and skills of the enterprise employees.

Figure 6.1: The system design process Figure 6.2: The design governance

Furthermore, during the construction design the governing system should define the operational rules that will guide

the enterprise operation (see section 2.7). These rules come in the form of coordination rules and production rules. Note

that design principles and operational rules must be mutually supportive.

The importance of the design governance is to guide the development of the new system from a holistic point of

view and thus, to ensure that (1) the whole system is integrated with the macro-system in which it operates (teleological

perspective) and that (2) the parts of the new system are constructed in an integrated manner (ontological perspective).

Furthermore, the governing system can introduce changes to the object system by changing, removing and/or creating

new design principles. These are pro-active changes that occur from seizing new opportunities of improving the object

system. These changes in the design principles can affect the constructional models at different abstraction levels and

thus, the models affected need to be engineered again.

System Engineering is the activity in which the ontological (highest abstraction level) models are converted into

detailed (lower abstraction levels) models until construct the implementation model (see figure 6.3) [Dietz, 2006]. The

reverse process in which the ontological model is constructed from the implementation model is called reverse engi-

neering. The reverse engineering is important to extract the ontological models of the US when this does not exist.

Recovering the DMS example, before building the DMS supporting an administration department (US), the enterprise

need to know what to support. This means that the US must be described by means of construction models. This is

done by using reverse engineering which in this case means to know, for instance, the information flows associated to

administration department and subsequent decisions processes.

An appropriate form of governance is required to coordinate and trace the (re)engineering and reverse (re)engineering

activities. The governing system at the design level is essential to guide from a holistic point of view the production of

1Note that constructional principles are transversal to the design and engineering processes. Put another way, the creation of design principles

guide the production of a construction model (design) but should also guide the subsequent construction of lower level models (engineering).

43

Figure 6.3: The system engineering process Figure 6.4: The engineering governance

the object system constructional model (ideally the ontological model) by starting on the using system (re)define a set of

design principles. These principles also guide the production of more detailed construction models (i.e. principles also

guide the engineering process) [Hoogervorst, 2009].

At the engineering level, the governing system should specify new (or detailed the already existing) operational rules

for the more detailed models produced. At this level, the governing system should also ensure that the design principles

are preserved from the ontological model until the implementation model. Furthermore, the dynamics of the system

should also be guided at this level by the governing system. We outline two different ways to guide these dynamics.

First, a top-down approach where the rules (operational rules and design principles) in high level constructional models

are analyzed in order to seize opportunities of improvement in the system. These improvements result from proactive

governance and naturally they imply changes in the construction models. Hence, these changes need to be engineered

till the implementation models.

Second, a bottom-up approach where the operational rules at low levels constructional models are controlled in or-

der to detect unexpected changes between what is reality and what is modeled. Note that the governing system is not

responsible for these control activities (only their guidance). However, deviations to operational rules with negative im-

pact in the enterprise functioning should be address by the governing system (reactive governance) and further reversing

engineered till the ontological model. This control exercised at lower levels is essential for systems with an emergence

nature, such as enterprises [Neves & Onori, 2009]. This means that a system should be continuously engineered and

reversing engineered. Governance plays a main role during these processes by guiding the system dynamics in order to

keep up-to-date models that reflect the behavior of real-time systems.

System implementation assigns technological means to the constructional elements in the implementation model

[Dietz, 2008] (see figure 6.3). In case of an implementation model expressed in a programming language, the implemen-

tation is the compilation of that model to a specific platform. Once a system is implemented it can be put into operation.

Figure 6.5 presents the overall view of the GSDP by integrating all the system development processes.

Figure 6.5: Enterprise program and project portfolio governance in the GSDP

44

The GS should not directly participate in the assignment of technological means (human and non-human). As we

discussed before the role of governance is to ensure the correct execution of certain activities and not directly participate

in their execution. One can think that the governance should ensure, for instance, that the control and audit mechanisms

are successfully implemented at this level. It is true that the governing system should ensure the correct execution of

these activities but this guidance is done by means of constructional models (in particular the implementation model)

resulting from design and engineering activities. Otherwise, if the governing system would directly participate in the

technology assignment, the holistic vision of the system and the enterprise design focus could be lost.

However, if we take the implementation process in a broader sense (by not just use this notion to refer to the as-

signment of technological means) to refer to the implementation of projects and programs2 that allow the system to

implement its strategy and subsequent design, the governing system should participate at this level by defining and

guiding initiatives to operationalize the system strategy [Hoogervorst, 2009]. In the enterprise context, we use the term

enterprise program and project portfolio to refer to the central list of all enterprise programs and projects and their associ-

ated data [Hoogervorst, 2009]. The evidence behind this competence is that an integrated design must be operationalized

through a similarly unified, coherent and consistent set of projects and programs. Note that the enterprise governance

should not implement these projects, but define a set of activities that guide the correct execution.

At the operational level is important that the governing system provides a compliance process to ensure that the

operation of the enterprise conforms the defined operational rules. This compliance process should also educate the

enterprise employees for the governance problematic and the importance of their continuous participation (we will

approach this topic in the next stage of the research). Furthermore, at this level the governing system should control the

effectiveness of its rules and thus, should revisit them when necessary.

6.2 Governance levels

A system can be viewed along different dimensions. In this report, we identify two orthogonal sets of governance levels

that approach the governing system from different perspectives and at various abstraction layers. As we previously

analyzed, governance exercised over the system development can be divided in the design level, engineering level,

implementation (used in a broader sense) and operational level. Furthermore, we additionally define the strategic level

where the EG deviates purpose, mission and strategic rules to guide the enterprise behavior. The design of the enterprise

should be aligned with these rules from the strategic level. The reverse is not true.

We will label this first set of levels of governance ’intra-system governance levels’, since they comprise the governance

activities required to successfully develop a system and deal with its changes (summarized in table 10.1). The first set

of governance levels purposes to master the intra-system complexity by approaching the system in four levels.

The second set of governance levels is related to inter-system aspects and purposes to master such complexity by

dividing a system in subsystems (see table 6.2) and applying the intra-system levels of governance to each sub-system.

This is a recursive process that should be applied until an adequate level of complexity is found. According to the

Evolvable Assembly Systems Paradigm (a system that can fully adapt to unforeseen changes in environment conditions),

the evolution must be enforced bottom up, since as lower is the complexity (in terms of local approaches instead of

holistic approaches) as easy is to evolve and change [Neves & Onori, 2009].

2Program is used as a cluster of projects that must be coordinated in order to contribute to a higher-order strategic goal

45

System level Governance level ResponsibilitiesStrategic Level Strategy Governance (re)Defining purpose and mission rules; guide the enterprise orientation, perspective and

position;

Design LevelFunction Design

Governance

Defining function design principles and continuously improving/changing system external

behavior

Construction Design

Governance

Defining construction design principles and continuously improving system efficiency (in-

ternal behavior) by revisiting these principles; defining operational rules

Engineering

Level

Engineering

Governance

Defining operational rules (coordination and production rules); seizing improvement oppor-

tunities in high level models (proactive governance)

Reverse Engineering

Governance

Abstracting operational rules; ensuring that changes at low level models preserve architec-

ture principles and operational rules (reactive governance)

Implementation

Level

Program and project

portfolio Governance

Defining and guiding a coherent and consistent set of projects and programs to implement

the system’s strategy and design

Operational Level Operation Governance Providing compliance process to ensure that the operation of the enterprise conforms the

operational rules

Table 6.1: intra-system governance levels

Scope Governance level ResponsibilitiesEnvironment Global Governance External regulation of an enterprise

Enterprise system Enterprise Governance Guide the enterprise system development and subsequent changes from a holistic point

of view

Enterprise subsystem Local Governance Guide the enterprise sub-system development and subsequent changes

Table 6.2: Inter-system governance levels for the enterprise system

The GS should rather improve the interactions among its components instead of improving the internal behavior of

each component. The internal behavior of each component should be governed by local governance. Consequently,

this local governance would mainly concern the alignment within the component. In this fashion, the critical factors

regarding component interactions are concerned and thus, the ability to the system operate as an organic whole can be

maximized as well as the system agility and adaptability. Note that the role of GS goes beyond system alignment, we have

been arguing that governance rules should guide other aspects such as information distribution, processes optimization,

resources allocations, decision-making among others. The following figure presents the conceptual models associated

with the different levels of governance.

Figure 6.6: Governance levels

46

IIISolution Design

7Solution Basis

I keep the subject constantly before me

and wait till the first dawnings open

little by little into the full light

– Isaac Newton

In the previous chapters, we conducted a research in three different fields of knowledge - ontological models,

governance themes and system dynamics - in order to analyze the role of the enterprise governance in guiding the

different semantic planes of an enterprise over time. In this chapter we consolidate the theory analyzed previously to-

wards the thesis hypothesis in order to understand how the enterprise ontological models defined with DEMO can help

the enterprise governance in guiding the enterprise.

7.1 Enterprise System as a set of constraints

Following the paradigm shift of the enterprise bureaucratization process from management, based on self-interest, to

one based on rules and procedures that aim to continuously guide the enterprise function [Fox et al., 1997], we purpose

that an enterprise may be perceived by its governing system as a set of constraints on the activities performed by the

organization-agents.

In the state-of-the-art regarding modeling the enterprise ontology we inferred that an organization (construction

perspective of an enterprise) consists of a set of acts performed by a set of social individuals behaving according to

assigned authority and corresponding responsibility against a common background of social norms and values. The

atoms of the organization are the P-facts and C-acts and they always occur in universal patterns - transactions (the

molecules). The fibers constitute a “tree-structure of connected transactions, starting with the transaction through which

a service is delivered to the environment of the organization, or with an internal self-activation” [Dietz, 2006]. Each

individual plays one or more roles in the organization and he/she is allocated with proper authority at the level that the

role can execute its acts. The reality capture by the enterprise construction models produced in the design process can be

translated into the enterprise operational plane by means of a set of constraints abstracted from the construction models

that will constrain the P-World and C-World of these individuals in their daily operation. However, these models must

properly and mutually co-evolve with changes in the enterprise operation (and vice-versa) and thus, the notion of time

remains essential.

The contribution of our research is to understand how enterprise ontological models can support the operation of

the enterprise governance in guiding the enterprise as an organic whole over time. Literature in the knowledge field of

governance and ontology modeling have not paid adequate attention to the time axis, in the sense that enterprise models

47

do not co-evolve mutually with the enterprise dynamics, and governance approaches have not been focus on how to deal

with undesirable changes and system resilience. An enterprise is never a static entity. Some sectors will be more stable

than others, but nevertheless, an organization that remains exactly the same over time will eventually erode its potential

to achieve its purpose.

In the state of the art we define the ontology of time to help representing the functioning of the organization. An

important component of representing the enterprise function is the ability to temporally project, that is, to determine the

possible set of future states where the enterprise can be in an equilibrium state (a set of norms). This has interesting

implications for an organization hit by disaster. Since, it is possible to detect when the enterprise is in a state of dys-

function. Recapturing the notion of system resilience approached in the state-of-the-art, it implies that the organization

should not aim to recover and rebuild itself to be the same as it was before disaster struck, but should recover to a new

equilibrium, where it will regain synergy with its external environment. Put another way, when the enterprise is in a state

of dysfunction, it may need to (re)design and (re)engineering certain artifacts to recover to a new equilibrium state.

Lets analyze how DEMO ontological models can support the enterprise governance in addressing these issues and

the main four requirements identified in the first chapter.

7.2 Governance and DEMO

The assignment of competence, authority and responsibility to each actor role and their subsequent operationalization

constitutes one of the most challenging aspects in guiding a social system where its subjects enter and comply with

commitments towards each other. We identified these three notions as the main threads connecting the governance of the

enterprise dynamics with DEMO. Each one of these notions must have associated an explicit set of governance outputs.

Within these outputs we can outline two main groups. (1) Outputs that will restrict the undesirable detailed design

freedom - design principles . These outputs propose to guide the engineering process (detailed design) regarding the C

and P world of each actor (how such acts are supported at the infological, datalogical and technological levels). They

can be perceived as a complementary principles set to the principles devised from the prescriptive enterprise architecture

notion (the reference context used to guide the principles definition differs in the two approaches). (2) Outputs that will

guide the enterprise operation (production and coordination rules). These outputs propose to ensure that the enterprise

operation is aligned with the enterprise design by ensuring that each actor deals according to what is defined at the design

level, and deals with on-going undesirable and expected changes that may cause dysfunction.

In this way organizational changes (the actors filling certain roles are continuously changing), information security

(the authority to access to information resources that is given to each actor), authorization and delegation processes (who

can transfer or delegate authority), among several others aspects can be addressed by the enterprise governance.

7.2.1 Role

The organization notion (construction perspective of an enterprise) is in its essence considered to be about the interaction

of the actor roles. An actor is a subject fulfilling an actor role and it performs two kinds of acts: production acts and

coordination acts. In the ψ-theory, an actor role is perceived as the essential unit of a competence, responsibility and

authority and responsibility.

48

DEMO abstracts from the subjects in order to concentrate on the different actor roles they fulfill. The actor roles

and their interactions are defined in DEMO interaction model which shows the ontological construction or composition

of an enterprise. Moreover, DEMO not only identifies internal actor roles, but also environmental actor roles which are

external to the enterprise system but that directly interact with the actor of the enterprise system.

Within the enterprise, there is the possibility of grouping different actor roles (levels of abstraction) i.e. the gener-

alization or specialization of the actor roles. In this manner we can dominate complexity and analyze the interaction

between the actor roles at different abstraction levels. An unit of authority, competence and responsibility is denoted by

elementary actor role (otherwise, it is denoted a composite actor role). Different from the notion of specialization and

generalization, there is the notion of hierarchy of roles. This happens when an actor role is a subordinate of a former.

For example, recruiting-officer is a subordinate of human-resource-manager, which in turn is a subordinate of president.

Each actor role is associated with:

• Adequate authority needed for the role to perform its P and C acts. Authorities include the right of using resource,

the right to perform activities, and the right to execute status changing actions;

• One or more resources (e.g. information banks) may be allocated to a role for disposition under its authority;

• The competence (skills, knowledge and experience) required for the realization of the job functions;

• The responsibility of an actor to to be committed to the C-world;

• A set of principles that purpose to constraint the engineering process (process of detailing conceptual models till

obtain the implementation models which presupposes how the roles activities will be supported and controlled in

the different design domains)

• A set of rules that purpose to constraint (guide) the actors activities in dealing with their agenda. These constraints

are unique to the organization role;

The notion of actor roles is essential for governing the enterprise since it allows to master the enterprise complexity

(governing individual actors would be ineffective and inefficient), deal with the enterprise dynamics (the actors are

continuously changing but the roles do not change so often), among a plenty of other aspects from allowing information

access management to security issues as we will see throughout this chapter.

The actor roles are directly retrieved from DEMO construction models. The interaction model provides in a concise

way this information, the Interstriction model adds all passive mutual influences between actor roles. To usefully reason

about competence, authority and responsibility notions associate to each actor role, the EG must have some way of

modeling and address these notions.

7.2.2 Competence

The first step in assigning a person to an actor role is to evaluate if the person has the adequate competence to exercise its

job. Put another way, one must have the ability to properly execute its transactions types (mainly manifested in p-acts)

[Dietz, 2008]. For instance, a justice official Y from a section X of DIAP must possess the skills and knowledge to

prepare the survey and make the cost calculations associated to it.

Organizations must understand their core competency needs - the skills, knowledge, behaviors, and abilities that are

necessary for people in key roles to deliver business results. According to [Boulter et al., 2010], there are six stages

49

involved in defining a competency model for a given job role: (1) it must be defined criteria for superior performance

of the job role; (2) for data collection it must be choose a sample of people to be assigned to the role; (3) it must be

collected sample data about the behaviors that contribute to success; (4) it must be developed a set of hypotheses about

the competencies of exceptional performers and analyzed how they produce successful results; (5) the results of data

collection and analysis must be validated;(6) the competency models must be applied in HR activities. These stages are

useful for the EG to define a set of competency models for the enterprise by starting on DEMO models.

Figure 7.1: Emotional competence model

For each actor role retrieved from the DEMO construction model, the EG should define a set of main competence

domains based on the bank of production acts and facts associated to each actor role. Each competence domain defined

should be associated with an enforcement level and should be controlled and evaluated according to a define set of

competence stages (e.g. unconsciousness/consciousness incompetence/competence). A generic set of competence sub-

domains is illustrated in figure for the emotion competence domain 7.1.

Based on the competence domains identified, the EG should devise a set of rules which should guide the assignment

process and the on-going suitability of the actors’ competences. These rules will guide the operation of HR and managers

in recruiting and assigning individuals to an actor role. Additionally, a set of production rules should be defined to guide

each actor in dealing timely and adequately regarding its production-acts.

Figure 7.2: Competence governance

Moreover, the EG should define a set of competence (p-acts) principles. A principle is a predefined action comprising

a statement, a rationale, its implications and the key actions that should be performed to fulfill the principle. These

principles will restrict the detailed design freedom (e.g. how the enterprise must be engineered to support the actors’

50

production acts), and they are a subset of the design principles devised from each enterprise design domain.

The creation of competence principles presupposes that the enterprise ontological models exist. The interaction

model representing the actors transactions and the transaction result table should be the main input for governing system

to produce the following outputs (see also figure 7.2):

for each Ri in R do:

competence_o f (Ri,CD), engineering_o f (Ri,CP), assignmentRule_o f (Ri,CR), prodRules_o f (Ri, Pi, PR)

where R ∈ {Ri : Ri ∈ InternalActorRoles} ∧CD ⊂ CompetenceDomains ∧CR ⊂ CompetenceRules ∧CP ⊂

CompetencePrinciples ∧ Pi ∈ ProductionActs(Ri) ∧ PR ⊂ ProductionRules

7.2.3 Authority

Authority is widely perceived as the right to exercise power, or the legitimate or socially approved use of power. For

one to be assigned to an enterprise actor role, it is necessary to be accepted by a corporate body. According to DEMO,

authority is “the condition of being allowed to act”. Authority can be assigned to a subject through authorization or

delegation.

The actor that performs the promise in a transaction is recognized to be the authorized person for executing the

transaction. Therefore, the actor authorized to promise and execute a transaction has the full-responsibility for the

transaction [Dietz, 2006]. If the person that has the authority to do some act needs to “transfer that authority” to another

actor, we are in a case of delegation. Put another way, delegation is the process of transferring authority from an actor

to another. And it means that the authorized actor will transfer the authority but not the responsibility [Dietz, 2006].

Similarly, in [Dewsbury & Dobson, 2007] is argued that when an obligation is transferred, the agent that delegates

becomes the responsibility principal, whereas the obligation receiver becomes the responsibility holder.

Figure 7.3: Authority governance

The EG should define for each actor role a set of authority rules expressing what an actor is authorized and not

authorized to do (see figure 7.3). While principles purpose is to guide the design process (the way enterprise elements

are arranged), rules are actionable directive that guide the enterprise operation (activities execution that bring forward

the enterprise products and services). Authority rules need to respond from the perspective of access control (who is

51

authorized to use what resources and in what context) and information security (information is only understood by those

who have legitimacy to access it). Authority rules should be clear regarding which actors can transfer their authorities to

which other actors and in which conditions (authorization and delegation processes).

The EG can create authority rules for each role based on the Interstriction DEMO models (ISM), the Banks Content

Table and the Transaction Pattern Diagram. The abstraction in the ISM from the particular way in which the governance

competence gets an appropriate insight to the relationship between (the fulfiller of) an actor role and the needed informa-

tion. Furthermore, authority rules should be enforced and operationalized. For this purpose there should be implemented

access control services that will ensure that an informational entity or practice of a service can only be accessed by peo-

ple or applications with proven legitimacy. The following outputs regarding the authority notion should be produced by

the EG:

for each Ri in R do: in f oAcessRule_o f (Ri, AR), delegationRule_o f (Ri,R j,Tx), authorizationRule_o f (Ri,R j,Tx)

where R ∈ {Ri : Ri ∈ InternalActorRoles} ∧ Ri is the actor who will delegate or transfer the authority while R j is the

person who receives the authority ∧Tx ∈ Transactions ∧ AR ⊂ AuthorityRules ∧ AP ⊂ AuthorityPrinciples;

7.2.4 Responsibility

Every actor must be committed to their c-acts and be responsible for their results (c-facts). Responsibility outputs must

avoid a chance that the responsible person for certain acts does not take on his or her responsibility and concludes the

case by blaming other persons or resources. The EG should ensure that the actors are aware of their c-acts that are

expressed in DEMO’s process model and that they act according to the defined action rules. The transaction pattern

diagram also reveals the responsibility areas which encompass all acts that the indicated actor role is allowed to perform.

The transaction pattern diagram also reveals the responsibility areas which encompass all acts that the indicated actor

role is allowed to perform. A complementary approach of responsibility is provided in [Dewsbury & Dobson, 2007]

where responsibility is perceived as the “relationship between two agents regarding a specific state of affairs” which is

associated to a list of obligations held by the responsibility holder (indicating how the responsibility can be fulfilled).

This notion is complementary to the DEMO definition and it goes further on the purposing method to model the casual

responsibilities (we refer the reader to [Dewsbury & Dobson, 2007]).

In [Dewsbury & Dobson, 2007] is also distinguished casual responsibility, “the obligation to ensure that some state

of affairs comes about or is/is not maintained”, and consequential responsibility “the obligation to take the blame if some

state of affairs does not come about or is/is not maintained”. The argumentation is based on the distinction between social

individuals and machines. Whereas the latter can be casually responsible for assuring that some state is conserved, it

is the human that is consequentially responsible if the respective machine fails to fulfill its task. The authors consider

that these concepts will help system designers in identifying system vulnerabilities and provide a basis for supporting

recovery from failure.

From each DEMO transaction results a fact. It is important to clarify who is responsible and who owns the produced

fact. This issue of responsibility and ownership of data is made fully transparent by the CM. In a transaction there are

always two actors involved, the initiator and the executor. One may choose either of them as the owner of the fact (which

shows that the notion of ownership is not as clear as one would think first). The executor is the one who has brought

about the fact, and, thus, the one who can be held responsible for having executed the transaction in the correct way. The

52

initiator on the other hand has requested for the production of the fact, and, thus, is the first candidate for legal owner of

the fact, particularly if he or she has paid for it.

Figure 7.4: Responsibility governance

We purpose to bring together the definition of pre and post-conditions in [Dobson, 2005] and DEMO’s action rules

in order to allow the EG to ensure that each actor is aware and is committed of their C-acts (see figure 7.4). Moreover, it

is purposed also that the EG defines a set of external exceptions in order to deal with undesirable changes and allow the

enterprise to maintain its (or recover to a new) equilibrium state (addressing resilience) by defining the actors respon-

sible to address the expected exception when it occurs. Another important aspect to increase the enterprise resilience

and avoid propagating dysfunction is to implement control mechanisms in order to ensure that all the actors act conform

the defined action rules. Deviations that can have a negative impact in the enterprise functioning must be immedi-

ately communicated to the EG (mechanism alert), who must properly address the deviation impact from a holistic point

of view and take corrective guidance actions. Therefore, the enterprise governance should produce the following outputs:

for each Ri in R do:

coordRules_o f (Ri,Ci,CR), preCond_o f (ARi,Ri, PreC), posCond_o f (ARi,Ri, PosC), exception_o f (Ri, Ex,R j),

where R = {Ri : Ri ∈ InternalActorRoles} ∧Ci ∈ CoordinationActs(Ri) ∧ ARi ∈ ActionRules ∧CR ⊂

CoordinationRules ∧ ActionRules = {x : x ∈ CoordinationRules ∨ x ∈ ProductionRules} ∧ PreC ⊂

PreConditions ∧ PosC ⊂ PostConditions ∧ Ex = {Exi : Exi ∈ Exceptions} ∧ R j = Actor role responsible for the

exception.

7.3 An high-level framework

The conceptual model that relates the EG with the ontological models and the enterprise architecture is outlined in figure

7.5. The EG is represented as a cloud since in literature is still lacking a well established set of construction models for

an organismic governance perspective. This topic will be addressed in the advanced topics, since this analysis just make

sense after a well strong foundation on what should be the operation of governance which is the main purpose of our

thesis - to provide a method to guide the EG in guiding the enterprise dynamics by means of the enterprise ontological

models and the notion of enterprise architecture. In the advanced topics by starting on the artifact provided by our thesis

53

we will reveal the production acts and start to analyze a possible set of construction acts associated to the EG.

Figure 7.5: Stressing the relation between Enterprise Governance, Ontological models and Architecture

Enterprises are artifacts. They are systems that are, and have to be, designed and engineered, like any other artifact.

The governance can promote and guide the design of the enterprise ontology (often the responsibility of enterprise

engineers). This ontology contains the essence of the organization that is going to realize the enterprise business. With

these models the governance see with a single glance the interface transaction types, so they know which kinds of parties

they have to explore as the enterprise customers and suppliers, and they can start to think of how to guide and successful

establish collaborations with them. The governance also see with a single glance what the internal transactional structure

is, what responsibilities are required, what competencies the enterprise need to hire and what resources each actor is

authorized to access it. Then, the management team and other staff can realize and implement the new organization

effectively and efficiently based on the governance outputs and under a set of projects and programs established by the

enterprise governance.

The EG uses the ontological models to master in a holistic manner the enterprise complexity and devise a set of

outputs that will guide the enterprise design as well as the enterprise execution plan (operation). Governance outputs

can be divided in (1) principles devised from all the enterprise design domains (traceable with the enterprise areas of

concern) that will restrict the design process (EA notion), and (2) outputs retrieved from DEMO models based on the

notions of competence, authority and responsibility, which will guide the detailed design and the enterprise operation.

The purpose of principles is to deal with the article main concern (the lack of integration among the enterprise

elements at design level), while rules will ensure that the enterprise operation conforms the enterprise design. The

DEMO ontological models and other ’lower’ construction models are modeled structuring and assigning with meaning

contexts and/or actions (sensemaking). These aspects are preformed in the controlling plane responsible to captured the

on-going enterprise operation.

54

8Bringing EG to DEMO

The judgements of particular times, places and people depend on subjective standpoints

and therefore are not the same thing as objective truths in themselves

– Cleary

In the previous section, Solution Basis, we analyzed how the enterprise ontological models defined with DEMO

can support the operation of the EG in guiding the enterprise development process and its subsequent dynamics. The

results of this research were consolidated in a high-level framework which outlines the role of the enterprise governance

regarding the prescriptive notion of architecture and the responsibility, competence and authority notions. To analyze

how the EG propose to guide the system development process and its subsequent changes researched previously, we will

apply the DEMO method to the EG itself. In this manner, in this section we model the operation/behavioral perspective

researched in the previous section and we complement it with a construction perspective.

8.1 Towards an EG ontological model

The Enterprise Governance is an artifact. It is a system that is, and has to be, designed and engineered, like any other

artifact. This insight has important consequences. Through the distinction between the function of the EG (what it is

expected to do) and its construction (internal behavior), the way of thinking used in this research to approach the EG

becomes feasible and logical. In this context, we recursively used the generic system development process (GDSP) to

integrate in one single approach these two perspectives. This approach aims to guide the development of the EG and it is

depicted in Appendix 2. In this section the focus is on the construction perspective of the EG by approaching its internal

behavior at the ontological level with DEMO.

Let us then start describing succinctly what we understand as the internal behavior of the EG by recapturing what

was researched in the state-of-the-art. We outlined that the governance must be approached as a multi-level structure,

we identified five essential levels regarding the enterprise development process and its continuously transformation

(from strategic level to the operational level - we refer the reader to section 7). The internal operation of each EG

level have to be specified in terms of the associated acts and respective facts for both the P- and C-worlds. The first

interface transaction type (T01) that can be identified from our research is ’strategy guidance’. We can already identify

the presence of a category ’STRATEGY’. The initiator and the executor of T01 is the part of the EG competence

responsible for govern the strategy in which senior managers and executive board should participate actively (teleological

perspective). We outline three main tasks underlying the strategy guidance act (sub-production acts): (1) governance

over the enterprise vision and mission, (2) guiding of the enterprise orientation, perspective and positioning and (3)

definition of the main areas of concern. The subsequent facts are respectively the enterprise mission and vision, strategic

55

guidelines1, and the enterprise areas of concern. The transaction T02 ’collecting external information’ regards the

continuous act of analyzing the market to obtain key information (subsequent fact) to guide the enterprise strategy.

We identify the third interface transaction type (T03), called ’Strategy and Design alignment’ with the result type

’the strategy S and design D had been aligned’. The ’DESIGN’ category can also be outlined. The initiator role of

T03 is the Strategy Governor and the executor of T03 is the integrate whole of knowledge constituted by architects,

engineers, operational and technical users of the enterprise. We will cal the executor role the Enterprise Architect -

CA05. This role is responsible for executing periodically the ’architecture development’ act comprising the definition

of principles and standards to guide the enterprise design (transaction T04). However, the initiation of the transaction

T04 is dependent on the investment approval, which is executed by the composite external actor ’Investment Approver

CA02’. For the development of the enterprise architecture, the CA05 needs to restrict the design freedom associate to

the set of functional and construction requirements associated to the enterprise design domains. These requirements are

provided by the enterprise business role (CA03) which is the executor of T05 - requirements development. Moreover, it

must be defined a set of internal decision-making processes in order to approve the normative design outputs produced

by the Enterprise Architect. The decision making is represented by the actor role ’Decision Maker’.

From our research on system development we identified the importance of producing the system ontological model

(ontological design) to approach in a holistic manner the enterprise, and the process of detailing these ontological models

(engineering or detailed design) to approach the infologic and datalogic levels of the enterprise. Hence, the transactions

’Enterprise OM production’ (T08) and ’(re)Engineering’ (T09) can be outlined, as well as the category ’ENGINEER-

ING’. There should be an Ontological Designer role (A02) to execute T08 and an Engineer role (A03) to execute T09

both guided by the facts (principles and standards) that resulted from transaction T06. Nevertheless, the construction

models resulting from these transactions need to be approved by the enterprise architect. When there are changes at the

construction models that cause deviations between these models and the enterprise architecture (T06 fact), there must

be initiated an ’Exception Handling’ transaction. CA05 is the role responsible for execute this transaction and thus,

responsible to handle the exception and to apply the appropriate corrective actions.

Then, there should be an organizational role that govern the implementation of the facts (detailed construction mod-

els) that result from the engineering transaction. Hence, we can identify the category ’IMPLEMENTATION’ and the

transaction type ’Govern Implementation’ (T12). Recapturing what we researched, this transaction should be executed

by a role that manages the enterprise project portfolio (A04) to guide the implementation process. The facts result from

this transaction should be validated and approved by the Decision-Maker role. Finally, there should be a role that, under

the projects defined by the role A04, assigns technological means to the elements identified in the construction model

facts resulting from the engineering acts.

An important notion taken from the state-of-the-art was the importance of rules to deal with the enterprise dynamics

and guide the enterprise actors in dealing timely and adequately with their agenda (at the operational level). If the

enterprise is in a state of expected dysfunction (deviation from a certain norm), rules may be already defined and can be

applied to help the enterprise to recover to a new equilibrium state. Hence, regarding the governance of the enterprise

dynamics we identified three essential roles: ’Rules Developer’, ’Observer’ and ’Evaluator’. A main finding of our

research is the use of the ontological models (in particular the notions of role, competence, authority and responsibility)

1Note that principles are associated to the notion of the EA at the design level, and rules are associated to the Enterprise Operation at the execution

level, we use the term guideline to differentiate and avoid fuzziness between these concepts.

56

to devise a set of rules (authority, assignment, production and coordination rules). Hence, the ’Rules production’ act

(T15) is initiated by the role ’Ontological Designer’, it is executed by the ’Rule developer’ role (A05), and it results in

’Rules data’ fact. Similarly, as we analyzed before rules must be internally approved by the ’Decision-maker’ role.

For the enterprise to determine if it is in a state of equilibrium, there should be specified a set of enterprise norms.

When one of these norms is violated, then the enterprise may be in a state of dysfunction. The ’Rule developer’ role

is also responsible for defining such norms. Each time a norm is created or changed, it is initiated a new transaction

called ’Operational control’ (T17). Then, there must exist an ’Observer’ (A06) which is responsible for executing this

transaction. Its result is a fact that expresses if the enterprise is in a state of equilibrium or dysfunction. In order to

produce such fact, (1) the ’Observer’ executes periodically an observation act and produces an observation fact, and (2)

the ’Evaluator’ role (A07) evaluates this observed fact comparing it with the associated norm fact and then determines

if the enterprise is in a state of function or dysfunction.

Therefore, there must exist an exception list and subsequent set of ’rectification rules’ that must be applied in case

of expected dysfunction. And also casual indicators (pre and post conditions) that can guide the process of applying

action rules. When the post-conditions or previously defined norms were not met the enterprise faces an exception

and should apply the respective rectification rules. If the exception still persists, no rectify rules exist to eliminate the

dysfunction or the set of rectification rules that propose to deal with dysfunction were not sufficient to eliminate it, we

are in the presence of an unknown exception. The ’Rule developer’ will be responsible for initiate a redesign transaction

that will be executed by the ’Enterprise architect’ role which will handled the exception through the (re)design of

certain organizational artifacts and be responsible for initiating a set of subsequent transactions (from (re)engineering

and (re)implement certain artifact to (re)create new rules).

All the transactions identified are initiated and executed periodically. Transformation in the enterprise state can have

origin from a top-down perspective as well as bottom-up perspective. From a top-down perspective, the enterprise strat-

egy is in continuous transformation and every time key aspects in the enterprise strategy are reformulated, the enterprise

itself may need to be (re)designed and (re)engineered to enable the implementation of such strategy. Additionally, con-

tinuous improvements in the enterprise design will imply also a top-down (re)engineering of the enterprise. From a

bottom-up perspective, observation facts and deviation to the enterprise norms may imply a (re)design of the enterprise

and the subsequent activities of (re)engineering and implement the new construction models. This control exercised at

lower levels is essential for systems with an emergence nature, such as enterprises [Neves & Onori, 2009].

Figure 8.1 presents the interstriction model of the Enterprise Governance (construction perspective). The models

depicts the EG roles and subsequent transactions. The elementary internal roles are colored in white, the composite

internal roles are colored in blue, and the external roles are colored in green. In this model we also depicted the

Production Banks (CPB) - which represent a set of P-facts - and the information links between each PB and each Actor.

The transaction table which specifies the results expected for each transaction identified can be consulted in table 8.1.

Each one of the EG actor roles identified can be fulfilled with a set of competences or even committee depending

on the size and business of the enterprise. As the nature of the task differs, so does the nature of the resources involved

in the EG. In particular, for the decision-maker role should be defined an executive committee. This committee should

comprise the authority elements, the decision-making processes and procedures that should be carefully defined to

oversee the designing, engineering, implementation and operation governance processes. This committee should be

composed by enterprise department leaders, chief information officer, and other key representatives who represent all

57

involved disciplines and entities in the enterprise universe.

Figure 8.1: The governance of the enterprise - Interstriction Model

Transaction Type Result TypeT01 Strategy Governance R01 governance normative outputs for Strategy STRAT has been produced

T02 External information collection R02 market information INFO has been collected

T03 Strategy and Design alignment R03 design DSG has been aligned with strategy S

T04 Investment Approval R04 the investment for developing architecture EA has been approved

T05 Requirements Development R05 the functional and construction requirements were defined

T06 Architecture Development R06 principles PRINC and standards STD has been produced for requirements REQ

T07 Architecture approval R07 Architecture EA has been approved

T08 Enterprise OM production R08 the enterprise ontological models OM have been produced

T09 (re)Engineeering R09 the enterprise construction models CM have been produced

T10 Design Approval R10 the construction models CM have been approved

T11 Exception Handling R11 the corrective actions CA to handle the exception EX have been applied

T12 Governance implementation R12 a set of projects PROJ and programs PROG have been defined

T13 Projects approval R13 projects PROJ and programs PROG have been approved

T14 Implementation R14 construction models CM have been implemented under projects Proj and programs Prog

T15 Rules production R15 rules RULE have been produced

T16 Rules approval R16 rules RULE have been approved

T17 Operational control R17 the enterprise is in a state S of function/dysfunction

T18 Observation R18 observation act OBS has been done

T19 Evaluation R19 evaluation act EVAL has been done

T20 (re)Design R20 redesign of Design DSG has been done

Table 8.1: Transaction Result Table for the EG interstriction model

58

9Solution Derivation

Simplicity before understanding is simplistic;

simplicity after understanding is simple

– Edward De Bono

In the previous sections we analyzed how the EG can guide the enterprise dynamics by means of the competence, au-

thority and responsibility notions retrieved from DEMO models, and how this governance structure can be approached at

the ontological level. This analysis resulted in (1) a set of conceptual models to help the EG in producing normative out-

puts by retrieving specific information from DEMO models, (2) a high-level framework where the concepts approached

in our thesis were integrated and their relations were stressed, and (3) an ontological model of the governance over the

continuous process of transforming an enterprise over time. In this section, we start from the models and formalisms

that result from previous sections in order to develop the main design artifact of our thesis - a reference method that

can effectively help in practice the enterprise governance in guiding the enterprise by means of the ontological models

defined with DEMO.

Figure 9.1: Theorems of the research conducted that serve as the basis for the development of the method

9.1 Towards a reference method for governing the enterprise dynamics with DEMO

Based on the previous sections, we developed a reference method to govern the enterprise dynamics by using DEMO

models. The method was first inferred based on a set of theorems that result from the research conducted (summarized

59

in figure 9.1). And then, the method was cyclical refined with the practical case study used to validate the method. This

method comprises a set of stages that will be illustrated with scenarios retrieved from the library case. The Library case

study is a standard example to explain how DEMO works (the complete excerpt of the case together with the DEMO

diagrams necessary for this study can be consulted on [Dietz, 2006]). The case envisions how a university’s library

functions and operates.

First note regarding our method is that the governance of the enterprise strategy was left out from our method since

the definition and guidance over the enterprise strategy precedes the ontological design and thus, it is not directly con-

cerned within our thesis hypothesis which is to analyze how to govern the enterprise by means of the ontological models.

Put another way, our research focus on how to implement the enterprise strategy and not on how to formulate it. How-

ever, we still concern in our method the alignment of the design with the enterprise strategy (the reverse is not true).

Briefly, the enterprise governance should govern the enterprise strategy by defining normative outputs for the enterprise

mission and purpose, addressing the enterprise perspective and positioning, and identifying the areas of concern.

1. define the enterprise ontological models with DEMO

Enterprises do not often have ontological models that represent their essence in a holistic manner, the first step is to

abstract these models from the enterprise reality which can be done by reverse engineering when the enterprise possess

detailed models of the current reality. Otherwise, the implementation models of the enterprise should be abstracted from

sensemaking activities and then reverse engineered (for a detailed insight on how to reverse engineered from CRISP and

other models we refer the reader to [Dietz, 2008]). In case of developing a new enterprise the production of the enterprise

ontological models (ontological design) is essential and should be defined in line with the enterprise strategy preceding

the enterprise engineering. Recapturing the systemic theories, this process should be constituted by a function phase

which precedes a construction phase. The governance has the responsibility to promote and guide the definition of such

models by identifying the enterprise actor roles and the subsequent production and coordination acts/facts, specifying

the lawful sequences of events in the P-world and the C-world, among other aspects.

Figure 9.2: Ontological models can be obtained by reverse

engineering the implementation models

Figure 9.3: Exemplification of a DEMO model for the library case -

interstriction model

2. define the enterprise architecture

According to what we analyzed in the thesis context and the state-of-the-art of governance themes, a prescriptive notion

of enterprise architecture is essential to govern the design (in particular the detailed design or engineering). It consists

60

in defining a set of functional and construction principles using the design domains as a reference context and tracing

the principles with the enterprise areas of concern in order to align enterprise strategy and enterprise design. In order to

define the EA within DEMO context we captured the architecturing process in figure 9.4. Moreover, as we analyzed in

the UoD the organization design domain implicit in the three upper layers should also be added to the three architectures

defined in order to approach how the enterprise is organized to behavior. Since the definition of EA has been analyzed

previously in literature (and successfully validated in practice), we rather focus on the following steps of our method

which are novel in this knowledge of field and they purpose to answer directly to the thesis hypothesis (i.e. to know how

enterprise ontological models can help to guide the different enterprise semantic planes).

Figure 9.4: Definition of the enterprise architecture to guide the enterprise detailed design

Area of Con-

cern

Main Design Do-

main

Design Principles

Business Products and services must allow personalization by customers

Customer sat-

isfaction

Organization Customer administration must be locally present, under unified, central governance

Information Complete and up-to-date student information must be available at all student contact points

FlexibilityOrganization Process flow control logic must be separated from process execution logic

Organization Employee decision making must take place at the lowest possible level

Table 9.1: Examples of architecture principles

3. identify the competence and responsibility principles for each actor role

Competence principles purpose to restrict the detailed design freedom regarding the actors’ production acts, while re-

sponsibility principles purpose to restrict the detailed design freedom regarding the actors’ coordination acts. These

principles will allow guiding how the acts of such actors are supported by DEMO’s I-organization, D-organization lay-

ers as well as application and technical layers.

61

Production princi-

ples (competence)

Data from CA02 must be updated in real-time; application should only accept the complaint fact

if only the critical CPB11 data is provided; A01 must need to authenticate to create or update

CA02 data; The information associated to CA02 must be stored centrally and be accessible by

only actors with authorized access;

Coordination princi-

ples (responsibility)

A01 relationship with customers must take into consideration CA02 profile and needs; CPB11

must be handled electronically; CA02 suggestions for improvements must be evoked actively; the

Portal where CA02 can introduce data should be implemented by using the notions of web 2.0 and

Rich Web Applications; application interfaces used by A01 to insert/manipulate data associated

to CA02 must follow the best practices and norms regarding accessibility and usability;

Table 9.2: Illustrative set of responsibility and competence principles for actor role A01 (Registrar)

4. define the competence domains and subsequent assignment rules for each actor role

Competence domains can be perceived as attributes that will guide the evaluation process to check if a person has the

adequate competence to exercise its job. Example of competence domains for role A01: Problem Solving, Customer

Service, Stress Tolerance, Self-Management, Decision-Making, Oral Communication, Conflict Management, Reasoning.

Based on the competence domains can be retrieved a set of assignment rules to guide the allocation of individual

with the right competences to each role. In this manner the HR can use such rules to deal with the continuous orga-

nizational changes. Example of assignment rules for A01 could be: HR must only accept people with more than two

years-experience in working with public contact; the actor must be fluent in the native language and English; HR should

privilege people who work with bureaucratic documentations; the actor role must master all the competence domains

enumerated above.

5. define all the authority, delegation and authorization rules for each actor role

Authority rules aim to address aspects related to the authority notion such as access to information resources and subse-

quent security. For this purpose should be defined (1) the steps that each actor need to do, (2) who is allowed to access

what information and the information that must be audited for each actor role.

All the steps to be performed are represented by the Process Struc-

ture Diagram for each transaction type. A process step is a transi-

tion in the C-world and it is represented by the C-act and the con-

sequent C-fact. Therefore, for one specific transaction, the Process

Model defines all the C-acts that an actor role is allowed to per-

form. Moreover, the PM also defines all the coordination and pro-

duction banks that an actor role needs information from in order

to act correctly. The responsibility areas are rigorously defined in

DEMO: nothing is redundant and nothing is omitted. Therefore,

we can state that the DEMO’s Process Model illustrates all the

c-acts an actor role is allowed and has to perform (see figure 9.5). Figure 9.5: Area of responsibility for actor role A01

The illustration of these three requirements can be further transformed in eligible authorization rules. Consequently,

62

Steps Information required Audit

Each time CA02 requests for a membership

registration, A01 needs to promise T01, and

request and accept T03 (if the case). It also

needs to accept T02 and execute and state

T01

All the production facts and coordina-

tion facts that are stored in CB03, CB01,

CB02, CPB11, CPB12, CPB14, PB03,

PB01, PB02 at different times

Relative time and promise , execu-

tion and state of T01, request and ac-

cept of T03 if the case, request and

accept T02

Table 9.3: Definition of authority rules

if the acts and information required do not exist, the actors are not allowed to do and see anything else than what is

specified. In this fashion, DEMO enforces a role-based access control. Moreover, should be defined authorization and

delegation rule which simply specify which role has the rights to give an amount of authority to other role, and each

actor role can delegate his amount of authority to other role.

6. identify the pre-conditions and post-conditions needed to discharge action rules, and create a list of exception

conditions

Action rules aim two govern the enterprise operation, and they consist of two categories: the coordination rules for guid-

ing the coordination activities (responsibility) and the production rules for guiding production activities (competence).

Action rules were defined in step 1 with DEMO methodology. Illustration of one of the various action rules associated

to the actor role A01:

on requested T01(M) with member(new M) = P

if age(P) < minimalAge

then decline T01(M)

else promise T01(M)

Figure 9.6: AR01 associated to the actor role registrar

on promised T01(M)

if < membership M applies for reduced fee for year Y>

then request T03(M,Y)

else if <membership M applies for reduced fee for year Y>

then request T02(M,Y) with standard_fee(Y)

Figure 9.7: AR02 associated to the actor role registrar

From the situation calculus theory and the system resilience research conducted, we outline the importance of using

conditional operators (pre-and post-conditions) to ensure that only valid structures (i.e. set of fluents for which the

enterprise is in an equilibrium state) can be built. We also identify the importance of anticipate and have normative

outputs to handle exception in order to ensure that the enterprise recovers to a new equilibrium state. Moreover, in

[Dobson, 2005] regarding the responsibility notion are defined constructs to model the notion of responsibility. These

constructs also comprise conditional indicators and exception lists in order to deal with undesirable changes.

A set of pre-conditions must hold before an action rule can start. These can be pre-conditions about the environment

state in which the responsibility is discharged and about the actor who has been assigned the responsibility. After an

instance of discharging a responsibility there are statements about the environment and the actor that are true, these are

the post-conditions (formal statements).

Pre-Conditions:

[Before AR01 can start] Admission form available;

63

[Before AR01 can finish] A01 has knowledge of required identification, and the number of free slot per day;

Post-Conditions: Admission decision recorded on form

if decision is to accept

then Number of members offered admission increased by 1;

Exception conditions list express all the exceptions that need to be handled when a deviation occurs and affects

the enterprise functioning. In this fashion, when an exception is detected the adequate mechanisms and actors will be

properly alerted.In the case when exceptions that will have negative impacts in other actors or any other elements of the

enterprise can be anticipated, the exceptions and subsequent impact should be identified. Tackling the situation calculus

approached in the state-of-the-art to the governance of undesirable changes:

• Rectify Rules RRX: action rules that aim to deal with exceptions;

• Fluents Fx: represents some property of the world whose value may change after a rectify rule have been per-

formed;

• do(RRX; FX, AX) represents the situation that results from actor role AX performing action rule RRX where FX

is intuitively true/satisfied;

• In case of exception, if Rectify Rules do not exist or the exception still persists after apply the rules, it may imply

three scenarios: (1) alerting key actors to address the exception, (2) creating new rectify rules to address the ex-

ception and/or (3) (re)design and (re) engineering certain organizational artifacts;

Exceptions illustration for A01:

(1) Exception (violated norm): Member applies with non-standard identification/qualification

F01: member eligibility; Responsibility: A01; RR01: the member must be immediately contacted and must be followed the proce-

dures defined in document Y

do(RR01, F01, A01) ; if the exception persists the Admissions Office should be alerted;

(2) Exception : Monthly income was less than 1.000 Euros

F02: monthly income; Responsibility: Library chief (e.g. A08); RR02: the EG of the library should be alerted and take the

appropriate corrective actions according to the practices in X

do(RR02, F02, A08) ; if the exception persists may imply a possible (re)design and (re) engineering of certain artifacts;

7. define a set of projects and programs to guide the implementation of the lowest-level construction models

The EG should not directly participate in the assignment of technological means (human and non-human). As we dis-

cussed before the role of governance is to ensure the correct execution of certain activities and not directly participate in

their execution. However, the EG should also guide the implementation process by means of projects and programs that

allow the system to implement its strategy and subsequent design.

In the enterprise context, the term enterprise program is used as a cluster of projects that must be coordinated in order

to contribute to a higher-order strategic goal, and project portfolio to refer to the central list of all enterprise projects

and their associated data. The evidence behind this competence is that an integrated design must be operationalized

through a similarly coherent and consistent set of projects and programs. Note that the enterprise governance should not

be responsible for the implementation of these projects but for their definition.

64

IVValidation

10Hypothesis Validation

A fact [...] is innocent, unless found guilty

A hypothesis is a novel suggestion that no one wants to believe

It is guilty, until found effective

– Edward Teller

In this chapter the main design artifact of our thesis - a reference method - will be validated in order to evaluate

its utility, quality, and efficacy in addressing the IV requirements elicited in an early phase of our research1. The

validation follows the design evaluation guideline within the design-science research methodology (we refer the reader to

section 4.2 thesis methodology). Briefly, there can be outlined five design evaluation methods: observational, analytical,

experimental, testing and descriptive [Hevner et al., 2004]. In this thesis, we will use in a complementary fashion two

evaluation methods: the observational and the descriptive method. The study of our reference method in DIAP business

environment corresponds to the case study evaluation within the observational method. The descriptive method will be

used to construct an informed argument based on the relevant research to prove the artifact’s utility (exploit throughout

the research). This argument is supported with a set of scenarios from the Library case and DIAP inquiries direction

case.

10.1 Case Study: DIAP - inquiries direction

DIAP is an organizational structure of the MP (Public Prosecution) with the competence to manage and direct the inquiry

and is responsible for the repression and prevention of crime and for the prosecution in the respective DIAP districts (see

also section 3 problem definition). DIAP is one of the several (sub)organizations of the Portuguese justice that together

constitute the Portuguese Justice System (PJS). The PJS is the set of entities and instruments used by government to

maintain social control, enforce laws, and administer justice by deterring and mitigating crime and sanctioning those

who violate laws. In this context it is important to understand the interfaces between DIAP and other entities of the

PJS in order to administer justice. For this purpose we stress the main relations among the main entities of the PJS in

Appendix 3.

The inquiries direction module within DIAP (DID) constitutes one of the core aspects of the PJS since it is through

such macro-process that the information to administer justice is gathered by means of diligences and crime investigations.

DID can be perceived as a decision support system (it decides if the client’s inquiry should be archived, should be target

of diligences and crime investigation or should be sent to Courts) used by citizens (its clients) to achieve improved

1Since the reference method is based on a set of conceptual models that stress the relation between the role of governance and the DEMO models,

these conceptual models are subsequently being validated (a detailed validation was left out from the document due to size restrictions).

65

decision-making for conflict resolution. As a DSS it gathers information from various internal and external systems

(e.g. registries, OPCs, MP). The public ministry where DID is part of has a body of autonomous magistrates formed

of public prosecutors. It is the prosecutor’s duty to present the case against an individual suspected of breaking the law

in a criminal trial. For the daily operation of DIAP, the magistrates are assisted by justice officials who are the staff in

prosecution offices which give support to the procedure. Briefly, the DID comprise five main macro-processes:

• Crime case identification: the process is triggered (initialized) when a individual, collective entity or public ad-

ministration police reports a crime. This macro-process comprise the process of complaint (registration and veri-

fication) by the citizen in the DIAP and subsequent legal proceedings;

• Inquiry pre-analysis and distribution: when a crime occurrence is notified the documents and information related

to the case is collected in order to decide the topology of the inquiry and proceed to its subsequent distribution to

the respective DIAP section and respective magistrate competence. Note that other processes such as redistribution

(e.g. inadequate competence of the magistrate) must be triggered within this macro-process;

• Inquiry analysis: the information and documentation associated to the inquiry is collected; the inquiry is prepared

and presented to the magistrate who will decide if the inquiry should be archived, sent to court or more dili-

gences and investigation should be performed. Depending on the decision deadlines management and expedition

documents are produced;

• Diligences and crime investigation: this macro-process occur aims to gather more information associated to the

inquiry in order to improve the final decision taken by the magistrate or judges. It comprises the production of

documents to approve the performance of diligences and investigation (approved by the instruction judge) and

coordination between OPCs and other entities in collecting information.

• Archiving or sent case to court: it comprises the respective notifications to the key stakeholders. In case of

archiving it may include the process of request approving with other entities in order to decide if the case should

or not be archived (usually done by the instruction judge). In case of utter charges, it comprise the process of

shipping the inquiry to courts.

Additionally to these processes, there are several supporting processes in order to ensure that the justice system is

managed properly, such as: administrative and financial support; human resources management; criminal reduction

support (e.g. implementation of deprivation and non-custodial punitive measures to prevent crime); the study, design,

development, implementation, support or management of computer-based information systems for the justice system

(e.g. ITIJ), among many others supporting processes.

10.2 Design artifact validation

In order to validate our method, each step of the method will be applied to the DID case and the utility of the artifact will

be assessed. Then, the results are evaluated against the four requirements and the contributions of the method will be

outlined. Note that the development of the artifact and its validation was a cyclical process, in the sense that our reference

method co-evolve with its assessment. For the complete description of the DID case including its main processes the

reader must read carefully Appendix 4 and see the subsequent overflow charts. The case description is divided in three

main parts: (1) the first part comprises the process of complaint and the pre-analysis process (topology identification

and (re)distribution processes); (2) the second part comprises the preparation of the inquiry and the decision process of

66

the magistrate; (3) the last part incorporates the four main processes that the inquiry can be subjected depending on the

magistrate decision: archiving, diligences, crime investigation and order of charge (sending the case to courts). This part

includes also the subsequent notification processes to stakeholders of the case and the approval of the final decision by

external entities.

1. Define the enterprise ontological models with DEMO

In order to construct the DEMO models of DID we execute the following steps:

• Describing a set of detailed scenarios and draw the subsequent flowcharts;

• Specifying the flowchart activities according to the three levels identified in the abstraction axiom (onto-info-data).

The focus on the B-org of an enterprise provided us a reduction of complexity of at least 70%.

• Identification of the transactions patterns (P-acts & C-acts) which provides a reduction of complexity of an addi-

tional 70%. Therefore, cumulated, there can be achieved complexity reduction of around 90%.

• Identification of the lawful states of the P-world and the C-world and the lawful sequences in both worlds.

• Production of DEMO models according to the way of working described in section 6.1.2.2.

Figure 10.1: Interstriction Model: Actor Transaction Diagram of MP-DIAP and Production Banks

We identified the following roles in DID, each role in practice is fulfilled by specific organizational functions or

profile (for a detailed explanation consult Appendix 4): (A01 Complaint admiter ; Central-Section-Desk collaborator)

(A02 Inquiry distributor ; Justice Official from Central-Section-Register) (A03 Inquiry (re)distribution decider ; Deputy

Prosecutor) (A04 Competence approver ; Prosecutor 2) (A05 Inquiry pre-analyst ; justice official from respective section)

(A06 Inquiry analyst ; Magistrate responsible for inquiry) (CA01 Complainer ; Citizen) (CA02 External ’information

activities’ approver ; Instruction Judge) (CA03 external information provider ; OPCs, criminal registry, citizens etc.)

(CA04 decision approver ; Instruction Judge).

2Note that if the expedition document purposes to request district competences, the order must be decided by the Republic’s General Prosecutor

(Procurador Geral da República).

67

The interstriction model can be seen in figure 10.1. One transaction represents four actions (promise:pm, request:rq,

state:st, accept:ac or decline:dc). The subsequent transaction result table can be consulted below. A Bank Contents Table

(BCT) specifies the fact banks in which the elements of object classes, and the instances of fact types and result types

from the SM are contained (this can be consulted in table 1 in Appendix 3). Also in appendix can be consult the process

diagram in figure 8 which specifies the lawful sequences of events in the P-world and the C-world: the atomic process

steps and their conditional and casual relationships. For each transaction or P-act, this process model reveals all implicit

(i.e., non-verbal) and all tacitly performed acts (C-acts).

Transaction Type Result Type

T01 complaint submission R01 complaint submission S has been started

T02 inquiry (re)distribution R02 inquiry I associated to the section Se has been created

T03 inquiry delegation decision R03 inquiry’s distribution process IDP has been decided

T04 inquiry delegation approval R04 inquiry’s distribution process IDP has been approved for delegation to Magistrate M

T05 inquiry preparation and presentation R05 inquiry I has been prepared and presented to Magistrate M

T06 inquiry future orientation R06 inquiry I analysis/decision has been started

T07 external information approver" R07 information gathering regarding inquiry I by information provider IP has been approved

T08 external information gathering R08 information provider IP deliver information documents D about the inquiry I

T09 complaint approver R09 complaint submission S has been approved (for charge or archive)

Table 10.1: Transaction Result Table

Figure 10.2: State Model

68

Figure 10.2 represents the State Model, represented in a State Space Diagram. From the case description and the

Transaction Result Table, we identify the internal categories COMPLAINT, INQUIRY and SECTION and the external

categories PERSON, PROSECUTOR, and INFORMATION PROVIDER (all colored gray).

2. define the enterprise architecture

It is important to have in mind that DIAP is a sub-organization of the Portuguese Justice System and thus, the global

architecture must be defined at the level of the PJS in order to achieve coherence and consistency among the principles

and standards for all the sub-organizations. As we outlined before, since a prescriptive notion of architecture it is not

a novel artifact of our thesis, we will just represent a small illustrative set of principles to guide the (re)design of the

DIAP. The process of devising such principles by means of the enterprise design domains is outlined in figure 9.4. The

principles are aligned with the enterprise strategy by tracing the enterprise goals with the areas of concern, and use the

areas of concern as a reference context for devising the principles (see figure 10.3. See also figure 10.4 for a recapturing

of what was analyzed in the UoD about the main enterprise design domains. Table 10.2 identifies the main areas of

concern of the DIAP. A table with the architecture principles for the DID case depicting the principles for the several

design domains and areas of concern can be consulted in Appendix 5.

Security There is still not mechanism that ensure that information resources can only be accessed by people or applications with

proven legitimacy and that information is only understood by those who have legitimacy to access.

Interoperability Criminal investigation and diligences are core processes of DIAP inquiries direction. However, it is still lacking mecha-

nisms for DIAP to effectively communicate with external entities from courts and OPCs to criminal registries.

Customer satisfaction One of the main concern is the public opinion about justice and the spread lack of trust in it.

Flexibility and speed The long waiting times associate to each inquiry and the long delays in conducting diligences and investigation should be

addressed by increasing the organization flexibility and quick responsiveness.

Regulatory compliance

and auditing

DIAP as a key public entity in the process of administer justice, it must itself respect a set of compliance and legislation

to be neutral and practice justice during inquiry direction. Moreover, no monitoring mechanisms exist to record historic

information to be later use for auditing purposes.

Table 10.2: DID areas of concern

Figure 10.3: Reference framework for architecturing Figure 10.4: Main enterprise design domain

3. identify the competence and responsibility principles for each actor role

The competence and responsibility principles aim to guide the engineering process by addressing how the production

and coordination acts are supported at the infologic, datalogic and technological layers. Table 10.3 illustrates a set of

competence and responsibility principle defined for a illustrative subset of the DID actor roles. Note that we only address

internal actors, since the coordination acts performed with external actors are addressed in the responsibility principles

of the internal actors that establish this interface.

69

Actor

Roles

Reference con-

text

Design principles and subsequent acts

A01Competence

(P-acts) Princi-

ples

The information associated to CA01 must be stored centrally and be accessible by only actors with authorized

access; data from CA01 must be updated in real-time; applications should only accept the complaint fact if

only the critical CPB01 data is provided; A01 must need to authenticate to create or update CA01 data;

Responsibility

(C-acts) Princi-

ples

A01 relationship with customers must take into consideration CA01 profile and needs; CPB01 must be han-

dled electronically; CA01 suggestions for improvements must be evoked actively; the Portal where CA01

can introduce data should be implemented by using the notions of web 2.0 and Rich Web Applications; ap-

plication interfaces used by A01 to insert/manipulate data associated to CA01 must present the information

in a consistent and structured manner depending on the CA01 profile, and must follow the best practices and

norms regarding accessibility and usability;

A02Competence

(P-acts) Princi-

ples

The identification of the inquiry topology and its distribution process must follow a set of accepted standards

defined by the EG; knowledge management systems must present CPB02 information, all the information

about past decisions and redistribution processes, and must have a collaborative space for A02 ideas; the sup-

portive processes of creating, printing, back-ups associated to the inquiry must be automatically processed;

the A02 acts regarding the creation of the inquiry template and its distribution must be performed centrally

and be accessible by the audit ability services;

Responsibility

(C-acts) Princi-

ples

The system that supports the distribution process to the different DIAP sections should respect a set of rules

defined by the EG regarding distribution scales, impediment of magistrates etc; all the information regarding

CPB02, the distribution process as well as changes and the redistribution process, must be stored centrally and

be accessible for auditing proposes. The portal, where A02 can create the inquiry and associate the respective

topology, must follow standards and norms that allow its integration with other justice systems.

A06Competence

(P-acts) Princi-

ples

All the orders, documents and CPB05 information should be protected with digitized signature, should be

stored centrally and be accessible for auditing proposes; the part of PJS system that supports A06 acts should

be provided with redundancy and load balancing mechanism to ensure appropriate levels of reliability and

performance; for supporting A06 decision-making processes, the information must be stored in a way that

makes possible to aggregate it or explore it at different levels of detail, and to alert an adequate competence

when data inconsistencies are detected; Information about defendants Processes must be accessible to A06 in

real-time and independently of the national location where the inquiry is been conducted; all the information

to be introduced by A06 must respect a specific data model defined and accepted by the EG;

Responsibility

(C-acts) Princi-

ples

One single communication protocol and communication standards should be defined by the EG allowing to

coordinate the DIAP-MP (in particular A06 acts) with courts, OPCs, criminal registries and other organiza-

tions regarding the reporting of inquiries, criminal investigations, diligences, prepare and electronically sign

orders (these protocols must be defined at the PJS nation-wide level); the application must support proce-

dures for verifying the authenticity of the documents received from external entities, particularly regarding

the documents integrity, non repudiation, and alert the user when there are any instances of non compliance

of authenticity provided; the registration of all A06 acts should be performed centrally and be accessible

for auditing proposes; all the information to be gathered from external sources CA03 should be validate by

mechanisms introduced by the user (metadata rules for filling inquiry fields) in order to ensure data consis-

tency and integrity; integration between systems from external entities should be based on the structuring and

provision of web services;

Table 10.3: Illustrative set of competence and responsibility principles

4. define the competence domains and subsequent assignment rules for each actor role

This will allow the enterprise to deal with the continuous changes of the actors by providing guidance to the HR team

in assigning an actor with adequate competences to a certain role. Additionally, assignment rules can be use to establish

performance expectations, and to evaluate actors performance.

70

(Actor roles : com-

petence domains)

(A01 : Customer Service, Stress Tolerance, Oral Communication, Conflict Management)

(A02 : Reasoning, Ability to organize) (A03 : Reasoning, Judging) (A04 : Decision-making,

Leadership) (A05 : Ability to organize, Write Communication, Team Skills) (A06 : Ability

to acquire knowledge, Judging, Reasoning, Self-management, Ability to deal with emotional

stress, Integrity)

Table 10.4: Competence domains for each actor role

Starting from the competence domains elicited the EG must define a set of assignment rules for each actor role. For

instance, for an actor to be assigned to the actor role:

• A01 - HR must not accept people without more than one year of experience in working with public contact; HR

should privilege people who work with bureaucratic documentations; the actor must demonstrate knowledge about

the PJS and she/he must demonstrate a customer-driven thinking. Additionally, formation should be conducted

in annual basis regarding information about complaints data, DIAP processes and conflict management. More-

over, the actor performance should be evaluated against the competence domains identified, and a set of metrics

regarding the complaint registration medium time.

• A06 - HR must have to take into account the DIAP section in which the actor will be associated - for this purpose

it should be created a matrix containing all the DIAP sections and the subsequent competences of the A06 (see

table 10.5); Examples of assignment rules if the actor will be associate to A06 exercising its competences in

DIAP section II: the actor must have knowledge in the legislature relative to minors, and must have formation

about the relations between the children behavior/reactions and the different kinds of abuse and educations; HR

should privilege actors able to deal with emotional stress; HR should not accept people that does not domain the

legislature regarding the section of DIAP that he must be allocated; Additionally, formation should be conducted

in annual basis regarding psychology issues about criminal behaviors. Furthermore, the actor performance should

be evaluated against the competence domains identified and a set of metrics based on the information retrieved

from their electronic agendas.

Sections Number Competence Domains Assignment Rules

Central Section14 CD01,CD02 AR1,AR2

15... CD01,CD03 AR3,AR4

Generic Sections5 CD04,CD05,CD01 AR2,AR4

7... CD01,CD02 AR1

Semi-specialized Sections2 CD03,CD06 AR5,AR6

4... CD07 AR7

Specialized Sections1 CD08,CD06 AR5,AR6

3 and 8 CD09 AR1,AR8

Table 10.5: Matrix for defining assignment rules for actor A06 regarding the different sections of DIAP

5. define all the authority, delegation and authorization rules

Table 10.6 specifies the ’need-to-do’ (acts), ’need-to-know’ (information required) and ’need-to-audti’ for every actor

role of the DIAP inquiries direction case. The table was obtained by analyzing the results from the Process Model

(responsibility areas), the Interstriction Model and the Bank Contents Table(see figures 10.1, 8 and 1 respectively).

71

We identified the following fact banks (depicted in detail in figure 1 in Appendix 4): COMPLAINT - PB01, INQUIRY

(initial creation with complaint data, inquiry topology etc.) - PB02, (re)distribution process decision - PB03, competence

approval - PB04, inquiry after preparation and pre-analysis - PB05, Decision about Inquiry - PB06, external approval

for conducting crime investigation and diligences - PB07, EXTERNAL INFORMATION (PB08), external approval for

archiving inquiry or sent to court (approval) (PB09), data collected about complaint (before creating inquiry) - CPB01,

information about DIAP sections and respective competences and cases - CPB02, general data about DIAP: actors,

resources, responsibilities and authorities, competences - CPB03, information about all the prosecutors (competences,

availability, historic information) - CPB04, and all information associated to the inquiry - CPB05.

The information associated to one inquiry can be understood as a collection of documents that together constitute

the inquiry folder. Regarding the inquiry folder, we outline seven different accesses to the folder:

1. create the folder with initial information and properties (e.g. NPUIC, rating, topology, crime nature, open and

prescription dates, complaint data, magistrate, stakeholders information) (PB02);

2. changing the properties of the folder (e.g. status, redistribution processes or dispatch of incompetence from the

magistrate) (PB03, PB04,PB05);

3. adding external information to the folder by means of investigations and diligences (PB08);

4. archiving folder (PB06);

5. adding supporting information associated to the folder (e.g. decisions, approval documents from internal and

external sources etc.) (PB04,PB06, PB07,PB09);

6. reading access levels to the folder (six reading access levels depending on the information desired: folder status,

folder properties, stakeholders data, investigation and diligences data, supportive information, folder security);

7. additionally, it must be added an seventh access for creating and changing the security access to the folder (lets

add a new composite fact bank to represent this information - CPB06);

Note that the actor role A06, responsible for the inquiry analysis, conduction and decision, maps directly in the or-

ganizational function ’Magistrate’. In the MP universe, can be distinguished five different profiles within the Magistrate

function: Procurador Geral Adjunto, Procurador da República, Procurador Adjunto, Procurador Adjunto Estagiário,

Substituto do Procurador Adjunto. However, this distinction at the profiles level is not related with the acts executed

by A06, the distinction refers to other roles these profiles may fill, such as, the courts they may represent (e.g. Procu-

rador Geral Adjunt may represent the “Tribunais da relação” and the Central Administrative Court, and Procurador da

Republica may represent the first instance courts), and the rights in approving/deciding the appropriate competences for

conducting an inquiry. It is interesting to see that by approaching the DIAP reality by actor roles instead of profiles

these aspects became clear, and authority rules and information access management can be enforce in a more transparent

manner depending on the role that one actor executes at the moment.

Figure 10.5 outlines the responsibility areas of the actor roles A01 (Complaint admitter), A02 (Inquiry creator/dis-

tributor) and A06 (inquiry analyst). From these responsibility areas we can retrieve all the steps that each actor role

needs to perform (’need-to-do’).

Table 10.6 explicits the ’need-to-do’, ’need-to-know’ and ’need-to-audit’ for each actor role. These three require-

ments can be further transformed in eligible authorization rules. Note that the actors are not allowed to do and access

anything else than what is specified in the “information required” field. An example of an authority rule would be: an

72

Figure 10.5: Areas of responsibility for actor roles A01, A02 and A06

Roles Acts Information required Audit

A01 Each time CA01 requests for a complaint, A01 needs to

promise T01, and request and accept T02 (if the minimum

requirements are ensured) and execute and state T01.

All the production facts

and coordination facts that

are stored in CB01, CB02,

CPB01, CPB03, PB01, PB02

Relative time + promise, ex-

ecution and state of T01, re-

quest and accept of T02

A02 Each time A01 requests for creation and distribution of the in-

quiry associated to the complaint, A02 needs to promise T02.

In case A02 cannot decide the topology/distribution process

of the inquiry, A02 needs to request and accept T03 and ex-

ecute T02. Otherwise, A02 requests and accept T05. If T05

result is denied A02 must request and accept T03

All the production facts and

coordination facts that are

stored in CB02, CB03, CB05,

CPB02, CPB03, PB02, PB03,

PB05


ecution and state of T02, re-

quest and accept of T03, re-

quest and accept of T05

A06 Each time A05 requests T06, A06 needs to promise T06. To

execute T06, A06 may need to request T08. For this purpose,

A06 needs first to request and accept T07. And only then,

request and accept T08. This process is cyclical till a decision

is made. When a decision is made, to execute the decision,

A06 needs to request and accept T09

All the production facts and

coordination facts that are

stored in CB06, CB07, CB08,

CB09, CPB03, CPB05 PB06,

PB07, PB08, PB09


ecution and state of T06,

request and accept of T07,

T08, T09

Table 10.6: Illustrative set of ’need-to-do’, ’need-to-know’ and ’need-to-audit’ for creating authority rules

actor filling the role A02 must have full access (create, read, update and delete)to CB02 and PB02, and it must have

read-only access to CPB02 and CPB03.

All the authority rules can be further mapped in a CRUDE table. Table 10.7 summarizes the information access for

the actor roles identified (the coordination facts were not included in the table for simplification reasons). Note that when

an actor creates, updates or delete information it must be authenticated to do such acts so the subsequent information

can be audited.

* Regarding the six access levels identified about the inquiry folder, A05 should only have access to the folder status and the folder properties

73

PB01 PB02 PB03 PB04 PB05 PB06 PB07 PB08 PB09 CPB01 CPB02 CPB03 CPB04 CPB05

A01 CRUD R CRUD R

A02 CRUD R R R R

A03 CRUD R R R

A04 CRUD R CRUD

A05 CRUD R R R*

A06 CRUD R CRUD R R CRUD

Table 10.7: DIAP Inquiries Direction CRUD matrix

Moreover, there should be defined delegation and authorization rules. An illustrative set of such rules is exemplified

below:

Authorization Rules: an actor filling the role A04 can authorize an actor filling the role A06 to be responsible for a certain INQUIRY

(note that A04 maps in the deputy prosecutor profile except if the authorization process concerns district competences, in that case the

role A04 maps in the profile of the Republic’s General Prosecutor); an actor filling the role A02 can execute an authorization process

for an actor filling the role A03 to be responsible for deciding the topology of the inquiry and subsequent distribution process; an actor

filling the actor role A06 that feels that his/her competences are not adequate, can initiate an authorization process for authorizing

another actor A06, this process will be latter approved by A04;

Delegation Rules: an actor filling the role A06 can delegate the responsibility of performing certain coordination acts to another actor

filling the same role (delegation processes usually occur when an actor role needs to be fulfilled by more than one actor in the same

transaction). Hence, the actor can delegate to another magistrate the responsibility of performing the coordination acts with external

entities for obtaining approvals or for gathering information (the actor who delegated the responsibility is still the main responsible

for the c-acts and respective facts).

6. identify the pre-conditions and post-conditions needed to discharge action rules, and create a list of exception

conditions

Below is specified an illustrative set of action rules for the actor roles A01, A02 and A06. Note that the definition of

these rules were defined in the first step of our method, since the definition of action rules is comprised in the DEMO

methodology. We propose to bring the conditional operators and exceptions associate to the responsibility notion and the

ontology of time. For each action rule, there should be defined a set of pre-conditions (PreC) that must hold before an

action rule can start, and a set of post-conditions (PosC) which are are statements about the environment and the agent

that are true after performing an action rule.

AR01-AR03 associated to the role A01 complaint admitter:

[PreC: Before workflow can start] Complaint admission form available; CA01 has required documentation;

[PreC: Before workflow can finish] A01 has knowledge of required identification;

when complaint submission (T01) of [complaint] is requested

if the complainer documents and filled specific model [Mo] respect the complaint admission requirements

then T01 of [complaint] must be promised

else T01 of [complaint] must be declined

[PosC] Admission decision recorded on form;

[PreC: Before workflow can start] [complaint] information is digitalized

[PreC: Before workflow can start] A01 has the adequate mechanisms to communicate [complaint] to A02

74

when complaint submission (T01) of [complaint] is promised

then inquiry creation/distribution (T02) of [inquiry] must be requested with

the information about complainer and complaint of inquiry = [complaint]

[PosC] Number of Complaints (NCo) = NCo+1;

when inquiry creation/distribution (T02) of [inquiry] is accepted

then complaint submission (T01) of [complaint] must be stated

[PosC] Inquiry creation recorded on form;

AR04 associated to the role A02 inquiry creator-distributor:

[PreC: Before workflow can start] A02 has the required information about inquiry topology and DIAP sections - CPB02;

A02 has the authority to create the [inquiry] and write access to the properties of the [inquiry];

[PreC: Before workflow can finish] communication mechanisms to send the inquiry to the respective DIAP section is available;

when inquiry creation/distribution (T02) of [inquiry] is requested

if the complaint information is complete

then if the inquiry can be typed

then T02 of [inquiry] must be accepted and inquiry preparation (T05) of [inquiry] must be requested

else inquiry delegation decision (T03) of [inquiry] must be requested

else T02 of [inquiry] must be declined

[PosC] Inquiry status set to ’Created’ by actor Y;

AR05-AR07 associated to the role A06 inquiry analyst:

[PreC: Before workflow can start] A06 has full read-access to the inquiry folder information;

when inquiry analysis (T06) of [inquiry] is requested

if Magistrate [M] has the adequate competence to conduct the [inquiry]

then if insufficient information regarding [inquiry]

then external information approval (T07) of [inquiry] must be requested

else complaint (charge/archive) decision (T09) of [inquiry] must be request

else T06 must be declined

[PosC] the Magistrate [M] decision regarding [inquiry] is recorded in the inquiry itself;

on external information approval (T07) of [inquiry] accepted

then external information gathering (T08) of [inquiry] must be request

[PreC: Before workflow can start] CA04 approved gathering external info of [inquiry]; external info regarding [inquiry] is available;

when external information gathe ring (T08) of [inquiry] is stated

if insufficient information regarding [inquiry]

then external information approval (T07) of [inquiry] must be requested

else complaint (charge/archive) decision (T09) of [inquiry] must be request

[PosC] [inquiry] is updated with external information; [inquiry] status updated to ’decision-making’;

on complaint (charge/archive) decision (T09) of [inquiry] accepted

then inquiry analysis (T06) of [inquiry] must be stated

[PosC] the [inquiry] status is updated to ’archiving’/’sending’ to court;

75

Illustrative set of exceptions:

(1) Exception: Information access to the inquiry folder was violated

F01: Inquiry confidentiality; Responsibility: PJS EG (e.g. CA05); RR01: the EG must be immediately alerted, the information

regarding the violation should be accessible to audit by the EG, the appropriate penalties must be applied and the impact of the

violation must be assessed

do(RR01, F01,CA05);

(2) Exception: The number of complaints and inquiry increase for more than 11500 in a month

F02: monthly complaints; Responsibility: CA05; RR02: analysis the possibilities to increase the number of inquiry analyst and

reduce the time spent for each inquiry analysis

do(RR02, F02,CA05) ; if the exception persists may imply a possible (re)design and (re) engineering of certain organizational

artifacts;

(3) Exception: The time for conducting investigation on the Inquiry exceed the time planned

F03: Inquiry analysis time planned; Responsibility: A06; RR03: the analysis of the inquiry delayed should assume maximize

priority, the delay should be communicated to the key stakeholders, information about the delay should be accessed by the EG;

do(RR03, F03, A06) ; if the exception persists may imply a possible (re)design and (re) engineering of certain organizational artifacts;

(4) Exception: The magistrate has no adequate competence to conduct the Inquiry

F04: Inadequate inquiry competence distribution; Responsibility: A06; RR04: A06 should send the document requiring for a

competence redistribution to Deputy Prosecutor A03 ((re)distribution decider), A03 should evaluate another magistrate to analysis

the inquiry and send the request for approval to the Prosecutor/Republic’s General Prosecutor A04 (competence approver);

do(RR04, F04, A06) ;

(5) Exception: Complaint is applied with non-standard identification/qualification

F05: Complainer eligibility; Responsibility: A01; RR05: the member must be immediately contacted and must be followed the

procedures defined in document Y;

do(RR05, F05, A06) ; if the exception persists the Admissions Office should be alerted;

(6) Exception: The inquiry was archived without the required approval from the instruction judge (C04)

F06: Inquiry decision eligibility; Responsibility: A06; RR06: A06 must be request the approval of the decision made, and in the

case that C04 does not consent the archiving of the inquiry, the appropriate procedures should be applied to re-activate the inquiry;

do(RR06, F06, A06) ;

7. define a set of projects and programs to guide the implementation of the lowest-level construction models

The definition of a coherent and consistent set of projects and programs is essential to implement the new DID arrange-

ments. This set of projects and programs to govern the implementation process takes place after the detailed construction

models of the enterprise had been produced by detailing the ontological models with the guideline provided by the prin-

ciples (engineering process guidance). However, since in the current reality of the PJS there is no EG, the set of projects

and programs to be defined should first concern the development of the EG competence and then extend and refine the

illustrative set of normative outputs depicted in this chapter to tailor to the overall context of the PJS3.

Given the complexity of the PJS and the current problematic situation regarding its information system, the imple-

mentation of such projects and programs may take several years. Hence, the scenario of evolution of the PJS in the

coming years (in particular its information systems) will be dominated by the dialectic between what exists (the As Is)

and what is projected in the future (the To Be). This dialectic will occur under social, media and politic pressure, requir-

3Note that a higher level of governance should also be defined at the level of the pubic administration comprising the PJS and other ministries.

76

ing that the EG must spread an appealing vision associated to this set of projects and programs, and must continuously

align the interests of all stakeholders.

The illustrative set of projects to implement the EG in the PJS and to apply our method to the justice reality is

summarized in figure10.6. This figure presents a simple road-map which should be understood as merely illustrative

in the sense that time estimations were produced ad-hoc based on (1) the time consumed for us to produce the DIAP

ontological models and the subsequent representative set of normative outputs, (2) the complexity of DIAP in comparison

with the whole complexity of the PJS, and (3) the number of team members (we considered a team of three consultants

with expertise in the area of enterprise engineering). Further work needs to be undertaken in order to produce a more

complete and refined implementation road-map.

Figure 10.6: Road-map to guide the implementation of the EG and normative outputs within our reference method

77

10.3 Contributions revisited

Method step Contributions

Definition of OM

with DEMO

The first major contribution is the great reduction of complexity of DIAP to a level where the models are intellec-

tual manageable. We begin the analysis of the ’DIAP inquiries direction’ with documents with over 15 process

models (accompanied with long descriptions) that approach the reality in a disintegrated manner. These process

models hardly would be used as an effective tool to communicate, to enhance self-awareness or as a rigorous

definition of terms.

Starting from these models, we mastered the DID complexity in 90% by detecting recurring transaction pat-

terns and by focusing on the DIAP essence (B-organization). As a result we obtained one small set of models

(e.g. Interstriction model to represent the DID construction) that can be used as a starting point to (re)design and

(re)engineering the enterprise reality, and to align the interest of stakeholders (shared conceptualization). By mod-

eling DID with DEMO, all the actor roles and subsequent acts were clearly identified at the design level allowing

that such notions can be continuously governed and controlled at the engineering and operational levels.

Definition of EA,

and competence

and responsibility

principles

As enumerated throughout the paper, the set of principles defined for each enterprise design domain allow the

undesirable design (transversal to ontological design and engineering) freedom to be restricted and thus, allow the

enterprise to achieve consistency and coherence among its elements. This is an essential aspect to increase the

enterprise ability to be agile and flexible. Such principles can also be used to identify inconsistent and incoherent

enterprise requirements.

By devising principles for each actor role and its subsequent acts, DIAP addresses how the ontological transac-

tions are supported at the infologic, datalogic, application and technological levels in order to achieve seamless

integration among the DID procedures while addressing DID areas of concern.

Definition of

assignment,

delegation, au-

thorization and

action rules (and

subsequent con-

ditional operators

and exceptions)

Such aspects allow DIAP to deal with the continuous changes of the organizational actors (assignment rules to

guide associate people to roles), to address security issues, to deal in a continuous, transparent and effective

manner with the access of actors to information resources, to trace the actors’ actions, to define in a clear way

who has the permissions to execute authorization processes and who has the rights to delegate his/her amount

of authority, among other aspects. Briefly, DEMO allows to approach the notions of competence, authority and

responsibility at the design level, and the proposed method aims to ensure the correct execution of such aspects at

the operational level by means of rules.

Moreover, the conditional operators and exceptions list will allow DIAP to address functioning issues and to

increase resilience to hazards. In particular, anticipating and handling exceptions allow to address undesirable

changes by applying corrective rules for the enterprise to recover to a new equilibrium stare and/or by triggering

alert mechanisms for the adequate people to handle the exception which may imply the (re)design of certain

organization artifacts.

Projects and pro-

grams to guide the

implementation

process

The current major initiatives regarding the justice information systems combined with growing users demand

for justice procedures efficiency, together with considerable advances in information technologies, are driving

efforts to define in DIAP a set of programs and projects to implement all the construction models resulting from

the (re)design and (re)engineering processes. For these initiatives to be successfully performed, they require a

governance competence with the vision, body of knowledge and authority to align the stakeholders’ synergies and

to guide the justice change projects from a global to a local level in a reactive and proactive manner.

Table 10.8: Method Contributions revisited

78

10.4 Artifact completeness

Figure 10.9 summarizes how the different stages of our method cover the IV requirements defined early in this document.

The method can be said complete since it covers the IV requirements, however within each requirement further analysis

need to be undertaken in order to evaluate its completeness. In terms of design and engineering we argue that the

reference method proposed is complete in the sense that (1) the definition of the enterprise ontology with DEMO covers

all the essential aspects of the enterprise ontological design, and (2) the definition of principles and standards by using

the enterprise architecture notion and the notions retrieve from the DEMO models cover all the essential aspects to

govern the design and engineering processes. The completeness of using this method in practice it will depend in the

principles and standards defined by a certain competence and not in the artifact used to guide the process of defining

such principles and standards.

Regarding implementation governance, we argue that activities beyond the definition of programs and projects (ac-

tivities that are directly related with executing the implementation process), should not be part of this governance re-

sponsibility and thus, the method is complete in covering this requirement. Nevertheless, a more detailed approach in

providing guidance over the implementation of construction models is particularly desirable. Regarding the governance

of the enterprise operation, we still think that more work needs to be undertaken. The authorization and delegation rules,

information access management, production and coordination rules as well as anticipation of exceptions are critical

mechanisms to govern the enterprise execution. However, there is a plenty of other aspects to be exploited. Never-

theless, future research regarding this topic should be concerned with the trade-off between normative outputs that can

increase the enterprise resilience to hazards but at the same time contribute to increase the enterprise bureaucratization

(especially when rules are used in a excessive way transcending the essential aspects for what they have been proposed).

Method steps

Requirements 1 2 3 4 5 6 7

Governance of the Enterprise (Onto.) Design process√ √

Governance of the Enterprise Engineering process√ √

Governance of the Enterprise Implementation process√

Governance of the Enterprise Operation√ √ √

Table 10.9: Evaluation of artifacts completeness against the IV initial requirements

79

VConcludingRemarks

11Discussion

The thesis aims to explore how enterprise ontological models can support the EG in continuously exercising guidance

over the different planes of an enterprise (from design to operation). For this purpose, DEMO was chose as a relevant

methodology to use. Hence, the main concern was to understand the EG operation exercised at the enterprise-wide level

and to exploit how it can retrieve concepts from the enterprise OM within DEMO to govern the enterprise development

process and subsequent dynamics. The process was divided into 6 main research questions depicted in Table 11.1.

Research questions Findings

1. To what extent does

the current research in the

field of ontology address

the enterprise modeling in a

holistic manner?

- From [Flores et al., 1988] to [Dietz, 2006] the enterprise ontology emphasizes the social activities by

which individuals generate the space of cooperative actions in which they work (i.e. actors activity is

carried out by communication where they enter and comply with commitments towards each other.).

- DEMO as an essential methodology for modeling the enterprise ontology in an intellectual manageable

way. DEMO as the key method to validate our hypothesis since it is based on a rigorous theory, and it

provides a clear definition of the notions of responsibility, competence and authority.

2. To what extent does the

current research in the field

of governance address guid-

ance at the enterprise wide-

level?

- EG as an organizational competence to guide the enterprise in a holistic manner by exercising guidance

over enterprise strategy and architecture development, and the subsequent design, implementation and op-

eration [Land et al., 2009, Hoogervorst, 2009]. Governance should be exercised as a multi-level structure

(from global to local).

- The enterprise development (design, implementation and operation) transcends the capabili-

ties of the Corporate, IT and Architecture Governance disciplines [Committee, 2006, ITGI, 2004,

Mueller & Phillipson, 2007]. They should be addressed within the overall scope of the EG.

- Given the highly organized complexity of enterprises, a mechanistic (top-down, management ori-

ented) perspective is not adequate to govern the enterprise. Hence, governance should be associated

to an organismic perspective relying on the skills, knowledge and free will of the enterprise employees

[Alberts & Hayes, 2006, Hoogervorst, 2009].

3. How can the notion

of ontology and time be

bridged in order to allow the

governance of the enterprise

dynamics?

- Enterprise construction models must co-evolve with the enterprise operation.

- The importance of time projection and conditional operators to ensure that only valid structures can be

built (situation calculus theory [Reiter, 1991, Fox et al., 1997]).

- From the resilience research, the need of anticipating and handling undesirable changes for allowing the

enterprise to recover to a new equilibrium [Lance H. Gunderson, 2002, Holling, 1973].

4. To what extent does the

current research addresses

the issue of governance over

the different enterprise se-

mantic contexts?

- We outline two main notions in current literature to support governance over the development process:

(1) the prescriptive notion of enterprise architecture comprising a set of principles defined for the the var-

ious system design domains and traced with the enterprise areas of concern to guide the enterprise design

[Land et al., 2009, Hoogervorst, 2009]; (2) the action rules defined within DEMO to guide the enterprise

operation by ensuring that the enterprise actors deal timely and adequately with their agenda [Dietz, 2006];

5. What is the connec-

tion thread between DEMO

& EG?

- We identified the notions of competence, responsibility and authority as the essential notions that can

support the EG in guiding the enterprise design and operation.

6. How could EG operation

be tackled using the DEMO

methodology?

- The studied in governance themes and the ψ-theory are combined into a high-level framework and a

subsequent step oriented method to tackle the production of normative outputs for the various enterprise

levels with DEMO. The method was illustrated with the Library example and applied on the DIAP.

Table 11.1: Research questions and respective findings

80

12Conclusion

All speech, action, and behavior are fluctuations of consciousness.

All life emerges from, and is sustained in, consciousness.

The whole universe is the expression of consciousness.

The reality of the universe is one unbounded ocean of consciousness in motion.

– Maharishi Mahesh Yogi

At a certain point in time, an enterprise is the result of a high number of coordination and productions acts performed

by a set of social individuals that behave according to assigned authority against a common background of social norms

and values. These norms and values are the ’rules of the game’, the constraints imposed by the governor to bring the

desired order among the enterprise elements (manifested in the enterprise design) in order to maximize its functioning

and subsequently increase resilience to hazards by ensuring that the enterprise active elements are coordinated in a

coherent and consistent manner and communicate with an unified and common language. Put another way, integration

among the enterprise aspects is an essential condition for adequate enterprise performance and strategic success.

Within this context two main problems may be in the origin of a high percentage of strategic failures resulting

primarily from inadequate strategy implementation. First, the enterprise does not have the ability to apply in practice

the design theory from the enterprise engineering discipline and thus, it is unable to master the enterprise complexity

from a holistic point of view and to develop an integrated enterprise system. For this problem we outline the notion of

enterprise ontology within DEMO methodology to represent the essence of an enterprise in an intellectual manageable

way. Second problem, the lack of an organizational competence that should govern globally the enterprise development

process and subsequent changes in order to ensure the correct use of this theory. Given the highly organized complexity

of enterprises, a mechanistic, top-down, structural and management oriented governance perspective is not adequate to

govern the enterprise. An organismic perspective relying on the diverse skills, knowledge, creativity and free will of the

enterprise employees is used for guiding the enterprise strategy and enterprise development by restricting the undesirable

design freedom in the form of principles and guide the subsequent enterprise operation in the form of operational rules.

This research brought together the notions of the enterprise governance and DEMO ontologic models in order to un-

derstand how such models can be a reference context to govern the enterprise semantic planes over time. The notions of

competence, responsibility and authority within DEMO were identified as essentials concepts that the EG must concern

in order to guide the enterprise (re)design, engineering and operation processes. Based on the research about enterprise

modeling, governance themes and the time and functioning notion of a system, we developed a method to support the

EG in defining a set of normative outputs. The method aims to answer to the four initial requirements identified:

• guide the ontological design process and aligning it with the enterprise strategy by promoting and defining onto-

logical models with DEMO (identifying at the design level the notions of actor roles, authority, competence and

81

responsibility) and by defining the EA [first two steps of the reference method];

• restrict detailed design freedom (or guide the (re)engineering process) by defining the EA1 and the competence,

authority and responsibility principles [2nd and 3rd step of our method];

• guide the system design implementation process by defining a coherent and consistent set of projects and programs

to implement the enterprise constructional models obtained from the two previous processes [last method’s step];

• govern the the on-going dynamics at the operational level by means of production, coordination, assigning, and

authority rules, as well as by the casual indicators and exception list researched in the field of the time ’situation

calculus’ and resilience that allows the enterprise to recover to new equilibrium states [4th-to-6th method’s steps];

It is expected that enterprises that effectively develop this governance competence and use the subsequent design

and engineering theory can transform the enterprise world in a semantic web of agents (human and machine entities)

where their interactions are projected and formally describe at different semantic planes by means of construction models

that track what the enterprise is and what it is becoming (real-time behavior utopia). The governance challenge is to

integrate these insights in an organizational competence that enhances self-awareness by understanding the individual

and collective processes (social and cognitive) whereby tacit knowledge is combined with real-time information in order

to effectively guide the synchronization of humans and machines among space and time vectors.

12.1 Future Work

For potential future research, the framework and underlying reference method presented should be applied, proven and

refined on several case studies from different industry branches. It seems particularly desirable that more research be

undertaken in order to continue the development of a set of normative artifacts to guide in practice the operation of

the EG. Insights on how to collectively define normative outputs, the subsequent decision-making processes and which

enterprise employees should collaborate in the production of each kind of outputs, are essential aspects that were slightly

addressed in chapter III and must be deeply addressed in future work. An analysis on how these aspects vary within

different industry branches and different enterprise complexities should be considered.

A topic that should be further exploited is the use of the GSDP in a recursive way to guide an enterprise in developing

its governing system (see appendix 2). All the steps of this process should be addressed in detail, and should also be

analyzed the possibility of creating a methodology for developing a governing system by means of this approach.

Following the research literature, it has been proposed a shift from a centralized top-down governance to an or-

ganismic one (competence based perspective). We approach the construction perspective on an organismic governance

competence at the ontological level (ontological model). However future research needs to be undertaken in three di-

rections: first starting from the ontological models should be produced a set of detailed construction models in order to

analyze how tan organismic perspective of the enterprise governance can be supported at the infological, datalogical and

technological levels; (2) the construction models should be implemented in practice and thus, validated and refined; (3)

it should also be assessed how this organismic competence affects organizational learning and self-awareness.

1Note that the principles defined within the EA are transversal to the enterprise ontological design and enterprise engineering

82

VIAppendix

.1 The way of working with DEMO

DEMO offers a solid connection between the essence of an enterprise and its implementation and realization. Practical

experiences have shown that DEMO is mostly used in combination with other modeling approaches like UML and Petri

Nets. For example, the Use Cases from UML can be derived from DEMO’s Interaction Model, a DEMO transaction

being the starting point for the functional specifications of a system. In DEMO, the ontological model consists of four

aspect models each having its corresponding diagram:

The Construction Model (CM) is the most concise model, it specifies the composition, the environment and the struc-

ture of an organization. Hence, it comprises the identified actor roles in the composition and in the environment,

and the identified transaction types among the actor roles, the information banks (coordination and production)

and the information links between the actor roles and the information sources. It can be divided into two models:

the interaction model (IAM) and the interstriction model (ISM). The former depicts the “active influencing rela-

tionships” between the actor roles: who is initiating or executing a transaction. The latter pictures the “passive

influencing relationships” between the actor roles: it restricts the actions among the actor roles by considering the

facts produced by other actor roles. The CM’s outputs are the Action Transaction Diagram, the Transaction Result

Table (created together also with the State Model), the Actor Bank Diagram and the Bank Contents Table (created

together with the State Model). The Transaction Result Table (TRT) is a table of the identified transaction

Figure 1: Legend of the Organization Construction Diagram

kinds. The structure of each entry is:

<transaction number> <transaction name> <result fact number> <result fact formulation>, where:

<transaction number> ::= T<numerical code> Example: T01

<transaction name> ::= <nominative expression> Example: rental start

<result fact number> ::= R<numerical code> Example: R01

<result fact formulation> ::= <verbal expression in past tense> Example: [rental] has been started

Note that in the result fact explanation, variables are denoted by [<entity kind>]

The Bank Contents Table (BCT) is a table that shows the fact kinds of which instances are contained in the

83

listed production banks. The structure of each entry is:

<production bank number> <fact kind reference>, where:

<production bank number> ::= PB<numerical code> Example: PB01

<fact kind reference> ::= <name of fact kind extension> Example: RENTAL

| <formulation of fact kind intension> Example: the renter of [rental] is [person]

The Action Model (AM) enumerates the action rules that guide the actors in dealing with their agenda. Each agenda

type has one or more action rules that are grouped based on the previously identified actor roles. The AM con-

stitutes the bases for all other model types: it contains all the information that is also present in the CM, PM and

SM, just in a more detailed and former manner.

Basic action rule syntax:

when < transaction kind > of < object identifier(s) > is < transaction status >

if< boolean logical expression >

then < transaction kind > of < object identifier(s) > must be < perfective form of C-act >

else < transaction kind > of < object identifier(s) > must be < perfective form of C-act >

Note1: < transaction status > = requested, promised, executed, stated, accepted, etc.

Note2: < perfective form of C-act > = requested, promised, executed, stated, accepted, etc.

Note3: action rules are the operational form of the laws in the Process Model and the State Model.

Note4. The syntax and the formal semantics of the action rules need to be elaborated yet.

The Process Model (PM) specifies the lawful sequences of events in the P-world and the C-world: the atomic process

steps and their conditional and casual relationships identified for each transaction type depicted in the CM- It has

as main output the Process Structure Diagram and together with the State Model, the Information Use Table.

Transaction Pattern syntax: A box represents an act (C-act or P-act), a disk represents a C-fact, and a diamond

represents the P-fact of the transaction.

An act with it resulting fact is called a transaction step. They are represented by the combination of a box and a

disk or diamond.

The grey-lined large rectangles represent the responsibility areas of the initiator and the executor. In the example,

the initiator is B-CA01 and the executor is B-A01.

The symbol for the production step is colored grey to emphasize that it is performed by the executor in isolation.

The meaning of a solid arrow from a disk or diamond to a box, is that the responsible actor will (try to) perform

the act when the transaction status that is represented by the disk or diamond, has been reached. An external status

(C-fact) is represented by a small disk.

A double disk represents a discussion status.

A small disk with a cross in it represents an exclusive or. It means that the responsible actor either performs the

one act or the other.

The State Model (SM) indicates the lawful states of the P-world and the C-world: the object classes, the fact types and

the ontological coexistence rules. It has as main outputs the Object Fact Diagram and the Bank Contents Table.

84

Figure 2: Legend of the State model

The way of working with the models and their corresponding diagrams is the anticlockwise way as they are depicted

in Figure 5.10. First, the method for identifying the actor roles and the boundary of the organization is applied. IAM is the

immediate result expressed in the Actor Transaction Diagram and the Transaction List Table. Next follows the Process

Model with the Process Structure Diagram for each transaction type and the action rules specifications (formulated in

a pseudo-algorithmic language). The State Model is produced next and for the completion of the Process Model, also

the Information Use Table is constructed. The Actor Bank Diagram and the Bank Contents Table form the ISM and

complete the Construction Model. The Actor Bank Diagram together with the Actor Transaction Diagram constitute the

Organization Construction Diagram.

85

.2 An approach to develop the Enterprise Governance

Figure 3: The Enterprise Governance Development Process

Figure 3 presents the conceptual model of the enterprise governance development process (EGDP). The EGDP was

obtained by applying the GSDP recursively to the EG itself. Naturally, the object system is the enterprise governance

system, our problem domain. The using system is an enterprise (or part of an enterprise) which will use the functionalities

(normative outputs) of the enterprise governance system. The EGDP is divided in five main phases which are numbered

with a circle in the framework. The result of each phase is numbered with a square.

1st organization reverse engineering: since enterprise ontologies are hardly applied in practice, the organization model

(OS) needs to be reverse engineered from the enterprise implementation. Hence, the first step in the EG develop-

ment is to produce the ontological model of the organization (phase result) which can be done by using DEMO

methodology.

2nd EG function design: the functional model of the enterprise governance should define the expected external behav-

ior of the enterprise governance system for a given set of inputs. For this purpose, the governance functionalities

are identified based on the organization model requirements and the input required to process each functionality

is analyzed. As a result, it will be presented a black-box model of generic enterprise governance.

3rd EG construction design: the next step in the process is to take the functional specification and to design the con-

struction of the enterprise governance system which is going to provide the previous defined functionalities. For

this purpose, we will use the DEMO methodology to modeling the enterprise governance. As a result of these

phase, it will be presented an ontological model of a generic enterprise governance.

4th EG engineering: starts from the ontological model resulting from the construction design (previous phase) and it

produces a set of more detailed white-box (constructional) models till an implementation model in order to fit

the generic ontological model to each specific enterprise context. The result of this phases is a set of engineering

practices and detailed models that critically guide how the EG should be engineered.

5th EG implementation and operation: starts from the engineering models (ideally implementation model) and al-

locate technological means to the actor roles, construction and production acts/facts. Furthermore, it defines a

road-map to guide the implementation/operation of these activities.

86

.3 The Portuguese Justice System

The following picture presents the main entities involved in the Portuguese Justice System. Note that the picture only

summarizes the aspects related to the justice system which is way too complex for the details to be captured in just one

picture. Therefore, it is only present the main internal and external entities and the main relationships between these

entities (but not all of them). See the Annex to consult the acronyms and respective Portuguese-English translation.

Figure 4: The Portuguese Justice System

Relations: 1. Case initialization by an individual or a collective entity; OPC reports a crime; penalty failure detection; exchange information

between clients (citizens) and justice about the status of the investigation/decision process. 2. Obtain international collaboration, information and

external regulations. 3. Exchange of information (coordination) with external entities in investigation processes. 4. External legislation. 5. Exchange

of information and coordination between OPCs and MP in crime investigation and diligences. 6. Exchange of information and coordination between

MP and Courts in crime investigation and diligences. 7. Advocacy acts in the interests of a particular citizen that is being judge in the court.

8. Exchange of information (coordination) between MP and other entities in investigation processes (e.g. registries), correctional system, etc. 9.

Supports and manages the Portuguese Justice System. 10. Exchange of information (coordination) between OPCs and courts in crime investigation.

87

.4 Practical case - MP-DIAP Inquiries Direction

.4.1 Description - Part I

One can denounce an unlawful behavior by submitting a complaint to DIAP which can be done personally in the Central-

Section-Desk of DIAP. In the complaint submission one has to fill a specific model or delivery documents with critical

information related to the complaint. Petunia das Queixas, a front-line collaborator, meets personally in the CS-Desk the

citizens that want to submit a complaint2, and helps them to fill the specific model. Then, Petunia receives the documents

and forwards them to the Central-Section-Register of inquiries.

Manuel dos Registos, a justice official of DIAP, receives the specific models or generic documents and pre-analyzes

them in order to identify the crime topology of each complaint. Depending on the analysis notes, he creates and dis-

tributes the inquiry to the respective sections. This action is performed on the SGI system. Manuel dos Registos also

creates the cover of the inquiry, printing layout available on the SGI system. If Manuel has doubts about how to distribute

the models or/and documents, they are sent to the duty prosecutor for a decision. After the decision the models or/and

docs returns for registration and distribution.

Magistrosa Proc Adjunta, a Deputy Prosecutor, may receive inquiries from Manuel dos Registos (CS-Register), the

ones that did not respect the distribution requirements or the ones where Manuel could not decided about their topologies

and destiny sections. In this last case or when Magistrosa feels that she does not have the adequate competences to decide

on a particular inquiry, she builds an expedition document which includes a decision about the inquiry redistribution.

Then, sends this decision to Clara Prepara Inqueritos (a justice officials from a particular section).

Clara receives Magistrosa expedition document and forwards to the Prosecutor Alves o Procurador. Note that if

the expedition document purposes to request district competences, the order must be decided by the Republic’s General

Prosecutor (Procurador Geral da Republica). Then, Alves analyzes the case and Magistrosa decision, and decides to

approve or not her decision. If Magistrosa’s decision is approved by Alves, the inquiry is sent to Manuel dos Registos

(CS-Register) to distribute to the new section and the new deputy prosecutor. If not, he re-sends the inquiry to Clara

Prepara Inqueritos for her to send the inquiry back to Magistrosa.

.4.2 Analysis - Part I

We will begin to translate the case to an overflow diagram: (1) a set of activities - simple rectangle; (2) decision paths -

diamond; and (3) processes or a set of activities performed in a constrained manner based on the coordination of a set of

system participants to realize a set of system goals - rectangle with loop. Note that a lot of simplifications were done in

the scenario as well as in the flowchart diagram. See figure 5 to see the flowchart diagram of the first part of the scenario.

Furthermore, we labeled the activities of the flowchart according to the three levels identified in the abstraction axiom

(onto-info-data). The focus on the B-organization of an enterprise provides for a reduction of complexity of at least 70%.

Note that we already abstract from the diagram a lot of infological and datalogical activities, a complete diagram of this

scenario would have more activities of these types. In the flowchart we also outline the transaction pattern to the business

activities (or P-Acts) which provides a reduction of complexity of an additional 70%. Therefore, cumulated, there can

2Note that this scenario is focused on DIAP and thus, reflect only the complaints that are aligned with DIAP’s crime topologies (e.g. crimes

occurring in areas belonging to different constituencies in the District Court of Lisbon)

88

be achieved complexity reduction of around 90%.

As the first step in developing the ontological model of MP-DIAP, we produce the Interaction Model, in which the

actor roles of MP-DIAP are represented as one composite actor role. The first interface transaction type (T01) that can

be identified is “complaint submission”. Regarding, the state model we can already identify the presence of a category

“COMPLAINT” and the existentially dependent binary fact type “Citizen Ci is the applicant of Complaint Co”. The

initiator of T01 is the citizen or complainer and the executor is the central-section-desk of MP-DIAP.

We identify the second interface transaction type (T02), called “Inquiry (re)distribution” with the result type “the

topology T and subsequent distribution process DP of Complaint Co has been decided”. The initiator of T02 is the

central-section-register of MP-DIAP. We will cal the executor role “inquiry Distributor”. After the complaint topology

to be decided, we can identify the category “INQUIRY” and the existentially dependent binary fact type “The Complaint

Co is associated with the Inquiry I”.

However, this second transaction can start other transactions when the cannot decide the complaint topology and

subsequent distribution process. The third transaction type (T03) that can be identified is “inquiry delegation decision”

and the binary fact “Deputy Prosecutor Dp decides on the distribution process of inquiry I”. In order to make the

ontological model of MP-DIAP more generic, we add to it the existentially dependent binary fact type “Decision-maker

DM decides on the distribution process of inquiry I”. The executor role of this transaction is “(re)Distribution Decider”,

while knowing that this role is now fulfilled by the organizational function “Deputy Prosecutor” (Procurador Adjunto).

For the state model we identified the category “DISTRIBUITION”.

Furthermore, we identified the transaction type T04 “Inquiry delegation approval”, and the binary fact “Distribution

Process DP for inquiry I has been approved”. The executor of T04 is the “Competence Approver” and is performed

by the organization function “Prosecutor” or “General Public Prosecutor” in the case of approving inquiry distribu-

tion to district’s competences. When the inquiry is distributed to the respective section the transaction T02 “inquiry

(re)distribution” is accepted tacitly and begins a new transaction type called “inquiry preparation and presentation”.

.4.3 Description - Part II

Clara Prepara Inqueritos and other justice officials from different sections of DIAP (depending on the complaint topol-

ogy) receive inquiries from Manuel. Clara confirms on a physic sheet the receipt of the inquiry and makes a search on

SGI to know if there is information on the people involved in each complaint. She also performs a few calculations

on the system regarding the inquiry’s costs. Then she delivers the inquiry to the magistrate and updates the status of

the inquiry as "delivered" to the magistrate. Magistrosa Proc Adjunta, a Deputy Prosecutor, receives the inquiry. She

analyzes the inquiry and confirms its reception.

After Magistrosa analyzed and decided to go forward with the case, she creates an expedition document with her

decisions. Depending on her decisions, it can happen four different scenarios. In either case, Magistrosa updates the

status of the inquiry, and manages deadlines. Furthermore, this information is recorded on the SGI.

89

Figure 5: Overflow chart with the transaction and abstraction axiom - part 1

.4.4 Analysis - Part II

The main activities regarding the execution of the transaction “inquiry preparation and presentation” are mainly data-

logical (e.g. updating status of the inquiry on the SGI) and infological (e.g. calculation of inquiry’s costs). We identify

one more internal transaction within MP-DIAP and one of the most critical transactions concerning the future of the

inquiry. We will label this sixth transaction (T06) “inquiry future orientation” with the result type “inquiry I orientation

analysis has been started”. This transaction is request after the section has performed the pre-analysis of the inquiry.

The executor is the “inquiry Analyst”, this role is mapped to the MP-DIAP magistrates (or prosecutors). Note that this

transaction can originate T03 and T04 when the inquiry Analyst considers that does not have the adequate competences

to analyze the inquiry. Based on the information associated to the inquiry, the Analyst decides the future of the inquiry

(T06 execution).

90


.4.5 Description - Part III

Magistrosa can decide four possible scenarios for the inquiry future:

Archiving and Notifications: If the magistrate issued an order for archiving the inquiry. The magistrate prepares all

necessary notifications and shall send it to the recipients. Note that this case involves transactions with other

entities in order to decide if the case should or not be archived. The inquiry may be sent to the instruction judge to

gather more information on the inquiry and in last instance to decide if should be or not archived. This case also

reflects the notifications to all the stakeholders involved in the inquiry.

Conducting Diligences: when more information about the inquiry is required, the production and mailing of documents

might be needed, both for internal and external entities. Note that diligences might need to be previously approved

by the instruction judge. The instruction judge might also need to validate the diligences.

Crime Investigation: the Magistrate delegates research in OPCs and other entities to gather more information about

the case. Note that this may include the process of defining the jurisdiction of Magistrate/Department of Public

Prosecution for inquiry investigation.

Utter Charges and Shipping inquiry for Judgment: If the Magistrate concludes that the inquiry should be send to

courts (charge), he/she gives the Order of charge and send to DIAP sections to ship the inquiry to courts.

Meanwhile, Petunia das Queixas (from central-section-desk) also receives inquiries documents from OPCs and other

entities that result from diligences and investigation scenarios. If the documents have NUIPC, Petunia refers directly

to the corresponding sections. If she can not identify the NUIPC of the inquiry documents, she refers to the central-

section-register inquiries. In the last case, Manuel dos Registos searches on the SGI system to identify the NUIPC and

sends the inquiry to the corresponding section. Then Clara Prepara Inqueritos recieves the inquiries, analyzes, delivers

to the magistrate and the story repeats over and over again till the magistrate to decide to either archive the inquiry or

utter charge to the courts.

91

.4.6 Analysis - Part III

If the magistrate decides to archive the inquiry, it begins the new macro process to consult other entities and approvals to

archive the inquiry. This macro process has transactions types associated but for now we will not concern them for sim-

plification reasons. The same rationale was applied to all the other transactions types involved in macro processes such

as inquiry archiving, send notification to key stakeholders, define investigation competence, and conducting diligences.

When the inquiry is archive the transaction T01 is declined, meaning that no charge result from the complaint.


We identify a seventh transaction type (T07) called “diligences approval” with the result type “Diligence D has

been approved”. The executor is the “Diligences Approver”. In order to make the ontological model of PJS generic

we labeled the executor of T07 “External Information Approver”, since other request similar to diligences can be done,

such as, approvals for investigation processes. Note that the external information approver role in the PJS organization

corresponds to the instruction judge. The instruction judge is also the approver of the final decision regarding T01

(accept the complaint and approving the utter charge, or decline the complaint and archive the inquiry). Note, that these

are two differentiate roles which is essential to capture the essence of the system. Therefore, the eighth transaction type

(T08) that can be identified is “Complaint Approver” with the result type “Complaint Co has been approved”.

Furthermore, we identify the ninth transaction type (T09) “external information gathering”, with the result type

“provider P has provided information Inf for the inquiry I”. This transaction is enough generic to concern external

entities responsible for investigation processes as well as diligences. Note that each one of these macro-processes has

several transactions associated but they are out of the scope of this scenario, since they are not initiated or executed by

92

any actor role of the MP-DIAP.

Figure 8 specifies the lawful sequences of events in the P-world and the C-world: the atomic process steps and

their conditional and casual relationships. For each transaction or P-act, this process model reveals all implicit (i.e.,

non-verbal) and all tacitly performed acts (C-acts).

Figure 8: Transaction Pattern: process model

93

object class, fact type, or result type P-bank

COMPLAINT PB01

person P is the complainer in complaint C

complaint C submission has been started

complaint C documents have been delivered

INQUIRY PB02

inquiry I has been created

inquiry I is associated to section Se

inquiry I has been distributed to the section Se

distribution process DP of inquiry I has been decided by magistrate M PB03

distribution process DP of inquiry I has been approved for delegation to Magistrate M PB04

inquiry I has been prepared and presented to Magistrate M PB05

inquiry I orientation analysis has been started PB06

EXTERNAL INFORMATION3 PB07

external information gathering EI is associated to inquiry I and information provider IP

external information gathering EI has been approved

external information gathering EI has been started

information provider IP deliver information documents D about the inquiry I PB08

complaint submission S has been approved (for charge or archive) PB09

COMPLAINT DATA CPB01

specific model

stakeholders information

complaint facts

...

DIAP SECTIONS CPB02

<section, competences>

special cases

GENERAL CPB03

<actor, responsibilities>

<actor, authorities>

<prosecutor, competences> CPB04

INQUIRY INFO CPB05

<inquiry, NPUIC>

<inquiry, status>

<inquiry, stakeholders information>

<inquiry, open date, prescription date>

<inquiry, investigation information>

<inquiry, diligences information>

Table 1: Bank Contents Table - fact banks

94

.5 Normative outputs

Area of Concern Main DesignDomain

Design Principles

Security

Technology Network access must be based on authentication and role-based authorization

Technology It must be supported procedures for verifying the authenticity of the documents received from external entities,

particularly regarding the documents integrity and non repudiation

Information All process steps requiring authorization must store executional data

Information All data must have associated accessibility policies

Business The permission to change properties of each inquiry folder must be traced with each actor role, and each actor

must be mapped with organization functions (or profiles);

Technology It must be define different security levels regard the inquiries folder from managing the security associated to

the folder to changing the properties of the inquiry;

Technology Key actors must be alerted when there is an instance of non compliance of authenticity provided

Technology Essential and critical IT systems must have fail-operational protection

Interoperability:

Information It must be defined one single communication protocol and communication standards by the EG that allows to

coordinate the DIAP-MP with courts, OPCs, criminal registries and other organizations

Business Integration services may not contain business logic

Information All the information to be gathered from external sources should be validate in order to ensure data consistency

and integrity

Technology IT service consumption must be independent from its implementation

Technology Integration between systems from external entities should be based on the structuring and provision of web

services that provide controlled access to content and features

Information Operational data must be separated from informational data

Information Data must must have precise semantics according to standardized ontologies

Technology E-business solutions must be access channel independent

Cust. satisf.

Business Suggestions for improvements must be evoked actively;

Information The status of the inquiry must be available at all contact points and may be consulted by the respective com-

plainer/individual suspected

Organization Complainers administration must be locally present, under unified, central governance

Information Delays and predict waiting times for each inquiry Process must be available

Information All operational authorizations must be linked to personnel data

Technology Portal with customers must follow the best practices and norms regarding accessibility and usability

Flex. and speed:

Technology Must be defined for the global justice system a set of redundancy and load balancing mechanisms to ensure

appropriate levels of reliability and performance

Organization Process flow control logic must be separated from process execution logic

Technology The system that supports the distribution process to the different sections should respect a set of rules defined

by the EG regarding distribution scales and impediment of magistrates

Technology For communication with external systems that are not done online, the system must provide buffering mecha-

nisms preventing situations of unavailability of the justice systems

Information Information must be stored in a way that makes possible to aggregate it or explore it at different levels of detail

Organization Employee decision making must take place at the lowest possible level

Compl. and audit.:

Information Process events must be logged in read-only data storage

Information Actors’ acts regarding creating, updating or deleting inquiry information must be performed centrally and be

accessible by the audit ability services;

Information The auditing structure should allow to respond anytime to any information request about a particular proce-

dure/folder by means of “Crystal Reports” parameterized;

Technology Financial operational events must update financial informational systems real-time

Information Process design must exclude the necessity for data reconciliation

Technology Procurement processes must have ’non repudiation’ protection

Information Financial data should be stored at only one location

Table 2: Examples of architecture notion in practice for DID

95

.6 Revisiting OSA notion and aligning this notion with governance

The challenge of enhancing OSA is to master all the available information associated to an enterprise system and

to pass this information into the cognitive domain (a human brain). This is when information becomes awareness

[Alberts & Hayes, 2006]. Humans, as individuals, generate situation understanding by combining situation information

awareness with their prior knowledge and conceptual models, which comprise perceptions of the dynamics of cause-

effect relationships. By approaching an enterprise as a semantic web we can master its complexity at different semantic

planes. A semantic web can be perceived as a set of semantic planes that are guided by means of formal specifications in

order to provide a formal description of concepts, terms, and relationships within a given knowledge domain. Similarly,

an enterprise should be projected at different semantic planes, and the meaning (semantics) and distribution of informa-

tion should be formally described. To face this challenge, the EG purposes to guide the production of models which

capture the enterprise essence from different perspectives (e.g. system construction, processes, states) and at different

abstraction levels.

As we previously analyzed, the enterprise world consists of agents producing coordination and production facts,

as time flows. This reality is governed by a set of rules that constitute the ontological models. Furthermore, in order

to contemplate enterprise changes in these models, it was presented in [Aveiro, 2009] a way to capture the enterprise

dynamics by means of recursion of the world ontology. Within this perspective, OSA can be approached as the (1)

transformation process through which (2) the enterprise world becomes a semantic web of agents (human and machine

entities) that (3) are part (the self) of the enterprise world. This means that OSA starts by understanding the agents’ acts

and the facts produced, and it purposes to project this reality in different semantic planes where this reality is formally

describe. Finally, this formal specification should not be ’at present’ but should be part of the enterprise world capturing

on-going changes (real-time utopia). This OSA notion and its relation with the EG is summarized in figure 9. We outline

four main OSA concerns:

• Situation Awareness: the capability to extract patterns and meaningful activities from the enterprise world in a holistic manner

[Alberts & Hayes, 2006];

• Congruent Understanding and Prediction: the capability to temporally project these patterns and activities into different futures

by identifying threats and emerging opportunities.

• Effective Decision-making: the capability to form focused and timely decisions that accurately react/respond to these threats

and opportunities with available resources and capabilities.

• Coherent and Consistent Governance Intent : the capability to articulate decisions in terms of guidelines and constraints

provided by the governing system.

Figure 9: Organizational Self-awareness and Enterprise Governance

96

Bibliography

[Ackoff, 1971] Ackoff, Russell L. 1971. Towards a system of systems concepts. Management Science, 17(11).

[Ackoff, 1999] Ackoff, Russell L. 1999. Ackoff’s Best: His Classic Writings on Management. 1 edn. Wiley.

[Alberts & Hayes, 2006] Alberts, David S., & Hayes, Richard E. 2006. Understanding Command and Control. CCRP Publication

Series.

[Applegate & McKenney, 1995] Applegate, Lynda M., & McKenney, James L. 1995. Corporate Information Systems Management:

Text and Cases. McGraw-Hill Professional.

[Auramäki et al., 1988] Auramäki, Esa, Lehtinen, Erkki, & Lyytinen, Kalle. 1988. A speech-act-based office modeling approach.

ACM Trans. Inf. Syst., 6(2), 126–152.

[Austin, 1976] Austin, J. L. 1976. How to Do Things with Words: The William James Lectures Delivered in Harvard University in

1955 (Oxford Paperbacks). 2nd edn. Oxford Paperbacks.

[Aveiro, 2009] Aveiro, David. 2009. GOD-theory for organizational engineering: continuously modeling the continuous

(re)Generation, Operation and Deletion of the enterprise. Ph.D. thesis, Instituto Superior Técnico, Lisboa, Portugal.

[Boulter et al., 2010] Boulter, Nick, Dalziel, Murray, & Hill, Jackie. 2010. Achieving the perfect fit: how to win with the right people

in the right jobs. Gulf Publishing Company.

[Braun et al., 2005] Braun, Christian, Wortmann, Felix, Hafner, Martin, & Winter, Robert. 2005. Method construction - a core

approach to organizational engineering. Pages 1295–1299 of: SAC ’05: Proceedings of the 2005 ACM symposium on Applied

computing. New York, NY, USA: ACM.

[Buckle et al., 2000] Buckle, P., Mars, G., & Smale, S. 2000. New approaches to assessing vulnerability and resilience. Australian

Journal of Emergency, 8–15.

[Bunge, 1977] Bunge, M.A. 1977. Treatise on Basic Philosophy: The Furniture of the World. Dordrecht, The Netherlands: D. Reidel

Publishing Company.

[Carlsson, 2006] Carlsson, Sven A. 2006. Towards an information systems design research framework: A critical realist perspective.

In: In Proceedings of the First International Conference on Design Science Research in Information Systems and Technology.

[Chauvet, 1993] Chauvet, G. A. 1993. Non-locality in biological systems results from hierarchy. Application to the nervous system.

Journal of mathematical biology, 31, pp. 475–486.

[Christensen & Bickhard, 2002] Christensen, Wayne D., & Bickhard, Mark H. 2002. The Process Dynamics of Normative Function.

Hegeler Institute. Chap. In Monist.

[Committee, 2006] Committee, Basel. 2006. Core Principles for Effective Banking Supervision. Bank for International Settlements.

[Daft, 2006] Daft, Richard L. 2006. Organization Theory and Design: Understanding the Theory and Design of Organizations.

South-Western, Div of Thomson Learning.

[Dalziell & McManus, 2004] Dalziell, E. P., & McManus, S. T. 2004. Resilience, Vulnerability, and Adaptive Capacity:. Tech. rept.

University of Canterbury. Civil and Natural Resources Engineering.

[Dewsbury & Dobson, 2007] Dewsbury, Guy, & Dobson, John. 2007. Responsibility and dependable systems. Springer.

97

[Dietz & Hoogervorst, 2007] Dietz, Jan, & Hoogervorst, Jan. 2007. Enterprise Ontology and Enterprise Architecture, How to let

them evolve into effective complementary notions. GEAO Journal of Enterprise Architecture, 2.

[Dietz, 2006] Dietz, Jan L. G. 2006. Enterprise Ontology: Theory and Methodology. Springer.

[Dietz, 2008] Dietz, Jan L. G. 2008. Architecture - Building strategy into design. The Hague, Netherlands: Academic Service.

[Dobson, 2005] Dobson, J. 2005. Roles are responsibility relationships really. IEEE Symposium on People and.

[Eberhardt Rechtin, 1999] Eberhardt Rechtin, A. Terry Bahill. 1999. Systems Architecting of Organizations: Why Eagles Can’t

Swim. 1 edn. CRC.

[Flores et al., 1988] Flores, Fernando, Graves, Michael, Hartfield, Brad, & Winograd, Terry. 1988. Computer systems and the design

of organizational interaction. ACM Trans. Inf. Syst., 6(2), 153–172.

[Fox et al., 1997] Fox, Mark S., Barbuceanu, Mihai, Gruninger, Michael, & Lin, Jinxin. 1997. An Organization Ontology for

Enterprise Modelling. In: Modeling, In: International Conference on Enterprise Integration Modelling Technology 97. Springer.

[Garud et al., 2008] Garud, Raghu, Jain, Sanjay, & Tuertscher, Philipp. 2008. Incomplete by Design and Designing for Incomplete-

ness. Organization Studies - SAGE Publications, 29(03), 351–371.

[Gingrich, 2003] Gingrich, P. 2003. Introduction to Social Theory - Class Notes. Ph.D. thesis, Department of Sociology and Social

Studies - University of Regina.

[Gruninger et al., 2000] Gruninger, Michael, Atefi, Katy, & Fox, Mark S. 2000. Ontologies to Support Process Integration in

Enterprise Engineering.

[Haren, 2005] Haren, Van. 2005. TOGAFTM The Open Group Architecture Framework A Management Guide. Van Haren Publishing.

[Henderson & Venkatraman, 1999] Henderson, J. C., & Venkatraman, N. 1999. Strategic alignment: leveraging information tech-

nology for transforming organizations. IBM Syst. J., 38(2-3), 472–484.

[Henriques et al., 2010a] Henriques, Miguel, Tribolet, José, & Hoogervorst, Jan. 2010a. Enterprise Governance and DEMO - Guid-

ing enterprise design and operation by addressing DEMO’s competence, authority and responsibility notions. In: Proceedings of

INFOrum 2010. Universidade do Minho.

[Henriques et al., 2010b] Henriques, Miguel, Tribolet, José, & Hoogervorst, Jan. 2010b. Enterprise Governance and DEMO: a

reference method to guide enterprise design and operation with DEMO. In: Proceedings of CAPSI 2010.

[Hevner et al., 2004] Hevner, A. R., March, S. T., Park, J., & Ram, S. 2004. Design Science in Information Systems Research. MIS

Quarterly, 28(1), 75–105.

[Holling, 1973] Holling, C. S. 1973. Resilience and stability of ecological systems. Annual Review of Ecology and Systematics.

[Hoogervorst, 2009] Hoogervorst, Jan A. P. 2009. Enterprise Governance and Enterprise Engineering (The Enterprise Engineering

Series). 1 edn. Springer.

[Hoogervorst & Dietz, 2008] Hoogervorst, Jan A. P., & Dietz, Jan L. G. 2008. Enterprise Architecture in Enterprise Engineering.

Enterprise Modelling and Information Systems Architectures, 3(1), 03–13.

[IEEE1471, 2000] IEEE1471. 2000. IEEE 1471-2000 Recommended Practice for Architectural Description for Software- Intensive

Systems. Tech. rept. IEEE Computer Society.

[ITGI, 2004] ITGI, The ITGovernance Institute. 2004. Board Briefing on IT Governance. The Information Systems Audit and Control

Association.

[Kampfner, 2001] Kampfner, R. 2001. Adaptive systems view of organizational functions. Proceedings of the 45th Annual Confer-

ence of The International Society for the Systems Sciences.

[Kaplan & Norton, 2004] Kaplan, Robert S., & Norton, David P. 2004. Strategy maps. Boston, Mass.: Harvard Business School

Press.

98

[Kavakli & Loucopoulos, 1999] Kavakli, V., & Loucopoulos, P. 1999. Goal-driven business process analysis application in electricity

deregulation. Information Systems Journal, 24, 187–207.

[Kosanke et al., 1999] Kosanke, K., Vernadat, F., & Zelm, M. 1999. CIMOSA: enterprise engineering and integration. Comput. Ind.,

40(2-3), 83–97.

[Kotter, 1995] Kotter, John P. 1995. Leading Change: Why Transformation Efforts Fail. Harvard Business Review, 59–67.

[Lance H. Gunderson, 2002] Lance H. Gunderson, Lowell Pritchard. 2002. Resilience and the behavior of large-scale systems. Island

Press.

[Land et al., 2009] Land, Martin Op’t, Proper, Erik, & Waage, Maarten. 2009. Enterprise Architecture: Creating Value by Informed

Governance. Springer-Verlag.

[Li & Williams, 2005] Li, Hong, & Williams, Theodore J. 2005. A Vision of Enterprise Integration Considerations: a holistic

perspective as shown by the Purdue Enterprise Reference Architecture. IFIP International Federation for Information Processing.

Springer Boston.

[Magalhães & Silva, 2009] Magalhães, R., & Silva, A. Rito. 2009. Organizational Design and Engineering. Tech. rept. Center for

Organizational Design and Engineering, Lisboa, Portugal.

[Magalhães & Tribolet, 2005] Magalhães, Rodrigo, & Tribolet, José. 2005. Engenharia Organizacional: das partes ao todo e do todo

às partes na dialectica entre pessoas e sistemas. Sistemas de Informacao Organizacionais.

[Mintzberg, 1983] Mintzberg, H. 1983. Structure in Fives - Designing Effective Organizations. Prentice Hall Inc.

[Mueller & Phillipson, 2007] Mueller, Lynn M., & Phillipson, Andrew. 2007. The emerging role of IT governance. Tech. rept. IBM

institute.

[Mulder, 2006] Mulder, J. 2006. Rapid Enterprise Design. Tech. rept. PhD thesis, Delf University of Technology.

[Neves & Onori, 2009] Neves, Pedro, & Onori, Mauro. 2009. Evolvable Production Systems: Approach towards Modern Production

Systems. In: Proceedings of the 6th CIRP-Sponsored International Conference on Digital Enterprise Technology. Springer Berlin

/ Heidelberg.

[O’Donovan, 2003] O’Donovan, Gabrielle. 2003. A Board Culture of Corporate Governance. International Journal.

[Paape, 2007] Paape, L. 2007. Corporate Governance: The Impact on the Role, Position, and Scope of Services of the Internal Audit

Function. Ph.D. thesis, Rotterdam School of Management (RSM).

[Parsons, 1951] Parsons, T. 1951. The Social System. Free Press.

[Peffers et al., 2007] Peffers, Ken, Tuunanen, Tuure, Rothenberger, Marcus A., & Chatterjee, Samir. 2007. A Design Science Re-

search Methodology for Information Systems Research. Journal of Management Information Systems.

[Pettigrew, 1998] Pettigrew, Andrew M. 1998. Success and failure in corporate transformation initiatives. Pages 271–289 of: Infor-

mation Technology and Organizational Transformation. New York, NY, USA: John Wiley & Sons, Inc.

[Reiter, 1991] Reiter, Raymond. 1991. The frame problem in situation the calculus: a simple solution (sometimes) and a complete-

ness result for goal regression. San Diego, CA, USA: Academic Press Professional, Inc. Pages 359–380.

[Smith & Fingar, 2003] Smith, Howard, & Fingar, Peter. 2003. Business Process Management: The Third Wave. Meghan-Kiffer

Press.

[Sousa et al., 2006] Sousa, Pedro, Caetano, Artur, Vasconcelos, Andre, Pereira, Carla, & Tribolet, José. 2006. Enterprise architecture

modeling with the Unified Modeling Language. Idea Group Publishing. Enterprise Modeling and Computing with UML.

[Vernadat, 2002] Vernadat, François. 2002. Enterprise modeling and integration (EMI): Current status and research perspectives.

Metz, France: Elsevier Science Publishers B. V.

99

[Wand et al., 1999] Wand, Yair, Storey, Veda C., & Weber, Ron. 1999. An ontological analysis of the relationship construct in

conceptual modeling. ACM Trans. Database Syst., 24(4), 494–528.

[Warfield & Cardenas, 2002] Warfield, John N., & Cardenas, A. Roxana. 2002. Handbook of Interactive Management. Ajar Pub-

lishing Company.

[Weick, 2001] Weick, Karl E. 2001. Making sense of the organization. Blackwell Publishing.

[Weill & Ross, 2004] Weill, Peter, & Ross, Jeanne W. 2004. IT governance: how top performers manage IT decision rights for

superior results. Harvard Business School Press.

[Weinberg, 2001] Weinberg, Gerald M. 2001. An Introduction to General Systems Thinking. Dorset House Publishing Company,

Incorporated.

[Winograd, 1988] Winograd, Terry. 1988. A language/action perspective on the design of cooperative work. San Francisco, CA,

USA: Morgan Kaufmann Publishers Inc.

[Wittgenstein, 1984] Wittgenstein, L. 1984. Werkausgabe Band 1: Tractatus logico-philosophicus. Tagebücher 1914-16.

Philosophische Untersuchungen.

[Yu & Mylopoulos, 1994] Yu, Eric S. K., & Mylopoulos, John. 1994. From E-R to "A-R" - Modelling Strategic Actor Relationships

for Business Process Reengineering. Pages 548–565 of: Proceedings of 13th Int. Conf. on the Entity-Relationship Approach

(ER’94), number 881 in Lecture Notes in Computer Science. Springer-Verlag.

[Zacarias et al., 2007] Zacarias, Marielba, Magalhaes, Rodrigo, Caetano, Artur, Pinto, Helena Sofia, & Tribolet, Jose. 2007. Towards

Organizational Self-Awareness: An Initial Architecture and Ontology. Idea Group Inc.

[Zachman, 1999] Zachman, J. A. 1999. A framework for information systems architecture. IBM Syst. J., 38(2-3), 454–470.

100

Enterprise Governance and DEMO - ULisboa › downloadFile...Enterprise Governance and DEMO Towards a...

Documents

Transcript of Enterprise Governance and DEMO - ULisboa › downloadFile...Enterprise Governance and DEMO Towards a...