How can Knowledge Technologies become Agile? An...

How can Knowledge Technologies become Agile? An Explorative Investigation and a Morphological

Framework

Technical Report

Markus Strohmaier1, Eric Yu2

1 University of Toronto, Department of Computer Science and Know-Center [email protected]

2 University of Toronto, Faculty of Information Studies

[email protected]

1 Motivation

The emergence of information and knowledge technologies at the end of the last century has enabled workers and organizations to communicate, collaborate, access information and to participate in knowledge generation and transfer across temporal and spatial boundaries. Knowledge technologies provide support for knowledge workers in knowledge intensive processes on different levels, distinguishing themselves from information technologies by integrating the notion of meaning and semantics [Rigau et al. 2002]. In order to provide support, knowledge technologies typically utilize ontological models based on languages such as BPMN, BPEL, SCORM, LOM and, on a more technical level, Petrinets, OWL, RDF, WRL and others. Examples include Workflow Management Systems [Hollingsworth 1995], Process-Aware Information Systems [van der Aalst et al. 2006] and Ontology-based Knowledge Management Systems [Fensel 2002]. Ontological models provide formal semantic information that enables the application of, for example, semantic search algorithms and automated reasoning. However, development of ontological models is typically expensive, making high upfront investments in knowledge engineering necessary (using, for example, approaches such as [Schreiber et al. 2002]). In dynamic environments, ontological models need to evolve in order to maintain their practical utility. Drivers coercing such changes include, among others, competition, customers, technology itself, or social factors [Conboy and Fitzgerald 2004]. As a consequence, ontological models need to be extended, merged, aligned and mapped – which raises problems such as language level mismatches, ontology level mismatches, practical problems and problems related to model versioning [Klein 2001], which in turn impairs the capability of knowledge technologies to deal with change swiftly and adequately. Agility has caught the attention of researchers and practitioners as a quality attribute that promises to enable systems to successfully deal with dynamics and complexity

2 Authors

on different levels. Existing research includes work on the agility of model and ontology development [Ambler 2006, Mirzaee et al. 2005], agility of software development [Abrahamsson 2002], agility of specific processes and knowledge technologies ([Holz and Maurer 2003, Holz et al. 2003]) and agility of IT landscapes in organizations [Stolze et al. 2005]. However, the notion of agility, unlike other quality attributes of systems such as flexibility, modularity or adaptability, lacks an intuitive meaning in many contexts. As a consequence, the term lacks an accepted definition and is often used ambiguously, domain-specifically and referring to different and even conflicting meanings. Therefore, the aim of this work is to analyze, organize and investigate the dispersed work on agility as a basis for understanding agility in the context of knowledge technologies. This contribution therefore strives to find answers to the following three questions: “What characterizes agility?”, “How does agility relate to other quality attributes, such as flexibility, adaptability, or modifiability?” and “What does agility mean in the context of knowledge technologies?”. In order to answer these questions, we present an analytical instrument for identifying, understanding and assessing agility in different contexts. After that, we aim to apply this knowledge from different contexts to one specific domain: understanding agility as a quality of knowledge technologies. The results of this analysis will help researchers and practitioners to: 1) understand agility as a quality attribute of knowledge technologies on different

levels 2) identify relationships and potential synergies between fields of research that are

hardly connected presently 3) explore and identify new applications for agile concepts

2 Knowledge Technologies

Knowledge technologies have been defined by the EU IST-FP6 as a vision of ambient intelligence, in which "people will be surrounded by intelligent and intuitive interfaces embedded in everyday objects around us and an environment recognising and responding to the presence of individuals in an invisible way". The ISTAG1 has “identified context- and semantic-based systems as key enabling knowledge technologies, including content-based image retrieval, Semantic Web, Knowledge GRID, Digital content management, Ontologies and Knowledge Management”2. Concrete applications of knowledge technologies include workflow management systems [Hollingsworth 1995], knowledge management systems [such as Hyperwave, Opentext], decision support systems [Hersh 1999] or learning systems [Mayer et al. 2005]. The roles of and uses for models in the context of knowledge technologies are twofold: Models can be used during design- [MC 2006] as well as during runtime [MRT 2006]. Problems with knowledge technologies that were identified by past research efforts include the necessity for manually building large ontological models that require dozens of person-years for development [Rigau et al.

1 The Information Society Technology Advisory Group: http://cordis.europa.eu/ist/istag.htm 2 http://cordis.europa.eu/ist/ka3/iaf/iaf-kt-fp6.htm, last accessed on July 19th, 2006

How can Knowledge Technologies become Agile? An Explorative Investigation and a Morphological Framework 3

2002]. The static and rigid nature of these models, together with a lack of comprehensiveness and scalability [Rigau et al. 2002] demand new approaches for knowledge technologies that are able to deal with change on different levels. As a consequence, issues of model transformation, maintenance and evolution gain importance [MT 2006]. Approaches for dealing with increasing dynamics in ontological models are already on their way, and include collaborative ontology development instruments such as ontology editors with collaborative functionality [Sure et al. 2002] or wiki-based approaches [Hepp et al. 2006]. Approaches from the area of knowledge discovery and knowledge mining are used to eliminate the need for humans in the ontology development process by utilizing algorithms for ontology construction [Craven et al. 1998]. In addition, ontology mapping and mediation aims to increase reuse of ontologies [Klein 2001]. As evident in this brief review, dealing with increasing dynamics represents a central challenge for knowledge technologies. Existing research on agility as a new quality of systems promises to introduce techniques and strategies for preparing systems to successfully deal with change in their environment. As a consequence, this work aims to investigate how the notion of agility can contribute to increasing the ability of knowledge technologies to deal with change.

3 Research Approach

Contemporary and interdisciplinary phenomena, such as agility, are often addressed by young and emergent research areas that lack theoretical foundation. Such lack of theoretical foundation and the novelty of these phenomena hinder quantitative investigations, and demand conceptual research approaches that contribute to the development of models and conceptualizations [Remus 02]. These models and conceptualizations are expected to increase understanding about and the degree of structure within the domain in question. This work utilizes two basic approaches to address this challenge: Case study research [Yin 1984] and morphological analysis [Ritchey 2005]. Case study research represents a useful research approach for 1) investigating a contemporary phenomenon within its real-life context where 2) the researcher has little or no control over behavioural events and 3) the research questions are of descriptive, explanatory, or exploratory nature [Yin 1984]. Agility represents such a phenomenon that is contemporary and currently hard to separate from the context in which it is discussed (for example: agile methods [Abrahamsson et al. 2002] or agile manufacturing [Sarkis 2002, Gunasekaran 1998, Dove 1996]). Morphological analysis is assumed to be especially useful for 1) examining all different configurations possible in a field of interest and 2) discover new relationships and configurations that might have been overlooked by other methods [Ritchey 2005, page 5]. By using morphological analysis, we aim to explore and comprehensively investigate the potential applications of agility in the context of knowledge technologies. Based on a literature research on existing work on agility, etymology of the term agile and a review of research areas that are related to the questions at hand, an

