Knowledge Management Framework for Early Phases in

TOGAF-based Enterprise Architecture

Juan Pablo Meneses-Ortegon and Rafael A. Gonzalez

Pontificia Universidad Javeriana, Bogotá, Colombia

Keywords: Knowledge Management, Enterprise Architecture, TOGAF.

Abstract: Consulting firms in enterprise architecture that develop projects through the TOGAF framework may

generate valuable knowledge from project to project. However, for this knowledge to create value, it must

be supported by an effective ability to capture, store and reuse it. This paper proposes a knowledge

management framework focused on TOGAF initial phases to enable reusing lessons from previous projects.

Through a specific meta-model, it offers “ways of” thinking, working, supporting, controlling and

modelling this process. As a result, we present some steps to develop knowledge management in TOGAF-

based enterprise architecture projects through a case study in a consulting firm.

1 INTRODUCTION

Enterprise Architecture (EA) is a discipline that is

defined as "a coherent set of principles, methods and

models used in the design and/or implementation of

an organizational structure, business processes,

information systems, and infrastructure" (Lankhorst,

2012). This discipline involves and requires the

effective use of both tacit and explicit knowledge,

related to both client and consulting companies. Due

to the complexity of this knowledge, companies

need a flexible processes that allows them to adapt

themselves as such knowledge evolves (Arango

Serna et al., 2011).

Of existing EA frameworks, TOGAF –The Open

Group Architecture Framework– stands out, due to

its world-wide acceptance and use. This framework

proposes several phases to follow, including two

early stages: preliminary and phase A (architecture

vision). These phases provide the initial knowledge

that allows supporting the rest of the enterprise

architecture exercise, requiring crucial knowledge

management processes, such as identification,

acquisition, and development (Struck et al., 2010).

Moreover, resulting knowledge in EA consulting

firms may become their most valuable resource.

TOGAF has an associated lifecycle to develop

the enterprise architecture called "Architecture

Development Method " - ADM (The Open Group,

2009), that presents specific steps that generate

information which can be converted into knowledge

in order to be used by the client as well as the

consulting firm. When a company doesn’t have a

model or policy for knowledge management, its

knowledge can be lost or not effectively re-used.

This article provides a research proposal, based

on knowledge management, to support

communication, transmission and appropriate use of

knowledge for decision-making. It gives support to

the patterns of enterprise architecture management,

such as the definition of methodologies,

visualization and representation of information

models (Ernst, 2008). Thus, by using management

services centered on explicit knowledge generated

through ADM within the TOGAF frameworkand

stored in the architecture repository, it allows

effective governance ot the implementation process.

This paper presents the research problem, the

methodology used, followed by the presentation of

the case study used as application domain. In the

next section, the article shows the proposed

knowledge management framework and its

composition.

Finally conclusions and future work derived

from the project are presented.

2 RESEARCH APPROACH

This section has two parts: the explanation of the

research problem and the methodology used to face

it.

Meneses-Ortegón, J. and Gonzalez, R.

Knowledge Management Framework for Early Phases in TOGAF-based Enterprise Architecture.

DOI: 10.5220/0006049400310040

In Proceedings of the 8th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2016) - Volume 3: KMIS, pages 31-40

ISBN: 978-989-758-203-5

2.1 Research Problem

TOGAF enterprise architecture is supported in the

ADM method (The Open Group, 2009). In each

phase, a number of deliverables and associated

knowledge is generated, but it may become lost or

not effectively reused, due to lack of monitoring in

consulting firms. This knowledge is important due to

the possibility of taking advantage of it in later

enterprise architecture projects. Information that

becomes knowledge, by being linked to experience,

will help to deal with future projects, allowing the

project manager to not repeat the same mistakes or

indeed to take advantage of good practices identified

in previous projects. These good practices will guide

the development of new activities, for instance, in

activities applied to government-related projects or

within the same industry sector.

The initial phases of TOGAF are a particularly

rich source of potentially valuable knowledge. In the

preliminary phase of TOGAF-ADM, the EA group

defines the project’s goals and expectations

according to the aims and vision of the business and

the definition of stakeholders, their requirements and

priorities. All this implies a process of knowledge

identification and acquisition related to frameworks,

methodologies and other tools that support the rest

of the project. After defining this initial stage, the

architecture vision goes on to further specify

knowledge from the point of view of business, data,

application and technology (Struck et al., 2010).

However, there is no evidence of effective future use

