Towards an Enterprise Ontology-based Approach to ......O conceito de ontologia empresarial divide uma empresa em tres ca-ˆ madas: Ontological, Infological e Datalogical, focando a

Towards an Enterprise Ontology-based Approach toInformation Architecture

Miguel Morais da Cunha Catarino Tavares

Thesis to obtain the Master of Science Degree in

Information Systems and Computer Engineering

Examination Committee

Chairman: Prof. Mario Jorge Costa Gaspar da SilvaSupervisors: Prof. Doutor Andre Ferreira Ferrao Couto e Vasconcelos

Prof. Doutor Artur Miguel Pereira Alves CaetanoMember of the Committee: Prof. Pedro Manuel Moreira Vaz Antunes de

Sousa

May 2013

placeholder

Abstract

The role of information has become increasingly important and crucial for organizations. Therefore

improving the management of information has been a real concern for organizations, and for that

reason the importance of Information Architecture (IA) in organizations has become very high. Public

administration (PA) is no different, and, as a result, the development and improvement of an IA as a

reference for the PA has become an important goal.

This work aims to define how an organization can accomplish its IA through an Enterprise Ontology

(EO) approach. The EO divides an enterprise in three layers: Ontological, Infological and Datalogical,

and focuses its theory and application on the ontological layer, which represents the business layer of an

enterprise, through its methodology Design & Engineering Methodology for Organizations (DEMO). This

means that EO focus on the business essence of an enterprise independently of its implementation.

This work proposes to use the DEMO to create an IA and assesses if the result is a valid IA that is

well accepted in the PA context. In order to demonstrate how DEMO can create an IA, the proposed

methodology was applied in three case studies, namely, two Portuguese PA service providers and an

on-line appointment application of a Portuguese public organization. For the evaluation of the results a

Design Science Research Methodology (DSRM) was applied and in the evaluation step it was applied

the Moody & Shanks Framework with the feedback from the stakeholders. In the end, we concluded that

DEMO is a valid and reliable method to create an IA.

Keywords: Information Architecture , Enterprise Ontology , DEMO , Enterprise Architecture , Infor-

mation Entities , Public Administration

iii

placeholder

Resumo

Opapel da informacao nas organizacoes tem-se tornado cada vez mais importante e crucial. Por

isso, melhorar a gestao da informacao tornou-se numa verdadeira preocupacao para as empre-

sas e por essa razao a importancia da arquitetura informacional tem-se tornado cada vez maior. A

administracao publica nao e diferente e, por isso, o desenvolvimento e melhoria de uma arquitetura

informacional de referencia tem-se tornado num objetivo da administracao publica.

Este trabalho procura definir como uma organizacao pode conseguir a sua arquitetura informacional,

usando Enterprise Ontology. O conceito de ontologia empresarial divide uma empresa em tres ca-

madas: Ontological, Infological e Datalogical, focando a sua teoria e aplicacao na camada ontologica,

que representa a camada de negocio de uma empresa, atraves da sua metodologia Design & Engineer-

ing Methodology for Organizations. Desta forma as ontologias empresariais focam-se exclusivamente

na essencia do negocio, independentemente da sua implementacao.

Este trabalho propoe usar esta metodologia para criar uma arquitetura informacional e avalia se o

resultado e uma arquitetura informacional valida e bem aceite no contexto da administracao publica. De

forma a demonstrar como esta metodologia cria uma arquitetura informacional a mesma foi aplicada

em tres casos de estudo, nomeadamente, dois organismos da administracao publica que fornecem

servicos e uma aplicacao de marcacao de consultas de outro organismo publico. De forma a avaliar os

resultados aplicamos a Design Science Research Methodology e no processo de avaliacao foi utilizada

a Framework de Moody & Shanks e as opinioes dos intervenientes. No final, concluımos que o DEMO

pode ser utilizado para criar uma arquitetura informacional.

Keywords: Arquitetura Informacional , Enterprise Ontology , DEMO , Arquitetura Empresarial , Enti-

dades Informacionais , Administracao Publica

v

placeholder

Acknowledgements

This dissertation has been a long and hard journey and certainly the most challenging project i

have done so far in my life, and which could not have been possible without so many people and

to whom i am deeply grateful for all their support.

First and foremost, i want to express my gratitude to my supervisor, Prof. Andre Vasconcelos, for all the

guidance and support, for all the patience and availability, and whose expertise and knowledge made

this work possible. I thank him for everything.

I thank my co-supervisor, Prof. Artur Caetano, for all the guidance and support, specially in the beginning

of this thesis, where his advise was very important for its definition.

I also want to thank Eng. Carlos Mendes, whose expertise and patience made a big contribution to my

knowledge and this thesis.

I also thank AMA, especially Eng. Maria Joao Marques, Fatima Oliveira and Helena Figueiredo, for all

their support and availability to help and for all the information they provided.

I also want to thank Camara Municipal de Almada, specially to Sandra Guerreiro and Isabel Sequeira,

for giving me the opportunity of performing a case study in Loja do Munıcipe, and for all their support

and availability to help me.

I want to thank all my friends who have always supported and encouraged me.

I want to thank Maria for all her endless patience and support, for enduring all the absent moments and

for cheering all the shared ones.

I want to thank all my family who always have been there for me and for all the encouragement and

motivation they have given me all my life. I want to specially thank my aunt Fatima for all her support

and help through this work.

Finally, i want to thank my parents, my mother Manuela and my father Joao, for all their support all my

life, for supporting all my studies and never stop believing in me, and for all the love they have always

given me. I owe everything to them, and for that, it is to them that I dedicate this work.

vii

placeholder

Acronyms

ADSE Direcao-Geral de Protecao Social aos Trabalhadores em Funcoes Publica

AM Action Model

AMA Agencia para a Modernizacao Administrativa

ATD Actor Transaction Diagram

BCT Bank Contents Table

BMS Balcao Multiservicos

CA Composition Axiom

CM Construction Model

DEMO Design & Engineering Methodology for Organizations

DM Distinction Axiom

DSRM Design Science Research Methodology

EA Enterprise Architecture

EAT Enterprise Activities Table

EE Enterprise Engineering

EO Enterprise Ontology

IA Information Architecture

IAM Interaction Model

IE Information Entity

IS Information System

ISM Interstriction Model

IT Information Technology

IUT Information Use Table

LDM Loja do Munıcipe

OCD Organization Construction Diagram

OFD Object Fact Diagram

OM Operation Axiom

OPL Object Property List

ix

OS Object System

PA Public Administration

PM Process Model

PSD Process Structure Diagram

TA Transaction Axiom

TRT Table Result Table

UML Unified Modeling Language

US Using System

WOSL World Ontology Specification Language

x

placeholder

placeholder

Contents

Abstract iii

Resumo v

Acknowledgements vii

Acronyms ix

1 Introduction 1

1.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Theoretical Background 7

2.1 Enterprise Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.2 The Process of Engineering a System . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.3 The Generic System Development Process . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Information Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.1 Definitions and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.2 Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Enterprise Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

xiii

2.4.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4.2 The Ψ Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4.3 The Organization Theorem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Related Work 23

3.1 Design and Engineering Methodology for Organizations (DEMO) . . . . . . . . . . . . . . 23

3.1.1 The DEMO Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1.2 World Ontology Specification Language (WOSL) . . . . . . . . . . . . . . . . . . . 25

3.1.3 The Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Public Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.1 Work Developed by AMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3 Other Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Proposal 31

4.1 Proposal Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 First Phase: Enterprise Activities Table (EAT) . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3 Second Phase: DEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.4 Third Phase: Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5 Demonstration 37

5.1 Loja do Cidadao - Balcao Multiservicos (BMS) . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.1 The Enterprise Activities Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1.2 The Constrution Model (Interaction Model) . . . . . . . . . . . . . . . . . . . . . . 40

5.1.3 The Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1.4 The Action Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1.5 The State Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.6 The Constrution Model (Interstriction Model) . . . . . . . . . . . . . . . . . . . . . 47

5.1.7 The Global State Model for BMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

xiv

5.2 Camara Municipal de Almada - Loja do Munıcipe (LDM) . . . . . . . . . . . . . . . . . . . 50




5.2.4 The Action Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2.5 The State Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54


5.3 Company X - Department of Information Systems . . . . . . . . . . . . . . . . . . . . . . . 57




5.3.4 The Action Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.3.5 The State Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64


5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6 Evaluation 69

6.1 Balcao Multiservicos (BMS) - Loja do Cidadao . . . . . . . . . . . . . . . . . . . . . . . . 71

6.2 Camara Municipal de Almada - Loja do Munıcipe . . . . . . . . . . . . . . . . . . . . . . . 73

6.3 Company X - Department of Information Systems . . . . . . . . . . . . . . . . . . . . . . . 75

6.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7 Lessons Learned 81

8 Conclusions 83

8.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Bibliography 85

Appendixes 88

A Case Study I: BMS 89

xv

A.1 The State Model for the remaining Institutions . . . . . . . . . . . . . . . . . . . . . . . . . 89

