University of Ghent
Faculty of business and economics
Intermediate Report
The development of an optimal
visualisation for enterprise architecture
(ArchiMate)
Justine Paesschesoone
Table of contents
Problem definition and research question ......................................................................... 3
Methodology .................................................................................................................... 3
Read Literature ................................................................................................................. 4
Articles................................................................................................................................................................................... 4
Books ...................................................................................................................................................................................... 4
Part 1: Enterprise architecture defined .............................................................................. 5
1.1 The origin ...................................................................................................................................................................... 5
1.2 EA as a management tool ....................................................................................................................................... 6
Part 2: ArchiMate ............................................................................................................. 6
2.1 ArchiMate and Enterprise Architecture ........................................................................................................... 6
2.2 ArchiMate 1.0 .............................................................................................................................................................. 7
2.2.1 Layering .......................................................................................................................................................................... 7
2.2.2 Structure per layer ..................................................................................................................................................... 8
2.2.3 The framework ............................................................................................................................................................ 8
2.2.4 The relationships ........................................................................................................................................................ 8
2.3 ArchiMate 2.0 .............................................................................................................................................................. 9
2.3.1 ArchiMate and TOGAF .............................................................................................................................................. 9
2.3.2 Motivation extension................................................................................................................................................. 9
Part 3: Visualisation ........................................................................................................ 10
3.1 Principles for designing effective visual notations .................................................................................... 10
Literature, yet to read ..................................................................................................... 12
Tool ................................................................................................................................ 12
Time schedule (Gantt Chart) ........................................................................................... 13
Appendix ........................................................................................................................ 14
2
Problem definition and research question
There is an ever-growing interest in Enterprise Architecture (EA). A lot of enterprises
use it to have a good overview of the company, to align business with IT or even to
keep their processes aligned with their chosen strategy. Nevertheless, we notice that
small and medium-sized enterprises (SMEs) do not participate in this trend. Although
it could offer them many benefits, there is almost no SME that already has
implemented EA or even knows the concept.
SMEs often have limited IT knowledge and less opportunities to hire experts in
that matter. Therefore, the modelling languages, used to express the EA should be
made easier to read for people with limited IT skills.
In this thesis, I will explore the scope for enhancing the tool support of the
standard used method ArchiMate, to make it easier to read. A user-friendly enterprise
architecture language and tool is simply more likely to be adopted by small
enterprises. (Bernaert, Poels, Snoeck, De Backer, 2012)
In other words, there will be checked whether the new and easier visualisation of
ArchiMate will be an incentive to encourage SMEs to implement EA.
Methodology
I would like to split up my thesis into three different parts.
Part one should be my study of literature. This part also will be divided into three
sections. The first section will discuss the origin of enterprise architecture itself. The
second section focuses on ArchiMate 1.0 and 2.0, discusses the concepts, the
relationships, the extensions, ... The last section will be about visualisation.
In part two, I would like to discuss the visualisations I’ve developed. This part, I
would also like to divide into four different sections. Section one should include the
concepts of the business layer. Section two should contain the concepts of the
application layer. Section three would have the concepts of the technology layer. And
finally, I will discuss the visualisations of the relationships in section four.
In part three, I would like to analyse and discuss the tests that I would like to
make in two different companies. My intention is to start testing in a company where
EA is core business (like BIZZdesign), and then take a company that has
implemented ArchiMate for their Enterprise Architecture, but where it is not
considered as their core business (if possible, even perhaps a SME).
3
Read Literature
Articles
 Bernaert, M., Poels, G., Snoeck, M., & De Backer, M. (2012). Enterprise
Architecture for Small and Medium-sized enterprises: A starting point for
bringing EA to SMEs, based on adoption models.
 Dietz, J. L. G., Go, A., & Lee, C. (2007). Enterprise Architecture in de praktijk.
Via nova architectura: 1-9.
 Engelsman, W., Quartel, D., Jonkers, H., & van Sinderen, M. (2010).