of these outputs in future projects in a governed and

systematic fashion, attached to ADM.

Although enterprise architecture is often

supported in knowledge management tools through

the implementation of enterprise wikis or digital

libraries that allow information retrieval (Tu et al.,

2012; Fiedler et al., 2013), and other kind of project-

oriented search-based tools for enterprise

architecture management (Anajafi et al., 2010), EA

has not been sufficiently supported in tailored

knowledge management processes.

The contribution of this paper is aimed at

communicating and/or transferring knowledge for

EA decision-making. This decision-making may be

reflected, for instance, in activities such as reviewing

the current architecture (Buckl et al., 2010) or in

supporting the patterns of enterprise architecture

management, like methodologies definition,

visualization and representation of information

models (Ernst, 2008). This flow of knowledge is a

special challenge because of the number and

diversity of stakeholders.

Likewise, it is important to manage the

generated artifacts as an important part of the

enterprise architecture, which are usually stored in

the architecture’s repository. The problem is that

often these repositories are no more than that, a

repository where the results of each activity are

stored, but do not inform future decisions based on

reuse or socialization. Therefore, the use of explicit

knowledge management services integrated in the

process of ADM - TOGAF, coupled to the

repository, should allow the implementation of an

effectively governed architecture where the

knowledge acquired is exploited beyond the scope of

a single project.

2.2 Research Methodology

The research methodology adopted is design science

research as a methodology for the design and

development of information systems (Peffers et al.,

2007), where the designed artefact in our case is the

framework for EA knowledge management. In

Peffers et al., the process is effectively completed

once the artefact is demonstrated, validated and

communicated.

For this reason, the development of this project was

implemented through this methodology, which

focuses on solving real-world problems through a 6-

phase approach:

 Identify the problem and motivation

 Define solution objectives

 Design and development

 Demonstration

 Evaluation

 Communication

Development and validation of the solution was

done iteratively around the following artefacts:

knowledge maps, knowledge processes, process

models of the preliminary and architecture vision

stages and the overall knowledge management

framework.

Specific development of the research method is

described in sections 4 and 5.

2.3 Case Study

Development of the knowledge management

framework was carried out in the context of a large

IT and EA Colombian consulting firm, Indra

Colombia, in relation to their TOGAF-based EA

consulting projects. Indra is a multinational

company with headquarters in Spain and its main

core is generating innovative IT services and

KMIS 2016 - 8th International Conference on Knowledge Management and Information Sharing

solutions. These services are delivered in line with

management strategies of customer needs through

consulting, development and project management,

integration and implementation solutions and

outsourcing of information systems, in sectors such

as: transport and traffic, energy and industry, public

administration and healthcare, financial services,

security and defence and telecom and media (Indra,

2014).

Indra has offices in 138 countries with a total of

42 thousand professionals approximately. The

company has presence in Latin American countries

including Argentina, Bolivia, Brazil, Chile,

Colombia, Ecuador, El Salvador, México, Panamá,

Perú, Uruguay and Venezuela (Indra, 2014). Indra

has an 18 year presence in the Colombian market,

currently with more than 2000 professionals and 7

offices in Bogotá, Pereira, Barranquilla and

Medellin, with solutions and services in cloud

computing, outsourcing of BPO (business process

outsourcing) and networks and telecommunications,

with major clients in the public and private sector.

Our scope is focused on EA consulting, which has

mostly been oriented to the financial, healthcare and

public sectors.

Our first step was getting to know their EA

processes. To describe those processes, we gathered

information through meetings (1 hour each) with the

consulting area manager, leaving as evidence the

minutes of each one of them. In these meetings, we

uncovered their enterprise architecture processes

already undertaken through documents resulting

from projects and proposals previously made by the

consulting area.

After having the information of the company

processes, we matched them against the activities

proposed by TOGAF, in order to identify which

tasks were completely carried out, which ones were

not and which ones could be most amenable for

knowledge management.

Subsequently, we analysed documents

(proposals and enterprise architecture artefacts),

complemented with informal interviews and direct

observation of the activities carried out to fully

address explicit and tacit knowledge considerations.

3 PROPOSED FRAMEWORK

In this section, we describe how we designed the

knowledge management framework (KMF).

3.1 Why a Framework?

The main task for the design of a KMF is the

definition of its purpose.

The initial premise of this research is to enable

the use and reuse of knowledge. This was motivated

by the aim of speeding up the development of the

