Towards an Enterprise Ontology-based Approach to Information 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 Silva Supervisors: Prof. Doutor Andre´ Ferreira Ferrao˜ Couto e Vasconcelos Prof. Doutor Artur Miguel Pereira Alves Caetano Member of the Committee: Prof. Pedro Manuel Moreira Vaz Antunes de Sousa

May 2013 placeholder Abstract

he role of information has become increasingly important and crucial for organizations. Therefore T 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

papel da informac¸ao˜ nas organizac¸oes˜ tem-se tornado cada vez mais importante e crucial. Por Oisso, melhorar a gestao˜ da informac¸ao˜ tornou-se numa verdadeira preocupac¸ao˜ para as empre- sas e por essa razao˜ a importanciaˆ da arquitetura informacional tem-se tornado cada vez maior. A administrac¸ao˜ publica´ nao˜ e´ diferente e, por isso, o desenvolvimento e melhoria de uma arquitetura informacional de referenciaˆ tem-se tornado num objetivo da administrac¸ao˜ publica.´

Este trabalho procura definir como uma organizac¸ao˜ 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 aplicac¸ao˜ 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 implementac¸ao.˜

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 administrac¸ao˜ 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 administrac¸ao˜ publica´ que fornecem servic¸os e uma aplicac¸ao˜ de marcac¸ao˜ de consultas de outro organismo publico.´ De forma a avaliar os resultados aplicamos´ a Design Science Research Methodology e no processo de avaliac¸ao˜ 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 , Administrac¸ao˜ Publica´

v placeholder Acknowledgements