4 Authors

analytical instrument for analyzing different agile approaches was developed. By investigating research in four different areas, agile methods, agile processes, agile manufacturing and agile businesses (business agility), it is aimed to obtain a deeper understanding about current approaches to achieving agility. Subsequently, the results of these investigations are utilized to construct a morphological framework, aiming to illustrate the potential of agility as a new quality for knowledge technologies.

4 Agile, Agility and Agile Systems

In the following, a selective excerpt of available definitions of agility is introduced to develop a richer semantic basis for understanding. It represents an excerpt, because such an investigation can never be exhaustive; and it is selective, because its purpose is to shed light on the usage of the term in different domains (vs. an encompassing picture of the term itself). [M-WD 2006] states that agile stems from agilis, from agere to drive, act. It provides two definitions: 1) marked by ready ability to move with quick easy grace and 2) having a quick resourceful and adaptable character (an agile mind). In addition [M-WT 2006] defines it as the ability to move easily. Wordnet [CSL 2006] takes up that definition and introduces agile as 1. moving quickly and lightly and refers to mentally quick (an agile mind). [M-WD 2006] points to the term agent for further definitions. In [M-WD 2006] an agent is: something that produces or is capable of producing an effect, an active or efficient cause, a chemically, physically, or biologically active principle and a means or instrument by which a guiding intelligence achieves a result. [CSL 2006] defines an agent to be an \emph{active and efficient cause; capable of producing a certain effect and a representative who acts on behalf of other persons or organizations. Subsequently, agility can be understood to be a quality, a system’s ability of being agile. Other related terms include nimbleness and dexterity in motion [M-WD 2006, OED 2006]. [M-WT 2006] defines agility to be represented in the ease and grace in physical activity. [CSL 2006] defines agility to be the gracefulness of a person or animal that is quick and nimble and introduces synonyms including legerity, lightness, lightsomeness and nimbleness.

5 Analytical Design

In order to understand and assess agility as a quality attribute of systems, we introduce a multi-dimensional instrument for analyzing agility based on a comprehensive literature research in the areas agile methods, agile manufacturing, agile processes and agile businesses, but also information systems effectiveness [Seddon et al. 1998], cybernetics [F. Heylighen and C. Joslyn 2001] and agent theory [Yu 1995]. First and foremost, the analytical design makes a fundamental distinction between agility of, agility through and agility for. Agility of refers to the systems that need to deal with dynamics and complexity (such as organizations, information


systems, specific IT applications, etc). Agility for refers to the stakeholders that have an interest in achieving agility in some system, such as individuals, groups or management. Agility through refers to the qualities, instruments, techniques, algorithms and concepts that can enable agility in systems, but which do not necessarily need to be agile themselves, for example loose coupling, decentralization or weak structures. These fundamental distinctions represent the basis for the analytical instrument introduced in Table 1. The instrument proposes multi-dimensional analyses including: Focus, Structure of Dealing with Change, Types of Change, Strategies for Dealing with Change and Means for Dealing with Change. Each of the dimensions is designed to answer a specific question regarding existing conceptualizations of agility. Table 1 gives an overview of the instrument’s elements and corresponding questions.

Nr. Element Addressed Questions Regarding Agility 1) Focus What facets of a system should be agile? Who are

the targeted stakeholders? 2) Structure of Dealing

with Change Who or what causes change? Who or what deals with change? Who or what is affected by change?

3) Types of Change What types of change are dealt with? 4) Strategies for

Dealing with Change What are the strategies for dealing with change?

5) Means for Dealing with Change

What are instruments for dealing with change?

Table 1 Overview and Main Questions of the Analytical Instrument

The following sections introduce each of the analytical elements in greater detail. Because of the relative novelty of knowledge technologies, the instrument reverts to theories from the field of information systems to ground the analytical framework in a broader research context.

1) Focus: Agility has been discussed as a quality attribute of information systems on different levels. To analyze and compare these heterogeneous approaches in the light of a coherent concept, we utilize an adapted version of the two-dimensional matrix for information systems effectiveness introduced by [Seddon et al. 1998]. The two dimensions of this matrix represent different categories and stakeholders of information systems. From an agile system’s perspective, the matrix can be used to distinguish between agility for and agility of: Agility for relates to the different stakeholders that share an interest in achieving agility in some system, including management, groups, individuals and independent observers. Agility of can be related to different facets of information systems including aspects of IT design or use, singular IT applications, types of IT applications, all IT applications of an organization, aspects of a system development methodology and IT functions.

[Seddon et al. 1998] argue that an assessment of information systems effectiveness strongly depends on the stakeholders who are affected by or have an interest in different facets of information systems. An evaluation of agility, similar to an evaluation of system qualities in general, also depends on the stakeholders that

6 Authors

share an interest in agility. The following Table 2 categorizes existing research on agile systems into the two dimensional matrix of information systems effectiveness, answering the questions “What facets of agility in the context of information systems are targeted by existing agile approaches?” and “Who are the targeted stakeholders?”

Agility of

Agility for

An aspect of IT design or use

A single IT application in an organization

A type of IT application

All IT applications used by an organization

An aspect of a system develop-ment me-thodology

An IT function

Independent Observer

Individual Agile Modeling

Group Agile Processes

(Autonomic Computing)

Agile Methods

Management/Organization

Agile Businesses, Agile Manufacturing

Agile Project Management

Country

Table 2 Different Levels of Information Systems Analysis and Relation to Existing Agile Approaches

Table 1 fulfils multiple purposes: First, it provides an initial categorization scheme

for the heterogeneous body of work on agile systems. Second, it acts as a starting point for identifying and comparing the means for achieving agility in different contexts. Finally, this table can help in identifying new fields in which the notion of agility might be applied to improve on different aspects of information systems.