initial phases of an EA project in order to generate

knowledge to provide innovation in new proposals

of projects (to reuse knowledge and improve upon

it). After that, we wanted to manage processes of

knowledge generation and its storage. To do this, the

framework was instantiated in a prototype, allowing

its use and validation. With this prototype, the

extraction and dissemination of knowledge were

enhanced. The prototype was structured around the

early stages of TOGAF trying to maintain or

improve delivery times. Indeed, it is important to

note that while reuse, per se, is often a time-saving

strategy, knowledge management activities that

enable such reuse may, by contrast, take up a

significant amount of time, which is partly the

reason why in practice it is not often found to a large

extent.

To meet these goals, first we seek to identify the

elements that generate information, through use of

ontological engineering and other knowledge

management methods, abstracted using the "Ways

of" meta-model (Land et al., 2009). In this meta-

model, we identified the tasks to develop both the

knowledge management framework as well as the

prototype, the way these tasks are modelled, the

languages to be used for development and how to

control the outcome. The complete "Ways of" meta-

model guiding our framework is presented in section

4 of this document.

3.2 Knowledge-generating Entities

The description of the entities associated with

knowledge and learning processes were based on the

case study. In this description, we identified two

components: the first begins with personal

interaction to gather information from face to face

meetings, which may be with the consulting firm or

the client company. The second was focused in the

acquisition and storage of the artifacts generated by

each activity. In table 1 we describe the spaces or

objects used for information generation, which is

associated with the enterprise architecture in the

selected phases (see Table 1).

Knowledge Management Framework for Early Phases in TOGAF-based Enterprise Architecture

Table 1: Enterprise architecture information.

Object

Description

Personal relationship

For the development of the

early stages of TOGAF,

people involved create

efficient communication, but

knowledge is often in

conversations and reuse is

not possible.

E-mail

E-mail as a tool used to

obtain information from

customer or to exchange

information among those

involved in the project.

Previous proposals

We take information from

development of proposals

already made that were

approved or not.

Success cases

Among the projects already

developed, it is important to

identify success stories that

can provide feedback to be

used in future projects. This

will include artefacts

generated in previous

projects, and unrealized

(projects in which the

company made proposal but

were not developed, yet

contain useful information).

Lessons Learned

In each project proposal,

which was developed or not,

the project generates some

lessons learned in order not

to make the same mistakes, if

any.

3.3 Meta-model Framework

To develop the framework, we selected the "Ways

of" meta-model because this is an appropriate way

of abstracting the results of an EA processes,

according to (Land et al., 2009). With this meta-

model, used as a template, we described how the

framework was generated, how it should be used and

how it will be supported by IT elements.

Based on this model, we start by describing the

way of thinking, which shows the understanding of

the domain in which the framework will be applied

in relation to the issues raised. This way helps to

understand how processes can be modelled and to

take a broad view of the solution.

We also include the way of modeling, which

identifies how a process is modeled and what

language is used for it, the activities and tasks of the

framework, as well as identifying the relationship

between them.

The way of working, is the next step, it describes

what tasks are performed in the framework and their

order.

The way of controlling, indicates the tools that

enable monitoring how the framework objectives are

being fulfilled, based on the use of resources.

Finally, the way of supporting determines the IT

that will be used to support the tasks and/or activities

in the framework.

The design of this knowledge management

framework focused on the first two phases of

TOGAF-based enterprise architecture, known as

preliminary and Phase A. Vision Architecture.

These stages were chosen because they are

sequential and are the initial phases of ADM. This

allows developing a knowledge management process

of an enterprise architecture project since its

inception and with often more reusable content than

later stages.

4 A KNOWLEDGE

MANAGEMENT FRAMEWORK

FOR ENTERPRISE

ARCHITECTURE

In this segment, we describe the five “Ways of” that

constitute the framework: thinking, modelling,

working, controlling and supporting.

4.1 Way of Thinking

The “way of thinking” is designed for the first

phases of TOGAF, preliminary and architecture

vision. The aim in the first one (preliminary) is to

build the bases needed in order to start the enterprise

architecture project, that is, in this phase we define

the “where, why, how and who” to build the

architecture. The aim in the second one (architecture

vision) is to define and validate the principles, goals

and strategies of the business. After having this

business information, the next step is to determine

the architecture’s principles (The Open Group,

2011).

Based on (Rus and Lindvall, 2002), the

framework focuses on three main activities: i)