his dissertation has been a long and hard journey and certainly the most challenging project i T 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 Direc¸ao-Geral˜ de Protec¸ao˜ Social aos Trabalhadores em Func¸oes˜ Publica´ AM Action Model AMA Agenciaˆ para a Modernizac¸ao˜ Administrativa ATD Actor Transaction Diagram BCT Bank Contents Table BMS Balcao˜ Multiservic¸os 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 Background7

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˜ Multiservic¸os (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.1 The Enterprise Activities Tables ...... 51

5.2.2 The Constrution Model (Interaction Model) ...... 51

5.2.3 The Process Model ...... 51

5.2.4 The Action Model ...... 52

5.2.5 The State Model ...... 54

5.2.6 The Constrution Model (Interstriction Model) ...... 55

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

5.3.1 The Enterprise Activities Tables ...... 57

5.3.2 The Constrution Model (Interaction Model) ...... 57

5.3.3 The Process Model ...... 59

5.3.4 The Action Model ...... 60

5.3.5 The State Model ...... 64

5.3.6 The Constrution Model (Interstriction Model) ...... 64

5.4 Summary ...... 67

6 Evaluation 69

6.1 Balcao˜ Multiservic¸os (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 Aposentac¸oes˜ (CGA) ...... 90

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

A.1.5 Direc¸ao-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 Seguranc¸a 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 Doenc¸a and Renovac¸ao˜ do Cartao˜ Europeu de Seguro de Doenc¸a...... 38

5.23 The EAT for the service: Pedido de Alterac¸ao˜ de NIB de beneficiarios´ ADSE...... 38

5.24 The EAT for the service: Pedido de Alterac¸ao˜ 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: Recec¸ao˜ de Documentos de Despesas de Saude...... 39

5.27 The EAT for the service: Emissao˜ da Declarac¸ao˜ 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.38 The AM for LDM case study (Part 2)...... 53

5.39 The AM for LDM case study (Part 3)...... 54

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.45 The AM for Company X case study (Part 2)...... 61

5.46 The AM for Company X case study (Part 3)...... 62

5.47 The AM for Company X case study (Part 4)...... 63

5.48 The AM for Company X case study (Part 5)...... 64

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 Reduc¸ao˜ 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 Refeic¸oes˜ Escolares...... 98

B.77 The EAT for the service: Pedido de Licenc¸a de Utilizac¸ao...... ˜ 99

xxv B.78 The EAT for the service: Pedido de Licenc¸a de Publicidade ou Ocupac¸ao˜ do Espac¸o Publico.´ ...... 99

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

C.80 The EAT for the service: Registar Marcac¸ao.˜ ...... 101

C.81 The EAT for the service: Actualizar Dados Marcac¸ao.˜ ...... 101

C.82 The EAT for the service: Pesquisar Marcac¸ao...... ˜ 101

C.83 The EAT for the service: Actualizar Estado de Marcac¸ao.˜ ...... 102

C.84 The EAT for the service: Consultar Marcac¸ao...... ˜ 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

he importance of Information Technology to support business in organizations is a given fact nowa- T 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 • 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 Chapter1 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 Chapter2 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 Chapter3 the related work is addressed and taken into consideration. Corresponds to part of the DSRM step ”Design and development” as well.

In Chapter4 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”.

Chapter5 presents the results of the application of the proposed solution to three case studies. Corre- sponds to the DSRM step ”Demonstration”.

In Chapter6 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 Chapter7 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 Chapter8 we present our conclusions. Corresponds to the DSRM step ”Communication”.

In AppendixA 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 AppendixB 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 AppendixC 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 AppendixD we present AMA’s IA.

In AppendixE we present the WOSL notation.

6 Chapter 2

Theoretical Background

n Chapter2 we approach the theoretical background of this thesis, i.e., the main theoretical notions Iand 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

n this Chapter we address the related work of this thesis. We start by analysing the DEMO method- Iology, 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 Modernizac¸ao˜ 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 AppendixE.

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 chapter4.

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 AppendixD, 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 Cidadao˜ 2.

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 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

n this Chapter we present our proposal of solution to the problem described in Chapter1. Consid- Iering 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 Chapter3, 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 delivered Table 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

n Chapter5 we pretend to demonstrate how the DEMO methodology is a valid tool for the creation Iof 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˜ Multiservic¸os (BMS)

This case study is based in Loja do Cidadao’s˜ service, named Balcao˜ Multiservic¸os (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 (Direc¸ao-Geral˜ de Protec¸ao˜ Social aos Trabalhadores em Func¸oes˜ Publica).´ In AppendixA 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 chapter4 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 Doenc¸a and Renovac¸ao˜ do Cartao˜ Europeu de Seguro de Doenc¸a.

Figure 5.23: The EAT for the service: Pedido de Alterac¸ao˜ de NIB de beneficiarios´ ADSE.

38 Figure 5.24: The EAT for the service: Pedido de Alterac¸ao˜ 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: Recec¸ao˜ de Documentos de Despesas de Saude.

39 Figure 5.27: The EAT for the service: Emissao˜ da Declarac¸ao˜ 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.

Transaction Types Result Types 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 delivered Table 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 .

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 chapter3, 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 CATEGORY Table 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/pm Table 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-T06 Table 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

Property Type Object Class Scale NIB CITIZEN NUMBER NIF CITIZEN NUMBER NISS CITIZEN NUMBER payment value SERVICE EURO type DOCUMENTS CATEGORY photo FORM BOOLEAN Table 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 5.2.1 The Enterprise Activities Tables

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.

5.2.2 The Constrution Model (Interaction Model)

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.

Transaction Types Result Types 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 delivered Table 5.7: The TRT for LDM case study.

5.2.3 The Process Model

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.

5.2.4 The Action Model

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 Figure 5.38: The AM for LDM case study (Part 2).

53 Figure 5.39: The AM for LDM case study (Part 3).

5.2.5 The State Model

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.

Property Type Object Class Scale NIB CITIZEN CARD NUMBER NIF CITIZEN CARD NUMBER water supply doc SERVICE BOOLEAN payment value SERVICE EURO publicity doc SERVICE BOOLEAN Table 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 object class, fact type, or result type process steps 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/pm Table 5.9: The IUT for LDM case study.

5.2.6 The Constrution Model (Interstriction Model)

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 object class, fact type, or result type P-bank 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-T08 Table 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.

5.3.1 The Enterprise Activities Tables

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.

5.3.2 The Constrution Model (Interaction Model)

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 Transaction Types Result Types 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 consulted Table 5.11: The TRT for Company X case study.

5.3.3 The Process Model

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.

5.3.4 The Action Model

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 Figure 5.45: The AM for Company X case study (Part 2).

61 Figure 5.46: The AM for Company X case study (Part 3).

62 Figure 5.47: The AM for Company X case study (Part 4).

63 Figure 5.48: The AM for Company X case study (Part 5).

5.3.5 The State Model

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.

Property Type Object Class Scale 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 DATE Table 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.

5.3.6 The Constrution Model (Interstriction Model)

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 object class, fact type, or result type P-bank 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 Chapter4, 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

n this Chapter we present the evaluation process used to validate our thesis proposal, namely, prove Ithat 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 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˜ Multiservic¸os (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

n this Chapter we analyse the lessons learned in this work. After concluding the work and the appli- Ication 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

ith the increasing importance of information and its management for organizations the question W 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.

IEEECOMPUTER 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. & VANDER 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.

Property Type Object Class Scale NIB CITIZEN NUMBER NIF CITIZEN NUMBER NISS CITIZEN NUMBER payment value SERVICE EURO Table A.14: The OPL for ACP services.

89 A.1.2 Autoridade Regional de Sa ´ude(ARS)

Figure A.62: The OFD for ARS services.

Property Type Object Class Scale NIB CITIZEN NUMBER NIF CITIZEN NUMBER NISS CITIZEN NUMBER payment value SERVICE EURO Table A.15: The OPL for ARS services.

A.1.3 Caixa Geral de Aposentac¸oes˜ (CGA)

Figure A.63: The OFD for CGA services.

90 Property Type Object Class Scale NIB CITIZEN NUMBER NIF CITIZEN NUMBER NISS CITIZEN NUMBER type DOCUMENTS CATEGORY Table A.16: The OPL for CGA services.

A.1.4 Centro Nacional de Pensoes˜ (CNP)

Figure A.64: The OFD for CNP services.

Property Type Object Class Scale NIB CITIZEN NUMBER NIF CITIZEN NUMBER NISS CITIZEN NUMBER type DOCUMENTS CATEGORY Table A.17: The OPL for CNP services.

91 A.1.5 Direc¸ao-Geral˜ do Consumidor (DGC)

Figure A.65: The OFD for DGC services.

Property Type Object Class Scale NIB CITIZEN NUMBER NIF CITIZEN NUMBER NISS CITIZEN NUMBER Table A.18: The OPL for DGC services.

A.1.6 Eletricidade de Portugal (EDP)

Figure A.66: The OFD for EDP services.

Property Type Object Class Scale NIB CITIZEN NUMBER NIF CITIZEN NUMBER NISS CITIZEN NUMBER Table 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 Property Type Object Class Scale NIB CITIZEN NUMBER NIF CITIZEN NUMBER NISS CITIZEN NUMBER payment value SERVICE EURO type DOCUMENTS CATEGORY photo FORM BOOLEAN Table A.20: The OPL for IMTT services.

A.1.8 Instituto da Seguranc¸a Social (ISS)

Figure A.68: The OFD for ISS services.

Property Type Object Class Scale NIB CITIZEN NUMBER NIF CITIZEN NUMBER NISS CITIZEN NUMBER type DOCUMENTS CATEGORY Table A.21: The OPL for ISS services.

94 A.1.9 Portal do Cidadao˜ (PC)

Figure A.69: The OFD for PC services.

Property Type Object Class Scale NIB CITIZEN NUMBER NIF CITIZEN NUMBER NISS CITIZEN NUMBER Table 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 Reduc¸ao˜ de Tarifa de Agua.´

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 Refeic¸oes˜ Escolares.

98 Figure B.77: The EAT for the service: Pedido de Licenc¸a de Utilizac¸ao.˜

Figure B.78: The EAT for the service: Pedido de Licenc¸a de Publicidade ou Ocupac¸ao˜ do Espac¸o Publico.´

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 Marcac¸ao.˜

Figure C.81: The EAT for the service: Actualizar Dados Marcac¸ao.˜

Figure C.82: The EAT for the service: Pesquisar Marcac¸ao.˜

101 Figure C.83: The EAT for the service: Actualizar Estado de Marcac¸ao.˜

Figure C.84: The EAT for the service: Consultar Marcac¸ao.˜

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

object class, fact type, or result type process steps 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/rq Table C.23: The IUT for Company X case study (Part 1).

106 object class, fact type, or result type process steps 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/pm Table 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