2) Structure of Change: In existing work, agile systems are, among others, regarded to be flexible [Evans 2001, Goldman et al. 1995, Gunasekaran 1998], reconfigurable [Gould 1997, Goldman et al. 1995, Kidd 1995, Dove 1996], self-organizing [Dove 1996], adaptable [Gould 1997, Kidd 1995], adaptive [Abrahamsson et al. 2002], weakly-structured [Holz et al. 2003], modular [Abrahamsson et al. 2002], maneuverable [Christopher 2000], extendable [Gunasekaran 1998], scalable [Gunasekaran 1998], and robust [Kidd 1995]. The enormous breadth of available attributions makes it hard to sketch a convergent characterization of agility. However, a common issue that underlies most of these characterizations is the ability to deal with change. This represents a universal theme that can be identified across different contexts [Conboy and Fitzgerald 2004, Caswell and Nigam 2005, Verstraete 2004], and many of the introduced attributions can be regarded to represent different approaches for addressing that challenge. This work considers change to be at the heart of research on agility. By taking this perspective, and by building on cybernetics, agent theory and requirements engineering, we introduce the following definition of agility as a baseline for the investigations of this work:


“Agility is the ability of a first order intentional system to effectively and efficiently deal with change in order to satisfy its set of goals.” This definition emphasizes several aspects of systems: First, it follows a system-

oriented approach to defining agility, which is a consequence of the relative nature of agility (agility for). Second, it establishes a distinction and relationship between the change impulse and its effects on the system. Third, the definition requires systems to be intentional [Yu 1995]. That means that they need to pursue goals, and judge the effectiveness and efficiency of their (re-)actions to change in the light of their intentions. Fourth, the definition strengthens that the intentional system is of first order, emphasizing that it “has beliefs and desires, but no beliefs and desires about beliefs and desires”3 [Jennings and Wooldridge 1998]. Fifth, the definition strengthens that an agile system pursues a set of (potentially conflicting) goals, rather than a single goal – and thereby (potentially) has to resolve them [Yu 1995]. Sixth, the definition does not make any assumption about the objectively “right” way to deal change (or the “right” strategy), whether for example to initiate, accept, reject, influence or ignore it, but emphasizes the openness of agile systems to choose the best strategy available for specific situations (subjectively) in the light of their goals. In other words, agility does not prescribe certain behavior, but represents a concept that is relative to systems – depending on the goals they pursue.

Figure 1 Sketch of Roles and Activities of Systems Dealing with Change

Figure 1 provides a graphical sketch of the introduced definition based on

[Strohmaier and Yu 2006], and introduces relevant roles and activities: In Figure 1, causative entities represent the entities that cause change. Directive agents deal with change through exploration, decision making and action. Decisions regarding change are made in light of goals that a directive agent pursues. The managed entity is the entity that is affected by change, and that is managed by the directive agent. The introduced illustration acts as a frame for comparing the structure of different existing conceptualizations of agility.

3) Types of Change: Existing agile approaches distinguish between a broad set of different types of change, including expected/unexpected [Verstraete 2004],

3 As elaborated later, this aspect is important to distinguish agility from other quality attributes,

such as reflectivity

8 Authors

predictable/unpredictable [Gould 1997, Dove 1996], incremental/revolutionary [Nelson et al. 1997, Regev et al. 2005], planned/unplanned, frequent/rare, continuous/discontinuous [Tochtermann 2004, Dove 1996], external/internal, temporary/permanent [Regev et al. 2005] or welcome/unwelcome change. These categories can be related to different levels, implications, forms and actions. However, these categories are not absolute but relative - While a particular change might be welcome to one stakeholder, it might be unwelcome to another. Also, change might be temporary to one stakeholder, while it is permanent for another. The space of expected changes might also be modified: For example it might be increased through variation (such as [Liaskos 2006] in the context of requirements engineering) or the utilization of explorative instruments (such as scenario development, including SAAM [Clements et al. 1995, Bass et al. 1998], ATAM [Kazman et al. 2000], [Lassing et al. 1999], or [Bengtsson et al. 2000] in the context of software architecture). 4) Strategies for Dealing with Change: Different types of change, goals and environments can evoke different strategies for dealing with change. It is the task of an agile system (more specifically: its directive agent) to select the most appropriate strategy in the light of the goals an agile system pursues. In order to do that, a directive agent can (in principle) execute the following three main tasks related to change4: Exploration of change: The directive agent can for example perceive, identify, seek for, scan and assess change in the light of the goals that the agile system pursues. Decision upon change: In principal, the directive agent is autonomous (free) in deciding upon change. He has three main strategies available: accepting, rejecting and influencing change. Accepting change can mean to agree, approve of or surrender to change; rejecting change can mean to decline, ignore, dismiss or resist to change, and influencing change can mean to mitigate, limit, negotiate or counter-attack change. Action upon change: Depending on the outcome of the decision process, the directive agent can plan change and perform control on the managed entity. Planning change refers to the activities that the directive agent undertakes to envision a desired output. Control refers to unfreezing, acting upon and refreezing [Schein 1996] the managed entity.

4 based on control theory and cybernetics, as for example introduced in [Heylighen and Joslyn

2001]


Figure 2 An Overview of Tasks and Strategies for Dealing with Change

Figure 2 aims to give a non-exhaustive overview of the different tasks and

strategies for dealing with change. 5) Means for Dealing with Change: In the light of the introduced structure of systems that deal with change, means for achieving agility exist on different levels. Thereby, the question “How can agility be achieved” is addressed (Agility through). We distinguish between the system qualities that are expected to contribute to agility (such as adaptability, flexibility, expandability) and the concrete techniques proposed to achieve agility (such as feedback mechanisms, distributed control or rapid prototyping).

In the following section, we apply the analytical instrument to four existing

conceptualizations of agility.

6 Analyzing Existing Conceptualizations of Agility in Different Domains

All of the following research areas claim to conduct research on improving the agility of some system, including agile methods (agility of software development), agile processes (agility of workflow management systems), agile manufacturing (agility of organizations) and agile businesses (agility of organizations and information systems).

10 Authors

6.1 Agile Methods

Agile methods represent a field of research focusing on software development methods. The motivation of agile methods largely stems from the inappropriateness of traditional software development techniques, such as the waterfall model [Royce 1970] and variations of it [Boehm 1988, Yourdon 1989], the spiral model [Boehm 1988], and the V-Model [iabg 1995]. Rigidity and inflexibility of these traditional techniques led to the emergence of alternative approaches that emphasize (among other aspects) shorter release cycles, stronger customer orientation and more intense, informal communication and cooperation. Examples include Extreme Programming, Scrum, Agile Modeling [Ambler 2006] and Agile Management [Anderson 2006]. With the emergence of the Agile Manifesto [Fowler and Highsmith 2001], the term “agile methods” is frequently used to refer to the 12 principles in the manifesto document. Table 3 depicts the results of applying the introduced analytical instrument to agile methods: Agile methods refer to an aspect of a system development methodology, and the stakeholders having an interest in agility are management and developers. The (intentional) entities that represent the cause for change are mainly customers. Developers represent the directive agents, which need to identify, decide and act upon change. The managed entity is the software that is under development. Agile methods largely focus on accommodating unexpected, unplanned, incremental, frequent and continuous change. The techniques proposed by agile methods are designed to encourage, influence and accommodate change, while control is executed by means of instruments such as version control. Quality attributes that are frequently proposed by agile methods are adaptability of the software and the software development process, manoeuvrability of the project, responsiveness of developers, speed of development and utility of the outcome.