Accessing knowledge (A), ii) Obtaining knowledge

(O) and iii) Sharing knowledge (S). Those activities

are matched against TOGAF’s first and second

phases, as shown in Tables 2 and 3, which shows the

main activities proposed by TOGAF for the

preliminary and vision phasesalong with the

knowledge processes to be managed. Both Table 2

KMIS 2016 - 8th International Conference on Knowledge Management and Information Sharing

and Table 3 use the letters A, O and S, as previously

described.

Table 2: Activities in preliminary phase.

Table 3: Activities in architecture vision.

4.2 Way of Modelling

This framework includes activity modelling through

the BPMN notation. This notation describes the way

current processes are managed; this is needed in

order to use it in the rest of the framework. The

second step of this “Way of modelling” is to classify

knowledge through the ontologies generated from

the information of existing proposals. The modeling

of knowledge through ontologies identifies the

stakeholders who generate, access and use

knowledge. It also identifies the knowledge that

should be managed within the framework, the

artifacts used and/or generated, and the relationship

between them. In addition, ontologies are used to

identify information that must be stored and

displayed within the lessons learned system.

As this project is based on TOGAF’s preliminary

and architecture vision stages, we modelled the

processes in those phases in order to identify those

processes that are susceptible of management within

the KMF. In this way, we could identify if there

were changes on them that could affect current

processes. Unfortunately, given the confidential

nature of some of these processes, they cannot be

explicitly reported.

The third step is taking into account the way in

which knowledge is stored and/or made available.

This is important because the documentation of

every phase of ADM in TOGAF should be classified

and the resulting knowledge must be available easier

and faster for the rest of the process.

4.3 Way of Working

According to the activities identified in TOGAF-

based proposals for EA projects, the “way of

working” has five tasks described below. The first

task is the classification of the architecture principles

used in each project as well as the business

requirements. The classification of the architecture

principles identifies which of those principles can be

reused. This classification also includes the type of

business of the company for which the EA is done,

the size and the scope of the project and if this

project was planned or integrated with other EA

frameworks. These characteristics are transformed

into tags in the classification system. The other

category, the business requirements, allows the reuse

of existing solutions for similar requirement types.

The second task is designed for supporting the

knowledge generation process, taking advantage of

the results of the first task. Here, a classification of

previous completed projects (with varying degrees

of success), as well as proposals not carried out, is

created. To do that, we take into account some

factors (the tags of the classification) like financial

success, development time, best practices, customer

satisfaction, among others. This classification is

supported by the first task. This process supports

knowledge traceability, relating it with the projects

in which it was generated.

The third task is oriented to reusing the

knowledge. In this task, and taking the results of the

first and second tasks as inputs, we identify the

assigned roles for each project in order to know how

they are intervening in each kind of project; in this

way, we can have them on the “work table” for

future projects.

Those tasks describe how the knowledge we

have about projects under development or already

developed is managed within the KMF, but this must

be supported by a process of knowledge capture and

storage, which allows obtaining knowledge in an

orderly manner for subsequent optimal search.

That’s why we define the following two tasks.

The fourth task generates an orderly way to face

the process of knowledge capture, focusing on the

ADM activity in order to know the user company

and to validate its mission, vision and goals. At this

point, we use some of the information generating

objects like emails, the user company web page and

interviews of the members of the company in order

to identify and classify in which project they were

used.

The last task addresses the process of knowledge

storage in order to facilitate its access, taking

Knowledge Management Framework for Early Phases in TOGAF-based Enterprise Architecture

account the typical knowledge flow and maintaining

its quality. Here we take advantage of the

classification of the last task in order to keep the

information generating objects (i.e. codified

knowledge sources) according to their respective

project.

4.4 Way of Controlling

According to (Fairchild, 2002), knowledge

management performance may be placed in the

context of the Balanced Scorecard. As such, they

provide a method to measure the projects done for a

company around the evaluation of four perspectives:

financial, customer, internal processes and

development and learning. This method controls a

knowledge management process based on the

intellectual capital to, in our case, align the strategy

of the enterprise architecture area with the KMF

which is been proposed.

This intellectual capital is monitored from the

employee's perspective (financial perspective) of the

project roles which manage knowledge and the roles

which generate, make available and use knowledge

in order to avoid the creation of personal

dependencies when someone needs access to it. The

customer perspective will be evaluated from the

point of view of successful projects, especially

according to codified factors and executed

