GHENT UNIVERSITY
FACULTY OF ECONOMICS AND BUSINESS
ADMINISTRATION
ACADEMIC YEAR 2013 – 2014
THE DEVELOPMENT OF A DOMAIN
ONTOLOGY FOR ENTERPRISE
ARCHITECTURE
Intermediate Report Friday, May 10, 2013
Thesis presented to obtain the degree of
Master of Science in Applied Economics, Business Engineer
Sarah Carron
Under the supervision of
Prof. dr. Geert Poels & Maxime Bernaert
1
Content Page – Intermediate Report Tuesday, February
9, 2016
1. Problem statement and positioning
2.1. Problem positioning
2.2. Problem Statement
2.3. How will this thesis contribute to a solution
2.4. Research questions to be answered
2. Methodology
3.1. Creating a list of frameworks
3.2. Choosing the selection criteria
3.3. Making the ontology
3.4. Validating the ontology
3. Progress so far
4. Timeline for further progress
5. List of literature
6. Appendices: List of EA Frameworks
2
1. Problem statement and positioning
1.1. Problem positioning
The first step of this research was an attempt to understand what the title
of this thesis meant. Seeing that the subject of Enterprise Architecture
was new to me, some primary research was necessary.
Here I will
explain the meaning of my title and the problem it will try to solve. The title
goes as follows:
Developing a-domain ontology 1 for Enterprise Architecture 2.
1
When talking about a domain ontology one tries to reference to an
abstraction of reality in a certain domain while defining entities and
relationships between those entities. The ontology can be used as a
common language when working in that domain or to map a certain
appearance in that reality. The domain concerning my thesis is Enterprise
Architecture (EA).
2
EA is a tool to support strategy implementation in an organization. It
helps to highlight the necessary steps or processes an organization
should go trough to realize its future wanted state (TO BE vs. AS IS). A
few sources also see it as a tool that supports change in an organization
(Greefhorst, D., Koning, H., & Vliet, H., 2006) and a way to align business
with IT.
1.2. Problem statement
One of the biggest problems in Enterprise Architecture is the fact that
there are too many different architecture frameworks being built and used.
Even more, within these frameworks there is no common ground. The
same definitions are used for different terms and the same terms are
being used in different ways making communication between two different
frameworks very complicated (Greefhorst, D., Koning, H., & Vliet, H.,
2006). The reason for this chaos can be accounted to the fact that EA is
3
still a pretty young discipline compared to others where unity has come
over time (Chen, D., Doumeingts, G., & Vernadat, F., 2008).
1.3. How will this thesis contribute to a solution?
The domain-ontology being built should contribute to a solution for this
problem of alignment. First of all it can be used as a common ground
between different frameworks, making communication easier. Second
seeing that an ontology is constructed with a high level of abstraction it
can easily be used as a means of communication between different
stakeholders in the enterprise (Chen, D., Doumeingts, G., & Vernadat, F.,
2008). Third it should also facilitate the analysis of architectures across
different fields and the reuse of analytic results (M. Lankhorst et al.,
2013).
1.4. Research questions to be answered
In the process of getting to this domain ontology a few research
&
methodology questions come to mind:
1. Why would a domain-ontology be useful?
2. What is a domain-ontology?
3. What is the difference between an Upper-ontology (e.g. IDEAS?)
and a Domain-ontology (e.g. CARP)?
4. Which Architecture Frameworks should we incorporate in this
ontology? What selection criteria do we use?
5. Do we create a new framework for it or do we base the domain
ontology on an existing one? (Dimitri, R., Jan, V., Bernaert, M., &
Poels, G., 2012-2013)
6. If we choose an existing one, which one? CARP?
7. Seeing that there is no common ground, what definitions will be
used for this ontology? (Chen, D., Doumeingts, G., & Vernadat, F.,
2008)
8.
How to model this ontology? (Table seems like the best solution.)
9. How to validate the final ontology? Use case? Practice?
4
2. Methodology
2.1. Creating a list of frameworks to incorporate
The first step of the process is to create a list of EA frameworks including
as many frameworks as possible. After completion it will be necessary to
select those frameworks, which can be incorporated into the domainontology.
After reading some articles on EA I found that there were 2 basic kinds of
frameworks: Methods and models. Methods are descriptions of the
process one needs to follow to get to a certain architecture, a road map
so to say. Examples are SEAM, GEAM, Nolan-Norton, etc. Within the
“Models” category one can still distinguish 2 different sub kinds. The first
kind is the one where entities get divided into categories, most of the time
the division is based on different viewpoints. This is called viewpoint
modeling. The most well known framework in this category is of course
Zachman.
Other
examples
model, DoDAF and, RM-ODP
are:
("Viewpoint
Kruchten's "4+1"
view
Modeling." Wikipedia.
Wikimedia Foundation, 03 Oct. 2013.). In the second kind the
relationships between those entities are defined as well. Hereafter I will
refer to these models as meta-models. Examples of meta-models are:
TOGAF, CHOOSE and CARP. This classification can be used as a
selection criterion for the domain-ontology.
2.2. Choosing the selection criteria
A first step will be to exclude all methods. Due to the fact that these are
not abstractions of reality but a road map to success, they cannot be used
in an ontology. This leaves us with a list of models to deal with. Now we
have to consider the relevance of each one. To do this we can use
several criteria: (1) We can choose the ones most used in practice or (2)
use the ones most referenced to in literature (3) use the ones used as a
benchmark (4) Keep only the ones with a meta-model. The information of
the first and third criteria can be found researching surveys on EA. The
5
second criteria can be found by analyzing references in literature. The
selection choice still needs to be made.
2.3. Making the ontology
Once we have the final list of frameworks, we can start building the
ontology. The first step is to get to know all the frameworks that will be
incorporated into more detail. Reading literature or manuals about these
frameworks will be necessary. The goal is to find overlapping concepts in
different frameworks. Roose, D. & Van Steenlandt, J. (2013) have already
mentioned
some
overlapping
concepts
trough
comparing
some
frameworks to the Zachman framework. You can see their findings in the
table below.
Table 1: Roose, D. and Steenlandt, J. (2013)
A second table that could be used as a basis for this research is the one
from Bernaert, M., Poels, G., Snoeck, M., & De Backer, M. (2013) shown
here:
Table 2: Bernaert, M., Poels, G., Snoeck, M., & De Backer, M. (2013). CHOOSE: Towards a
Metamodel for Enterprise Architecture in Small and Medium-Sized Enterprises. (Table 1, pg 25)
6
A third source comparing frameworks by views/perspectives, abstractions
and SDLC Phases is: Urbaczewski, L., & Mrdalj, S. (2006).
All of these sources and more can be used as a starting point for the final
ontology.
2.4. Validating the ontology
My first thought for validation was to let different people solve the same
use-case using different frameworks.
After this I would translate their
classifications to the final ontology to see if all the information is classified
the right way according to the domain-ontology. This is still just a thought.
I believe I need some more insight into the matter before deciding on it.
3. Progress so far
One of the first necessary steps needed for this thesis is to clearly delimit
and define the concepts that will be used in this paper, considering the
lack of consistency in EA. I will try to use definitions already defined in
other literature or standards to avoid adding new meanings to the pile of
interpretations.
Model:
An
abstract
representation
of
reality
in
any
form
(including
mathematical, physical, symbolic, graphical, or descriptive form) to
present a certain aspect of that reality for answering the questions
studied (ISO 15704)
Method or Methodology:
A set of instructions (provided through text, computer programs, tools,
etc.) that is a step-by-step aid to the user. (ISO 15704)
Enterprise:
An enterprise is one or more organizations sharing a definite mission,
goals and objectives to offer an output such as a product or a service.
(ISO 15704)
7
Architecture:
A description of the basic arrangement and connectivity of parts of a
system (ISO 15704).
This list is still unfinished and will be completed during the further
progress.
Another list of EA frameworks was also created. It is included in the end as
appendix. This list contains all the frameworks, models, tools, languages
etc. that I encountered during some primary research on this subject. It will
serve as a selection pool for the frameworks that will be used in the final
ontology.
While making these lists I also read a lot of papers, which are mentioned
in point 5. These papers helped me put things into perspective and to see
the need for standardization in EA. Now I also understand better in which
direction my further research should go and what information I should be
looking for.
4.
Timeline for further progress
DEADLINE
TO DO
10-05-13
Understanding EA Concepts and defining the definitions used
throughout the research.
15-06-13
Making a list of existing EA frameworks.
15-07-13
Understanding CARP as a domain-ontology.
15-07-13
Selecting the frameworks to be incorporated in the ontology.
Choosing the right
criteria.
30-09-13
Getting to know the frameworks that will be used into more
detail.
15-10-13
Getting to know CARP or other possible domain ontologies.
28-02-14
Forming the ontology.
30-04-14
Validating the ontology.
8
25-05-14
5.
Finishing report.
List of Literature
5.1.
List of literature read
1. Dimitri,
R.,
Jan,
V.,
Bernaert,
M.,
&
Poels,
G.
(n.d.).
DEVELOPMENT OF A COMMON BASE FOR ENTERPRISE
ARCHITECTURE. Ghent University.
2. Schekkerman, J. (2005). Trends in enterprise architecture. Institute
for
Enterprise
Architecture,
Report
on
the
Third
…,
2009(December), 1–33.
3. Bernaert, M., Poels, G., Snoeck, M., & Backer, M. De. (2000).
Enterprise Architecture for Small and Medium- Sized Enterprises :
A Starting Point for Bringing EA to SMEs , Based on Adoption
Models, 1–33.
4. Sessions, R. (2007). Comparison of the top four enterprise
architecture methodologies
5. Bernaert, M. (n.d.). De zoektocht naar Know-How, Know- Why,
Know-What en Know-Who, 34–41.
6. Greefhorst, D., Koning, H., & Vliet, H. (2006). The many faces of
architectural descriptions. Information Systems Frontiers, 8(2),
103–113. doi:10.1007/s10796-006-7975-x
7. Gall, N. (2012). Gartner ’ s 2011 Global Enterprise Architecture
Survey : EA Frameworks Are Still Homemade and Hybrid. Gartner.
8. Bernaert, M., Poels, G., Snoeck, M., & De Backer, M. (2013).
CHOOSE: Towards a Metamodel for Enterprise Architecture in
Small and Medium-Sized Enterprises.
9. Capgemini. (n.d.). Enterprise , Business and IT Architecture and
the Integrated Architecture Framework Contents.
10. Urbaczewski, L., & Mrdalj, S. (2006). A comparison of enterprise
architecture frameworks. Issues in Information Systems, VII(2), 18–
23.
9
11. Lankhorst, M. M. (2004). Enterprise architecture modelling—the
issue of integration. Advanced Engineering Informatics, 18(4),
205–216. doi:10.1016/j.aei.2005.01.005
5.2.
List of literature in progress/to read
1. Chen, D., Doumeingts, G., & Vernadat, F. (2008). Architectures for
enterprise integration and interoperability: Past, present and future.
Computers in Industry, 59(7), 647–659.
doi:10.1016/j.compind.2007.12.016
2. Lankhorst, M. (2013). Enterprise architecture at work: Modelling,
communication and analysis. Springer Berlin Heidelberg.
3. Lagerström, R., Johnson, P., & Höök, D. (2010). Architecture
analysis of enterprise systems modifiability – Models, analysis, and
validation. Journal of Systems and Software, 83(8), 1387–1403.
doi:10.1016/j.jss.2010.02.019
4. Fischer, R., Aier, S., & Winter, R. (2007). A federated approach to
enterprise architecture model maintenance. Enterprise Modelling
and …, 14.
5. Tavernier, V. (2012). Ontwikkeling van een gevalstudie voor
enterprise architecture.
6. Van Acker, A., & Poels, G. (2012). Literatuurstudie naar de
bekendste raamwerken voor enterprise architectuur. Ghent
University.
7. Lassing, N., Rijsenbrij, D., & Van Vliet, H. (2001). Zicht op
aanpasbaarheid. few.vu.nl.
8. Zur Muehlen, M. (2004). Organizational Management in Workflow
Applications – Issues and Perspectives. Information Technology
and Management, 5(3/4), 271–291.
doi:10.1023/B:ITEM.0000031582.55219.2b
9. Janssen, J., & Radboud Universiteit Neimegen. (2005). Digitale
Architectuur - Selectiemodel Enterprise Architectuur Raamwerken:
Deelonderzoek - Groepering Enterprise Architectuur Raamwerken,
33.
10
10. Khayami, R. (2011). Qualitative characteristics of enterprise
architecture. Procedia Computer Science, 3, 1277–1282.
doi:10.1016/j.procs.2011.01.004
11. Lassing, N., Rijsenbrij, D., & Van Vliet, H. (2003). How well can we
predict changes at architecture design time? Journal of Systems
and Software, 65(2), 141–153.doi:10.1016/S0164-1212(02)00056-0
12. Langenberg, K., & Wegmann, A. (2004). Enterprise architecture:
What aspects is current research targeting. Laboratory of Systemic
Modeling, 2.
5.3.
Other sources used
1. "Ontology (information Science)." Wikipedia. Wikimedia
Foundation, 19 Apr. 2013. Web. 20 Apr. 2013.
1. "Viewpoint Modeling." Wikipedia. Wikimedia Foundation, 03 Oct.
2013. Web. 25 Apr. 2013.
2. Van 't Veld, Steven. "A/I/M - Weblog Van Steven Van 't Veld." A/I/M
- Weblog Van Steven Van 't Veld. N.p., n.d. Web. 07 May 2013.
http://www.aim.nl/weblognl/columns/200009%20NL%20IC10%20tapscott%20het%20proble
em%20alignment.php
3. ISO 15704, Industrial Automation Systems—Requirements for
Enterprise-reference Architectures and Methodologies, 2000
11