AN APPROACH FOR CREATING AND MANAGING ENTERPRISE
BLUEPRINTS
André João de Oliveira Sampaio
Dissertação para obtenção do Grau de Mestre em
Engenharia Informática e de Computadores
Júri
Presidente: Professor Alberto Manuel Ramos da Cunha
Orientador: Professor André Ferreira Ferrão Couto e Vasconcelos
Co-Orientador: Professor Pedro Manuel Moreira Vaz Antunes de Sousa
Vogal: Professor José Manuel Nunes Salvador Tribolet
Outubro de 2010
I
II
AGRADECIMENTOS
À Helena, o meu tudo, que sempre me apoiou, sem quem eu nunca teria conseguido.
Ao Mickey e ao Tommy, os meus gatos, que me fizeram companhia durante as longas noites de trabalho.
A todos do universo Link Consulting e Aitec que me acolheram, ajudaram a crescer e que me permitiram por em
prática o que é abordado nesta tese.
Aos meus amigos e família, pelos conselhos que me deram e pela compreensão quando não pude estar presente.
A toda a comunidade do Instituto Superior Técnico, docentes, colegas e amigos que me ajudaram durante o
percurso académico.
Ao professor Pedro Sousa, pelo entusiasmo, disponibilidade e inspiração.
III
RESUMO
As organizações têm, nas últimas décadas, incorrido em esforços substanciais para produzir blueprints
arquitecturais que, devido à ausência de metodologias ou à escolha inadequada de ferramentas, são tipicamente
diagramas informais pouco úteis para a grande maioria da audiência. A necessidade de uma abordagem
estruturada tem aumentado à medida que a comunidade se apercebe das dificuldades inerentes à criação e
manutenção das representações arquitecturais.
A Arquitectura Empresarial é uma das disciplinas que nasceu em resposta a estas necessidades. Nas duas últimas
décadas termos como view, viewpoint e concern tornaram-se ubíquos, na medida em que se instalaram no
vernáculo das diferentes escolas de Arquitectura Empresarial, resultando de influências das práticas e conceitos
da Arquitectura de Software. Com um vocabulário comum veio a reutilização de princípios que permitissem a
criação de descrições arquitecturais adequadas. Contudo estes contributos não abrangem o problema do esforço
de criação.
Esta tese apresenta uma abordagem para a geração automática de views, em conformidade com as restrições
impostas por um viewpoint. O trabalho desenvolvido recorre às influências de disciplinas como teoria de grafos,
teoria de conjuntos e à modelação da Empresa como um grafo, para especificar formalmente o conteúdo a ser
compreendido nas vistas e para descrever as convenções de desenho que ditam como o conteúdo deve ser
representado. Partindo de perspectivas formais, a abordagem propõe que a diminuição do esforço no processo de
criação e manutenção de blueprints arquitecturais seja atingida com base na incorporação da automação desses
processos numa solução de software.
Palavras-Chave: Viewpoint, View, Blueprint, Arquitectura Empresarial, Representação Gráfica, Especificação
Formal.
IV
ABSTRACT
Organizations have, in the last decades, made substantial efforts to produce architectural blueprints which, due to
the lack of methodology or to the use of inappropriate instruments, typically consist in a set of informally
designed diagrams with diminished value for most audiences. The need for an engineering approach as soared
over the last years, as the community acknowledges the difficulties of creating and managing these graphical
architectural descriptions.
Enterprise Architecture is one of the disciplines that emerged in response to such need. In the last two decades
terms such as view, viewpoint and concerns have become ubiquitous and are well-established within the
vernacular of the different schools of Enterprise Architecture, resulting from the influence of concepts and
practices originating from Software Architecture. With a common understanding of the terms came the
reutilization of principles, guidelines that enabled the definition of adequate architectural descriptions. However
no contributions were made regarding the effort needed for the production of the representations.
This thesis presents an approach for the automated creation of views that conform to the constraints of a
viewpoint. The developed work resorts from influences from disciplines such as graph theory, set theory and to
the idea of the Enterprise modelled as a graph, to specify the content to be represented in a view and to describe
the representation conventions that enforce how the content should be graphically represented. From this formal
perspective, the approach proposes that de effort associated with the process of creating and maintaining
architectural blueprints can be reduced through the incorporation of the automation of these processes in a
software solution.
Keywords: Viewpoint, View, Blueprint, Enterprise Architecture, Graphical Representation, Formal
Specification.
V
INDEX
AGRADECIMENTOS .......................................................................................................................................... II
RESUMO.......................................................................................................................................................... III
ABSTRACT ....................................................................................................................................................... IV
INDEX ............................................................................................................................................................... V
LIST OF FIGURES ............................................................................................................................................. VII
LIST OF TABLES ................................................................................................................................................ IX
LIST OF ALGORITHMS ....................................................................................................................................... X
DEFINING AN APPROACH: STARTING GROUNDS .............................................................................................. 1
1 Introduction ............................................................................................................................................... 1
1.1 Introduction ....................................................................................................................................................... 1
1.2 Problem Statement ............................................................................................................................................ 2
1.3 Thesis Objectives ................................................................................................................................................ 3
1.4 Thesis Outline ..................................................................................................................................................... 4
ARCHITECTURE DESCRIPTIONS AND SUPPORTING APPLICATIONS: AN OVERVIEW ........................................... 5
2 Architecture Descriptions .......................................................................................................................... 5
2.1 4 + 1 View Model ............................................................................................................................................... 5
2.2 RM-ODP.............................................................................................................................................................. 7
2.3 EAB ..................................................................................................................................................................... 8
2.4 IEEE Std. 1471-2000 ......................................................................................................................................... 10
2.5 ArchiMate on Viewpoint Classification ............................................................................................................ 13
2.6 An ontological system perspective on Enterprise Blueprints ........................................................................... 14
3 Related Tools ........................................................................................................................................... 18
3.1 Automatic Diagram Layout............................................................................................................................... 18
3.2 Enterprise Architecture Tools .......................................................................................................................... 20
THE PROPOSED APPROACH ............................................................................................................................ 23
4 Approach Summary ................................................................................................................................. 23
4.1 First Stage ......................................................................................................................................................... 23
4.2 Second Stage .................................................................................................................................................... 25
5 Approach Foundations ............................................................................................................................. 26
5.1 Ontological System perspective of the Enterprise ........................................................................................... 26
5.2 An Enterprise Modelled as a Graph ................................................................................................................. 27
COMPRISED SECTIONS OF A VIEWPOINT ........................................................................................................ 37
VI
6 Content Viewpoints ................................................................................................................................. 37
6.1 Content Metamodel ......................................................................................................................................... 37
6.2 Blueprint Content Selection ............................................................................................................................. 43
6.3 Filters ............................................................................................................................................................... 46
6.4 Aggregation Procedures ................................................................................................................................... 47
6.5 Contents of a Blueprint .................................................................................................................................... 49
6.6 Content Viewpoint Section Structure .............................................................................................................. 50
7 Graphical Viewpoints ............................................................................................................................... 51
7.1 Graphical Specification ..................................................................................................................................... 51
7.2 Graphically Representing a view ...................................................................................................................... 55
7.3 Graphical Viewpoint Section Structure ............................................................................................................ 60
ACHIEVING AUTOMATION ............................................................................................................................. 61
8 Enterprise Architecture Management System......................................................................................... 61
8.1 Introduction ..................................................................................................................................................... 61
8.2 Repository Integration ..................................................................................................................................... 63
8.3 Blueprint Management .................................................................................................................................... 66
8.4 Time Dimension ............................................................................................................................................... 69
9 Cases ........................................................................................................................................................ 72
9.1 Case 01: Link Consulting - Portugal .................................................................................................................. 72
9.2 Case 02: Financial Group I - Portugal ............................................................................................................... 72
9.3 Case 03: Financial Group II - Brazil ................................................................................................................... 72
9.4 Case 04: Financial Group III - Brazil .................................................................................................................. 72
CLOSING STATEMENTS ................................................................................................................................... 73
10 Conclusions .............................................................................................................................................. 73
10.1 Summary .......................................................................................................................................................... 73
10.2 Lessons learned ................................................................................................................................................ 74
11 References ............................................................................................................................................... 76
APPENDIX A: PSEUDO-CODE CONVENTIONS .................................................................................................. 79
APPENDIX B: RATIONAL SYSTEM ARCHITECT OBJECT MODEL......................................................................... 80
APPENDIX C: ENTERPRISE BLUEPRINTS EXAMPLES ......................................................................................... 81
VII
LIST OF FIGURES
FIGURE 1 DIFFERENT REPRESENTATIONS OF THE SAME CONTENT. .......................................................................................... 2
FIGURE 2 "4+1" VIEW MODEL [28]. ................................................................................................................................ 6
FIGURE 3 IEEE STD. 1471 CONCEPTUAL FRAMEWORK. .................................................................................................... 10
FIGURE 4 MAGIC QUADRANT FOR ENTERPRISE ARCHITECTURE TOOLS [17]........................................................................... 21
FIGURE 5 FORRESTER WAVE: ENTERPRISE ARCHITECTURE TOOLS [16]. ................................................................................ 21
FIGURE 6 SEPARATION OF CONCERNS: MODEL, VIEW, VISUALIZATION AND VIEWPOINT. ADAPTATION FROM [31]. ........................ 24
FIGURE 7 SEPARATION OF CONCERNS: CONSIDERING TWO VIEWPOINT PARTS. ........................................................................ 24
FIGURE 8 OVERVIEW OF THE SOFTWARE SOLUTION. .......................................................................................................... 25
FIGURE 9 REPRESENTATION OF THE CONSTRUCTION OF A SYSTEM [12]. ................................................................................ 26
FIGURE 10 REPRESENTATION OF A GRAPH, AN INDUCED SUB-GRAPH AND A SPANNING SUB-GRAPH [41]. .................................... 28
FIGURE 11 EXAMPLE OF A CONNECTED AND A DISCONNECTED GRAPH [41]. .......................................................................... 29
FIGURE 12 REPRESENTATION OF AMBIGUOUS RELATIONSHIPS. ............................................................................................ 30
FIGURE 13 REPRESENTATION OF UNAMBIGUOUS RELATIONSHIPS. ........................................................................................ 30
FIGURE 14 REPRESENTATION OF THE GRAPH FOR S01. .................................................................................................... 33
FIGURE 15 REPRESENTATION OF THE GRAPH OF SCENARIO S02. .......................................................................................... 36
FIGURE 16 REPRESENTATION OF THE SUB-GRAPHS IN DISTINCT TIME INTERVALS. .................................................................... 36
FIGURE 17 REPRESENTATION OF THE CONTENT METAMODEL FOR S03. ................................................................................ 42
FIGURE 18 EXAMPLE OF A REPRESENTATION OF THE ADDRESSED CONTENT FOR S04. ............................................................... 44
FIGURE 19 REPRESENTATION OF THE FIRST [A], SECOND [B] AND THIRD [C] CONTENT SELECTION CONDITIONS FOR S04. ................. 45
FIGURE 20 REPRESENTATION OF THE OUTPUT OF THE FIRST AGGREGATE PROCEDURE FOR S04. ................................................. 48
FIGURE 21 REPRESENTATION OF SECOND AGGREGATE PROCEDURE FOR S04. ......................................................................... 49
FIGURE 22 REPRESENTATION OF THE VIEW GRAPH FOR S04. ............................................................................................... 49
FIGURE 23 EXAMPLE OF SYMBOLS LAID OUT DIFFERENTLY DUE TO THE AMBIGUITY OF THE GRAPHICAL GUIDELINE. ......................... 51
FIGURE 24 BLUEPRINT DRAWING SPACE. ........................................................................................................................ 52
FIGURE 25 DESIRED GRAPHICAL REPRESENTATION FOR S04. ............................................................................................... 55
FIGURE 26 INFLUENCE PATHS TRAVELLED. ....................................................................................................................... 59
FIGURE 27 ENTERPRISE ARCHITECTURE MANAGEMENT SYSTEM’S MAJOR AREAS. ................................................................... 61
FIGURE 28 EAMS OVERVIEW. ..................................................................................................................................... 62
FIGURE 29 GRAPHICAL INTERFACE USED TO DEFINE FILTERS. .............................................................................................. 68
FIGURE 30 BLUEPRINT WITH NO APPLIED FILTER. .............................................................................................................. 69
FIGURE 31 BLUEPRINT WITH A FILTER APPLIED. ................................................................................................................ 69
FIGURE 32 GRAPHICAL INTERFACE THAT ALLOWS THE SPECIFICATION OF TIME RELATED CONSTRAINTS. ........................................ 69
FIGURE 33 BLUEPRINT WITHOUT TIME RESTRICTIONS. ....................................................................................................... 70
VIII
FIGURE 34 BLUEPRINT WITH TIME RESTRICTIONS. ............................................................................................................. 70
FIGURE 35 CONTROL PANEL FOR DYNAMIC VISUALISATION. ................................................................................................ 70
FIGURE 36 BLUEPRINT WITH NO TIME RESTRICTIONS. ........................................................................................................ 71
FIGURE 37 BLUEPRINT RESTRICTED TO A DATE. ................................................................................................................ 71
FIGURE 38 RATIONAL SYSTEM ARCHITECT OBJECT MODEL. ............................................................................................... 80
FIGURE 39 APPLICATION ORGANIC. ............................................................................................................................... 81
FIGURE 40 APPLICATION CONTEXT. ............................................................................................................................... 82
FIGURE 41 PRODUCT VIEWPOINT. ................................................................................................................................. 82
FIGURE 42 COMPONENT INTEGRATION .......................................................................................................................... 83
FIGURE 43 APPLICATION STRUCTURE. ............................................................................................................................ 83
FIGURE 44 PROJECT IMPACT. ....................................................................................................................................... 84
FIGURE 45 APPLICATION CONTEXT (EAMS-VIEWER). ...................................................................................................... 85
FIGURE 46 APPLICATION STRUCTURE (EAMS-VIEWER). ................................................................................................... 86
IX
LIST OF TABLES
TABLE 1 RM-ODP VIEWPOINTS [31]. ............................................................................................................................ 7
TABLE 2 COMPARISONS BETWEEN ENGINEERING AND IT DRAWINGS. ...................................................................................... 8
TABLE 3 EAB BLUEPRINT TYPES. ..................................................................................................................................... 9
TABLE 4 DEFINITIONS OF IEEE STD. 1471 CONCEPTUAL FRAMEWORK. ............................................................................... 11
TABLE 5 BEHAVIORAL VIEWPOINT DEFINED IN [24]. .......................................................................................................... 11
TABLE 6 SUMMARIZED SECTIONS OF THE HILLIARD’S VIEWPOINT TEMPLATE [8]. .................................................................... 12
TABLE 7 VIEWPOINT PURPOSE DIMENSION [31]. .............................................................................................................. 13
TABLE 8 VIEWPOINT ABSTRACTION LEVELS [31]. .............................................................................................................. 13
TABLE 9 NOTIONS OF [38]. ......................................................................................................................................... 16
TABLE 10 TREE LAYOUT ALGORITHMS. ........................................................................................................................... 19
TABLE 11 GRAPH LAYOUT ALGORITHMS.......................................................................................................................... 19
TABLE 12 EDGE ROUTING ALGORITHMS. ......................................................................................................................... 19
TABLE 13 PROPERTY VALUES OF THE ARTIFACTS IN S02. .................................................................................................... 36
TABLE 14 PROPERTY VALUES FOR APPLICATION COMPONENTS OF S04. ................................................................................ 49
TABLE 15 CONTENT GUIDELINES FOR THE CONTENT VIEWPOINT. ......................................................................................... 50
TABLE 16 ASSOCIATION OF THE ARTIFACTS WITH GRAPHICAL TYPE. ...................................................................................... 59
TABLE 17 CONTENT GUIDELINES FOR THE GRAPHICAL VIEWPOINTS. ..................................................................................... 60
TABLE 18 EAMS FUNCTIONALITIES. .............................................................................................................................. 63
TABLE 19 SYSTEM ARCHITECT ENCYCLOPEDIA’S USED METHODS AND DESCRIPTIONS. .............................................................. 64
TABLE 20 SYSTEM ARCHITECT DEFINITION’S USED METHODS AND DESCRIPTIONS. ................................................................... 64
TABLE 21 SYSTEM ARCHITECT ENCYCLOPEDIA’S USED ATTRIBUTES AND DESCRIPTIONS. ............................................................ 64
TABLE 22 METHODS FOR IREPOSITORY. ......................................................................................................................... 64
X
LIST OF ALGORITHMS
ALGORITHM 1 EXAMPLE OF AN AGGREGATE PROCEDURES TEMPLATE.................................................................................... 47
ALGORITHM 2 DESCRIPTION OF THE FIRST AGGREGATE PROCEDURE FOR S04. ........................................................................ 48
ALGORITHM 3 DESCRIPTION OF THE SECOND AGGREGATE PROCEDURE FOR S04. .................................................................... 48
ALGORITHM 4 IDENTIFYENTRYPOINTS METHOD TEMPLATE. ................................................................................................ 53
ALGORITHM 5 ASSOCIATE METHOD TEMPLATE. ............................................................................................................... 54
ALGORITHM 6 GRAPHICALORCHESTRATION METHOD TEMPLATE. ........................................................................................ 54
ALGORITHM 7 CHILDNODES SUPPORT ALGORITHM. .......................................................................................................... 54
ALGORITHM 8 CHILDEDGES SUPPORT ALGORITHM. ........................................................................................................... 54
ALGORITHM 9 PARENTNODES SUPPORT ALGORITHM. ........................................................................................................ 55
ALGORITHM 10 PARENTEDGES SUPPORT ALGORITHM. ...................................................................................................... 55
ALGORITHM 11 AGGREGATECHILDNODES SUPPORT ALGORITHM. ....................................................................................... 56
ALGORITHM 12 CALCULATESIZE METHOD FOR GRAPHICAL ELEMENTS CLASSIFIED AS SYMBOL. ................................................... 56
ALGORITHM 13 CALCULATEPOSITION METHOD FOR GRAPHICAL ELEMENTS CLASSIFIED AS SYMBOL. ............................................ 57
ALGORITHM 14 CALCULATEHEIGHT FOR GRAPHICAL ELEMENTS CLASSIFIED AS CONTAINER. ...................................................... 57
ALGORITHM 15 CALCULATEWIDTH FOR GRAPHICAL ELEMENTS CLASSIFIED AS CONTAINER. ....................................................... 57
ALGORITHM 16 CALCULATESIZE METHOD FOR GRAPHICAL ELEMENTS CLASSIFIED AS CONTAINER. .............................................. 57
ALGORITHM 17 CALCULATEPOSITION METHOD FOR GRAPHICAL ELEMENTS CLASSIFIED AS CONTAINER. ....................................... 58
ALGORITHM 18 GRAPHICAL ORCHESTRATION FOR S04. .................................................................................................... 58
ALGORITHM 19 IDENFITYENTRYPOINS FOR S04 ............................................................................................................... 58
ALGORITHM 20 ASSOCIATE FOR S04 ............................................................................................................................. 58
ALGORITHM 21 CHOREOGRAPHELEMENTMETHODS FOR S04. ............................................................................................ 59
ALGORITHM 22 DISTRIBUTEELEMENTS FOR S04. ............................................................................................................. 60
ALGORITHM 23 ALGORITHM TO OBTAIN ALL THE REPOSITORY’S ARTIFACTS. ........................................................................... 64
ALGORITHM 24 ALGORITHM USED FOR THE RETRIEVAL OF ALL THE REPOSITORY’S RELATIONSHIPS. ............................................. 65
ALGORITHM 25 GETARTIFACTSBYTYPE .......................................................................................................................... 65
ALGORITHM 26 GETARTIFACT ...................................................................................................................................... 65
ALGORITHM 27 GETARTIFACTPROPERTY ........................................................................................................................ 65
ALGORITHM 28 GETRELATIONSHIPBYTYPE ..................................................................................................................... 66
ALGORITHM 29 GETRELATEDARTIFACTS......................................................................................................................... 66
ALGORITHM 30 GETREPOSITORYADDRESSEDINFORMATION ............................................................................................... 67
ALGORITHM 31 CREATE .............................................................................................................................................. 67
XI
1
Chapter 01
DEFINING AN APPROACH: STARTING GROUNDS
1 INTRODUCTION
1.1 INTRODUCTION
For long, has the capturing of the essence of architecture, been a considerate challenge in the attempt to control
functionality and complexity [35]. Applied in a wide range of domains, from buildings and construction, to
information systems, architecture addresses different systems or areas, yet still bears common concerns.
Architecture forms the basis for analysis optimizations, validation and a starting point for further developments
and planning. As organizations struggle to cope with complexity and an ever-growing change rate, they turn to
Enterprise Architecture.
As an important role of Enterprise Architecture, modelling the enterprise artifacts and their relations has been the
subject matter of many endeavours. Organizations have made, over the last decades, substantial efforts to
produce architectural blueprints [38]. Graphical representations are an attractive and effective way of conveying
information [26]. Schematic representations, engineering drawings and graphs, are ways to represent models and
play a big role in architecture, but their value is bound to its adequacy and ability to communicate the intended
message to the desired audience, the stakeholders.
Different stakeholders have different needs, and it is not always easy or even possible, to accommodate these
needs into a single model [24], [22]. Stakeholders, in an enterprise context, can be identified ranging from
business or IT management to software engineers (among others), each of them requiring specific information in
an accessible way. To predict the consequences of developments and changes in the enterprise landscape,
whether business or IT, it is crucial to have an overview of what changes and the resulting impact, so that
decision-makers and engineers have access to the information they need to support their actions [30].
To adequately address the needs of the audience and to enforce an engineering approach in the construction of
the architectural representation, the various schools of Enterprise Architecture have turned to more matured
disciplines such as Software Architecture. Terms such as view, viewpoint and concerns have become well
established in the vernacular, leading to the common understanding that a view, whether graphical or not, must
conform to a viewpoint, which establishes the purposes and audience for the view as well as the techniques for
its creation and analysis [24], [31].
2
1.2 PROBLEM STATEMENT
The effort required to manually maintain enterprise blueprints is greater than what should be required [38] and
therefore, automation is needed to overcome this predicament and still deliver the enterprise blueprints.
“…the truth is that companies fail to have such maps, claiming that update costs are
simply too high given the rate of changes of the organization artifacts…”
Pedro Sousa (2009) [38]
A blueprint, as any other view, relies on a viewpoint to which it conforms. To allow a blueprint to be
automatically created is to imply, in the current scope, that its viewpoint can be expressed programmatically.
Resorting to an algorithmic perspective the viewpoint should identify a finite sequence of well-defined steps for
solving a problem, more specifically, the univocal identification of a view or views. By referring to well-defined,
such entails to non ambiguous and deterministic related behaviour. However, due to the overall maturity level of
the Enterprise Architecture discipline much work is yet to be done.
Informal practices use informal specifications, thus to some extent informal viewpoints. A distinction is in order,
when accusing a viewpoint of informality it is not implied that the structure of the viewpoint is itself a careless
one, however it suggests its content can be.
A common misconception is to rely on identification of notation symbols in a viewpoint as the sufficient
condition to produce representations, [28] is an example of which, Lankhorst [31] on the other hand highlights
concerns accounting the readability and usability of models. It is necessary that representation conventions take
part in the specification, both to impose adequate representation and to allow the automation of such
representations. The visualization of a model should be consistent. In Figure 1 four representations of a same
graph are displayed but have distinct layouts. Although a viewpoint based on notation could have any of these
views conforming to it, a viewpoint that expressed drawing conventions, regarding the layout, couldn‟t. If
restrictions of this kind are not enforced it is deemed impossible the endeavour to produce standardized
representations.
Figure 1 Different representations of the same content.
3
Inherent to the process of creating and using viewpoints is the concept of scoping, in which the domain to be
represented and the constraints are established. A Blueprint is a graphical representation of information, which
originates from an architectural repository and corresponds to model of the enterprise. An incorporation of the
viewpoint is the specification of the parts of the model to represent, resulting in a view of the model, where
constraints are imposed and the domain of analysis is identified. As previously stated, to avoid ambiguity, a
formal specification is acclaimed. Therefore, the solution encompasses needs on expressing constrains that
dictate which information is selected to be represented on the map.
The problem therefore relates to the ability to define parts of viewpoint that comprise non-ambiguous
specifications from which architectural blueprints can be automatically created.
1.3 THESIS OBJECTIVES
The purpose of this thesis is to exercise the ability to create and manage Enterprise Blueprints, based on their
viewpoints and information maintained in an architectural repository, without manual modelling effort.
Breaking down the previous sentence, the premises and assumptions are as follows:
“…information maintained in an architectural repository…”
o The content to graphically represent by means of a blueprint is comprised in an architectural
repository.
o The architectural repository is a component of an Enterprise Architecture Tool from which the
information is attainable.
o The information and the underlying metamodel are considered “input variables”
“…based on their viewpoints …”
o Such implies that for a blueprint to be successfully automated, one must follow a clear
specification on how to achieve such representation.
o The viewpoints should comprise parts that address the identification of the content, the
representation conventions and means to support the usage of different metamodels.
“…create and manage Enterprise Blueprints…” & “…without manual modelling effort…”
o This assumes that the aforementioned blueprints are subject to automation, achieved through a
software solution, and that there is no human participation in the modelling process.
o The software solution must be able to integrate with the architectural repository and must
accommodate the needs of the viewpoint specification and produce the conforming graphical
views.
In the context of the previous statements and sections this thesis proposes itself to: (1) Establish the means to
specify enterprise blueprints by proposing principles to comprise in the conforming viewpoints; (2) Develop a
software solution that automates the creation of enterprise blueprints; (3) Validate the need for the thesis‟s
approach and its ability to aid organizations in the resolution of real life problems.
4
1.4 THESIS OUTLINE
The thesis is divided in six chapters each comprising one or more sections.
Chapter 1:
The first chapter addresses the context and scope of the work, by covering the problem statement and the thesis
main objectives.
Chapter 2:
The second chapter is an overview of related work concerning architecture descriptions and commercial tools
that either have the ability to generate graphical representations or that are candidates for providing the
architectural repository to use in the software solution.
Chapter 3:
The third chapter starts by introducing the basics of the approach. Section 4 presents a summary of the approach,
how the work was divided and an introduction to the proposed parts of viewpoints. Section 5 discusses how the
approach is influenced by an ontological system perspective and describes the basic principles used for
modelling an Enterprise as a graph.
Chapter 4:
The fourth chapter concerns the comprised parts of the viewpoints. Section 6 describes the approach regarding
the selection of content of the blueprint and Section 7 concerns the means and process to express graphical
representation constraints.
Chapter 5:
The software solution implemented for this thesis is described in Section 8 with special emphasis on how the
proposed viewpoint parts are addressed. The last section of the fifth chapter describes the context of the projects
in which the approach was put into practice in different Organizations.
Chapter 6:
The sixth chapter comprises the conclusion of this work.
5
Chapter 02
ARCHITECTURE DESCRIPTIONS AND SUPPORTING
APPLICATIONS: AN OVERVIEW
2 ARCHITECTURE DESCRIPTIONS
Architecture provides means to handle the complexity of systems, to do so the architects need ways to represent
them as clearly and easily as possible. However, due to the heterogeneous nature of the audience, sketches or
over-engineered diagrams do not suffice. Hence one is compelled to review some of the most remarkable
contributions regarding concepts, models, methods, and overall approaches to architecture descriptions.
2.1 4 + 1 VIEW MODEL
The difficulty of capturing the essence of a system‟s architecture, in a diagram, comes as the main driver for the
definition of the “4+1” model. In 1995, Philippe Kruchten [28] published an influential paper in which he
presents a model for describing the architecture of software-intensive systems based on the hypothesis of using
more than one architectural style and the need to adjust the representation according to the stakeholders needs.
The model was later institutionalized as the conceptual basis of the RUP1.
The view model comprises five views:
Logical View: The logical architecture identifies the functional requirements addressing the services
that the system provides to its users. The system is decomposed into a set of key abstractions (e.g.
objects), exploiting also the principles of encapsulation and inheritance.
Development View: This view describes the static organization of the software and its development.
Process View: This view takes into consideration non-functional requirements such as performance and
availability, and aims to capture the concurrency and synchronization aspects of the design.
Physical View: Addresses concerns such as scalability, performance and availability, describing the
mapping of software, hardware and its distribution.
1 Rational Unified Process 2 International Organization for Standardization, http://www.iso.org/.
6
Scenarios: The “+1” view provides a driver do discover key elements in design validation and
illustration. It shows how the other “4” views work together seamlessly by the use of a small set of
important scenarios (use case instances).
Figure 2 "4+1" view model [28].
Many extensions to this model were proposed over the years such as [39],[32],[27] and[29]. Christine
Hofmeister also defined a similar taxonomy [21], categorizing the architecture into four views:
Conceptual View: Analogue to the “4+1” logical view [39].
Module Architecture View: Describes the interfaces and interdependencies between artifacts.
Code Architecture View: Captures how modules and interfaces in the module view are mapped to
source files and how run-time images in the execution view are related to executable files.
Execution Architecture View: Describes the structure of a system in terms of its run-time platform
elements, such as tasks, processes, threads, and address spaces.
Despite the important contribution of this model, it was still criticized. Although the view model classification
highlights the importance of capturing design decisions it gives no insight on how to do this, thus failing to
define adequate processes for documenting these decisions [9].
Mark Lankhorst [31] raised issues regarding whether or not the concepts used (object classes, associations, etc.)
for communication with end users were the most appropriate, and also pointing out the absence of explanation
on how the modelling concepts contributed to the goals of each view. Due to the existing dependence between
the views, modelling is considered difficult without first going through the scenarios and logical views [33].
7
2.2 RM-ODP
In 1996, resulting from a joint effort from ISO2, ITU
3 and IEC
4 , emerged RM-ODP
5 (Reference Model of Open
Distributed Processing). The RM-ODP defines concepts necessary to specify open distributed processing
systems from prescribed viewpoints and provides a framework for the structuring of specifications for large-
scale, distributed systems.
The five viewpoints, as presented in Table 1, were chosen to be both simple and complete, covering all the
domains of architectural design6, to primarily enable communication between developers of different systems,
and not between other stakeholders of the same system [33].
Viewpoint
Enterprise Information Computational Engineering Technology
Goal Capture purpose,
scope, and
policies of the
system
Capture
semantics
of information
and
processing
performed by
the system
Express
distribution of
the system in
interacting
objects
Describe design
of distribution-
oriented
aspects
of the system
Describe
choice of
technology
used in the
system
Concern Organizational
requirements
and structure
Information
and processing
required
Distribution of
system
Functional
decomposition
Distribution
of the system,
and mechanisms
and
functions
needed
Hardware and
software
choices
Compliancy
to other views
Notions Objects
Communities
Permissions
Obligations
Contract
...
Object classes
Associations
Process
...
Objects
Interfaces
Interaction
Activities
...
Objects
Channels
Node
Capsule
Cluster
...
Not stated
explicitly
Table 1 RM-ODP viewpoints [31].
A set of general concepts and rules are defined for each viewpoint as well as a language to express them [33].
The RM-ODP does not explicitly associate viewpoints to a specific class of stakeholders, leaving this implicit in
the concerns [31].
2 International Organization for Standardization, http://www.iso.org/. 3 Telecommunication Standardization Sector, http://www.itu.int/ITU-T/. 4 International Electrotechnical Commission, http://www.iec.ch/. 5 Also named ITU-T Rec. X.901-X.904 and ISO/IEC 10746. 6 http://www.rm-odp.net/
8
2.3 EAB
“What most organizations call an architecture is really a mess of indecipherable diagrams.”
Bernard Boar (1999) [3]
In 1998, driven by the belief that organizations were unable to have a structured approach to recording IT
Architecture, Bernard H. Boar presented EAB7, a methodology that comprises an extensive definition of
concepts with associated notation and well-formed semantics [2]. It starts with an interesting critique on how
architecture diagramming is perceived and its output. The lack of semblance to blueprint rigor added to an
individualized approach creates significant problems. Table 2 compares typical IT drawings with engineering
drawings.
Blueprint issue Engineering drawings Typical IT architecture drawings
Degree of specification of
drawing rules
Formal notation system:
Icons and graphics
Formal text
Precise meanings
Personal notation per drawing
Random icons and graphics
Random text
Ambiguous meaning
Representation of the given
problem
Repeatable Seldom repeatable
Maintenance of model to reflect
reality
Active model One-time model
User expectation Predictable representation Ad hoc representation
Methodology Managed None
Education Formal education and certification No education No certification
Community use of blueprinting
system
Community Practice None
Objects to express Minimum definition of what it
communicates
Personal definition
Completeness of blueprinting Drawing System Personal sketching
Knowledge repository of record The blueprint Individual‟s mind
Visibility of designs High visibility Fog
Table 2 Comparisons between engineering and IT drawings.
The discrepancy between the drawing approaches is pointed out to be a differentiating factor in the ability to
become an “Information Age Predator” [2]. This fierce approach and the use of terms backed by citations of Sun
Tzu, is present throughout the work.
“Those who implement IT architecture well will win and those who don’t will lose”
Bernard Boar (1999) [3]
7 Enterprise IT Architecture Blueprints
9
A main concept of this approach is the blueprint, which, in analogy to an engineering drawing, uses pictorial
graphics, textual presentation, and notation rules to depict physical and functional end-product requirements [3].
EAB can be used to document eight types of blueprint, presented in Table 3, according to architecture type and
perspective.
Architecture Perspective
Architecture Type Logical Physical Functional Sketch
Infrastructure
Logical
infrastructure
architecture
Physical
infrastructure
architecture
Functional
infrastructure
architecture
Infrastructure architecture
sketch or infrastructure
conceptual architecture
Application
Logical
application
architecture
Physical
application
architecture
Functional
application
architecture
Logical application
architecture or application
conceptual architecture
Table 3 EAB Blueprint types.
An EAB is a rigorously structured document, divided into sections and subsections, which is, in its entirety, the
blueprint. The methodology is structured into 61 notions, each of them is an idea or set of ideas the EAB
practitioner must understand in order to draw and interpret the blueprints. These notions explain how to draw
each type of diagram, how icons and diagrams relate and what each section ought to contain.
There are four core EAB diagrams, each of which illustrates an architecture type by combining its icons with
other icons. The diagrams are:
System Block Diagram – has the system as a central element, coupled with other icons, the diagram
illustrates the architectural structure within and EAB domain from a system-level view.
Platform Diagram – has the platform as central element and illustrates the architectural structure from a
platform-level view.
Interoperability Diagram – illustrates an architecture where both configured platforms and services are
the central elements of granularity, depicting an instance of an information technology device with its
associated interoperability, from an interoperability-level view.
Function Block Diagram – with function block as the central element that provides a mechanism that
enables the display of functional relationships and decomposition of business functions, from a
functional-level view.
Although EAB methodology is presented as rigorous, predictable and unambiguous, it is not short of its
downfalls. According to Vasconcelos [40] one of the major limitations encountered was the inability to
customize EAB templates in order to respond to the necessities and environment of each user. Furthermore, [40]
added that for EAB to be financially profitable the practitioners must be highly experienced and trained – which
is seldom the case.
10
2.4 IEEE STD. 1471-2000
IEEE Std. 1471-2000 presented a theoretical foundation for the definition, analysis and description of software
architecture. IEEE8 created IEEE Architecture Planning Group, in 1995, followed by IEEE Architecture
Working Group, in 1999, to define IEEE Std.1471 with the purpose of establishing a set of concepts and
designation to describe software architecture. In September 2000, the standard “Recommended Practice for
Architectural Description of Software-Intensive Systems” was approved.
The goal of this standard is not to normalize the system architecture by establishing a fixed number of views or
their nature; neither has it recommended any modelling language or methodology. The framework presented in
Figure 3, identifies, describes and relates various concepts involved in sustainment of architectures of software-
intensive systems, and the recording of such architecture in terms of architectural descriptions.
Figure 3 IEEE Std. 1471 Conceptual Framework.
The following table presents a list of metamodel concepts
Term Definition
Architect The person, team, or organization responsible for systems architecture.
Architecting The activities of defining, documenting, maintaining, improving, and certifying proper
implementation of an architecture.
Architectural
Description A collection of products to document an architecture
8 Institute of Electrical and Electronics Engineers, http://www.ieee.org/
11
Architecture The fundamental organization of a system embodied in its components, their relationships to
each other, and to the environment, and the principles guiding its design and evolution.
System A collection of components organized to accomplish a specific function or set of functions
System
Stakeholder
An individual, team, or organization (or classes thereof) with interests in, or concerns relative
to, a system.
View A representation of a whole system from the perspective of a related set of concerns
Viewpoint
A specification of the conventions for constructing and using a view. A pattern or template
from which to develop individual views by establishing the purposes and audience for a view
and the techniques for its creation and analysis.
Table 4 Definitions of IEEE Std. 1471 Conceptual Framework.
The terms view and viewpoint are central to the recommended practice. The term viewpoint was chosen to align
with that of RM-ODP, which although has no separate term for view, defines viewpoint (on a system) as:
“…a form of abstraction achieved using a selected set of architectural constructs and structuring rules, in order
to focus on particular concerns within a system.”
A view may contain various architectural models, allowing it to use multiple notations and a model shared by
multiple views; however, each view is defined by only one viewpoint. A viewpoint is specified by:
Viewpoint name;
Target stakeholders;
Target concerns;
Language, modelling techniques, or analytical methods used to construct a view based on the
viewpoint;
Source of the library viewpoint.
Table 5 regards an example of a viewpoint defined in [24].
Behavioral viewpoint
The behavioral viewpoint has a long history, prior to its use in architecture in the systems engineering,
simulation, and software engineering/design communities. Examples include Petri nets, parallel path
expressions, and constrained expressions.
The behavioral viewpoint may be specified as follows:
Concerns
What are the dynamic actions of and within a system?
What are the kinds of actions the system produces and participates in?
How do those actions relate (ordering, synchronization, etc.)?
What are the behaviors of system components? How do they interact?
Modeling methods
Events, processes, states, and operations on those entities.
Analytic methods
Some examples are: communicating sequential processes, the pi-calculus, and partially ordered sets of events.
Table 5 Behavioral viewpoint defined in [24].
12
Nevertheless, Richard Hilliard [20] underlined that these simple requirements leave much to the imagination of
the defining architect and proposed a template for recording viewpoints, which met the requirements of IEEE
1471. Table 6 describes the overall structure of the template. The description is based on the work of [8].
Section Description
Viewpoint Name The name of the viewpoint and any known aliases.
Overview An abstract or brief overview of the viewpoint and its key features.
Concerns A listing of the architecture related concerns framed by this viewpoint.
Anti-Concerns Optional. It can be useful to document the kinds of issues a viewpoint is not
appropriate for. Articulating anti-concerns may be a good antidote for certain overly
used notations.
Typical Stakeholders Optional. The typical audiences for views prepared using this viewpoint. Who are the
usual stakeholders for this kind of view?
Model types Identify each type of model used by the viewpoint.
Model languages For each type of model used, describe the language or modeling techniques to be
used. Each model language is a key modeling resource that the viewpoint makes
available. Model languages provide the vocabularies for constructing the view.
Viewpoint
metamodels
Optional. A metamodel presents the conceptual entities, their attributes and the
relationships that comprise the vocabulary of a type of model. Any metamodel should
capture:
Entities: What are the major sorts of elements are present in this type of model?
Attributes: What properties do entities in this type of model possess?
Relationships: What relations are defined among entities within this type of
model?
Constraints: What kinds of constraints are there on entities, attributes or
relationships within this type of model?
Conforming
Notations
Identify an existing notation or model language to be used for this type of model.
Model
correspondence rules
The viewpoint may specify model correspondence rules. Each one may be
documented here.
Operations on views Operations define the methods which may be applied to views and their models.
Operations can be divided into categories:
Creation methods are the means by which views are prepared using the
viewpoint. These could be in the form of process guidance (how to start, what to
do next); or work product guidance (templates for views of this type); heuristics,
styles, patterns, or other idioms.
Interpretive methods provide the means by which views are to be understood by
readers and system stakeholders.
Analyses methods are used to check, reason about, transform, predict, apply and
evaluate architectural results from this view.
Implementation methods capture how to realize or construct systems using
information from this view.
Examples Optional. This section provides examples for the reader.
Notes Optional. Any additional information users of the viewpoint may need.
Sources What are the sources for this viewpoint, if any? This may include author, history,
literature references, prior art, etc.
Table 6 Summarized sections of the Hilliard’s Viewpoint template [8].
13
In 2000, the only requirement on consistency was that a description must record any known inconsistencies
among its views [15]. ISO/IEC 42010 WD1 proposed a mechanism to record the relations between architectural
views. Nelis Boucké presented additional work on this matter [5]. Considering two viewpoints on a system, a
Logical Viewpoint, and a Deployment Viewpoint, David Emery [15] presented the following as an example for a
useful viewpoint correspondence rule:
“Every software element identified in the Logical View must be allocated to at least one computational element
in the Deployment View.”
In sum, this approach made a great contribution to the software architecture communities and many others, even
so to this day it is still subject to continuous improvement and refinement whether through its new denomination
of ISO/IEC 42010 or the countless adaptations to other domains, such as Enterprise Architecture in ArchiMate.
2.5 ARCHIMATE ON VIEWPOINT CLASSIFICATION
ArchiMate9 is The Open Group's
10 modelling language for enterprise architecture, based on IEEE Std.1471. The
development process started July 2002 and lasted until December 2004 resulting in [31], among other things.
The subject of this subsection is the extension on IEEE Std.1471‟s viewpoint notion, regarding its classification.
To assist in the selection of the appropriate viewpoint, [31] introduced a loose framework for definition and
classification of viewpoints and views.
Typical Stakeholder Purpose Examples
Design Architect, software
developer, business
process designer
Navigate, design, support
design decisions, compare
alternatives
UML diagram,
BPMN diagram,
flowchart, ER diagram
Deciding Manager, CIO, CEO Decision making Cross-reference table, landscape map,
list, report
Informing Employee, customer,
others
Explain, convince, obtain
commitment
Animation, cartoon, process
illustration, chart
Table 7 Viewpoint purpose dimension [31].
Typical Stakeholder Purpose Examples
Details Software engineer, process
owner
Design, manage UML class diagram, Testbed process
diagram
Coherence Operational managers Analyze dependencies,
impact of change
Views expressing relations like „use‟,
„realize‟ and „assign‟
Overview Enterprise architect,
CIO, CEO
Change management Landscape map
Table 8 Viewpoint abstraction levels [31].
9 http://www.archimate.org/ 10 http://www.opengroup.org/
14
The matter of using viewpoints also comes into question when the authors, based in their experience, present the
stages through which the use of an architectural viewpoint will pass [31]:
1. Scoping – Select the viewpoint, the domain to be represented and the constraints.
2. Creation of views – Create or select a view conforming to the viewpoint.
3. Validation – Validate the resulting view with the designated stakeholders.
4. Obtaining commitment – If the stakeholders agreed, will they commit to the impact of what is described
by the view?
5. Informing – Inform adjacent stakeholders, members with less decision power, considered less crucial,
but still important.
2.6 AN ONTOLOGICAL SYSTEM PERSPECTIVE ON ENTERPRISE BLUEPRINTS
In 2009, Pedro Sousa, driven by the difficulty of keeping enterprise blueprints updated, presented a project
oriented approach for dealing with this problem [38].
With special focus on the IT domain, considerations were made regarding automated mechanisms able to solve
the blueprint issue. Briefly, it is an essay proposing new requirements for known theories and models to allow
blueprints to be systematically produced and maintained in real organizations. The creation and management of
blueprints is accomplished through a blueprint engine.
The approach identified two main requirements for keeping blueprints up to date:
Information about what has changed – The information is attained from IT project planning sources. In
order to automatically produce representations the information consumed must be reliable and
bidirectional11
Set of rules to update the blueprints – Formal specification of the blueprints and the artifacts each
should depict.
Although information retrieval from IT project sources is out of our scope, the rigorous specification is not. The
formalization laid some initial notions but the connection between some important architecture jargons (e.g.
viewpoints) was left astray.
The system-oriented vision of the paper obliges further study on the fundamental system perspectives: function
and construction [12].
2.6.1 System perspectives
Related to the function of the system, the teleological perspective concerns the goal or the purpose of the system.
This perspective is also called black-box, since knowledge about construction and operation of the system is not
addressed [22].
11 Changes in blueprints should propagate back to the enterprise information pool.
15
The construction of the system, deals with what the system is. This is the ontological system perspective, which
is also referenced to as the white-box perspective, since the knowledge regarding construction and operation of
the system is essential [22].
In the scope of this thesis and the basic grounds of [38], the adequate perspective is the ontological, if the system
is the enterprise and its representation is intended, only from knowing its construction and operation can this be
achieved.
2.6.2 Ontological System Definition
The following notions are from [12].
Reference to two special symbols is required:
≺ means “is part of”;
⊳ means “acts upon” – If x ⊳ y and y ⊳ x, then x and y interact.
Something is a system if and only if it has the following properties:
Composition: a set of elements of some category
Environment: a set of element of the same category
Production: the elements in the composition produce things that are deliverable to the elements in the
environment.
Structure: a set of influence bonds among the elements in the composition, and between them and the
elements in the environment.
Let σ be a system and Γ the category of σ, then,
Composition as C of σ is defined as
(01). ≺
Environment as E of σ is defined as:
(02). ⊳ ⊳
Structure as S of σ is defined as:
(03). , ⊳ ⊳ ,
Let σ1 with the construction < C(σ1), E(σ1), S(σ1) > and σ2 with the construction < C(σ2), E(σ2), S(σ2) > . Then σ2
is a subsystem of system σ1 if and only if
(04).
(05).
16
(06).
2.6.3 Basic Grounds
Starting from the ontological system definition [38] presented its practical basic grounds.
Id. Notion Description
E Enterprise Modelled as a graph G.
A Artifacts Set of all artifacts.
R Relationships Set of all relationships.
G Graph The vertices are artifacts; The edges are relationships.
Types Set of all types12.
A type γ defines the properties and restrictions imposed on artifacts of that type.
P Property Artifacts attribute.
Table 9 Notions of [38].
As in any enterprise, G into which it is modelled, is also affected by the change, so let , represent the
value of G at time t, where t is a discrete variable corresponding to the succession of states , of
, .
If an artifact has a type Γ then “a IsA γ” and “γ = type (a)”, which states that γ is of the type of the
artifact a. The relationships, or structural bounds [12], are also typified according to the vertices to which they
are connected.
Accommodating these alterations, the definitions of Composition, Environment and Structure are respectively, as
follows:
(07). ≺
(08). ⊳ ⊳
(09). , ⊳ ⊳ ,
Having exposed the basics of the formalization language, [38] introduces the basic views: Organic, VORG;
Environment, VENV; Composition, VCOMP; Structure, VSTR.
The Organic View depicts artifacts of type system that are contained in the set TORG and has a property value
PORG present in OrgHierarchySet. The latter holds hierarchy values by which the artifacts will be graphically laid
out.
12 The notion category is addressed as type in this paper.
17
(10). , ,
The Environment View of a system depicts artifacts held in E(σ) during t.
(11). , ,
The Composition View of a system addresses artifacts contained in C(σ) at time t.
(12). , ,
The Structure View represents all the relationships of all artifacts related to the system at t.
(13). , , , , , ,
18
3 RELATED TOOLS
3.1 AUTOMATIC DIAGRAM LAYOUT
To understand the requirements of an automatic diagram layout for the blueprint generation engine it was
necessary to catch a glimpse of what has been done on this subject. Although none of the following fully
addresses the needs of the blueprint engine, they are all either commercial success or results of academic
researches that resulted in commercial products. In this section, three case tools are overviewed, and their
diagram layout capabilities identified.
3.1.1 Magic Draw
MagicDraw13
UML is a CASE tool developed by No Magic, Inc.14
, considered a state-of-the-art UML
programming solution, providing code engineering, structure retrieval and diagramming functionality. The
solution grows from its ability to host a large number of plug-ins (DoDaf, SysML, DOORS, Rational
RequisitePro etc.). An open API makes MagicDraw customizable allowing user to access diagrams, the model
and the graphical interface from their plug-ins.
Code and database engineering enables the preparation of code skeletons from UML model and vice-versa.
MagicDraw layout mechanism presents two categories of layout tools: general layout tools and specific diagram
layout tools15
.
3.1.2 Nevron .NET Vision
Nevron .NET Vision16
is a suite, from Nevron, to create data presentation applications for the .NET framework,
featuring charting, diagramming and user interface components, for Windows Forms and ASP.NET. The most
noteworthy component, in the current scope, is Nevron Diagram for .NET and its automatic arrangement of
diagrams feature. The application supports both mesh and grid connectors routing, and accommodates tree
layouts, graph layouts and cell layouts.
3.1.3 yFiles for .Net
yFiles.NET is a Windows Forms class library for the Microsoft .NET environment, functionality to
automatically calculate layouts for graphs, diagrams, and networks. The integration with components is done
programmatically. yFiles supports other technologies such as Java, AJAX and Flex. Their layout capabilities are
categorized into three types of algorithms:
Graph layout algorithms: Responsible for assigning coordinates to all graph elements: nodes and edges.
Edge routing algorithms: Compute edge paths and leave the nodes of the graph unchanged.
Label placement algorithms: Perform no operation on either a graph's nodes or its edge paths, but
compute suitable positions for labels.
13 http://www.magicdraw.com/ 14 http://www.nomagic.com/ 15 http://www.magicdraw.com/files/manuals/MagicDraw%20UserManual.pdf 16 http://www.nevron.com/Products.Nevron.NETVision.Overview.aspx
19
3.1.4 Layouts and Routing Algorithms
The following is a compilation of algorithms of the aforementioned tools.
Tree Layout Description
Layered The algorithm displays the tree‟s vertices into layers.
Compact The algorithm displays a tree with depth arrangement of the vertices as compact as possible.
Tip Over The algorithm displays the children vertices of a vertex in either a single row or a single
column.
Balloon Layouts the children vertices in a single circle around its parent vertex.
Table 10 Tree layout algorithms.
Graph Layout Description
Hierarchical The algorithm displays the graph‟s vertices into layers.
Organic The algorithm applies the force-directed layout paradigm. While calculating a layout, the
nodes are considered physical objects with mutually repulsive forces; the connections also
follow the physical analogy and are considered springs that produce repulsive or attractive
forces between their end points if they are too short or too long. The layout algorithm
rearranges the positions of the nodes in such a way that the sum of the forces reaches a
minimum.
Orthogonal The algorithm displays the graph only with orthogonal edges and minimizes the drawing
area, edge crossings and edge bends.
Symmetrical The algorithm applies the force-directed layout paradigm. It produces straight-line graph
drawings with uniform edge lengths. Also couples attractive and repulsive forces, which
balance each other at a specified edge length.
Barycentre The barycentre layout method splits the graph into a set of fixed and free vertices. Fixed
vertices are nailed to the corners of a strictly convex polygon, while free vertices are placed
in the barycentre of their neighbours.
Circular Layout algorithm that portraits interconnected ring and star topologies
Table 11 Graph layout algorithms.
Edge Routing Description
Stack The stack layout represents a directed, constrained cells layout, which stacks the cells in
horizontal or vertical order.
Flow The flow layout represents a directed constrained cells layout, which arranges the cells in
horizontal or vertical lanes.
Table Arranges cells in a tabular manner (e.g. preserves tabular metrics).
Dock The dock layout represents a space eating cells layout, which places vertices at per-vertex
specified docking areas of the currently available layout area.
Table 12 Edge routing algorithms.
20
3.2 ENTERPRISE ARCHITECTURE TOOLS
“Many enterprises start off using diagramming tools and spreadsheets to document
their architectures. Although this can be useful initially, ensuring consistency of these
documents becomes extremely difficult once artifacts appear in multiple places. For
example, an application might appear on a diagram depicting a server, a diagram
depicting a business process and a diagram depicting the application’s interfaces.
Changes to the application might require opportunities for inconsistency and
inaccuracy.”
Gartner (2008) [17]
3.2.1 Rational System Architect
After a careful analysis, the chosen enterprise architecture tool was IBM Rational System Architect17
. Two main
factors lead to this decision. The blueprint engine needs interoperability, which System Architect provides via
their Application Program Interface (API). Provided in VBA 6.5, we are able to access the API through .Net
Framework thus allowing the use of more recent technology able to withstand the demands of the software
solution. Rational System Architect not only comes with a solid repository able to provide the model
information, but also, through its drawing it is possible to create the diagrams in which to draw the blueprints
and save them directly in the repository. The later reason is due to availability
3.2.2 EA Tools Overview
A major issue when choosing an enterprise architectural approach is the availability of tools to support the
various activities such as development, storage, presentation and architectural representation [25]. The market
for enterprise architecture tools, much like enterprise architecture methodologies, is still in an immature state
[25], [31]. It is important to understand the major characteristics and features of these instruments and analyze
their technical capability to support the solution.
Countless enterprise architecture initiatives are haunted right from the start due to the lack of adequacy of the
products that support them. These tools must feature key elements such as a repository, retrieval of models,
metamodels and so forth.
In 2005, Mark Lankhorst [31] proposed subdivision into the following categories:
Modelling and Design: Tools that support modelling and design of models.
Reporting and Publication: Tools that allow the construction of reports and viewpoints for specific
stakeholders
Storage and Retrieval: Metadata repositories that store models, metamodels and perspective related
specifications.
17 http://www-01.ibm.com/software/awdtools/systemarchitect/
21
In 2008, Gartner [17] presented these four minimal requirements:
The existence of a repository.
A flexible metamodel that support relationships in various viewpoints.
The ability to create or import models and artifacts.
The ability to present repository information to support the stakeholders needs.
The following year Gartner [18] redefined minimal requirements as:
The ability to create or import models and artifacts;
The ability to present repository information to support the stakeholders needs;
A robust and flexible repository and meta-model that support changes and temporal relationships;
Administrative capabilities (audit, configuration, versioning).
As the years pass, requirements continue to change due to the developing maturity of these instruments [16]. The
existence of a metamodel evolved to the existence of an easily configurable metamodel that accommodates
change and complex relationships. Despite recent developments, there are still important features pushed aside
into second plan. Tools are usually not designed with interoperability in mind, feature that is of extreme
importance when faced with the necessity to integrate information from a myriad of sources (IT Management
Tools, Software design and development tools, etc.) [31]. This leads to the matter of in what dimension are EA
Tools reviewed.
The EA Tools Review Framework consists of two dimensions: the basic functionality of the tool, and the utility
of the tool to different professionals [25]. The Gartner Group also defines two criteria axis: Ability to Execute;
Completeness of Vision. Forrester defines three evaluation categories, Current Offering, Market Presence and
Strategy.
Figure 4 Magic Quadrant for Enterprise Architecture
Tools [17].
Figure 5 Forrester Wave: Enterprise Architecture Tools
[16].
22
23
Chapter 03
THE PROPOSED APPROACH
4 APPROACH SUMMARY
This thesis presents an approach for the automated creation of views that conform to the constraints of a
viewpoint. The developed work resorts to influences from formal disciplines such as graph theory, set theory and
to the idea of the Enterprise modelled as a graph, to univocally specify the content to be comprised in a view and
to describe the representation conventions that enforce how the content should be represented. From this
perspective, the approach proposes that the effort associated with the process of creating and of maintaining
architectural blueprints can be reduced through the incorporation of the automation of these processes in a
software solution. Therefore, as a reaction to the problem statement, this thesis proposes an approach to define
and use non-ambiguous viewpoint specifications to enable the use of automation in the constructions of
enterprise blueprints.
The work can be disaggregated into two stages:
Establish the means to specify the construction of enterprise blueprints;
Produce a software solution that automates the creation of enterprise blueprints.
4.1 FIRST STAGE
The first stage concerns the construction of viewpoints. The idea is not to propose a complete viewpoint template
but instead to identify and describe viewpoint sections, required by the approach, to enable the automated
creation of enterprise blueprints. Following the work of [38], the enterprise is perceived as a system and is
modelled as a graph, which is to say that the ontological system notion influences the classification of the graph
(If it is connected or unconnected and so forth). Such graph is the base model for the specifications comprised by
the viewpoint. Further detail on this matter is covered in section 5.2.
The current approach complies with the motto “Make a clear distinction between a model and its visualization”
[31] and enforces that the selection of the appropriate domain of a viewpoint should be distinguished from the
principles that guide its representation. This is a principle regarding concern separation originates from
ArchiMate [31] and is illustrated in Figure 6. The same content can be used in numerous graphical
representations with different notations, layouts or other drawing conventions. To abide to such, the approach
24
embraces the principle that the guidelines of the graphical representation can be influenced by the view whereas
the opposite is not verified. For example, the classification of the concepts can influence the icons, the colours,
the positioning guidelines, etc.
Model View Visualization
Viewpoint
Architect Stakeholders
select
derive
visualise
Figure 6 Separation of concerns: model, view, visualization and viewpoint. Adaptation from [31].
By imposing on the model a series of constraints, that express concerns and domain boundaries, one identifies
the content to be represented. Considering that the enterprise is modelled as a graph, the identification of the
content is indeed an identification of a sub-graph. Therefore the imposition of a constraint on the graph relates to
the identification of a sub-graph and the definition of the related set of nodes and edges. Thus a view that
conforms to a set of constraints identified in a viewpoint is the result of a union of all these sub-graphs. The
related specifications are addressed by a viewpoint part named Content Viewpoint, which is further described in
section 6.
To address the visualisation of the view, the viewpoint should comprise a second section that identifies not only
the drawing conventions but also the process description, expressing how one can assemble the view and the
conventions to produce the graphical view. The aforementioned viewpoint part is called Graphical Viewpoint
and is described in section 7.
Model View Visualization
Viewpoint
Architect Stakeholders
select
derive
visualise
Content
ViewpointGraphical
Viewpoint
Figure 7 Separation of concerns: considering two viewpoint parts.
25
Therefore the approach considers two viewpoint sections, illustrated in Figure 7, which are described in Chapter
4 preceded by a detailed description of the notion of an enterprise perceived as a system modelled as a graph in
section 5.
4.2 SECOND STAGE
The second stage of the work concerns the ability to build a software solution around the aforementioned
viewpoint sections and the capacity to automate the creation of the enterprise blueprints. This stage relates to
objectives (2) and (3).
The overall idea is illustrated in Figure 8, were the viewpoint specification serve as input for the solution. The
solution obtains the content from the repository and produces the enterprise blueprints. The solution is described
in section 8
Software Solution
Architectural
Repository
Viewpoints
Specifications Blueprints
Content
Figure 8 Overview of the software solution.
The solution is later be used in architecture initiatives of several organizations to establish if whether or not the
approach is useful to aid in the resolution of real life problems, by supporting up-to-date graphical
representations with no manual effort. The initiatives are described in section 9.
26
5 APPROACH FOUNDATIONS
What is an adequate formal model for the enterprise? Which are its basic principles and premises? These are
only some of the questions one needs to address. Influenced by architectural concepts such as views and
viewpoints and the ontological system definition, this section sets out to identify how these concepts can take
part in the specification of a formal model of the enterprise, and how such model is exposed to principles of
graph theory, set theory, and other related fields.
5.1 ONTOLOGICAL SYSTEM PERSPECTIVE OF THE ENTERPRISE
The notion of Systemicity regards the universe as a world of interconnected systems, so that everything is a
system or component of a system. Mario Bunge [6] [12] [19] had various intriguing primary concepts concerning
its ontological Model, the Bunge-System Model. Besides claiming that a system can be analysed into its
composition, environment and structure, the model also relies on a perception of the universe as a Systemicity.
Resorting to this concept, and sustained by authors such as Dietz [12] [13], Op't Land [35] and Sousa [38], the
analogy of an Enterprise as a system is regarded has critical to the rationale. Therefore the model used for the
enterprise must be able support this system perspective (see 5.2.2).
The approach recognizes enterprise as coupled with the ontological system notion (see 2.6.2) and therefore
assumes, as in the latter, that the Enterprise has a set of essential properties: composition; structure; environment.
Although [12] and [38] make reference to the property production this works deviates from it. Even though the
property and its notion applied to a system makes perfect sense, it does not take part in the extension of the
thesis.
The Construction of a system is the collection of its composition, environment and structure. The construction
can be described by the elements in the composition and the environment, as well as the relations of the
structure. If the aforementioned properties are part of the enterprise, the collection of its properties is its
construction. An example of a visualization of a construction is presented in Figure 9 where the composition is
represented by the grey elements; the environment is represented by the white elements; the lines represent the
structural bonds between the elements.
Figure 9 Representation of the construction of a system [12].
27
To cover all pertinent concepts three additional concepts can be referenced. The boundary is what separates the
composition and the environment, depicted by a gray line. The kernel of a system is a collection of the
composition together with the structural bonds between themselves, illustrated by the aggregate of grey elements
and lines fully contained inside the boundary. Finally, the operation is the collective activity between the
elements in the composition and the environment of the system, which is the manifestation of its construction in
the course of time.
The influence of the aforementioned concepts and how their formal definition incorporates the current approach
is covered in the next section.
5.2 AN ENTERPRISE MODELLED AS A GRAPH
The notations used by [12], [36] and [38], as well as the depiction of system constructions in a graph-like
representation, motivated the use of set theory and graph theory principles and concepts as a initial inspiration
for the definition of the specifications to incorporate in the viewpoints.
Graphs are abstract mathematical objects which are designed for describing relations between objects. The
objects are called nodes and the relations between objects are called edges. Graphs have long been a mean to
enable people to visualise information. As in Figure 9 the usage of graph-like diagram is generally understood,
thus powerful. Furthermore, the definition of graphs and their construction is mathematical hence formal. The
current approach recognizes these benefits and therefore considers that graphs are suitable modelling instruments
to encompass the viewpoint needs.
A starting principle of this thesis is that the enterprise is modelled as graph.
5.2.1 The Basics of a Graph Approach
Let an Enterprise E, be modelled as a graph of artifacts and their relationships, respectively the nodes and
edges of the graph. A graph is an ordered pair of disjoint sets , , with being a subset of the set (2)
of unordered pairs of [4]. The model is finite, as it should be considering the reality of an enterprise,
subsequently and are always finite, and respectively represent the set of nodes and the set of edges.
The order of is the number of nodes in and can be denoted by , which can be used for the cardinality
of a set. Thus . The size of is the number of edges in G. Therefore the notation , can
denote a graph of order n and size m.
In general, stakeholders have no interest or advantaged in the full scope and details. Their concerns, state which
parts are deemed relevant [31]. Thus stakeholders require specific views to focus on their concerns and put aside
unnecessary information. If the concerns dictate the accounted constraints in the identification of a construction,
and resorting to a sub-graph enables the selection of a subset of artifacts and relationships of a graph, then a sub-
graph can be considered analogous to the concept of a view. So, sustained by the aforementioned considerations,
by means of sub-graphs of one can address matters such as stakeholder concerns. Since a view conforms to a
viewpoint it becomes apparent that specifications in a viewpoint will to some extent address the definition of
sub-graphs.
28
A graph , is a sub-graph of , if:
(14).
(15). .
If contains all edges of that joint two nodes in the sub-graph is induced or spanned by and is thus
denoted by . A sub-graph of is an induced sub-graph if . If , then is said to
be a spanning sub-graph of [4]. These notions are illustrated in Figure 10.
Figure 10 Representation of a graph, an induced sub-graph and a spanning sub-graph [41].
Falling on the principle of Systemicity and taking into account that the enterprise is regarded as a system and
modelled as a graph, one could state that , where the universe is modelled as . Thus the
Enterprise is viewed as an induced sub-graph of the universe. But why is it and induction? The answer arises
from distinction between aggregates and systems.
Both an aggregate and a system are collection of items, but only the later has unity and integrity. Due to the
system analogy, and as stated in [6] and [12], the elements are grouped together by interaction bonds, and
therefore a graph modelling a system with unconnected nodes would be deviant. If elements of an enterprise are
not connected on any level, what would be the benefit of their consideration in a study? If there are nodes with
no connections, then they are not part of the construction, thus irrelevant from a perspective of a related set of
concerns. Therefore the connectedness of the graph is an issue.
As stated in [41] graphs are sometimes perceived as a “one piece”, which is an incomplete examination. As
observable in Figure 11 a graph can be either connected or disconnected. A walk in is a finite sequence of
edges in which any two consecutive edges are adjacent or identical, and the number of edges from the initial
node to the final node is called the length [41]. A walk in which all the edges and vertices are distinct is a
path. A graph is connected if and only if there is a path between each pair of relations. So in order to uphold
as an induced subgraph of , a path exists so that from any artifact one can reach any other artifact .
Furthermore in a system perspective, this implies that through the navigation of interaction bonds, any artifact in
the construction is reachable by any other artifact in the construction of the same system.
29
Figure 11 Example of a connected and a disconnected graph [41].
It is therefore a condition of this approach that the graph is connected and that any sub-graph is also
connected.
Let each artifact have a type , where is the set of all types. The expressions “a IsA y” and
state that is the type of artifact . A type defines the properties for artifacts of that type [38]. A
property can be a value or a reference to another artifact. If a reference exists between artifacts and , then a
relationship exists between them.
An artifact, as the incorporation of items in the construction of a system, can be a system or not. This is
identified by the category of the artifact. The statement implies that is the category of an
artifact . If an artifact is a system then , otherwise if is not a system
then .
Let each relationship be an ordered pair of , have a relationship type18
,where is the
set of all relationship types, and have a category , where is the set of all categories. For all
relationships the representation of relationship , connects the representation of with
the representation of . Although, as referenced in [38], the types of the relations can be influenced by the
types of the connected artifacts, the current approach addresses them as distinct , such is explained further
ahead in this section. A relationship type defines a set of ordered pairs of artifact types, referred to as .
So for , with , , a relationship , of the relationship type can
exist if and .
For a relationship type the statement implies that is the category of . If a relationship
type is classified by a category z then any relationship classified with such type is also associated with the
category. Therefore, for a relationship the statement implies that is the category of r. The
category of a relationship r = , can also be expressed as , instead of
, , for readability purposes.
For each relationship , and type where and r = , there is a
relationship , . So if a relation expressed that “ composes ”, then “ is composed by ”
18 Relationship types will be addressed only as types for simplicity matters, when the context allows it.
30
could be articulated by the complement relation. In sum the complement inverts the direction allowing a
complementary semantic interpretation
But what if there was more than one edge between the same two nodes? A pure graph 19doesn‟t allow the use of
parallel edges simply because its construction can‟t support it. By observing the Figure 12 and following the
aforementioned notation, even though there are two relationships and using pair notation, it is evident that
, thus leaving room for ambiguity. This issue also affects the notion of relationship type
due to it relying on the same notation. In order to use a pure graph, more nodes and types should be necessary.
Let these nodes be called binding nodes.
A relationship is in fact a pair of edges where the type of the binding node, referenced in both edges, is the
relationship type. The aforementioned ambiguity can be solved by considering such binding nodes. So
considering Figure 12 and using binding nodes and represented in Figure 13, the relationships would be
defined as , , , and , , , .
a01 a02
r01
r02
Figure 12 Representation of ambiguous relationships.
a02a01
c01
c02
Figure 13 Representation of unambiguous relationships.
For the sake of simplicity such abstraction is used throughout the work by considering relationship types.
Furthermore binding nodes are disregarded and therefore not considered in the set of all artifacts of a graph. As a
consequence no references will be made considering different relationships types for the same pair of artifacts.
Such also applies to relationship categories.
Throughout the thesis, sequences of graph operations will be described in pseudo-code. The general pseudo-code
conventions are identified in Appendix A and are based on the conventions used in [37] and [10]. The described
algorithms address to graphs, artifacts, relationships and sets; therefore a further description of associated fields
is in order. For example, since the introduction of set theory by George Cantor in 1874 [11], set has been subject
of various studies and considered one of the most fundamental concepts in mathematics, surrounded by
numerous theorems, corollaries, axioms, mottos, etc. Restrained by the scope of this work, one is only able to
address certain parts of such panoply, therefore only concepts considered essential to the exposure of the thesis‟s
ideas are presented.
19 Such is possible in multi-graphs or pseudo-graphs.
31
Let a set have an attribute cardinality which identifies the number of elements in a set. Therefore, for a set
, , , . An empty set is identified by the symbol .
Regarding a graph , , two attributes are introduced. The set of nodes of a graph is available through
the attribute nodes of the graph, so that . The set of relationships of a graph is provided by the
field edges, where . The creation of a node with “ID” as the identifier has the form I
and the declaration of a new edge between the nodes and is denoted as , . The creation of
a graph is expressed in the form graph ( , ) where the two empty sets address the set of nodes and the set of
edges.
For a directed edge , where and are artifacts, one can use attributes to identify the first
element of the pair, called origin; or to identify the second element, called the destiny. So let a relationship r
have an attribute origin were , and have an attribute destiny were .
5.2.2 Supporting the System Perspective
In accordance to a system‟s essential properties (see 2.6.2) there must be a clear way to identify the composition,
environment and structure of the system. The approach resorts to the relationship categories for the distinction
of elements of the construction, therefore uses three categories, each corresponding to an essential system
property. So with as the set of all categories its definition is:
(16). I , I , I
The category ISCOMPOSITION is intended to aid in the identification of elements that belong to the composition of a
system. For a relationship , and I = category(r):
The pair , intendeds to express “ is composed by ”.
The pair , intendeds to express “ composes ”.
The artifact category of is such that
The definition of the composition of a system (07) for a system can then be expressed as:
(17). ≺ ,
≺ ,
≺ ,
The category ISENVIRONMENT is intended to aid in the identification of elements that belong to the environment of
a system. For a relationship , and I = category(r):
The intended meaning of , is “ has in its environment ”.
The intended meaning of , is “ belongs to the environment of ”.
The artifact category is such that
32
The definition of the environment of a system (08) for a system can be expressed as:
(18). ,
,
The category ISSTRUCTURE is proposed to aid in the identification of the unordered pairs of elements that express
the structure of a system. For an artifact with , a relationship , and
where :
The intended meaning of { , is “ and establish a structural relationship of a system”.
The definition of the structure of a system (09) for a system can then be expressed as:
(19). , , I ,
5.2.3 Using the System Perspective
To best understand previous implications an example is in order. The objective of the following example is the
identification of the construction of a system based on a scenario s01 that comprises the construction of a
graph , and the identification of the relationship categories. The construction is obtained by resorting to the
application of the definitions in (17), (18) and (19).
Let Figure 14 be a representation of a graph , which is a subgraph of a , representing a partial view20
of
the construction of a system .
The graph is defined as such:
(20). ,
(21). , , , , , , , , ,
(22). , , , , , , , , , , , , , ,
, , , , , , , , , , , , , , ,
20 The view includes the identification of the relationship‟s categories instead of its types as displayed previously.
33
a11
a01
a12
a13
a22
a24
a21
a23
a25
a26
ISENVIRO
NMENT
ISSTRUCTURE
ISCOMPOSI
TION ISCOMPOSITION
ISSTRUCT
URE
ISCOMPOSITION
ISCOM
POSITION
ISCOMPOSITION
ISCOMPOSITION IS
STRUCTURE
ISSTRUCTURE
ISSTRUCTURE
ISSTRUCTURE
ISCOMPOSITION
ISCOMPOSITION
Figure 14 Representation of the graph for s01.
The distribution of the relationships by category is as follows:
(23). , , ,
, , , , ,
,
(24). ,
(25). , ,
, , ,
,
To conform to (17) and by analysing (23), artifacts , and must represent systems and therefore:
(26).
The partial construction21
of the system , according to (17), (18) and (19), is as follows:
(27). , , ,
(28). ,
(29). , , , , ,
21 Since the construction may not be completely represented.
34
The partial construction of the system , according to (17), (18) and (19), is as follows:
(30). ,
(31).
(32). ,
With system with the construction , , , system with the construction < C( ),
E( ), S( ) > and with the construction , , , then and are subsystems of
, if and only if the conditions (04), (05) and (06) are verified such that :
(33).
(34).
(35).
(36).
(37).
(38).
Therefore the partial construction , , of the system is defined by:
(39). y y ≺ , y I z y y
I z ≺ y y, z I y ≺ , y
I
, a a
, , , , ,
, , , , , , ,
(40). ,
,
(41). , x, y I ,
01)}
, , , , , , , , , , ,
35
5.2.4 Time Dimension
An enterprise is constantly subject to change, and the ability to accommodate an ever-growing change rate is a
major factor regarding the survivability of an enterprise. How can time influence the enterprise model? Each
occasion the reality of the enterprise is altered, that change must be propagated to its model. In [38] the agents
responsible for change were the projects, and the artifacts of the graph had an associated state of existence. Since
addressing the time dimension is related only to the capacity to accommodate the evolution of the model, the
project perspective is considered outside the scope and only the artifact‟s states of existence are considered.
The idea is that the enterprise in a moment t is a view of the graph and therefore a sub-graph of . The
appointed moment in time or an ordered array of adjacent moments identify the view‟s constraints. Therefore by
resorting to the artifacts property values and comparing them to the imposed value or range of values, it should
be possible to identify a sub-graph that represents the enterprise in the addressed time reference.
Let the artifacts have a property that identifies the moment in time it became “alive” and a property
that identifies the moment when it becomes “dead”.
Let be a representation of the enterprise at the moment t, where is an induced sub-graph of and is
defined by the following:
(42). ,
(43).
(44). ,
So let
be a representation of the enterprise in the between the moment and , and is defined by the
following:
(45).
,
(46).
(47).
,
Having described how sub-graphs can be defined and used as views constrained by a single moment or a
collection let a scenario comprise a graph illustrated in Figure 15, where the property values of graph‟s
artifacts are defined in Table 13.
36
a05
a01 a02
a03a04
a06
Figure 15 Representation of the graph of scenario s02.
0 0
0 0
0 10
0 10
2 3
4 10
Table 13 Property values of the artifacts in s02.
Taking into account and the view specifications:
Figure 16[a] is an example of a representation of a sub-graph
of
for and .
Figure 16[b] is an example of a representation of a sub-graph of
for .
Figure 16[c] is an example of a representation of a sub-graph of
for .
a01 a02
a03a04
a01 a02
a03a04
a06
[b] [c]
a01 a02
a03
a05
a04
[a]
Figure 16 Representation of the sub-graphs in distinct time intervals.
The notion of time is transversal to the approach. To apply time dimension principles to any other graph
specification the only condition that must be verified is that the graph must be a sub-graph of . However, since
the constant use of time views would add unwanted complexity to the presentation of the remaining graph
related specifications, the time dimension will only again be taken into account in 8.4.
37
Chapter 04
COMPRISED SECTIONS OF A VIEWPOINT
6 CONTENT VIEWPOINTS
A content viewpoint is a part of a viewpoint, which comprises the specifications of the constraints and concerns
that dictated which content will be graphically represented in a blueprint. This section addresses the concepts and
principles inherent to the construction of a view.
6.1 CONTENT METAMODEL
The ability to accommodate different metamodels must be covered. Also required is the ability to deal, to some
extent, with changes encompassed by metamodels. Different viewpoints can comprise distinct metamodels
therefore a viewpoint must either specify the metamodel to which it refers to or make reference to its
specification.
The content metamodel identifies how the artifact types and relationship types, addressed by , are structured.
Let the content metamodel be modelled as the graph , as an ordered pair of sets, such that , ,
where is the set of all artifact types, modelled as nodes, and the set of all relationship types. Each pair of
artifact types in PPAIRS defined by a relationship type is modelled by an edge. The graph has the same
characteristics as and therefore it is a finite, directed, connected graph.
A viewpoint may comprise or reference the complete content metamodel or a sub-graph of the metamodel.
Any partial reference must abide to the principle that a graph is an induced sub-graph of .
The set of artifact types and the set relationship types of a graph are the same as the ones used to classify the
construction of .
(48).
(49).
However if only a partial metamodel is referenced and considering (14) and (15), then:
(50).
(51).
38
Taking the former into account it becomes obvious that the use of partial metamodels results in a first level of
constraints, hence the limitations imposed by the metamodel have to be verified in the remaining specifications.
Since the metamodel can be affected by change, a good practice is to minimise the impact on viewpoint
specification that was introduced by the changes. By adding a level of indirection one can defend itself from
simple changes such as the use of different concept identifiers, either due to someone deciding that the name was
no longer appropriate or simply because the metamodel is implemented abroad and the language is, for example,
Spanish instead of English. This level of indirection is achieved by a correspondence mapping, which also
allows the use of simple and abstract identifiers that can avoid context influences to the specification. The need
for this level of indirection was identified from real-life architecture initiatives, where constant malpractices
remain: Even after the specification of the viewpoints, the enterprise metamodel was still in transformation.
Faced with such a reality a cross-validation instrument became needed.
6.1.1 Correspondence Mapping
Information sources of an enterprise are spread throughout various infrastructures, formats and are generally
inconsistent. As the most valuable asset of an enterprise, its dubious reliability and the difficulty to access it has
long been a problem subject to numerous studies, initiatives and so forth that continues do dazzle and torment
the IT Community. Restricting the subject to the scope of this thesis, a well established practice in Enterprise
Architecture is the consolidation of all the essential information in a central repository, an architectural
repository. Through this centralization effort, a more accurate model of the enterprise is expected.
As stated in 1.3 the information used to create and manage Blueprints, is maintained by an architectural
repository. Such information is considered as a premise to be adequate to serve as the model of an enterprise and
therefore a bridge must be established between the repository and the specifications encompassed by the
viewpoints.
The architectural repository used for this work is object oriented in a matter that information is encapsulated into
class instances, with attributes inherited from its class type, and structured by references between such instances.
Let an instance I instantiate class , where is the set of all instances, and is the set of all classes.
The statement implies that an instance is an instantiation of a class . Let a reference
have a reference type , where is the set of all references and the set of all reference types.
The correspondence between the repository and a graph has the following guidelines:
Each instance is modelled as an artifact;
An instance is to a class as an artifact is to its type;
Each attribute of an instance matches a property in an artifact;
Each reference between instances is modelled as a relationship between artifacts;
A reference is typified the same way a relationship is.
For a repository to be referenced by a viewpoint a correspondence mapping must be defined. The purpose of
such mapping is to establish the association between the set of classes and artifact types, between reference types
39
and relationship types, and the identification of the categories. The matching of the types is used to validate the
specification of the metamodel and subsequently employed for the same purpose for any other that makes
reference to the metamodel as a validation instrument.
Let a correspondence mapping, identified by , have a construction , , , where:
The artifact correspondence mapping is a set of pairs where the first element of each pair is a class
and the second is an artifact type.
o Each of these pairs establishes a correspondence between the class and the artifact type.
o The existence of a pair , where and , implies that any I that is
an instance of is modelled as an artifact that is classified with the type .
The relationship correspondence mapping is a set of pairs where the first element of each pair is a
reference type and the second is a relationship type.
o Each of these pairs establishes a correspondence between the reference type and the
relationship type.
o The existence of a pair , where and , implies that any with a
type is modelled as a relationship that is classified with the type
The category correspondence mapping is a set of pairs < z, where the first element
identifies a relationship category and the second is a set of reference types that are classified according
to the category.
The system correspondence mapping is a set denoting the classes to be covered by the artifact
category ISSYSTEM.
By determining the correspondences, one is also establishing the available types and categories. The artifact
types and relationship types available for the specification of a viewpoint, that addresses the correspondence
mapping, can be identified by (52) and (53) respectively. The expression in (54) denotes the available
relationship categories, whereas (55) determines the relationship category of a relationship type.
(52). y , y
(53). ,
(54). z,
(55). catego y z, ,
A viewpoint may comprise the complete correspondence mapping of a repository or simply a part of it, given
that viewpoints can be subject to pre-scoping. A partial correspondence mapping ‟ is well-founded if it
originated from a valid correspondence mapping and the following is verified:
(56).
(57).
40
(58).
(59). z z p z ,
z z p z , z
How does one validate a correspondence mapping? If all the elements in the construction are well-structured
then the correspondence mapping is valid. The artifact correspondence mapping must abide the following:
An artifact type models one and only one class, and a class cannot be modelled by more than one
artifact type, hence there can only be one occurrence of each class or type (60).
(60). y y , y
y y , y p p y
The relationship correspondence mapping must abide the following:
A relationship type models one and only one reference type, and a reference type cannot be modelled
by more than one relationship type, hence there can only be one occurrence of each relationship type or
reference type (61).
(61). ,
, p p
The category correspondence mapping is well defined if:
There is only one occurrence for each category;
A reference type is associated with only one category;
Hence:
(62). z z p z ,
z z p z , p p
z
To establish the relation of the types identified in and the types of and if the correspondence mapping is
complete then:
(63).
(64).
However if the correspondence mapping is partial then considering (56) and (57) :
(65).
(66).
41
Therefore, regressing to the content metamodel then taking into account (50),(51),(63),(64),(65) and (66) :
(67).
(68).
(69).
(70).
6.1.2 Using Correspondence Mapping and Metamodel
This section describes a scenario which is an example of the definition of a correspondence map
and the associated . Besides contextualizing the utilization of the aforementioned instruments it will also
support further examples and scenarios presented in remaining sections.
The scenario starts from a populated repository modelled as the graph
, , a
correspondence mapping and a content metamodel modelled as a graph
, . The
contents of the repository will be address be means of sub-scenarios throughout the remaining chapters. The
construction of is defined by:
(71). , , , , , ,
, , , , , ,
, , , ,
,
(72). , , , , , , , ,
, , , , ,
(73). , , , ,
, , , , ,
(74). , , ,
42
TAPPLICATIO
N
TCOMPONEN
T
TPLATFORM
TENTITY
TPROCESS
TPROJECT
TSTAKEHOL
DER
TSOLUTIONTDOMAIN R01
R01
R01
R02
R03 R05
R04
R06R07
Figure 17 Representation of the content metamodel for s03.
Let , illustrated in Figure 17, be the metamodel for , detailed as:
(75). , , , , , , ,
,
(76). , , , , , ,
(77). , , , ,
,
(78). ,
(79). ,
(80). ,
(81). ,
(82). ,
(83). ,
(84).
(85).
(86). , , , ,
43
6.2 BLUEPRINT CONTENT SELECTION
When creating a view, a set of procedures to take into account the concerns for which the view is built, therefore
to produce an enterprise blueprint one must encompass means on how to select its adequate content.
The content selected from the graph is named addressed content and it is modelled as a graph
, , which is a sub-graph of the graph .
The concerns of a stakeholder are not always simple, to cope with complexity and to enable adequate answers,
the questions must sometimes be broken down into smaller parts. In the current context, such implies that
can result of the union of more granular parts. So, let a graph , model the result of imposing
a constraint on and be named content selection condition. Hence is a sub-graph of and results of
the union of all :
(87).
An initial question may arise, how granular can a selection condition get? In an extreme perspective, the graph
would be a construction of two empty sets, but the usefulness of such liberty would be none. The set can be
empty but the definition of a set cannot, simply because no concern would be addressed. However, such
does not imply that or can‟t be empty. If no artifacts conform to the conditions then none should be
presented. Therefore the simplest definition of or must at least specify one condition regarding the set
of artifacts.
A rule of thumb is suggested to identify a minimum number of : for each referenced artifact type specify at
least one . The exact number should vary according to the complexity and interdependency of the selection
restrictions, always taking into account legibility concerns.
For example, if all types in (75) as illustrated in Figure 17 were addressed in a then the suggested number of
is equal to . Therefore the addressed content could be defined modelled as the graph:
(88).
Let the scenario relate to and identified in , and be described by the following:
“Select an Application named , the Application Components related by and the
Platforms related by to the components. All elements of the type Platform should be
grouped together and the Application should comprise its Application Components
grouped by the corresponding application layer that is identified by the value of the
property of an Application Component."
To exemplify the formalization process in a reverse-engineering approach, let , , illustrated in
Figure 18, represent the addressed content from scenario , where:
44
the set of artifacts and relationships
is identified in (89) and (90);
the set of artifact types is disclosed in (91) and the set of relationship types
in (92);
the artifact type matching is declared in (93), (94) and (95);
the relationship type matching is acknowledged in (96) and (97).
a01
c01 c02 c03 c04
p01 p02 p03
Figure 18 Example of a representation of the addressed content for s04.
(89). , , , , , , ,
(90). , , , , , , , , , , , , , ,
,
(91). , ,
(92). , }
(93).
(94).
(95).
(96). , , , , ,
(97). , , , , ,
From previous guidelines and considering the following paragraphs describe a
specification of three , from informal description in , to the specification of the set of artifacts and
relationships. For explanation purposes the following is considered: for any relationship if , if one of the
elements of the pair isn‟t covered by the specification of , he is depicted in the illustration of .
45
For
and considering “an Application named ”, the statement identifies a type Application and a
property restriction where name equals “ ”.
(98).
,
(99).
(100).
For
and considering “Application Components related by ”, the statement identifies a type
Application Components and a relationship type with artifacts of the type Application.
(101).
,
(102).
,
(103).
,
,
For
and considering “Platforms related by to the components”, the statement identifies a type
Platforms and a relationship type with artifacts classified as .
(104).
,
(105).
,
(106).
,
,
a01
a01
c01 c02 c03 c04
c01 c02 c03 c04
p01 p02 p03
[a] [b] [c]
Figure 19 Representation of the first [a], second [b] and third [c] content selection conditions for s04.
So illustrated in Figure 18 is the result of the union of the graphs depicted in Figure 19 where:
46
To enable the reuse of viewpoints in the construction of multiple views the specification should comprise
discriminated slots with no pre-disclosed values, with the values only being established upon construction of the
view.
As an example consider that only mentioned “an Application identified by name” instead of “an
Application named ”. The specification of
defined in (99) would have to include an open reference
instead of the explicit assertion of the identifier.
Let a parameter reference an artifact‟s identifier, where is the set of all parameters. Considering the
aforementioned example and to notion of parameter, then
could be redefined as:
(107).
This enables the reutilization of the viewpoint in the construction of as many views as the number of valid
parameter values. Therefore if had x applications then the viewpoint would support the construction of x
views.
6.3 FILTERS
The approach considers that the addressed content, when represented in a blueprint, may yet be subject to further
constraints. Considering the context of analyses methods [20] encompassed in Operations of view (see 2.4), the
approach defines a filter as a view of a view. More precisely a filter is a view of the addressed content and
therefore a sub-graph of .
Let a filter be modelled as a graph , with no connectedness constraints and where.
(108).
(109).
The specification of filters in a viewpoint supports finer grain analysis to the resulting blueprint. Considering a
blueprint that depicts all the applications of an enterprise, one might consider useful, while in the context of all
depictions, the ability to denote a set of the elements that conform to a set of condition. For example, the main
concern is to identify all the applications of an enterprise but a pertained analysis may require the identification
of the applications that are scheduled for decommissioning (see 8.3.2). The design of the filter can express the
condition by which it is possible to identify the conforming applications and thus by binding a representation
convention with the filter, one could alter the related depictions, by, for example, changing the icon‟s colour.
A similar tool has previously been referenced although in a disguised fashion. The principles here defined relate
to the Time Dimension (see 5.2.4), however due to the fact that time is considered to be ever-present and not
context dependent, it is described separately.
47
6.4 AGGREGATION PROCEDURES
When displaying information, it is sometimes useful to resort to grouping mechanisms, either to identify types,
categories or other classification guidelines regarding the set of elements it identifies.
To enable such behaviours the approach uses aggregation procedures that comprise the definition of content
aggregation. The aggregation procedures are algorithms described in pseudo-code (see Appendix A: Pseudo-
code Conventions) that have the single purpose of specifying how a content aggregation is achieved.
A content aggregation is modelled directed graph , , where is the set of all artifacts and
is the set of all aggregation relationships. A content aggregation must always include content of the
repository and therefore:
(110).
An aggregation artifact models a pertinent concept or notion that does not have a matching object in a repository
but, that is useful in the organization of content referenced in a view. An aggregation artifact may reference a
property of an artifact and thus be identified by its value, or may be declared by the explicit assignment of a
constant serving as the artifact‟s identifier (111). For an artifact with a property an aggregation artifact
can be created in the form of (112).
(111). I
(112).
An aggregation relationship is an ordered pair of nodes that establishes an association between an artifact and an
aggregation artifact, or vice versa.
A simple template identified in Algorithm 1 is proposed for the aggregation procedures.
AGGREGATEPROCEDURE( )
1 ,
2 ⊳
3
Algorithm 1 Example of an aggregate procedures template.
To exemplify the procedure specification the analysis of is resumed. Scenario states that “...All elements
of the type Platform should be grouped together...”, therefore a content aggregation must have an aggregation
artifact and an aggregation relationship for each artifact representing a platform. Let the artifact identified by the
abbreviation “p s” be an aggregation artifact that represents the entity that is used to group the elements of the
type Platform.
Let the AGGREGATEPROCEDURE01 described in Algorithm 2 be an aggregate procedure for .
48
AGGREGATEPROCEDURE01( )
1 ,
2 p s
3
4 node
5
6
,
7
Algorithm 2 Description of the first aggregate procedure for s04.
Based on set of artifacts identified in (89), Algorithm 2 and by depicting the aggregation artifacts and
aggregation relationships with dashed lines, Figure 20 is an example of an illustration of .
p01 p02 p03
pls
Figure 20 Representation of the output of the first aggregate procedure for s04.
Scenario went on to state “...the Application should comprise its Application Components grouped by the
corresponding application layer that is identified by the value of the property of an Application
Component.”.
The first part of the statement identifies that a walk of length 2 should exist, relating the artifact classified as
Application and the artifacts classified as Application Component. If length is equal to 2 then a third type of
artifact is involved, aggregation artifacts. Therefore, it is necessary to create aggregation relationships between
Application artifacts and aggregation artifacts and between the latter and Application Component artifacts. The
second part of the sentence explicates how the identifiers of the aggregation artifacts are encountered.
So let the content aggregation bound to the previous exposure, be defined by aggregation procedure in
Algorithm 3.
AGGREGATEPROCEDURE02( )
1 ,
2 node
3
4 node
5
6
7
, ,
8
Algorithm 3 Description of the second aggregate procedure for s04.
49
To finish the example, by considering (89) , Algorithm 3, and taking into account Table 14 where the property
values of the components are identified, the Figure 21 is an illustration example of .
Table 14 Property values for Application Components of s04.
a01
c01 c02 c03 c04
lay02lay01
Figure 21 Representation of second aggregate procedure for s04.
6.5 CONTENTS OF A BLUEPRINT
The purpose of the specifications of content viewpoint is to give the architect the resources with which to
construct a view. A view comprises the contents to graphically represent in the Blueprint and its definition
establishes the base work model for the Graphical Viewpoint specifications. Let a view be modelled as a
graph , , which conforms to a content viewpoint if it is defined has the union of the addressed
content and the content aggregations:
(113).
So in a retrospection to and considering ,
and , the resulting view
is specified by
(114) and is illustrated in Figure 22.
(114).
a01
c01 c02 c03 c04
p01 p02 p03
pls
lay02lay01
Figure 22 Representation of the view graph for s04.
50
6.6 CONTENT VIEWPOINT SECTION STRUCTURE
This section presents the guidelines to structure the Content Viewpoint section. The guidelines have as subjects
the main notions described in the previous sections. The content guidelines in Table 15 identify what
must/should be comprised or referenced in the viewpoint section, organized by subject.
Sub-section Content guidelines
Repository
identification.
The repository must be identified, typically by the unique identifier of the database
and the associated Enterprise Architectural tool.
Correspondence
Mapping.
The correspondence mapping associated with the repository must be comprised or
referenced.
Optional. Comprise or reference the partial correspondence mapping.
Optional. Reference the rules used to validate a correspondence mapping.
Content Metamodel. The content metamodel specification of the referenced repository must be comprised
or referenced.
Optional. Comprise or reference the partial metamodel specification.
Optional. Reference the rule used to validate a metamodel.
Optional. The metamodel‟s application configuration file.
Addressed Content The section must identify and specify the information selection conditions and the
resulting address repository information.
The section must identify the set o available parameter slots.
Filters Optional. Comprise specification of applicable filters.
Optional. Identification of Time Dimension restrictions.
Content Aggregation Identification of the content aggregations and the specification of the respective
aggregation procedures.
Optional. Reference to the Pseudo-code Conventions.
Table 15 Content guidelines for the Content Viewpoint.
51
7 GRAPHICAL VIEWPOINTS
The adequacy of a graphical representation is bound to its audience, its stakeholders. Whereas a landscape map
can be a useful instrument for a CEO, a UML class diagram would typically have lesser value as a
communication artifact. How often does one encounter a CEO that can distinguish a composition association
from an aggregation association? Well, not very often. The reason is that he simply doesn‟t need to know the
difference, since he is not a typical audience for such type of representations.
Therefore besides the inherent granularity issue, it is plain to see that the viewpoint concerns are also bound to
representation/drawing conventions. In [26], a drawing convention is defined as a basic rule that a drawing must
satisfy to be admissible. This notion might be taken lightly in a preliminary reading, but a drawing convention
of a real-life application can be extremely complex and can involve many details of a drawing.
Stating that an icon identified by X should be placed “above” the icon Y, is surely a guideline but nonetheless an
ambiguous one. The layout of a graphical representation must be described with more than vague direction
indication, otherwise there are distinction factors between [a] and [b] illustrated in Figure 23.
X
Y
X
Y
[a] [b]
Figure 23 Example of symbols laid out differently due to the ambiguity of the graphical guideline.
With the purpose of achieving automated construction of the graphical representation one cannot rely on woolly
or poorly structured specifications. As defined in [24] a viewpoint is a set of conventions for constructing and
using a view. Since this thesis takes a split approach, by separating the means of obtaining the content (see 6)
and the means to represent it, a graphical viewpoint is portrayed as a set of conventions for constructing and
using a graphical view.
This section presents the base ideas for defining graphical viewpoints, such as the concepts, algorithms and
integration with the previous viewpoint section.
7.1 GRAPHICAL SPECIFICATION
A graphical viewpoint is a viewpoint section that serves to accommodate the specification of drawing
conventions used to produce a graphical representation of a view that conforms to a content viewpoint.
The content to portray in the Blueprint is identified by a graph . To express the constraints and guidelines of a
graphical representation the approach associates elements of the graph with objects that impose the conventions
based on the artifacts‟ and relationships‟ classifications. These objects are called graphical elements. A
graphical element has attributes, methods and is defined according to its graphical type. The rules of the
52
associations and the method orchestration are specified by a graphical orchestration. A graphical viewpoint can
also make reference to other algorithms to sustain the terms of the types and the orchestration.
7.1.1 Graphical Essentials
A graphical element is classified according to a graphical type, which dictates its methods and attributes. The
specification of the methods is described in pseudo-code and the implementation varies according to the type.
The keyword this is used to identify the element instance. The naming convention for graphical types is camel
case, with the first letter in lower-case. For a node the statement asserts that a graphical
element classified by the graphical type is associated with .
The algorithms comprised by a graphical type describe the conventions by which the associated content is
drawn. The blueprint drawing space is a defined as a horizontally-flipped first quadrant of a two dimension
Cartesian coordinate system, illustrated in Figure 24.
0
1 2 3
1
2
3
0
x-axis
y-a
xis
Figure 24 Blueprint drawing space.
A graphical element works as a decorator, in the decorator design pattern, in the sense that he extends the
artifacts with means for them to be drawn according to the conventions. The types provide attributes that define
the location depiction and dimensions of the element in the drawing space. An additional field is required to hold
reference to the appointed artifact.
Thus, a graphical type has five base attributes:
icon - An attribute that identifies the image that is used to depict the associated artifact.
o For example, a reference to UML Notation identifying the class icon used in class diagrams.
xCoordinate - The smallest value in the x-axis covered by the icon.
yCoordinate -The value of the icon apex.
height -The vertical distance from the lowest part of the icon to the apex.
width - The horizontal distance from the xCoordinate to the largest value in the x-axis comprised by the
icon.
content - An attribute that references the associated artifact of the graph .
o The reverse reference is denoted by an attribute wrapper of an artifact.
53
Depending on the implementation, the method can either be a simple pair of statements initializing the attribute
values, or it can contain a number of procedures identifying how such attribute values are calculated.
Graphical types have two default methods: CALCULATESIZE; CALCULATEPOSITION. The attributes height and width
are initialized or initially influenced by the method CALCULATESIZE. CALCULATEPOSITION relates to procedures that
affect the position of the icon in order to cope with surrounding influences (e.g. a translation transformation).
7.1.2 Graphical Orchestration
A Graphical viewpoint comprises a graphical orchestration that includes:
- The view.
- Set of graphical types.
- Set of entry points.
Four base procedures:
o ASSOCIATE o IDENTIFYENTRYPOINTS o CHOREOGRAPHELEMENTMETHODS o DISTRIBUTEELEMENTS
As stated previously, the view is a primary input for the constraint definition of the current viewpoint
section.
The second major input is the set that identifies the available graphical types. By “available” the statement
implies that the types belonging to the set are the only ones referenced throughout the remaining procedures.
Each type has distinct method implementations and the execution of the graphical element‟s methods can
influence other elements. This influence regards the capacity of a graphical element to invoke the methods or
alter the attributes of adjacent elements.
An entry point is an artifact that is the initial node of a walk in , where each node influences the subsequent
adjacent node. An entry point cannot take part in any other walk unless as its initial node or unless the walk is
defined inside DISTRIBUTEELEMENTS. The set of entry points has the constraints defined in
IDENTIFYENTRYPOINTS.
IDENTIFYENTRYPOINTS ( )
1
2 ⊳
3
Algorithm 4 IdentifyEntryPoints method template.
The ASSOCIATE method expresses the conditions that dictate how the artifacts are associated with a graphical
type. The description in Algorithm 5 is a template for this kind of procedure and the number of cited conditions
is equal to the cardinality of .
54
ASSOCIATE ( )
1 node
2 ⊳
3 ⊳
4 ⊳ “ ”
Algorithm 5 Associate method template.
The CHOREOGRAPHELEMENTMETHODS algorithm defines the number of influence walks, by expressing the
invocation order of the entry point‟s methods. Since there is a limited number of walks, not all the possible path
combinations are travelled hence a further iteration is required to establish the influences among the entry points.
Such iteration is described in DISTRIBUTEELEMENTS and can also comprise additional graphical depictions such as
textual, arrow-like depictions or overlapping symbols. Considering as global, then Algorithm 6 is an example
of a specification of graphical orchestration.
GRAPHICALORCHESTRATION( )
1 I I I
2 ASSOCIATE
3 CHOREOGRAPHELEMENTMETHODS ,
4 DISTRIBUTEELEMENTS ,
Algorithm 6 GraphicalOrchestration method template.
7.1.3 Support Algorithms
This section presents examples of support algorithms that to enable a more agile the use of graphs and simplify
the definition of complex procedures. This “library” encompasses algorithms that cover the notion of adjacency
through the identification of nodes or relationships based on the direction of the edges attached to a provided
node.
The CHILDNODES, as presented in Algorithm 7, is used identify any node of a parameter graph that connects
through any existing relationship to the parameter node and where the provided node is the origin of such
relationships.
CHILDNODES(graph, root)
1
2 edge
3
4
5
Algorithm 7 ChildNodes support algorithm.
Algorithm 8 describes CHILDEDGES, which returns the set of all relationships belonging to a given graph, where a
parameter node is the origin of the relationships.
CHILDEDGES(graph, root)
1
2 edge
3
4
5
Algorithm 8 ChildEdges support algorithm.
55
The PARENTNODES, in Algorithm 9, returns a set of nodes that are adjacent the parameter node and where the
node is the origin the relationship defined by the pair.
PARENTNODES (graph, root)
1
2 edge
3
4
5
Algorithm 9 ParentNodes support algorithm.
As in Algorithm 8, the implementation of PARENTEDGES, provided in Algorithm 10, differs only in the condition
that the given node, root, is the destiny of the relationships, instead of the origin.
PARENTEDGES (graph, root)
1
2 edge
3
4
5
Algorithm 10 ParentEdges support algorithm.
7.2 GRAPHICALLY REPRESENTING A VIEW
This section presents an example of the contents of a graphical viewpoint based on scenarios s03 and s04, and
configured to produce the representation illustrated in Figure 25.
pls
p01
p02
p03
a01
lay01
c01
lay02
c02
c03
c04
Figure 25 Desired graphical representation for s04.
56
7.2.1 Defining Graphical Types
To establish the base representation conventions, the initial step is to identify and describe the graphical types,
their attributes and methods. To enable more simple algorithmic descriptions the resort to support algorithm
libraries is advised. When a series of procedures or instructions is repeated throughout the specification of either
the graphical types or the graphical orchestration the advice is to isolate such functionalities in a comprising
support algorithm. For this example Algorithm 11 is used as a support algorithm and is therefore available for all
the others.
AGGREGATECHILDNODES is an extension of Algorithm 7 that besides identifying adjacent nodes of a root node also
filters the result according to the category of the edge. More precisely only adjacent nodes connected by an edge
categorized as are returned.
AGGREGATECHILDNODES( , )
1
2 edge
3
4
5
6
Algorithm 11 AggregateChildNodes support algorithm.
Having identified the parts of a support library one moves on to define the types. The set of available artifact
types is defined as , .
Both the types have the base attributes and two additional attributes and . The representation the
graphical elements can comprise child depictions implying that the latter overlaps a part of the parent‟s
depiction, influencing its size. These symbols are disposed in a layered manner and the number of symbols per
layer and consequently the number of layers is influenced the value of a ratio. The attribute identifies
the number of vertically staked layers and identifies the maximum number of child depictions for any
layer. For the sake of simplicity, the attribute icon of every element is considered to reference a rectangle with a
textual representation the associated artifact‟s identifier.
The type Symbol has only the base methods. Its instances are not intended to comprise other depictions and have
a fixed size. Both the methods comprise only attribute initializations.
Symbol.CALCULATESIZE ( ,ratio)
1
2
3
4
Algorithm 12 CalculateSize method for graphical elements classified as Symbol.
57
Symbol.CALCULATEPOSITION ( , , )
1
2
Algorithm 13 CalculatePosition method for graphical elements classified as Symbol.
The Container type has two base methods and two additional methods. Algorithm 14 calculates the height of the
graphical element taking into account the layout and number of comprised depictions.
Container.CALCULATEHEIGHT( )
1
2
3
4
5
6
7
Algorithm 14 CalculateHeight for graphical elements classified as Container.
Algorithm 15 calculates the widest layer and establishes it as the required width of the container. By this it is
guarantying that container depiction comprises in width the arranged child graphical representations.
Container.CALCULATEWIDTH( )
1
2
3
4
5
6
7
Algorithm 15 CalculateWidth for graphical elements classified as Container.
The CALCULATESIZE for containers establishes the height and width of the container based on the graphical
distribution on the comprised symbols.
Container.CALCULATESIZE ( ,ratio)
1 I ,
2 node
3 appe I ,
4
5
6 CALCULATEWIDTH( )
7 CALCULATEHEIGHT( )
Algorithm 16 CalculateSize method for graphical elements classified as Container.
Algorithm 17 sets the coordinates of the Container according to the input parameters and then calculates the
coordinates for each of the comprised children and invokes the respective homonymous method.
58
Container.CALCULATEPOSITION ( , , )
1
2
3
4 I ,
5
6
7
8
9
10 I I , ,
Algorithm 17 CalculatePosition method for graphical elements classified as Container.
7.2.2 Defining the Orchestration
Having established the set of types and their implementation, the graphical orchestration can be defined and is
thus described in Algorithm 18.
GRAPHICALORCHESTRATION( )
1 I I I
2 ASSOCIATE
3 CHOREOGRAPHELEMENTMETHODS ,
4 DISTRIBUTEELEMENTS ,
Algorithm 18 Graphical Orchestration for s04.
Following the order of the graphical orchestration:
IDENTIFYENTRYPOINTS ( )
1
2 node
3 PARENTNODES( , )
4
5
6
Algorithm 19 IdenfityEntryPoins for s04
The execution of IDENTIFYENTRYPOINTS for graph will result in , .
ASSOCIATE ( )
1 node
2 I ,
3
4
5
6
Algorithm 20 Associate for s04
59
The ASSOCIATE for graph will lead to the associations identified in Table 16.
Artifact Graphical type
Container
Symbol
Symbol
Symbol
Symbol
Symbol
Symbol
Symbol
Container
Container
Container
Table 16 Association of the artifacts with Graphical type.
Algorithm 21 invokes the algorithm to calculate the size of every entry point.
CHOREOGRAPHELEMENTMETHODS ( , , )
1 node
2 appe CALCULATESIZE ( ,ratio)
Algorithm 21 ChoreographElementMethods for s04.
Considering and , then invocations can be portrayed by the influence paths illustrated in Figure 26,
where the left side of the illustration regards entry point and the right addresses .
a01 lay01 c01
a01 lay02 c02
a01 lay02 c03
a01 lay02 c04
pls p01
pls p02
pls p03
Figure 26 Influence paths travelled.
Finally the specification of DISTRIBUTEELEMENTS is addressed to establish how the elements are transversally
influenced, after which the blueprint is ready to be built.
DISTRIBUTEELEMENTS ( )
1
2
3
4 node
5
6 I I , , )
60
7
8
9
10 node
11
Algorithm 22 DistributeElements for s04.
7.3 GRAPHICAL VIEWPOINT SECTION STRUCTURE
This section presents the guidelines to structure the Graphical Viewpoint section. The guidelines have as subjects
the main notions described in the previous sections. The content guidelines in Table 17 identify what
must/should be comprised or referenced in the viewpoint section, organized by subject.
Sub-section Content guidelines
Support Algorithms The section must include or reference all support algorithms it used.
Graphical Types The Graphical Types must be comprised or referenced.
Graphical
Orchestration
The section must comprise the specification of the graphical orchestration as well as
any related methods.
Graphical Sketch Optional. A graphical sketch of the desired output may be provided.
Table 17 Content guidelines for the Graphical Viewpoints.
61
Chapter 05
ACHIEVING AUTOMATION
8 ENTERPRISE ARCHITECTURE MANAGEMENT SYSTEM
The software solution Enterprise Architecture Management System (EAMS) is a real-world implementation of
this thesis subject. The solution was developed by the author as a collaborator of Link Consulting. Some of its
capabilities and functionalities go beyond the scope at hand and are the result of collaboration with other
colleagues and students. The descriptions here addressed concern only designs and implementations done solely
by the author.
8.1 INTRODUCTION
The solution comprises Rational System Architect (RSA), EAMS-BackOffice and EAMS-Viewer, and provides
set of functionalities based upon major actuation areas illustrated in Figure 27.
Figure 27 Enterprise Architecture Management System’s major areas.
62
Blueprint Management comprises any blueprint related capability such as Blueprint creation and filtering. Time
dimension is a transversal module responsible for any time related operations. Information Integration addresses
a part conceived to extend the import and export capabilities of the repository. Report Management regards the
capability to generate reports from a PowerPoint templates and populate them with repository information either
textual or blueprints. The two latter are not covered by the scope of the thesis and are therefore not subject to
further study in the following sections.
EAMS BackOffice is a Windows Forms Application developed in .Net Framework 3.5 and is the main controller
of the solution, having the responsibility of orchestrating the overall integration. Although in a macro perspective
one could view EAMS as already containing the repository, in reality the repository is provided by Rational
System Architect and is accessible through its API (See 3.2.1).
EAMS BackOffice uses RSA for its repository and drawing engine. The inter-process communication
mechanism is OLE Automation based on Component Object Model and enables content exchange with the
repository and access to System Architect‟s drawing engine. Due to the communication characteristics, both
EAMS-BackOffice and RSA run in the same computer. Further notes on repository integration are address in
8.2.
System Architect
EAMS-ViewerWorkstation
EAMS-BackOfficeWorkstation
EAMS-Viewer
Figure 28 EAMS Overview.
EAMS-Viewer is a WPF22
application that comes as an extension of the drawing capabilities of RSA and also to
enable remote access to the content via web-services thus allowing local and remote execution as illustrated in
Figure 28. However robust the SA drawing engine is, it was not designed to support dynamic representations and
therefore provides only limited potential for the Time dimension.
Table 18 describes the functionalities and matches them with the solution‟s components.
22 Windows Presentation Foundation: http://msdn.microsoft.com/en-us/library/ms754130%28v=VS.90%29.aspx
63
Functionality Description BackOffice Viewer
Create Blueprint Concerns the ability to automatically create a graphical
representation conforming to a viewpoint.
supported supported
Create Blueprints
in Batch mode
The capacity to automatically create a number of blueprints
taking into account one or more viewpoints. The number of
blueprints is determined by the number of referenced
viewpoints and the respective parameters.
For example instead of selecting the parameter in
scenario s04, one could provide a set of parameters and for
each of them a blueprint conforming to that viewpoint
would be created.
supported unsupported
Filter Blueprint Identify graphically specific content of a graphical
representation. Such relates to 6.3 and is addressed in 8.3.2
supported unsupported
Visualise Blueprint
Dynamically
The ability to create a blueprint in a drawing space where
the user interactions can dynamically alter the
representation.
Such relates to 5.2.4 and is addressed in 8.4.1.
unsupported supported
Time Restrictions The capacity to apply a constraint to the content of the
blueprints, based on the time parameters.
Such relates to 5.2.4 and is addressed in 8.4.1.
supported supported
Table 18 EAMS functionalities.
8.2 REPOSITORY INTEGRATION
The purpose of this section is to contextualize the main notions covered in 6 as well as identifying how the API
was adapted to support the graph oriented approach.
To cope with repository changes the approach uses the content metamodel and the correspondence mapping.
The correspondence mapping is implemented as an XML file with the same structure as defined in 6.1.1. When
the application is initialized the file is loaded and its content is used to build translation dictionaries. The idea is
the same; the dictionaries are keyed by the graph types and return the repository types.
The API object representing the repository is the Encyclopedia which references a Metamodel. The metamodel
object has a list of all the object types and has means of identifying the reference types. To dynamically identify
the viewpoint‟s metamodel one only needs to iterate through and and use each of their mappings to
retrieve the full data structure from the repository.
Having addressed the types the following step concerns the content retrieval. How does one go from the formal
description to obtaining the appropriate information to represent in the Blueprints? As covered in 6.2, to obtain
the addressed content a number of content selection conditions must be defined. Since a requirement is that the
specification is supported by the solution, then one must assure that all the selection conditions can be mimicked
64
and therefore through some choreography of the objects, methods and attributes of the API, one can construct an
interface to satisfy the approach‟s needs.
Although the API is rather extensive for the present scope only this partial view is required. Such methods and
attributes must suffice so that an implementation Repository of an interface IRepository could, through
choreography, provide the necessary means for an implementation of a viewpoint to specify the information
selection conditions programmatically. From Encyclopedia one can obtain the content by means of Definitions.
The base API methods regarding Encyclopedia are identified in Table 19 while for the methods and attributes for
Definitions are respectively addressed in Table 20 and Table 21.
Object Method Purpose
Encyclopedia GETALLDEFINITIONS Returns all the definitions in the encyclopedia.
Encyclopedia GETFILTEREDDEFINITIONS Returns a definition according to the name and type provided. The
name parameter is optional.
Table 19 System Architect Encyclopedia’s used methods and descriptions.
Object Method Purpose
Definition GETPROPERTY Returns the property value.
Definition GETRELATEDOBJECTS Returns related definitions according to a relationship type.
Table 20 System Architect Definition’s used methods and descriptions.
Object Attribute Purpose
Definition Name Name of the definition instance.
Definition SAType Type of the definition instance.
Table 21 System Architect Encyclopedia’s used attributes and descriptions.
So let a contractual interface IRepository have the methods described in Table 22.
Method Purpose
GETALLARTIFACTS Obtain the set of all artifacts.
GETALLRELATIONSHIPS Obtain the set of all relationships.
GETARTIFACTSBYTYPE Obtain the set of artifacts of a type.
GETARTIFACT Obtain a specific artifact.
GETRELATIONSHIPSBYTYPE Obtain the set of all relationships of a type.
GETRELATEDARTIFACT Obtain an adjacent artifact.
GETARTIFACTPROPERTY Obtain the value of an artifact property
Table 22 Methods for IRepository.
Considering , , the first thing to identify is how one can obtain the set of all artifacts and the set
of all relationships . Algorithm 23 expresses a way to identify for a parameter encyclopedia equal to .
The implementation is straightforward since a corresponding method is already provided by the API.
IRepository.GETALLARTIFACTS( )
1 return .GETALLDEFINITIONS( )
Algorithm 23 Algorithm to obtain all the repository’s artifacts.
65
Let a method GETRELATIONSHIPTYPES return a set of all the relationship types. The process to identify is more
complex since there are no available API methods that allow the direct retrieval of all the relationships.
Therefore, and as specified in Algorithm 24, one needs to loop through all the artifacts and then for each of them
cycle through all the types of relationships in order to obtain all the definition pairs that account to the
relationships.
IRepository.GETALLRELATIONSHIPS(encyclopedia)
1
2 I I
3 node I
4
5 node a
6 ,
7
Algorithm 24 Algorithm used for the retrieval of all the repository’s relationships.
Let a method GETARTIFACTTYPEMAPPING obtain an object type that matches an artifact type introduced as a
parameter. Let a method GETRELATIONSHIPTYPEMAPPING obtain a reference type that matches a relationship type
introduced as a parameter.
Revisiting 6.2, one can observe that the constraints are expressed with allusions to types and identifiers, hence to
provide means to retrieve a more restricted set of artifacts two algorithms are proposed. Algorithm 25 identifies
how a set of all artifacts of a given type can be found.
IRepository.GETARTIFACTSBYTYPE (encyclopedia, type)
1 I I
2 GETFILTEREDDEFINITIONS ( , )
Algorithm 25 GetArtifactsByType
For a more detailed selection and considering that RSA uses the property name as an object identifier, Algorithm
26 denotes how a specific artifact can be attained.
IRepository.GETARTIFACT (encyclopedia, name, type)
1 I I
2 GETFILTEREDDEFINITIONS (name, )
Algorithm 26 GetArtifact
Algorithm 27 describes the steps required to obtain the value of an artifact‟s property.
IRepository. GETARTIFACTPROPERTY(encyclopedia, , , )
1 I , ,
2
Algorithm 27 GetArtifactProperty
66
With the identification of types and artifacts completed the remainder of the section relates the selection of
relationships and adjacent artifacts. Algorithm 28 identifies how a set of all relationships of a given type can be
acquired, whereas Algorithm 29 describes the steps to identify an adjacent node restricted by the connecting
relationship type. The latter is much similar in principle to Algorithm 11 .
IRepository.GETRELATIONSHIPSBYTYPE (encyclopedia, type)
3
4 I I I
5 node I
6 node a
7 ,
8
Algorithm 28 GetRelationshipByType
IRepository.GETRELATEDARTIFACTS (encyclopedia, , , relationshipType)
9 I , ,
10 I I I
11
Algorithm 29 GetRelatedArtifacts
8.3 BLUEPRINT MANAGEMENT
As stated previously blueprint management addresses all concerns related to the blueprints. Thus far, the method
used to integrate EAMS with the repository has been covered, leaving the remaining viewpoint concepts to be
contextualized with the blueprint notion.
Creation of Blueprints regards the ability to create graphical representation of the information in the architectural
repository based on specification, without manual effort. So as previously described such specification is a
viewpoint, which identifies the content viewpoint and the graphical viewpoint. The viewpoint is implemented
programmatically as an implementation of an interface IViewpoint.
8.3.1 Blueprint configuration
EAMS BackOffice follows a plug-in architecture which through the use of Reflection23
allows the dynamic
creation of instances of IViewpoint from loaded assemblies. When the application starts it obtains the
correspondence mapping and the metamodel after which it will load DLLs24
that comprise implementations of
IViewpoint and that are bound to that repository. However, EAMS Viewer obtains the information of the
available blueprints by explicitly inquiring the BackOffice via web services about its available viewpoints.
There are two types of actions to perform on a blueprint, create the representation and filter the blueprint. These
actions are respectively related to the graphical representation of a or the identification of a . So let
23 http://msdn.microsoft.com/en-us/library/ms173183%28v=VS.90%29.aspx
24 Dynamic-link libraries: http://support.microsoft.com/kb/87934
67
IViewpoint have a method CREATE and a method FILTER where the first comprises the necessary step to create the
blueprint and the second contains the specification of the filters.
To exemplify a specification, is revisited and described in pseudo-code as the method
GETREPOSITORYADDRESSEDINFORMATION in Algorithm 30. Let = “a01”.
GETREPOSITORYADDRESSEDINFORMATION (encyclopedia, )
1
2
3
4
5
6
7
8
9 I , ,
10 I , , ,
11 I I
12
13 ,
14
15 I , , ,
16
17 ,
18
19
20 ,
Algorithm 30 GetRepositoryAddressedInformation
Considering and the related examples in previous chapters, Algorithm 31 comes into play as the
implementation of IViewpoint.CREATE.
IViewpoint.CREATE ( )
1 ,
2 GETREPOSITORYADDRESSEDINFORMATION(
3 AGGREGATEPROCEDURE01(
4 AGGREGATEPROCEDURE02(
5
6
7 GRAPHICALORCHESTRATION( )
Algorithm 31 Create
68
8.3.2 Extending the filters
Resuming the notion of filter presented in 6.3 this section presents how such idea is captured in EAMS. The
solution supports filters in a two-fold manner:
Pre-defined filters;
Run time definition.
The viewpoint can contain a number of filters and each is a public method of the interface IViewpoint. To apply
a filter on a blueprint the user selects the viewpoint followed by the parameters and the filter configurations; this
will result in the creation of a blueprint in which the content covered by the filters is highlighted.
The second method serves as a “sand box” for filter specification, where the user can specify filter through a
graphical interface illustrated in Figure 29. Such comes as an extension to the first approach, enabling user to
perform analysis that were not initially parameterized. The soundness of the specification is enforced by
mechanisms of the graphical interface that restrict the available options according to the constraint of the
concerning viewpoint, thus avoiding situations of excessive liberty, which could lead to ill-definition of filters,
rendering them with little or no value.
Figure 29 Graphical Interface used to define Filters.
Figure 29 illustrates an example that would then be interpreted as a filter with the following specification, where
the values are passed as parameters and :
(115). ,
(116).
(117).
69
To exemplify the use of filters Figure 30 depicts a blueprint that when subject to a filter can be depicted as
Figure 31.
Figure 30 Blueprint with no applied filter.
Figure 31 Blueprint with a filter applied.
8.4 TIME DIMENSION
Continuing the discourse of section 8.4.1 the focus returns to the time dimension and the idea of influencing the
representations of the enterprise according to temporal marks.
The solution comprises two functionalities regarding this matter:
Time restriction;
Dynamic visualization;
8.4.1 Time Restriction
Time restriction is a transversal constraint of the content of graphical representations. This is supported by the
graphical interface, illustrated in Figure 32, where the user can determine restriction mode and the associated
value, according to three options: No restriction; Single value restriction; Restriction by range.
Figure 32 Graphical interface that allows the specification of time related constraints.
70
Such can be traced back to in section 5.2.4 where:
(42) relates to time restrictions based on a single value.
(45) relates to time restriction base of a range o values.
Figure 33 illustrates a non restricted blueprint and Figure 34 displays the corresponding graphical representation
with restrictions applied, where the constrained representation has seven disappearing icons.
Figure 33 Blueprint without time restrictions.
Figure 34 Blueprint with time restrictions.
8.4.2 Dynamic Visualisation
EAMS-Viewer allows dynamic interactions with the graphical representations. From this ability a different
implementation of the time dimension was possible. Figure 35 illustrates a control panel that enables the run-
time alterations of the time restriction. When the blueprint is displayed in EAMS-Viewer, the solution identifies
the Minimum Date and the Maximum Date that account for the biggest and smallest values of the artifacts‟ time
related properties. The user is then able to alter the interval according to the time interval in which he wants to
visualize the representation. This interaction can be achieved by moving the bars of a slider or by directly
altering Begin Date and End Date.
Figure 35 Control panel for dynamic visualisation.
Figure 36 depicts a blueprint with Begin Date and End Date equal to the Minimum Date and Maximum Date,
where as Figure 37 illustrates the same blueprint with the slider set to a single date.
71
Figure 36 Blueprint with no time restrictions.
Figure 37 Blueprint restricted to a date.
72
9 CASES
This section describes the context in which EAMS was deployed or used in four organizations.
9.1 CASE 01: LINK CONSULTING - PORTUGAL
Link Consulting participated in various live presentations and demonstrations regarding EAMS, both in Portugal
and abroad. For these events a demonstration package was built with various viewpoints addressing mainly the
IT domain. Some of the live performances include events such as IBM Software Live, Innovation days 2009,
IBM Rational Day25
, etc.
For this project more than 15 viewpoints were specified (see Appendix C: Enterprise Blueprints Examples)
9.2 CASE 02: FINANCIAL GROUP I - PORTUGAL
This project used EAMS to aid in the construction and maintenance of an Application Catalogue and a Service
Catalogue. The first stage consisted in the use of Information Integration to collect data from information sources
scattered throughout the organization, into the architectural repository. The second project phase resorted to the
ability to create the enterprise blueprints. The representations where then used as a comprising part of several
reports.
For this project nine viewpoints where defined and used to create and maintain blueprints.
9.3 CASE 03: FINANCIAL GROUP II - BRAZIL
EAMS participated in two projects of this organization. The first regarding a generic proof-of-concept and a
second one regarding the support in the construction of an architecture intra-net site.
The proof of concept addressed only some customizations of the demonstration package referenced in [9.1].
In the second project, EAMS was used to maintain all the graphical representations required for an internal
architecture web site. This was a particularly interesting case. Although there were only 3 viewpoints involved
the number of outputs was considerable. This was the biggest performance endeavour the solution ever took part,
where in 24 hours using Batch Generation (see 8.1) approximately 88000 blueprints were created, each with an
average of more than 30 artifacts.
9.4 CASE 04: FINANCIAL GROUP III - BRAZIL
This case occurred in the context of Basel II26
to endow the organization with the ability to produce the graphical
representations to comprise in reports related to Basel II Pillar 3 Reports.
In this case the author did not participate in the specification of the viewpoints.
25 www-05.ibm.com/pt/ibmforum/apresentacoes/Enterprise_Architecture_Management_System_IBM_Rational_Day.pdf
26 http://www.bis.org/list/bcbs/tid_22/index.htm
73
Chapter 06
CLOSING STATEMENTS
10 CONCLUSIONS
10.1 SUMMARY
The first steps of this thesis concern the research of architectural descriptions and the study of the contributions
made in the last decades regarding the concept of view, viewpoints and concerns. Such provided an initial
overview on what was being done to guide the construction of graphical representations that conveyed value for
the targeted audience.
With such initial research we moved to the issue of automated creation. A representation is considered well
defined if it is unambiguously interpreted by the audience, but the process of construction is deemed too costly.
So the vision shifted to the idea that if the specification of the representation is unambiguous it can be interpreted
by a machine, which can then produce the representations faster than any person. From this we set out to
identify some of the major issues that prevented the use of today‟s viewpoints from automated interpretations.
Such lead us to more mature disciplines.
From the ontological system definition we set path to establish the conditions for an enterprise to be modelled as
a graph, and from this mathematical model we developed an approach that merged the practices in software and
enterprise architecture with the use of formal model. With such, the thesis devised an approach based on the
separation of concerns to propose two viewpoint parts: content viewpoint; graphical viewpoint. Such directed to
an establishment of concepts, principles and a series of steps to endow the specification of the viewpoint with the
required characteristics that would allow the transition to the automated creation, thus addressing the first
objective:
(1) Establish the means to specify enterprise blueprints by proposing principles to comprise in the
conforming viewpoints;
The work then proceeded to the second stage: the implementation of a software solution capable of creating such
blueprints. This stage started with a research of related applications and EA tools to establish the technological
principals. Having established the architecture repository technology, the work evolved in the same steps as the
74
viewpoint parts: first establish means to obtain the content of the representations; followed by the
implementation that would convey the processes inherent to graphical viewpoints. Thus addressing:
(2) Develop a software solution that automates the creation of enterprise blueprints;
The software solution is currently successfully deployed in two major financial groups. EAMS was used in
another architecture initiative in a third financial group and was also the subject of several public presentations
and live demonstrations to various audiences, on a national and international level. The overall appreciation has
been quite positive. The major advantages recognized by these audiences have been: the reduced effort in
creating the enterprise blueprints; the ability to enforce restrictions and maintain consistency and coherence; the
potential of the time dimension feature. All of which leads to the final objective:
(3) Validate the need for the thesis‟s approach and its ability to aid organizations in the resolution of
real life problems.
10.2 LESSONS LEARNED
This section comprises the identification of the most relevant lessons:
The approach is dependent from the quality of the information - As denoted on an early stage of the work, the
enterprise is perceived through the information maintained by the repository. If the repository does not reflect the
reality, neither will the blueprints, and therefore rendering all other efforts useless.
A formal approach is crucial to the definition process - The use of informal specifications leaves room for:
multiple interpretations; lack of rigour; inability to verify the specifications. A formal approach provides the
architect the ability to use verification in their work as means of reasoning and enriching his specifications. Even
if the stakeholders cannot initially provide a clear description of the requirements (concerns, constraints), an
architect equipped with the right instruments (well-established model, rules.) can analyse the requests and in a
more expedite manner identify any sources of ambiguity or incoherence and therefore re-establish conversation
with the client audience to set aside any doubts.
The use of pseudo-code is useful but requires additional information - The use of pseudo-code has long been an
instrument of reasoning however it is limited to some extent. The specification of the drawing conventions was
greatly supported by pseudo-code descriptions but when the conventions become too intricate the architect will
sooner or later start to struggle with the specification. Complex layout algorithms require to some extent the
company of graphical sketches. Such statement might be interpreted as a step-backwards, but it is exactly the
contrary. What was learned from experience is that easiest way to define the conventions is to start from a sketch
and then begin the breaking the depiction into smaller parts through refinement iterations, thus gradually
constructing the specifications in pseudo-code.
Standard languages have little concern for graphical conventions - Indeed there are a number of languages with
great value and pervasiveness. The languages rely mostly of the syntactic interpretation of the representation,
the interpretation of the icons. However there are a number of implications regarding how these elements are
spread throughout the representation. This is not a novel problem, many have pointed out modelling principles
75
and notions, yet the only contributions rely on qualitative (e.g. Gestalt principles) instead of quantitative
attributes. As long as two people can draw different graphical representations that conform to the same
specification, the automation of such specification will still be faced with assumptions and not well-structured
rules.
The usage of relationship categories is not without its downfalls - Even though the categorization of the
relationships simplifies the explanation of the model and has the same principles as the ones used by the
architectural repository, it abstracts from the reality of system theory. This implies the following: if the
relationships between the objects aren‟t objects there is no easy way to truly reflect the state of existence of a an
association between two objects, therefore the work done regarding time dimensions is still subject to
considerable improvements.
76
11 REFERENCES
[1] Apostel, L., “Towards a formal study of models in the non-formal sciences”, Synthese, vol. 12, no.
2-3, pp. 125--161, (1960)
[2] Boar, B.H., “Constructing Blueprints for Enterprise IT Architectures”, Willey Computer
Publishing, USA (1998)
[3] Boar, B.H., “A Blueprint for Solving Problems in Your IT Architecture”, IT Professional , vol. 1,
no. 6, pp. 23--29, IEEE Computer Society, USA (1999)
[4] Bollobás, B. “Modern Graph Theory”, Graduate Texts in Mathematics, vol. 184, Springer, USA
(1998)
[5] Boucké, N., Weyns, D., Hilliard R., Holvoet, T., Helleboogh, A., “Characterizing Relations
between Architectural Views”, Proceedings of the 2nd European conference on Software
Architecture, Lecture Notes In Computer Science, vol. 5292 , pp 66--81,Springer , Germany
(2008).
[6] Bunge, M., “Treatise on Basic Philosophy: Ontology II: A World of Systems”, vol. 4, Reidel, USA
(1979).
[7] Butler, Blowers, M., “System Architect 10.7”, Technical Audit TA001269IMT, Butler Group,
USA (2007).
[8] Callo, T., Avgeriou, P., America, P., “Documenting a Catalog of Viewpoints to Describe the
Execution Architecture of a Large Software-Intensive System for the ISO/IEC 42010 Standard”,
[http://www.esi.nl/projects/darwin/publications/2010_37_r11_Callo_Documenting_Viewpoints_ISI_IEC_42010.p
df], (2009)
[9] Clements, P., “Documenting Software Architectures, Views and Beyond”, Addison-Wesley, USA
(2002).
[10] Cormen, T.H, Leiserson, C.E, Rivest, R.L., Stein, C., “Introduction to Algorithms” The MIT Press,
USA (2001)
[11] Devlin, K., “The Joy of Sets: Fundamentals of Contemporary Set Theory”, Springer, USA (1993)
[12] Dietz, J.G.L., “Enterprise Ontology: Theory and Methodology”, Springer, Germany (2006).
[13] Dietz, J.G.L., “Architecture: Building strategy into design”, Academic Service, Netherlands
(2008).
[14] Dijkman, R.M, Quartel, D.A.C, Pires, L.F., Sinderen, M.J., “An Approach to Relate Viewpoints
and Modeling Languages”, Proceeding of the Seventh IEEE International Conference on
Enterprise Distributed Object Computing, pp 14--27, IEEE Computer Society, Australia, (2003)
[15] Emery, D., Hilliard, R., “Updating IEEE 1471: architecture frameworks and other topics”,
Seventh Working IEEE/IFIP Conference on Software Architecture, pp 303--306, IEEE Computer
Society, USA (2008)
[16] Forrester, Peyret, H., “Enterprise Architecture Tools, Q2 2007”, Forrester, USA (2007).
[17] Gartner, James, G. A., “Magic Quadrant for Enterprise Architecture Tools”, Gartner RAS Core
Research Note G00156427, (2008)
[18] Gartner, Handler, R. A., Wilson, C., “Magic Quadrant for Enterprise Architecture Tools”, Gartner
RAS Core Research Note G00172491, (2009).
[19] Herrera, S.I., Pallioto, D., Tkachuk, G., Luna, P.A., “Ontological Modelling of Information
77
Systems from Bunge’s Contributions”, Proceedings for the 17th International Conference on
Advanced Information Systems Engineering, vol. 2, pp 571--581, FEUP Porto, Portugal (2005).
[20] Hilliard, R., “Viewpoint modeling”, Proceedings for the 1st ICSE Workshop on Describing
Software Architecture with UML, (2001).
[21] Hofmeister, C., Nord, R. L., Soni D., “Describing Software Architecture with UML”, Proceedings
of the First Working IFIP Conference on Software Architecture, IFIP Conference Proceedings,
vol. 140, pp. 145--160, Kluwer, Netherlands (1999).
[22] Hoogervorst, J.A.P., “Enterprise Governance and Enterprise Engineering”, Springer-Verlag,
Netherlands (2009).
[23] IBM Corp., “IBM Rational System Architect VBA Extensibility Guide Release 11.3.1”,
[http://publib.boulder.ibm.com/infocenter/rsdp/v1r0m0/topic/com.ibm.help.download.sa.doc/pdf1131/Extensibilit
y_VBA.pdf], (2009)
[24] IEEE Computer Society, “IEEE Std. 1471-2000: IEEE Recommended Practice for Architecture
Description of Software-Intensive Systems”, IEEE, USA (2000).
[25] Schekkerman, J., “Enterprise Architecture Tool Selection Guide v5.0”, Institute for Enterprise
Architecture Developments, [http://www.enterprise-architecture.info/Images/EA%20Tools/Enterprise%20
Architecture%20Tool%20Selection%20Guide%20v50.pdf], (2009)
[26] Kaufmann, M., Wagner, D., “Drawing Graphs: Methods and Models”, Lecture notes in computer
science, vol. 2025, Springer, Germany (2001).
[27] Kennaley, M., “The 3+1 Views of Architecture (in 3D)”, Proceedings of the Seventh Working
IEEE/IFIP Conference on Software Architecture, pp. 299--302, IEEE Computer Society, USA
(2008).
[28] Kruchten, P., “The 4+1 View Model of Architecture”, IEEE Software, vol. 12, no. 6, pp. 42--50,
IEEE Computer Society, USA (1995).
[29] Kruchten, P., Cappila, R., Dueñas, J. C., “The Decision View’s Role in Software Architecture
Practice”, IEEE Software, vol. 26, no. 2, pp. 36--42, IEEE Computer Society Press, USA (2009)
[30] Lagerstrom, R., “Analyzing System Maintainability Using Enterprise Architecture Models”,
Journal of Enterprise Architecture, vol. 3, no. 4, pp. 33--41, USA (2007).
[31] Lankhorst, M., et al., “Enterprise Architecture at Work: Modeling, Communication and Analysis”,
Springer, Germany (2005).
[32] Liu, N., Zheng, D., Gao, F., Xiong, Y., “Research on the Application of UML in Software
Architecture Modeling”, Proceedings of the 2008 10th IEEE International Conference on High
Performance Computing and Communications, pp. 762--766, IEEE Computer Society Press, USA
(2008)
[33] May, N., “A Survey of Software Architecture Viewpoint Models”, Proceedings of the Sixth
Australasian Workshop on Software and System Architectures, pp. 13--24, RMIT University,
Australia (2004).
[34] Odevci, B., “An Enterprise Abstraction Approach: Viewing Enterprise Architecture Through
Natural Language Constructs” ,Journal of Enterprise Architecture, vol. 6, n. 1, pp. 24--30,
Association of Enterprise Architects, USA (2010).
[35] Op't Land, M., Proper, E., Waage, M., Cloo, J., Steghuis, C., “Enterprise Architecture: Creating
Value by Informed Governance”, Springer-Verlag, Germany (2009).
[36] Romero, J.R., Vallecillo, A., “Well-formed Rules for Viewpoint Correspondences Specification”
Proceedings of the 2008 12th Enterprise Distributed Object Computing Conference Workshops,
78
pp. 441--443, IEEE Computer Society, USA (2008)
[37] Russel, S.J, Norvig, P, “Artificial Intelligence: A Modern Approach”, Prentice Hall, USA (2002)
[38] Sousa, P., Lima, J., Sampaio, A., Pereira, C., “An Approach for Creating and Managing
Enterprise Blueprints: A case for IT Blueprints”, The 21st International Conference on Advanced
Information Systems, Lecture Notes in Business Information Processing, vol. 34, pp. 70--84
,Springer, Germany (2009).
[39] Tu, Q., Godfrey, M.W, “The build-time software architecture view”, Proceedings of the IEEE
International Conference on Software Maintenance, pp. 398--407, IEEE Computer Society, USA
(2001).
[40] Vasconcelos, A., “Arquitecturas dos Sistemas de Informação: Representação e Avaliação”, DEI,
IST-UTL, Portugal (2007).
[41] Wilson, R.J., “Introduction to Graph Theory”, Addison Wesley, England (1996)
79
APPENDIX A: PSEUDO-CODE CONVENTIONS
The use of pseudo-code as long been accepted to enable the representation of algorithms to enable a more
capable interpretation by the targeted audience. Having established the use of graph and their formal
specification as first-grade citizens of the work, one must possess a way to express cumbersome specifications
and entangled mathematical formulas. The approach describes algorithms in pseudo-code most of it comprising
procedures of graphs, nodes and edges through the use of mathematical formulas, looping constructs and
assignments.
The pseudo-code conventions are as follows:
Indentation is significant. Indentation indicates block structure, used to delimit the scope of loops or
conditions, as, for example, in the language Python, and unlike languages such as Java, C#, etc.
The looping constructs while and for each, and the conditional constructs if, else have the same
interpretation as in C#. The looping construct for has the same interpretation as in Pascal.
Variables are local to given procedure.
Assignments are on the form , which assigns the value of to the variable . Multiple assignments
are transitive so, and is equivalent to .
Elements in Collections, lists or arrays, are accessed by specifying the name followed by the index in
square brackets.
Objects comprise a set of attributes or methods defined by their corresponding type. Methods have
capitalized names and are regarded as a set of procedural statements for achieving the desired result,
which can be applied to different types with different implementation through type polymorphism. A
method is accessed by specifying the name of the object followed by a dot, the name of the method and
an ordered sequence of parameters wrapped in parenthesis. An attribute is accessed using its name
followed by its object in square brackets.
The symbol ⊳ identifies that the remainder of the line is a comment.
80
APPENDIX B: RATIONAL SYSTEM ARCHITECT OBJECT
MODEL
Figure 38 Rational System Architect Object Model.
81
APPENDIX C: ENTERPRISE BLUEPRINTS EXAMPLES
Figure 39 Application Organic.
Support Inf rastructure
Risk & ComplianceInsight & Performance
Front Of ficeCore Banking
DevelopmentDatabase
Retail ProductCommercial Product
Private Wealth
ComplianceRisk Management
Analytics PlatformOperational Excellence
CRM & Marketing
Performance ManagementCustomer Ins ight
Basel II
Business Process Analytics
Business Activity Monitoring
Retail CustomersCommercial Customers
AML
ALM
Credit Risk
Market Information
Human Resources
Marketing
Business Architecture
Business and Resourse Planning
Channel Analytics
Customer Analytics
Call CenterClient Servicing
Mortgages
Credits
Deposits
Asset Management
Commercial Loans
Cash Management
Commercial Deposits
TivoliWorkflowWebsphere
System ArchitectSASProcess Execution
IBM MainframeERPEAI
Data WarehouseDashboardsBusiness Intelligence
BorlandVS Team SystemDOORS
TivoliSystem ArchitectSAS
Quality ManagementProject SuiteIBM Mainframe
ERPDocument ManagementData Warehouse
CMDBBMSApplication Catalogue
SAS
Business Intelligence
IBM MainframeReveleusAlgorithmics
ERPSASTivoli
MKSOpen ALM
RiskWinKamakuraSAS
WorkflowWebsphereEAI
Business IntelligenceBMSSystem Architect
EAIBusiness Intelligence
System ArchitectBMSWebsphere
Internal Knowledge
Sharer
BloombergReuters
ERP
MarketeerERP
BMSSystem Architect
Resource Availabil ity
Checker
IBM Business Planner
Call Center SolutionBusiness IntelligenceWebsphere
SAS
Altiris
Business IntelligenceCRMERP
Business IntelligenceCall Center SolutionERPCRM
Mortgage Today
Credit NowCredit Appliance v2
ERP
AltirisxAssetTivoli
Loan CheckerERP
AltirisERP
Commercial AnalyticsDeposit CheckerERP
82
Figure 40 Application Context.
Figure 41 Product Viewpoint.
Processes Informational Entities
Consumed Applications Provided Applications
Projects Application IT Platforms
8 Serv ice Order
Management Application
7 Channel Sales
Management Application
6 Product / Serv ice
Catalog Manager
5 Mass Market Sales
Management Application
4 Corporate Sales
Management
3 Channel Sales
Management Application
2 Campaign
Management Application
DB2WebSphere
SQL ServerJ2EE1 Customer Order
Management Application
Selling Complete Customer
Order
Order Handling
Determine Customer
Order Feasibility
Authorize Credit Receiv e PO & Issue
Orders
Track & Manage
Customer Order
Handling
Issue Customer Orders Close Customer Order
Customer Bill Customer Product Specif ication
Product Of f ering Product Customer Bill Inquiry
Customer Order Serv ice Serv ice Specif ication
Agrius
83
Figure 42 Component Integration
Figure 43 Application Structure.
Integrat ion Layer
Integrat ion Layer
B usiness Layer
D ata Layer
Presentat ion Layer
File Integrator
Adobe Flex
Mainframe File Manager.NET Framework 3.5 SP1
Part icipants
Balcony
TibcoFile IntegratorMainframe File Manager
.NET Framework 3.5 SP1IBM Mainframe
Orac le 10SQL Server 2005 SP2
DatawarehouseJ2EE
Corporate Database SystemBalcony
Integrat ion Layer
Event Manager.NET Framework 3.5 SP1
Tibco
Incident ManagementBalcony
Debt ManagementDashboards
Commerc ial Analy ticsUncompliance Management
AgendaOperational Data System
DashboardsDeposits
Externals
BalconyAgenda
Commerc ial Analy ticsIncident Management
Operational Data SystemDebt Management
Central Bank
BalconyOperational Data System
Operational Data SystemBalcony
Debt ManagementDepos its
BalconyOperational Data System
Debt ManagementDashboards
Commerc ial Analy ticsUncompliance Management
AgendaOperational Data System
Incident ManagementUncompliance Management
Operational Data SystemDebt Management
Risk CentralizerCentral Asset Quotes
TBC - Risk
Manager
TBC - Asset
Manager
CDS -
Repos itory
BCN - Database
INF - Incident
File Manager
BCN - Event
Handler
INF - Debt Fi le
Manager
INF - Business
Data Integrator
CLI - Client Fi le
Manager
INF -
Uncompliance
File Manager
INF - Agenda
Data
INF - Asset Fi le
Manager
CKP - Future
Assets
CKP -
Business Data
DPO - Interest
Rates Manager
DPO - Account
Balance
Manager
BCN -
Corporate
Client Data
Agregator
AGD - Agenda
Data
CLI - Risk AlertINF - Incident
Management
ODS Asset
Management
EFT - Debt
Manager
ODS Asset
Integrator
BCN - Event
Handler
BCN - Serv ice
Manager
TBC - Debt
Manager
EFT - Debt
Serv ices
TBC - Interests
Manager
TBC - Balance
Manager
TBC - Risk
Manager
ODS Asset
Serv ices
TBC - Asset
Manager
INF - Debt Fi le
Manager
INF - Future
Assets
Integrator
INF - Business
Data Integrator
CLI - Client Fi le
Manager
INF -
Uncompliance
File Manager
INF - Agenda
Data
INF - Asset Fi le
Manager
INF - Incident
File Manager
MFM - Inc ident
File Manager
MFM -
Uncompliance
File Manager
RES-RI
Uncompliance
File Manager
MFM - Asset
File Manager
ODS Asset Fi le
Manager
EFT - Debt
Integrator
MFM - Debt File
Manager
BCN - Client
Interface
Corporate Client
Manager
CommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentCommentComment
Customer Order Management Application
Business
Platforms
Integration
Repositories
Data
External Applications
1 Serv ice Order
Management Application
Customer DatabaseMarket / Sales Database
COMA -
Customer
Qualif icat ion -
DATA
COMA -
Channel
Guidance and
Data Capture -
DATA
COMA - Order
Validation - INT
COMA - Order
Management
Prov ider - INT
COMA - Order
Lyf ecycle
Management
COMA - Order
Tracking &
Management
COMA - Order
Distribution
COMA - Order
Orchestration
COMA - Order
Publication
COMA - Order
Validation
COMA -
Customer
Qualif icat ion
COMA - Order
Establishment
COMA - Order
Management
DB2
SQL Server
WebSphere
J2EE
84
Figure 44 Project Impact.
85
Figure 45 Application Context (EAMS-Viewer).
86
Figure 46 Application Structure (EAMS-Viewer).