proposals. The internal processes perspective in this

case includes the selected phases of TOGAF: the

way in which these phases are currently done, the

way in which we propose do them with the KMF

and the technology (last perspective) will be faced

from the point of view of the KMF’s support in

information technologies tools, which are presented

in the next section. These perspectives may

incorporate specific performance assessment tools,

such as process mining for the internal perspective,

customer satisfaction for customer perspective,

financial performance for the financial perspective

and acceptance and success models (e.g. TAM or

DeLone and McLean) for the learning and

development perspective.

4.5 Way of Supporting

The “way of supporting” of the KMF is about the

instantiation of the framework in a KMS

(Knowledge Management System) prototype. In the

next sections, we describe the tools and resources

used to design and build the prototype.

4.5.1 Definition of KMS

This definition is given by three phases: i) existing

search tools to support the knowledge management

framework and the degree of encoding of the

information within it; ii) identification of tools or

technologies to support the activities described in the

way of working; iii) definition of the system

architecture to provide a reference model for the

KMS implementation.

4.5.2 Existing Tools

According to the case study, we found tools

currently used to support the initial phases of an

enterprise architecture project based on TOGAF.

These tools are presented in Table 4.

Table 4: Existing tools.

Tool

Use description

Search in

company web

page

In the early stages of TOGAF we seek

to understand the company to which

the project of enterprise architecture is

implemented, for that reason, often this

information initially is searched in the

pages of customers. Besides that, we

need to define the use of certain

technologies of information for the

support to the final architecture.

Email systems

Through emails the company requests

and provides information throughout

the process in early stages.

Repository

In the study case, currently the

company has a system for

documentation management supported

on a SharePoint server, but in this

certain documents some there are some

documents without any specification or

order. Additionally, many documents

are also stored for each role in each of

the computers they use.

In these repositories the company has a

series of documents in which the

learned lessons from each project are

reflected, initially during the generation

of the proposal and later in the project.

4.5.3 New Tools or Technologies

In order to understand what kind of tools we needed

in our framework and to comply with the

requirements presented during the meetings with

experts from the area EA of the company, we

searched for tools in order to support the framework

and its validation through the development of a

software prototype. This search allowed us to find

tools to classify information such as tagging,

KMIS 2016 - 8th International Conference on Knowledge Management and Information Sharing

representation of information, lessons learned

systems, and enterprise repositories. Among the

tools that use tags we identified, as an important

characteristic, the need for collaboration between

users to share knowledge through keywords. Such

collaboration allows an enterprise to have a

classification evolve from emergent patterns,

because some users will have more tags than others

(Golder and Huberman, 2006). The use of tagging

can be used by technologies such as "entity linking",

this is used in the framework called UnBWiki.

UnBWiki identify in a text entities and words to get

your relationship automatically (Monteiro et al.,

2015).

Some of these tools can also be visual browsers

such as Yasiv for Amazon (amazon, 2012), weave

(University of Massachusetts Lowell, 2015), Gephi

(“Gephi - The Open Graph Viz Platform,” 2010),

NodeXL (Microsoft, 2015), d3 data-driven

documents (Bostock, 2015). These visual tools gave

us some ideas to represent graphically the obtained

information in the first and second tasks in the way

of working of our framework. The goal is to show

these classifications according to their labels and

easy search.

Finally, we propose lessons learned systems in

the development of the prototype. For instance, the

Knoco System (Knoco, 2014), shows that we can

have services such as design, capture and learning

obtained from the analysis of lessons.

This search helped us to decide that prototype

should not affect the development time of current

EA projects. For this reason, a system of lessons

learned must be generated rapidly at the end of each

project to provide feedback.

4.5.4 Development of a KMS Method

We propose to use ontologies as the principal tool to

the development of KMS that supports the

framework. These ontologies will be made from the

combination of the ontologies development methods

like “Methontology” –it’s a method to generate

ontologies from scratch– (Corcho et al., 2005) and

“On-To-Knowledge” –it’s a methodology to build

systems from ontologies– (Corcho et al., 2006). The

methods have some activities that complement each

other and give dynamic to the project because it

need prototyping and refinement from expert

analysis (Asunción Gómez-Pérez et al., 2004).

4.5.5 KMS Architecture

To define the architecture that will support the

framework, we validated those that are applicable to

the project because of the size and scope of the

initial TOGAF phases and proposed by (Maier,

2007). The architectures proposals were: i) task-