Extending Enterprise Architecture modelling with business goals and
requirements.
 Henderson, J.C., Venkatraman, N. (1993). Strategic alignment: Leveraging
information technology for transforming organisations. IBM Systems Journal,
32.
 Henderson-Sellers B., Low G., & Gonzalez-Perez C. (2012). Semiotic
Considerations for the design of an Agent-Oriented Modelling Language.
Springer.
 Maes, R. (1999). A generic framework for information management.
 Moody, D. L. (2006). What makes a good diagram? Improving the cognitive
effectiveness of diagrams in IS development.
 Moody, D. L. (2009). The “physics” of notations: Towards a scientific basis for
constructing visual notations in software engineering. IEEE Trans Softw Eng,
35 (6): 756- 779.
 Session, R.(2007). A comparison of the Top four Enterprise Architecture
methodologies.
 The Open Group. (2012). ArchiMate 2.0 Specification.
https://www2.opengroup.org/ogsys/catalog/C118. Accessed February 2013.
Books
 Josey, A., et al. (2012). Archimate 2.0 A Pocket Guide. The Open Group.
 Lankhorst, M., et al. (2013). Enterprise architecture at work : modelling,
communication and analysis. Springer.
4
Part 1: Enterprise architecture defined
1.1 The origin
About 25 years ago, two main problems emerged in the business world. First, people
started implementing more and more information systems, because they were
necessary for the proper functioning of the business. After all, information, or ITsystems help supporting the business processes. However, this resulted in very
complex systems and automatically leads us to the second problem. IT and business
processes are strongly connected with each other, but due to the increasing
complexity, the alignment of both business and IT became a tough task. All this
resulted in ever increasing costs but decreased added value for the company itself
(Sessions R., 2007).
A clear approach for the alignment between business and IT, in short business-IT
alignment, had to be realised. Technical projects needed to be in better alignment
with what the business needed. Communication between IT and business had to be
optimised.
That is when information management was introduced. Henderson &
Venkatraman came up with their alignment model (Henderson & Venkatraman, 1993)
which linked business strategy, IT strategy, business processes and IT processes all
together. So both, the strategic and operational level were connected.
Later, this model was extended to the Amsterdam Information Management
Model (AIM), also known as The Nine Square framework. (Maes, 1999). An
information/communication-column and a structure-row were added to the original
model. This column and row represent the very concept of information management.
This additional information facilitates communication between the four subdomains of
the original model. A good information policy ensures the alignment between IT and
business for the entire company.
Now, where can we situate Enterprise Architecture? The middle row of the model
represents the development and implementation of business, information and IT
architecture. This is exactly what Enterprise Architecture stands for. It provides
business-IT alignment from a structural point of view.
As we live in an ever-changing world, companies need to respond to this to stay
ahead of competition. However, change in the IT field is not enough to be better than
the other. Also the total way of working has to change, which means that if something
5
changes in the IT field, this must be translated into the business processes. Only
total integration of business and IT ensures good replies to change (Dietz, Go, Lee,
2006). Enterprise Architecture is an ideal tool for this.
1.2 EA as a management tool
Enterprise architecture can also be seen from a more managerial point of view. Not
only the architecture itself, also the corporate culture of a company is important in
achieving the goals that are set to give direction in executing the strategy (Lankhorst
et al., 2013).
Crafting a strategy entails first having a good mission, which describes the
company’s purpose and present business. Next, a vision has to be developed. A
vision describes management’s aspirations for the future. Further, this can be
translated into a company’s strategy. This is then transformed into specific goals for
which different actions can be taken. These actions have an impact on the daily
operations of the company and that’s were enterprise architecture delivers real value.
EA namely aims at making the chosen strategy useful for operations by means of
design principles (Dietz, 2006).
Part 2: ArchiMate
2.1 ArchiMate and Enterprise Architecture
“The role of the ArchiMate standard is to provide a graphical language for the
representation of enterprise architectures over time.” (Josey A. et al., 2012)
Organisations that are into Enterprise Architecture and want to communicate
about it, need a language to express their Enterprise Architecture. And that’s what
ArchiMate is all about. You need a modelling language to express your EA.
ArchiMate is used for communicating with different stakeholders, from their goals to
their implementation scenarios. It offers an integrated architectural perspective that
visualises the different domains of an organisation and their interrelationships.
Most of the already existing modelling languages have been developed to model
specific subdomains such as business process design and software development. In
process modelling, many different languages are in use, such as BPMN, ARIS,…
They find widespread use and are quite easy to understand. For software modelling,
on the other hand, there is only one dominant language, UML. The Unified Modelling
6
Language (UML) is rather a complex language and is more difficult to understand for
people who are not familiar with it.
All these modelling languages focus on a separate domain of the overall
enterprise architecture of an enterprise. However, to obtain a better alignment
between IT and business, there is the need for a modelling language that brings
together all these different subdomains. That is why ArchiMate was designed. Since
2008, ArchiMate is supported as an open standard and administered by The Open
Group.
2.2 ArchiMate 1.0
2.2.1 Layering
The ArchiMate language consists of three layers. At an abstract level, each layer has
the same general structure. This means that the same types of concepts and
relationships are used, but they differ in character and level of detail. More concrete
concepts are defined, specific for a certain level. As a result, it is possible to better
synchronise the different layers with each other. The Open Group defines the
different layers as followed (The Open Group standard, 2012):
1. The business layer: This layer offers products and services to external
customers, which are realised in the organisation by business processes
performed by business actors or roles.
2. The application layer: This layer supports the business layer with application
services, which are realised by (software) application components.
3. The technology layer: This layer offers infrastructural services needed to run
applications, realised by computer and communication devices and system
software.
The three layers are mainly linked with each other by the service concept. This
concept is very important for the enterprise modelling language. “A service is defined
as a unit of functionality that some entity (e.g., a system, organisation, or department)
makes available to its environment, and which has some value for certain entities in
the environment.” (Lankhorst, 2013) Services can be delivered by the entire
enterprise to a particular customer but also a specific software application can
7
provide a service to a business process. This is what creates the various layers of
the language. A higher layer makes use of the services of lower layers.
Consequently, the services of higher layers are realised in the lower layers.
2.2.2 Structure per layer
Each layer has the same general structure and consists of three types of elements.
The following types of elements can be identified: Active structure elements,
behaviour elements and passive structure elements.
An active structure element is defined as an entity that possesses the ability to
carry out behaviour. These elements show who or what exercises the performed
behaviour (the subjects of activity). A behaviour element specifies the type of activity
that is performed by one or more active structure elements. Eventually, a passive
structure element is the object on which the behaviour is performed. It contains
information that is necessary for carrying out certain behaviour. Most passive
structure elements are data objects, but they may also be physical objects.
All three elements together are derived from natural language. A sentence also
includes a subject (active element), a verb (behaviour) and an object (passive
element). This connection improves the ease of use of the ArchiMate modelling
language.
2.2.3 The framework
When we combine the three layers and three different types of elements from the two
previous sections, we obtain one overall framework. This framework consists of nine
cells and is kept together by the service concept, as already mentioned before.
An important insight is that every possible representation of an enterprise
architecture can be framed in this overall framework, but not all representations will
cover all nine cells. However, each representation will include more than one cell.
2.2.4 The relationships
The foregoing three layers, and the various concepts among each other are
connected via relationships. These relationships are the centre of the business-IT
alignment because they match the different layers (Open Group Standard, 2012).
Three different kinds of relationships can be distinguished: Structural relationships
(used to define structural coherence between entities), dynamic relationships (used
8
to define coherence between behavioural entities) and all other relationships that do
not belong to the two above types.
2.3 ArchiMate 2.0
2.3.1 ArchiMate and TOGAF
As TOGAF, The Open Group Architecture Framework, is a framework and
methodology for developing enterprise architecture, ArchiMate is the language or
graphical representation in which the architecture description has to be encoded. The
objective of The Open Group is to continuously evaluate TOGAF and ArchiMate so
that they complement each other even more.
The core of TOGAF is a stepwise cycle approach for the development of
enterprise architecture, called ADM (the Architecture Development Method). ADM is
an iterative process and consists of several phases. The structure of the ArchiMate
1.0 language highly corresponds with three architectural domains (phases) of
TOGAF’s Architecture Development Method (ADM).
Only the Business Architecture, Information Systems Architectures and
Technology Architecture phases are supported by ArchiMate 1.0. To provide support
for the other phases, two extensions were added. The first extension concerns the
Motivation extension. This extension includes the Preliminary, Architecture Vision,
Requirements Management and Architecture Change Management phases. The
second extension concerns the Implementation and Migration extension. This
extension includes all remaining phases: the Implementation Governance, Migration
Planning and Opportunities and Solutions phases.
2.3.2 Motivation extension
Many modelling languages concentrate on what the enterprise should do, instead of
paying attention to the underlying motivation behind it (Engelsman, Quartel, Jonkers
& van Sinderen, 2010). This is also the case with ArchiMate 1.0. It does not take into
account the rationale behind the architecture, regarding goals and requirements.
TOGAF however, has a Requirements management phase, which plays a central
role in its architecture development method (ADM). During each stage of the ADM, it
is checked whether there is compliance with the ambitions of the stakeholders (their
requirements).
9
Part 3: Visualisation
3.1 Principles for designing effective visual notations
In many notations, a lot of attention is spent on selecting certain concepts, what they
mean and their interrelationships. The development of the notation of these concepts
(visual syntax), is usually pushed to the background. Researchers consider visual
notations to be informal, or even unimportant. Therefore, they see the visualisation of
their concepts as something that provides aesthetic instead of more effectiveness.
The design of the concepts is purely based on instincts, repetitions, common sense
and is defined without any reference to theory or empirical evidence (Moody, 2009).
This practice is called an unselfconscious design culture and should be turned
into a selfconscious design culture where designers are able to explain their design
on the basis of explicit design principles (Moody, 2009). Without these principles,
designers miss out on the infinite possibilities that the design space offers. Moody
(2009) compiled a list of nine principles to achieve cognitively effective notations. A
selection was made of the six most relevant:
1. The principle of Semiotic Clarity: A symbol may only be assigned to one
specific concept. There must be no more than one concept linked with a symbol and
vice-versa. When there is no 1:1 correspondence, four types of irregularities can
occur: Symbol redundancy (happens when multiple symbols may be used for the
same concept), symbol overload (happens when multiple concepts are linked with
one and the same symbol), symbol excess (happens when there exists a symbol that
isn’t linked to any concept at all) and symbol deficit (happens when there is a concept
that has no symbolic representation).
2. The principle of Perceptual Discriminability: This principle relates to the
difference between various symbols. The more different the symbols are, the easier it
is to interpret and recognise them. The more visual variables (shape, size, colour,…)
used, the better.
3. The principle of Semantic Transparency: The use of symbols whose
meaning is intuitively easy to guess only by looking at it, facilitate readability. The
extent to which certain symbols are transparent, can be plotted on a continuum with
on the one side Semantic Immediacy, on the other side Semantic Perversity and
Semantic Opacity in the middle. Semantic immediacy implies that a novice reader
can deduce the meaning of the symbol by its appearing only. Semantic opacity is
10
when the design of the symbol was purely arbitrarily. A symbol is semantically
perverse when a novice reader assigns the wrong meaning to the symbol after
having seen the symbol.
4. The principle of Visual Expressiveness: The amount of visual variables
used, should not only be maximised between symbols mutually, it should also be like
that across the entire visual vocabulary.
5. The principle of Dual Coding: Adding text to your design can be useful to
reinforce the meaning of the symbol. It’s not the purpose to make text a key
component of the symbol, but only to use it as a supplement.
6. The principle of Graphic Economy: The human brain has certain limits, also
in terms of the number of symbols that can be recognised effectively. A diagram
should contain around seven, plus or minus two, elements to be the most effective.
For specialised readers this seems very few, however, for novice readers, this may
already be a lot (Moody, 2006). There are three ways to keep the number of symbols
manageable. First, by simplifying the semantics of a notation itself, concepts can be
deleted for which symbolisation is then no longer needed. A second method is to
deliberately choose not to display certain concepts graphically. The third approach
does not deal with the reduction of the symbols, but helps increasing the human
discrimination ability to manage the complexity. This can be done by using multiple
visual variables.
Principles 4 and 5 of the paper are considered irrelevant because they relate to
diagrams, whereas this thesis deals with the notation of symbols on itself. Principle 9
has also been excluded because it is beyond the scope of this thesis to further
develop
different
dialects
for
the
language.
11
Literature, yet to read
In the first section of my study of literature I would like to add a piece about the
motivations to implement Enterprise Architecture. Therefore, I would like to read the
following book:
 Op’t Land, M., Proper, E., Waage, M., Cloo, J., & Steghuis, C. (2009). Enterprise