Agile Methods

Agility for (Stakeholders) An individual, a group (Developers), management

Agility of (Systems) An aspect of a system development methodology (Software Development)

System Structure Causative Entity Customer Directive Agents Developer Managed Entity Software

Types of Change Unexpected, unplanned, incremental, frequent, continuous

Strategies Exploration of Change Encourage Decision upon Change Accept, Influence Action upon Change Control

Agility through (Means) Quality Attributes Adaptability, Manoeuvrability,

Responsiveness, Speed, Utility


Techniques Planning game, story cards, reflection workshops, iterative incremental cycles, review meetings, early and continuous deployment, integration and testing, customer participation, limited documentation, light weight processes, pair programming, parallelism, collective ownership of code, Examples: Scrum, XP, FDD, Crystal

Table 3 Analysis of Agile Methods

6.2 Agile Processes

The agile processes research community largely aims to eliminate the drawbacks of traditional workflow management systems (such as rigidity, inflexibility) by conducting research on business process support systems that are weakly structured and light weighted [Holz et al. 2003]. The pursued goals include reducing process execution times and increasing process flexibility. Solution-oriented approaches in this research domain include instruments for ad-hoc process modeling [Huth et al. 2003] and modeling of weakly-structured workflows [Papavassiliou 2002]. Table 4 depicts the domain of agile processes according to the introduced analytical instrument: Agile processes are concerned with increasing the agility of Workflow Management Systems, which can be regarded to be a specific type of IT application. The stakeholders that share an interest in agile processes are process designers and workers that use the system. The causative agent is a (dynamic) environment that evokes and coerces changes in the Workflow Management System. Workers and process designers represent the directive agents while workflows represent the managed entities. Research on agile processes aims to develop systems that are able to accept expected/unexpected, unplanned, predictable/unpredictable, incremental and both frequent and rare change. Analysis and assessment of change represents the basis for planning and implementing change in workflows. Quality attributes that are proposed to contribute to the agility of workflows are adaptability, reusability and expandability of workflow definitions and workflow instances, coupling intensity of type-instance bindings and comprehensibility of workflow models.

Agile Processes Agility for (Stakeholders) A group (Workers, Process

Designers) Agility of (Systems) A type of IT application (Workflow

Management Systems) System Structure

12 Authors

Causative Entity Environment Directive Agents Workers, Process Designers Managed Entity Workflows

Types of Change Expected/Unexpected, Unplanned, Predictable/Unpredictable, Incremental, frequent/rare

Strategies Exploration of Change Analyze, Assess Decision upon Change Accept Action upon Change Plan, Control

Agility through (Means) Quality Attributes Adaptability, reusability,

expandability, coupling intensity, comprehensibility

Techniques CBR systems, Petri nets, simulation, analysis, ad-hoc modeling, late modeling, late binding

Table 4 Analysis of Agile Processes

6.3 Agile Manufacturing

Agile manufacturing represents a field of research in organizational sciences. [Gould 1997] reports that its emergence can be traced back to post world-war II times, where there was a strong need for U.S. companies to easily switch between military- and consumer production. In the U.K., agility has become a topic during the 1990ies as a reaction to a perceived increase of competitiveness in the economic climate [Gartner 2002]. In general, agile manufacturing is regarded to be a departure from the then prevalent lean management approaches, towards more adaptable forms and structures of organizations. Agile manufacturing therefore focuses on the development of organizations that are “fast moving, adaptable and robust […], capable of rapid reconfiguration” [Kidd 1995], that “embrace change” [Goldman 1995], and that are “able to thrive in an environment of continuous and unpredictable change” [Dove 1996]. Latest research in that domain for example develops frameworks for agile manufacturing systems [Gunasekaran 1998] and domain-specific benchmarks that aim to measure the degree of agility of organizations, including the technological dimension [Sarkis 2001]. Table 5 introduces a characterization of agile manufacturing according to the analytical instrument: The objects of investigations are organizations and supporting technologies. The main stakeholder sharing an interest in agility is management. Agile manufacturing regards the environment and the system itself to represent the causative entity. Management and the IT department are in charge of dealing with change, while the organization and all its IT applications are regarded to represent the managed entity. Agile manufacturing aims to prepare organizations for a wide range of changes, including expected/unexpected, planned/unplanned, predictable/unpredictable, incremental/revolutionary, and


frequent/rare. Strategies used to explore change include seek for, scan, monitor, assess and analyze change. Agile manufacturing emphasizes the openness of agile systems by including rejection of change as an acceptable strategy. Quality attributes expected to contribute to agility include compatibility, scalability, variability, process integration, extendibility, flexibility, adaptability, robustness, manoeuvrability and responsiveness.

Agile Manufacturing

Agility for (Stakeholders) Management Agility of (Systems) The organization (intentional), All IT

applications used by an organization System Structure

Causative Entity Environment and system itself Directive Agents Management, IT Department Managed Entity The organization, all IT applications

Types of Change Expected/Unexpected, Planned/Unplanned, Predictable/Unpredictable, Incremental/Revolutionary, frequent/rare

Strategies Exploration of Change Seek, Scan, Monitor, Assess, Analyze Decision upon Change Reject, Accept, Influence Action upon Change Plan, Control

Agility through (Means) Quality Attributes Compatibility, Scalability,

Integration, Variability, Process Integration, Extendibility, Flexibility, Adaptability, Robustness, Manoeuvrability, Responsiveness

Techniques Feedback/ Feedforward control mechanisms, Dynamic Teaming, Rapid prototyping, Concurrent engineering, Distributed teams and manufacturing, competency landscapes, information logistics, delayed configuration

Table 5 Analysis of Agile Manufacturing

6.4 Agile Businesses

Agile Businesses (or Business Agility) is a relatively young research field that is concerned with the alignment of information technologies to business changes in

14 Authors