based, ii) centralized and iii) distributed (view table

5).

Table 5: Architectures for KMS.

Architecture

Description

Task-based

This architecture allows

modular KMS from the

context, the articulation of tasks

and processes, through a

workflow, describing and

classifying information sources,

generating information

acquisition, all supported by

good management technologies

information (Maier, 2007).

With the use of this

architecture, we could take

advantage of workflow

management, context, and

resources where the

information comes. It will

enable reuse these information

for the organization.

Centralized

This architecture can be

exploited using a single server

that allows access of

information to all users of the

project, taking account the high

number of customers and of

projects developed and will

develop, (Maier, 2007). This

allows consolidate knowledge

and is useful for knowledge

management of small segments

of the organization, requiring

an infrastructure with high

availability and processing

especially when the

information sources are very

high.

Distributed

It can generate KMS with

direct communication between

each of the members of the

project from a peer-to-peer

approach, where you can have

instant messaging, document

sharing and use of

collaboration tools, but it must

be supported by a systematic

order, which allows reuse of

knowledge.

Knowledge Management Framework for Early Phases in TOGAF-based Enterprise Architecture

5 VALIDATION OF THE

KNOWLEDGE MANAGEMENT

FRAMEWORK FOR

ENTEPRISE ARCHITECTURE

After the framework was designed, we made its

validation with the aim to verify its behaviour in the

process of building a real enterprise architecture.

This validation was made based on (González R. and

Sol, 2012). The actual KMS prototype as a software

tool will be reported elsewhere.

5.1 Construction and Validation of a

Prototype with the Technology

Acceptance Model - TAM

(Varela et al., 2010).

In this phase, we developed a prototype to verify if

the knowledge management of the lessons learned

was possible in a process of EA construction. This

prototype was implemented in the case study

company and we applied a survey that was

developed based on TAM. This survey had the aim

of identifying the utility and ease of use of the

framework, as perceived by the user. These

perceptions helped to identify the attitude towards

use and the use intention.

The prototype is a software that graphically

represents the learned lessons obtained in the

development of enterprise architecture projects.

These lessons are stored and sorted by description,

status, date of generation, phase in which it was

presented and / or project. This storage is done

inside the software through to enter, edit or delete

the lesson’s information. After having lessons, the

software allows filtering them based on each item of

classification. The result of this search is a graphic

relationship between related lessons. For instance,

two lessons generated in the same phase of EA will

be linked. Those links generate a relationship graph

of lessons where each kind of data has a different

color: a link between two lessons generated in phase

A will have a different color than a link of lessons

generated in the preliminary phase. All this helps to

understand what kind of lessons exist and how they

are related inside an enterprise context.

5.2 Enterprise Architecture Experts’

Opinion

During the development of the framework and its

validation, two case study company experts provided

information about real EA projects and gave us

some requirements on knowledge processes. In

addition, they performed a validation of both the

framework and the prototype.

The experts were an engineer, enterprise

architecture senior consultor on the study case

company and a consulting area manager of

enterprise architecture and member of the research

committee of The OpenGroup - Latin America, who

is in charge of the TOGAF’s internalization.

The developed framework was presented to

these two experts and they could use the prototype

too. Their opinions were:

 The knowledge management of the prototype

is really helpful to the company.

 They highlighted the visual facility and the

use facility of the prototype in order to

manage the lessons learned, especially

because it generates a unified structure to

identify best practices and minimizes errors.

Also, this improves the availability and use of

the lessons learned and identifies the lessons

with relationships they have in common in

order to define actions that must be repeated

or mistakes that should not be repeated.

 Having a knowledge management process in

order to access, obtain and share knowledge

systematically enables feedback about the

lessons learned in each of the projects.

 Once you have used the prototype, it is

possible to determine that the use of a KM of

completed or in progress projects are helpful

for starting a new one.

In addition, the framework and its validation

supports the management of knowledge gained in

the development of the selected phases. Also, we

found that once the prototype was used by experts,

the requirements presented by them could be

satisfied without significant additional workload or

time.

6 FUTURE WORK AND

LIMITATIONS

The prototype was designed with two main

limitations. First, the limitation to the two first

phases in TOGAF, and, second, an expert validation

based on potential (not actual) utility.

As future work, we propose the application of

the framework in a full EA project. The next one is

to obtain conclusions not only with expert’s

KMIS 2016 - 8th International Conference on Knowledge Management and Information Sharing

