Understanding Enterprise Architecture through Bodies of Knowledge
A Conceptual Model
Camila Leles de Rezende Rohlfs
1
, Gerd Gr¨oner
2
and Fernando Silva Parreiras
1
1
Faculty of Business Sciences, FUMEC University, Belo Horizonte, Brazil
2
Software Systems Engineering, University of Duisburg-Essen, Essen, Germany
Keywords:
Conceptual Model, Enterprise Architecture, ArchiMate, Body of Knowledge.
Abstract:
There is extensive interest in modeling enterprises from a holistic perspective, showing not only the IT in-
frastructure of an organization, but also how this IT infrastructure supports business processes and how it
contributes to the realization of products and services. This interest has led to a large number of papers re-
porting on Enterprise Architecture. In this paper, we propose a new conceptual model to describe enterprises
from a holistic perspective. The proposed model is based on relationships between the ArchiMate language
and bodies of knowledge (BOKs). The conceptual model allows to understand how the bodies of knowledge
relate to the enterprise architecture. For this, we propose criteria that allow to relate the bodies of knowledge
to the perspectives that are defined in the ArchiMate language. Based on the proposed model, this work shows
how bodies of knowledge can be used cooperatively inside an enterprise architecture to improve the quality
of internal processes in order to generate value for the interests that support their strategic planning. Studies
indicate the benefits of ArchiMate in enterprise modeling. Existing studies have already shown the benefits
of using BOKs to represent and share available knowledge in and across enterprises. In this work, we go one
step further and show how the conceptual alignment of BOKs and ArchiMate advance the understanding of
enterprise architectures.
1 INTRODUCTION
The increasing complexity of business, the advance-
ment of new technologies, the growth of requirements
and the need to achieve business goals drive compa-
nies and organizations to cover their business pro-
cesses, organizational structures and technology by
a variety of models and specifications. In this con-
text, the complexity of organizational environments
and information systems justified the emergence of
the term Enterprise Architecture (EA) to denote a
comprehensive set of principles, methods and models
for defining and implementing organizational struc-
tures, business processes, information systems and
even technical infrastructures of IT within an orga-
nization (Lankhorst, 2005).
Comprehensive enterprise architectures are ben-
eficial to represent a wide variety of organizational
structures, processes, technologies and any kind of
relationships between modeling artifacts. Thus, enter-
prise architectures help to understand an organization,
its business objects and alignments with the underly-
ing information technology.
These architectures are built from the information
capture and understanding of business services and
processes, information systems and technical infras-
tructure (van Hee et al., 2004; Papazoglou, 2003).
However, a key challenge is to cover and identify rel-
evant artifacts for a particular architecture and how
these artifacts are related to other artifacts within and
across architectures. Obviously, this requires knowl-
edge about the whole enterprise, its structure, behav-
ior, technology and its actors.
Covering all artifacts and their relationships for
enterprise architectures is challenging by the embrac-
ing nature and coverage of heterogeneous architec-
tural domains. These domains reflect the variety of
stakeholders in the process of defining and maintain-
ing the architectures. Furthermore, predominant or-
ganizational aspects and specific features from the IT
make architectures more complex.
The first efforts to capture enterprise architectures
were based on sets of diagrams (Bass et al., 2003).
Although diagrams involve the use of intuitive graph-
ics, their understanding is still subject of interpreta-
tion. More recently, a family of languages for descrip-
tion organizational architectures has been proposed
((Jonkers et al., 2003), (Lankhorst, 2005)), enabling
249
Leles de Rezende Rohlfs C., Gröener G. and Silva Parreiras F..
Understanding Enterprise Architecture through Bodies of Knowledge - A Conceptual Model.
DOI: 10.5220/0004952502490259
In Proceedings of the 16th International Conference on Enterprise Information Systems (ICEIS-2014), pages 249-259
ISBN: 978-989-758-029-1
Copyright
c
2014 SCITEPRESS (Science and Technology Publications, Lda.)
a comprehensive and precise coverage of enterprises
from various views.
To tackle the previously described problem, we
propose a new conceptual model that covers enter-
prise architectures as one building block and organi-
zation knowledge sources as an other block. Knowl-
edge of an enterprise is covered by so-called bodies
of knowledge (BOKs). While bodies of knowledge
are used to represent knowledge that is available to
members of a group or organization, there is no inte-
gration of this established knowledge representation
formalism in the enterprise architecture so far.
We suggest a concept that is able to bring those
two domains together: enterprise architecture and
bodies of knowledge. The model was structured
from relationships created between the ArchiMate
language (standardized by The Open Group) and the
bodies of knowledge. The choice of the BOKs is justi-
fied by complementary natures that emphasize differ-
ent aspects of the organization. The paper shows how
some bodies of knowledge are related to the organi-
zational interests defined in the ArchiMate specifica-
tion. Knowing these relationships, enterprise execu-
tives can work cooperatively on interests based on the
knowledge presented by the common BOKs related
with these organizational interests.
This paper is structured as follows. Section 2 mo-
tivates the need for the proposed model in terms of
competence questions. Section 3 presents enterprise
architecture languages in general and the ArchiMate
language in particular. Section 4 introduces the used
BOKs. Section 5 presents a conceptual model for rep-
resenting bodies of knowledge based on ArchiMate.
Section 6 presents how the bodies of knowledge can
be related to the interests of the organizational struc-
ture from the ArchiMate language. Section 7 presents
related work. Finally, Section 8 concludes the paper.
2 COMPETENCE QUESTION
In the following, we exemplify how covered knowl-
edge helps to develop and maintain enterprise archi-
tectures for a drugstore. For this example, we outline
some competency question that we expect to be able
to answer.
When conductingstrategic planning, the drugstore
defines its mission, values and vision. Accordingly,
the drugstore aims to implement and achieve all goals
and visions. However, a survey conducted within
the drugstore found that many times the proposed
projects do not achieve the expected results due to the
lack of knowledge about the architecture.
Subject experts argue that it is important to know
how the organizational objectives bind business pro-
cesses, which is the technological structure that sup-
ports their processes, how the work is performed,
which products are generated and who are the people
in the organization.
For example, a proposed project of the market-
ing sector requested the restructuring of the system
“Promotional Package”. The sector manager of the
drugstore asked the enterprise architect to verify the
project’s impact on business processes and other en-
terprise systems. To find the impacted business pro-
cesses, the enterprise architect has to search for those
enterprise sectors that use the system in order to make
a manual survey of processes passing through these
sectors. To assess the impacted systems, the enter-
prise architect needs the help of the software devel-
opment sector in order to get a survey of the affected
systems.
The difficulty faced by the enterprise is that the
knowledge about business processes is tacit, in other
words, it is stored in the heads of some company em-
ployees and in some cases, there is an isolated map-
ping. Furthermore, the knowledge about the enter-
prise software systems is concentrated in the software
development sector. The software development sector
has documentation of the systems, but has no infor-
mation related to business processes served. There is
little or no traceability between systems and the pro-
cesses that they automate.
The problem faced by the drugstore is that the
teams directly related with an interest of the enter-
prise architecture, i.e., those people that perform ac-
tivities related to that interest, have little knowledge
about their interests and their relationships with other
interests. For example, the professionals responsible
for capturing requirements within a project has little
knowledge about techniques to perform this activity.
The knowledge presented by the BOKs related with
the interest, which addresses this activity, can assist
these professionals in its execution. Another exam-
ple, professionals working with the sales processes
management of the company are not aware of the re-
lationship between applications that automate activi-
ties of such processes. The knowledge presented by
the BOKs is related to both interests. Thus, BOKs can
assists these professionals in the execution of their ac-
tivities. This problem prevents the modeling, visual-
ization and understanding of enterprise architecture.
The raised problem can be divided up into three
subproblems: 1 - Lack of knowledge about a particu-
lar interest of the organization. For example, the drug-
store has difficulty to elicit and capture all require-
ments. 2 - Lack of knowledge about the relationships
between interests. For example, it is difficult to assess
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
250
the impact on business processes from a technological
change proposed by a project. 3 - Difficulty of model-
ing the enterprise architecture. For example, the orga-
nizational architect does not know how and where to
find the information needed to model the architecture
of the drugstore.
To solve these problems, we propose the collabo-
rative use of bodies of knowledge related to the enter-
prise interests. Based on a set of enterprise interests,
which is predefined in the ArchiMate specification,
we show the integration of bodies of knowledge in
enterprise architecture languages in order to improve
the overall understanding of the enterprise structure,
behavior and technology.
3 ENTERPRISE MODELING
WITH ARCHIMATE
Building an Enterprise Architecture is a discipline
that organizes and structures components from busi-
ness and IT, and their relationships that seek to
increase organizational performance through better
management of complexity.
Typically, an enterprise architecture is created so
that the different concerns and interests of the key
people of the organization are met by a better align-
ment between business and technology. Its goal is
to develop insights into the architecture, which ex-
plains how the concerns and requirements are consid-
ered and how commitments or agreements are neces-
sary to reconcile potentially conflicting interests (Ia-
cob et al., 2012). For the practical application of
enterprise architectures, some frameworks have been
created. These frameworks support and guide the de-
velopment of enterprise architectures, but they need
languages such as ArchiMate.
3.1 Purpose of Enterprise Architecture
Language
Each stakeholder in an enterprise possesses special-
ized views, facing the nature of its operations and
specific responsibilities. Even in the same part of an
organization, these people have clearly different men-
tal models. They speak specific languages and under-
stand preformed concepts by the set of their concerns,
policies and objectives themselves. To provide effi-
cient communication, enterprise architects use a stan-
dard language to model and communicate the archi-
tecture to stakeholders.
ArchiMate is a standard language that aims
mainly at providing a uniform representation of dia-
grams to describe enterprise architectures. It offers
an integrated conceptual approach that displays the
various domains of architectures, as well as the re-
lationships and dependencies among its components.
ArchiMate was developed in the context of an Euro-
pean project (Lankhorst, 2005) and it is a standard
of The Open Group based on the concepts of In-
stitute of Electric and Electronic Engineers (IEEE)
1471 (Hilliard, 2000). The ArchiMate framework
pre-defines concepts and relationships that allow the
description of the company as well as of its evolu-
tion over time, including changes and migrations. It
is simple, yet comprehensive enough to provide a
good mechanism for structuring an architecture (Ia-
cob et al., 2012).
3.2 The ArchiMate Language Structure
A precise specification of architecture components
and their relationships requires a modeling language
that prioritizes the consistent alignment between orga-
nization abstraction layers. In a modeling language,
specifications of components and relationships that
are provided to the architect are formalized in the lan-
guage metamodel (Iacob et al., 2012).
With respect to its horizontal range (columns),
the ArchiMate basic language consists of three types
of elements: active structure elements (organization
and its stakeholders), behavioral elements (processes)
and passive structure elements (informationand data).
With respect to its vertical extent (lines), the enter-
prise is modeled in three layers: business, application
and technology (Lankhorst, 2005).
According to (Lankhorst, 2005), an active struc-
ture element is defined as an entity capable to perform
behavior. An behavior element is defined as an activ-
ity unit undertaken by one or more active structure
element. The passive structure elements are objects
in which the behavior is performed.
Layers can be conceptualized as follows: the busi-
ness layer provides products and services to exter-
nal clients developed in the organization by business
processes performed by business actors; the applica-
tion layer supports the business layer, with services
conducted by software applications; the technology
layer provides infrastructure services (e.g., process-
ing, storage and communication services) needed
to run the applications realized by computers, the
hardware and the communication software of a sys-
tem (Lankhorst, 2005).
The elements and layers identified above can be
arrangedin a framework with nine cells, as illustrated
in Figure 1.
Besides the main concepts described above,
UnderstandingEnterpriseArchitecturethroughBodiesofKnowledge-AConceptualModel
251
Figure 1: Archimate Framework including extensions (Ia-
cob et al., 2012).
ArchiMate contains a core set of relationships. They
establish the connections between the concepts.
In ArchiMate language modular extensions can be
added with goal of creating new concepts, relation-
ships, or attributes. The 2.0 edition of the ArchiMate
specification addresses two such extensions: the Mo-
tivation extension and the Implementation and Migra-
tion extension (Iacob et al., 2012). These two exten-
sions are included in Figure 1.
The ArchiMate Motivation extension adds the mo-
tivational concepts as objective (or goal), principle
and requirement. It discusses how the enterprise ar-
chitecture is aligned with its context, as described by
motivational elements.
The ArchiMate extension of Implementation and
Migration adds concepts to support subsequent
phases related to the implementation and migration
of architectures: Opportunities and Solutions, Migra-
tion Planning and Implementation Governance (Iacob
et al., 2012).
ArchiMate advocates a more flexible approach in
which architects and other stakeholders can define
their own views on an enterprise architecture. In this
approach, views are specified by viewpoints. View-
points define abstractions in the set of models that rep-
resent the enterprise architecture, indicating a particu-
lar type of stakeholder and pointing to a particular set
of interests. Viewpoints can be used to isolate certain
aspects but also to relate two or more aspects (Iacob
et al., 2012).
An ArchiMate viewpoint is a selection of a rele-
vant subset of ArchiMate concepts (and their relation-
ships). A number of these viewpoints were developed
based on practical experiences.
Other viewpoints exist to cover motivational as-
pects. Each of these viewpoints presents a different
perspective on the motivation modeling that underlies
some enterprise architecture and allows a designer to
concentrate on certain aspects. Other viewpoints al-
low to model aspects of implementation and migra-
tion. The model definition of viewpoints is presented
in Section 5.
4 BODIES OF KNOWLEDGE IN
ENTERPRISE ARCHITECTURE
Generally, the bodies of knowledge formalize various
concepts and identify a set of knowledge, which is
recognized as good practice and applicable within a
particular context. Thus, concepts, information, ac-
tivities, tasks, practices, tools and standards are struc-
tured around knowledge areas into a body of knowl-
edge. The goal is to provide this knowledge to the
members of a group or organization that has an inter-
est in a certain area.
In order to assist organizational modeling, some
bodies of knowledge were selected for study. The cri-
terion for choosing the BOKs was defined by the au-
thors according to the nature of each BOK with regard
to the emphasis given to different aspects of the orga-
nization. The authors investigated BOKs, used by or-
ganizations and educational institutions, which were
related to enterprise interests. We selected the follow-
ing BOKs: Business Analysis Body of Knowledge
(BABOK), Business Process Management Common
Body of Knowledge (BPM CBOK), Data Manage-
ment Body of Knowledge (DMBOK), Project Man-
agement Body of Knowledge (PMBOK), Systems
Engineering Body of Knowledge (SEBOK), Software
Engineering Body of Knowledge (SWEBOK).
According to the International Institute of Busi-
ness Analysis (IIBA), the BABOK is a globally rec-
ognized standard for the practice of business analysis.
Their primary purpose is to define the profession of
business analysis and to help these professionals to
understand problems and to specify appropriate solu-
tions to deliver value to the organization. For this,
the guide describes business analysis knowledge ar-
eas, their associated activities and tasks, and the skills
necessary to be effective in their execution. More-
over, it describes techniques and practices generally
accepted, proven and widely used in the discipline of
business analysis (IIBA, 2009).
The guide to the BPM CBOK is a reference for
business processes management practitioners. It is
organized into knowledge areas that are segmented
into two perspectives: organizational oriented per-
spective and process perspective. These areas reflect
BPM capabilities that may be considered by an or-
ganization implementing Business Process Manage-
ment (ABPMP, 2013).
The purpose of this guide is assist business pro-
cesses management professional in optimizing the
results of organizations by improving business pro-
cesses. The guide provides a list of common activi-
ties and tasks associated with each knowledge area. It
also provides a comprehensive overview of best prac-
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
252
tices and lessons learned collected by the Associa-
tion of Business Process Management Professionals
(ABPMP) and affiliated associations (ABPMP, 2013).
The DMBOK guide structures the process of Data
Management (DM) to effectively manage and lever-
age the use of data assets. Its goals are to meet
and to exceed the needs for information of concerned
parts (stakeholders) of the company in terms of avail-
ability, security and quality. For this, the BOK in-
troduces concepts, identifies data management goals,
describe about functions, activities, primary deliv-
erables, roles, principles, commonly accepted good
practices, technology and organizational/cultural is-
sues related with DM (Brackett and Earley, 2009).
The PMBOK guide is a recognized standard
for the project management profession that defines
project management and related concepts. Based
on the statement that the application of appropriate
knowledge, processes, skills, tools and techniques can
have a significant impact on project success, the BOK
provides guidelines and describes the project man-
agement life cycle, the related processes, the sum of
knowledge and best practices within the profession of
project management (PMI, 2013).
The SEBOK provides a compendium of the key
knowledge sources and references of systems engi-
neering. It is organized and explained to assist a
wide variety of users with respect to the develop-
ment, management and application of systems. Their
objective is to strengthen the mutual understanding
across the various disciplines involved in operating
systems. The guide describes the boundaries, termi-
nology, content, and structure of systems engineer-
ing (Pyster et al., 2013).
The purpose of the SWEBOK is to provide a con-
sensually validated characterization of the bounds of
the software engineering discipline and to provide a
topical access to the body of knowledge supporting
that discipline. The BOK is widely used in disciplines
related to software development, both in academia
and in practice. It directs the software engineer in the
development of their activities throughout the devel-
opment life cycle of software (IEEE Computer Soci-
ety, 2004).
5 A CONCEPTUAL MODEL FOR
KNOWLEDGE INSIDE
ARCHITECTURES
The overall goal of this work is to create a conceptual
model that allows understanding how these bodies of
knowledge relate to the enterprise architecture. In
Figure 2: Interests, related to the enterprise architecture, de-
fined in the ArchiMate specification.
this section, we show the proposed conceptual model,
which is based on two pillars: bodies of knowledge
(BOK) and the ArchiMate language. The viewpoints
defined in ArchiMate were used to create the relation-
ship between bodies of knowledge and the enterprise
architecture.
5.1 ArchiMate Viewpoint Model
ArchiMate allows that views are specified through
viewpoints. Viewpoints define abstractions on the
set of models representing the enterprise architecture,
each aimed at a particular type of stakeholder and ad-
dressing a particular set of concerns. Viewpoints are
a means to focus on particular aspects of the architec-
ture. These aspects are determined by the concerns of
a stakeholder with whom communication takes place.
What should and should not be visible from a spe-
cific viewpoint is therefore entirely dependent on the
argumentation with respect to a stakeholder’s con-
cerns (Iacob et al., 2012).
Different interests related to the enterprise can be
shown by the viewpoints. Figure 2 summarizes the
interests related to the enterprise, addressed by view-
points.
An architect is confronted with many different
types of stakeholders and concerns. To help him in
selecting the right viewpoints for the task at hand,
ArchiMate introduces a framework for the defini-
tion and classification of viewpoints and views. The
framework is based on two dimensions: purpose and
content (Iacob et al., 2012).
The following three types of architecture support
the purpose dimension of architecture views: Design-
ing, Deciding and Informing. Designing viewpoints
support architects and designers in the design pro-
cess from initial sketch to detailed design. Deciding
viewpoints assist managers in the process of decision-
making by offering insight into crossdomain architec-
ture relationships, typically through projections and
intersections of underlying models, but also by means
of analytical techniques. Informing viewpoints help
to inform any stakeholder about the enterprise ar-
chitecture, in order to achieve understanding, obtain
UnderstandingEnterpriseArchitecturethroughBodiesofKnowledge-AConceptualModel
253
Figure 3: ArchiMate Viewpoint Model in Database.
commitment and convince adversaries (Iacob et al.,
2012).
For characterizing the content of a view, Archi-
Mate defines the following abstraction levels: De-
tails, Coherence and Overview. Views on the detail
level typically consider one layer and one aspect from
ArchiMate. At the coherence abstraction level, multi-
ple layers or multiple aspects are spanned. Extending
the view to more than one layer or aspect enables the
stakeholder to focus on architecture relationships like
process-uses-system (multiple layer) or application-
uses-object (multiple aspect). The overview abstrac-
tion level addresses both multiple layers and multiple
aspects (Iacob et al., 2012).
Some viewpoints have a scope that is limited to a
single layer or aspect. Others have a broader scope
and can address more layers and aspects. However, a
viewpoint is related to only one enterprise interest. A
viewpoint may be related to the extensions defined in
ArchiMate. An extension can relate to multiple view-
points. We show all these relationship in the model
presented in Figure 3. This structure was modeled
in a database to collect all relationships between the
ArchiMate viewpoints and the knowledge areas of the
BOKs.
5.2 Bodies of Knowledge Model
The introduced BOKs are structured around knowl-
edge areas. A knowledge area is related to just a body
of knowledge. Each body of knowledge cites and / or
defines roles related to the activities and good prac-
tices detailed in the BOK. A role can be cited and / or
defined in multiple BOKs.
Figure 4 shows the structure of the bodies of
knowledge with regard to the knowledge areas and
roles cited and / or defined. This structure was mod-
eled and built into a database to allow the creation of
relationships between the ArchiMate viewpoints and
the knowledge areas of the bodies of knowledge.
Figure 4: Bodies of Knowledge Model in Database.
5.3 Relationship Criteria and
Relationship Model
According to ArchiMate, an enterprise interest can be
represented by one or more viewpoints. A particu-
lar role has an interest, therefore, is interested in all
viewpoints that represent that interest.
ArchiMate defines which stakeholders are inter-
ested in a viewpoint. The BOKs cite and / or define
roles according to interests, activities, tasks and best
practices. In this work, we link interests, viewpoints
and stakeholders defined in ArchiMate with the roles
cited and / or defined in the BOKs. An interest of
a role has been defined, based on the definition of the
role by a BOK, and / or the closeness it has with stake-
holders defined as interested in a viewpoint represent-
ing that interest.
The SWEBOK and the SEBOK define the roles
software engineer and systems engineer. They are de-
fined as those interested in software engineering and
systems engineering. These roles have the same inter-
ests like the roles defined in Rational Unified Process
(RUP) (Kruchten, 2003).
Figure 5 shows one example about the groups of
interests and viewpoints that represent this particular
group and the corresponding interested roles. These
interests, viewpoints and roles are represented in the
model from the entities “interest”, “viewpoint” and
“role” respectively, as shown in Figure 6.
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
254
Figure 5: Interest Groups - Example with the interest ”Busi-
ness Behavior”.
Relationship criteria were created to enable the es-
tablishment of relationships between the knowledge
areas of BOKs and the ArchiMate viewpoints. Rela-
tionship criteria - If a knowledge area declares a sub-
set, not empty, of the set of characteristics defined by
a viewpoint, so a relationship between the knowledge
area and the viewpoint can be created.
Restrictions on the relationship criteria: 1 - The
subset related to the set of stakeholder can not be
empty. The definition of a stakeholder in a knowl-
edge area can be direct or indirect (see interest group).
2 - The subset related to the set of Concerns can not
be empty. The definition of a concern in an area of
knowledge should be direct. 3 - If the knowledge area
declares Purposes, at least one of them has to be part
of the purposes defined in viewpoint. 4 - If the knowl-
edge area declares Abstraction Level, at least one of
them has to be part of the Abstraction Levels defined
in viewpoint. 5 - If the knowledge area declares Lay-
ers, at least one of them has to be part of the Layers
defined in viewpoint. 6 - If the knowledge area de-
clares Aspects, at least one of them has to be part of
the Aspects defined in viewpoint.
Figure 6 shows the structure of the relationship
between the bodies of knowledge and the ArchiMate
viewpoints. This structure was modeled and built into
a database to allow the creation of relationships be-
tween the ArchiMate viewpoints and the knowledge
areas of the bodies of knowledge.
5.4 Questions that Can Be Answered
From the Model
The constructed model consists of 3 parts: 1 - Archi-
Mate Viewpoint Model; 2 - Bodies of Knowledge
Model; 3 - Relationship between the bodies of knowl-
edge and ArchiMate viewpoints. The physical struc-
ture, based on the models, was represented in a
database. The relevant information of the ArchiMate
viewpoints, the bodies of knowledge and the relation-
Figure 6: Relationship between the bodies of knowledge
and the ArchiMate viewpoints.
ships between the bodies of knowledge and Archi-
Mate viewpoints were collected in the database.
Some questions that can be answered from the
model. These questions can be answered directly
or indirectly. Direct questions can be answered
from data that were entered into the database. Data
taken directly from the ArchiMate specification or the
BOKs specifications. Indirect questions can be an-
swered based on the proposed relationship between
BOKs and ArchiMate.
The direct questions that can be answered are di-
vided in two groups: 1 - Direct questions with data
from the BOKs and 2 - Direct questions with data
from the ArchiMate. Some example questions for
group 1 are the following:
• What were the BOKs studied?
• What are the knowledge areas of a BOK?
• What are the roles cited in a BOK?
Some questions that belong to group 2 are:
• What are the stakeholders interested in a view-
point?
• What are the aspects of the architecture focused
by viewpoint? (Concerns, Purposes, Abstraction
Levels, Layers and Aspects).
• What are the parts of the enterprise architecture
represented by a viewpoint? (Interest)
The competence questions, presented in Section 2, are
an example of indirect questions. Other indirect ques-
tions are:
• What are the BOKs, knowledge areas and roles
interested in a viewpoint?
• What are the layers of interest of a BOK, of a
knowledge area, of a role?
• Which is the purpose most often related to a
knowledge area, to a BOK, to a role?
UnderstandingEnterpriseArchitecturethroughBodiesofKnowledge-AConceptualModel
255
Figure 7: Interest areas of the enterprise architecture and the bodies of knowledge relevant.
6 VALIDATION
In order to validate this approach, we addressed di-
rect and indirect competence questions, as those men-
tioned in Section 2. From the responses, a report was
created that shows how bodies of knowledge are re-
lated to the interests of an enterprise.
The criteria presented in Section 5.3, enabled the
establishment of relationships between the knowledge
areas of BOKs and the ArchiMate viewpoints. A
viewpoint is related to one and only one interest, but
an interest may be related to multiple viewpoints. For
each interest, we tracked all the BOKs who have
knowledge areas related to at least one viewpoint
linked to the interest. The relevance percentage of a
BOK on a particular interest was calculated from the
number of links between the knowledge areas of the
BOK and the viewpoints linked to the interest.
Figure 7 shows the interest areas of the enterprise
architecture and the bodies of knowledge relevant to
these interests. The size of the each circle is propor-
tional to the relevance percentage of the BOK to the
interest. Analyzing the figure horizontally, we can vi-
sualize the bodies of knowledge that are relevant to
the enterprise interests. For example, the figure shows
that interest 3 (the information and data used) has
three BOKs related to it: DMBOK, SWEBOK and
SEBOK. Analyzing the figure vertically, we can see
what interests are related to the BOKs, e.g., CBOK
is related to 8 interests: business behavior, structure
of the enterprise, applications and components, re-
late the enterprise, relates applications to their use,
overview, motivation and implementation and migra-
tion.
Figures 8, 9 and 10 show each interest area of the
enterprise architecture and the bodies of knowledge
separately to these interest with the respective rele-
Figure 8: Bodies of knowledge relevant to interests with the
respective relevance percentages - Part 1.
vance percentages. We can see separately all BOKs
related to a particular interest and their respective per-
centage of relevance. For example, Figure 8 shows
that the business behavior interest is related to the
CBOK and SEBOK. The relevance percentage of the
CBOK is 95% and relevance percentage of the SE-
BOK is 5%.
In Section 2, we presented 3 problems: 1 - Lack
of knowledge about a particular interest of the organi-
zation. 2 - Lack of knowledge about the relationships
between interests. 3 - Difficulty of modeling the en-
terprise architecture.
In the example presented about Problem 1, we de-
scribed about the issue that professionals, responsible
for capturing project requirements, have little knowl-
edge about techniques that perform this activity. Ac-
cording to ArchiMate, the Motivation interest is re-
lated to this activity. In this case, the results presented
in Figure 9 show that SEBOK, BABOK, PMBOK,
SWEBOK and CBOK are related to that interest.
The SEBOK have the knowledge area “Systems
Engineering and Software Engineering”. The SWE-
BOK has a knowledge area that talks about require-
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
256
Figure 9: Bodies of knowledge relevant to interests with the
respective relevance percentages - Part 2.
Figure 10: Bodies of knowledge relevant to interests with
the respective relevance percentages - Part 3.
ments elicitation. This area is concerned with the col-
lection of software requirements. It includes require-
ment sources and elicitation techniques. The BABOK
have the elicitation knowledge area. This area de-
scribes about preparation for elicitation, conducting
elicitation activity, documentation of elicitation re-
sults, confirmation of elicitation results and elicita-
tion techniques. The scope management knowledge
area in PMBOK describes about the process of defin-
ing and documenting the needs of the stakeholders to
achieve the project objectives. This knowledge area
presents tools and techniques to collect requirements.
Finally, the CBOK describes methods for gathering
information.
In the example related to Problem 2, we described
about the difficulty to assess the impact on business
processes from a technological change proposed by a
project. This example is associated with two interests
of the organization, business behavior and relates ap-
plications to their use. The results in Figure 7 show
that these interests have BOKs in common, for exam-
ple, the CBOK.
The CBOK describes about the realization of busi-
ness process management and has areas of expertise,
such as the Process Analysis knowledge area, that
explain the need to understand how applications are
used to support one or more business processes, and
how they are used by other applications.
Lastly, in the example presented about Problem 3,
we reported the difficulty of the enterprise architect to
know how and where to find the information needed
to model the enterprise architecture. By using BOKs
to work in a specific interest, activities related to that
interest are defined and organized. By using BOKs to
work cooperatively on enterprise interests, the points
of intersection between the interests can be mapped,
allowing to create traceability between artifacts that
are part of the intersection. Thus, the use of the BOKs
can assist the enterprise architects to locate the ar-
tifacts as well as their relationships. For example,
the Motivation and Applications and components and
their mutual relationships interests, have four BOKs
in common. A point of intersection between these
interests, based on the BOKs, are the requirements.
These BOKs describe about the importance of trace-
ability between requirements throughout the project.
7 RELATED WORK
As mentioned throughout this paper, there are sev-
eral initiatives to support organizational modeling.
The enterprise architectures modeling is reflected in
various frameworks for structuring architectures that
followed the seminal work of John Zachman (Zach-
man, 1987) and are proposed or adopted by inter-
national organizations of standardization and gov-
ernment organizations. Examples of such frame-
works include: Architecture Framework TOGAF
(The Open Group Architecture Framework) (Group,
2011); Department of Defense Architectural Frame-
work (DoDAF) (of Defense, 2010); United States
Government Federal Enterprise Architecture (Gov-
ernment, 2012); Extended Enterprise Architecture
Framework of Institute For Enterprise Architecture
Developments (Schekkerman, 2006); Gartner Frame-
work (James et al., 2005); Pragmatic Architecture
Framework (Ltd, 2011), RM-ODP reference model
of ISO (Reference Model for Open Distributed Pro-
cessing) (Farooqui et al., 1995); and Architecture
ARIS (Architecture of Integrated Information Sys-
tems) (Scheer, 1999).
These frameworks help enterprise architectures
modeling in practice. They guide, direct and use
other methodologies, languages and tools, such as
BPMN (OMG, 2013); ArchiMate (Iacob et al., 2012);
architecture repositories, business intelligence, mod-
eling and communication.
In this paper (Section 2), we show that is impor-
tant to know how the enterprise objectives are linked
to business processes and the technological structure
that supports these processes. Domi et al. (Doumi
UnderstandingEnterpriseArchitecturethroughBodiesofKnowledge-AConceptualModel
257
et al., 2011), propose an approach for modeling strate-
gic alignment. The approach proposed ensures that
the models of the strategy are linked with models of
the functional level.
Was not found literature related to the joint use
of enterprise architecture and bodies of knowledge
specifically. However, there are some works that ad-
dress a specific body of knowledge for enterprise ar-
chitecture and other works that address the modeling
of some enterprise interests and bodies of knowledge
as complementary approaches.
Kandjani and Bernus argue that Enterprise Archi-
tecture is an area of interdisciplinary study relies on
models, methods and theories of many disciplines.
These authors advocate that the EA discipline (EAD),
as any other developing discipline, there should exist
a commonly accepted terminology, allowing interdis-
ciplinary theories to be stated, which in turn facilitate
the creation of cross disciplinary models and method-
ologies (Kandjani and Bernus, 2012a) and (Kandjani
and Bernus, 2012b). The works of Kandjani and
Bernus (Kandjani and Bernus, 2012a) and (Kandjani
and Bernus, 2012b) have points in common with this
work because, like us, they believe that EA is a dis-
cipline that has an evolving body of knowledge. As
a discipline, EA is related to other disciplines. These
disciplines related to EA may have their own bodies
of knowledge. Moreover, the authors show that in the
context of EA, different domains may have artifacts
in common.
Abran, April and Monsalve (Abran et al., 2012)
write about the expressiveness of business process
modeling notations for software requirements elici-
tation. They present some propositions to adapt the
BWW (Bunge-Wand-Weber) representation model to
allow its application to the software requirements
elicitation domain. These propositions are based on
the analysis of the Guide to the Software Engineering
Body of Knowledge (SWEBOK) and the Guide to the
Business Analysis Body of Knowledge (BABOK).
The BWW representation model is frequently used
for assessing the expressiveness of business process
modeling notations. This work relates the BOKs,
BABOK and SWEBOK, to the some enterprise in-
terests. The BOKs are worked collaboratively in the
interests. But the work, unlike ours, does not have cri-
teria for to relate BOKs with the enterprise interests.
In another paper, Abran, April and Mon-
salve (Abran et al., 2010) show that proposals for new
modeling notations emerge and the evolution of cur-
rent ones are becoming more complex, often in an
attempt to satisfy the many different modeling per-
spectives required by each stakeholder. They present
a method to identify the specific notation construct
requirements at multiple levels of abstraction, which
satisfy the needs of a stakeholder when performing
a specific task. Initially the focus is on two differ-
ent stakeholders: software engineers (SE) and busi-
ness analysts (BA), and one specific software engi-
neering activity: requirements eliciting and analysis.
The specific body of knowledge of the two stakehold-
ers (SWEBOK for the SE and BABOK for the BA)
are used to identify each stakeholder specific nota-
tion construct requirements, at multiple levels of ab-
straction in order to propose a simplification of their
notation and constructs set. They presents solution
avenues to simplify business process modeling nota-
tions by identifying the specific constructs preferred
by different stakeholders. Similarly to the above
work, this work is related to ours because it shows the
ability to work collaboratively BOKs into enterprise
interests, but interests are not addressed punctually as
in our case.
8 CONCLUSIONS
The relationships presented in this work between
BOKs and interests of the enterprise architecture en-
able collaborative use of bodies of knowledge. These
relationships can be used as drivers to promote the
dissemination of knowledge within each interest area
from the BOKs related to this area, as well as dissem-
ination of knowledge about the relationships between
these interests. This collaborative use of the BOKs
with the enterprise interests, defined in the ArchiMate
specification, facilitates the modeling, visualization
and understanding of enterprise architectures.
How correlated work, a study will be conducted
to verify which support processes, executed in orga-
nizations, can help the building of enterprise architec-
ture. This study takes into consideration the architec-
tural subdivision proposed by TOGAF. The TOGAF
divides enterprise architecture in 4 sub-architectures:
Business, Application, Infrastructure and Data. The
study, based on state of the art, will verify which sup-
port processes are capable to assisting the construc-
tion of each sub-architecture.
As a complementary part, a new study will be con-
ducted, based on the results presented in this paper to
determine how the bodies of knowledge can help cre-
ate and improve these support processes and the re-
lationships between them. The end result will be ap-
plied in a real organization, with the aim of improving
support processes and promote communication and
traceability between them to support the modeling,
construction and maintenance of enterprise architec-
ture. This will be done in the context of a drugstore.
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
258
ACKNOWLEDGEMENTS
This work is supported by FAPEMIG Brazil under
Grant No. 11334.
REFERENCES
ABPMP (2013). Guide to the Business Process Manage-
ment Common Body of Knowledge: ABPMP BPM
CBOK
R
. Association of Business Process Manage-
ment Professionals.
Abran, A., April, A., and Monsalve, C. (2010). Represent-
ing unique stakeholder perspectives in bpm notations.
Abran, A., April, A., and Monsalve, C. (2012). On the ex-
pressiveness of business process modeling notations
for software requirements elicitation.
Brackett, M. and Earley, P. S. (2009). The DAMA Guide to
The Data Management Body of Knowledge (DAMA-
DMBOK Guide).
Doumi, K., Ba¨ına, S., and Ba¨ına, K. (2011). Modeling ap-
proach for business it alignment. In ICEIS (4), pages
457–464.
Farooqui, K., Logrippo, L., and deMeer, J. (1995). The iso
reference model for open distributed processing: an
introduction.
Government, U. F. (2012). The Common Approach to Fed-
eral Enterprise Architecture. U.S. Federal Govern-
ment.
Group, T. O. (2011). The Open Group Architectural Frame-
work (TOGAF Version 9.1). The Open Group.
Hilliard, R. (2000). Ieee-std-1471-2000 recommended
practice for architectural description of software-
intensive systems. IEEE.
Iacob, M., Jonkers, H., Lankhorst, M., Proper, E., Quartel,
D., et al. (2012). Archimate 2.0 specification.
IEEE Computer Society (2004). Software Engineering
Body of Knowledge (SWEBOK). Angela Burgess,
EUA.
IIBA (2009). A Guide to the Business Analysis Body of
Knowledge. International Institute of Business Anal-
ysis.
James, G. A., Robert, A., Handler, A. L., and Nicholas,
G. (2005). Gartner enterprise architecture framework:
Evolution 2005.
Jonkers, H. et al. (2003). Architecture language reference
manual. Telematica Instituut.
Kandjani, H. and Bernus, P. (2012a). The enterprise archi-
tecture body of knowledge as an evolving discipline.
In ICEIS, pages 452–470.
Kandjani, H. and Bernus, P. (2012b). Evolution of enter-
prise architecture discipline - towards a unified devel-
oping theory of enterprise architecture body of knowl-
edge as an evolving discipline. In ICEIS (3), pages
145–154.
Kruchten, P. (2003). The Rational Unified Process: An In-
troduction. Addison-Wesley.
Lankhorst, M. (2005). Enterprise architecture at work:
Modelling, communication and analysis. Springer.
Ltd, P. E. (2011). Peaf - overview.
of Defense, U. D. (2010). DoD Architecture Framework
(Version 2.02). U.S. Department of Defense.
OMG (2013). Business process model and notation (bpmn).
Papazoglou, M. (2003). Service-oriented computing: con-
cepts, characteristics and directions. In Web Informa-
tion Systems Engineering, 2003. WISE 2003. Proceed-
ings of the Fourth International Conference on, pages
3–12.
PMI (2013). A Guide to the Project Management Body of
Knowledge: PMBOK Guide. PMI Standard. Project
Management Institute, Incorporated.
Pyster, A., Olwell, D., Hutchison, N., Enck, S., Anthony, J.,
Henry, D., and Squires, A. (2013). Guide to the Sys-
tems Engineering Body of Knowledge (SEBoK) ver-
sion 1.1.2.
Scheer, A. W. (1999). ARIS Business Process Modeling.
Springer.
Schekkerman, J. (2006). Extended enterprise architecture
framework essentials guide.
van Hee, K. M. et al. (2004). Workflow management: mod-
els, methods, and systems. The MIT press.
Zachman, J. A. (1987). A framework for information sys-
tems architecture.
UnderstandingEnterpriseArchitecturethroughBodiesofKnowledge-AConceptualModel
259