A.1.1 Automovel Club de Portugal (ACP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

A.1.2 Autoridade Regional de Saude (ARS) . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.1.3 Caixa Geral de Aposentacoes (CGA) . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.1.4 Centro Nacional de Pensoes (CNP) . . . . . . . . . . . . . . . . . . . . . . . . . . 91

A.1.5 Direcao-Geral do Consumidor (DGC) . . . . . . . . . . . . . . . . . . . . . . . . . 92

A.1.6 Eletricidade de Portugal (EDP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

A.1.7 Instituto da Mobilidade e dos Transportes Terrestres (IMTT) . . . . . . . . . . . . . 93

A.1.8 Instituto da Seguranca Social (ISS) . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

A.1.9 Portal do Cidadao (PC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

A.2 The Global OFD for BMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

B Case Study II: LDM 97

B.1 The Enterprise Activities Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

B.2 The OFD for LDM Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

C Case Study III: Company X 101

C.1 The Enterprise Activities Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

C.2 The OFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

C.3 The IUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

D IA developed by AMA 108

E WOSL Notation 109

xvi

placeholder

placeholder

List of Tables

4.1 The TRT for the pizzeria case study (second phase). . . . . . . . . . . . . . . . . . . . . . 35

5.2 The TRT for ADSE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.3 The OPL for ADSE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.4 The IUT for ADSE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.5 The BCT for ADSE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.6 The OPL for BMS case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.7 The TRT for LDM case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.8 The OPL for LDM case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.9 The IUT for LDM case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.10 The BCT for LDM case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.11 The TRT for Company X case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.12 The OPL for Company X case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.13 The BCT for Company X case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

A.14 The OPL for ACP services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

A.15 The OPL for ARS services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.16 The OPL for CGA services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

A.17 The OPL for CNP services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

A.18 The OPL for DGC services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

A.19 The OPL for EDP services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

A.20 The OPL for IMTT services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

A.21 The OPL for ISS services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

A.22 The OPL for PC services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

xix

C.23 The IUT for Company X case study (Part 1). . . . . . . . . . . . . . . . . . . . . . . . . . . 106

C.24 The IUT for Company X case study (Part 2). . . . . . . . . . . . . . . . . . . . . . . . . . . 107

xx

placeholder

placeholder

List of Figures

1.1 The DSRM process model (Peffers et al., 2007) . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 The roots of EE (Dietz & Hoogervorst, 2008) . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 The system design process (Dietz & Hoogervorst, 2008) . . . . . . . . . . . . . . . . . . . 9

2.4 The Process of Engineering a System (Dietz & Hoogervorst, 2008) . . . . . . . . . . . . . 10

2.5 The Generic System Development Process (Hoogervorst & Dietz, 2008) . . . . . . . . . . 11

2.6 EA diagram (Vasconcelos, 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.7 The OA (Dietz, 2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.8 The Basic Transaction Pattern (Dietz, 2006) . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.9 The Standard Transaction Pattern (Dietz, 2006) . . . . . . . . . . . . . . . . . . . . . . . . 17

2.10 The transaction pattern, according to the CA (Dietz, 2006) . . . . . . . . . . . . . . . . . . 18

2.11 Summary of the DA (Dietz, 2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.12 The process of performing a coordination act (Dietz, 2006) . . . . . . . . . . . . . . . . . 20

2.13 Representation of the organization theorem (Dietz, 2006) . . . . . . . . . . . . . . . . . . 20

3.14 The distinct aspect models of DEMO (Dietz, 2006) . . . . . . . . . . . . . . . . . . . . . . 24

3.15 The diagrams and tables of the aspect models of DEMO (Dietz, 2006) . . . . . . . . . . . 25

3.16 WOSL notation example for membership creation (Dietz, 2006) . . . . . . . . . . . . . . . 26

4.17 Proposal overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.18 DEMO’s first steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.19 Analysis and Synthesis adaptation to the EAT. . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.20 The EAT for the pizzeria case study (second phase). . . . . . . . . . . . . . . . . . . . . . 34

4.21 The ATD for the pizzeria case study (second phase). . . . . . . . . . . . . . . . . . . . . . 35

xxiii

5.22 The EAT for the services: Pedido do Cartao Europeu de Seguro de Doenca and Renovacao

do Cartao Europeu de Seguro de Doenca. . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.23 The EAT for the service: Pedido de Alteracao de NIB de beneficiarios ADSE. . . . . . . . 38

5.24 The EAT for the service: Pedido de Alteracao de Morada de beneficiarios ADSE. . . . . . 39

5.25 The EAT for the service: Pedido de 2ªVia do Cartao de Beneficiario da ADSE. . . . . . . 39

5.26 The EAT for the service: Rececao de Documentos de Despesas de Saude. . . . . . . . . 39

5.27 The EAT for the service: Emissao da Declaracao de IRS. . . . . . . . . . . . . . . . . . . 40

5.28 The EAT for the service: Consulta da Conta-Corrente do Beneficiario ADSE. . . . . . . . 40

5.29 The ATD for ADSE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.30 The PSD for ADSE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.31 The AM for ADSE (Part 1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.32 The AM for ADSE (Part 2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.33 The OFD for ADSE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.34 The OCD for ADSE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.35 The ATD for LDM case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.36 The PSD for LDM case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.37 The AM for LDM case study (Part 1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52



5.40 The OCD for LDM case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.41 The ATD for Company X case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.42 The PSD for Company X case study (Part 1). . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.43 The PSD for Company X case study (Part 2). . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.44 The AM for Company X case study (Part 1). . . . . . . . . . . . . . . . . . . . . . . . . . . 60





5.49 The OCD for Company X case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

xxiv

6.50 The data model quality factors (Moody & Shanks, 2003). . . . . . . . . . . . . . . . . . . . 70

6.51 The UML for BMS case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.52 BMS models evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.53 The UML for LDM case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.54 The quality factors evaluation for LDM’s models. . . . . . . . . . . . . . . . . . . . . . . . 74

6.55 The LDM’s models evaluation as an IA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.56 The UML for Company X case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.57 The quality factors evaluation for Company X’s models. . . . . . . . . . . . . . . . . . . . 77

6.58 The average evaluation for each quality factor. . . . . . . . . . . . . . . . . . . . . . . . . 77

6.59 The average evaluation for each quality factor (Disregarding the mentioned evaluation). . 78

6.60 The Company X’s models evaluation as an IA. . . . . . . . . . . . . . . . . . . . . . . . . 78

A.61 The OFD for ACP services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

A.62 The OFD for ARS services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.63 The OFD for CGA services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.64 The OFD for CNP services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

A.65 The OFD for DGC services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

A.66 The OFD for EDP services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

A.67 The OFD for IMTT services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

A.68 The OFD for ISS services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

A.69 The OFD for PC services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

A.70 The OFD for BMS case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

B.71 The EAT for the service: Pedido de Contrato de Fornecimento de Agua. . . . . . . . . . . 97

B.72 The EAT for the service: Pedido de Denuncia do Contrato de Agua. . . . . . . . . . . . . 97

B.73 The EAT for the service: Pedido de Entrada de Requerimento para Reducao de Tarifa de

Agua. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

B.74 The EAT for the service: Pedido de Pagamento de Factura da Agua. . . . . . . . . . . . . 98

B.75 The EAT for the service: Pedido de Pagamento de Renda. . . . . . . . . . . . . . . . . . . 98

B.76 The EAT for the service: Pedido de Refeicoes Escolares. . . . . . . . . . . . . . . . . . . 98

B.77 The EAT for the service: Pedido de Licenca de Utilizacao. . . . . . . . . . . . . . . . . . . 99

xxv

B.78 The EAT for the service: Pedido de Licenca de Publicidade ou Ocupacao do Espaco

Publico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

B.79 The OFD for LDM case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

C.80 The EAT for the service: Registar Marcacao. . . . . . . . . . . . . . . . . . . . . . . . . . 101

C.81 The EAT for the service: Actualizar Dados Marcacao. . . . . . . . . . . . . . . . . . . . . 101

C.82 The EAT for the service: Pesquisar Marcacao. . . . . . . . . . . . . . . . . . . . . . . . . . 101

C.83 The EAT for the service: Actualizar Estado de Marcacao. . . . . . . . . . . . . . . . . . . 102

C.84 The EAT for the service: Consultar Marcacao. . . . . . . . . . . . . . . . . . . . . . . . . . 102

C.85 The EAT for the service: Pesquisar Local de Atendimento. . . . . . . . . . . . . . . . . . . 102

C.86 The EAT for the service: Registar Local de Atendimento. . . . . . . . . . . . . . . . . . . . 102

C.87 The EAT for the service: Consultar Local de Atendimento. . . . . . . . . . . . . . . . . . . 102

C.88 The EAT for the service: Alterar Local de Atendimento. . . . . . . . . . . . . . . . . . . . . 103

C.89 The EAT for the service: Alterar Estado no Atendimento. . . . . . . . . . . . . . . . . . . . 103

C.90 The EAT for the service: Registar Utilizador. . . . . . . . . . . . . . . . . . . . . . . . . . . 103

C.91 The EAT for the service: Alterar Utilizador. . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

C.92 The EAT for the service: Pesquisar Utilizadores. . . . . . . . . . . . . . . . . . . . . . . . 103

C.93 The EAT for the service: Consultar Utilizadores. . . . . . . . . . . . . . . . . . . . . . . . . 104

C.94 The OFD for Company X case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

D.95 The Portuguese PA IA by AMA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

E.96 WOSL notation (Part 1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

E.97 WOSL notation (Part 2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

xxvi

Chapter 1

Introduction

The importance of Information Technology to support business in organizations is a given fact nowa-

days (Aerts et al., 2004). The alignment between business and IT and the alignment among the

various areas and architectures within IT are important and difficult challenges for organizations since

many of them do not manage their information well. Taking this into account, it is important to under-

stand the context of information within an organization. According to (Erlin et al., 2008) the reliability of

the information will greatly affect decision making and the organization itself. The importance of informa-

tion is a crucial factor within both the business and organizational design domain (Hoogervorst & Dietz,

2008).

The main motivation of this work relates with the impact and the importance of information for organiza-

tions and their business. Information plays a key role in organizations since it affects decision making,

as well as the costs of the organization (Erlin et al., 2008). Information also affects the quality of service

to the client, since is also very important when dealing with the client (Erlin et al., 2008).

So to better manage information, an information architecture (IA) is essential for collecting, analysing,

managing and sharing of information more effectively (Erlin et al., 2008). Taking this into account it

is easy to conclude that the main objective of IA is supporting business, and improving the alignment

between business and IT (Vasconcelos, 2007).

The goal of this work derives from these concerns, in the context of Public Administration (PA), since

PA is an aggregation of organizations and the management of their information is very important (AMA,

2011). Therefore, PA needs an IA in order to structure and manage its information. This work intents

to make an Enterprise Ontology (EO) approach to PA in order to achieve an IA. This means that this

work aims to address the concerns of developing an IA, in the context of PA, through an EO approach,

which is a new subject that analyses enterprises from a new and objective perspective focused on their

essence, rather than its actual appearance (Dietz & Hoogervorst, 2007).

1

1.1 Problem

In this section we define the problem this work approaches, and to do so, it is important to understand

that are several problems related to information and PA, and, as a result, there are several solutions

and proposals, inherent to this area. So, it is important to define the course of this work, based on the

research made from the related work, and that also reaches a problem that meets the needs of PA.

The main problem is that there is not a specialized methodology or framework designed to achieve an

IA. As (Watson, 2000) states, there is no organization or process for creating and sustaining an IA. There

are some approaches to IA, but the problem is that they are focused on specific contexts. Many of the

existing Enterprise Architecture (EA) frameworks approach the information layer, but do not focus and,

more importantly, do not specialise in IA. So, the main problem that we propose to resolve in this thesis

is:

The organization’s struggle to create an IA with a well defined methodology.

With this in mind and taking in consideration the importance of information for PA, the objective of this

work and what it proposes to achieve is a precise and efficient method to obtain an IA. The course cho-

sen to achieve this purpose is through the fields of EOs and its application with the Design & Engineering

Methodology for Organizations (DEMO)1 (Dietz, 2006). This new way of understanding enterprises and

their relations with their intervening actors, through transactions, was mainly researched and developed

by Professor Jan Dietz2 (Dietz, 2006). These fields approach enterprises from an ontological point of

view and seek to analyse and design them as a whole, but lack focus and specialization on the IA. So, if

the DEMO methodology was not conceived for the purpose of creating an IA, this leads us to the main

question of this work:

Can Enterprise Ontologies, with the application of DEMO methodology, be used in order to

achieve an Information Architecture?

This is a problem that has been addressed before from a different perspective. In Bernardo’s dissertation

(Gomes, 2011) this problem was approached from a different point of view, since he stated that in order

to achieve an IA it would be necessary to devise a DEMO based methodology and therefore DEMO is

not a methodology capable of creating an IA. In this thesis we state that an EO approach with a DEMO

methodology application is capable of creating an IA, which we validated and proved in the case studies

performed in this thesis.

Apart from this question, there are three more questions this thesis approaches, for the following rea-

sons:1For more information about DEMO methodology: http://http://www.demo.nl/2For more information about Professor Jan Dietz: http://www.st.ewi.tudelft.nl/˜dietz/

2

http://http://www.demo.nl/

http://www.st.ewi.tudelft.nl/~dietz/

• Can we define a more efficient alternative to the DEMO text approach?

• Is the State Model (SM), in the context of Portuguese PA, a well accepted IA representation model?

• And also, is SM a better accepted IA representation model than a more common and well known

representation model like the Unified Modeling Language (UML)?

Since the goal of this work is to achieve a method of achieving an IA for organizations, with special

attention to PA organizations, the DEMO text approach might be considered a problem in terms of an

efficient approach. Considering that obtaining all the necessary information to thoroughly make a busi-

ness description (DEMO text) is not always easy, specially for enterprises with a broad business scope,

we considered that the DEMO text can become a constraint to the application of DEMO methodology.

In the context of a big organization, or a group of several organizations, like the PA, there is a higher

probability of the DEMO text to be a constraint, since it may not be very efficient or flexible to create a

very thorough and detailed DEMO text for such a broad scope. Therefore, we proposed an alternative

approach to the creation of DEMO’s first model that aims at reducing the impact of that constraint. This

is an issue already approached in other works, namely, in (Ferreira, 2011) where the use of Business

Process Model and Notation (BPMN) as an input for DEMO methodology was proposed, but this im-

plies that the analysed organization must have its processes defined in BPMN models, which may not

be always true. So, we propose a more general alternative, which does not depend on any kind of

documentation the organization may or may not have.

Regarding the DEMO’s SM there is the concern that this model may not be a good representation

model as an IA, for the reason that DEMO methodology and World Ontology Specification Language

(WOSL) are not very well known concepts, specially in the Portuguese PA, and because of that it may

be difficult to understand these models (Huysmans et al., 2010). As stated in (Dietz & Habing, 2004) the

ontology concept is still a very new concept in the field of designing and engineering business systems

and Information Systems (IS), and DEMO is also still a very academically researched methodology. So,

there is the risk of this methodology and SM’s WOSL representation not being well accepted in the

Portuguese PA and, therefore, the need of assessing such risk.

1.2 Contributions

In this section we address the contributions this work aims to accomplish. Taking into account this thesis

main question the objective is to achieve an method of creating an IA for organizations using an EO

approach, with the application of DEMO methodology. The choice of an EO approach is due to its high

theoretical foundation and scientific acceptance (Dietz, 2006), and also DEMO is a high quality proven

methodology in the areas of Business Process Redesign and Organization Engineering (Van Reijswoud

3

& Van der Rijst, 1995) (Dumay et al., 2005) (Dietz, 1999). For these reasons and taking into account

this thesis main question, the main contributions of this thesis are:

• Assess that an EO approach with the application of DEMO methodology is a valid method for the

creation of an IA.

• Provide a simple, efficient and valid method for the creation of an IA, for the Portuguese PA.

In addiction to these contributions there are two more contributions inherent to the other two questions

addressed in this thesis.

• Provide a more efficient alternative for the DEMO text approach.

• Assess if the SM is a valid representation model for an IA, in the context of Portuguese PA.

So, to address this thesis questions and achieve the proposed contributions three case studies were

performed in three different Portuguese PA organizations. In order to assess the quality and validity of

the resulting IA for each case study, and also answer these questions, an evaluation process is needed.

So, we decided to evaluate our results mainly with the combination of the Moody and Shanks Framework

(Moody & Shanks, 2003) and the feedback of the stakeholders, through a qualitative questionnaire.

1.3 Research Methodology

In Section 1.3 we define the research methodology that was followed in this work. The purpose of

research, according to (Kothari, 2008), is to discover answers to questions through the application of

scientific procedures, and the purpose of research methodology is to do this in an systematically way

(Kothari, 2008). Taking this into account and also the fact that the purpose of this work is to evaluate

the validity of a DEMO model as an IA, we decided to follow a Design Science Research Methodol-

ogy (DSRM). According to (Hevner et al., 2004) an DSRM approach should create an innovative and

purposeful artifact, for a specific problem, and this artifact must be thoroughly evaluated so it can be

determined its utility to the problem. This methodology fits perfectly in this work, since we want to eval-

uate the DEMO model utility as an IA, for an organization, with special concern for the Portuguese PA.

According to (Peffers et al., 2007) the DSRM is composed by six steps, namely:

1. Problem identification and motivation: Define the specific research problem and justify the

value of a solution.

2. Define the objectives for a solution: Infer the objectives of a solution from the problem definition

and knowledge of what is possible and feasible. The objectives can be quantitative, such as terms

4

in which a desirable solution would be better than current ones, or qualitative, such as a description

of how a new artifact is expected to support solutions to problems.

3. Design and development: Create the artifact, which includes knowledge of theory that can be

brought to bear in a solution.

4. Demonstration Demonstrate the use of the artifact to solve one or more instances of the problem.

This could involve its use in experimentation, simulation, case study, proof, or other appropriate

activity. In this work the demonstration will be done with case studies.

5. Evaluation: Observe and measure how well the artifact supports a solution to the problem. In the

end of this step the researchers can decide if they want to iterate back to improve the quality of the

artifact or proceed to the next step.

6. Communication: Communicate the problem and its importance, the artifact, its utility and novelty,

the rigor of its design, and its effectiveness to researchers and other relevant audiences such as

practicing professionals, when appropriate.

The structure of this dissertation is aligned with the six phases of the DSRM, as defined in the next

section.

Figure 1.1: The DSRM process model (Peffers et al., 2007)

In this work the type of approach taken was a qualitative approach. On one hand, a quantitative approach

aims to follow an established plan, based on clearly defined hypotheses and variables, which will result in

an statistic data analysis (Neves, 1996). On the other hand, a qualitative approach is driven through the

course of the work development, and not measurable by events (Neves, 1996). This approach generally

implies the presence of the researcher in the field, and contact with the participants of the researched

context (Neves, 1996). So, this work took a qualitative approach, due to the following reasons:

• The need for the researcher in the field, due to the need of data collection.

• The need to take in consideration the perspective of the context’s participants.

• The impossibility to make statistic inferences about the produced results, due to the fact that the

scope of this work is limited to a reduced number of case studies.

5

1.4 Thesis Structure

The dissertation is divided in eight chapters, described as follows.

In Chapter 1 is provided a contextualization about the theme of this thesis and describes the problem

we propose to solve, concerning the creation of an IA. Corresponds to the DSRM’s steps ”Problem

identification and motivation” and ”Define the objectives for a solution”.

In Chapter 2 is described the theoretical background that supports this thesis work, which includes the

most important theoretical definitions for this work. Corresponds to part of the DSRM step ”Design and

development”.

In Chapter 3 the related work is addressed and taken into consideration. Corresponds to part of the

DSRM step ”Design and development” as well.

In Chapter 4 is presented the proposed solution to solve the identified problem, namely, the creation of

an IA. Corresponds to the final part of the DSRM step ”Design and development”.

Chapter 5 presents the results of the application of the proposed solution to three case studies. Corre-

sponds to the DSRM step ”Demonstration”.

In Chapter 6 is defined the evaluation process applied in this thesis and the case studies are assessed

according to that evaluation process. Corresponds to the DSRM step ”Evaluation”.

In Chapter 7 is made a retrospective analysis to understand and explain what have learned, based on

the obtained results. Corresponds to the final part of the DSRM step ”Evaluation”.

Finally, in Chapter 8 we present our conclusions. Corresponds to the DSRM step ”Communication”.

In Appendix A we present some of the results of the first case study, which could not be included in this

thesis main structure, due to space limitations.

In Appendix B we present some of the results of the second case study, which could not be included in

this thesis main structure, due to space limitations.

In Appendix C we present some of the results of the third case study, which could not be included in this

thesis main structure, due to space limitations.

In Appendix D we present AMA’s IA.

In Appendix E we present the WOSL notation.

6

Chapter 2

Theoretical Background

In Chapter 2 we approach the theoretical background of this thesis, i.e., the main theoretical notions

and definitions regarding this thesis so the reader can have a better understanding of the concepts

that are the bases of this work. We will give a brief overview of the concepts Enterprise Engineering

(EE) and Enterprise Architecture (EA), which are an important bases for the two main concepts of this

thesis. Next, we will address in more detail the two main concepts, namely, Information Architecture (IA)

and Enterprise Ontology (EO).

2.1 Enterprise Engineering

The current situation in organizational sciences greatly resembles the one that existed in IS sciences

around 1970 (Dietz & Hoogervorst, 2008). One problem that still remains is that traditional organizational

sciences fall short in assisting enterprises to adapt their strategies and to implement them effectively and

flexibly (Dietz, 2008). According to (Dietz & Hoogervorst, 2008), citing (Ackoff, 1999), the failing strategic

initiatives are due to the fact that the initiatives are fundamentally “anti-systemic”. This results in a failure

to derive success from strategy and the key reason for this strategic failure comes from the lack of

coherence and consistency, collectively also called congruence, among the various components of an

enterprise (Dietz & Hoogervorst, 2008). This is the result of a behavioural approach, black-box thinking,

whereas changing an enterprise requires an engineering approach, white-box thinking (Dietz, 2008).

So in order to achieve a change that allows avoiding these strategic failures, the way enterprises are

perceived has to change too. The needed new paradigm is that enterprises are purposefully designed

systems that consequently can be re-designed and re-engineered in a coherent and consistent way

whenever necessary (Dietz, 2008).

7

After people became aware of the distinction between the form and the content of information, a transi-

tion started from an era of data systems engineering to an era of IS engineering (Dietz & Hoogervorst,

2008). The new era of EE emerged from the need to articulate the concern for the intention of informa-

tion on top of its content, and develop the ontological view of the enterprise (Dietz, 2008). The roots of

EE and the relationships between form, content and intention are represented in Figure 2.2.

Figure 2.2: The roots of EE (Dietz & Hoogervorst, 2008)

The mission of EE referred to in (Dietz, 2008) is to combine relevant parts from the traditional organiza-

tional sciences and the IS sciences, and to develop emerging theories and associated methodologies for

the analysis, design, engineering, and implementation of future enterprises. To accomplish this mission

two essential elements are considered, namely EO and EA (Hoogervorst & Dietz, 2008). These two

notions are related to common design and engineering concepts in the Generic System Development

Process, approached later in this section.

2.1.1 System Design

Before approaching the topic of system design it is important to understand the definition of system.

There are many notions and points of view about system, but the one stated by (Dietz & Hoogervorst,

2008) is the most suited definition in the context of this work. So, (Dietz & Hoogervorst, 2008) states that

are two different system notions, namely the teleological system notion and the ontological system no-

tion. In this work we are interested in the ontological system notion, which is about the construction and

operation of a system, taking into account its behaviour, and therefore it is the dominant system notion

in all engineering sciences. According to (Dietz & Hoogervorst, 2008), for something to be considered a

system it must have the following properties:

• Composition: a set of elements of some category

• Environment: a set of elements of the same category. The composition and the environment are

disjoint.

• Structure: a set of interaction bonds among the elements in the composition and between these

and the elements in the environment.

8

• Production: the elements in the composition produce things (products or services) that are deliv-

ered to the elements in the environment.

The corresponding type of model, for the ontological system notion, is the white-box model, which is a

direct conceptualization of the ontological system definition (Dietz & Hoogervorst, 2008).

Figure 2.3: The system design process (Dietz & Hoogervorst, 2008)

Now that the definition of system is established, and bearing in mind that both referred notions are valid

when designing a system, the subject of design system is now addressed. According to (Op ’t Land

& Proper, 2007) in a development process several systems are involved. The system design process,

represent in Figure 2.3, is defined by (Dietz & Hoogervorst, 2008) in four steps, namely:

• The starting point is the need by some system, called the using system (US), of a supporting

system, called the object system (OS). This step consists in a white-box model of the US, due to

be the need of construction of the US.

• Then one determines the requirements for the OS in terms of the construction and operation of the

US (function design). This step consists in a black-box model of the OS, due to the requirements

being about the function and the behaviour of the OS.

• The next step is to devise specifications for the construction and operation of the OS, in terms of a

white-box model of the OS, i.e., the construction design.

• Finally a thorough analysis of this white-box model must guarantee that building the OS is feasible,

given the available technology.

The end result of a design process, the execution of the referred steps, is a balanced compromise

between (reasonable) requirements and (feasible) specifications (Dietz & Hoogervorst, 2008).

2.1.2 The Process of Engineering a System

The next step after executing the system design process at the ontological level, resulting in its construc-

tional specifications, is to execute the process of engineering a system. This means that is necessary to

further engineer through the detailed design, so that the system can be implemented (Dietz & Hooger-

vorst, 2008). In Figure 2.4 is represented the process of engineering a system. This process consists

9

basically on producing a coherent and consistent ordered set of white-box models of the system (Dietz

& Hoogervorst, 2008).

Figure 2.4: The Process of Engineering a System (Dietz & Hoogervorst, 2008)

According to (Dietz & Hoogervorst, 2008) the ’lowest’ model is the implementation model, which can

be implemented on the available technological platform, whilst the ’highest’ model is the ontological

model, which is fully independent of the implementation and only shows the essential features of the

system. Considering that a set of functional requirements regarding an OS is fully appropriate and

complete, (Dietz & Hoogervorst, 2008) refers that it may be desirable from the point of view of the en-

closing environment to impose additional functional requirements that do not conflict with the determined

requirements, but that would satisfy other goals of the enterprise.

2.1.3 The Generic System Development Process

As we will see in the next section the concept of architecture can be defined according to different points

of view, but in this context (Hoogervorst & Dietz, 2008) defines architecture as normative restriction

of design freedom, i.e., is considered a prescriptive concept, which means that architecture defines

how a system must become, rather than a descriptive concept that describes how a system is. Those

restrictions are intended to be a set of design principles, which application allows the satisfaction of one

or more requirements regarding both the design and engineering of a system (Dietz & Hoogervorst,

2008).

In line with the distinction between requirements and specifications, (Dietz & Hoogervorst, 2008) also

distinguishes between functional principles or function architecture, and constructional principles or con-

struction architecture. This distinction and the previous description of system design and engineering,

plus their relation with the concept of architecture, lead us to the Generic System Development Process

(GSDP), which is presented in Figure 2.5.

10

Figure 2.5: The Generic System Development Process (Hoogervorst & Dietz, 2008)

2.2 Enterprise Architecture

In order to approach and understand the concepts of EA and IA, first we must understand the concept

of architecture, in the context of business and IS. In (Dietz & Hoogervorst, 2008) it is suggested an

approach to the definition of architecture, where it is considered that architecture is related to design

principles. The suggested definition of architecture in (Dietz & Hoogervorst, 2008) is ”normative restric-

tion of design freedom”. This means that architecture is composed by set of design principles, divided

in functional and constructional principles, that should be defined in order to satisfy the requirements of

the given architecture.

According to (IEEE Computer Society, 2000), architecture is the fundamental organization of a system

embodied in its components, their relationships to each other and to the environment and the principles

guiding its design and evolution. This means that architecture gives us an organized and well modelled

view over business, IS, or other areas of an enterprise.

The concept of EA is another concept that can have different definitions and point of views, but ulti-

mately the EA must give us an overview of an enterprise and helps us understand its virtues and flaws.

According to (Pereira & Sousa, 2004) EA is a framework or a “blueprint” of how the organization will

achieve the current and future business objectives. This means that EA is composed by a group of

crucial architectures that model different aspects and areas of an enterprise, namely, IS architecture,

IA, technology architecture, etc. According to (Lankhorst, 2009) EA is a set of principles, methods and

models that define the enterprise’s organizational structure. It supports design and implementation of

business processes, IS and infrastructure.

In (Vasconcelos, 2007) EA is defined as a set of conceptual models built with the purpose of achieving

a coherent and comprehensive overview of the enterprise.

Figure 2.6 shows the relationship between EA and IA. IA supports the EA and business processes by

identifying and modeling all the information used and necessary in the business processes.

11

Figure 2.6: EA diagram (Vasconcelos, 2007)

2.3 Information Architecture

The concept of IA is one the most important concepts in this work, since its main goal is to achieve an IA

through an EO approach. IA can be considered an ambiguous concept, since there are different opinions

and definitions regarding it. As (Brancheau et al., 1989) once said, citing (Brancheau & Wetherbe, 1986),

one of the most obvious problems encountered in developing an IA is its broad scope. Therefore it is

important to analyse different points of view and make a clear definition of IA regarding this work. After

defining IA we will approach what should be it’s composition, taking into consideration the research

and the opinion of different important and relevant works, but the importance of the composition to the

context of the PA will also be considered.

2.3.1 Definitions and Objectives

The term ”Information Architecture” was firstly coined, according to (Dillon & Turnbull, 2005), by Richard

Wurman in 1975 to describe the need to transform data into meaningful information for people to use,

which was not entirely an original idea, but was certainly the first conjunction of the terms in the now

common IA label.

In (Kirikova, 2009) is referred that IA describes the structure of a system, i.e., the way information is

grouped and used within a system. It also distinguishes the IA in two parts the visible and the invisible. It

is a definition based on fractal IS and different modes of information processing (human brain, software,

hardware) which is not an interesting approach of IA as far as this work is concerned.

Dillon defined IA as ”the process of designing, implementing, and evaluating information spaces that are

humanly and socially acceptable to their intended stakeholders” (Dillon & Turnbull, 2005). Dillon related

the IA with human activities such as design or creative writing, which of necessity draw on disciplines to

support process and education, bypassing any reference to IA as a discipline or field of its own (Dillon &

Turnbull, 2005).

According to (Vasconcelos, 2007) IA has the objective of identifying and defining the most important

12

types of data that support the development of the organization’s business. The goal behind the IA is to

describe the different Information Entities (IE) necessary for the achieving of the business processes of

an organization. The main objectives of the IA are described in (Vasconcelos, 2007) as:

• Identifying the key information for the business.

• Defining the data independently of the applications or systems, where it will exist.

• Providing the basis for corporative data management.

2.3.2 Composition

Taking into account the theoretical background and definitions analysed and described previously it is

now essential to define what are the main components of the IA. In the context of this work, the IA

consists of informations entities, which are composed by attributes, and their relationships.

According to (Vasconcelos, 2007) and (Caetano & Vasconcelos, 2011) IEs encompass all concepts that

have meaning in the context of the business operation and on which is relevant (and possible) to store

information, e.g., person, material, location and even tangible or intangible objects. An IE is charac-

terized, at least, by the following notions, stated in (Vasconcelos, 2007) and (Caetano & Vasconcelos,

2011):

• A Name.

• A Unique Identifier, by which its occurrences (instances) are uniquely recognized in the organiza-

tion.

• Its Attributes.

• A Description.

• Its Relationships, with other entities.

2.4 Enterprise Ontology

In this section we will approach the concept of EO, which is the the main theoretical basis of the solution

proposed in this work. We will start by defining EO and then we will approach the Ψ theory, which can

be considered as the foundation of the EO concept. Finally we will analyse the organization theorem,

which states how the enterprise’s organization must be structured from an ontological point of view. This

theorem is an important theoretical foundation for the Ψ theory and EO.

13

2.4.1 Definition

Before establishing the definition of EO it is important to understand and set the definition of ontology.

The original Greek word from which the English word ”ontology” stems, means study or knowledge of

what is or exists (Dietz, 2006). Although the meaning of the word maybe consensual, the definition of

the concept ontology is not.

Gruber defined ontology has an ”explicit specification of a conceptualization” (Gruber, 1995). Gruber

also refers, in (Gruber, 1995), that when the knowledge of a domain is represented in a declarative

formalism, the set of objects that can be represented is called the universe of discourse, and the de-

scribable relationships among them, are reflected in representational vocabulary. This definition is too

strict and focuses mainly on identifying and describing a set of agents and their relationships within a

certain domain (Gruber, 1995).

According to (Dietz & Hoogervorst, 2008), in its modern use, ontology has preserved its original meaning

of dealing with the essence of something. Still, it has a definite practical goal, which is to provide a basis

for the common understanding of some area of interest among a community of people who may not

know each other at all, and who may have very different cultural backgrounds (Dietz & Hoogervorst,

2008).

Taking the previous definition of ontology in account, Dietz refers that the objective is to define the

concept of EO through a notion of ontology that includes the dynamic aspects of a system, and that at the

same time does justice to the nature of enterprises (Dietz, 2006). Dietz also defines enterprises as social

systems, and their operating principle consists of the ability of human beings to enter into and comply

with commitments (Dietz, 2006). This means, that the purpose is to understand the essence of the

construction and operation of complex systems, more specifically, of enterprises (Dietz & Hoogervorst,

2008).

2.4.2 The Ψ Theory

According to (Dietz, 2008) EO is founded on the Ψ-theory. It is a holistic and integrative theory, firmly

rooted in three other theories:

• Habermas’ Theory of Communicative Action.

• Bunge’s Systems Theory.

• Wittgenstein’s World Ontology.

As an holistic and integrative theory, the ontological model of an enterprise has to satisfy five quality

requirements (Dietz, 2008), which are:

14

• Coherent: It constitutes a whole.

• Consistent: It contains no logical contradictions.

• Complete: It includes all ontologically relevant elements.

• Concise: It is as minimal as possible.

• Essential: It is independent of realization and implementation.

According to (Albani et al., 2006) a business domain model that satisfies these requirements is called

an EO.

The Ψ theory is divided in four axioms (Dietz, 2006), the Operation Axiom (OA), the Transaction Axiom

(TA), the Composition Axiom (CA) and the Distinction Axiom (DA), that we are going to describe in the

following sections.

2.4.2.1 The Operation Axiom

According to (Dietz, 2006) the OA states that the operation of an enterprise is constituted by the activities

of actor roles, which are elementary chunks of authority and responsibility, fulfilled by subjects. Then,

the subjects perform two kinds of actions: production acts (P-acts) and coordination acts (C-acts) (Dietz,

2006), (Dietz & Hoogervorst, 2008). These acts are described in (Dietz, 2006), (Dietz & Hoogervorst,

2008) as:

• P-Acts: It represents a contribution of goods and/or services to the environment of the enterprise.

• C-Acts: It represents the commitment between subjects regarding the performance of P-acts.

These acts result into facts, namely production facts (P-facts) and coordination facts (C-facts), which are

the concrete result of a P-act and a C-act, respectively (Dietz, 2006).

From the distinction between P-acts and C-acts results another distinction in which each each of these

kinds of acts have effect, which is the production world (P-world) and coordination world (C-world) (Dietz,

2006). Then, the state of the P-world, at a particular point in time, is the set of P-facts that have

been created up to that point in time, and the same happens for C-world and C-facts (Dietz, 2006). In

Figure 2.7 is the graphical representation of the OA.

Figure 2.7: The OA (Dietz, 2006)

15

2.4.2.2 The Transaction Axiom

In this axiom is addressed the relation and the different patterns that exist between the P-acts and the

C-acts. This axiom states that coordination acts are performed as steps in universal patterns, also called

transactions, which involve two actor roles and are aimed at achieving a particular result (Dietz, 2006).

These transactions are divided into three sequential phases, namely the Order Phase (O-phase), the

execution phase (E-phase) and the result phase (R-phase), which involve two actor roles identified as

the initiator and executor of the transactions (Dietz, 2006). In (Dietz, 2006) these phases are described

as:

• O-phase: In this phase the initiator and the executor work to reach an agreement about the in-

tended result of the transaction, i.e., the P-fact, as well as the intended time of creation.

• E-phase: In this phase the executor creates the P-fact.

• R-phase: In this phase the initiator and the executor work to reach an agreement about the pro-

duced P-fact, as well as the actual time of creation. The P-fact only comes to existence if an

agreement is reached.

Figure 2.8: The Basic Transaction Pattern (Dietz, 2006)

The basic transaction pattern of this axiom, represented in Figure 2.8, presents the phases previously

described. This pattern is composed by four basic steps, namely request, promise, state and accept,

which are described in (Dietz, 2006) as:

• Request: It is the starting point of the transaction and represents the request and intentions of the

initiator towards the product/service and the executor.

• Promise: This step represents the agreement and commitment between the initiator and the ex-

ecutor towards the end result.

• State: This step represents the statement of the executor towards the initiator, regarding the fin-

ished product/service.

16

• Accept: Finally the initiator, presented with the end result, accepts it or in case of an unexpected

result he tries to reach an agreement with the executor in order to accept the result.

This pattern assumes that both the initiator and the executor keep consenting to each other’s acts (Dietz,

2006). In real life transactions both actors will not always consent to each other, so there is a need of

a more complete pattern that can predict this actions. Thus, arises the standard transaction pattern,

represented in Figure 2.9, that introduces four new steps, namely decline, quit, reject and stop, with the

purpose of making the transaction pattern more sustainable (Dietz, 2006).

Figure 2.9: The Standard Transaction Pattern (Dietz, 2006)

There are two states were the initiator and the executor may dissent, namely when they are trying

to reach an agreement, which is in the request and state. These new steps intend to resolve this

divergences, as described in (Dietz, 2006):

• Decline: After a request by the initiator, the executor has now two options, to promise or to decline

the request. This step has the purpose of allowing the executor to negotiate requests that he can

not accomplish.

• Quit: If the executor declines the initiator request, they try to reach an agreement towards the end

result. After negotiating if the initiator realizes that the executor will not be able to produce what he

wants, then he quits and ends the transaction.

• Reject: When the executor presents the end result to the initiator in the state step, the initiator has

the chance to reject this state if the promise made by the executor was not met.

• Stop: If the initiator rejects the executor state, they try to reach an agreement towards the end re-

sult. After negotiating if the executor realizes that the demands from the initiator are unreasonable

or he can not meet his demands, then he stops and ends the transaction.

17

2.4.2.3 The Composition Axiom

This axiom presents the different ways of how a transaction may be initiated. According to (Dietz, 2006)

a transaction may be initiated in two ways, it is self-activated or enclosed, which means that is activated

by another transaction, as shown in Figure 2.10. Figure 2.10 presents two transactions, T1 and T2, and it

is possible to see that T1 it is self-activated and T2 it is enclosed, i.e., is activated by T1. The transaction

T2 is dependent of T1, and the number of T2 instances is determined by T1. As (Dietz, 2006) refers

the CA is important when defining the business process concept, since a business process, normally, is

composed by many enclosed transactions.

Figure 2.10: The transaction pattern, according to the CA (Dietz, 2006)

2.4.2.4 The Distinction Axiom

The last axiom of the Ψ theory, the DA, addresses the different human abilities of how an actor can play

his role (Dietz, 2006). This different abilities are called performa, informa and forma and are represented

in Figure 2.11, and contextualized in the production and coordination worlds.

Figure 2.11: Summary of the DA (Dietz, 2006)

These abilities concern the way people communicate and exchange information, and each one is con-

sidered as a different level of communication and as different level of information management. These

abilities are described by (Dietz, 2006) as:

18

• Performa: This ability concerns the bringing about of new, original things, directly or indirectly by

communication. This means that in the coordination world it concerns the commitments between

actors, whereas in the production world it concerns the decisions and the judgements made by

the actors. It is considered by (Dietz, 2006) that performa is the essential human ability for doing

business of any kind.

• Informa: This ability concerns the content aspects of communication and information. This means

that in the coordination world it concerns the way actors interpret and formulate information,

whereas in the production world it concerns the way information is created, transformed, deduced,

reproduced, etc.

• Forma: This ability concerns the form aspects of communication and information. This means

that in the coordination world it concerns the way actors perceive and exchange the information,

whereas in the production world it concerns the way how information is physically managed, i.e.,

how data is stored, transmitted, copied, transmitted, etc.

As described before, the three abilities correspond to different kinds of communication acts, which lead

to the coordination act, and its implications related to the different acts (Dietz, 2006). First there is the

performative act that aims at achieving the social understanding, which corresponds to the intentions

and the commitment between actors in the coordination act, which is part of a performative exchange

between them (Dietz, 2006). For the actors to perform a performative act they need to express it through

an informative act. The informative act aims at achieving the intellectual understanding of the coordi-

nation act, which is part of a informative exchange between them. This means that both actors must

(intellectually) understand the content of the information they are exchanging, namely the thoughts they

are exchanging (Dietz, 2006). For each actor to understand the other one’s thoughts they must perform

a formative act. The formative act aims at achieving the significational understanding of the coordination

act, which means that both actors must use and understand the same language, whether spoken or sign

(language) (Dietz, 2006). In Figure 2.12 it is represented the process of performing a coordination act

and its implications in each act, previously described.

2.4.3 The Organization Theorem

With the Ψ theory and its four axioms described before, it is possible to understand the benefits they

provide in order to extract the essence of an organization from its actual appearance (Dietz, 2006). The

question now is how these benefits can be combined 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 ontological model of an enterprise (Dietz, 2006). The answer is the organization theorem,

which according to (Dietz, 2006) states that the organization of an enterprise is a heterogeneous system

19

Figure 2.12: The process of performing a coordination act (Dietz, 2006)

that is constituted as the layered integration of three homogeneous systems: the B-organization (from

Business), the I-organization (from Intellect), and the D-organization (from Document).

The organization theorem and these three systems are represented in Figure 2.13, where the relation-

ships between the systems are shown. The three systems are considered to be in the category of social

systems, which means that they are similar as far as the coordination is concerned, and only differ in the

production, as shown in Figure 2.13 (Dietz, 2006).

Figure 2.13: Representation of the organization theorem (Dietz, 2006)

According to (Dietz, 2006) the B-organization, as the ontological level of the enterprise, contains the

complete knowledge of its essence, which means that all the rest is realization and implementation.

Nevertheless an enterprise is more than just the integration of these three systems (Dietz, 2006). Human

beings are part of an enterprise, and they need a particular environment to live in, which means that they

have biological needs, and therefore some physical requirements and specific facilities are required to

met their needs (Dietz, 2006). Although important, this aspect that must be considered in an enterprise,

is not considered in this approach, since it is not directly related to the adopted notion of enterprise

(Dietz, 2006).

20

2.5 Summary

In this Chapter, we reviewed the main concepts of this thesis, namely, IA and EO and also the related

concepts of EE and EA.

As this work aims to improve the definition and creation of an IA for the Portuguese PA, it is important and

necessary to define what is an IA and what are its components. The concept of IA can be considered an

ambiguous concept, since there is not a general consensus regarding its definition. So, after analysing

different points of view and definitions for the IA, it was defined the IA definition adopted in this thesis

and its components. So taking into account the PA context, AMA’s IA and also taking into account

the theoretical background and definitions given by (Vasconcelos, 2007) and (Caetano & Vasconcelos,

2011), the IA, in the context of this work, should be composed by: IEs, Relationships, which must

describe the type of relationship between the IEs, and the IE’s Attributes.

The analysis of EO concept made us realise the real benefit of taking an EO approach. It is important

to realise that EOs are a new approach to analyse, (re)design and (re)engineer enterprises as a design

system, which results in several advantages. Dietz points out in (Dietz, 2006) that substantial changes

in organizations are accomplished generally with cheer luck, due to a lack of well-founded theory about

the operation of organizations, in most of the current approaches to (re)designing and (re)engineering

enterprises. Often even the most basic notions, like action, actor and process, are not clearly and

precisely defined (Dietz, 2006). This means that this changes often rely on unprecedented achievements

from the people who actually do the work. So this new approach of EOs aims at making a fresh start,

in (re)design and (re)engineer enterprise, by separating the stable ontological essence of an enterprise

from the variable way in which it is realised and implemented, and this way master the diversity and

complexity of enterprises (Dietz, 2006).

In order to achieve an IA it is essential to have a clear and precise knowledge of the enterprise and its

components, which is what EOs provide. So, this work pretends to apply the EOs approach to three

case studies, within a PA context, in order to achieve the IA for each case.

21

placeholder

Chapter 3

Related Work

In this Chapter we address the related work of this thesis. We start by analysing the DEMO method-

ology, which is the methodology used in this work to achieve an IA. Then, we will contextualize this

work with the Portuguese PA and the Agencia para a Modernizacao Administrativa (AMA), which is the

enterprise context of this work. Finally, we will address some previous works that are related to this

work.

3.1 Design and Engineering Methodology for Organizations (DEMO)

Dietz refers in (Dietz, 2001) that DEMO is a theory about the ‘construction’ and the ‘operation’ of or-

ganisations, that is rooted in the Communicative Action Paradigm regarding human communication and

action. This means that the ”working principle” of an organization consists in the interaction of human

beings and the commitments they make in their interactions, which they must comply (Dietz, 2001). The

authority, the responsibility and the competence, of the actors, play an essential role for the comply-

ing of these commitments. So, this is a methodology for modeling, (re)designing and (re)engineering

organizations (Dietz, 1999).

According to (Dietz & Hoogervorst, 2008) the DEMO methodology is based on the Ψ theory, and takes

into consideration the organization theorem. This methodology is composed by four distinct aspect

models, represented in Figure 3.14, which are the Construction Model (CM), the Process Model (PM),

the Action Model (AM) and the State Model (SM). These models correspond to diagrams, tables and

lists. The aggregation of these models, i.e., the whole diagram of Figure 3.14, constitutes the complete

ontological knowledge of an organization, and therefore corresponds to the B-organization layer of the

organization theorem, represented in Figure 2.13.

23

Figure 3.14: The distinct aspect models of DEMO (Dietz, 2006)

3.1.1 The DEMO Models

The Construction Model (CM). The CM specifies the construction of the organization, more specifically

and according to (Dietz, 2006), the CM of an organization specifies its composition, its environment, and

its structure. The composition and environment of the organization are considered to be both a set

of actor roles. The CM is composed by two other models, namely the interaction model (IAM), which

shows the active influences between actor roles, and the interstriction model (ISM), which shows the

passive influences between actor roles (Dietz, 2006). The IAM is composed by the Transaction Result

Table (TRT) and the Actor Transaction Diagram (ATD). The TRT identifies the transactions, and the

corresponding result for each transaction. The ATD represents the transactions and the participating

actors, and the relations between transactions and actors. The ISM is composed by the Actor Bank

Diagram (ABD) and the Bank Contents Table (BCT). The BCT identifies the production and coordination

banks, and the ABD inserts these banks into the ATD, which adding extra information links results in the

Organization Construction Diagram (OCD) (Dietz, 2006).

The Process Model (PM). The PM of an organization is, according to (Dietz, 2006), the specification of

the state space and the transition space of the C-world. This means that the PM specifies the transaction

pattern, described in Figure 2.9, for every transaction defined in the CM, and also the relations between

transactions, and the participating actors (Dietz, 2006). The PM is expressed by the Process Structure

Diagram (PSD) and the Information Use Table (IUT). The PSD specifies the process steps for each

transaction and the relations within composed transactions, and also the participating actors. The IUT

identifies the object classes, the fact types and the result types, and relate them with the process steps.

The Action Model (AM). The AM consists of a set of action rules, which serve as guidelines for an actor

(Dietz, 2006). So these rules serve to define the actions the actors should take, but sometimes the actor

might need to deviate from an action rule, and ultimately the responsibility, for his actions, its his (Dietz,

2006). According to (Dietz, 2006) the AM is the basis of the other aspect models since it contains all

information that is (also) contained in the CM, PM and SM.

24

Figure 3.15: The diagrams and tables of the aspect models of DEMO (Dietz, 2006)

The State Model (SM). According to (Dietz, 2006), the SM specifies the state space of the P-world: the

object classes and fact types, the result types, and the ontological coexistence rules, that are contained

in the AM. The SM may be viewed as the detailing of the contents of the information banks (coordination

and production banks), which are part of the CM. The SM is expressed by the Object Fact Diagram

(OFD) and the Object Property List (OPL). The OFD represents the object classes, identified in the PM

by the IUT, and their relations. The OPL lists the object classes and their respective properties. The

OFD is based on WOSL, which will be addressed in the next section.

These four models and their respective diagrams and tables are represented in Figure 3.15, and can

be viewed as a concretion of the understanding of an aspect of an organization presented in the four

main models that DEMO considers, for the purpose of communication, or as a result from interpreting

communicated diagrams and tables (Dietz, 2006).

3.1.2 World Ontology Specification Language (WOSL)

In the context of DEMO methodology the WOSL is the representation language that Professor Dietz

(Dietz, 2006) choose to model the SM. According to (Dietz, 2005) the goal behind WOSL is not only to

model the state space of a world, as the current ontology languages only do, but also its transition space.

According to (Dietz, 2006) although the grammar of WOSL could be fully expressed in modal logic, it

is more appropriate for the practical use of the language to apply a graphical notation. The semantic

basis as well as the diagrammatical notation of WOSL is adopted from the Object-Role Modeling (ORM)

notation (Dietz, 2005), formalized by Terry Halpin (Halpin, 2001). The WOSL’s notation is presented in

Appendix E.

Figure 3.16 shows the relation between two entities, Membership and Person, in WOSL notation. The

example shows a dependency law between the two entities, represented by the circle next to the mem-

bership square. This means that for every membership x there must be a person y such that member(x,y)

holds. The diamond connected to the membership entity represents a fact type. The fact type meaning

25

Figure 3.16: WOSL notation example for membership creation (Dietz, 2006)

is that a particular membership begins its operational existence at the moment of the creation of the fact

type ”membership X has been started”.

For further detailed and concise information about every specification and rule of the WOSL notation the

consultation of Professor Dietz’s book (Dietz, 2006) is required.

3.1.3 The Methodology

The process of operation of the DEMO methodology, in terms of producing the aspect models is anti-

clockwise, which starts with the IAM of the CM. In order to start the IAM it is necessary a list of identified

transactions and the participating actor roles, as well as the identification of the boundary of the enter-

prise. After the IAM, expressed by the ATD and the TRT, follows the PM, expressed by the PSD and

the IUT. Next is the AM, which is expressed in a pseudo-algorithmic language, followed by the SM, ex-

pressed in the OFD and the OPL. Finally the CM is finished with the ISM, composed by the ABD and

the BCT, which result in the OCD (Dietz, 2006).

According to (Dietz, 2006), the general elicitation method to acquire the basis for a correct and complete

set of aspect models of an EO consists of three analysis and three synthesis steps, which are described

in (Dietz, 2006) as:

• The Performa-Informa-Forma Analysis: All available pieces of knowledge are divided in three sets,

according to the DA, in section 2.4.2.4.

• The Coordination-Actors-Production Analysis: The Performa items are divided into C-acts/results,

P-acts/results, and actor roles, according to the OA, represented in Figure 2.7, in section 2.4.2.1.

• The Transaction Pattern Synthesis: The transaction pattern, according to the TA, is juxtaposed

over the results so far, in order to cluster them into transaction types. For every transaction type,

the result type is precisely formulated and the TRT is produced.

• The Result Structure Analysis: According to the CA, in section 2.4.2.3, every transaction type of

which an actor in the environment is the initiator may be conceived as delivering and end result to

26

the environment. Generally, the executor of this transaction is initiator of one or more other trans-

action types, and so on. The results of these cascade transactions can be viewed as components

of the end result.

• The Construction Synthesis: For every transaction type, the initiating actor role(s) and the execut-

ing actor role are identified, based on the TA, addressed in section 2.4.2.2. This is the first step in

producing the ATD.

• The Organization Synthesis: A definite choice has to be made as to what part of the construction

will be taken as the organization to be studied and what part will become its environment. The

ATD can now be finalized.

In this work we propose an alternative to the traditional process for this method to acquire the aspect

models of an EO, as explained in chapter 4.

3.2 Public Administration

The concept of PA is not easy to define, since its composition is not clear. According to (DGAEP, 2013)

PA is a vast and complex reality that can be perceived in two ways, namely in an organic sense and ma-

terial sense. In an organic sense, PA as referred to in (DGAEP, 2013) is formed by a system of organs,

services and state agents, and also by other public entities, which aim at the regular and continuous sat-

isfaction of the collective needs. In this sense, it is possible to distinguish three major groups of entities,

in PA, namely: direct state administration; indirect state administration; and autonomous administration

(DGAEP, 2013). In a material sense, (DGAEP, 2013) refers that PA is the very activity developed by

those organs, services and agents.

Therefore it is now necessary to analyse the correlation between PA, i.e., the enterprise context of this

work, and the objectives and purposes of this work, taking into account the PA perspective defined

above. This work is in the enterprise context of AMA and its goal of improving the IA of the Portuguese

PA. On one hand, AMA is considered to be part of the indirect state administration, in an organic sense

perspective. On the other hand, the IA, which is the main subject of this work, is supposed to support all

PA, serving as reference architecture.

3.2.1 Work Developed by AMA

The concept of IA has been analysed and developed by AMA, in the context of PA. AMA has even been

developing an IA for the PA, with special focus on the fields of identification, relationships and attendance

(AMA, 2011).

27

According to AMA their IA reflects the informational entities necessary for the identification and imple-

mentation of the registration of cases and contacts in the process of providing services to people and

organizations, aiming to register and query interactions (contact event) and requests (cases) (AMA,

2011). It is an IA that covers all organizations within the PA, and intends to be simple and generic, so it

can serve as basis to the definition of IA, for each organization (AMA, 2011).

So, the main objective of AMA for this IA is for all the PA entities to use the same informational language,

enabling an easier and more accessible change of information between those entities (AMA, 2011). This

aims at simplifying and facilitating the exchange of information by PA entities, which can be difficult with

a divergent informational language, specially since such exchange of information is very common (AMA,

2011).

The IA developed by AMA is presented in Appendix D, and it was extracted from (AMA, 2011), where its

IEs, attributes and relations are described in more detail.

3.3 Other Works

This subsection analyses and describes two previous works that are related to this work and the im-

provement of IA, in the context of the Portuguese PA.

The first work we analyse is the work from Ricardo Castelao in his dissertation for his Masters Degree.

Ricardo’s thesis, entitled ”An Information Architecture for the Public Administration” (Castelao, 2010),

was also a work for AMA. His work focused on improving AMA’s IA by developing a new IA based on the

Enterprise Architecture Planing (EAP) methodology, with two case studies (Castelao, 2010). His work

with the applied methodology identified a set of missing attributes in AMA’s IA.

The second work we analyse is the one performed by Bernardo Gomes in his dissertation for his Masters

Degree. The work performed by Bernardo was also in AMA’s context. His thesis, entitled ”Information

Architecture and Enterprise Ontologies” (Gomes, 2011), focused on developing an methodology, based

on EOs, specialised in modeling the IA. The methodology developed by Bernardo consisted in three

steps based on a combination of the DEMO methodology with the work of Terry Halpin (Halpin, 2001),

which consisted in the mapping from Object-Role Modeling (ORM) to Unified Modeling Language (UML).

Bernardo then applied his methodology to the service Balcao ’Perdi a Carteira’1 of the PA organism

called Loja do Cidadao2.

1Information about Balcao ’Perdi a Carteira’ in: http://www.portaldocidadao.pt/PORTAL/entidades/PCM/AMA/pt/SER_balcao++perdi+a+carteira.htm?flist=s

2Information about Loja do Cidadao in: http://www.portaldocidadao.pt/portal/pt/lojacidadao/

28

http://www.portaldocidadao.pt/PORTAL/entidades/PCM/AMA/pt/SER_balcao++perdi+a+carteira.htm?flist=s

http://www.portaldocidadao.pt/PORTAL/entidades/PCM/AMA/pt/SER_balcao++perdi+a+carteira.htm?flist=s

http://www.portaldocidadao.pt/portal/pt/lojacidadao/

3.4 Summary

After analysing the DEMO methodology, it is important to understand its benefits. The DEMO method-

ology follows an EO approach, which means this methodology ensures five qualities in a conceptual

model of an enterprise, namely coherent, consistent, complete, concise, essential Dietz (2006). A co-

herent modeling of an enterprise means the conceptualization of the enterprise must constitute logical

and truly integral whole. Therefore this whole must be complete, consistent and concise, which means

that all relevant issues are covered, there is no logical contradictions or irregularities, and the whole must

be compact and succinct, which means that can not contain superfluous matter Dietz (2006). Finally

the modeling of an enterprise must be essential, which means that must only show the essence of the

enterprise, its deep structure Dietz (2006).

It is important to understand how these benefits can be an advantage to the development of the IA. First

the DEMO methodology models are objective, since they do not depend on who is modeling. DEMO

models are also complete and consistent, which means that all irrelevant information is not considered,

and only the essential information is presented Dietz (2006). This is a major advantage from DEMO,

because it will allow an objective analysis of the organizations, and represent them in a more realistic

way, without irrelevant and superfluous information. This might result in a objective and essential IA, due

to the focus of DEMO models in the core and essential information of the organization.

The main objective of AMA is to accomplish an IA that can serve as basis for all IAs in the PA, and so

they have identified what they have considered to be the most important and essential IEs and defined

their relationships. So, by validating DEMO as a valid methodology to develop an IA, this work intents

to improve the IA developed by AMA by providing a valid methodology for AMA to develop the IA for the

several different PA organizations and therefore create a database of IA which will enable the creation

of an IA of reference that would improve the information management within the Portuguese PA.

Analysing the previous works we can see that Bernardo Gomes’s work is strictly related to this one,

since approaches the same problem. This work intentions started to be the validation of Bernardo’s

work, i.e., applying his methodology to different contexts, making some case studies, and then validate

the methodology. After some consideration about Bernardo’s work, this work changed its intentions

towards the solution. The problem remains, as how can we develop an IA for an organization, and

the EO approach remains as well, but the solution proposed in this work differs from the methodology

proposed by Bernardo in a way that this work states that DEMO methodology is capable of developing

an IA, through the representation of the SM.

29

placeholder

Chapter 4

Proposal

In this Chapter we present our proposal of solution to the problem described in Chapter 1. Consid-

ering the choice of an EO approach to the problem, we propose a solution based on the DEMO

methodology to create an IA. We decided for an EO approach, with the DEMO methodology application,

due to two main reasons.

First, the EO theory is focused only on the ontological layer, which is focused in the essential part of an

enterprise, i.e, its business layer, seeing that the ontology of an enterprise is independent of its organi-

zational structure, its implementation and its changes (Dietz, 2006). This means that DEMO models are

very stable and only change when the ontology of an enterprise changes (Dietz, 2006). Therefore, EO

focuses exclusively on the business essence of an enterprise, disregarding its implementation (Dietz,

2006), which suits well in the creation of an IA, which should focus in the business essential information.

Secondly, EO and DEMO are both highly regarded as a theory and a methodology, respectively, in

an academic sense, and the proof of that are the numerous publications made since (Dietz, 1990),

one of Professor Dietz’s earliest research publications, which lead to the development of the DEMO

methodology (Dumay et al., 2005). Furthermore, DEMO is a high quality proven methodology in the

areas of Business Process Redesign and Organization Engineering (Van Reijswoud & Van der Rijst,

1995) (Dumay et al., 2005) (Dietz, 1999), which makes it a very suitable option for defining the IA of an

organization.

4.1 Proposal Overview

Our proposal can be divided in three main phases, which are addressed in the following sections. The

first phase is a proposed alternative approach to the DEMO text, the second phase is the application of

the DEMO methodology and lastly the third phase is an extra step in the validation process so we have

31

a better understanding of the SM quality as an IA.

So, this thesis proposal is to assess the validity of using the DEMO methodology as a method to create

an IA and therefore this methodology is the proposed solution for this thesis main problem. However, to

answer two other questions raised by this thesis, there was a change in the traditional input used in the

DEMO methodology and an extra step in the validation process. So, in an traditional DEMO approach

the input would be a DEMO text, but in this thesis we propose an alternative to this artifact, due to issues

already covered in section 1.1. After applying the DEMO methodology and in the validation process we

create an UML version of the resulting SM and use it to assess the SM’s level of acceptance by the

evaluating stakeholders. In Figure 4.17 is represented the proposal overview.

Figure 4.17: Proposal overview

4.2 First Phase: Enterprise Activities Table (EAT)

The traditional first steps of DEMO methodology consist in three analysis steps and three synthesis

steps, described in more detail in Chapter 3, applied after the construction of a DEMO text, which is a

detailed business description of the enterprise or the analysed context. Figure 4.18 depicts those first

steps, which culminate in the first model of the CM, the IAM.

Since this is a very extensive and quite time consuming process we decided to propose an alternative

process to reach the IAM. The major difference between the presented DEMO methodology and our

adapted proposal is the elimination of the DEMO text and in its place the creation of what we decided

to call Enterprise Activities Table (EAT). The EAT is, as the DEMO text, the business description of the

enterprise, structured in a different way. The objective behind this concept is to gather all the essential

business information, by identifying all the business services and processes, and then identify all the

activities performed in those services and processes. We then adapted the three analysis and three

synthesis steps to the EATs in order to construct the IAM.

So, we started by applying an adaptation of the Performa-Informa-Forma Analysis, the Coordination-

Actors-Production Analysis, the Transaction Pattern Synthesis and the Construction Synthesis, as de-

scribed in Figure 4.19. The goal is to organize, structure and gather the information in the EAT in an

32

Figure 4.18: DEMO’s first steps

Figure 4.19: Analysis and Synthesis adaptation to the EAT.

efficient way, but at the same time the EAT must have the necessary information to perform the adapted

analysis and synthesis. The goal in each adapted step of the EAT is to:

• The Performa-Informa-Forma Analysis: Identify if the activity is an ontological, infological or data-

logical act, according to the DA, in section 2.4.2.4.

• The Coordination-Actors-Production Analysis: Identify the intervening actors for each activity, tak-

ing into account the Performa-Informa-Forma Analysis and what is produced in the activity.

• The Transaction Pattern Synthesis: Identify the transaction and the transaction type to which each

activity belong.

• The Construction Synthesis: Identify the roles for the intervening actors in each activity.

33

After analysing all six steps we structured the EAT so that we could create the ATD with the same quality

and accuracy as if we were doing it with the normal process of the DEMO methodology. So, we decided

to apply the EAT to the pizzeria case study (second phase) to find out if we would reach to the same

transactions and a equal or similar ATD as if we would adopt the traditional method. In Figure 4.20 is

represented the complete EAT for the pizzeria case study, with the four adapted steps.

Figure 4.20: The EAT for the pizzeria case study (second phase).

With the complete EAT we have the necessary information to create the TRT and the ATD, as we will

see in the next section.

4.3 Second Phase: DEMO

In this phase, after creating the TRT and the ATD with the new EAT approach, we continue the creation

of the other DEMO models following the DEMO Methodology as defined in (Dietz, 2006). But before

that, in the IAM phase, while creating the TRT an the ATD there are two more steps executed along with

these two models, namely:

• The Result Structure Analysis: Identify the dependencies between transactions, according to the

CA, in section 2.4.2.3.

34

• The Organization Synthesis: Identify the boundaries between which belongs to the organization

and which belongs to the environment that interacts with the analysed organization, i.e., identify

the organization’s actor’s responsibility area.

The Result Structure Analysis eventually has no impact on the completion of the ATD, but is very impor-

tant for the creation of the PM, since we need to know the dependencies between transactions in order

to create the PM. On the other hand, the Organization Synthesis gives us the final information needed

to complete the ATD, seeing that is crucial to know which actors and transactions belong to the organi-

zation, and which external actors interact with the analysed organization and the transactions between

them and the organization. So, with that in mind and with the EAT presented in the previous section we

created the ATD and TRT, for the pizzeria case. As we can see the transactions defined in the ATD and

in the TRT are identified in the EAT’s ”Preposition (result)” column. The actors defined in the ATD are

identified in the EAT’s ”Initiator” and ”Executor” columns. The ATD is presented in Figure 4.21 and the

TRT is presented in Table 4.1

Figure 4.21: The ATD for the pizzeria case study (second phase).

Transaction Types Result Types

T01 - Completion R01 - purchase P has been completed

T02 - Preparation R02 - purchase P has been prepared

T03 - Payment R03 - purchase P has been paid

T04 - Delivery R04 - purchase P has been deliveredTable 4.1: The TRT for the pizzeria case study (second phase).

35

With the conclusion of the first phase of the CM, the construction of the following DEMO models resume

as defined by Professor Dietz in (Dietz, 2006). In the end of the DEMO methodology we will have defined

the SM, represented by the OFD and the OPL, which we state that represents the necessary information

for the IA of the analysed case study. So, from here we step to the validation phase.

4.4 Third Phase: Validation

We called Validation to the third phase of our proposal, because in the validation process of our work we

address two problems regarding the DEMO models. First, each of the DEMO models have a particular

and specific language, particularly, in the state model the WOSL, limited to the theories and DEMO

methodology developed by Professor Dietz, presented in (Dietz, 2006). Therefore, it may be difficult for

someone that does not know or has studied the DEMO methodology and its theoretical background to

understand these models (Huysmans et al., 2010), and more importantly the state model. This adds to

the fact that DEMO methodology is not a very well known or used methodology, attending the Portuguese

PA context, which can result in the inability of the case studies collaborators to understand the DEMO

models or accept them as good representation for their IA.

For these reasons we decided to validate not just the DEMO models and the state model, but also

transform the state model to a different, more popular and well known language. This way we can

evaluate the gap between the two models, and understand if the state model as a final result is an

adequate and understandable IA or if the final results presented in a different language are a more

suitable presentation of the IA. In conclusion this step is an assessment of the SM’s acceptance level,

in the PA context, and also assess the level of acceptance in comparison with a more common and well

known representation model as UML.

36

Chapter 5

Demonstration

In Chapter 5 we pretend to demonstrate how the DEMO methodology is a valid tool for the creation

of a IA, by applying this methodology for three different case studies. Therefore, in this chapter we

present all the necessary steps to achieve an IA, from the EATs and through the DEMO methodology,

which culminates in the results and the outputs that ultimately result in the IA for each case study,

namely, the SM for each case study. These results will be evaluated in the next chapter.

5.1 Loja do Cidadao - Balcao Multiservicos (BMS)

This case study is based in Loja do Cidadao’s service, named Balcao Multiservicos (BMS), which has

the objective of gathering several services of public and private institutions, provided to citizens, in one

single attending point. It works as a front end intermediate between the citizen and the institutions for

certain services. Since all this services are provided and focused on the citizen, all the information in

BMS is focused on the citizen. Therefore, the purpose of this case study is to create the IA of the BMS,

valid for all the services of all institutions. So, in order to gather the necessary information we started by

interviewing Helena Figueiredo and Fatima Cavaleiro, which are both responsible for BMS’s operations,

in AMA. In the next sections we will describe every step taken from the interviews until the IA.

Since this will be the first case study that we will address, we are going to give a more thorough approach

and analysis to the methodology and its necessary information to understand the outputs generated

in each model. In the following case studies we will adopt a more direct approach, focusing on the

presentation of the results.

Considering that BMS provides many services for several different institutions we decided to analyse

the services of each institution separately, so we could have a better focus in each institution, and in

the end merge the state model of each case. Also, by separating the methodology’s application for

37

each institution we can produce DEMO’s models one-hundred percent accurate for each case, instead

of producing a general model for all cases. We believe this benefited greatly the validation of the models

for each case.

Although this case study resulted in several outputs for each institution and due to space limitations,

we will only present the results for the ADSE (Direcao-Geral de Protecao Social aos Trabalhadores em

Funcoes Publica). In Appendix A we present the resulting OFD and OPL for the other institutions.

5.1.1 The Enterprise Activities Tables

So, with the information acquired in the interviews we started by constructing de EATs. As described in

chapter 4 the EAT resumes the Performa-Informa-Forma Analysis, the Coordination-Actors-Production

Analysis, the Transaction Pattern Synthesis and the Construction Synthesis, which represent the first

steps towards the ATD. So, the resulting EATs for each service of ADSE case can be analysed in the

following figures.

Figure 5.22: The EAT for the services: Pedido do Cartao Europeu de Seguro de Doenca and Renovacaodo Cartao Europeu de Seguro de Doenca.

Figure 5.23: The EAT for the service: Pedido de Alteracao de NIB de beneficiarios ADSE.

38

Figure 5.24: The EAT for the service: Pedido de Alteracao de Morada de beneficiarios ADSE.

Figure 5.25: The EAT for the service: Pedido de 2ªVia do Cartao de Beneficiario da ADSE.

Figure 5.26: The EAT for the service: Rececao de Documentos de Despesas de Saude.

39

Figure 5.27: The EAT for the service: Emissao da Declaracao de IRS.

Figure 5.28: The EAT for the service: Consulta da Conta-Corrente do Beneficiario ADSE.

5.1.2 The Constrution Model (Interaction Model)

With the EATs completed we have the necessary information and analysis to create the TRT an the ATD.

The TRT consists in transactions types and their respective result types identified from the analysis of

the EAT. So, after analysing all the EATs we reached to the following TRT, presented in Table 5.2.


T01 - Registration R01 - registration R has been done

T02 - Perform Service R02 - service S has been started

T03 - Deliver Receipts R03 - receipts RC have been collected

T04 - Payment R04 - service S has been paid

T05 - Documents Management R05 - the management for documents D has been done

T06 - Deliver Documents R06 - documents D have been deliveredTable 5.2: The TRT for ADSE.

The ATD consists mainly in the identification of the transactions and the actors that perform these trans-

actions. While creating the ATD there are two more steps that are made along with it, namely the Result

Structure Analysis and the Organization Synthesis. Although the Result Structure Analysis has no im-

pact in the ATD’s creation, the Organization Synthesis is essential as we can see in the ADSE case,

40

where we have to identify what belongs to the BMS organization and what belongs to the environment

that interacts with BMS, which means identifying the responsibility areas of the actors that belong to the

BMS organization. So, the ATD for the ADSE case is presented in Figure 5.29.

Figure 5.29: The ATD for ADSE.

The grey square, with BMS on the top side, is the responsibility area for the BMS internal actors. The

greyish boxes (Citizen, Registered Citizen and ADSE) represent external actors that interact with the

scope of our organization, delimited within the grey square. The reddish boxes (Recorder, Service

Executer, Manager) represent the actors that belong to the organization. The circles with diamonds

inside (Registration, Perform Service, Deliver Receipts, Payment, Documents Management and Deliver

Documents) are the identified transactions for the ADSE case study. Each transaction has a initiator and

a executer which are identified by the connections between the transaction and the actor. The executer

has a diamond in the end of the connection along the actor box.

5.1.3 The Process Model

After achieving the TRT and the ATD for the CM we start to define the PM by creating the IUT and

the PSD. The PM consists in the specification of the transaction patterns for the transactions identified

in the CM. Here is where the Transaction Pattern Synthesis steps in because we need to know the

dependencies between transactions in order to conclude the transaction patterns for those transactions.

41

In the PSD its identified the process steps for each transaction and the relations within composed trans-

actions. So, with the Transaction Pattern Synthesis and with the results obtained in the CM we reached

to the PSD presented in Figure 5.30.

Figure 5.30: The PSD for ADSE.

Analysing more deeply the PSD, there are two types of relations between process steps, namely:

• Casual Relation: Its represented by the solid lines and means that one action causes another

action, i.e, the execution of one process step causes the execution of another process step.

• Conditional Relation: Its represented by the dashed lines and means that one action is conditioned

by another, i.e., the execution of one process step is conditioned by the completion of another

process step.

These relationships depend on the minimum and maximum (X..Y) number of occurrences defined. So,

we can conclude that transaction Registration has no causal or conditional dependencies with other

transactions. The transaction Perform Service may trigger the transactions Deliver Receipts or Payment.

In the event of this transaction triggering one or both transactions, the completion of Perform Service

is conditioned by the completion of the other transactions. The transaction Documents Management is

self-activated internally, which means that is initiated by the same actor that executes the transaction.

This transaction may trigger an undefined number of occurrences of the transaction Deliver Documents,

and its completion is conditioned by the completion of the triggered transactions.

Although the IUT is part of the PM, its creation depends on information obtained in the SM, i.e., in the

IUT we take the object classes, fact types and result types from the SM and specify in which process

steps they are used. Despite belonging to the PM we will present the IUT in the SM section 5.1.5, so it

can be more understandable.

42

5.1.4 The Action Model

The AM of an organization consists of a set of action rules, i.e., the AM defines the possible actions

an actor can make in each step of the PM, and the rules that define those actions. In the end the

actions are made by people and people can break the rules, so the AM can not guarantee that the actor

complies with the established rules and ultimately the actor must be responsible for the choice of his

own actions. The definition of the rules for each process step, of each internal actor, must be considered

by the analysis of all the gathered information about the case study.

The AM defines the organization’s rules in a pseudo-algorithmic language, which uses three important

clauses for its purpose, namely:

• on clause: every action rule is enclosed by an on-no bracket pair, which specifies the possible

actions that can be made in that action rule.

• if clause: this conditional clause is used when an actor can make more than one choice. For every

possible choice the condition that must be met for the actor to chose that action is defined. Every

condition is followed by the symbol ”≥”, followed by the respective action. For each action rule that

has a conditional clause its conditions are enclosed by an if-fi bracket pair.

• do clause: this clause is used for repeated actions that are enclosed by an do-od bracket pair.

It is important to understand that we only define the action rules for the process steps of the internal

actors that belong to the organization. Sometimes in an action rule it is necessary to specify a rule in

an informal way and for those cases the informal expressions are inserted between the meta-brackets

<and >.

So, with all these definitions in mind and all the information gathered so far and created in CM and PM

the AM for the ADSE case was created as follows, in Figures 5.31 and 5.32.

43

Figure 5.31: The AM for ADSE (Part 1).

44

Figure 5.32: The AM for ADSE (Part 2).

5.1.5 The State Model

The SM consists in the specification of the object classes, the fact types and the result types, as well

as the relationships between them. The SM is represented by the OFD and the OPL, which can be

interpreted as the representation of the object classes, the fact types, the result types and the relations

between them, in the OFD case, an the object classes properties, in the OPL case. As addressed in

chapter 3, the OFD is based on the WOSL language. So, the ADSE’s resulting OFD is presented in

Figure 5.33.

Figure 5.33: The OFD for ADSE.

45

Property Type Object Class Scale

NIB CITIZEN NUMBER

NIF CITIZEN NUMBER

NISS CITIZEN NUMBER

payment value SERVICE EURO

type DOCUMENTS CATEGORYTable 5.3: The OPL for ADSE.

The internal object classes derive from the transaction’s result types and the external classes derive

from the inputs and outputs of the transactions. The fact types must be analysed from each transaction.

In the ADSE case, we can see there are four core object classes that are created within the ADSE,

namely, REGISTRATION, SERVICE, RECEIPT and DOCUMENTS. These four object classes relate

to five external object classes, namely, CITIZEN, CITIZEN CARD, ADSE CARD, ENTITY and COM-

PROVATIVO. The fact types, which may be interpreted as relationships between the object classes, are

represented by the rectangle divided in the middle, and with the identification ”F**”, which as a descrip-

tion of the relationship between the object classes. These fact types normally have a dash above one

of the rectangle’s square, which represent the SM’s unicity law. If we consider the fact type F05, what

the SM’s unicity law states is that one object class COMPROVATIVO must always have one, and only

one, SERVICE object class associated, but the opposite is not true. In the fact type F01 where there is a

dash above both squares the unicity law states that one CITIZEN must always have one, and only one,

CITIZEN CARD and vice-versa. The SM’s dependency law is identified by a circle next to the object

class, which in the ADSE case, happens with the REGISTRATION object class, which means the object

class REGISTRATION depends on the CITIZEN, and a REGISTRATION instance cannot exist without

a CITIZEN associated to it. Finally, the squares with diamonds within them represent the transactions

result type, identified in the TRT, and in the OFD we identify to which object class each result type is

associated. Each internal object class must have always at least one result type associated, otherwise

its not an object class created within the analysed organization.

The OPL created for the ADSE case is presented in Table 5.3, which basically represents the identified

properties for each object class.

In conclusion, as stated in section 5.1.3, after creating and defining the OFD and the OPL the PM’s IUT

can be now defined. So, in Table 5.4 is presented the IUT for the ADSE case. The objective of the IUT

is to identify for each process step of the PM the object classes, fact type and result types belong.

46

object class, fact type, or result type process steps

B-R01 Registration R has been done T01/ex

B-R02 Service S has been started T02/ex

B-R03 Receipts R have been collected T03/ex

B-R04 Service S has been paid T04/ex

B-R05 The management for documents D has been done T05/ex

B-R06 Documents D have been delivered T06/ex

CITIZEN T01/rq

REGISTRATION T01/rq T02/rq

CITIZEN CARD T01/rq

SERVICE T02/rq

DOCUMENTS T05/rq T06/rq

RECEIPTS T03/rq

COMPROVATIVO T02/ex

ADSE CARD T01/pm

ENTITY T01/pm

F01 the identification of [citizen] is [citizen card] T02/pm

F02 the registered citizen in [registration] is [citizen] T02/pm

F03 the citizen registration of [service] is [registration] T03/ex

F04 the receipts of [service] are [receipts] T02/pm T02/st

F05 the [comprovativo] is the proof of [service] completion T01/rq

F06 the [service] needs or generates [documents] T01/pm

F07 the [citizen] needs the insurance identification [adse card] T06/rq

F08 the [documents] are delivered to [entity] T06/pmTable 5.4: The IUT for ADSE.

5.1.6 The Constrution Model (Interstriction Model)

Finally, with the conclusion of the PM, the AM and the SM we can finish the CM by completing the

ISM, which consists of the BCT and the OCD. The BCT consists of the identification of the production

banks for each object class, fact type and result type. A production bank contains the production facts

produced in transactions, and the production banks represent the information that each actor needs in

an certain transaction. So, the BCT for the ADSE case is presented in Table 5.5.

47

object class, fact type, or result type P-bank

B-R01 Registration [R] has been done B-PB01 - Production facts B-T01

B-R02 Service [S] has been started B-PB02 - Production facts B-T02

B-R03 Receipts [R] have been collected B-PB03 - Production facts B-T03

B-R04 Service [S] has been paid B-PB04 - Production facts B-T04

B-R06 Documents [D] have been delivered B-PB06 - Production facts B-T06

B-R05 The management for documents [D] has been done B-PB05 - Production facts B-T05

CITIZEN APB01 - Personal Data

REGISTRATION B-PB01 - Production facts B-T01

CITIZEN CARD APB01 - Personal Data

SERVICE B-PB02 - Production facts B-T02

DOCUMENTS B-PB06 - Production facts B-T06

RECEIPTS B-PB03 - Production facts B-T03

COMPROVATIVO APB02 - Service Data

ADSE CARD APB01 - Personal Data

ENTITY APB02 - Service Data

F01 the identification of [citizen] is [citizen card] B-PB01 - Production facts B-T01

F02 the registered citizen in [registration] is [citizen] B-PB01 - Production facts B-T01

F03 the citizen registration of [service] is [registration] B-PB02 - Production facts B-T02

F04 the receipts of [service] are [receipts] B-PB03 - Production facts B-T03

F05 the [comprovativo] is the proof of [service] completion B-PB02 - Production facts B-T02

F06 the [service] needs or generates [documents] B-PB05 - Production facts B-T05

F07 the [citizen] needs the insurance identification [adse card] B-PB01 - Production facts B-T01

F08 the [documents] are delivered to [entity] B-PB06 - Production facts B-T06Table 5.5: The BCT for ADSE.

The OCD basically consists in the identification of the production banks in the ATD model, as represented

in Figure 5.34. The production banks are represented as diamonds outside the BMS’s responsibility

area.

48

Figure 5.34: The OCD for ADSE.

5.1.7 The Global State Model for BMS


NIB CITIZEN NUMBER

NIF CITIZEN NUMBER

NISS CITIZEN NUMBER


type DOCUMENTS CATEGORY

photo FORM BOOLEANTable 5.6: The OPL for BMS case study.

As we stated in the beginning of section 5.1, the approach to the BMS case study was to analyse

and address each institution present in the BMS’s services separately. So, after completing the DEMO

methodology for all institutes we merged all the resulting OFDs and OPLs. The global OFD for the BMS

49

case study is presented in Figure A.70, which is in Appendix A.2. In Table 5.6 is presented the global

OPL for the BMS case study.

5.2 Camara Municipal de Almada - Loja do Munıcipe (LDM)

In this section we present the case study based on the services provided by Loja do Munıcipe (LDM),

which functions as a service desk of Camara Municipal de Almada for the citizens of this city council. The

LDM works like and has the same goal as the BMS, acting as a front end intermediate between the citi-

zen and the Camara Municipal de Almada and other public organizations, which have services provided

by LDM. Due to the numerous services provided by LDM we decided to include only a few services, but

at least one from each main type of service provided (General Administration and Finance, Sanitation,

Education and Urbanism). In order to gather all the necessary information we started by interviewing

Isabel Sequeira which is responsible for LDM’s operations and also interviewed a few employees who

perform the services to the citizens in the LDM.

As stated in section 5.1, in the following sections of this case study we will focus more in the presentation

of the results instead of analysing and describing them.

Figure 5.35: The ATD for LDM case study.

50


After performing the interviews and gathering all the necessary information we created the EATs. Due

to space reasons LDM’s EATs are presented in Appendix B.1.


So, with the completion of the EATs we can now present the TRT and the ATD, the first part of the CM,

i.e., the IAM. The TRT and the ATD for this case study are presented in Table 5.7 and Figure 5.35,

respectively.


T01 - Perform Service R01 - service S has been started

T02 - Deliver Ticket R02 - ticket T has been delivered

T03 - Fill Form R03 - form F has been filled

T04 - Install Contador R04 - contador C has been installed

T05 - Remove Contador R05 - contador C has been removed

T06 - Payment R06 - service S has been paid

T07 - Validate Form R07 - form F has been validated

T08 - Deliver Form R08 - form F has been delivered

T09 - Deliver Oficio R09 - oficio O has been deliveredTable 5.7: The TRT for LDM case study.


As we stated before, in section 5.1.3, with the completion of the CM’s first part we can now define the

PM and its models, the PSD and the IUT. However the IUT can only be completely concluded after

concluding the SM, so we will present the IUT in the end of section 5.2.5. Nevertheless, the PSD can

be now constructed and is presented in Figure 5.36.

51

Figure 5.36: The PSD for LDM case study.


Figure 5.37: The AM for LDM case study (Part 1).

The AM model for this case study was defined as follows, in Figures 5.37, 5.38 and 5.39.

52


53



So, with the completion of CM’s first part, the PM and the AM we can finally create SM’s models,

namely, the OFD and the OPL which are presented as follows in Figure B.79, which is in Appendix B.2,

and Table 5.8, respectively.


NIB CITIZEN CARD NUMBER

NIF CITIZEN CARD NUMBER

water supply doc SERVICE BOOLEAN


publicity doc SERVICE BOOLEANTable 5.8: The OPL for LDM case study.

As stated in section 5.2.3, with the completion of the SM and its models we can now present, in Table 5.9,

the completed IUT model of the PM.

54


B-R01 Service S has been started T01/ex

B-R03 Form F has been filled T03/ex

B-R02 Ticket T has been delivered T02/ex

B-R04 Contador C has been installed T04/ex

B-R05 Contador C has been removed T05/ex

B-R06 Service S has been paid T06/ex

B-R07 Form F has been validated T07/ex

B-R08 Form F has been delivered T08/ex

B-R09 Oficio O has been delivered T09/ex

SERVICE T01/rq

CITIZEN T01/rq

CITIZEN CARD T01/rq

TICKET T02/rq

FORM T03/rq T07/rq T08/rq

CONTADOR T04/rq T05/rq

OFICIO T09/rq

F01 the identification of [citizen] is [citizen card] T01/pm

F02 the [citizen] requests the [service] T01/rq

F03 the ticket in [service] is [ticket] T02/pm

F04 the form of [service] is [form] T03/pm

COMPROVATIVO T01/ex

F06 the [service] may generate a [oficio] T09/pm

F07 the [comprovativo] is the proof of [service] completion T01/pm

ENTITY T04/rq T05/rq T08/rq

F08 the [form] is delivered to the [entity] T08/pm

F05 the [entity] changes the [contador] T04/pm T05/pmTable 5.9: The IUT for LDM case study.


With the completion of the PM, the AM and the SM, we can, finally, present the ISM’s BCT and OCD in

Table 5.10 and Figure 5.40, respectively.

55


B-R01 Service [S] has been started B-PB01 - Production facts B-T01

B-R02 Ticket [T] has been delivered B-PB02 - Production facts B-T02

B-R03 Form [F] has been filled B-PB03 - Production facts B-T03

B-R04 Contador [C] has been installed B-PB04 - Production facts B-T04

B-R05 Contador [C] has been removed B-PB05 - Production facts B-T05

B-R06 Service [S] has been paid B-PB06 - Production facts B-T06

B-R07 Form [F] has been validated B-PB07 - Production facts B-T07

B-R08 Form [F] has been delivered B-PB08 - Production facts B-T08

B-R09 Oficio [O] has been delivered B-PB09 - Production facts B-T09

SERVICE B-PB01 - Production facts B-T01

CITIZEN APB01 - Personal Data

CITIZEN CARD APB01 - Personal Data

TICKET B-PB02 - Production facts B-T02

FORM B-PB03 - Production facts B-T03

CONTADOR B-PB04 - Production facts B-T04

OFICIO B-PB09 - Production facts B-T09

COMPROVATIVO APB01 - Personal Data

ENTITY APB01 - Personal Data

F01 the identification of [citizen] is [citizen card] B-PB01 - Production facts B-T01

F02 the [citizen] requests the [service] B-PB01 - Production facts B-T01

F03 the ticket in [service] is [ticket] B-PB02 - Production facts B-T02

F04 the form of [service] is [form] B-PB03 - Production facts B-T03

F05 the [entity] changes the [contador] B-PB04 - Production facts B-T04

F06 the [service] may generate a [oficio] B-PB09 - Production facts B-T09

F07 the [comprovativo] is the proof of [service] completion B-PB01 - Production facts B-T01

F08 the [form] is delivered to the [entity] B-PB08 - Production facts B-T08Table 5.10: The BCT for LDM case study.

56

Figure 5.40: The OCD for LDM case study.

5.3 Company X - Department of Information Systems

Our last case study was performed in the department of IS of a Portuguese public organization (we shall

call it Company X). The goal of this case study is to create the IA for a new application that is being

developed in this department with the objective of allowing the Portuguese citizens to make on-line

appointments in the several different attending points of this organization, scattered all over the country.

We shall call this application VMP.


After performing the interviews and gathering all the necessary information we created the EATs. Due

to space reasons Company X’s EATs are presented in Appendix C.1.


So, with the completion of the EATs we can now present the TRT and the ATD, the first part of the

CM, i.e., the IAM. The TRT and the ATD for this case study is presented in Table 5.11 and Figure 5.41,

57

respectively.

Figure 5.41: The ATD for Company X case study.

58


T01 - Register Appointment R01 - Appointment A has been registered

T02 - Update Appointment Data R02 - Appointment A has been updated

T03 - Find Appointment R03 - Appointment A has been found

T04 - Update Appointment State R04 - Appointment A state has been updated

T05 - Consult Appointment R05 - Appointment A has been consulted

T06 - Register Attending Point R06 - Attending Point AP has been registered

T07 - Create Schedule R07 - Schedule S has been created

T08 - Create Reservation R08 - Reservation R has been created

T09 - Find Attending Point R09 - Attending Point AP has been found

T10 - Consult Attending Point R10 - Attending Point AP has been consulted

T11 - Change Attending Point R11 - Attending Point AP has been changed

T12 - Change Attending Point State R12 - Attending Point AP state has been changed

T13 - Register User R13 - User U has been registered

T14 - Change User R14 - User U has been changed

T15 - Find Users R15 - User U has been found

T16 - Consult Users R16 - User U has been consultedTable 5.11: The TRT for Company X case study.


So, we can now present this case study PM and its PSD in Figures 5.42 and 5.43.

Figure 5.42: The PSD for Company X case study (Part 1).

59

Figure 5.43: The PSD for Company X case study (Part 2).

The IUT will be presented in section 5.3.5, for reasons stated in the previous case studies.


The AM model for this case study was defined as follows, in Figures 5.44, 5.45, 5.46, 5.47 and 5.48.

Figure 5.44: The AM for Company X case study (Part 1).

60


61


62


63



So, with the completion of CM’s first part, the PM and the AM we can finally create SM’s models,

namely, the OFD and the OPL which are presented as follows in Figure C.94, which is in Appendix C.2,

and Table 5.12, respectively.


NISS USER NUMBER

user information USER CATEGORY

appointment contact information APPOINTMENT CATEGORY

date APPOINTMENT JULIAN DATE

appointment state APPOINTMENT STATE

district ATTENDING POINT CATEGORY

county ATTENDING POINT CATEGORY

attendingpoint state ATTENDING POINT STATE

reservation schedule RESERVATION DATETable 5.12: The OPL for Company X case study.

As stated in section 5.3.3, with the completion of the SM and its models we can now present, in Ta-

bles C.23 and C.24, the completed IUT model of the PM, which is in Appendix C.3.


With the completion of the PM, the AM and the SM we can finally present the ISM’s BCT and OCD in

Table 5.13 and Figure 5.49, respectively.

64


B-R01 Appointment [A] has been registered B-PB01 - Production facts B-T01

B-R02 Appointment [A] has been updated B-PB02 - Production facts B-T02

B-R03 Appointment [A] has been found B-PB03 - Production facts B-T03

B-R04 Appointment [A] state has been updated B-PB04 - Production facts B-T04

B-R05 Appointment [A] has been consulted B-PB05 - Production facts B-T05

B-R06 Attending Point [AP] has been registered B-PB06 - Production facts B-T06

B-R07 Schedule [S] has been created B-PB07 - Production facts B-T07

B-R08 Reservation [R] has been created B-PB08 - Production facts B-T08

B-R09 Attending Point [AP] has been found B-PB09 - Production facts B-T09

B-R10 Attending Point [AP] has been consulted B-PB10 - Production facts B-T10

B-R11 Attending Point [AP] has been changed B-PB11 - Production facts B-T11

B-R12 Attending Point [AP] state has been changed B-PB12 - Production facts B-T12

B-R13 User [U] has been registered B-PB13 - Production facts B-T13

B-R14 User [U] has been changed B-PB14 - Production facts B-T14

B-R15 User [U] has been found B-PB15 - Production facts B-T15

B-R16 User [U] has been consulted B-PB16 - Production facts B-T16

APPOINTMENT B-PB01 - Production facts B-T01

ATTENDING POINT B-PB06 - Production facts B-T06

USER B-PB13 - Production facts B-T13

RESERVATION B-PB08 - Production facts B-T08

SCHEDULE B-PB07 - Production facts B-T07

ADMINISTRATOR APB01 - SS Data

INTERNAL USER APB01 - SS Data

DOCUMENTS APB01 - SS Data

THEME APB02 - Theme List

F01 the [appointment] is made by the [user] B-PB01 - Production facts B-T01

F02 the [administrator] gives permissions to the [user] B-PB14 - Production facts B-T14

F03 the [appointment] has an [attending point] B-PB01 - Production facts B-T01

F04 the [attending point] is managed by the [internal user] B-PB11 - Production facts B-T11

F05 the [attending point] has a [schedule] B-PB06 - Production facts B-T06

F06 the [attending point] has a [reservation] B-PB06 - Production facts B-T06

F07 the documents of [theme] are [documents] B-PB01 - Production facts B-T01

F08 the theme of [reservation] is [theme] B-PB08 - Production facts B-T08

F09 the [attending point] has [theme] B-PB06 - Production facts B-T06

F10 the theme of [appointment] is [theme] B-PB01 - Production facts B-T01

65

Table 5.13: The BCT for Company X case study.

Figure 5.49: The OCD for Company X case study.

66

5.4 Summary

In this Chapter we applied the proposal, presented in Chapter 4, to three different case studies. After

the interviews and having gathered all the relevant information we created the EATs for each case study.

With the EATs completion we had the necessary information to create DEMO’s first model the IAM,

which is composed by the ATD and the TRT. We then applied the DEMO methodology and create the

four models, CM, PM, AM and SM, for each case study. In the BMS case study we divided its analysis

and DEMO application for each institution that BMS supports, so in section 5.1.7, we present the SM for

the entire BMS. After achieving the SM for each case study we can now assess its quality as an IA.

67

placeholder

Chapter 6

Evaluation

In this Chapter we present the evaluation process used to validate our thesis proposal, namely, prove

that DEMO methodology can be used to create an IA. For this evaluation process we used three

tools, namely, Xemod 20101, the Moody & Shanks Framework and the feedback from the stakeholders

of each case study.

The Xemod 2010 application is a software developed by an enterprise called MPRISE and this software

was created exclusively to make DEMO models. Thus, making Xemod the perfect solution to develop

the DEMO models of our case studies, seeing that is only focused on DEMO models and only allows

to produce models that meet and respect the methodology developed by Professor Jan Dietz. Never-

theless, the biggest advantage of this application is its validating feature that verify the consistency and

correctness between the models, ensuring that DEMO methodology theories and rules are met for the

verified project. Therefore, taking into account that we used this application and its validation feature in

our three case studies, we can safely say that our models are correct and consistent between them, and

also respect DEMO methodology’s theories and rules.

The second step of our evaluation process is inspired in the Moody & Shanks Framework (Moody &

Shanks, 2003), which defines quality factors for a data model. In the data model quality management

framework (Moody & Shanks, 2003) defined the quality factors that are decisive factors for a model

evaluation are the ones in Figure 6.50. The assessment of these quality factors in the case study

models will be done by the respective stakeholders.

1For more information about Xemod 2010 application: http://www.mprise.eu/default.aspx?id=104

69

http://www.mprise.eu/default.aspx?id=104

Figure 6.50: The data model quality factors (Moody & Shanks, 2003).

The objective or purpose of each quality is (Moody & Shanks, 2003):

1. Completeness: refers to whether the data model contains all user requirements.

2. Simplicity: means that the data model contains the minimum possible entities and relationships.

3. Flexibility: is defined as the ease with which the data model can cope with business and/or

regulatory change.

4. Integration: is defined as the consistency of the data model with the rest of the organization’s

data.

5. Understandability: is defined as the ease with which the concepts and structures in the data

model can be understood.

6. Implementability: is defined as the ease with which the data model can be implemented within

the time, budget and technology constraints of the project.

All these quality factors were applied in the evaluation process of this thesis, except the last one. The

implementability factor was not considered in this work because it implies that stakeholders know finan-

cial and technological information about the organization, which they do not no, and therefore, are not

qualified to evaluate this factor.

Finally, the third evaluation step used in this thesis was the feedback of the stakeholders of each case

study. As stated by (Sargent, 2005), there are several validation techniques that can be used in model

verification and validation. Taking into account the work in this thesis and the type of models resulting

from the DEMO methodology, we decided that the most appropriate validation technique would be what

Robert Sargent calls Face Validity (Sargent, 2005). This technique consists of asking the individuals that

have the knowledge about the system whether the model and/or its behaviour are reasonable (Sargent,

2005). The data model quality management framework developed by (Moody & Shanks, 2003) also

states that the design of effective systems depends on the participation and satisfaction of all relevant

stakeholders in the design process.

70

In order to have a better understanding of the results and a better understanding of the SM quality as an

IA we confronted the stakeholders with both the SM and a conversion of the SM to an UML modulation,

as stated in section 4.4. Furthermore, in the evaluation process the assessment of the quality factors

and the feedback from the stakeholders will be done together through a questionnaire. Therefore, this

questionnaire consists in six questions to the stakeholders, which they had to answer for each presented

solution (SM and UML model). The questions in the questionnaire are:

1. How complete do you believe the model is?

2. How simple do you believe the model is?

3. How flexible do you believe the model is?

4. How righteous do you believe the model is?

5. How understandable do you believe the model is?

6. Do you think the model represents the IA of the analysed case study?

In the beginning of the questionnaires we made a brief explanation about the purpose of the case study

and told what were the definitions of IA and IEs, so stakeholders could make a better evaluation of

question six. The definition of IA presented in the questionnaire was: ”IA is a model that represents

the business’s essential information, through the identification of key business informational entities and

their relationships. This model is the basis for creation of the data models, for the given business.”

The definition of IEs presented in the questionnaire was: ”The IEs consist of business components that

aggregate and store the business’s essential information.”

6.1 Balcao Multiservicos (BMS) - Loja do Cidadao

The models presented to BMS’s stakeholders were Figure A.70, which is in Appendix A.2, and Table 5.6,

which is in section 5.1.7, for the SM and Figure 6.51 for the UML model.

71

Figure 6.51: The UML for BMS case study.

So, we presented both this models to the stakeholders and asked them to answer the mentioned ques-

tions, for each model, from ”1” to ”10” where ”1” means the model is completely misaligned with reality

and ”10” means the model represents the reality perfectly. Unfortunately in this case study we only got

one stakeholder to evaluate it and his evaluation is presented in Figure 6.52.

Figure 6.52: BMS models evaluation.

As we can see in the evaluation, the SM was considered, in an overall perspective, as a better repre-

sentation of the BMS. Even the evaluation of the question ”Do you think the model represents the IA of

the analysed case study?” stated that SM is a more appropriate IA for BMS, with an evaluation of ”10”,

in opposition to the ”9” evaluation of the UML.

72

So, in the BMS case study we can see that SM was very well accepted, even though not being a known

model by the stakeholders. It was even considered to be more simple and more understandable than

UML model, as well as a better IA representation of the BMS.

6.2 Camara Municipal de Almada - Loja do Munıcipe

In the LDM’s case study we had the evaluation of five stakeholders. The models presented to LDM’s

stakeholders were Figure B.79, which is in Appendix B.2, and Table 5.8, which is in section 5.2.5, for the

SM and Figure 6.53, for the UML model.

Figure 6.53: The UML for LDM case study.

So, the stakeholder’s evaluation for the five quality factors, regarding the analysed models, is presented

in Figure 6.54. Furthermore, the stakeholder’s evaluation of the question ”Do you think the model repre-

sents the IA of the analysed case study?” is presented in Figure 6.55.

73

Figure 6.54: The quality factors evaluation for LDM’s models.

Analysing the stakeholder’s evaluation of the models, concerning the five quality factors, we realize that

SM was considered to be a more complete, flexible and righteous model unlike the UML model that

was considered a more simple and understandable, which was the concern behind this evaluation step

and the reason why we decided to make the comparison between the two representations. Although

the difference was higher in the understandability factor, with an average evaluation of 9,8 for UML and

8,0 for SM, we believe that this is not a big gap that would discourage the use of the SM. We also

believe that this gap would be shortened if the stakeholders had a short formation or explanation about

the WOSL language and the SM. The difference in the simplicity factor is considerable less, with an

average evaluation of 9,0 for UML and 8,4 for SM, and is a probable result of the incorporation of two

SM’s entities on other entities, in the UML model.

74

Figure 6.55: The LDM’s models evaluation as an IA.

Considering the question ”Do you think the model represents the IA of the analysed case study?” the

SM was considered to be a better IA, with an average evaluation of 9,2 against an average evaluation

of 9,0 for the UML. We believe this is a direct result of a better evaluation of the completeness and

integration quality factors, which maybe due to a more rich and detailed information in the SM.

6.3 Company X - Department of Information Systems

In the Company X’s case study we counted with the evaluation of three stakeholders. The models

presented to Company X’s stakeholders were Figure C.94, which is in Appendix C.2, and Table 5.12,

which is in section 5.3.5, for the SM and Figure 6.56, for the UML model.

So, the stakeholder’s evaluation for the five quality factors, regarding the presented models, is presented

in Figure 6.57. Furthermore, the stakeholder’s evaluation regarding the models as an IA is presented in

Figure 6.60.

75

Figure 6.56: The UML for Company X case study.

76

Figure 6.57: The quality factors evaluation for Company X’s models.

After receiving and analysing the evaluation results we noticed that one of the evaluations was very

particular because one of the stakeholders evaluated the SM with ”2” for all the quality factors and

evaluated the UML with ”5” for all the quality factors as well. Since this was a very particular and

divergent evaluation we decided to inquire our contact in Company X if there was any particular reason

for that evaluation. It was told us that there was not any particular reason for that evaluation, just

that not everyone knows the DEMO methodology and therefore the presented models may not be of

easy interpretation. So, with this evaluation we can see, in Figure 6.58, the comparison of the average

evaluation, for each quality factor, between the two models. In this comparison we can see that UML

model had a better evaluation in the five quality factors, specially in understandability and simplicity.

Although UML model had a better evaluation the SM is not far behind, and both had a fairly positive

evaluation.

Figure 6.58: The average evaluation for each quality factor.

These were the Company X’s evaluation results, however if we were to disregard the mentioned particu-

lar evaluation we would see a significant difference in the comparison of the average evaluation between

the two models, as showed in Figure 6.59. If we would consider these results the overall evaluation would

reverse with a better evaluation to the SM, specially in the completeness and integration quality factors.

Understandability would be the only quality factor that UML still would have a slight better evaluation.

77

Figure 6.59: The average evaluation for each quality factor (Disregarding the mentioned evaluation).

Regarding the models assessment as an IA the same situation occurs. The SM model was evaluated

with an average of 5,67 and the UML model with an average of 6,33. However if we would disregard the

particular evaluation we would have an average evaluation of 7,5 for the SM and an average of 7,0 for

the UML.

Figure 6.60: The Company X’s models evaluation as an IA.

6.4 Summary

In this chapter we presented the case studies evaluation. The evaluation process was based on the

combination of the Moody and Shanks Framework with the feedback from the stakeholders. It was also

used the modulation application called Xemod 2010, which guaranteed the correctness and consistency

of the DEMO models.

The results were in general positive, specially in the first two case studies, where they were better

accepted with very good evaluations. Most of the stakeholders understood the models and accepted

78

them as a valid IA for the respective case studies.

79

placeholder

Chapter 7

Lessons Learned

In this Chapter we analyse the lessons learned in this work. After concluding the work and the appli-

cation of our proposal in the three case studies, we can now understand and see how EO and DEMO

really focus on the business essence. With the layering of the enterprise into three layers: Ontological,

Infological and Datalogical, and focusing on the ontological layer it is possible to see in the analysis and

the results the abstraction from the implementability of the business. This is clearly one of the main

advantages of this methodology and one of the reasons for the positive results.

One important issue about DEMO methodology is the business description necessary to create DEMO’s

first model. This step is very dependent on the person who does it, the source of information and on

the description itself. For the same enterprise or case study it is possible to arrive to different business

descriptions depending on the information source, specially if this source is a person, due to possible

different perspectives from different persons with different roles on that business. Therefore, this is

a very crucial step where the researcher must be very careful and thorough when gathering all the

information and analysing the different points of view, otherwise the DEMO models maybe affected.

With the alternative proposed in this work we also pretended to avoid these pitfalls by clearly identifying

each activity in each case study.

We also identified a performance issue in this step, namely, the original approach defined in (Dietz, 2006)

might have a serious performance constraint in the definition of the business description for enterprises

or case studies. The DEMO text is a very thorough and detailed description of all the analysed business.

So, if the analysed business is very big and complex the DEMO text might become a serious obstacle.

The proposed alternative main goal was to improve this performance constraint without affecting the

development of DEMO methodology an its models. And by analysing the results we believe we can

safely say that this alternative clearly did not affect the DEMO models quality. In order to evaluate the

performance improvement it is necessary to realise a case study where the two approaches are used

and compared, which was not possible to do in this work. Because of that, we can not state that our

81

proposal has a better performance, however we believe that our proposed alternative is undoubtedly a

more efficient approach and therefore contributed with a valid and valuable alternative to the DEMO text.

Another issue and concern in this work was the acceptance of DEMO models by the organization’s

stakeholders. Although DEMO is a highly regarded scientific methodology and very researched in the

academic world, it is not so well known in the enterprise world, specially in the Portuguese PA. So, in

order to have a better assessment of the DEMO model’s acceptance we compared these models to

a converted UML model, which is a very well known modulation language. In order to evaluate these

models it was applied an evaluation process that combined the Moody and Shanks Framework with

the feedback from the case study’s stakeholders. With this evaluation process we could analyse the

level of acceptance for DEMO models, which in an universe of nine stakeholders was in overall a very

good acceptance level. There was only one exception in the last case study where one stakeholder

didn’t understood the DEMO models very well and therefore evaluate them poorly. Aside from this

exception, the acceptance was very high and in an overall evaluation the DEMO models were considered

to be more complete, flexible and righteous, while the UML models where considered more simple and

understandable. It was expected that the UML model would have a better evaluation in these factors, but

the difference to the DEMO models evaluation was very short and we believe that the understandability

factor would have a shorter difference if the stakeholders had a short formation or explanation about

the subject. Finally in the models evaluation as an IA, the overall evaluation clearly favoured the DEMO

models, with very positive results, which means that stakeholders accepted the SM as a valid IA, and

therefore prove that SM is a good representation model for an IA and was even considered to be a better

representation than UML.

With all this in mind and considering the positive results of the case studies, we can safely answer this

thesis main question with the claim:

DEMO is a valid methodology for the creation of an IA.

82

Chapter 8

Conclusions

With the increasing importance of information and its management for organizations the question

of how can organizations improve and better manage their information arises. Therefore, a well

designed and developed Information Architecture (IA), that maps the essential business information of

an enterprise, has become an essential response to this information management. So, the question

that arises is how do organizations create their IA and if there is any method or methodology to do so.

During the work of this thesis we could not find any research or paper that could solve this problem and

struggle for the organizations. After analysing the problem and the related work we decided to take an

Enterprise Ontology (EO) approach to solve this problem, for two main reasons. First, the EO theory

focus its analysis on the ontological layer of an enterprise and therefore in the business essence of an

enterprise, disregarding its implementation, which suits well in the creation of an IA, which should focus

on the business essential information. The second reason is that EO is a very academic researched

and accepted concept, which gives this work a very acknowledged theoretical foundation. So, the main

question this thesis arises is if DEMO, the EO methodological application, is a valid methodology for

the creation of an IA. This work aimed to solve this question in the context of the Portuguese Public

Administration (PA) and in the enterprise context of AMA, which has the goal of improving the IA in the

Portuguese PA by developing a IA of reference for all the PA.

Considering that obtaining information to perform DEMO’s analyses and syntheses is not always easy

and for enterprises with a broad business scope we considered that the creation of a detailed and

concise business description (DEMO text) can be a constraint to the application of DEMO methodology.

Therefore we proposed an alternative approach to the creation of DEMO’s first model that pretends to

reduce the impact of that constraint.

In order to demonstrate how DEMO could create an IA we conducted three case studies. Taking into

account the PA context, the three case studies were carried out in three PA organizations. The first two

were conducted in the Loja do Cidadao and in the Camara Municipal de Almada’s Loja do Munıcipe,

83

which provide services for the citizens. The third case study involved a application that provides services

of scheduling appointments. To assess the validity of the case studies we applied the Moody & Shanks

Framework with the feedback of the stakeholders, and analysed their assessment of the obtained results.

After analysing the feedback from the stakeholders and their evaluation of the results we arrived to

the conclusion that an EO approach with a DEMO methodology application can be used to create an

IA and this method is a valid tool for the creation of an IA, in the Portuguese PA. With the positive

results we proved that our alternative for the DEMO text approach is a valid alternative, regarding the

production quality DEMO models. Finally, we also proved that, in the Portuguese PA, the SM is a good

representation model for the IA as is a well accepted representation model, since only one of the nine

stakeholders involved in the evaluation process gave a bad review to the DEMO results.

8.1 Future Work

As we seen before in this work, the initial input for the creation of DEMO’s first model can be an issue and

an constraint in the application of this methodology and so it must be further researched and improved.

The alternative proposed in this thesis should be further researched and tested to guaranty a better level

of performance.

Also, as stated before, one of the goals of this work was for the method of creating an IA to be simple

and efficient and for that purpose the automation of DEMO methodology would greatly benefit the appli-

cation of this methodology. This automation process would depend on the input and we believe that the

alternative input proposed in this work, with further research and refinement, would be a suitable input

for an automation process of this methodology, since the information is gathered in a format that is well

integrated with almost every software solution.

An important future work for this thesis would be to further research and improve the SM as an IA,

without compromising EO’s theories, goals and benefits. This would require a more extensive research

of the IA and WOSL, and the application of more case studies to further improve and focus the SM as a

definite IA model.

Finally, regarding this work and a Reference IA, which is an important goal for AMA and the Portuguese

PA, more research and work is needed to get there. By validating DEMO as a valid method to create an

IA, in the context of PA, it is now possible to take this work and apply it to several more case studies for

different PA organizations and therefore create a knowledge base of IAs for the PA. With a set of IAs of

the major PA organizations it would be possible to study and research them so that a reference architec-

ture creation methodology could be applied to the identification of the main IEs and their composition.

An automated process would greatly ease the creation of this set of IAs.

84

Bibliography

ACKOFF, R. (1999). Ackoff’s best: his classic writings on management . Wiley (New York).

AERTS, A., GOOSSENAERTS, J., HAMMER, D. & WORTMANN, J. (2004). Architectures in context: on

the evolution of business, application software, and ict platform architectures. Information & Man-

agement , 41, 781 – 794.

ALBANI, A., DIETZ, J.L.G. & ZAHA, J.M. (2006). Identifying business components on the basis of an

enterprise ontology. In Interoperability of Enterprise Software and Applications, 335–347, Springer

London.

AMA (2011). Agencia para a modernizacao administrativa: Arquitectura informacional, versao 1.0.

BRANCHEAU, J.C. & WETHERBE, J.C. (1986). Information architectures: Methods and practice. Infor-

mation Processing & Management , 22, 453 – 463.

BRANCHEAU, J.C., SCHUSTER, L. & MARCH, S.T. (1989). Building and implementing an information

architecture. SIGMIS Database, 20, 9–17.

CAETANO, A. & VASCONCELOS, A. (2011). Arquitectura processos e ferramentas de sistemas de infor-

macao: Arquitectura de informacao.

CASTELAO, R. (2010). An Information Architecture for the Public Administration. Master’s thesis, Instituto

Superior Tecnico.

DGAEP (2013). Direccao-geral da administracao e do emprego publico, organizacao da administracao

do estado: Administracao publica.

DIETZ, J. (1990). A communication oriented approach to conceptual modelling of information systems.

In B. Steinholtz, A. Sølvberg & L. Bergman, eds., Advanced Information Systems Engineering, vol. 436

of Lecture Notes in Computer Science, 134–151, Springer Berlin / Heidelberg, 10.1007/BFb0000590.

DIETZ, J. (1999). Understanding and modelling business processes with demo. In Conceptual Modeling

- ER 99, vol. 1728 of Lecture Notes in Computer Science, Springer Berlin / Heidelberg.

85

DIETZ, J. (2005). A world ontology specification language. In R. Meersman, Z. Tari & P. Herrero, eds.,

On the Move to Meaningful Internet Systems 2005: OTM 2005 Workshops, vol. 3762 of Lecture Notes

in Computer Science, 688–699, Springer Berlin Heidelberg.

DIETZ, J. (2008). Enterprise engineering: introduction to an emerging new discipline, presentation.

DIETZ, J. & HABING, N. (2004). A meta ontology for organizations. In R. Meersman, Z. Tari & A. Corsaro,

eds., On the Move to Meaningful Internet Systems 2004: OTM 2004 Workshops, vol. 3292 of Lecture

Notes in Computer Science, 533–543, Springer Berlin Heidelberg.

DIETZ, J. & HOOGERVORST, J. (2007). Enterprise ontology and enterprise architecture, how to let them

evolve into effective complementary notions. GEAO Journal of Enterprise Architecture, 2.

DIETZ, J.L. (2001). Demo: Towards a discipline of organisation engineering. European Journal of Op-

erational Research, 128, 351 – 363.

DIETZ, J.L.G. (2006). Enterprise Ontology: Theory and Methodology . Springer.

DIETZ, J.L.G. & HOOGERVORST, J. (2008). Enterprise ontology in enterprise engineering. Proceedings

of the 2008 ACM symposium on Applied computing SAC 08, 28, 572.

DILLON, A. & TURNBULL, D. (2005). Information Architecture. New York: Marcel Dekker.

DUMAY, M., DIETZ, J. & MULDER, H. (2005). Evaluation of demo and the language/action perspective

after 10 years of experience.

ERLIN, YUNUS, Y.A. & RAHMAN, A.A. (2008). The evolution of information architecture. In Information

Technology, 2008. ITSim 2008. International Symposium on, vol. 4, 1 –6.

FERREIRA, J.A.P. (2011). Towards an Enterprise Ontology-based Approach to Service Identification.

Master’s thesis, Instituto Superior Tecnico.

GOMES, B. (2011). Information Architecture and Enterprise Ontologies: An Enterprise Ontology Ap-

proach for Defining the Enterprise Information Architecture. Master’s thesis, Instituto Superior Tecnico.

GRUBER, T.R. (1995). Toward principles for the design of ontologies used for knowledge sharing. Int. J.

Hum.-Comput. Stud., 43, 907–928.

HALPIN, T. (2001). Information modeling and relational databases: from conceptual analysis to logical

design. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA.

HEVNER, A.R., MARCH, S.T., PARK, J. & RAM, S. (2004). Design science in information systems

research. MIS Q., 28, 75–105.

HOOGERVORST, J.A.P. & DIETZ, J.L.G. (2008). Enterprise architecture in enterprise engineering. En-

terprise Modeling and Information Systems Architecture, 3, 03–13.

86

HUYSMANS, P., VEN, K. & VERELST, J. (2010). Using the demo methodology for modeling open source

software development processes. Information and Software Technology , 52, 656 – 671.

IEEE COMPUTER SOCIETY, I. (2000). Ieee std 1471-2000, ieee recommended practice for architectural

description of software-intensive systems.

KIRIKOVA, M. (2009). Towards flexible information architecture for fractal information systems. In Infor-

mation, Process, and Knowledge Management, 2009. eKNOW ’09. International Conference on, 135

–140.

KOTHARI, C. (2008). Research Methodology: Methods and Techniques. New Age International (P) Lim-

ited.

LANKHORST, M. (2009). Enterprise Architecture at Work , chap. Introduction to Enterprise Architecture,

1–11. Springer Berlin Heidelberg, 2nd edn.

MOODY, D.L. & SHANKS, G.G. (2003). Improving the quality of data models: empirical validation of a

quality management framework. Information Systems, 28, 619 – 650.

NEVES, J. (1996). Pesquisa qualitativa: caracteristicas, usos e possibilidades. Caderno de pesquisas

em administracao Sao Paulo, 1, 1–5.

OP ’T LAND, M. & PROPER, E. (2007). Impact of principles on enterprise engineering. In ECIS, 1965–

1976.

PEFFERS, K., TUUNANEN, T., ROTHENBERGER, M.A. & CHATTERJEE, S. (2007). A design science re-

search methodology for information systems research. Journal of management information systems,

24, 45–77.

PEREIRA, C.M. & SOUSA, P. (2004). A method to define an enterprise architecture using the zachman

framework. In Proceedings of the 2004 ACM symposium on Applied computing.

SARGENT, R.G. (2005). Verification and validation of simulation models. In Proceedings of the 37th

conference on Winter simulation, WSC ’05, 130–143, Winter Simulation Conference.

VAN REIJSWOUD, V. & VAN DER RIJST, N. (1995). Modelling business communication as a foundation

for business process redesign: a case of production logistics. In System Sciences, 1995. Vol. IV.

Proceedings of the Twenty-Eighth Hawaii International Conference on, vol. 4, 841 –850 vol.4.

VASCONCELOS, A. (2007). Arquitectura dos Sistemas de Informacao: Representacao e Avaliacao. Ph.D.

thesis, Instituto Superior Tecnico.

WATSON, R. (2000). An enterprise information architecture: a case study for decentralized organiza-

tions. In System Sciences, 2000. Proceedings of the 33rd Annual Hawaii International Conference on,

10 pp.–.

87

placeholder

Appendix A

Case Study I: BMS

A.1 The State Model for the remaining Institutions

A.1.1 Automovel Club de Portugal (ACP)

Figure A.61: The OFD for ACP services.


NIB CITIZEN NUMBER

NIF CITIZEN NUMBER

NISS CITIZEN NUMBER

payment value SERVICE EUROTable A.14: The OPL for ACP services.

89

A.1.2 Autoridade Regional de Saude (ARS)

Figure A.62: The OFD for ARS services.


NIB CITIZEN NUMBER

NIF CITIZEN NUMBER

NISS CITIZEN NUMBER

payment value SERVICE EUROTable A.15: The OPL for ARS services.

A.1.3 Caixa Geral de Aposentacoes (CGA)

Figure A.63: The OFD for CGA services.

90


NIB CITIZEN NUMBER

NIF CITIZEN NUMBER

NISS CITIZEN NUMBER

type DOCUMENTS CATEGORYTable A.16: The OPL for CGA services.

A.1.4 Centro Nacional de Pensoes (CNP)

Figure A.64: The OFD for CNP services.


NIB CITIZEN NUMBER

NIF CITIZEN NUMBER

NISS CITIZEN NUMBER

type DOCUMENTS CATEGORYTable A.17: The OPL for CNP services.

91

A.1.5 Direcao-Geral do Consumidor (DGC)

Figure A.65: The OFD for DGC services.


NIB CITIZEN NUMBER

NIF CITIZEN NUMBER

NISS CITIZEN NUMBERTable A.18: The OPL for DGC services.

A.1.6 Eletricidade de Portugal (EDP)

Figure A.66: The OFD for EDP services.


NIB CITIZEN NUMBER

NIF CITIZEN NUMBER

NISS CITIZEN NUMBERTable A.19: The OPL for EDP services.

92

A.1.7 Instituto da Mobilidade e dos Transportes Terrestres (IMTT)

Figure A.67: The OFD for IMTT services.

93


NIB CITIZEN NUMBER

NIF CITIZEN NUMBER

NISS CITIZEN NUMBER


type DOCUMENTS CATEGORY

photo FORM BOOLEANTable A.20: The OPL for IMTT services.

A.1.8 Instituto da Seguranca Social (ISS)

Figure A.68: The OFD for ISS services.


NIB CITIZEN NUMBER

NIF CITIZEN NUMBER

NISS CITIZEN NUMBER

type DOCUMENTS CATEGORYTable A.21: The OPL for ISS services.

94

A.1.9 Portal do Cidadao (PC)

Figure A.69: The OFD for PC services.


NIB CITIZEN NUMBER

NIF CITIZEN NUMBER

NISS CITIZEN NUMBERTable A.22: The OPL for PC services.

A.2 The Global OFD for BMS

95

Figure A.70: The OFD for BMS case study.

96

Appendix B

Case Study II: LDM

B.1 The Enterprise Activities Tables

Figure B.71: The EAT for the service: Pedido de Contrato de Fornecimento de Agua.

Figure B.72: The EAT for the service: Pedido de Denuncia do Contrato de Agua.

97

Figure B.73: The EAT for the service: Pedido de Entrada de Requerimento para Reducao de Tarifa deAgua.

Figure B.74: The EAT for the service: Pedido de Pagamento de Factura da Agua.

Figure B.75: The EAT for the service: Pedido de Pagamento de Renda.

Figure B.76: The EAT for the service: Pedido de Refeicoes Escolares.

98

Figure B.77: The EAT for the service: Pedido de Licenca de Utilizacao.

Figure B.78: The EAT for the service: Pedido de Licenca de Publicidade ou Ocupacao do EspacoPublico.

B.2 The OFD for LDM Case Study

99

Figure B.79: The OFD for LDM case study.

100

Appendix C

Case Study III: Company X

C.1 The Enterprise Activities Tables

Figure C.80: The EAT for the service: Registar Marcacao.

Figure C.81: The EAT for the service: Actualizar Dados Marcacao.

Figure C.82: The EAT for the service: Pesquisar Marcacao.

101

Figure C.83: The EAT for the service: Actualizar Estado de Marcacao.

Figure C.84: The EAT for the service: Consultar Marcacao.

Figure C.85: The EAT for the service: Pesquisar Local de Atendimento.

Figure C.86: The EAT for the service: Registar Local de Atendimento.

Figure C.87: The EAT for the service: Consultar Local de Atendimento.

102

Figure C.88: The EAT for the service: Alterar Local de Atendimento.

Figure C.89: The EAT for the service: Alterar Estado no Atendimento.

Figure C.90: The EAT for the service: Registar Utilizador.

Figure C.91: The EAT for the service: Alterar Utilizador.

Figure C.92: The EAT for the service: Pesquisar Utilizadores.

103

Figure C.93: The EAT for the service: Consultar Utilizadores.

104

C.2 The OFD

Figure C.94: The OFD for Company X case study.

105

C.3 The IUT


B-R01 Appointment A has been registered T01/ex

B-R02 Appointment A has been updated T02/ex

B-R03 Appointment [A] has been found T03/ex

B-R04 Appointment [A] state has been updated T04/ex

B-R05 Appointment [A] has been consulted T05/ex

B-R06 Attending Point [AP] has been registered T06/ex

B-R07 Schedule [S] has been created T07/ex

B-R08 Reservation [R] has been created T08/ex

B-R09 Attending Point [AP] has been found T09/ex

B-R10 Attending Point [AP] has been consulted T10/ex

B-R11 Attending Point [AP] has been changed T11/ex

B-R12 Attending Point [AP] state has been changed T12/ex

B-R13 User [U] has been registered T13/ex

B-R14 User [U] has been changed T14/ex

B-R15 User [U] has been found T15/ex

B-R16 User [U] has been consulted T16/ex

APPOINTMENT T01/rq T02/rq T04/rq

ATTENDING POINT T06/rq T11/rq T12/rq

USER T13/rq T14/rq

RESERVATION T08/rq

SCHEDULE T07/rq

ADMINISTRATOR T13/rq T14/rq T15/rq T16/rq

INTERNAL USER T06/rq T07/rq T08/rq T09/rq

INTERNAL USER T10/rq T11/rq T12/rq

DOCUMENTS T01/pm

THEME T06/rqTable C.23: The IUT for Company X case study (Part 1).

106


F01 the [appointment] is made by the [user] T01/pm

F02 the [administrator] gives permissions to the [user] T13/pm

F03 the [appointment] has an [attending point] T01/pm

F04 the [attending point] is managed by the [internal user] T06/rq

F05 the [attending point] has a [schedule] T06/pm

F06 the [attending point] has a [reservation] T06/pm

F07 the documents of [theme] are [documents] T01/pm

F08 the theme of [reservation] is [theme] T08/pm

F09 the [attending point] has [theme] T06/pm

F10 the theme of [appointment] is [theme] T01/pmTable C.24: The IUT for Company X case study (Part 2).

107

Appendix D

IA developed by AMA

Figure D.95: The Portuguese PA IA by AMA.

108

Appendix E

WOSL Notation

Figure E.96: WOSL notation (Part 1).

109

Figure E.97: WOSL notation (Part 2).

110