generation of visualizations for service architectures€¦ · generation of visualizations for...
Post on 08-Jun-2020
13 Views
Preview:
TRANSCRIPT
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
x
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
4.31 Layered blueprint with high cardinality of relations before calculating path . . . . . . . . . 68
4.32 Layered blueprint with high cardinality of relations before calculating path . . . . . . . . . 69
4.33 Layered blueprint with high cardinality of relations before calculating path . . . . . . . . . 69
xii
4.34 Layered blueprint with high cardinality of relations before calculating path . . . . . . . . . 70
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
xiv
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
xvi
1Introduction
Contents
1.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Objectives of work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1
2
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
8
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
14
3Related Work
Contents
3.1 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
15
16
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
44
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()
elser.hideRelation()
elseif origin.Type = originParent && destination.Type = destinationParent or origin.Type =destinationParent && destination.Type = originParent thenr.showRelation()
elser.hideRelation()
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.
Figure 4.31: Layered blueprint with high cardinality of relations before calculating path
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
Figure 4.32: Layered blueprint with high cardinality of relations before calculating path
We then select the Calculate connection Route, which will open the interface 4.33.
Figure 4.33: Layered blueprint with high cardinality of relations before calculating path
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.
Figure 4.34: Layered blueprint with high cardinality of relations before calculating path
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
78
5Work Evaluation Methodology
79
80
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
Instantiation/ real exam-ples
Relative to ab-sence of artifact
Qualitativefeedback fromusers on theunderstandabil-ity of theartifact.
Environment/ consistencywith people /understandabil-ity
QualitativePractitionersand Re-searchers
Instantiation/ real exam-ples
Relative to ab-sence of artifact
Qualitativefeedback fromusers on theutility of theartifact to theorganization
Environment/ consistencywith organiza-tion / utility.
QualitativeInstantiation/ real exam-ples
Relative to ab-sence of artifact
Figure 5.2: IS artifact evaluation based on the generic evaluation model instances
82
6System Testing
Contents
6.1 User testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
83
84
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
88
7Conclusion
Contents
7.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
89
90
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
92
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
[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
AAnnex
95
Figure A.1: Archimate Metamodel
96
Figure A.2: Hierarchy of criteria for IS artifact evaluation
97
98
top related