generation of visualizations for service architectures€¦ · generation of visualizations for...

Generation of Visualizations for Service Architectures

Frederico de Jesus Assis de Campos Dionısio

Thesis to obtain the Master of Science Degree in

Information Systems and Computer Engineering

Supervisor: Prof. Pedro Manuel Moreira Vaz Antunes de Sousa

Examination Committee

Chairperson: Prof. Paolo RomanoSupervisor: Prof. Pedro Manuel Moreira Vaz Antunes de Sousa

Members of the Committee: Prof. Sandra Pereira Gama

November 2017

Acknowledgments

I would like to thank my parents and sisters who have supported me throughout my whole life and

pushed me to work and be successful. A big thanks to my uncle since he has been my mentor since

I decided to come to this field of work. I would also like to thank my Professor Pedro Sousa, who has

taught me much of what I have learned and has provided this opportunity to do this thesis that has been

extremely enlightening. My senior manager Andre Sampaio also deserves a big regards since he has

helped and taught me much. And finally a big thank you to my two close friends Goncalo and Ines who

have stood by my side throughout this Master’s Degree.

Abstract

Lately, organizations have been struggling with representing their service architectures due to problems

such as lack of communication between the various departments and a common language to represent

that architecture. There is also a big problem regarding the size of the architecture that becomes almost

incomprehensible to visualize it. In this thesis I will do a research on what has been done regarding this

theme, what the discipline of Enterprise Architecture has done to support the visualization of Service

Architectures, what the frameworks to model it are, and what tools can be used to help us develop

a solution. We provide a solution to what we think it is fit for this problem. This work has the goal of

improving service architecture visualization in line with the main Enterprise Architecture frameworks and

guidelines. This work was inserted in the context of the organization Servicos Partilhados do Ministerio

da Saude.

Keywords

Service Architecture; Visualization; Representation; Visualization generation; Viewpoints

iii

Resumo

Actualmente, as organizacoes tem tido problemas ao representar as suas arquitecturas de servicos de-

vido a problemas como falta de comunicacao entre os varios departamentos, e a falta de uma linguagem

comum para representar essa arquitectura. Ha tambem um grande problema que tem a ver com o facto

de essas arquitecturas serem extremamente vastas, que se tornam quase incompreensıveis. Nesta

tese foi feita pesquisa sobre o que ja foi feito sobre este tema. O que e que a disciplina de Arquitec-

tura Empresarial fez para suportar a visualizacao de arquitecturas de servicos. Que frameworks ha

para modelar essas arquitecturas e que ferramentas nos ajudaram a desenvolver uma solucao. Vamos

especificar a solucao que achamos ser adequada para este problema. Este trabalho tem o objectivo

de melhorar a visualizacao de arquitecturas de servicos em linha com as frameworks e directrizes da

disciplina de Arquitectura Empresarial. Este trabalho decorreu no contexto da organizacao, Servicos

Partilhados do Ministerio da Saude.

Palavras Chave

Arquitectura de servicos; Visualizacao; Representacao; Geracao de visualizacoes; Ponto de vista

v

Contents

1 Introduction 1

1.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Objectives of work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Background work 7

2.1 Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Enterprise Architecture Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Service Notion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Operation Axiom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.2 Transaction Axiom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.3 Distinction Axiom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Service Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Service Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.1 SOA basic concepts - Logical and physical services . . . . . . . . . . . . . . . . . 13

3 Related Work 15

3.1 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1 Modeling Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1.A UML - Unified Modeling Language . . . . . . . . . . . . . . . . . . . . . . 17

A – Represent a SOA Architecture in UML . . . . . . . . . . . . . . . 17

B – Problems with the UML framework . . . . . . . . . . . . . . . . . 19

3.1.1.B Archimate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

A – Archimate Relationships . . . . . . . . . . . . . . . . . . . . . . 21

B – Archimate Views and Viewpoints . . . . . . . . . . . . . . . . . . 22

C – Service Realization Viewpoint . . . . . . . . . . . . . . . . . . . 23

D – Application Cooperation Viewpoint . . . . . . . . . . . . . . . . . 24

E – Problems with the Archimate Framework . . . . . . . . . . . . . 25

3.1.1.C TOGAF Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

vii

A – Problems with the TOGAF Framework . . . . . . . . . . . . . . . 25

3.1.2 Modeling Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.2.A Enterprise Architecture Visualization Tool Survey . . . . . . . . . . . . . 26

A – Create and configure a visualization . . . . . . . . . . . . . . . . 26

B – Create a visualization . . . . . . . . . . . . . . . . . . . . . . . . 26

C – Visual parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 26

D – Layouting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

E – Set-up and adapt the EA information model . . . . . . . . . . . . 27

F – Visualization Types . . . . . . . . . . . . . . . . . . . . . . . . . 28

G – Problems with the Enteprise Architecture Survey Tool . . . . . . 31

3.1.2.B EAMS - Enterprise Architecture Management System . . . . . . . . . . . 31

A – Blueprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

B – Blueprint as a graph . . . . . . . . . . . . . . . . . . . . . . . . . 35

C – Problems on the EAMS . . . . . . . . . . . . . . . . . . . . . . . 36

3.1.2.C Enterprise Architect (SparxSystems Ltd) . . . . . . . . . . . . . . . . . . 39

A – Problems on the Enterprise Architect . . . . . . . . . . . . . . . 39

3.1.3 Alternative visualizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4 Solution 43

4.1 Collapse containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.1.1 Collapse containers manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2 Filter blueprints based on properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2.1 Applying multiple filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2.1.A Algorithm to apply multiple filter . . . . . . . . . . . . . . . . . . . . . . . 52

4.2.1.B Multiple filter layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2.1.C Filter example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.3 Sorting instances by property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.3.0.A Types of properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.3.0.B Layout of the sorting interface . . . . . . . . . . . . . . . . . . . . . . . . 58

4.3.0.C Sorting example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.4 Filter the blueprint relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.4.1 Blueprint relationships definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.4.2 Relationships filter flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.4.2.A Algorithm to filter relations . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.4.3 Calculate relationship path of an entity given a depth . . . . . . . . . . . . . . . . . 64

viii

4.4.3.A Algorithm to calculate path . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.4.3.B Highlighting path example . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.5 Defining blueprints to support the SPMS organization . . . . . . . . . . . . . . . . . . . . 71

4.5.1 SPMS internal organization and blueprints definitions . . . . . . . . . . . . . . . . 71

4.6 Final considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5 Work Evaluation Methodology 79

6 System Testing 83

6.1 User testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.1.1 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.1.2 System Usability Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.1.2.A Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.1.2.B Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7 Conclusion 89

7.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

A Annex 95

ix

List of Figures