opinions, but also with measurement certain of

indicators set for an EA project. Also, the

framework can be extebnded to other phases of EA

proposed by TOGAF, so that more knowledge

processes can be identified and managed. Finally,

we propose that the KM system use semantic web

technologies to generate knowledge from

documents, text, emails, among other artifacts

developed in previous EA projects.

7 CONCLUSIONS

To identify the knowledge creation in consulting in a

technology company’s projects, focused on

enterprise architecture, we defined which of these

processes are susceptible for knowledge

management, giving to the EA area the chance to

reuse knowledge to their advantage.

Working with an important company of EA

projects, based on TOGAF, as case study for

improving knowledge management we were able to

design, build and validate a knowledge management

framework, using real cases.

This framework supports the generation of

knowledge, in this case for the initial TOGAF

phases, to later retrieve that knowledge that is

valuable for the company and use it to make

decisions in subsequent proposals. This supports a

cycle of knowledge management that allows to

company to know its processes, the way how they

are developed and the way how the company can

implement the framework in order to do the

processes better.

The knowledge processes are improved through

the proposed cycle in the framework, because this

framework organizes the identified knowledge in the

initial phases through tagging and ontology

engineering. This cycle generates, reuses, adds and

stores knowledge, because it is aligned with the

company’s current processes that are in turn defined

by a standard TOGAF framework. These proposed

processes did not generate extra work for the

company because they are embedded in the

“normal” processes; for that reason, we propose the

use of the framework in order to support EA

knowledge management in an orderly and

productive way.

In the end, we learned that studies about KM

must count with a well-defined delimitation to

support its development in order to get an integral

management of the selected processes, because

working with whole organization or all its projects

can bring problems about the specifications for an

KM because of the amount of data, information,

knowledge and/or resources. As to the obtained

results, the KM framework's validation with a

software protoype also enabled potential users, who

are not experts in KM, to understand how

knowledge can be managed in a tangible way,

getting visible results for the organization's EA area.

REFERENCES

amazon, 2012. Amazon Products Visualization - YASIV

[WWW Document]. URL http://www.yasiv.com/

(accessed 5.24.16).

Anajafi, F., Nassiri, R., Shabgahi, G.L., 2010. Developing

effective project management for enterprise

architecture projects, in: 2010 2nd International

Conference on Software Technology and Engineering

(ICSTE). Presented at the 2010 2nd International

Conference on Software Technology and Engineering

(ICSTE), pp. V1–388–V1–393.

doi:10.1109/ICSTE.2010.5608867

Arango Serna, M.D., Londoño Salazar, J.E., Zapata

Cortés, J.A., 2011. Arquitectura empresarial - una

visión general. Rev. Ing. Univ. Medellín 9, 101–111.

Asunción Gómez-Pérez, Mariano Fernández-López, Oscar

Corcho, 2004. Ontological Engineering with examples

from the areas of Knowledge Management, e-

Commerce and the Semantic Web.

Bostock, M., 2015. D3.js - Data-Driven Documents

[WWW Document]. URL https://d3js.org/ (accessed

6.14.16).

Buckl, S., Matthes, F., Schweda, C.M., 2010. Future

Research Topics in Enterprise Architecture

Management – A Knowledge Management

Perspective, in: Dan, A., Gittler, F., Toumani, F.

(Eds.), Service-Oriented Computing. ICSOC/

ServiceWave 2009 Workshops, Lecture Notes in

Computer Science. Springer Berlin Heidelberg, pp. 1–

11.

Corcho, O., Fernández-López, M., Gómez-Pérez, A.,

2006. Ontological engineering: Principles, methods,

tools and languages, in: Ontologies for Software

Engineering and Software Technology. pp. 1–48.

Corcho, O., Fernández-López, M., Gómez-Pérez, A.,

López-Cima, A., 2005. Building legal ontologies with

METHONTOLOGY and WebODE. Lect. Notes

Comput. Sci. Subser. Lect. Notes Artif. Intell. Lect.

Notes Bioinforma. 3369 LNAI, 142–157.

doi:10.1007/978-3-540-32253-5_9

Ernst, A.M., 2008. Enterprise Architecture Management

Patterns, in: Proceedings of the 15th Conference on

Pattern Languages of Programs, PLoP ’08. ACM,

New York, NY, USA, pp. 7:1–7:20.

doi:10.1145/1753196.1753205

