Reconciling Knowledge Management and Workflow Management
Systems: The Activity-Based Knowledge Management Approach
(Distributed Systems Group, Institute of Information Systems,
Vienna University of Technology, Austria
Abstract: Current trends in collaborative knowledge management emphasize
the importance of inter- and intra-organizational business process support.
Enactment of business processes has primarily been a domain of workflow
management systems. In this paper we propose a hybrid architecture for
reconciliation of knowledge management and workflow management systems
in order to support process participants in organizations, who are increasingly
distributed and need to share and distribute knowledge artifacts. Today
one pressing challenge is to utilize software as to create, share, and
exchange (knowledge) work in collaborative knowledge activities across
locations, while still being business process aware. This paper develops
a conceptual framework, discusses a software architecture, and presents
examples of a software system implementation for activity-based knowledge
management for global project teams.
Key Words: workflow, knowledge management
Organizations face unprecedented competition, forcing them to offer
exceptional levels of service - at whichever stage or sector of the
productive business process they find themselves. As a consequence
organizations need to communicate, collaborate, and coordinate their
(knowledge) work activities, projects, and complex business processes
in real-time [Zeng, 01] and on a global
scale. Knowledge is seen as a critical factor in optimizing corporate
performance. Knowledge work requires the interaction of many
individuals, groups, and project teams. Participants interact and
coordinate their work with others, regardless where they are and what
sort of computer or mobile device they use. Today e-mail is the most
popular application on the Internet and used to exchange ideas,
documents and "knowledge-artifacts" in general. But still it
remains a challenge to manage knowledge-based projects and coordinate
work activities. Whilst systems such as knowledge management (KM) and
workflow management systems (WfMS) are becoming more and more
commonplace, it is still true to say that the links between work
activities, their resources, and communications between the actors are
not recorded in KM systems. An important goal knowledge management
initiatives aim for is to record the history of creation, seamless
access, distribution, and assessment of knowledge work. The
interdependence of IT and information assets have never been greater
than in the area of the new networked global economy. Efficient
technology and communication infrastructure is a key factor to the
success and viability of a modern, flexible, and adaptive
This leads to changing business objectives as well as changing
communication practices. Organizations are forced to: manage and
coordinate their product and service development processes; make their
products and services available as quickly as possible; and to involve
employees, customers, suppliers and partners in different stages of
the business processes. Therefore organizations aim to resolve four
major issues (in some instances with the help of KM systems): (a)
coordination across departments, project groups and their various
responsibilities, and applications; (b) coordination with their
customers, partners, suppliers, distributors, retailers, employees and
even competitors; (c) traceability of knowledge work at all stages of
business processes regardless of location; and (d) adequate
infrastructure to understand, evaluate, and monitor work activities
and processes. The relatively new discipline of Knowledge Management
has arisen as a result of the ongoing search by organizations for
competitive advantage and leverage of their knowledge assets, allied
with the progressive development of information systems. Two different
schools of thought influence the literature on KM. The Japanese
perspective [Nonaka, 98] distinguishes between explicit and tacit
knowledge, and proposes the conversion between the two forms as the
key to knowledge creation. The Western, mainly US view of knowledge is
of a management process, with the systematic storage and retrieval of
information in context.
The contribution of this paper is to present the Activity-based
Knowledge Management approach as a conceptual basis for reconciling
Knowledge Management with Workflow Management Systems. The underlying
proposition of our approach is to associate work activities including
their deliverables (e.g. artifacts) with time and cost related
information with business processes (i.e. workflow instances). In
essence, we think that for knowledge management activities support for
ad hoc processes is crucial and do not aim to model knowledge-based
business processes in advance. This contrasts a more traditional
understanding of Workflow Management Systems. Therefore our approach
focuses more on ad hoc process support rather than on techniques found
in KM literature [e.g. Applehans, 98] and has
more similarities with the approach presented by [Binbasioglu, Karagiannis, 00] and by [Karagiannis, 95]. The remainder of the paper is
organized as follows: Section 2 elaborates on the
conceptual framework for knowledge work activities. This is achieved
by first decomposing knowledge work activities in the next section and
then by presenting a "technology framework" in order to
understand knowledge-based information systems along two orthogonal
dimensions: Knowledge Usage and Knowledge Context. Section 3 discusses the building blocks of
Activity-based Knowledge Management solutions. Section
4 discusses Related Work. Section 5 proposes a
software architecture for enabling process modeling and instantiation
for Activity-based KM systems for global project teams. Section 6 discusses an example of Activity-based
Knowledge Management. Conclusions are finally presented in Section 7.
2 Conceptual Framework for Knowledge-Based Work
Knowledge Management (KM) is often loosely defined in terms of processes,
culture, and ways of communicating. KM, it can be argued, represents the
processes that enable the organization to act, in response to the changing
internal and external environments in which they operate. Drucker (1994)
discusses a "knowledge society" where "knowledge workers"
play a central role and "knowledge-based intangibles" such as
product development know-how being the capital of the future.
In order to understand key functionalities of information systems aiming
to support Knowledge Management Table 1 [Doculabs, 03]
provides an overview of functional categories of KM systems.
||How is knowledge gathered or captured?
What types/formats of information can be gathered (e.g. files from file
servers, intranet pages, Web pages, e-mail, etc.)?
||Who can contribute information to the knowledge base?
Do administrators control the process, or can users actively add information
to the knowledge store?
||Does the system provide ways to categorize the information?
What is the organization taxonomy?
Can information be related/linked with other information (providing context)?
||How is information delivered to users?
Can the system "push" information to users via e-mail or via
What parameters are used to determine the information to be pushed to specific
Does the system allow users to search for information?
Who is allowed to "consume" knowledge?
Can knowledge be shared outside the company (e.g. customers, suppliers,
and partners) to optimize information exchange and processes?
||Does the system allow users to collaborate?
What collaborative capabilities are provided (e.g. discussion databases,
bulletin boards, routing, etc.)?
||Can the system help users analyze the contents of a knowledge
Can the system project the knowledge different users require?
Can the system be used for data mining or analysis?
Can the system be used to generate custom reports that leverage the information
and any relationships in the knowledge base?
Table 1: General Knowledge Management functional categories
There are many framework proposed in the literature focusing on understanding
key functionalities of information systems aiming to support Knowledge
Management [e.g. Applehans, 98; Binbasioglu,
Karagiannis, 00, Doculabs, 03] to name a few.
Some of the proposed categories help us to gain a clear picture as to in
which areas KM systems should provide IT support to organizations. In some
categories KM systems on the market today are not sufficient, but require
interfaces to systems such as workflow management systems, Groupware, or
Project Management (PM) systems.
Advances in the area of Internet Computing, WfMS, and KM are often seen
as substantial for supporting distributed knowledge work. Cooperative knowledge
work in teams is increasing and as a consequence the use of collaborative
KM systems and WfMS are becoming more pervasive. WfMS have been defined
as "technology based systems that define, manage, and execute workflow
processes through the execution of software whose order of execution is
driven by a computer representation of the workflow process logic"
[WfMC, 95]. To fully understand the context of collaborative
technologies for organizations it is important to first analyze the dimensions
of current systems. In this paper our model to analyze collaborative technologies
distinguishes two dimensions: Knowledge Usage and Knowledge Context as
shown in Figure 1. Knowledge Usage is about the "paradigm"
knowledge is used. In its simplest form knowledge is only retrieved. The
next stage allows retrieval and sharing of knowledge. The following stage
enables users to create workspaces by organizing knowledge artifacts using
files and folder hierarchies. The distribution stage enables knowledge
workers to distribute knowledge artifacts (objects) by using push/pull
mechanisms. Finally the link stage allows retrieval, sharing, workspaces,
distribution, and in addition allows links between all knowledge artifacts.
The second dimension Knowledge Context reveals contextual information on
knowledge artifacts. Generally we can say that the higher contextual information
is the more process awareness is stored together with knowledge artifacts.
In its simplest stage it allows auditing of knowledge artifacts. For example
users may view timestamp information on creation and routing of artifacts.
The second stage enables organizational modeling, i.e. to define persons,
roles, departments, and other organizational constructs required to design
organizational structure. Organizational models allow organizations to
define a set of access rights and rules for artifacts. The third stage
additionally enables process modeling. Process tracking enables administrators
to view the progress of business processes and the progress of activities
as the building blocks of processes. Finally Reporting and Analysis supports
analysis of all previously explained stages, and statistical comparisons
We find it useful to relate technologies on the market today to those
two dimensions in order to elaborate our proposed Activity-based KM approach.
Groupware systems usually provide very low knowledge context information
but provide relatively high knowledge usage capabilities, since they enable
users to retrieve, share, organize their work in workspaces, and to distribute
artifacts. An example of a system also supporting linkage of knowledge
artifacts will be presented in section 4. Document
Management systems are increasingly integrated with WfMS as recent mergers
demonstrate (e.g. Lotus Notes/OneStone). Project management (PM) software
is still mostly viewed as a software for individuals (i.e. project managers)
and rarely offers collaborative or business process aware solutions. Moreover,
in most cases PM software is not integrated with corporate information
systems and in fact is only utilized as a graphical modeling tool for outlining
tasks. Most Knowledge Management systems on the market today are workspace-centered
and provide only very simple forms to model organizational structures (e.g.
using roles only, but not skills). It is interesting to note that nearly
no KM system provides interfaces to business process modeling and enactment
systems (the domain of WfMS). Most KM-systems enable users to retrieve
knowledge artifacts from repositories, but rarely allow distribution and
process awareness (see section 3 for examples).
A modeled business process such as "customer order entry"
can be modeled using a WfMS. However a modeled process can only be enacted
(instantiated) as it was designed. If an exception occurs, a workflow administrator
needs to re-model the process before the execution can continue. This limits
the usability of WfMS in a world where constant adaptation to new situations
is necessary and where teams are increasingly mobile and distributed. An
example of an ad-hoc process is discussion of a project's design review
using e-mail (Groupware). Workflow management systems are typically organizationally
aware because they contain an explicit representation of organizational
processes. In recent years there has been considerable attempts to merge
workflow and knowledge management technologies [Dayal,
01]. Industrial research labs [Chen, 01] and
product teams [Dustdar, 02; 04]
have made significant steps forward. A WfMS can impose a rigid work environment
on users, which often has a consequence. One example is among users who
perform time-consuming manual "work arounds"; the consequence
is lower efficiency and dissatisfaction with the system. Workflow automation
provides unique opportunities for direction information flow and monitoring
work performance. As a consequence WfMS enable continuous loops of sub
processes such as goal setting, working, monitoring the work, measuring
performance, recording and analyzing the outputs and evaluating the "productivity"
of personnel. Users of WfMS often consider the controlling and monitoring
possibilities as a "dark side" of these systems, which results
in demotivating employees. A business process has well defined inputs and
outputs and serves a meaningful purpose either inside or between organizations.
Business processes and their corresponding workflows exist as logical models.
When business process models are executed they have specific instances.
When a workflow is instantiated the whole workflow is called a work case
[WfMC, 95]. The WfMS enacts the real world business
process for each process instance. A business process consists of a sequence
of activities. An activity is a distinct process step and may be performed
either by a human agent or by a machine. Any activity may consist of one
or more tasks. A set of tasks to be worked on by a user (human agent or
machine) is called work list. The work list itself is managed by the WfMS.
The WfMC calls the individual task on the work list work item [WfMC,
95]. To summarize, a workflow is the instantiated (enacted or executed)
business process, either in whole or in parts. During enactment of a business
process documents, which are associated to tasks are passed from one task
participant to another. In most cases this passing of documents or executing
applications is performed according to a set of rules. A WfMS is responsible
for control and coordination such as instantiating the workflow, assigning
human or non-human agents to perform activities, generating worklists for
individuals, and routing tasks and their associated objects such as documents
between the agents. For an in-depth discussion on WfMS we refer to e.g.
Bussler in [Bussler, 99].
Research shows that team performance is positively affected by communications
between team members, as shown in [McDonough, 99].
Literature stresses the importance of the formal and informal communicative
aspects of collaborative systems, which reflect the underlying structural
dependencies in work settings [McDonough, 99]. Working
in organizations is often characterized as "networks of commitments,"
as people in the organization send work through the systems [Winograd,
86]. Figure 1 suggests that KM systems of moving
from currently being mostly "retrieval" oriented towards "collaborative"
direction and on the business process spectrum some KM systems strive to
support the spectrum of ad-hoc business processes and modeled processes
as depicted in Figure 1.
Figure 1: Technology Framework
3 Foundations of Activity-Based Knowledge Management
Knowledge can be viewed as information enriched with context. With context
we mean information about the "who, when, how, and why". As an
example, consider an "Explorer"-like view on a file system. This
view allows the person to see documents (artifacts) stored inside folders.
The name of such folders might reflect project names themselves. The mentioned
view on these documents does not contain further contextual information
on what a person (yourself, or others) actually have to do (did) with it
(e.g. create another document, send an e-mail to customer, call partner
organization, etc.). For example if the person in the above example needs
to see who actually received a document stored in any given (project) folder,
he is required to manually retrieve his e-mail box in order to find this
information. This simple example shows that links between artifacts, such
as documents or database information, and activities performed by persons
are usually not stored in information systems such as KM or WfMS. However
this linkage is of paramount importance for knowledge-intense business
processes in order to provide contextual information on knowledge artifacts
for processes such as new product development, which cannot be modeled
using a WfMS. We propose activities as an important building block for
reconciliation of KM systems and WfMS. Activities have multiple relationships
with other entities highly relevant to information systems dealing with
knowledge work, as depicted in Figure 2. Activities
require resources (e.g. persons), documents, time, and deliver deliverables.
Resources are required to perform activities. Those resources used for
activities generate costs. The same applies to the time required to perform
activities: it generates costs.
Figure 2: Activities and their relationships
4 Related Work
There has been a lot of work on classification models for collaborative
systems, however, no "one and agreed upon" taxonomy of analyzing
and understanding collaborative systems has been proposed so far. Academia
and industry suggest various classification schemes. In industry for example,
people frequently use the term e-mail and groupware interchangeably. More
generally, there is the tendency to classify categories of collaborative
systems by naming a product (e.g. often many use the term Lotus Notes and
Groupware interchangeably). Academic research has suggested many different
classification models. For a recent extensive survey of collaborative application
taxonomies see [Bafoutsou, Mentzas, 02]. [DeSanctis,
Gallupe, 87], Ellis, Gibbs and Rein [Ellis et al,
91] and [Johansen, 88] suggest a two dimensional
matrix based on time and place, where they differentiate between systems'
usage at same place/same time (e.g. electronic meeting rooms), same place/different
time (e.g. newsgroups), different place/different time (e.g. workflow,
e-mail), different place/same time (audio/video conferencing, shared editors).
This classification model helps to easily analyze many tools on the market
today; however, it fails to provide detailed insights on collaborative
work activities themselves as well as their relationship to business processes.
[Ellis, 98] provides a functionally oriented taxonomy
of collaborative systems, which assists in understanding the integration
issues of workflow and groupware systems and is shown in Table 2.
||Shared workspace, Database
||Access control, artifacts versioning, backup, recovery,
and concurrency control.
||Supports explicit communications between participants.
||Coordination and Organizational Model
||Handles the ordering and synchronization of activities.
||Agent (Application or User-Interface agents)
||Provide domain-specific functionalities, such as a meeting
Table 2: Collaborative systems taxonomy
The classification system of Ellis [Ellis, 98]
provides a framework to understand the characteristics of collaborative
systems and their technical implementations. The first category (Keepers)
provides those functionalities related to storage and access to shared
data (persistency). The metaphor used for systems based on this category
is a "shared workspace". A shared workspace is basically a central
repository where all team members put (upload) shared artifacts (in most
cases documents) and share those among the team members. Technical characteristics
of "keepers" include database features, access control, versioning,
and backup/recovery control. Popular systems examples include BSCW [Bentley
et al., 97], IBM/Lotus TeamRoom and the Peer-to-Peer workspace
system Groove [Groove, 02]. The second category
(Communicators) groups all functionality related to explicit communications
among team members. Basically this boils down to messaging systems (e-mail).
Its fundamental nature is a point-to-point interaction model, where team
members are identified only by their name (e-mail address) and not by other
means (e.g. by skills, roles or other constructs, as in some advanced workflow
systems). The third category (Coordinators) is related to ordering and
synchronization of individual activities that make up a whole process.
Examples of Coordinator systems include workflow management systems. Finally,
the fourth category (Team-Agents,) refers to (semi-)intelligent software
components that perform domain-specific functions and thereby help the
group dynamics. An example for this category is a meeting scheduler agent.
Most systems in this category are not off-the-shelf standard software.
Both evaluation models presented above provide guidance to virtual teams
on how to evaluate products based on the frameworks. Current systems for
virtual teamwork have their strength in one or two categories of Ellis'
framework. Most systems on the market today provide features for Keepers
and Communicators support or are solely Coordinator systems (e.g.
Workflow Management Systems) or are Team-Agents. To the best of
our knowledge there is no system integrating at least three of the above
categories in one system. In the following section we evaluate current
collaborative systems categories for their usage in virtual teams and summarize
their shortcomings in respect to the requirement for virtual teamwork.
4.1 Evaluation of Collaborative Systems
Cooperative tasks in virtual teams are increasing, and as a consequence
the use of collaborative systems is becoming more pervasive. In recent
years it has increasingly become difficult to categorize systems according
to the frameworks discussed above, since systems boundaries have become
increasingly fuzzy and due to recent requirements for virtual teamwork.
Traditional systems in the area of interest to virtual teamwork are groupware,
project management (PM) and workflow management systems (WfMS). The mentioned
system categories are based on different "metaphors". Groupware
systems mainly can be categorized along two lines (metaphors), namely the
communications or workspace metaphor.
Communications-oriented groupware supports unstructured work
activities using communications as the underlying interaction pattern.
One very popular instance of communications-oriented groupware is e-mail.
When e-mail is used as the main medium for virtual teams (as in most cases),
data and associated information (such as attachments) remain on central
mail servers and/or personal inboxes without any context information in
which those email communications were used (involved business processes,
performed activities, created artifacts as described above). Enterprise
groupware systems are generally focused on enterprise-wide messaging and
discussion databases and do not support organizational components and structures
such as people and their associated roles, groups, task, skills, etc. This
leads to "organizationally unaware" systems treating all messages
alike (semantically) and without any awareness of underlying business processes,
which are essential for efficient collaboration in project teams.
Workspace-oriented groupware, on the other hand, allows team
members to upload/download artifacts using files and folders to organize
their work. Groupware, as indicated above, usually does not implement an
underlying organizational model (i.e. providing information on the structure
of a team such as team members and their roles, skills, tasks, and responsibilities).
The lack of explicit organizational "structuring" is a disadvantage
as well as an advantage at the same time. It is disadvantageous because
traditional groupware has no "hooks" for integrating business
process information, which is important in order to integrate artifacts,
resources, and processes. This will be discussed in more depth in the next
section. The advantage of the lack of explicit organizational structure
information is the fact that such systems may be used in all organizational
settings without much prior configuration efforts on the one hand and secondly
this leads to increased personal flexibility, as the proliferation of e-mail
systems in teamwork demonstrate.
The second category, which we will briefly investigate in this
section are project management systems (PM). As we have stated
above virtual teamwork is in most cases organized as project
work. Projects have well defined goals and are defined by their
begin and end dates as well as by the required resources
and their tasks (work breakdown structure). It is interesting to note
however, that PM systems traditionally support the work of the project
manger as the main (and only) user of the PM system. They do not
support dynamic interaction (instantiation) of processes. More
recently, project management systems combine with information sharing
tools (shared workspaces) to provide a persistent storage for
The enactment of the task by team members, as defined by the project
manager, is not supported by PM systems. In other words we can conclude
that PM systems are not geared towards virtual teamwork but focused more
on the planning aspect. They provide "static" snapshots (usually
in the form of GANNT charts) of projects and how they "should"
be. There is no support for the work activities performed by the virtual
The purpose of workflow management systems is to support the
notion of processes within and in some cases between organizations [e.g.
Aalst and Kumar, 01]. A business process can be
unstructured (ad-hoc), semi-structured, or highly structured (modeled).
For example a business process such as "customer order entry"
can be modeled using a traditional WfMS. However highly structured
processes can only be enacted (instantiated) as they were designed. If
an exception occurs, a workflow administrator needs to re-model the process
before the execution can continue. This limits the usability of WfMS in
a world where constant adaptation to new situations is necessary and where
teams are increasingly mobile and distributed. An example of an ad-hoc
process is discussion of a project's design review. A semi-structured
process consists of groups of activities, which are modeled; however in
contrast to a structured (modeled) process it may also consist of activities,
which are not pre-defined. A process is semi-structured, when there might
be one or more activities between already modeled activities such as assign
process, which are not known beforehand and therefore cannot be modeled
in advance. Most WfMS distinguish models of a business process (build time)
and their enactment (run time). For a comprehensive study of Workflow products
and their characteristics see [Aalst, Hee 02]. For
a detailed discussion of WfMS-shortcomings, e.g. unclear semantics of Workflow
control patterns see [Aalst et al., 03]. The often
required modeling of workflows before enactment, as well as their unclear
modeling semantics, frequently lead to substantial inflexibility for virtual
teams. In (cross-organizational) virtual teams "exceptions are the
rule", therefore modeling a process (project) is often not possible
for creative, innovative virtual teams of knowledge workers such as in
product development or consulting teams, as our small motivating scenario
presented above, indicates.
To our knowledge, traditional groupware and workflow management systems
do not support the requirements outlined above (see e.g. [Bafoutsou,
Mentzsa, 02]. Most groupware systems follow a "workspace"
metaphor, which allows users to upload/download artifacts using files and
folder to organize their work. When e-mail is used as the main medium for
project teams (as in most cases), data and associated information (such
as attachments) remain on central mail servers and/or personal inboxes
without any context information in which those email communications
were used (involved business processes, performed activities, created artifacts
as described above). Enterprise groupware systems are generally focused
on enterprise-wide messaging and discussion databases and do not support
organizational components and structures such as people and their associated
roles, groups, task, skills etc. This leads to "organizationally unaware"
systems treating all messages alike (semantically) and without any awareness
of underlying business processes, which are essential for efficient collaboration
in project teams.
To summarize: The requirements for virtual teams cannot simply be met
by loosely coupling traditional workflow and groupware systems, which are
based on different metaphors and goals. To summarize, we suggest that an
integrated Workflow and Groupware system needs to (i) provide organizational
constructs (persons, roles, skills, groups, tasks) in order to flexibly
model an organizational structure and responsibilities of virtual teams;
(ii) provide constructs for modeling generic tasks and associated document-templates
or applications in order to enact them for particular team members; (iii)
provide the means to graphically model a control flow for business processes
at a high level of abstraction (granularity); (iv) allow cross-organizational
process enactment with ad-hoc processes (without modelling) and analysis
of interaction patterns between team members; and (v) allow integration
(and communications-references) of database repositories as an important
resource for artifact management.
Our goal for the next section is to distil the above requirements of
(cross-organizational) virtual teams into a systems-architecture and present
our design goals and to outline architectural considerations of Caramba
[Caramba Labs 04; Dustdar, 04].
5 Architectural Issues
In the following section we will provide an overview of
architectural issues we are concerned with while designing an
activity-based KM system called Caramba [Caramba
Labs, 2004]. An in-depth presentation of the architecture or the
software itself is beyond the scope and focus of this paper. However,
we will discuss relevant issues based on our proposed activity-based
KM approach in this section. Software prototype development began in
1997 and it evolved into a commercial product, which has been launched
in 2001. Software architectures typically include the description of
components, connectors, and configurations [Perry, 92; Shaw, 96]. For
this it is important to decompose a system into a well-defined set of
components that have clear responsibilities [Parnas,
72]. Since architectures in the KM and WfMS area have to cope with
and to integrate with various information systems installed in
organizations we decided to strive for a middleware style rather than
a classical client-server style. The following descriptions will point
out the respective architectural style used in a particular layer or
component. The Caramba software architecture [Dustdar, 04] is composed of multiple layers:
middleware, client suite, and a persistence store. Objects and
services are accessed through the Transparent Access
Layer (TAL) from the CarambaSpace platform (middleware).
Depending on access mechanisms and the requested services (e.g. via
Java client with RMI protocol or via Web browser with http), Caramba
provides a unique way to handle requests using a meta model framework
to describe content and separating presentation, logic and data. This
model permits high flexibility, enables customization, and extensions
as well as the adoption of new devices or technologies. The goal of
this layer is to offer transparent access to a CarambaSpace. The TAL
utilizes various services to transform, describe, manipulate and
observe objects. All objects managed through a CarambaSpace are well
described using a meta model description framework. Objects can be
customized in their structure (e.g. adding columns to tables, adding
relations to objects) and their presentation by adopting their meta
model description. Any changes are dynamically reflected by client
components. Based on the meta model description framework Caramba
enables various options to customize data and content and to integrate
data from different resources (e.g. corporate databases).
This layer also provides facilities for fine-grained object notification
services and the implementation of customized services based on object
observers. The middleware does not manage states and persistence of objects.
Objects are stored, manipulated, and retrieved via the Persistence
Layer (PEL). Caramba leverages and adopts standard Java based technologies
(e.g. JDBC, JNDI, HTTP, etc.) to access and integrate data. Figure 3 depicts
an overview of the conceptual architecture.
Figure 3: Conceptual Architecture
6 Activity-Based KM Component - An Example
The activity-based knowledge management component (ObjectCenter) will
be presented in this section. The goal of this component is to provide
a mechanism to link activities with artifacts, as discussed in section
3. Based on the metamodel discussed above, Caramba provides a set of
organizational objects: Persons, Roles, Groups, Skills, Units, Organization,
Tasks, and Documents (i.e. Templates). Utilizing these organizational
constructs an administrator is able to model any organizational structure,
such as hierarchical, flat, or matrix. Each object class consists of attributes
describing the object. The object class Persons contains attributes
about the Person such as name, address etc. The object class Roles
allows definition of organizational roles such as "Head of IT".
The object class Group defines project settings such as "Product
Team IT-Solutions". Skills enable definition of required skill
sets such as "Certified Java Developer". Units describe
permanent departments such as "Marketing". The ObjectCenter provides
means (by drag & drop) to link the rows of object classes with each
other, as depicted in Figure 4.
It allows users to view relationships between who (organizational
constructs) is performing which activities (Tasks) and using what
(Documents), as shown in Figure 5. In fact, the ObjectCenter
and the MatrixEditor enable project team members to view actual relationships
between any of Caramba's object classes in an easy manner. In global project
team settings it is of paramount importance to allow "location aware"
queries, such as "show all project team members with Java-Skills (Organizational
construct) located in Vienna".
In this case the project team member has to narrow down his query by
using the Operator contains "Vienna" applied to the
Attribute "Location" (MatrixEditor). System administrators may
even add organizational object classes (named "Organizational"
inside the ObjectCenter) to suit their global project requirements. They
may do this by editing the metamodel of Caramba. One example is that, as
in global project teams cultural issues are very relevant, the project
team would like to add a new organizational object class named "culture
portfolio" to the list of managed object classes. This object class
stores "cultural variables" and may be linked to Persons or Groups
(or any other customized object classes). For example the global project
team could agree to store Hofstede's dimensions [Dustdar,
Hofstede, 99] such as power distance, individualism, masculinism, uncertainty
avoidance, and long-term orientation. The goal in this case is to provide
means to describe required cultural variables in order to be successful
in a certain project team setting. The ObjectCenter can be utilized in
order to link and to store Persons, their Roles, Skills, etc. (all object
classes in the Organizational constructs tree) with customized objects
(e.g. cultural variables discussed above). This is one example of how the
Activity-based KM component can to be expanded and customized for global
and "culture-sensitive" project team settings.
In order to fulfil one of the main goals of a reconciled KM and WfMS,
Caramba supports modeling of business processes and their enactment by
implementing a workflow engine (Process Modeler), utilizing the information
presented in the section above (ObjectCenter), using tasks and their associated
organizational constructs in directed graphs.
Figure 4: ObjectCenter
Figure 5: MatrixEditor
This paper outlines the requirements to reconcile knowledge management
and workflow management systems in order to provide business process awareness
to knowledge artifacts. The Activity-based Knowledge Management approach
presented here enables knowledge workers to link knowledge artifacts such
as documents (format independent) or database entries to activities performed
by human actors. These hyperlinks between artifacts and process activities
enacted by people are currently not implemented by traditional Knowledge
Management systems. We believe that the Activity-based approach to Knowledge
Management provides a solid foundation for reconciliation of Knowledge
Management and Workflow Management Systems. In this paper we argue that
activities performed by persons need to be linked to knowledge artifacts
in order to provide process awareness and -support to KM systems. A software
architecture and implementation is presented in order to show the viability
of our concepts.
[Aalst et al., 03] W.M.P. van der Aalst, A.H.M.
Hofstede, B. Kiepusziewski, A.P. Barros, Workflow Patterns, Distributed
and Parallel Databases, 14(3), pp. 5-51, 2003.
[Aalst, Hee, 02] W.M.P. van der Aalst, K. Hee,
Workflow Management: Models, Methods, and Systems, MIT Press, Cambridge,
[Aalst, Kumar 01] W.M.P. van der Aalst, A. Kumar,
A reference model for team-enabled workflow management systems. Data &
Knowledge Engineering 38 (2001), 335-363, 2001.
[Applehans, 98] W. Applehans, A. Globe, G. Lugero,
Managing Knowledge: A Practical Approach. New York: Addison-Wesley 1998.
[Bafoutsou, Mentzsa, 02] G. Bafoutsou, G. Mentzsa,
Review and functional classification of collaborative systems. International
Journal of Information Management 22 (2002), pp. 281-305, Elsevier Science,
[Bentley et al., 97] R. Bentley, W. Appelt, U.
Busbach, E. Hinrichs, D. Kerr, K. Sikkel, J. Trevor, G. Woetzel, Basic
support for cooperative work on the World Wide Web, International Journal
of Human-Computer Studies, 46, pp. 827-846, 1997.
[Binbasioglu, Karagiannis, 00] M. Binbasioglu, D.
Karagiannis, A System for Supporting Organizations in Knowledge-Based Document
Preperation. Information Systems, 25/6-7, pp. 453-463, 2000.
[Bussler, 99] C. Bussler, Enterprise-wide Workflow
Management. IEEE Concurrency 7 (3), 32-43.
[Caramba Labs, 04] Caramba Labs Software AG, http://www.CarambaLabs.com
[Chen, 01] Q. Chen, M. Hsu, U. Dayal, Peer-to-Peer
Collaborative Internet Business Servers. HP-Labs Technical Working Paper
[Dayal, 01] U. Dayal, M. Hsu, R. Ladin, Business
Process Coordination: State of the Art, Trends, and Open Issues. In Proceedings
of the 27th VLDB Confererence, Roma, Italy, 2001.
[DeSanctis, Gallupe, 87] G. DeSanctis, R.
B. Gallupe, A foundation study of group decision support systems."
Management Science, 23(5), pp. 589-609, 1987.
[Doculabs, 03] Special Report on Knowledge Management
Products A Doculabs Software Analysis Report 2003. Chicago, IL.
[Drucker, 94] F. Drucker, Post-Capitalist Society.
New York: Harper Business, 2004.
[McDonough, 99] E.F. McDonough, K.B. Kahn, A. Griffin,
Managing Communication on Global Product Development Teams. IEEE Transactions
on Engineering Management 46, 375-386, 1999.
[Doculabs, 03] Special Report on Knowledge Management
Products, A Doculabs Software Analysis Report. Chicago, IL, 2003.
[Dustdar, 04] S. Dustdar, Caramba - A Process-Aware
Collaboration System Supporting Ad Hoc and Collaborative Processes in Virtual
Teams, Distributed and Parallel Databases, 15:1, 45-66, Kluwer Academic
Publishers, Special Issue on Teamware Technologies, January 2004
[Dustdar, 02] S. Dustdar, Mobility of Context for
project teams. Proceedings of the International Workshop on Mobile Teamwork
at the 22nd International Conference on Distributed Computing Systems (ICDCS
2002), July, IEEE Computer Society Press.
[Dustdar, Hofstede 99] S. Dustdar, G. Hofstede,
Videoconferencing across cultures - a conceptual framework for floor control
issues. Journal of Information Technology, 14, pp. 161-169, 1999.
[Ellis et al., 91] C.A. (Skip) Ellis, S.J. Gibbs,
G.L. Rein, Groupware: Some issues and experiences." Communications
of the ACM, 34(1), 1991.
[Ellis, 98] Ellis, C.A. (Skip), A Framework and
Mathematical Model for Collaboration Technology, in. Coordination Technology
for Collaborative Applications - Organizations, Processes, and Agents (Conen
and Neumann, Eds.), Springer Verlag, pp.121-144, 1998.
[Groove 02] Groove Networks (2002), http://www.groove.net
[Johansen, 88] R. Johansen, Groupware. Computer-support
for business teams. The Free Press. New York, 1988.
[Karagiannis, 95] D. Karagiannis, L. Marinos, Integrating
Engineering Applications via Loosley Coupled Techniques: A Knowledge-Based
Approach, Expert Systems With Applications, 8, 2, pp. 303-319, 1995.
[Nonaka, 98] I. Nonaka, H. Takeuchi, Knowledge-Creating
Company: How Japanese Companies Create the Dynamics of Innovation. Oxford:
Oxford University Press, 1998
[Parnas, 72] D.L. Parnas, On the criteria to be
used in decomposing systems into modules, Communications of the ACM, 15(12),
[Perry, 92] D.E. Perry, A.L. Wolf, Foundations
for the study of software architecture. ACM SIGSOFT Software Engineering
Notes, 17 (4): 40-52, 1992.
[Shaw, 96] M. Shaw, D. Garlan, Software architectures,
perspectives on an emerging discipline. Englewood Cliffs, NJ: Prentice-Hall,
[WfMC, 95] Workflow Management Coalition - Workflow
Management Specification: http://www.wfmc.org/standards/docs/tc003v11.pdf
[Winograd, 86] T. Winograd, F. Flores, Understanding
Computers and Cognition. Norwood, NJ: Ablex, 1986.
[Zeng, 01] L. Zeng, B. Benatallah A.H.H. Ngu, On
demand business-to-business integration. In Proceedings CoopIS 2001, 403-714,
Computer Science Lecture Notes, Heidelberg: Springer.