organizational contexts. According to [Stolze et al. 2005], business agility can serve two goals: speed and resilience. While coordination of change activities is regarded to represent a central issue [Caswell and Nigam 2005], knowledge management systems have been suggested as a vehicle for implementing business agility in organizations [Ashrafi et al. 2005]. Organic computing [Müller-Schloer 2004, Organic-Computing Initiative 2006] and decision support systems [Hersh 1999] have been identified as promising future research areas that have the potential to contribute to the field of business agility [Strohmaier and Rollett 2005]. Table 6 depicts the results of applying the analytical instrument: Agile business focus on increasing the agility of the IT infrastructure of organizations. Agile businesses regard management to be the main stakeholder of agile businesses. The environment represents the causative entity, while the IT department represents the directive agent. Agile businesses deal with expected/unexpected, planned/unplanned, predictable/unpredictable, incremental/revolutionary and frequent/rare change. Stimuli for change are actively explored, including seeking and scanning for, monitoring, assessing and analyzing change. Similar to agile manufacturing, agile businesses emphasize the openness of agile systems, reserving the right to reject change. Quality attributes expected to contribute to agile businesses are promiscuity, simplification, compatibility, reusability, redundancy, and modularity.

Agile Businesses (Business Agility)

Agility for (Stakeholders) Management Agility of (Systems) All IT applications used by an

organization System Structure

Causative Entity Environment Directive Agents IT Department Managed Entity all IT applications

Types of Change Expected/Unexpected, Planned/Unplanned, Predictable/Unpredictable, Incremental/Revolutionary, frequent/rare

Strategies Exploration of Change Seek, Scan, Monitor, Assess, Analyze Decision upon Change Reject, Accept, Influence Action upon Change Plan, Control

Agility through (Means) Quality Attributes Promiscuity, simplification,

compatibility, reusability, redundancy, modularity

Techniques Any device front-end, information hiding, loose coupling, encapsulation, standardization, component-based architectures, virtualization of computer capacity, self-organization,


distributed control, separation from business processes and enactment systems, late binding, security and session management, documentation for users, Small group pilots, rapid prototyping, mobile business, end user training

Table 6 Analysis of Agile Businesses (Business Agility)

7 Relation between Agility and Related Quality Attributes

This section investigates the relationship between the introduced definition of agility, and selected related quality attributes on the basis of the conducted analyses. In the following, the identified quality attributes are formulated as a specific configuration of an agile system: Flexibility: A flexible system can be regarded to be equivalent to an agile system if the agile system’s directive agent aims to accept all changes, and the managed entity is able to accommodate all of them. This for example is in accordance with the notion of technology flexibility as introduced by [Nelson et al. 1997]. Agility distinguishes itself by its goal orientation – reserving the right to reject change. Rigidity: A rigid system can be regarded to be equivalent to an agile system if the agile system’s directive agent aims to decline all changes. This is can also be referred to as a system’s disability to accommodate change. This is in accordance for example with the characterization of software development methodologies that are not able to deal with changing requirements (“rigid methods”). Robustness: A robust system can be regarded to be equivalent to an agile system if the agile system’s directive agent aims to can resist all changes while still being able to achieve the agile system’s goals, which can be related to the definition of [Heylighen and Gershenson 2003] who emphasize that robust systems can withstand errors and perturbations. Similarly, [Conboy and Fitzgerald 2004] emphasize that robustness represents the ability to endure all transitions caused by change without having to take corrective actions. Configurability: A configurable system can be regarded to be equivalent to an agile system if the agile system’s directive agent can accept a limited set of changes (regardless of the agile system’s goals) that the managed entity is able to accommodate. Self-configurability [Kephart and Chess 2003] additionally relies on the directive agent to evaluate and decide upon different configurations in the light of 1) its goals and 2) its knowledge about the environment and itself. Reflexibility: A reflexive system can be regarded to be equivalent to an agile system if the agile system additionally has second order intentional system capabilities [Wooldridge and Jennings 1995]. This requires a system to reflect upon and potentially change its set of goals. Work on the role of change in goal models represents first formal approaches in this direction [Chung et al. 1995, Chung et al. 1996].

16 Authors

Evolvability: An evolvable system can be regarded to be equivalent to an agile system if the agile system is reflexive, and additionally can adapt its constitution according to changing environmental conditions. Table 7 gives an overview of the discussed qualities of systems.

Quality Decision Preference

Goal Orientation

Flexibility Accept change No Rigidity Decline Change No Robustness Resist Change Yes Configurability Accept limited Change No Self-Configurability

Accept limited Change Yes

Reflexibility none Yes5 Evolvability none Yes

Table 7 Overview of Quality Attributes Related to Agility

8 Implications for Agile Knowledge Technologies

Knowledge technologies can be regarded to lack agility from several perspectives: the development of ontological models is costly and labour intensive, and implementation takes significant efforts. The structural distinction but functional relation between type and instance level increases the chance for side-effects and results in difficulties when dealing with change. In this section, we will introduce a morphological concept that illustrates different dimensions and aspects of agility in the context of knowledge technologies. Utilizing morphological analysis [Ritchey 2005] as a methodological framework, we aim to introduce a comprehensive analysis of the notion of agility [Ritchey 2005, page 4] for knowledge technologies. A morphological framework for agile knowledge technologies is constructed by setting a set of parameters of agility against each other in an n-dimensional matrix. “Each cell of the n-dimensional box contains one particular “value” or condition from each of the parameters, and thus marks out a particular state or configuration of the problem, complex.” [Ritchey 2005, page 4] and “These values represent the possible, relevant conditions that each issue can assume” [Ritchey 2005, page 6]. A morphological box is assumed to be especially useful for: 1) examining all different configurations possible in a field of interest 2) discover new relationships and configurations that might have been overlooked by other methods [Ritchey 2005, page 5]. Based on morphological boxes, solution spaces can be defined that represent a subset of configurations which satisfy some criteria [Ritchey 2005, page 5].

5 Reflexibility requires not only goal orientation, but reflection upon goals, in the spirit of 2nd

order intentional systems [Wooldridge and Jennings 1995].


The morphological box for agile knowledge technologies depicted in Table 8 aims to explore and open up the space of possibilities for achieving agility in knowledge technologies. This is in the spirit of [Ritchey2002] who claims that “We must first discover what we judge as possible, before we make judgments about what is desirable.” The morphological framework introduces four parameters, each with different values, based on the analysis conducted on different conceptualizations of agility. The values per parameter represent the possible, relevant conditions that each issue can assume [Ritchey 2005, page 6]. It thereby represents a non-quantified modeling approach [Ritchey 2005] to conceptualizing agile knowledge technologies.

Agility for User(s) Modeler(s) Developer(s)

Manage-ment

An Industry A Country

Agility of A single

knowledge technology

A type of knowledge technology

All knowledge technologies in an organization


Types of Change

Constant Predefined Ambiguous Surprise

Drivers behind Change

Customers Competi-tion

Technology Social Factors

Overhead

Agility through (Quality Attributes)

Flexibility Autonomy Modularity Adaptabi-lity

Speed Variability Configura-bility

Table 8 A Morphological Framework for Agile Knowledge Technologies