Architecture: Creating Value by Informed Governance. Springer.
For the second section, I need some more information about the viewpoint
orientation of ArchiMate and about the extensions of ArchiMate 2.0. That is why I still
want to read:
 Engelsman, W., Quartel, D., & Jonkers, H. (2010). Supporting requirements
management in Togaf and ArchiMate. The Open Group.
 Jonkers, H., van den Berg, H., Iacob, M-E., Quartel, D. (2010). ArchiMate
extension for modelling the TOGAF implementation and migration phases. The Open
Group.
Section three still needs serious attention. I’m planning to read:
 Bertin, J. (1983). Semiology of graphics: Diagrams, networks, maps.
 Gonzalez-Perez, C., Henderson-Sellers, B. (2008). Metamodelling for software
engineering.
 Moody, D.L., van Hillegersberg, J. (2008). Evaluating the visual syntax of UML: an
analysis of the cognitive effectiveness of the UML Family of Diagrams.
 Padgham, L., Winikoff, M., Deloach, S., & Cossentino, M. (2009). A Unified
graphical notation for AOSE. LNCS, vol. 5386.
 Rumbaugh, J. (1996). Notation notes: principles for choosing notation. Journal of
object oriented programming 9(2).
 Ware, C. (2008). Visual thinking for design.
Tool
While reading through the literature, I noticed that it is really necessary to create a
new tool for ArchiMate. Currently, ArchiMate has too many concepts with too many
different graphical symbols as a result. This is against the principle of Moody (2009),
saying that the number of symbols must remain manageable. I will therefore try to
distinguish families or groups of concepts that are highly related to each other, so I
can also link them visually with each other and have less different symbols.
12
Secondly, the three different colours, now used to differentiate between the
passive, behavioural and active concepts, are used incorrectly. Colour should be
used in a way that when the symbols are printed out in black and white, there still is a
distinction. If we now see the meta-model in black and white, no distinction can be
made between the application service and the business service. This could be
resolved by using another variable to distinguish between the different layers of
ArchiMate. If, for instance, we use different textures for the application layer and the
business layer, then this would resolve the previous problem and the variable colour
would be used on a redundant way (as it should be).
I also noticed that the symbols for data/business objects and contract are exactly
the same, although they both have a total different meaning. This is a violation
against the principle of semiotic clarity of Moody (2009). There is no 1:1
correspondence, multiple concepts are linked with one and the same symbol, so
there is symbol overload.
Time schedule (Gantt Chart)
The time schedule in the appendix shows the year 2013 from week 0 until week 52.
From week 53 on, we are in the year 2014 (week 74 represents the end of May
2014). I would like to have finished my study of literature (part one of the thesis) by
the start of the academic year 2013-2014, so that I can start immediately focusing on
the tool development and the testing of it. Around the middle of February, I would like
to set up the main structure of part two and three of the thesis. Then, I have about 10
weeks left to start writing, reading, rewriting and finishing these two parts. However,
this is a rough estimate.
13
Appendix
14