Fairchild, A.M., 2002. Knowledge management metrics

via a balanced scorecard methodology, in: Proceedings

of the 35th Annual Hawaii International Conference

on System Sciences, 2002. HICSS. Presented at the

Knowledge Management Framework for Early Phases in TOGAF-based Enterprise Architecture

Proceedings of the 35th Annual Hawaii International

Conference on System Sciences, 2002. HICSS, pp.

3173–3180. doi:10.1109/HICSS.2002.994356

Fiedler, M., Hauder, M., Schneider, A., 2013. Foundations

for the Integration of Enterprise Wikis and Specialized

Tools for Enterprise Architecture Management.

Presented at the Wirtschaftsinformatik, p. 109.

Gephi - The Open Graph Viz Platform [WWW

Document], 2010. URL https://gephi.org/ (accessed

6.14.16).

Golder, S.A., Huberman, B.A., 2006. Usage patterns of

collaborative tagging systems. J. Inf. Sci. 32, 198–208.

doi:10.1177/0165551506062337

González R., R.A., Sol, H.G., 2012. Validation and Design

Science Research in Information Systems 403–426.

Indra, 2014. Indra [WWW Document]. URL http://

www.indracompany.com/

Knoco, 2014. Lessons Learned Services | Knoco Ltd

[WWW Document]. URL http://www.knoco.com/

lessons-learned-introduction.htm (accessed 6.14.16).

Land, M.O. ’t, Proper, E., Waage, M., Cloo, J., Steghuis,

C., 2009. The Results of Enterprise Architecting, in:

Enterprise Architecture, The Enterprise Engineering

Series. Springer Berlin Heidelberg, pp. 49–83.

Lankhorst, M., 2012. Enterprise Architecture at Work:

Modelling, Communication and Analysis. Springer.

Maier, R., 2007. Knowledge Management Systems:

Information and Communication Technologies for

Knowledge Management. Springer.

Microsoft, 2015. NodeXL: Network Overview,

Discovery and Exploration for Excel [WWW

Document]. CodePlex. URL http://nodexl.

codeplex.com/Wikipage?ProjectName=nodexl

(accessed 6.14.16).

Monteiro, L.B., Weigang, L., Saleh, A.A., 2015. An

approach of Vector Space Model to link concrete

concepts with Wiki entities. Presented at the

Proceedings - 15th IEEE International Conference on

Computer and Information Technology, CIT 2015,

14th IEEE International Conference on Ubiquitous

Computing and Communications, IUCC 2015, 13th

IEEE International Conference on Dependable,

Autonomic and Secure Computing, DASC 2015 and

13th IEEE International Conference on Pervasive

Intelligence and Computing, PICom 2015, pp. 313–

320. doi:10.1109/CIT/IUCC/DASC/PICOM.2015.45

Peffers, K., Tuunanen, T., Rothenberger, M.A., Chatterjee,

S., 2007. A Design Science Research Methodology for

Information Systems Research. J. Manag. Inf. Syst.

24, 45–77. doi:10.2753/MIS0742-1222240302

Rus, I., Lindvall, M., 2002. Guest Editors’ Introduction:

Knowledge Management in Software Engineering.

IEEE Softw. 19, 26–38.

Struck, V., Buckl, S., Matthes, F., Schweda, C.M., 2010.

Enterprise Architecture Management from a

Knowledge Management Perspective-Results from an

Empirical Study., in: MCIS. p. 84.

The Open Group, 2011. TOGAF® Version 9.1, an Open

Group Standard [WWW Document]. URL http://pubs.

opengroup.org/architecture/togaf9-doc/arch/

The Open Group, 2009. TOGAF Version 9. The Open

Group.

Tu, F., Yang, C., Xiao, H., Yang, D., 2012. A study on

typical architecture layers of the digital library alliance

based on the enterprise architecture. IEEE, pp. 142–

145. doi:10.1109/ICIII.2012.6339940

University of Massachusetts Lowell, 2015. Weave (Web-

based Analysis and Visualization Environment)

[WWW Document]. URL http://www.oicweave.org/

(accessed 6.14.16).

Varela, L.A.Y., Tovar, L.A.R., Chaparro, J., 2010. Modelo

de aceptación tecnológica (TAM): un estudio de la inf

luencia de la cultura nacional y del perfil del usuario

en el uso de las TIC. 2010 187–204.

KMIS 2016 - 8th International Conference on Knowledge Management and Information Sharing