The first parameter Agility for distinguishes between users, modelers, developers, management, industries6 and countries as stakeholders that share an interest in agility. The second parameter Agility of classifies different aspects of knowledge technologies that are anticipated to exhibit agile behavior. This can be a single knowledge technology (a specific solution), a type of knowledge technology (e.g. a workflow management system), all knowledge technologies in an organization (an organization’s knowledge technology infrastructure), or an aspect of a system development methodology (e.g. ontology engineering). The next parameter Types of Change distinguishes different classes of change stimuli (based on [Kumar and

6 Adapted from [Seddon et al. 1998]

18 Authors

Narasipuram 2006] in the context of workflow management systems): constant change refers to situations where there are no variations in the stimulus of change, and each identified stimulus is paired with a fixed response. An example would be a workflow definition that is designed for a well-defined problem with no variation. Predefined change refers to situations where there is pre-defined variation in the stimulus of change, and there is a set of possible responses paired to it. In the domain of workflow management systems, this would correspond to pre-defined process paths that are “mutually exclusive and collectively exhaustive” [Kumar and Narasipuram 2006]. Ambiguous change refers to situations where there is ambiguity in the stimulus for change. Once the ambiguity is resolved, the system can react with predefined responses. In the context of workflow management, this would correspond to a process manager clarifying the stimulus and identifying adequate workflows. Surprise change refers to situations where there is no adequate respond to an identified stimulus yet. This requires analysis and planning of the situation. For workflow management systems, this means that new processes need to be designed. The next parameter Drivers behind change distinguishes the different causative agents Customers, Competition, Technology, Social Factors and Overhead (based on [Conboy and Fitzgerald 2004]). The final parameter Agility through distinguishes different types of achieving agility on a quality attribute level. The non-exhaustive list of possible values includes flexibility, reusability, modularity, adaptability, compatibility, variability and configurability. Concrete techniques for achieving agility are excluded from this framework because of 1) the sheer breadth of proposed techniques and 2) the domain-dependency of these approaches. For a detailed overview of concrete techniques we refer to section 6.

The morphological framework depicted in Table 8 was investigated for logical

contradictions among parameter values in the spirit of CCA (Cross Consistency Assessment) proposed by [Ritchey 2005]. The parameters were not investigated for empirical and normative constraints, because the goal of this work is to explore and open up the space for possible configurations of agile knowledge technologies, rather than restricting it. This would be done when defining a specific solution space. A solution space represents a subset of configurations within a morphological box, which satisfy some criteria.

Examples for solution spaces in the context of agile knowledge technologies include Agile Knowledge Technology Development (depicted as solid boxes in

Table 9) or Agile Workflow Management Systems (depicted as dashed boxes) or a domain not exhaustively dealt with from an agile perspective yet: Autonomic Computing (depicted as bold boxes). By having a look at these examples, the utility of the morphological framework for agile knowledge technologies becomes obvious: It aids in exploring new, potentially overlooked aspects of agility in the context of knowledge technologies, and aids in identifying potential synergies (represented as an overlap) between currently separated streams of research. The morphological framework thereby connects existing work, and helps in identifying new fields and directions for future research. It encourages to experiment with the self-understanding of existing streams of research. To give an example: In addition to users and modelers, Agile Workflow Management Systems might investigate what agility would mean to developers and managers. Agile Knowledge Technology


Development might shift its research focus from considering surprise change towards ambiguous and predefined change (which in part can already be observed in existing work, (for example in the Crystal Methodology [Abrahamsson et al. 2002]). “Morphing” the self-understanding of existing research streams might aid in identifying hidden assumptions or limitations of current research efforts that impair their ability to comprehensively address the respective research challenges.

Agility for User(s) Modeler(s) Developer(

s) Manage-ment

An Industry

Agility of A single

knowledge technology

A type of knowledge technology

All knowledge technologies in an organization


Types of Change

Constant Predefined Ambiguous Surprise

Drivers behind Change

Customers Competi-tion

Technology Social Factors

Overhead

Agility through (Quality Attributes)

Flexibility Autonomy Modularity Adaptabi-lity

Speed Variability Configura-bility

Table 9 Exemplary Solution Spaces For Agile Knowledge Technologies

9 Conclusions

As we aimed to illustrate with the introduction of the morphological framework, agile knowledge technologies represent a multi-dimensional, multi-faceted challenge. Means to achieve agility strongly depend on the stakeholders that share an interest in agility, the specific aspects of knowledge technologies that are supposed to exhibit agile behaviour, the drivers behind change and the type of change that is considered. Current research on knowledge technologies can be classified with the help of the morphological framework: For example, existing work can be regarded to focus on 1) achieving agility for modelers (of ontological models) and users (that need to adapt knowledge technologies to their needs) 2) agility of ontological modeling (an

Autonomic Computing Agile Workflow Management SystemsAgile Knowledge Technology Development

20 Authors

aspect of a system development methodology) and specific types of knowledge technologies (in particular workflow management systems) and 3) designing support for ambiguous and surprise change.

Acknowledgements

The research of this contribution is funded in part by the Natural Sciences and Engineering Research Council of Canada (NSERC), Bell University Laboratories (BUL) at the University of Toronto, the Know-Center Graz (within the Austrian Competence Center program Kplus) and the FWF Austrian Science Fund.

References

[Abrahamsson et al. 2002] P. Abrahamsson, O. Salo, J. Ronkainen, and J. Warsta. Agile software development methods - review and analysis. Technical Report 478, VTT PUBLICATIONS, 2002.

[Ambler 2006] S. Ambler. The agile modeling home page. http://www.agilemodeling.com/, last accessed on July 19th, 2006, 2006.

[Anderson 2006] D.J. Anderson. Agile management home page. http://www.agilemanagement.net, last accessed on March 8th, 2006, 2006.

[Bass et al. 1998] L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice. Addison Wesley, 1998.

[Bengtsson et al. 2000] P. Bengtsson, N. Lassing, J. Bosch, and H. van Vliet. Analyzing software architectures for modifiability, 2000.

[Boehm 1988] B. W. Boehm. A spiral model of software development and enhancement. IEEE Computer, 21(5), 1988.

[Regev et al. 2005] G. Regev, P. Soffer, R. Schmidt. A Taxonomy of Flexibility in Business Processes, prepared for the Seventh Workshop on Business Process Modeling, Development, and Support (BPMDS’06) Requirements for flexibility and the ways to achieve it, http://lamswww.epfl.ch/conference/bpmds06/taxbpflex, last accessed on July 18th 2006, 2005.