1.1 Design-Research Guidelines Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 DEMO Transaction Pattern [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 UML relationships [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Service Architecture example modeled in UML . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 Archimate Layers and Aspects [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4 Archimate Relationships [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.5 Archimate Viewpoint: Service Realization [3] . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.6 Archimate Viewpoint: Service Realization example [3] . . . . . . . . . . . . . . . . . . . . 23

3.7 Archimate Viewpoint: Application Cooperation viewpoint [3] . . . . . . . . . . . . . . . . . 24

3.8 Archimate Viewpoint: Application Cooperation viewpoint example [3] . . . . . . . . . . . . 24

3.9 TOGAF Viewpoint [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.10 Visualization Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.11 Matrix/Table Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.12 Graph Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.13 Entity-Relationship diagram Representation . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.14 UML Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.15 Tree View Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.16 Archimate Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.17 Blueprint implementation design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.18 Blueprint Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.19 Regular Layered Blueprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.20 Blueprint graph mapped from a regular blueprint . . . . . . . . . . . . . . . . . . . . . . . 36

3.21 Blueprint with high cardinality of instances . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.22 Blueprint with high cardinality of relations . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.23 EA SparxSystems editor tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

xi

3.24 Force Directed Graph Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.25 Tree Diagram Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1 Structure and Deploy Blueprint - Original blueprint . . . . . . . . . . . . . . . . . . . . . . 46

4.2 Solution Organic Blueprint - Refitting brother container . . . . . . . . . . . . . . . . . . . . 47

4.3 Solution Organic Blueprint - Refitting parent container . . . . . . . . . . . . . . . . . . . . 48

4.4 Collapse Interface button . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.5 Regular blueprint before applying filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.6 Regular blueprint after applying filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.7 Filter layout with two filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.8 Filter Demonstration - Blueprint before applying filter . . . . . . . . . . . . . . . . . . . . . 53

4.9 Filter Demonstration - Opening the filter interface . . . . . . . . . . . . . . . . . . . . . . . 53

4.10 Filter Demonstration - Step 2 - Select the class . . . . . . . . . . . . . . . . . . . . . . . . 54

4.11 Filter Demonstration - Step 3 - Select the property . . . . . . . . . . . . . . . . . . . . . . 54

4.12 Filter Demonstration - Step 4 - Select the operator . . . . . . . . . . . . . . . . . . . . . . 55

4.13 Filter Demonstration - Step 5 - Enter value and add the filter to the list . . . . . . . . . . . 55

4.14 Filter Demonstration - A filter instance and its appliance . . . . . . . . . . . . . . . . . . . 56

4.15 Blueprint graph by levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.16 Blueprint containers with no properties associated . . . . . . . . . . . . . . . . . . . . . . 57

4.17 Sorting Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.18 Sorting Demonstration - Container before sorting . . . . . . . . . . . . . . . . . . . . . . . 59

4.19 Sorting Demonstration - Step 1 - Click the sort button in the container . . . . . . . . . . . 59

4.20 Sorting Demonstration - Step 2 - Select the property to sort . . . . . . . . . . . . . . . . . 60

4.21 Sorting Demonstration - Step 3 - Select the order of sorting . . . . . . . . . . . . . . . . . 60

4.22 Sorting Demonstration - Step 4 - Apply the sort . . . . . . . . . . . . . . . . . . . . . . . . 60

4.23 Sorting Demonstration - Container after sorting . . . . . . . . . . . . . . . . . . . . . . . . 61

4.24 Structure and Deploy Blueprint with relationships activated . . . . . . . . . . . . . . . . . 61

4.25 Types of relation between entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.26 User Relationship Filter Flow chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.27 Blueprint with relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.28 Graph that shows various dependencies in a blueprint . . . . . . . . . . . . . . . . . . . . 66

4.29 Graph with relations and data instances highlighted for a depth of 2 . . . . . . . . . . . . . 66

4.30 Layered blueprint with high cardinality of relations before calculating path . . . . . . . . . 68




xii


4.35 Solution Organic Blueprint of SPMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.36 Actor Organic Blueprint of ARS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.37 Solution Organic Blueprint of ARS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.38 Business Process layered - SPMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.1 Model of generic evaluation methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.2 IS artifact evaluation based on the generic evaluation model instances . . . . . . . . . . . 82

6.1 SUS question evaluation scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

A.1 Archimate Metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

A.2 Hierarchy of criteria for IS artifact evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 97

xiii

Acronyms

CSV Comma-separated values

DEMO Design and Engineering Methodology for Organizations

EA Enterprise Architecture

EAMS Enterprise Architecture Management System

IT Information Technology

IS Information System

SOA Service Oriented Architecture

SPMS Servicos Partilhados do Ministerio da Saude

SUS System Usability Scale

TXT Text file

TOGAF The Open Group Architecture Framework

UML Unified Modeling Language

XML eXtensible Markup Language

xv

1Introduction

Contents

1.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Objectives of work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1

With the ongoing increase of the organization’s size and the role that IT has in it, there is a need to

support and sustain the IT service architecture. To do this, various departments within the organization

have developed several architectures to represent their services, using different languages and inde-

pendent from each other. Several modeling languages have been developed to address this problem

and organizations are now facing the problem of having multiple representations of the same service

architecture that is quite problematic to sustain.

Inside an organization there are many different stakeholders that have different needs, and it is not pos-

sible to address all those needs in a single visualization model. Luckily, there are several visualizations

or maps [5] that can help us developing proper representations of these service architectures.

The whole thesis has the discipline of Enterprise Architecture [6] as a foundation, which will provide us

the main concepts and domains to be represented in the architecture. It will also be in the context of the

organization Servicos Partilhados do Ministerio da Saude that hired the company where I am inserted:

Link Consulting. They had several problems across their departments, since each department was sup-

porting their architecture using a certain modeling language and it could have different interpretations

and cause some misunderstandings, since some languages have poor descriptions and definitions of

those services. For example, there were representations of the architecture being modeled using Archi-

mate [7], a list or simply using a draw. They had other problems regarding the density of information and

entities they had to manage with.

This document will have two chapters regarding the background work, which are the foundations to un-

derstand this thesis and a chapter with related work, which has a set of information of what has been

done regarding the following problem. After that, we present the developed solution and its testing.

1.1 Problem

In Servicos Partilhados do Ministerio da Saude, there is a lack of communication between the several

departments in an organization and there’s no agreement on how to represent the architecture services.

There is also a large heterogeneity of stakeholders that have interest in the service architecture but with

different level of detail and viewpoint. The architecture is constantly changing and the language that

every department uses to describe the architecture is different. There’s a need to create visual repre-

sentations of the service architecture that can be flexible and easy to understand by every stakeholder.

Every stakeholder should be able to navigate the architecture and be able to drill-down across the sev-

eral layers and still understand the architecture. In every department the organization has different ways

of thinking about what are the services and with different levels of details. This results in different visions

of the service architecture of the same organization, frequently so different that become incompatible

between them. Since each department has its own nomenclature to represent the same architecture,

3

the problem lies on finding a language that is easy to use, understandable and unique across the orga-

nization. There is also a large density of information.

The solution was validated with the stakeholders at the organization. A formal description of the problem

would be:

• Find the variables in the service architecture to be defined and presented in the visualization.

Those variables compose the structure of the metamodel of the service architecture, so the prob-

lem is to define different levels of detail for each stakeholder in the Servicos Partilhados do Min-

isterio da Saude.

• Find the best way to map those variables in each visualization. So we need to define how to

navigate the metamodel according to the stakeholder needs and create a configurable framework

that the stakeholder can select the most appropriate visualization to satisfy his need.

• Define the interaction content of each visualization.

• Address the large density of information and entities of the service architecture

So, briefly, the problem is to define a framework for visualizing multiple visualization paradigms according

to a stakeholder needs. This framework encompasses a configurable and interactive environment that

allows the user to select the level of detail and allows to navigate along the metamodel. An architectural

style is the combination of distinctive features in which the architecture is performed or expressed [1],

so with this dissertation, we intend to apply and explore the modeling principles of “multi-dimensional”

processes that support an unique architecture model for every stakeholder in the organization.

These problems are related to the problems the organization Servicos Partilhados do Ministerio da

Saude faces. To summarize those problems, it would be the large cardinality of entities the organization’s

architecture has. No clear distinction between them. Lack of features in the application interface to allow

the user to navigate the architecture such as filtering information or sort it.

Actually, there is a work in progress of loading the service architecture of each department, into the

EAMS software, and it was that that allowed us to verify the problems of large density of information and

large cardinality of entities and the need for different maps for different stakeholders.

1.2 Objectives of work

The main goal of this work was to gather and consolidate knowledge regarding this visualization

problem: the high cardinality of entities in the organization, the density of information, what has been

done in this field of work and how it supports the organizations in solving their problem. Based on that,

we proposed a solution that can be used as a foundation to develop those visualizations. We generated

4

and modified the current visualizations based on the graph theory model, specified the architecture

domains and developed a framework that can solve the problems regarding the organization, Servicos

Partilhados do Ministerio da Saude.

The solution was integrated in the EAMS, an enterprise architecture management system, owned and

maintained by Link Consulting.

1.3 Research Methodology

Computer science area is a vast field that includes the domain of IT and every researcher looks

for the best way to do their research in line with the main research methodologies. So I am going to

follow one of the most used methodologies for research in computer science, the Design Science in

Information Systems Research [8].

This frameworks provides the guidelines and principles in order to develop and validate a solution that

could solve the problem proposed. There is a series of guidelines that we must follow [8].

Guidelines Description

Guideline 1: Design asan Artifact

Design-science research must produce a viable ar-tifact in the form of a construct, a model, a method,or an instantiation.

Guideline 2: ProblemRelevance

The objective of design-science research is to de-velop technology-based solutions to important andrelevant business problems.

Guideline 3: DesignEvaluation

The utility, quality, and efficacy of a design artifactmust be rigorously demonstrated via well-executedevaluation methods.

Guideline 4: ResearchContributions

Effective design-science research must provideclear and verifiable contributions in the areas of thedesign artifact, design foundations, and/or designmethodologies.

Guideline 5: ResearchRigor

Design-science research relies upon the applicationof rigorous methods in both the construction andevaluation of the design artifact.

Guideline 6: Design as aSearch Process

The search for an effective artifact requires utilizingavailable means to reach desired ends while satis-fying laws in the problem environment.

Guideline 7:Communication ofResearch

Design-science research must be presented ef-fectively both to technology-oriented as well asmanagement-oriented audiences.

Figure 1.1: Design-Research Guidelines Table

The result of this research is to create an artifact that will address an organizational problem, so

it must be described effectively, and enable the implementation of the application in an appropriate

domain [8]. This is the first guideline.

5

The second guideline states that the goal in this research is to consolidate and acquire knowledge

related to the technology-based solutions, what has been done in this field of study and what are the

main business problems around this. The related work in this thesis addresses this guideline.

For the third guideline, we must evaluate our solution to verify the utility, quality and efficacy of our artifact

design [8]. The business environment sets the requirements for the evaluation of the artifact. We need

to define the right metrics and the gathering and analysis of appropriate data. I will specify later how the

evaluation was performed.

In the fourth guideline, it states that this research must contribute with knowledge to this field of study,

more specifically, it contributes with [8]:

• The Design artifact - It is the implementation of our solution that is supposed to solve the orga-

nization problem. It can provide new knowledge to do this or will use existing knowledge in an

innovative way.

• Foundations - This research should create new models, methods or instantiations as a way to

create new knowledge to support the existing foundations.

• Methodologies - This means that the development and utilization of evaluation techniques and

metrics should contribute to the design-science research methodology.

The fifth guideline depicts the way the research should be conducted. It requires the application of rig-

orous methods in the construction and evaluation of the artifact at hand. Rigor is defined as ”adherence

to appropriate data collection and analysis techniques” [8].

This sixth guideline states that design science is iterative. This means that design is a search process to

discover an effective solution. It looks for the best or optimal design, taking in consideration the realistic

information systems problems. An heuristic search strategy can provide good means to develop the

solution in the business environment.

Finally, the last guideline will be addressed later, but it states that the research should address the tech-

nology and management-oriented audiences.

6

2Background work

Contents

2.1 Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Service Notion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Service Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Service Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

7

The problem lies in developing a service architecture visualization framework, so in this chapter, we

give an overview of what has been done in this field of study. The analysis of that work will give us some

insight to solve our problem. Initially, we provide an introduction to EA (Enterprise Architecture), what

a service is and what kind of modeling frameworks and tools there are in the current present. Before

going into specifics of the related work, we need to provide a background information so that we can

contextualize the reader.

2.1 Enterprise Architecture

According to The Federation of Enterprise Architecture Professional Organizations [9], EA is “a well-

defined practice for conducting enterprise analysis, design, planning and implementation, using a holistic

approach at all times, for the successful development and execution of strategy”. It provides a set of

architecture principles and guidelines to manage the organization according to four major domains [9]:

business, information, application and technology. When implementing an organization strategy using

an EA approach, it must be taken into account those principles. Enterprise Architecture also provides

essential artifacts such as requirements, specifications, guiding principles and conceptual models that

describe the path to implement the next step of evolution of the organization [9].

2.1.1 Enterprise Architecture Domains

The four major EA domains - business, information, application and technology - are represented

as architectures in the various EA frameworks. TOGAF [6] provides the following definitions which are

widely accepted by the scientific community.

• Business Architecture – it defines the business strategy, governance, organization and key busi-

ness processes. So, it describes how the organization functions, what business processes oper-

ate, which stakeholders are involved and what the business goals are.

• Information Architecture – or Data Architecture, provides the artifacts, models, relationships and

standards on how the data is manipulated by the Application Architecture. It must be aligned with

the business architecture data.

• Application Architecture – An Application Architecture describes the structure and interaction of the

multiple applications as groups of capabilities that provide key business functions and manage the

data assets. So by other words, the application architecture is necessary to process the data and

support the business processes. These applications are not computer programs, but are logical

9

groups of capabilities that manage the Information Architecture and makes the bridge between the

Business Architecture and the Information Architecture.

• Technological Architecture – it provides the set of components, whether physical or logical, on

which the global architecture infrastructure will be set. It’s a set of technology and systems where

the Application and Information components will be installed.

2.2 Service Notion

We will provide a formal description of what a service is, based on the Linda Terlouw’s PhD. [10]. But

before providing the description, we need to give an insight. It was based on three axioms that defined

all process of providing a service.

2.2.1 Operation Axiom

This axiom focuses on the actions of the actors within the organization and the results that come

from those actions. Like it’s stated here [10]:

Axiom 1. Actors perform two kinds of acts: production acts and coordination acts. These acts have

definite results: production facts and coordination facts respectively. By performing production acts,

actors contribute to bringing about the function of the organization. By performing coordination acts,

actors enter into and comply with commitments regarding production acts. An actor is a subject fulfilling

an actor role. Actor roles are elementary chunks of authority and responsibility.

But what are those production and coordination acts? Production acts are actions that deliver any kind

of good by the actor to their environment. Coordination acts is different from the production acts. Despite

being executed by the same actors, they don’t contribute to the production of those goods, but as the

name says, it coordinates the process of production.

2.2.2 Transaction Axiom

This axiom takes a deeper look into the coordination act [10].

Axiom 2. Coordination acts and production acts always occur in particular patterns. These patterns are

paths through one universal pattern, called transaction. The result of carrying through a transaction is

the creation of production fact.

This transaction occurs in three phases involving two actors, the initiator who starts and completes the

transaction, and the executor who realizes the production act. The phases are [10]:

10

• Order phase (O-phase) – In this phase the initiator and the executor try to reach an agreement

about the production fact that the executor is creating, as well of the time of creation.

• Execution phase (E-phase) – In this phase the product is developed by the executor.

• Result phase (R-phase) – And finally, in this phase the executor and the initiator reach an agree-

ment about the fact that has been produced.

This is called the basic transaction pattern [10] and it consists of the request, promise, state and accept.

Figure 2.1: DEMO Transaction Pattern [1]

There can be two states in this transaction. The requested state and the stated state [10]. The

requested state the executor can either promise the service or decline the request. In the stated state,

the initiator can either respond to the executor with acceptance or rejection. By allowing these acts, there

can be a third state, the discussion state. In this situation, the two actors try to negotiate a resolution. If

the transaction follows the standard pattern, we enter the standard transaction pattern. And finally we

have the complete transaction pattern that is composed by the standard pattern and four cancellation

patterns. These cancellation patterns are the revocation of a request act, promise act, state act or

11

accept act [10].

2.2.3 Distinction Axiom

This third axiom is concerned with the various abilities that a human being involve in the activities

that are being performed [10].

Axiom 3. Three distinct human abilities play a role in the performance of coordination acts and produc-

tion acts: the forma, informa and performa abilities.

• Forma – this ability deals with the form aspects of communication and information. This means

that the actors have a way to understand and communicate the information. This information can

be transmitted using a particular language that the initiator and the executor understand.

• Informa – this ability deals with the content aspects of communication and information. This means

that to communicate, the information should be formulated by the initiator so that the executor can

interpret it.

• Performa – this ability states that the executor and the initiator can create new information and

knowledge through communication between them.

2.3 Service Definition

Based on the complete transaction pattern, a service definition was found [10]: “A service is a

pattern of coordination and production acts, performed by the executor of a transaction for the benefit of

its initiator, in the order as stated in the complete, universal pattern of a transaction. When implement it

as the ability to:

• Get to know the coordination facts produced by the initiator

• Make available to the initiator the coordination facts produced by itself.”

This pattern can be applied to every actor in every organization. There’s also the concept of composite

service. This is a service that requires the executor to start other services. This happens when a

transaction is enclosed in other transaction. But this definition of service is very generic, since it applies

to human actors and IT systems. The difference is in the implementation of those services. IT services

are implemented by IT systems and human services by humans.

12

2.4 Service Architectures

Applications have been decoupling their interfaces from the implementation since it’s not practical

to make future integrations due to being tightly coupled [11]. Instead, a new architectural approach

was developed. Now applications are exposing service’s interfaces to be used by others, who don’t

need to know the implementation of it. This style of architecture, has been created as Service-Oriented

Architecture or SOA. With SOA, only the service interfaces are exposed and the service consumers are

insulated from the details of implementation. The SOA Reference Architecture provides key principles

[11], that will help envision the solution, in which it can be outlined the following principles:

• It should be a generic solution, so we should be able to apply this solution to any organization.

• It should promote and facilitate alignment between IT and business, since the IT will be able to

support the information systems in the business.

• Address multiple stakeholder’s perspectives. There’s no consensus in this topic, since it’s quite

troublesome to build a service architecture that every stakeholder can comprehend it.

• In terms of layers, it should be minimum, to reproduce all possible combinations and elements of

the architecture.

2.4.1 SOA basic concepts - Logical and physical services

Physical or run-time services belong to one of the following architectures, physical or deployment

architecture, that are executing in the Operational Systems Layer [11]. A logical service is just represen-

tation of a repeatable activity that has a specified outcome. It’s considered black-box [12]. The physical

service will realize the functionality that the logical service represents. This service types will be neces-

sary to model the architecture in terms of visualization since it makes a differentiation in terms of what

the stakeholder wants to see.

13

3Related Work

Contents

3.1 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

15

3.1 Related work

With the background work specified, we can now go into the details of actual related work that can

help us.

3.1.1 Modeling Frameworks

In this section there will be depicted some modeling frameworks that widely used in the corporate

environment and will serve as a foundation for our work.

3.1.1.A UML - Unified Modeling Language

UML [13] is a visual modeling language whose purpose is to design the architecture component of

a system. It specifies the relations between each component, the properties that characterize them

and what functions does it has (it’s also called methods, since originally UML was design for software

systems). It captures information about the static structure and dynamic behavior of a system.

A – Represent a SOA Architecture in UML When presenting a Service-Oriented Architecture using

only logical services, it’s possible to use UML to model it [14]. The class diagram is a decent model to

represent relationships between services and its components. Those relationships are used by many

modeling languages which will be referenced later.

17

Figure 3.1: UML relationships [2]

This figure describes the relationships that can be used between the entities in the model, and its

notation.

In the following figure, it’s represented a service architecture.

18

Figure 3.2: Service Architecture example modeled in UML

Each box represents either a service or an application component. Using the table previously refer-

enced, it’s possible to verify what relations are between each component/service.

Those relations are used widely by many Enterprise Architecture modeling frameworks.

B – Problems with the UML framework UML is a modeling language more directed for classes,

which would be good for modeling the metamodel, but not so good to model a service architecture. As

you can see in the figure 3.2 there’s too many entities in the visualization and it turns the visualization

quite confuse and complex. UML doesn’t provide any mechanism for navigate across the visualizations.

We won’t even consider UML as a modeling framework to take into consideration while developing a

solution.

3.1.1.B Archimate

Archimate is a visual language to describe the enterprise architecture of an organization [7]. It

provides a uniform representation for diagrams that describe the architecture. There are two main

concepts in this modeling language. The elements that represent any entity in the architecture and

the relationships between those elements. Archimate adopted the relations from the UML notation with

some additions, as for the elements, it can be a little more complex. Archimate implements the concept

of layering and is based on the Enterprise Architecture discipline as expected. There are three layers:

19

• Business layer – depicts business services offered to customers and how they are structured inside

the organization

• Application layer – depicts application services that support the business and the applications that

realize them

• Technology layer – it represents all the technological infrastructure on which the applications exe-

cute

Those elements have a certain semantic associated, in which can be divided into three Aspects. An As-

pect is the “classification of elements based on layer-independent characteristics related to the concerns

of different stakeholders” [7].

• Active structure – represents the structural elements like business actors or application compo-

nents

• Behavior – represents the behavior that the elements in the Active structure perform

• Passive structure – it represents the elements on which the behavior is performed

Figure 3.3: Archimate Layers and Aspects [3]

With the Archimate Core Framework defined. The complete Archimate Metamodel can be specified.

See figure A.1 in appendix A.

This model specifies every element in the architecture and how those elements can communicate

with each other. There’s also a clear division between the business, application and technology layer.

20

The aspects of the framework are also depicted. The green elements belong to the passive structure,

the yellow elements to the behavior structure and the blue to the active structure.

A – Archimate Relationships Archimate re-use many relationships from the UML with some addi-

tions. Here’s the complete description [7]:

• Composition – this relationship explicitly states that the source element is part or completely com-

poses the whole of the target element.

• Aggregation – represents an element grouping other elements of the same type.

• Assignment – represents the allocation of responsibility, behavior or execution.

• Realization – indicates that more abstract entities are realized by more tangible entities.

• Serving – or “uses”, it means that an entity uses the other.

• Access – indicates that a process, function, interaction, etc., does something to a passive element,

like a data object.

• Triggering – describes a temporal or causal relationship between elements.

• Flow – represents the change of state, from one element to another.

• Specialization – indicates that an element is a particular kind of another element

• Association – represents a relationship that is not depicted by any other relationship.

• Junction – used to connect relationships of the same type.

21

Figure 3.4: Archimate Relationships [3]

B – Archimate Views and Viewpoints The Archimate specification defines “view, as a part of the

Architecture Description that addresses a set of related concerns and is tailored for specific stakehold-

ers” [7]. A view is specified by means of a viewpoint, which provides the concepts, model, analysis

techniques and visualizations [7]. A viewpoint specifies the concern for a certain stakeholder and it

provides the visualization that the stakeholder wants to see. It basically establishes the conventions for

developing and analyzing the view to approach the concerns specified by that viewpoint. Those conven-

tions include languages, notations, design rules, or modeling techniques to use on that view. When we

are creating a viewpoint, we need to follow two main steps [7]:

1. Select a set of relevant concepts from the Archimate Metamodel. Those concepts can be either

elements or relationships. You need to take into consideration the information that you need to

address the stallholders concern.

2. Define a representation to visualize those concepts in a way that can be understood by the stake-

holders.

When we apply a viewpoint to the architecture model, we are depicting the concepts on the first step

and represent it on the second step.

22

C – Service Realization Viewpoint The Archimate specification provides a Service Realization

Viewpoint that can be useful to our current work [7]. This viewpoint shows how business services

are realized by underlying processes and application components.

Figure 3.5: Archimate Viewpoint: Service Realization [3]

Elements that can be used in this view: Business actor, Business role, Business collabora-

tion, Business interface, Business process/function/interaction, Business event, Business service, Busi-

ness object, Representation, Application component/collaboration, Application interface, Application

process/function/interaction, Application event, Application service, Data object.

This viewpoint focus on the business realization and not so much on the services despite the name.

It provides the theoretical guidelines to develop the visualization but lacks on showing how to actually

define the visualization.

The following figure 3.6 depicts a service realization example:

Figure 3.6: Archimate Viewpoint: Service Realization example [3]

The business processes are realizing the business services that are being used by the actor, cus-

23

tomer.

D – Application Cooperation Viewpoint This viewpoint describes the relations between application

components in terms of the flow of information or what the services provide and use. It’s usually used to

create an overview of the application landscape of the organization [7].

Figure 3.7: Archimate Viewpoint: Application Cooperation viewpoint [3]

Elements that can be used in this view: Location, Application component/collaboration, Appli-

cation interface, Application process/function/interaction, Application event, Application service, Data

object.

This viewpoint is more useful than the previous one, since in future visualizations, the stakeholder might

want to see these elements on the architecture, so it’s something to take into consideration.

The following figure 3.8 represents a set of applications cooperating to realize the business pro-

cesses.

Figure 3.8: Archimate Viewpoint: Application Cooperation viewpoint example [3]

24

E – Problems with the Archimate Framework Archimate is a modeling framework specific for de-

veloping enterprise architecture visualizations, which would be ideal, but it’s a very technical language

that doesn’t appeal to the large set of stakeholders nor it provides navigation mechanisms. Large or-

ganizations with large service architecture will have archimate models that are unreadable due to the

enormous size those visualizations get.

3.1.1.C TOGAF Framework

TOGAF is a framework developed by “The Open Group” and has a set of concepts that can be used

to approach our visualization problem. TOGAF is a valuable tool for developing a broad range of different

IT architectures. Most importantly, it enables you to design, evaluate, and build the right architecture for

your organization. The key to TOGAF is a reliable, proven method - the TOGAF Architecture Develop-

ment Method (ADM) - for developing an IT architecture that meets the needs of your business. TOGAF

uses the concept of Viewpoint [6] to present the architecture from different perspectives. It’s the specifi-

cation of conventions for constructing and using a View. A View [6] is the representation of a related set

of concerns. It’s what is seen from a Viewpoint. An architecture view may be represented by a model

to demonstrate to stakeholders their areas of interest in the architecture. And so, according to TOGAF,

an architecture view [6] is the selected parts of one or more models that represent a complete system

architecture, focusing on those aspects that address the concerns of the stakeholders.

Figure 3.9: TOGAF Viewpoint [4]

In this figure, it is depicted what are the stakeholders, what’s their concern and the modeling tech-

niques that can be used to create a visualization that supports those concerns. It doesn’t provide visual

insight, as the Archimate, but the concepts and guidelines that will serve as a foundation.

A – Problems with the TOGAF Framework TOGAF is not a modeling framework but an enterprise

architecture framework so it provides guidelines to develop architectures and the correspondent visual-

izations, so we can only draw some guidelines that can help us developing a solution.

25

3.1.2 Modeling Tools

In this section, we will refer a few modeling tools that are widely used to model enterprise architec-

tures.

3.1.2.A Enterprise Architecture Visualization Tool Survey

This is a technical report that contains a wide state-of-the-art in EA visualizations and its tools to

support it [15]. It has a vast view-driven approach to EA modeling that states how to create and configure

a visualization, what are the visual parameters, the layout, storing and restoring a configuration, set up

and adapt the EA information model and data importation.

A – Create and configure a visualization So we need to find out if a binding to information is hard-

coded or loosely coupled. When it’s loosely coupled, it has the ability to employ a visualization type in

order to display arbitrary model elements in an EA information model [15]. This can be achieved using

either schema bindings of filter bindings.

• Schema bindings – it binds a visualization type to an instance of a particular class, attribute rela-

tionship, etc.

• Filter bindings – it filters an existing schema binding by attributes values or customized formulas.

B – Create a visualization This creation of visualizations can be achieved in multiple ways. The

authors asked several tool vendors which of the following approaches they supported [15]:

• Model driven – this “refers to visualizations that are generated based on data binding to a certain

information model”.

• Formed based – it “refers to a wizard which guides the user through the configuration and gener-

ation process of a particular visualization type”.

• Scripting – it uses special languages that are called domain specific languages that can be used

to program a visualization.

• Manual drawing – from a visual perspective it’s quite powerful and flexible way to display informa-

tion but it’s very time consuming and not very practical.

C – Visual parameters They asked the vendors what were the customization capabilities that are

most important in a visualization and the vendors replied [15]:

26

• Font

• Color

• Orientation

• Position

• Shape

• Size

D – Layouting There’s a comparison between model-driven approaches, which uses an automated

layouting, and manually layouting. Despite manual drawing could be combined with manual layouting

mechanisms, it’s not very practical for a computing device to use it. There’s the possibility to combine

manual layouting with automation.

E – Set-up and adapt the EA information model hey asked the vendors if their EA tool had a

predefined EA information model and they replied that can be either [15]:

• Full schema – This is the best practice guide.

• Configurable building blocks – But this can be adapted to the organization context which is more

appropriate to apply to several different organizations.

In terms of flexibility, the schema elements that can be extended or adapted are [15]:

• Classes

• Attributes

• Relationships

• Cardinality constraints

• Type constraints

• Access rights

And the operations that support those elements are [15]:

• Create

• Modify

• Delete

• Copy/clone – it’s the ability to create a deep copy of the element model. It refers to the class,

attributes, relationships as well as the data level, such as objects, values and links.

27

• Merge – it’s the ability to create an element model based on the information that two or model

elements contains.

• Move – it’s the ability to move objects or classes within a model. It’s quite dangerous since the

user can be unaware of that entity inheritance.

This is a conceptual framework for EA visualizations that can be quite useful for us to develop our

visualization since it provides several concepts on how to do it.

F – Visualization Types The authors asked several tool vendors to submit a list of up to 100 screen-

shots and descriptions to demonstrate the visualization capabilities of their EA tools. They clustered the

visualizations into different groups and developed a simplified version of a EA layer perspective. They

also specified what were the target stakeholders for each visualization [15].

Figure 3.10: Visualization Layers

From the several stakeholders referred, we choose the visualizations most accepted by the Enter-

prise Architect and Solutions Architect since they are the ones with highest knowledge and main interest

in a service architecture. The visualizations that had highest rate of utilization from these two stakehold-

ers were [15]:

• Matrix/Table

• Graph

• Entity-Relationship diagram

• UML

• Tree view

• Archimate

Matrix/Table

A matrix is a graphical representation of information. The information is represented in rows and columns

that are visually aligned. This is used to display information that is related with applications and business

aspects.

28

Figure 3.11: Matrix/Table Representation

Graph

It’s a graphical representation of entities and their relations. Each node in the graph is an entity and the

edges are the relationships between each entity. These visualizations are mainly used for application

and business layers.

Figure 3.12: Graph Representation

Entity-Relationship diagram

It’s a graphical abstraction of structural elements and respective relationships between them. Entities

are rectangles and relationships are connecting lines between entities. You can add attributes to entities.

Those attributes are represented as ellipses. These diagrams are mainly used to represent information

of the application layer.

29

Figure 3.13: Entity-Relationship diagram Representation

UML

As described in a previous chapter, UML is a modeling language that can be used for visualizing infras-

tructure or data structures. According to the surveys made by the authors, UML diagrams are mainly

used to display information of the application layer.

Figure 3.14: UML Representation

Tree view

It’s a graphical representation of hierarchical information that represents the information as a list of

items. To represent the hierarchy, it’s used an indentation. It’s mainly use to display information about

the application landscape.

30

Figure 3.15: Tree View Representation

Archimate

As described before, Archimate is an open and independent modeling language for enterprise architec-

ture. It represents structure, behavior and information for each layer in the Enterprise architecture.

Figure 3.16: Archimate Representation

G – Problems with the Enteprise Architecture Survey Tool This survey tool provides a set of

various languages and methods to develop several languages, either technical or more intuitive for non

experience users, but it doesn’t provide a method to unify a set of languages into one that can be

adaptable to all stakeholders and deal with large organizations.

3.1.2.B EAMS - Enterprise Architecture Management System

EAMS is a software developed by Link Consulting for managing enterprise architectures within an

organization. It works as a catalog for services but it has a visual component to represent it. This

modeling software uses the concept of Blueprint. A Blueprint is a graphical representation created

according to a set of rules defined by a ”Blueprint Type” and the parameter provided. Blueprint Type is

31

the implementation of the blueprint that can be designed through a visual tool designer integrated in the

EAMS or define the XML that represent the blueprint structure [16]. The parameter is an instantiation

of a Data Type. A blueprint is presented using boxes. A box represents an entity in the architecture or

just a generic container and it can have multiple boxes or entities inside it. This means there’s a relation

between the inner and outer box. When designing a blueprint, you specify the relations and the entities.

In the following image 3.17, it shows the blueprint designer.

Figure 3.17: Blueprint implementation design

This architectural tree specifies what will be shown in the visualization. You start by a root and do a

drill-down on the relations that you want to specify on each box.

32

Figure 3.18: Blueprint Explorer

The previous image 3.18 is a visualization of the blueprint and you can see the correlation between

the blueprint designer and an actual representation of it. These blueprints are static and the interaction

with the visualization is quite limited, since you can only navigate to other blueprints by setting a set of

navigation rules depending on the data type.

A – Blueprints As stated before, a blueprint is a graphical representation of a viewpoint. It shows the

Data Instances and containers that help structure the representation. There are four blueprints based

on the System Theory [17] that can support the service architecture .

Organic

We define a system as σ, so a Composition C of that system is the set of artifacts that [17]:

C(σ) = {x : x IsA Component ∧ x ≺ σ} (3.1)

The symbol ≺ represents ”is part of”.

33

x ≺ y if and only if, in order for y to be alive, x must also be alive and x cannot be part of another artifact

that y is not also part of.

This means that applications cannot share components and artifacts shared between applications

must have different nomenclatures [17].

A component must also have a formal description.

A given artifact c is a Application Component of a given Application a is and only if it complies with

the following conditions:

1. c is a subsystem of a. This means:

C(c) ⊆ C(a)

E(c) ⊆ C(a) \ C(c) ∪ E(a)

S(c) ⊆ S(a)

(3.2)

2. c is related with one and only one layer of a. Let p, q be two application layers of a. This means

that:

∀x : x ∈ E(p),@q 6= p : y ∈ E(q) ∧ y ∈ C(c) (3.3)

3. c is related with one and only one IT platform, the platform where the application components

execute.

A Composition is a set of elements of some category/type [5].

Context

The context blueprint is based on the System Environment of the Systems Theory [17]. An Environment

is a set of elements for the same category/type [5].

E(σ) = {x : x 6∈ C(σ) ∧ ∃y : y ∈ C(σ) ∧ (x→ y ∨ y → x)} (3.4)

The symbol→ means ”acts upon”. So in the previous formal representation, x and y can interact. [5]

Integration

This blueprint is based on the System Structure of the Systems Theory [17]. A Structure is a set of

influence bonds among the elements in the composition, and between them and the elements in the

Environment [5].

S(σ) = {< x, y > |(x→ y ∨ y → x) ∧ (x, y ∈ C(σ) ∨ (x ∈ C(σ) ∧ y ∈ E(σ)))} (3.5)

This means that two elements x and y act upon each other, or just one, and that both can be part of the

34

Composition, if they are not part of the Composition, then one must be part of it, and the other must be

part of the Environment.

Layer

This blueprint is not referenced in the Systems Theory, but it’s a variation of the Context Blueprint, so

the formal definition is this:

L(σ) = {x : x 6∈ C(σ) ∧ ∃y : y ∈ C(σ) ∧ (x 99K y)} (3.6)

The symbol 99K means ”Realization”. So, x realizes y.

B – Blueprint as a graph With all blueprints defined, we need to convert those formal definitions to

a graph that will support our visualizations.

We choose a graph as a theoretical representation of the architecture since it can represent entities and

relations between each entity.

A graph is a pair of (V,E) where V is a set of vertices or nodes and E is a set of edges that represent the

relationship between each vertice [18]. Those set of vertices represent instances of data types in the

architecture. The following picture 3.19 depicts a regular blueprint.

Figure 3.19: Regular Layered Blueprint

This blueprint 3.19 is mapped from the following graph 3.20.

35

Figure 3.20: Blueprint graph mapped from a regular blueprint

A container can be specified in the blueprint implementation, as a data instance or just a container

for other containers or symbols. A symbol is a data instance.

A data instance has a set of properties associated, according with the implementation of the metamodel

for each data type. So some parts of generating visualization of service architectures will be based on

those properties and what we can do to improve readability and interaction with the user.

These set of data types will be defined as Γ.

This set of relations between each container and the respective symbol will be defined as Ψ. So a formal

definition would be:

∃x, y ∧ (x, y ∈ Γ) ∧ (∃ →∈ Ψ) ∧ (x→ y ∨ y → x) (3.7)

So this means: ”There are two entities x and y that have a specific data type, and there’s a relationship

that belongs to our group of relationships, and there’s a relationship between x and y.” All of those

relations are defined in the metamodel.

C – Problems on the EAMS EAMS being an enterprise architecture management and visualiza-

tion tool, it’s not flawless and it doesn’t address all problems regarding the visualization of the service

architecture. The following figure 3.21 depicts a common problem.

36

Figure 3.21: Blueprint with high cardinality of instances

This is a common problem across large organizations that have large sets of entities and the EAMS

at the moment doesn’t have a mechanism to deal with with this level of cardinality. This makes the maps

unreadable since the user can’t assimilate such amount of information.

37

A similar problem happens with the relationships between entities in the blueprint as the figure 3.22

shows.

Figure 3.22: Blueprint with high cardinality of relations

The figure 3.22 shows a blueprint that’s useless due to the huge number of relations on the visual-

38

ization and doesn’t convey any information useful to the user and omits information on the visualization.

This is one of the challenges we had to face in order to solve our problem.

3.1.2.C Enterprise Architect (SparxSystems Ltd)

This visual and modeling tool is based on the UML. It supports several modeling languages such as

UML, Archimate, BPMN (Business Process Modeling Notation), Entity-Relationship diagrams, graphs,

and several other modeling languages. It’s a powerful tool that supports many languages and frame-

works and it’s relatively easy to use. This is an example of an Entity-Relationship diagram made using

this software tool.

Figure 3.23: EA SparxSystems editor tool

It also supports a many types of files. So the visualizations can be easily imported and exported in

many types, such as CSV, XML, TXT and more.

A – Problems on the Enterprise Architect Enterprise Architect being an editor, it supports several

modeling languages but the features of visualization it supports are transversal to every language. And

being an editor it focus much on the development of the visualizations and not the navigation, so there’s

no mechanism to interact with the visualizations. All languages supported by the Enteprise Architect

are technical languages that require some background knowledge about it, so we can’t expect a large

heterogeneity of stakeholders to understand it.

39

3.1.3 Alternative visualizations

Based on the book Visualization and Analysis [19], which is a book that provides an insight to every

type of visualization and guidelines about designing them and the correct way to interact with those vi-

sualizations, I will propose possible types of visualization that can be useful in defining the final solution.

The first one is the Force-Directed Graph [19]. This graph introduces the concept of cluster which is

simply a grouping based on the a common property description. In this case that property would be the

data type.

Figure 3.24: Force Directed Graph Example

In this graph, instead of using the color only, the edge would be represented with a technical symbol

based on the Archimate model, to represent the Data Type.

The Visualization and Analysis [19] book also have a different type of graph called the Tree Diagram. It

was previous referenced on the alternative to the Layer Blueprint section.

40

Figure 3.25: Tree Diagram Example

This graph has the concept of levels or layers. These layers represent the domain and Data Type of

the node. It provides an easy understanding of the layers in the service architecture.

Of course these visualizations would need to be adapted to our blueprints, since we cannot make a

direct mapping to those visualizations. The Context Blueprint as we see, contains several Data Types.

To represent that kind of blueprint, I will not discard the current solution used by the EAMS, the container

in a way is a cluster as shown on the Force-Directed Graph, and is useful to represent many groups of

different Data Types.

3.2 Considerations

All of the tools and frameworks have different approaches to visualize an architecture, but there’s not

a single one that can solve the problems at hand.

As we can see on the table 3.1.

Table 3.1: Table that cross the problems with the tools and frameworks

Tools and frameworks

Problems EAMS Enterprise Architect(SparxSystems)

Enteprise ArchitectureTool Survey TOGAF Archimate

High cardinality of instances × × � × ×High cardinality of relationships × × � × •

Disperse information � × × × ×Heterogeneity of stakeholders • � • × ×

41

The following list, shows the meaning of each symbol.

• Solves the problem - •

• Partially solves the problem - �

• Doesn’t solve the problem - ×

Disperse information is a vague term but it means that the modeling tool/framework can provide

mechanisms to create and visualize service architectures easy to read and interact with the visualization

according to a set of properties of the data instance in question. High cardinality of instances is a key

problem since there’s no solution to solve this problem across the various frameworks/tools. The same

problem happens with the relationships between each entity.

Regarding the heterogeneity of stakeholders, EAMS provide a designer that allows the user to develop

any kind of visualization according to the need of the stakeholder.

As a whole, it hasn’t been done much regarding this problem since all organizations have different

points of view, so they choose different frameworks and tools. And each organization tries to solve their

problems with specific solutions and not something generic like it should be.

42

4Solution

Contents

4.1 Collapse containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2 Filter blueprints based on properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3 Sorting instances by property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.4 Filter the blueprint relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.5 Defining blueprints to support the SPMS organization . . . . . . . . . . . . . . . . . . 71

4.6 Final considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

43

In this section, the goal is to present a set of features that aim to modify the representation of

the service architecture. These modifications will improve the readability, the amount of information

displayed to the user, allow the user to navigate according to the metamodel of the architecture and

present a set of maps to visualize the service architecture of the enterprise Servicos Partilhados do

Ministerio da Saude. The solution will be based on the Graph Theory, which is the structure to allow us

build blueprints.

The problems that were addressed were:

• Large cardinality of data instances

• Large cardinality of relationships between data instances

• Disperse Information

These problems were assessed with the stakeholders around this thesis. Which were my Professor and

my Senior consultant, which had significant impact in developing this thesis. To address these problems

we developed several solutions.

• Collapse - This consists in collapsing a container of data instances. This allows to hide containers

with high cardinality of instances that makes the map more simple to understand and navigate.

• Sorting - This addresses the problem of dispersed information. We allow the user to sort ascending

or descending according to a certain property of a certain set of data instances. This gives the

user other perspective and insight to the organization.

• Data instances filter - This addresses the high cardinality of instances in the visualization. We

allow the user to visualize only the instances he wants, according to a given property chosen by

the user.

• Relationships filter - This addresses the high cardinality of relationships in the visualizations. The

principle of the filter is the same. We allow the user to choose the type of relations we wants to

filter.

• Specific visualizations according to the organization - Every organization has its own service ar-

chitecture, so we developed maps to address this need. This addresses the large heterogeneity

problem, since all maps address a certain stakeholder need.

4.1 Collapse containers

One of the problems of service architectures stated before is the large cardinality of data instances

in the blueprints, which makes the blueprint useless since the readability is affected and the user can’t

understand the point the blueprint is trying to convey. The following blueprint 4.1 depicts this problem.

45

Figure 4.1: Structure and Deploy Blueprint - Original blueprint

The idea was to modify the initial algorithm that calculated the layout of the blueprint in the canvas,

so that we could collapse the containers that had a certain amount of symbols.

This number will be defined as α . This number is a parametrized value that can be previously defined

by the developer to adjust to the client’s need.

The algorithm to populate the blueprint was modified to this:

Algorithm 4.1: Redraw blueprint algorithmInput: Graph, αOutput: Graphfor v in Graph do

if v.type = ”container” thencount← countSymbolsFunction(v)if count > α then

collapseContainer(v)

After drawing the blueprint, we need to iterate the graph in this case, in order to collapse containers

that don’t meet the condition set in the algorithm. For each node, or container, that doesn’t fit the

46

condition, we call a function collapseContainer.

Algorithm 4.2: Collapse a container functionFunction collapseContainer (node)

if node.IsCollapsed() = true thennode.collapsed← falsenode.graphical.height← calculateNewHeight(node)refitBrothersNode(node.parent , node)refitParentNode(node.parent)

elsenode.collapsed← truenode.graphical.height← calculateNewHeight(node)refitBrothersNode(node.parent , node)refitParentNode(node.parent)

The following function is used in the algorithm to count the number of symbols inside a container.

Algorithm 4.3: Calculate number of symbols inside a containerFunction countSymbolsFunction (node)

ArrayOfChildren← node.Childrencount← 0for v in ArrayOfChildren do

if v.type = ”symbol” thencount = count + 1

return count

This is the main function that modifies the blueprint and effectively collapses a container. Notice that

this function verifies if the container is collapsed. This is because it was integrated in the interface a

button for each container that allow us to collapse or expand a container, but we will extend this matter

later.

And we also call two functions in this collapsing algorithm. The refitBrothersNode function normalizes the

other containers (if there are any) that share the same parent container and are on the same level. This

keeps the blueprint layout balanced without gaps between containers. And then the refitParentNode

function, redraws the parent container according to the new height set on the inner containers. The

following blueprint 4.2 depicts the refitBrothersNode function.

Figure 4.2: Solution Organic Blueprint - Refitting brother container

We can see that the all containers within the same level, share the same height. The following

blueprint depicts the refitParentNode function. We can see that the parent node’s height was modified

according to the height of the children nodes.

47

Figure 4.3: Solution Organic Blueprint - Refitting parent container

The parent container adjusted its height to fit the sum of heights of the inner containers.

Algorithm 4.4: Calculate the new height of a containerFunction CalculateNewHeight (node)

if node.IsCollapsed() = true thenβ ← predefinedEmptyContainerHeightreturn β

elseweight← node.weightsymbolArraySize← node.Childrenβ ← calculateHeightBasedOnSymbols(symbolArraySize, weight)return β

This function does not calculate the final height of the container, since it’s the refitBrothersNode

function that does that. It will only be the final height if that would be the container with most inner

nodes.

4.1.1 Collapse containers manually

After the blueprint has been redrawn with the necessary collapses, we need to provide the user with

the choice to expand the containers he wish to see or collapse others. We also provide an additional

information with the number of symbols inside that container if it’s collapsed. That prevents the user to

expand a container with an enormous amount of symbols that has no interest to him.

48

Figure 4.4: Collapse Interface button

This feature is quite useful to deal with blueprints with large cardinality of symbols, that makes the

map unreadable.

4.2 Filter blueprints based on properties

When the stakeholders are visualizing the the architecture, they have some needs in terms of identi-

fying instances with certain properties. The following figure 4.5 depicts a regular blueprint with no filter

application.

49

Figure 4.5: Regular blueprint before applying filter

As stated before, a blueprint is a graph of data instances, so we needed to develop an algorithm to

iterate the graph and display only the data instances that satisfy the condition inserted.

Algorithm 4.5: Filter blueprint by property algorithmInput: Graph, condition, property, dataType, valueOutput: Graphfor v in Graph do

if v.type = ”symbol” && v.dataType = dataType thenif v.property = property && v.isShown() && checkConditionWithValue(condition, property,value, property.value) thenshow(v)

elsehide(v)

To apply a filter, there’s a list of arguments the algorithm needs, besides the graph.

• Condition - This condition depends on the type of property.

50

• Property - This is the property of the data type selected.

• Data Type - The data type from which the filter will be applied.

• Value - It’s the value inserted by the user to filter the data instances.

The algorithm is quite simple. After receiving all arguments, the algorithm iterates the graph, and

when a condition is met, it runs a graphical function show(). This function simply displays that node, or

graphical instance, on the blueprint. If it’s already displayed, it doesn’t do anything. Now if the condition

isn’t met it runs the graphical function hide() that removes a graphical instance from the blueprint.

The following picture depicts a blueprint after a filter has been applied.

Figure 4.6: Regular blueprint after applying filter

4.2.1 Applying multiple filters

The user has the choice of applying more than one filter due to various reasons. The first reason

would be that the blueprint has more than one type of data types, he should be given the choice of

wanting to apply a filter to other types of data instances.

Another reason would be wanting to filter the already filtered graph, by other properties.

All these reasons lead to the user having the choice of customization the information he wishes to

51

visualize [19]. This also meets the problem of cardinality and dense information since we enable the

user to remove all information that’s not necessary when filtering by a key (data type property).

4.2.1.A Algorithm to apply multiple filter

The algorithm to apply multiple filters is quite simple. It receives the graph and iterates the graph the

number of filters, to apply each filter.

Algorithm 4.6: Apply multiple filters algorithmInput: Graph, filtersArrayOutput: Graphfor f in filtersArray do

applyF ilter(f,Graph)

The applyF ilter function is specified in the algorithm 4.5.

4.2.1.B Multiple filter layout

The following figure 4.7, shows the possibility of having two filters at the same time.

Figure 4.7: Filter layout with two filters

The interface also allows the user to remove any filter on the list, in order to keep the others persistent.

4.2.1.C Filter example

To show the interface and usability, we present here a set of steps that demonstrate how the filter

interface works. So for a certain blueprint, we are going to apply a filter.

The figure 4.8 is the blueprint before applying a filter.

52

Figure 4.8: Filter Demonstration - Blueprint before applying filter

In the figure 4.9, shows the interface of the filter.

Figure 4.9: Filter Demonstration - Opening the filter interface

In the next step 4.10, we select the class we want to apply the filter.

53

Figure 4.10: Filter Demonstration - Step 2 - Select the class

In this next step 4.11, we select the property.

Figure 4.11: Filter Demonstration - Step 3 - Select the property

This step 4.12, we select the operator. This operator can vary depending on the type of property.

54

Figure 4.12: Filter Demonstration - Step 4 - Select the operator

And in the next figure 4.13, we insert the value of the property and we add it to the filter list.

Figure 4.13: Filter Demonstration - Step 5 - Enter value and add the filter to the list

In this next figure 4.14, we see the filter list with our filter instance, with its appliance.

55

Figure 4.14: Filter Demonstration - A filter instance and its appliance

The filter is simply highlighting the instances that are in conformity with the filter.

As we can see, the interface provides an easy interaction with the system, that doesn’t need any

expertise to use it.

4.3 Sorting instances by property

According to Munzner [19], sorting is ”a powerful choice for finding patterns in a dataset by inter-

actively changing the attribute that is used to order the data”. By standard, the information display is

ordered by alphabetic order, and what we propose is to give the user the choice of ordering the data

instances by a property they see fit.

The following figure 4.15 is a blueprint graph that is ordered by levels. It will help us to explain how the

sorting algorithm works.

Figure 4.15: Blueprint graph by levels

56

Each container has the option of ordering the elements inside it. Whether it is containers or symbols,

but that arose some issues. If the user chooses to sort a container, he must face with the fact that inside

there could be containers of different data types or even containers that have no data types associated

(this is specified in the definition of the blueprint). So, when we see the list of properties to sort, it could

vary. There was also another problem: Should the user be able to sort all levels below the one he

selected?

By approaching the first problem, we had to deal with these constraints:

• Different data types of containers

• Containers with no properties associated, due to not having data types associated

So, what was decided was that if a container meets one of the conditions above, the only property that

he could sort, was by alphabetic order. As you can see the blueprint below 4.16:

Figure 4.16: Blueprint containers with no properties associated

The other problem we had was the levels of the graph. If I choose to sort a container, will I want to

sort only the children of that node, or all children below that level, recursively? By choosing the second

option the chance of the first problem appear would increase greatly, since we are expanding our depth

in the graph, therefore encountering different types of containers. So the solution would be to only sort

the immediate children of the node selected, and provide the list of properties of the data type, if all

children are from the same data type.

57

To sort symbols the logic is the same, but since all symbols inside a container are always from the same

data type, then there’s no problem.

There’s also a small issue so that we implemented a preventing mechanism. What if I choose to sort by

a certain property and a data instance doesn’t have that property populated. So by default, that property

will assume the smallest value where by ascending or descending, so it always stays in the last place. If

there are more than one data instance with no property populated, the order is by alphabetic order.

4.3.0.A Types of properties

A data type can have an indefinitely number of properties associated, but the types of properties are

limited. This is the current list property types.

• References - This is a list of references to other data instances. It depends on the relationship

assigned to that property.

• Text - A simple string.

• Date - As the name says, it’s a date set by day, month, year.

• Numeric - It’s a number.

• Boolean - It can assume two values, true or false.

There are two types of types that sorting doesn’t work. References and booleans. References can’t

be sorted, since they aren’t raw types of data, and are simply a list of data instances. And booleans

aren’t ordered attributes but nominal attributes [19], so we can’t sort it. So the types of properties we

can sort are: Text, Date and Numeric.

4.3.0.B Layout of the sorting interface

The following picture 4.17 shows the sorting interface.

58

Figure 4.17: Sorting Interface

4.3.0.C Sorting example

In this section we show the steps that demonstrate the sorting interface usability.

In this example we are going to sort this container by the ”Deprecated Date” property, in descending

order.

The following figure is the container before sorting 4.18.

Figure 4.18: Sorting Demonstration - Container before sorting

The first step is the select the button that opens the sorting interface 4.19.

Figure 4.19: Sorting Demonstration - Step 1 - Click the sort button in the container

59

The second step is to select the Deprecated Date property from the list 4.20.

Figure 4.20: Sorting Demonstration - Step 2 - Select the property to sort

The next step is to select the order of sort, in this case, Descending 4.21.

Figure 4.21: Sorting Demonstration - Step 3 - Select the order of sorting

Now, we apply the sorting by clicking the button Apply Sort 4.22.

Figure 4.22: Sorting Demonstration - Step 4 - Apply the sort

The following figure 4.23 depicts the container after the sort has been applied.

60

Figure 4.23: Sorting Demonstration - Container after sorting

So now, we have a set of data instances sorted in descending order of the date of deprecation.

4.4 Filter the blueprint relations

Some blueprints show relationships between data instances, according to the implementation of its

blueprint. The following picture depicts the several relations that can occur in a blueprint.

Figure 4.24: Structure and Deploy Blueprint with relationships activated

But as we can see, there are so many relations on the blueprint that it’s hard to understand what the

blueprint is trying to convey. So we developed another type of mechanism in order to filter the relations,

but before that we need to provide a theoretical introduction about how the relations are defined.

61

4.4.1 Blueprint relationships definition

The relationships of a graph are can be different from the relations from the metamodel. These rela-

tions are specified in the blueprint implementation.

There are two types of relations - unidirectional and bidirectional - and depending on the blueprint im-

plementation, there can be relations between every type of graphical entity as the following figure 4.25

shows:

Figure 4.25: Types of relation between entities

Two approaches have been implemented regarding these relations. The first solution was to filter

the relations. So, to implement the filter, we need to define how we are going to filter. Since relations

by a single data instance already exist, the idea was to divide the origin/destination into two groups:

The generic containers and data types. This means we can choose to represent on the blueprint,

relationships that have a origin/destination in a specific container or relationships that point to a certain

data type, for example, relationships that point to Applications.

The second approach was to find and outline a path from an entity given a depth, but we will it explain

later.

4.4.2 Relationships filter flowchart

With the types of origin/destination of each relationship and the types of direction of the relation

specified, we can now provide a flowchart 4.26, that specifies how the user interacts with the system.

62

Figure 4.26: User Relationship Filter Flow chart

The selection of the filter is quite linear. The user first selects the origin type of the relation. He then

selects if the relation is unidirectional, bidirectional or any of them. If it’s unidirectional the arrow goes

from the origin to the destination. If it’s bidirectional, then the origin/destination order is irrelevant. After

the user selects the direction, he then selects the destination type as he did for the origin.

63

4.4.2.A Algorithm to filter relations

We now have the arguments to filter the blueprint. The set of relationships are defined in the system

as an array of relations, so we just need to iterate that array with our arguments.

Algorithm 4.7: Filter relationships algorithmInput: relationsArray, originType, destinationType, directionTypefor r in relationsArray do

origin← r.originNodedestination← r.destinationNodedirection← r.directionTypeoriginParent← origin.getParent().T ypedestinationParent← destination.getParent().T ypeif direction = ”unidirectional” then

if origin.Type = originParent && destination.Type = destinationParent thenr.showRelation()

elser.hideRelation()

else if direction = ”bidirectional” thenif origin.Type = originParent && destination.Type = destinationParent or origin.Type =destinationParent && destination.Type = originParent thenr.showRelation()


elseif origin.Type = originParent && destination.Type = destinationParent or origin.Type =destinationParent && destination.Type = originParent thenr.showRelation()


The algorithm receives four arguments, the array of relationships, the origin and destination type,

whether it’s a generic container or a data type and the type of direction. It then verifies the direction

of each relation. If the relation is unidirectional then the origin and destination will be unequivocal. If

it’s bidirectional, then there’s no origin nor destination, so we have to verify both ends of the relation. If

there’s no relation direction specified, then it doesn’t matter what it is, so all types of direction count.

After verifying the direction, we check the parents container type. It simply verifies if the arguments match

the parameters of each relation in the array. If the condition checks out, it runs a method showRelation()

that is a graphical function to show the relation on the screen. If not, it executes the hideRelation() that

does the opposite.

4.4.3 Calculate relationship path of an entity given a depth

In service architecture there’s a great component of integration between services, which creates a

lot of dependencies between services, so when a service change, the user wishes to know the impact it

64

will have on the other services that depend on it.

In the blueprints, depending on the implementation, there are blueprints that depicts those dependen-

cies, so we are reusing and improving that feature. To show an example, here’s a blueprint with relations.

Figure 4.27: Blueprint with relationships

There’s a large cardinality of relations on the blueprint and it’s hard to determine what are the data

instances that depend on a given data instance. Here’s a graph 4.28 that depicts this problem.

65

Figure 4.28: Graph that shows various dependencies in a blueprint

It hards to look at this graph and determine all nodes that depend on a given one. What I propose is

a feature that allows the user to select a data instance and the level of deepness he wishes to visualize

and highlight all relations. This way the user can determine what are the data instances that depend on

the one provided.

For example, if the user selects a data instance with a level 2 of depth, it would look like this 4.29.

Figure 4.29: Graph with relations and data instances highlighted for a depth of 2

The selected node was the red one and the algorithm calculated and highlighted the path of relations

for a given depth. Now the user can see what services depend directly or indirectly on that data instance.

This works for relations going outwards, inwards or both ways. In the example given above, we used an

outward algorithm, but in this next chapter we provide the algorithm to calculate that path.

66

4.4.3.A Algorithm to calculate path

In this section we provide the algorithm that receives as input the direction, data instance and the

depth to calculate the path and highlight it for the user.

Algorithm 4.8: Calculate path algorithmInput: direction, entity, depthif direction = ”in” then

searchInDepth(depth, entity)

if direction = ”out” thensearchOutDepth(depth, entity)

elsesearchInDepth(depth, entity)searchOutDepth(depth, entity)

Algorithm 4.9: Calculate path for in relationsFunction SearchInDepth (depth, source)

if depth = 0 thenreturn

relationsArray leftarrow getRelations(source, ”in”)if relationsArray.size = 0 then

returnfor r in relationsArray do

highlightPath(r)searchInDepth(depth− 1, r.sourceId)

Algorithm 4.10: Calculate path for out relationsFunction SearchOutDepth (depth, source)

if depth = 0 thenreturn

relationsArray leftarrow getRelations(source, ”out”)if relationsArray.size = 0 then

returnfor r in relationsArray do

highlightPath(r)searchOutDepth(depth− 1, r.destinationId)

4.4.3.B Highlighting path example

Here we demonstrate how the interface works and the final result. We start with this layered blueprint

4.30.

67

Figure 4.30: Layered blueprint with high cardinality of relations before calculating path

From this blueprint, we will search in depth, the data instance AM Development, see figure 4.31.


In every data instance there’s a context menu that present us all interaction we can do individually

68

with each data instance. See figure 4.32


We then select the Calculate connection Route, which will open the interface 4.33.


69

In this interface, we can select the depth level and the direction of relations to calculate the path to

be shown on the figure 4.34.


70

With this path highlighted we can determine what entities depend on the AM Development service.

4.5 Defining blueprints to support the SPMS organization

All features specified before are generic solutions that can improve the user experience while visual-

izing any kind of blueprint in any organization but since we are doing this thesis in the context within the

organization, there was a need to develop some maps, or blueprints, that were fitted to the organization’s

internal structure.

The SPMS, Servicos Partilhados do Ministerio da Saude is an organization that develops IT solutions

for the public health care institutes. The organization wishes to visualize their service architecture ac-

cording to the internal organizations, so before presenting the developed blueprints, we need to provide

an insight of the internal organization of the SPMS.

4.5.1 SPMS internal organization and blueprints definitions

The SPMS has several internal departments that develop different IT solutions for the public health

care institutes. The following departments are managed and aggregated by an actor, DSI - Direcao de

Sistemas de Informacao:

• AIPI - Unidade de Coordenacao de Arquitetura, Interoperabilidade e Projetos Internacionais

• GQS - Unidade de Coordenacao de Gestao da Qualidade de Software

• GSS - Unidade de Coordenacao de Gestao de Servico e Suporte

• OSI - Unidade de Coordenacao de Operacoes, Seguranca e Infraestruturas

• PIC - Unidade de Coordenacao de Plataformas de Integracao de Cuidados

• RN - Unidade de Coordenacao de Registos Nacionais

• SIAG - Unidade de Coordenacao de Sistemas de Informacao de Apoio a Gestao

• SLICA - Unidade de Coordenacao de Sistemas Locais de Informacao Clınica e Administrativa

• SLICA CSP - Unidade de Coordenacao de Sistemas Locais de Informacao Clınica e Adminisitra-

tiva CSP

• SPD - Unidade de Coordenacao de Sistemas de Prescricao e Dispensa

• SSPES - Unidade de Coordenacao de Plataformas de Sistemas de Suporte a Programas Estru-

turais de Saude

But not all of those units, develop IT solutions. The AIPI, GQS, GSS and OSI, support the internal

organization business process, and don’t have the goal of producing solutions. All other units develop

71

IT solutions.

The development of this maps was in line with the stakeholders need, so we had a constant feedback

from the user, and had access to the internal documents of the organization.

One of the most essential maps was the Solution Organic blueprint, that represents the solutions pro-

duced and managed by each unit, inside the SPMS. The root is the DSI - Direcao de Sistemas de

informacao which is the one that aggregates all units inside SPMS. The blueprint instantiation is de-

picted in the following figure 4.35:

Figure 4.35: Solution Organic Blueprint of SPMS

The following list depicts the structure of this blueprint.

• DSI - Direcao de Sistemas de informacao

– DSI internal departments

∗ IT solutions produced by each internal department

This blueprint was developed in line with the architect of the SPMS that provided us the internal organi-

zation and how they manage each solution.

This is in terms of providing the IT solutions. But now we need to specify the organization structure

of the public health care institutes, since they are the ones using those applications.

• ARS - Administracao Regional de Saude (Regional health administration)

• ACES - Agrupamento de Centros de Saude (Group of health centers)

72

• ULS - Unidade Local de Saude (Local unit of health)

• CS - Centro de Saude (Health Center)

• Unidade Funcional (Functional Unit)

• Utente (Patient)

• Fornecedor (Supplier)

• Centro Hospitalar (Hospital Center)

There are five independent ARS: Algarve, Alentejo, Centro, Norte and Lisboa e Vale do Tejo. Since they

are managed independently, there’s no need to aggregate all actors in a unique blueprint.

Each ARS is composed by ACES, ULS and Centros Hospitalares.A ACES is composed by Centros

de Saude. A ULS is composed by Centros de Saude and Centros Hospitalares. A Centro de Saude

is composed by multiple Unidades Funcionais. So what we are having here is an hierarchy of entities

where the ARS is the root.

The instantiation of the blueprint is shown in the figure 4.36.

Figure 4.36: Actor Organic Blueprint of ARS

The organization is summarized in the following list:

• ARS - Administracao Regional de Saude

– ACES - Agrupamento de Centros de Saude or ULS - Unidade local de Saude

∗ CS - Centro de Saude

73

· Unidade Funcionais

To develop this blueprint, we assessed multiple spreadsheets that contained more than 3000 entities,

and we processed those spreadsheets to generate a blueprint for each ARS.

With two blueprints defined, Solution Organic belonging to the SPMS and an Actor Organic of the

ARS’s, we need to define a Solution Organic adapted to the needs of the ARS. Since the ARS’s are

the clients, they wish to visualize their architecture in terms of their internal business needs and not the

SPMS’s. After some inquiries with an architect in the SPMS, it was defined that the business needs are

divided in:

• Clınico - This refers to the applications used by the medical staff.

• Laboratorio - This is the set of application used by the laboratory technicians.

• Utente - This refers to the patient,

• Administrativo - It’s the set of applications that the front desk clerks use.

• Apoio a gestao - It’s the portfolio of management applications.

Each ARS has two sets of applications. The ones provided by the SPMS, and others by external suppli-

ers to satisfy their specific needs.

We divided into two groups, the solutions provided by the external providers, and the solutions provided

by the SPMS. The following picture 4.37 is a Solution Organic Blueprint of the ARS Algarve. We can

see it is separated into supplier’s groups and inside each container, a division according to the business

needs.

74

Figure 4.37: Solution Organic Blueprint of ARS

This blueprint was developed from some surveys provided by each ARS and how they managed their

solutions.

And the last blueprint developed was the Business Process layered - SPMS. This map conveyed how

each business processed was realized, what business objected it used and what actors interacted with

those processes. The following blueprint 4.38 shows the business process layer for the business process

Realizacao-MCDT.

75

Figure 4.38: Business Process layered - SPMS

This map was developed based on Archimate models and approved by the architect inside the SPMS.

4.6 Final considerations

The solution presented consisted in a set of features to help visualize any service architecture of any

organization, since those are generic solutions that meet the problems the SPMS has. The filters give

the user an easy tool to explore the architecture. The collapse allows the user to hide or show information

of interest, or not, to him. The sorting feature, gives the user a way to compare instances given a certain

property, for example, the user could sort a set of data instances by cost, from the cheapest to the most

expensive.

The relationships filter were not implemented due to time and software constraints, but the value it adds

is the ability to give the user the choice of only showing some relationships based on certain properties,

in this case, the containers to where they point and the type of relations.

The last feature developed, the Calculate and highlight path based on depth is more than a visual

feature. It actually allows the user to see the dependencies of each data instance, and how far it affects

other entities. Before this feature, it was literally impossible to determine those entities on blueprints with

76

large cardinality of instances and relationships.

But the most important feature were actually the maps developed, since they portray the architecture

of the organization and help the stakeholders to have an insight of the organization. The features

developed help the user to navigate through the maps. A map that doesn’t accomplish a purpose and

does not meet a stakeholders need could have all the features to navigate but it would still be useless.

The table 3.1 refereed a list of problems and how several tools/frameworks approached those problems.

The following table 4.1 now show how each problem is approached by each feature.

Table 4.1: Table that shows what feature is used to approach each problem

Problems Features provided by EAMS

High cardinality of instances - Collapsing containers- Filtering instances

High cardinality of relationships - Filter relationships by container type- Calculate and highlight path based on depth

Disperse information - Filtering instances- Sorting instances

Heterogeneity of stakeholders - Blueprints designer

The disperse information as stated before, refers to the mechanisms provided by the tool and if they

can be used to interact and simplify the information displayed on the visualization based on properties

of those data instances. Filtering and sorting instances are directly based on the properties of each en-

tity. To approach the heterogeneity of stakeholders, we developed several blueprints using the blueprint

designer already provided by the EAMS, that were fitted to each stakeholder’s need.

In the first part of the thesis, it was explored several visualizations from a javascript library called d3, in

order to find alternatives to the current container based visualizations, but it was concluded that most of

those libraries were more appropriate for geographic maps, mathematical statistic analysis, and some

graphs that actually supported a hierarchy based structure as EAMS supports, but one of its downsides

was the lack of mechanisms to manage high cardinality of relations and entities.

We choose this features since they were based on infovis features and had actual real-worl problem

solving.

77

5Work Evaluation Methodology

79

To evaluate the proposal solution I’m using a research paper that is based on the Design-Science

Research [8], the Artifact evaluation in information systems, Design-Science Research - A holistic View

[20].

This paper focuses on the artifact evaluation in Design-Science Research. It provides guidelines and

evaluation models that can be used as templates to assist us on the evaluation of the solution. There’s

an hierarchy of criteria that complies multiple approaches of evaluations, depending on the type and

purpose of the artifact.

See figure A.2

The paper then states a set of generic evaluation methods that constitutes a model. This term

generic means that it can be applied to all type of generic components in Information Systems and

it’s customizable depending on our domain. This model provides a set of methods that the author can

choose as he seems more fit.

Figure 5.1: Model of generic evaluation methods

• Description is simply depicting what is being evaluated.

• Assessed criterion is based on the hierarchy of criteria presented before. It’s the context to which

the evaluation is being performed.

• Form evaluation is the type of data that is being gathered, whether it can be quantitative, qualita-

tive, analysis and logical reasoning or even formal proof.

• Secondary Participant is who participates in the evaluation of the artifact, whether by using the

artifact or providing feedback.

81

• Level of Evaluation refers to either the abstract artifact that is assessed directly, or by instantiating

the artifact in real or artificial examples.

• Relativeness of Evaluation is comparing the artifact, or not, to other artifacts. It can be absolute,

this means that the artifact achieves its objective for example, relative to comparable artifacts, or

relative to the absence of artifact, when there aren’t no comparable artifacts.

Description Assessedcriterion

Formevaluation

SecondaryParticipant

Level ofEvaluation

Relativenessof Evaluation

Demonstrationof the use of theartifact with onereal example.

Goal/efficacyAnalysisand logicalreasoning

Instantiation/ real exam-ples

Absolute

Qualitativefeedback fromusers on theutility of theartifact to aspecific user.

Environment/ consistencywith people/util-ity

QualitativePractitionersand Re-searchers


Relative to ab-sence of artifact

Qualitativefeedback fromusers on theunderstandabil-ity of theartifact.

Environment/ consistencywith people /understandabil-ity

QualitativePractitionersand Re-searchers



Qualitativefeedback fromusers on theutility of theartifact to theorganization

Environment/ consistencywith organiza-tion / utility.

QualitativeInstantiation/ real exam-ples


Figure 5.2: IS artifact evaluation based on the generic evaluation model instances

82

6System Testing

Contents

6.1 User testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

83

This is an important part of our work, to conclude if the the developed artifacts can achieve the goals

stipulated, since it’s during the demonstration that we can evaluate the solution and obtain feedback

from the users in the aimed business organization.

The solution was integrated in the EAMS Web, which is the online EAMS tool. It will provide service

architectures visualizations along with the blueprints that currently exist. We ran some tests with some

users in the Servicos Partilhados do Ministerio da Saude, to obtain feedback from them.

The features developed that will be tested are:

• Filter data instances by properties

• Collapse and expand containers

• Sorting data instances and containers by properties

• Visualize path of relationships in depth

6.1 User testing

To evaluate this system, we ran user testings to obtain feedback regarding the usability. We also

asked the user to use the Think aloud protocol [21] during the execution of the tasks which consists

in a user to say out loud what they are thinking. This allows us to get some feedback. We then need

to assess these user tests with the System Usability Scale. Since this system is very limited to a few

interested stakeholders, the number of users we tested is also quite limited.

6.1.1 Tasks

To run the user tests, we had to set-up some tasks that allow us to verify the usability and understand-

ability of our system. The tasks were selected in order to have optimal coverage of the implemented

features.

• Task 1 - Visualize instances inside two collapsed containers

– Usability goals - The goal here was to see if the user understood how the expand and

collapse features work.

• Task 2 - Filter all data instances that contained a sub-string ”Sistema”

– Usability goals - The goal here was to verify if the interface to filter the data instance would

be a little confusing for the user and if the user accomplish this task using the minimal steps

required.

• Task 3 - Sort data instances inside a container by descending alphabetic order

85

• Task 4 - Determine all data instances that depend on a given instance

– Usability goals - The goal here is to verify if the user understand how the interface works

and its purpose.

6.1.2 System Usability Scale

The System Usability scale is a scale from 0 to 100, that assesses the usability and learn-ability of a

given system, based on ten questions answered by the users [22].

After running the user tasks, we asked the users the ten questions from SUS:

1. I think that I would like to use this system frequently

2. I found the system unnecessarily complex

3. I thought the system was easy to use

4. I think that I would need the support of a technical person to be able to use this system

5. I found the various functions in this system were well integrated

6. I thought there was too much inconsistency in this system

7. I would imagine that most people would learn to use this system very quickly

8. I found the system very cumbersome to use

9. I felt very confident using the system

10. I needed to learn a lot of things before I could get going with this system

All questions must be answered within the using a 5 point Likert scale 6.1:

Figure 6.1: SUS question evaluation scale

But in order to calculate the SUS score, the value given to each question is different from each other.

To assign a score to questions 1, 3, 5, 7 and 9, it’s the value on the scale (1-5) minus 1. For items 2, 4,

6, 8 and 10, the value is 5 minus the scale position (1-5).

Now we sum all scores and then multiple by 2.5 to obtain the value for the SUS 6.1.

86

Score for each questionUsers 1 2 3 4 5 6 7 8 9 10 SUS Score

User 1 4 1 4 1 4 1 5 1 4 1 90User 2 5 1 3 1 3 1 3 2 3 2 75User 3 4 1 4 1 4 1 5 1 5 2 90User 4 5 1 4 1 4 1 4 1 3 1 87.5

Average SUS score 85.63 ± 7.18

Table 6.1: SUS - Test Results

6.1.2.A Results

For the user inquiries, we had four users to test our system and then answer the SUS test. The

results are on the table 6.1.

For four users, the results are quite promising but the more users we use to test the system the more

trustworthy the results are. The global average score was 85.63, and according to Bangor, Aaron &

Kortum, Philip & Miller, James [23], this SUS score is placed on a B grade scale which is considered to

be an acceptable grade. This means the system achieved most of the users objectives and expectations

for the system.

The other idea is to assess the results and verify what were the critical issues. The questions that

had the lowest scores were the questions 3, 5 and 9. The question 3 is referent to how easy the system

was to use and one of the feedback the users gave us was and I quote: ”a new system is not always

easy to use”. So this is expected to happen when we introduce a new system to the users. The question

5 refers to the integration of the functions in the system and the answers despite positive, were not as

high as expected. After obtaining direct feedback with the users, the reasons to this were the location of

the filter button on the top and the icon chosen for the sort button that were confusing.

The question 9 refers to the level of confidence the user had in using the system, and the users explained

that they didn’t had much experience in using the software itself, so we can’t make a correlation with the

addition of new features.

6.1.2.B Conclusions

As stated before, the results were promising but the ideal was to test with more users to have a

wider feedback. But despite that, we got some feedback and conclude that we have some issues to fix,

like the position of the buttons that initiates the interface of filtering and the icon used to open the sort

interface isn’t that appropriate. We didn’t test the developed blueprints since they were developed with

the constant feedback and insight of the stakeholders and also, a map doesn’t belong in a usability test

since a specific map doesn’t interfere with usability and it isn’t inherent to the system.

87

7Conclusion

Contents

7.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

89

In the research of the related-work, it became more clear that there are no consensus regarding

the modeling the service architecture in the organizations, and it’s due to many reasons, like lack of

technical knowledge, communication and different conceptions of the same entity. This work tries to

develop some features and maps to create visualizations that aid the user to visualize those architecture

representations. Those features consist in filtering instances based their properties, filter relationships

based on the type of relations and the origin and destination type. We developed a sorting interface

that allows the user to order a set of instances based on a property. And developed some blueprints

that covers the architecture of the organization and provides various maps with different perspective that

approaches the heterogeneity of stakeholders. The calculating and highlighting path was an important

feature that’s more than a visualizing feature mechanism but a way to navigate across the metamodel

and check dependencies between each entity. All of those features and blueprints can be mashed up

together in a single representation and improve the visualization experience for the user. To test those

features we run some user tests to verify what the users think of the system and the feedback was quite

positive with some issues raised.

7.1 Future Work

With the issues raised from the user testing, we will have to verify how to make the filter interface

more intuitive for the user, so we will ask the users for their opinions. The sorting icon will also be

changed to a more intuitive one. And the feature that wasn’t implemented, the relationships filter would

be implemented when the software constraints were solved. We still need to continue to monitor the

users in order to verify what other issues could arise in order to improve the system.

91

Bibliography

[1] “The Enterprise Architect.” [Online]. Available: http://www.theenterprisearchitect.eu/

[2] “Wikipedia - Class Diagram.” [Online]. Available: https://en.wikipedia.org/wiki/Class diagram

[3] “OpenGroup - Enterprise Architect.” [Online]. Available: http://www.opengroup.org/subjectareas/

enterprise/archimate

[4] “OpenGroup - TOGAF - Enterprise Architecture.” [Online]. Available: http://www.opengroup.org/

subjectareas/enterprise/togaf

[5] A. J. d. O. Sampaio, “An approach for creating and managing Enterprise Blueprints,” Ph.D. disser-

tation, Instituto Superior Tecnico, 2010.

[6] The Open Group, “TOGAF Version 9,” Van Haren Publishing, 2009.

[7] ——, Archimate 3.0 Specification, 3rd ed. The Open Group, 2016.

[8] J. P. S. R. Alan R. Hevner, Salvatore T. March, “Design Science in Information Systems Research,”

no. 4, p. 32, 2004.

[9] Federation of Enterprise Architecture Professional Organizations, “A Common Perspective on En-

terprise Architecture,” Architecture and Governance Magazine, vol. 9, pp. 1–12, 2013.

[10] L. Terlouw, Modularization and Specification of Service-Oriented Systems, 2011.

[11] The Open Group, “SOA Reference Architecture,” The Open Group, p. 192, 2011. [Online].

Available: https://www2.opengroup.org/ogsys/catalog/C119

[12] ——, “Open Group Standard Service-Oriented Architecture Ontology,” The Open Group, 2014.

[13] J. Rumbaugh, I. Jacobson, and G. Booch, The UML reference manual, 1999, vol. 1.

[14] P. Rao, “Using UML service components to represent the SOA architecture pattern,” 2007.

[Online]. Available: https://www.ibm.com/developerworks/architecture/library/ar-logsoa/

93

http://www.theenterprisearchitect.eu/

https://en.wikipedia.org/wiki/Class_diagram

http://www.opengroup.org/subjectareas/enterprise/archimate

http://www.opengroup.org/subjectareas/enterprise/archimate

http://www.opengroup.org/subjectareas/enterprise/togaf

http://www.opengroup.org/subjectareas/enterprise/togaf

https://www2.opengroup.org/ogsys/catalog/C119

https://www.ibm.com/developerworks/architecture/library/ar-logsoa/

[15] S. Roth, M. Zec, and F. Matthes, “Enterprise Architecture Visualization Tool Survey 2014,” vol. 4,

2014.

[16] EAMS Client Application Manual. Link Consulting, 2015.

[17] P. Sousa, J. Lima, A. Sampaio, and C. Pereira, “An approach for creating and managing enterprise

blueprints: A case for IT blueprints,” Lecture Notes in Business Information Processing, vol. 34

LNBIP, pp. 70–84, 2009.

[18] K. Ruohonen, “Graph Theory,” no. November, p. 108, 2013.

[19] T. Munzner, Visualization Analysis and Design. CRC Press, 2014.

[20] N. Prat, I. Comyn-Wattiau, and J. Akoka, “Artifact Evaluation in Information Systems Design

Science Research - A Holistic View,” PACIS 2014 Proceedings, vol. Paper 23, pp. 1–16, 2014.

[Online]. Available: http://aisel.aisnet.org/pacis2014/23/

[21] C. H. Lewis, “Using the ”Thinking Aloud” Method In Cognitive Interface Design,” IBM, 1982.

[22] J. Brooke, “SUS - A quick and dirty usability scale,” Reading.

[23] A. Bangor, P. Kortum, and J. Miller, “Determining What Individual SUS Scores Mean : Adding an

Adjective Rating Scale,” p. 10, 2009.

94

http://aisel.aisnet.org/pacis2014/23/

AAnnex

95

Figure A.1: Archimate Metamodel

96

Figure A.2: Hierarchy of criteria for IS artifact evaluation

97

generation of visualizations for service architectures€¦ · generation of visualizations for...

Documents