[Caswell and Nigam 2005] N. S. Caswell and A. Nigam. Agility = change + coordination. In Proceedings of Seventh IEEE International E-Commerce Technology Workshops, 2005., pages 131–139, 2005.

[Christopher 2000] M. Christopher. The agile supply chain: competing in volatile markets. Industrial Marketing Management, 29(1):37–44, 2000.

[Chung et al. 1995] L. Chung, B. A. Nixon, and E. Yu. Using non-functional requirements to systematically support change. In RE ’95: Proceedings of the


Second IEEE International Symposium on Requirements Engineering, page 132, Washington, DC, USA, 1995. IEEE Computer Society.

[Chung et al. 1996] L. Chung, B. A. Nixon, and E. Yu. Dealing with change: An approach using non-functional requirements. Requirements Engineering, 1(4):238–260, December 1996.

[Clements et al. 1995] P. Clements, L. Bass, R. Kazman, and G. Abowd. Predicting software quality by architecture-level evaluation. In Fifth International Conference on Software Quality. Austin, Tx, October 1995.

[Conboy and Fitzgerald 2004] K. Conboy and B. Fitzgerald. Toward a onceptual framework of agile methods: a study of agility in different disciplines. In Proceedings of the 2004 ACM workshop on Interdisciplinary software engineering research (WISER ’04), pages 37–44, New York, NY, USA, 2004. ACM Press.

[Craven et al. 1998] M. Craven, D. DiPasquo, D. Freitag, A. McCallum, T. M. Mitchell, K. Nigam, and S. Slattery. Learning to extract symbolic knowledge from the world wide web. In In Proceedings of the Fifteenth National Conference on Artificial Intellligence (AAAI98), pages 509–516, 1998.

[CSL 2006] Cognitive Science Laboratory, Princeton University: Wordnet - a lexical database for the english language. http://wordnet.princeton.edu/, last accessed on March 8th, 2006 (2006)

[Dove 1996] R. Dove. Tools for analyzing and constructing agility. Republished by Agility Form, PA96-01, January 1996.

[Evans 2001] N.D. Evans. Business Agility: Strategies for Gaining Competitive Advantage through Mobile Business Solutions. Financial Times Prentice Hall, November 2001.

[Fensel 2002] D. Fensel. Ontology-Based Knowledge Management. Computer, 35(11):56-59, IEEE Computer Society Press, Los Alamitos, CA, USA, 2002.

[Fowler and Highsmith 2001] M. Fowler and J. Highsmith. The agile manifesto. In Software Development, Issue on Agile Methodologies, http://www.sdmagazine.com, last accessed on March 8th, 2006, August 2001.

[Gartner 2002] UK Gartner. The age of agility. Technical report, Report prepared by Gartner for BT, 2002.

[Goldman et al. 1995] S. Goldman, R. Nagel, and K. Preiss. Agile competitors and virtual organisations. Van Nostrand Reinhold, 1995.

[Gould 1997] P. Gould. What is agility? Manufacturing Engineer, 76(1):28–31, February 1997.

[Gunasekaran 1998] A. Gunasekaran. Agile manufacturing: enablers and an implementation framework. International Journal of Production Research, 36(5):1223–1247, May 1998.

22 Authors

[Hersh 1999] M.A. Hersh. Sustainable decision making: The role of decision support systems. IEEE Transactions on Systems, Man and Cybernetics - Part C: Applications and Reviews, 29(3):395–408, 1999.

[Heylighen and Gershenson 2003] F. Heylighen and C. Gershenson. Meaning of Self-organization in Computing. IEEE Intelligent Systems, 2003.

[Heylighen and Joslyn 2001] F. Heylighen and C. Joslyn. Cybernetics and second-order cybernetics. In R.A. Meyers, editor, Encyclopedia of Physical Science & Technology. Academic Press, New York, 2001.

[Hollingsworth 1995] D. Hollingsworth. Workflow management coalition – the workflow reference model. Technical report, Workflow Management Coalition, Jan 1995.

[Holz and Maurer 2003] H. Holz and F. Maurer. Knowledge management support for distributed agile software processes. In Advances in Learning Software Organizations, 4th International Workshop, LSO 2002, Chicago, IL, USA, August 6, 2002, Revised Papers, LNCS 2640. Springer, 2003.

[Holz et al. 2003] H. Holz, G. Melnik, and M. Schaaf. Knowledge management for distributed agile processes: Models, techniques, and infrastructure. In Proceedings of the 12th IEEE International Workshops on Enabling Technologies (WETICE 2003), Infrastructure for Collaborative Enterprises, 9-11 June 2003, Linz, Austria. IEEE Computer Society, 2003.

[Huth et al. 2003] C. Huth, N. Tas, I. Erdmann, and L. Nastansky. Groupprocess Web: Graphisch interaktives Management von Ad-hoc-Geschäftsprozessen im Web. In U. Reimer, A. Abecker, S. Staab, and G. Stumme, editors, WM 2003, Professionelles Wissensmanagement – Erfahrungen und Visionen, Luzern, 2003.

[IABG 1995] IABG. V-Model, Lifecycle Process Model - Brief Description. IABG Industrieanlagen-Betriebsgesellschaft mbH, Einsteinstr. 20, D-85521 Ottobrunn, 1995.

[Initiative 2006] Organic Computing Initiative. The organic computing website. http://www.organic-computing.org, last accessed on May 31st, 2006.

[Jennings and Wooldridge 1998] N.R. Jennings and M.J. Wooldridge. Agent Technology: Foundations, Applications and Markets. Springer Computer Science, 1998.

[Kazman et al. 2000] Rick Kazman, Mark Klein, and Paul Clements. Atam: Method for architecture evaluation. Technical Report CMU/SEI-2000-TR- 004, Carnegie Mellon Uiversity, Software Engineering Institute, 2000.

[Kephart and Chess 2003] J. O. Kephart and D. M. Chess. The vision of autonomic computing. Computer, 36(1):41–50, 2003.

[Kumar and Narasipuram 2006] K. Kumar and M. M. Narasipuram. Defining requirements for business process flexibility. In Proceedings of the Seventh Workshop on Business Process Modeling, Development, and Support


(BPMDS’06) Requirements for flexibility and the ways to achieve it (CAiSE’06), 2006.

[Lassing et al. 1999] N. Lassing, D. Rijsenbrij, and H. van Vliet. Towards a broader view on software architecture analysis of flexibility. In Proceedings of the 6th Asia-Pacific Software Engineering Conference ’99 (APSEC’99), 1999.

[Liaskos et al. 2006] S. Liaskos, A. Lapouchnian, Y. Yu, E. Yu, and J. Mylopoulos. On goal-based variability acquisition and analysis. In Proceedings of the 14th IEEE International Requirements Engineering Conference (RE’06), Minneapolis, USA, 2006.

[Mayer et al. 2005] H. Mayer, W. Haas, G. Thallinger, S. Lindstaedt and K. Tochtermann. APOSDLE - advanced process-oriented self-directed learning environment. EWIMT 2005: 2nd European Workshop on the Integration of Knowledge, Semantic and Digital Media Technologies, 2005.

[MC 2006] MoDELS / UML 2006. ACM/IEEE 9th International Conference on Model Driven Engineering Languages and Systems, Genova, Italy, 2006.

[Mirzaee et al. 2005] V. Mirzaee, B. Hamidzadeh, and L. Iverson. Managing change in ontologies. In Proceedings of the 2005 IEEE International Conference on Information Reuse and Integration, IRI - 2005, pages 253–258, Las Vegas Hilton, Las Vegas, NV, USA, 2005. IEEE Systems, Man, and Cybernetics Society.

[MRT 2006] [email protected]. Workshop in conjunction with MoDELS/UML 2006, ACM/IEEE 9th International Conference on Model Driven Engineering Languages and Systems, Genova, Italy, 2006.

[MT 2007] Model Transformation Track, during The 22nd Annual ACM Symposium on Applied Computing, Seoul, Korea, 2007.

[Müller-Schloer et al. 2004] C. Müller-Schloer, C. von der Malsburg, and R. P.Würtz. Organic computing. Informatik Spektrum, pages 332–336, 2004.

[M-WD 2006] Merriam Webster Dictionary: Online dictionary. http://www.m-w.com, last accessed on July 18th, 2006 (2006)

[M-WT 2006] Merriam Webster Dictionary: Online thesaurus. http://www.m-w.com, last accessed on July 18th, 2006 (2006)

[Nelson et al. 1997] K.M. Nelson, H.J. Nelson, and M. Ghods. Technology flexibility: Conceptualization, validation, and measurement. In Proceedings of 30th Hawaii International Conference on System Sciences (HICSS) Volume 3: Information System Track-Organizational Systems and Technology, 1997.

[OED 2006] Oxford University Press, Oxfurd University: Oxford English Dictionary. http://www.oed.com/, last accessed on July 18th, 2006 (2006)

[Papavassiliou et al. 2002] G. Papavassiliou, S. Ntioudis, A. Abecker, and G. Mentzas. Managing knowledge in weakly-structured administrative processes. In Proceedings of The Third European Conference on Organizational

24 Authors

Knowledge, Learning, and Capabilities - OKLC 2002, Athens, Greece, April 2002.

[Remus 2002] U. Remus. Prozeßorientiertes Wissensmanagement – Konzepte und Modellierung. PhD thesis, Wirtschaftswissenschaftliche Fakultät der Universität Regensburg, Regensburg, Deutschland, 2002.

[Rigau et al. 2002] G. Rigau, B. Magnini, E. Agirre, P. Vossen, and J. Carroll. Meaning: a roadmap to knowledge technologies. In COLING-02 on A roadmap for computational linguistics, pages 1–7, Morristown, NJ, USA, 2002. Association for Computational Linguistics.

[Ritchey 2005] T. Ritchey. General morphological analysis - a general method for non-quantified modelling. privately published, 2005. Adapted from the paper ”Fritz Zwicky, Morphologie and Policy Analysis”, presented at the 16th EURO Conference on Operational Analysis, Brussels, 1998.

[Royce 1970] W.W. Royce. Managing the development of large software systems. In Proceedings of IEEE Wescon, August 1970.

[Sarkis 2001] J. Sarkis. Benchmarking for agility. Benchmarking: An International Journal, 8(2):88–107, 2001.

[Schein 1996] E. Schein. Kurt lewin’s change theory in the field and in the classroom: Notes toward a model of managed learning. Systems Practice, 9(1):27–48, 1996.

[Schreiber et al. 2002] G. Schreiber, H. Akkermans, A. Anjewierden, R. de Hoog, N. Shadbolt, W. Van de Velde, and B. Wielinga. Knowledge Engineering and Management. The MIT Press, 2002.

[Seddon et al. 1998] P. B. Seddon, D. S. Staples, R. Patnayakuni, and M. J. Bowtell. The is effectiveness matrix: the importance of stakeholder and system in measuring is success. In ICIS ’98: Proceedings of the international conference on Information systems, pages 165–176, Atlanta, GA, USA, 1998. Association for Information Systems.

[Stolze et al. 2005] M. Stolze, T. Böhmann, and H. Chai. Call for papers - ieee international workshop on business transformation (bt’05) - july 19, 2005 - munich, germany, 2005.

[Strohmaier and Rollett 2005] M. Strohmaier and H. Rollett. Future research challenges in business agility -time, control and information systems. In Proceedings of Seventh IEEE International E-Commerce Technology Workshops, 2005., pages 109–115, 2005.

[Strohmaier and Yu 2006] M. Strohmaier and E. Yu. Towards autonomic workflow management systems. In Proceedings of CASCON2006: The 16th Annual International Conference on Computer Science and Software Engineering, 2006.


[Sure et al. 2002] Y. Sure, M. Erdmann, J. Angele, S. Staab, R. Studer, and D. Wenke. OntoEdit: Collaborative Ontology Development for the Semantic Web. In Proceedings of the First Semantic Web Conference, June 2002.

[Tochtermann 2004] K. Tochtermann. Beyond the state-of-the-art of knowledge management. Journal of Universal Computer Science, 10:671–673, 2004.

[van der Aalst et al. 2006] W.M.P. van der Aalst, C. Günther, J. Recker, and M. Reichert. Using process mining to analyze and improve process flexibility. In Proceedings of CAISE’06 - The 18th Conference on Advanced Information Systems Engineering, 2006.

[Verstraete 2004] C. Verstraete. Planning for the unexpected. IEE Manufacturing Engineer, 83(3):18–21, June-July 2004.

[Wooldridge and Jennings 1995] M. Wooldridge and N. R. Jennings. Intelligent agents: Theory and practice. Knowledge Engineering Review, 10(2):115–152, 1995.

[Yin 1984] R.K. Yin. Case Study Research: Design and Methods. Applied social research methods series; Volume 5. Sage Publications, Beverly Hills, London, New Delhi, 1984.

[Yourdon 1989] E. Yourdon. Modern Structured Analysis. Prentice-Hall, 1989.

[Yu 1995] E. Yu. Modelling Strategic Relationships for Process Reengineering. PhD thesis, Department of Computer Science, University of Toronto, Toronto, Canada, 1995.

How can Knowledge Technologies become Agile? An...

Documents

Transcript of How can Knowledge Technologies become Agile? An...