A Component Based Conceptual Methodology and Holistic Framework for IT System Implementation and Management. Combining Both the Action Research and Design Science Methodologies

For Review O

nly

A COMPONENT BASED CONCEPTUAL METHODOLOGY AND

HOLISTIC FRAMEWORK FOR IT SYSTEM IMPLEMENATION

AND MANAGEMENT: COMBINING BOTH ACTION RESEARCH

AND DESIGN SCIENCE METHODOLOGIES

Journal: MIS Quarterly

Manuscript ID: 2015-TR-13891

Category: Theory and Review

Keywords: implementation, socio-technical system, method, decision support systems, Information technology management, explanatory, IS development, technical innovation, modeling, software design

MIS Quarterly

For Review O

nly

A Component Based Conceptual Methodology and Holistic

Framework for IT System Implementation and

Management. Combining Both the Action Research and

Design Science Methodologies

Author: Simon Bulgacs BEng PgCert MSc

1/6/2015

2 Cliffe Avenue

Lightcliffe

Halifax

HX3 8TN

West Yorkshire

UK

Tel:0(+44)7796387946

Email:[email protected]

Abstract: In recent years there has been much debate on how technology should be

managed in the work place. This includes standardising IT systems, strategies and

work practices. Due to connectivity and the effect it’s had on the way businesses carry

out activities the debate has become ever more fragmented and complex. The

following paper expositionally describes how a methodology “the componentisation

process” can be applied to IT management issues. Included in the method is

integration of the Design Science Engineering and Action Research methodologies.

Historic arguments are avoided in favour of framework definition and model design

and building. A pragmatic, positivist and epistemological lens is used to survey the

subject as definitions and practical solutions are viewed as more important than just

describing perceived phenomenon.

Keywords: Process Standardisation; Componentisation; Paradigm Shift; Action

Research; Design Science, Object Oriented Design; IT Management; Information

System Implementation.

Page 1 of 35 MIS Quarterly

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

1 Introduction

As information systems (IS) now include IT (information technology) as a

fundamental component (Bulgacs, 2015; Mitroff & Silvers, 2008), how technology is

managed, not only in the work place but incidentally also in the home, has become a

core element in most management based subjects (Schepers & Wetzels, 2006; Wells,

2011). “As business cycles get ever shorter, the pressure to deliver high quality

IT-based solutions quickly and cheaply becomes more intense” (Avison et al., 1998,

p. 4). However information systems as a topic is a contentious issue, this is partially

due to its multi-discipline nature (Hasselbring, 2000; Wood-Harper, 1985). Currently

there are many different ways to approach the subject because of this the discipline

has been described as messy (Sawang, 2008). This is confirmed when IS

implementation management literature is reviewed and the multitude of

methodologies proposed and in use becomes apparent (Goldkuhl, 2013). Bulgacs

(2014a, p.5) claims “This is due to a lack of co-operation between disciplines which

has been caused by researchers and practitioners chasing agendas that profit them

rather than the subject.”, an opinion going back as far as Iilvari et al. (1998). IT

implementation is the key to standardising IS management techniques as this is the

first stage humans (other than developers and engineers) begin interacting with

technology (Bulgacs, 2014a). This initial interaction defines all antecedent and

subsequent issues that relate to technology management. A model needs to be created

that can not only analyse IT implementation methods but also evaluate related factors

and offer solutions. However creating standardised guidelines around a process that in

many cases wont be linear has proven divisive.

Here it will be explained how a method (componentisation) has been

developed that allows model building which includes all facets and factors that

revolve around decision making in relation to IT implementation, management and

maintenance, i.e. a pathfinder technique which points the technology implementer in

the right direction. To those familiar with engineering block diagrams, flowcharts and

algorithms there is nothing particularly revolutionary about the componentisation

method. How it is being applied to aid in decision making processes here is.

“Component-based engineering is of paramount importance for rigorous system

design methodologies. It is founded on a paradigm which is common to all

engineering disciplines: complex systems can be obtained by assembling components (building blocks)” [Gossler et al, (2007), p. 295].

Due to the complexity of the problem being addressed and its multiplicative issue and

evaluative nature any model modified or designed has to be as easily accessible and

understandable by as broad an audience as possible (Hevner & Chatterjee, 2010). This

is too ensure dissemination and adoption.

A re-occurring problem in IS research is that “Technology is not addressed

in SSM [soft systems methodology] to the extent necessary for drawing any

conclusions” (Iivari et al 1998, p. 180). Creating more conceptual models and theory

building that include no practical solutions may well be pointless as many already

exist (Bagozzi, 2007; Straub and Burton-Jones, 2007 & Turner et al., 2010). “Science,

the process of understanding ‘what is,’ may be insufficient for design, the process of

understanding ‘what can be.’” (Hevner & Chatterjee, 2010, p. 13). In the authors

1

Page 2 of 35MIS Quarterly

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

opinion all conceptual aspects of IT implementation and IT management have now

been covered in one study or another. At the time of writing this paper the only

holistic model that exists which addresses all the relevant issues and offers

standardised solutions is Bulgacs’s (2013) software based Information Technology

Implementation Program (ITIP) project.

“An important distinction between lo-fi and hi-fi prototypes is that lo-fi prototypes are “passive” models (paper based) while hi-fi prototypes (software based) are dynamic models with the purpose to expose some kind of behaviour of the future

system.” (Goldkuhl, 2013, p. 15).

It must be noted that comparable methodologies to the ITIP do exist, minus the

interactive software element, but these have been created by individual companies to

target specific contextual problems and have not been tested in different environments

(Peffer et al. 2008). “One of the differences with the ITIP project approach is that it

has equalled the importance of an individual to that of a workgroup or entire

organisation and vice versa.” (Bulgacs, 2015, p. 20). This creates as objective a lens

as possible to survey the field. Sheffield (2005) stated that any further studies into

current IS’s had to combine the three established streams of IS research namely

technology, behaviour and organisation (Cole et al, 2005; Hevner & Chatterjee,

2010). Hence any balanced investigation and study of the subject has to integrate and

in some part consolidate these three subject subsets. It also means any further study

will require researchers to have multiple-skill sets (Hevner & Chatterjee, 2010). Any

study that ‘black boxes’ or sidelines any of the subsets could lead to misleading

results (Fichman, 1992; Wixom & Todd, 2005). As already highlighted there are

sufficient bodies of work in each of these streams for a researcher to reference and

begin holistic model design and/or modification.

As mentioned one issue noted in historic projects is researchers abilities

(Bulgacs, 2014b). Historically there have been many studies that have sidelined

essential factors (Hevner et al. 2004; Stenmark, 2013). Here it is suggested that in

most cases this is because past contributors lacked knowledge in said missing field’s

e.g. why would a social scientist with a background in psychology be interested in

how the electronics inside a computer are designed or function? In relation to

human-technology interaction basic knowledge of this is essential as design and

technical characteristics have to be included in any analysis (Hevner & Chatterjee,

2010). “Even professional researchers, who ought to be ready to welcome change in

taken-as-given structures of thinking, show the same tendency to distort perceptions

of the world rather than change the mental structures we use to give us our bearings.”

(Checkland, 2000, p.18.). Cole et al. (2005) stated that any type of research must

make a dual contribution to both academia and practice. In the following sections it

will be discussed how two different paradigmatic approaches, one technical design

science engineering the other conceptual action research (Iivari et al. 1998) can be

combined to create a new process model for IT implementation and management.

There have been several papers which compare action research with design

science engineering (see Goldkuhl, 2013 for an in depth investigation) however the

aim of this paper is to create the building blocks for a workable model. In the

following sections the conceptual framework and domain limits will be established.

2


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

Then constructing a suitable architecture that allows appropriate components and

decision making functions and processes to be applied. This creates a 3 dimensional

flow chart, more on this in the methodology section.

2 Background and related studies

“Leavitt and Whistler (1958) in Robey and Boudreau (1999) were early researchers

who highlighted the impact innovative technology was going to have on the working

environment.” (Bulgacs, 2013, p. 251.). Over the years as business and individuals

have become ever more reliant on technology many academics and practitioners have

attempted to quantify and define human/IT interaction. As stated in the introduction

these disparate explanations of how to define said human/technology interaction have

resulted in more fragmentation and created a muddled discipline (Avison &

Wood-Harper, 1990a). In many papers, as noted by Conradi et al., (1994), researchers

have referred to variations of the same determinants using terminology from their

own respective disciplines (Cater-Steel et al., 2005; Turner et al., 2010). Although in

the early stages of defining a study/discipline this is necessary by 2015 (in IT

management research) it has become discombobulating, replicates data sets and in

some cases warrants unfruitful research (King and He, 2006; Robey and Boudreau,

1999; Schepers and Wetzels, 2006). As noted by Peffers et al. (2008, p.49.)

“We have recently accepted the use of interpretive research paradigms, but

the resulting research output is still mostly explanatory and, it could be

argued, not often applicable to the solution of problems encountered in research and practice.”

Peffers reiterated that most historic models were conceptual in nature and that any

new model designed had to be practical and include solutions. Seine et al. (2011, p.

38) argued “that there is a need for a research method that explicitly recognizes

artefacts as ensembles emerging from design, use, and ongoing refinement in context”

(artefact in this case means either a computer of IT system). Peffer went on to state

that the value of solutions offered should be evaluated at the inception of the project.

Bulgacs (2014a) broadly described information systems as large technical systems

with social implications whereas Iivari et al. (1998) described them as complex social

systems which technology functions within. It can be seen that conceptualising an IT

implementation from either one of these perspectives would require a completely

different paradigmatic approach. However both paradigms are relevant to the issue

being addressed and to some extent have to be included in any model being created

(Iivari et al. 1998).

In the seventies Rapoport (1970) refined a methodology based in psychology

called Action Research. It involves causing a disruption to a system and measuring

how the system changes in reaction to the disruption (Baskerville, 1999). “Action

Research encourages researchers to experiment through intervention and to reflect on

the effects of their intervention and the implication of their theories” (Avison et al.,

1999, p. 94). Kock et al., (1997) in Burnstein & Gregor (1999, p.126) state “the result

of Action Research is usually associated with the creation of new knowledge about

the system… while at the same time attempting to change it”.

3


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

“Action Research aims to solve current practical problems while expanding

scientific knowledge. Unlike other research methods, where the researcher seeks to

study organizational phenomena but not to change them, the action researcher is

concerned to create organizational change and simultaneously to study the process”

(Baskerville & Myers, 2004, p.329).

Which means

“The researcher is actively involved, with explicit benefit for both researcher

and organization. Second, the knowledge obtained can be immediately applied;

There is not the sense of the detached observer, but that of an active participant

Wishing to utilize any new knowledge based on an explicit, clear conceptual

framework. Third, the research is a (typically cyclical) process linking theory and practice.” (Cole et al. 2005, p. 329).

IS based Action Research sits more comfortably in the organisational science domain

of the IT implementation subject (Wood-Harper, 1985). Some studies have stated that

its more relatable to consultation methodology (Avison et al., 2007; Baskerville,

1999). This is because it is a reactive technique. “This is a major criticism of Action

Research–it does not easily produce generalisable learning” (Wood-Harper & Avison,

2003). Here it is proposed that new components can be added that will formalise the

“open-ended” techniques incorporated making it a more standardised methodology

overall. However a competitive advantage via IT is only sustainable while the IT and

its usage cannot be replicated (Melville et al., 2004).

“As a sustainable source of competitive advantage benchmarking is inherently

suspect since it appears to emphasize the systematic observation and replication of competitive resources rather than the design specific applications” (Powell

and Dent-Micallef, 1997, p.383).

As stated the fundamental methodological constructs of Action Research are based in

psychology (Baskerville & Myers, 2004). This is not conducive to creating a holistic

IS implementation model when factoring in technological characteristics. The

problems this creates can clearly be seen when deconstructing Davis’s (1986)

Technology Acceptance Model (TAM) and its subsequent revisions and modifications

(Abugabah & Sanzogni, 2014; Bagozzi, 2007; Benbesat and Barki, 2007;

Venkatesh, et al. 2003). “Information systems is a multi-perspective discipline and

should have a pluralism of research methods.” (Wood-Harper, 1985, p. 165). Bulgacs

(2014a, p.154) states “attempting to view technological implementation from an

acceptance perspective gives the researcher an impression of a multidimensional if

not infinite subject. It is posited that this is the wrong way to deconstruct IT

implementation methodology.” Due to the human element of technology management

a balance (or re-balance) had to be found between flexible and

prescribed/standardised techniques. In response to these unbalanced approaches

Avison & Wood-Harper (1990b) proposed the Multi-view framework

4


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

“The main motivation for Multi-view was to include these human or organisational

aspects fully into information systems development. But we also wanted to suggest

that information systems development was not a step-by-step, prescriptive process,

but iterative and sometimes applied differently as circumstances dictated.”

(Wood-Harper & Avison, 2003. p. 6)

In practice the multi-view framework is applied using Action Research techniques

(Bell & Wood-Harper, 2003). However as an implementation methodology the

multi-view concept lacks definitive domains and is fuzzy in its determinants and

limits (Iivari et al.1998). This is due to the affect context has on the applied ‘soft

systems’ method. Also diagnosis paths through the multi-view model are unclear and

even confusing due to the models none sequential nature. Although it included

conceptual technology maintenance and modification facets they were

underdeveloped and as in the TAM and comparable models it provides no hard or

quantitative technical solutions. As mentioned these are factors that are essential to

human computer interaction analysis. Later Multi-view 2 was developed in an attempt

to address these issues (Avison et al., 1998). However again it was interpretive in its

approach (Baskerville, 1999) and did not offer standardised solutions.

“The Multi-view framework has been applied in a number of situations. None

describes Multi-view working perfectly in an organization according to prescription, but all have delivered lessons furthering Multi-view development.

Multi-view includes tools and techniques blended into a common approach,

Each used on a contingency basis, that is, as appropriate for each problem situation.” (Avison et al., 1999. p.95).

Some researchers such as Hevner et al. (2004) and Peffers et al. (2008) have

attempted to take a more structured approach to the subject and utilised an

engineering principles. For instance Bulgacs (2013) incorporated the human decision

making process into an interactive software program. “Design Science research is

poised to take its rightful place as an equal companion to natural science research in

the Information Systems (IS) field.” (Hevner, 2007, p.87).

“Design Science, as conceptualized by Simon (1996), supports a pragmatic research paradigm that calls for the creation of innovative artefacts to solve

real-world problems. Thus, Design Science Research combines a focus on the IT

artefact with a high priority on relevance in the application domain.” (Hevner & Chatterjee, 2010, p. 9).

Hevner proposed that an ‘artefact’ could be designed that incorporated processes that

allowed standardised practical solutions to be offered for IT implementation and

management problems. Peffers et al. (2008) agreed and stated that there was enough

published research for a conceptual model to be created. They also stated that the

Design Science Research Methodology (DSRM) could be used in different contextual

settings. The approach generated a standardised method, which is an issue Action

Research practitioners have been struggling with (Seine et al. 2011). However

“Current DR methods are based on stage-gate models in that they separate and

sequence building and evaluation. Thus, they do not support the conditions necessary

5


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

for generating knowledge about the ensemble artefact through design.” (Seine et al.

2011, p. 52).

Hevner (2007, p.88.) describes three cycles or steps incorporated into the

design science process:

1. The Relevance Cycle bridges the contextual environment of the research project

with the design science activities.

2. The Rigor Cycle connects the Design Science activities with the knowledge base

of scientific foundations, experience, and expertise that informs the research

project.

3. The central Design Cycle iterates between the core activities of building and

evaluating the design artefacts and processes of the research.

The relevance cycle is used to identify the problem that is to be addressed and if any

changes will be accepted (this can be achieved using Action Research methodology).

The rigor cycle compares past knowledge, and known methods and solutions, with the

issue being addressed. The design cycle involves creating the actual artefact and the

iterative ‘test and improve’ steps. Again however “Traditional design science does not

fully recognize the role of organizational context in shaping the design as well as

shaping the deployed artefact.” (Seine at al. 2011, p. 38). Hevner and Chatterjee go on

to state that after testing the newly designed IS system if any functionality issues are

identified the researcher can enter the iterative test-redesign cycle. Which is relatable

to the reactive nature of Action Research.

Peffers et al. (2008, p. 81) noted “In Design Science Research, design and

the proof of its usefulness is the central component, while in Action Research, the

focus of interest is the organizational context and the active search for problem

solutions therein.” Furthermore “It would appear that the DSRM could be used as a

structure to present Action Research. Likewise, the search for a designed artefact

could be presented as Action Research. Clearly the side-by-side existence of the two

methodologies presents the researcher with choices for the structure of the research

process and the presentation of the resulting solution”. “ Both research approaches go

beyond pure explanation and understanding and they are associated with improvement

and change.” (AIS, 2013, p.1). The goals of these methodologies (in context) are

essentially the same. So from a bottom up perspective comparisons between the two

can be made. Indeed it has been suggested that one way to address the fragmentation

in information systems research is to integrate the two methodologies (Bulgacs,

2014c; Cole et al, 2005; Jarvinen, 2007; Goldkuhl, 2013). However “There exist

arguments that AR and DR (design research) are of diverse kinds; that AR is a

research method and DR is a research paradigm” (Baskerville, 2008 in Goldkuhl

2013, p.2). “Further research is needed in the area of methodology engineering to see

if such an integrated methodology is feasible” (Iivari et al. 1998, p. 188).

“One approach to achieving more relevance is to conduct research using

appropriate research methods that balance the interests of both researchers and

practitioners.” (Cole et al. 2005, p.325). In relation to Action Research and Design

Science Cole adds “that the two approaches can significantly inform each other as

there is a great degree of similarity and overlap between them, especially since they

are both proactive in that they intervene rather than study a phenomenon after the

fact” (Cole et al. 2005, p. 326).

6


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

Seine et al. ( 2011) suggest that a model can be developed that integrates

both Action Research and Design Science. “A new research method is needed to

conduct DR that recognizes that the artefact emerges from interaction with the

organizational context even when its initial design is guided by the researchers’

intent.” (Seine et al. 2011, p. 40). Action Design Research (ADR) “deals with two

seemingly disparate challenges (1) addressing a problem situation encountered in a

specific organizational setting by intervening and evaluating; and (2) constructing and

evaluating an IT artefact that addresses the class of problems typified by the

encountered situation.” (Seine et al. 2011, p. 40).

The paradigmatic nature of social science captures “the basic assumptions

of coexistence theories; where as in natural sciences, it captures the basic

assumptions of historically successive theories” (Iivari et al. 1998, p. 172).

“Natural science research methods are appropriate for the study of existing and

emergent phenomena; however, they are insufficient for the study of ‘wicked

organizational problems,’ the type of problems that require creative, novel, and innovative solutions.” (Hevner & Chatterjee, 2010, p.13).

“Design as Research encompasses the idea that doing innovative design that results in

clear contributions to the knowledge base constitutes research.” (Hevner & Chatterjee,

2010, p. 15).

“The output from the design science research must be returned into the

environment for study and evaluation in the application domain. The field study

of the artefact can be executed by means of appropriate technology transfer

methods such as action research.” (Hevner & Chatterjee, 2010, p. 17).

The overall goal is attempting to align company strategy with intended IT usage

(Henderson & Venkatraman, 1993) so any new IT system is implemented and

managed with as little difficulty as possible. With what is already known about

predictive analytics (March & Hevner, 2007; McLaren & Buijs, 2011) and technology

acceptance (Davis, 1986) it is proposed that a holistic workable model is now

achievable.

3 Discussion

In the article ‘Information Systems: What Sort of Science is it?’ (Avgerou, 2000) it

was noted that since the early 1980’s fragmentation had and still was occurring in the

IS discipline. Avgerou states this was down to the fact that the technical and

social/organisational aspects involved in IS research had separated. Recently this has

been re-investigated and confirmed by other researchers such as Tan (2013) &

Bulgacs (2013). This fragmented approach has created problems in relation to

discussion and research surrounding new IT implementation and modification. That is

to say that although models and techniques exist that explain and deal with specific

facets of IT implementation such as behaviour (Davis, 1986), human/technology

interaction (Hsu & Lin, 2008) or software functionality and compatibility (Stahl,

2000) there is no individual model, conceptual or practical, that includes all the

factors involved in IT implementation (Bulgacs, 2013; Xiangrong, 2010) which

makes the effectiveness of any of the established models debatable. As noted by

7


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

Hevner et al. (2004); Sawang (2008) & Stenmark (2013) the fragmentation is partially

due to the disjoint between contributors who have ‘black boxed’ technology, most

notably those from the interpretive school of philosophy (Walsham, 1995) and those

researchers from an engineering background who have focused more on technological

characteristics (Avison et al., 1998; Vidgen, et al.,1993). King & He (2006) &

Schepers & Wetzels (2006) confirmed that many current frameworks in use are

replications and modifications of earlier work and have proven contradictory and

misleading in different contextual settings.

3.1 Why is managing human technology interaction in the work place important?

The IS discipline, particularly understanding IT management and human technology

interaction, is relatively new subject in the overall scheme of things. Real study

en-mass only goes back 30 years (Avegerou, 2000). However in 2015 we all interact

with technology at some level. However there is still is no defining model that

explains what these interactions are or how we should interpret them. Historically

models have been created that describe the ‘landscape’ the problems exist within

without offering any ‘hard’ solutions (Goldkuhl, 2013). In relation to these issues

defining the IT implementation process is key hence:

� Why do research and development projects often meet with failure at the

implementation stage, rarely come in on budget or are completed on time with all

requirements fulfilled? (Legris et al., 2002; McManus & Wood-Harper, 2007).

A structured form of innovative software, IT and IS implementation would lower this

rate (Myers, 1995). “Without a strong component that produces explicitly applicable

research solutions, IS research faces the potential of losing influence over research

streams for which such applicability is an important value.” (Peffers et al. 2008,

p.49.). The initial questions that allow these issues to be addressed need to be defined:

1. Why do companies/organisations still have so many problems with IT/software

compatibility?

2. Why is there a disjoint between computer functionality, user ability and/or

engagement?

3. Why do a large percentage of IT implementation projects fail to achieve the

intended goal or entirely?

3.2 What can be done?

In an attempt to address the above questions it becomes clear that any model being

developed should not only standardise and solve implementation issues but also

define the implementation process including terminology (Stahl, 2000). Part of the

reason for the non-unified approach is that currently it is not possible for an individual

or a company to access direct knowledge on IS/IT implementation issues, it is a long

drawn out process that involves personal research and consultations. Partially this is

because design engineers and software architects generally work independently from

IT managers and end-users (Bulgacs, 2014c). In literature there appears to be a

differentiation between practitioner/implementer and researcher (Goldkuhl, 2013).

8


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

This raises another overriding question;

� Should the new model/process being designed be an action research methodology

that includes system design factors or be a system design method that incorporates

socio/political aspects?

Hevner & Chatterjee (2010, p. 18) state “The risk comes when experts in other

research paradigms attempt to apply their standards of rigor to design research

projects in which creative inspiration or gut instinct may lead to design decisions.”

“From a practical standpoint, it is expected that if a new system or method is

constructed it should provide better solutions to IS problems than existing systems or methods – that is, it should be faster, more efficient, more elegant, or

have some other feature that makes it a superior solution.” (Burstein & Gregor,

1999, p.128)

As stated there are many conceptual models which have been utilised in IS based

research this is confounding as most of these work on an expository basis (Peffers et

al, 2008) i.e., they show how a system works but offer no way of improving them or

any solutions to ‘hard’ issues (Straub & Burton-Jones, 2007). Conceptual models are

quantified in some part and presented as guidelines, processes and procedures to

follow. These “guidelines” are attempts to standardise methodology. This is useful to

engineers because standardisation facilitates smooth integration of both off-the-shelf

and custom components during initial development and subsequent maintenance

phases (Hasselbring, 2002).

Terminology use within the IS discipline has become a problem due to

researchers from different academic disciplines using words and terms which,

although familiar to those from the same discipline, can mean something completely

different to a researcher from another. This ultimately creates confusion and

misunderstanding (Bulgacs, 2015). For instance implemented technology has been

referred to as an artefact (Orlikowski and Iacono, 2001) but then the methodology has

also been described as an artefact (Lee, 2007). Here this is considered a mistake, the

technology is exactly that technology or Information Technology, you could go even

further and specifically state that the technological “artefacts” are in fact personal

computers! In relation to using computers to solve problems Iilvari et al. (1998, p.

175) state “As artefacts, they do not describe any existing reality rather they create a

new one”. Hence descriptive analysis and explanations are useful for theorizing and

finding reference points when evaluating which notation and conceptual tools to

include in practical models (Iivari et al. 1998). So clearly selecting as general a

terminology as possible is preferential but what about when you add new factors and

explanations which disciplines language is best to use? Establishing a standardised

language is one of the first steps in defining a discipline. However will a combined

Action Research/Design Science model require the creation of more conceptual tools,

techniques and tasks? Any words that describe these would have to be selected

carefully so as not to add to the confusion.

As the manner in which IT systems function are reliant on the contextual

environment said environment needs to be investigated so specific context is

understood by the researcher. In many cases it is likely that after an initial

investigation ‘off the shelf’ solutions could be offered rather than a customized one.

9


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

However it is no good implementing new technology if no one is willing or able to

use it (Bulgacs, 2014a). Which is why it is so important that environment is included

in any analysis. The human element of managing IT is capricious, variable depending

on context and is hard to define (Hevner & Chatterjee, 2010) never mind incorporate

into a standardised evaluative model. However engineers once had to consider

electricity conceptually as it couldn’t actually be seen. The way it was quantised was

by measuring the effect it had on the environment (Volta, 1800). Attempting to solve

an IT issue from an engineering perspective may not solve the issue in whole or even

in part hence a broader perspective has to be employed. Any new holistic model will

include aspects of both action and design research (AIS, 2013). This should

encapsulate continual modification/refinement of the IT “artefact” not only as it is

being implemented but also after the implementation.

4 Methodology

Engineers often describe different parts of a system as components (Hu, et al. 2005).

This technique could be described as componentisation. Lets say we wish to know

how much energy is required to make a cup of coffee, not only the energy required by

the human but also the brewing process. Once the framework/limits of the issue being

addressed have been defined each step can be broken down into its component parts

(Liew & Sundaram, 2005). Essentially you are creating a flowchart/block diagram of

the actions carried out, energy used in each action and the decisions required to select

the action. In exactly the same way the human decision making process can be

documented.

Figure 1 Decision Tree

Source Time-Management-guide.com (2015)

In the decision making process previous decisions select/affect subsequent decisions

as can be seen in Figure 1 (Liew and Sundaram, 2005).The same process can also be

10


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

applied to technology management. Historically some analysts from a social science

background have stated their dislike of hard engineering approaches (Baskerville,

1999) and have created complete methods for IT management that require the

researcher to have little or no technical knowledge. This is now being recognised as a

mistake which has led to fruitless projects (Bagozzi, 2007). In Action Research every

decision is either predictive/pre-emptive or reactive hence can be mapped as long as

the researcher follows the “guidelines” (Applegate, et al. 1986). Figure 2 shows a

decision making process in relation to data analysis.

Figure 2 Data Analysis

Source: Leek & Penn (2015)

As can be seen from Figure 2 decision support models exist that allow the analyst to

determine an outcome. Using words not just numbers to computationally aid in

decision making is covered by fuzzy logic methodology (Lin & Lee, 1991; Mamdani

& Assillian, 1975; Zadeh, 1996).

In relation to IT implementation developing methodology ad hoc or on the

job is undesirable as it allows the implementer too much leeway to make mistakes and

create non-unified systems (Pries-Heje & Baskerville, 2008). It is also

anti-standardisation. This becomes obvious when you consider the problems software

engineers have in connecting or integrating different information networks

(Hasselbring, 2000). Abstract/ad hoc knowledge used for theorising can be difficult to

model but still has to be included in evaluations. A problem with standardised

11


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

processes and techniques is that they are prone to stifle innovation. In the case of

hardware and software design ad hoc methods are often used to test new ideas.

However designing new technology from scratch during an implementation would be

extremely time consuming and expensive. In any technological implementation

process the model created has to encourage innovation and allow this in analysis,

evaluations and solutions.

Design Science Engineering could be considered a ‘hard’ system and

Action Research a ‘soft’ system. “In the literature it is often stated that ‘hard’ systems

thinking is appropriate in well-defined technical problems and that ‘soft’ systems

thinking is more appropriate in fuzzy ill-defined situations involving human beings

and cultural considerations.” (Checkland, 2000, p.17.). However SSM as Action

Research does not offer technical solutions so its usefulness is questionable. The

componentisation method includes a mixture of both the top down “soft” thinking

management and the bottom up “hard” engineering approaches. Using SSM to draw a

“basic” picture can be useful however. When a researcher starts to break down each

facet noted in the diagram things rapidly start to get messy. This is were software

becomes useful. An analyst can create extremely complex drawings and diagrams

using a computer. Not only this but software based models are easily

altered/modified.

4.1 The Human Element

“Previous models/artefacts haven’t perhaps captured all complexity of the

addressed work practices. There might be important work practice values held by

the practitioners, which are not included in the new design due to their tacit

characteror that they have been explicitly disregarded” (Goldkuhl, 2013, p. 14).

Some form of investigative analysis has to take place. This is because people involved

in the problem situation may have misdiagnosed the problem (Bulgacs, 2014a.).

People have different perspectives hence will view a problem situation differently

(Desanctis, et al. 1987; White, et al. 1980). This analysis can be used to identify

company culture, processes, power bases, technology in use, structure etc. The

researcher needs to be aware when model building that the model itself will need to

be modified as new information and data are discovered. The new information may be

found while carrying out exploratory activities and investigations. The methodology

described here (specifically the elements that revolve around human activity) are not

‘static’, i.e. the definitions do not have to be adhered too rigidly.

From the researchers perspective create a rich picture (Monk & Howard,

1998). Then compare it, by exploratory interviews, with people in the “problem

situations” viewpoint. At the beginning of the evaluation the analyst has to identify

what they think the problem may be within the defined framework. Then by the

process of elimination, factor out all the problems it is not, i.e. If it isn’t a behavioural

issue then it must be either a technological or organisational one. As soon as the

researcher starts modifying the rich picture diagram (and their perception of the

situation) the componentisation process has begun. A useful comprehensive

conceptual tool is CATWOE:

12


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

Clients - customers: ‘beneficiaries or victims affected by the system’s activities’.

Actors - actors: ‘agents who carry out, or cause to be carried out, the main activities

of the system, especially its main transformation’.

Transformation - transformation process: ‘the means by which defined inputs are

transformed into defined output’ (where input is current situation

and output is desired situation).

World view - Weltanschauung: ‘an outlook, framework or image that makes this

particular root definition meaningful’.

Owner - ownership of the system: ‘some agency having a prime concern for the

system and the ultimate power to cause the system to cease to exist’.

Environmental constraints - environmental constraints: ‘features of the system’s

environments and/or wider systems which it has to take as ‘‘given’’.

(Basden & Wood-Harper 2006, p. 62.)

CATWOE is also comparable to object oriented analysis. Both methods use system,

subsystems and wider system (Checkland, 2000). We will not go too deeply into SSM

here as this would distract from the overall purpose of this paper. Transformation is

especially interesting in the CATWOE model as this relates to strategic alignment

between company goals and intended use of technology.

1. You must accept and act according to the assumption that social reality is socially

constructed, continuously.

2. You must use explicit intellectual devices consciously to explore, understand

and act in the situation in question.

3. You must include in the intellectual devices ‘holons’ in the form of

systems models of purposeful activity built on the basis of declared

worldviews. (Checkland, 2000, p.38.)

Any change/improvement process in a company that relates to IT is a dynamic

process that changes as more information is discovered the human element obviously

includes debates with those involved in the situation being investigated “but do not

expect the debate to be tidy or predictable; be deft, light on your feet, ready to follow

where the debate leads, unready to follow any dogmatic line.” (Checkland, 2000, p.

33.) In some respects Action and Design Science research are both qualitative and quantitative. It is the point were these too techniques meet that integration between

the two methodologies can begin.

4.2 Practical framework, architecture and boundaries

Here a method is taken from soft systems analysis (Checkland, 1993; Checkland

2000). This initially requires the person carrying out the analysis to view the system

being evaluated holistically. This is because the componentisation process cannot

begin until the limits or domain of the issue have been defined. The objective of the

evaluation is to make an IT/IS system better somehow. This means viewing the

problem being addressed in the “rich” sense and attempting to include as many facets

and factors as possible (Monk & Howard, 1998). Keeping in mind the three most

important aspects human behaviour/activity, organisation and technology. Soft

systems methodology moves the initial view from a specific problem to “the idea of a

13


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

situation which some people, for various reasons, may regard as problematical.”

(Checkland, 2000, p. 15). However the rich picture itself could create problems later

in the analysis as the researcher is already beginning to define where the issue may be.

This can be solved by allowing each “component” of the diagram to be modifiable.

The initial framework includes the three main aspects of IS management those being

the aforementioned technological, behavioural and organisation. The first question

that needs to be asked is “what is the problem that needs addressing?”. Here it is

suggested that the analyst uses the definitions of technology, organisation and

behaviour defined by Bulgacs’s (2013) ITIP project. The first step is too define the

problem domain and parameters. Here this is IT technology management. The second

is to identify the primary elements. In this case they are behaviour, technology and

organisation. Then issues can be subdivided into components and added to the

specific elements the problem is defined as being. Further more Bulgacs (2014a,

p.154) stated “A reference point needed to be identified that would include all actors

(developers, managers and users) the domain limits were found to be at the point of

sale, i.e., intersection of a person/company selling IT and a person/company wishing

to buy IT”.

To create a set of guidelines or standard process you have to follow the

definitions defined in the domain description/framework. “An application domain

consists of the people, organizational systems, and technical systems that interact to

work toward a goal.” (Hevner & Chatterjee, 2010, p. 17). Once the study framework

has been set the componentization of all incorporated factors can go on virtually

indefinitely starting at the broad domain subject area down to lets say how the brain

functions electro-chemically Once the “problem/issue” has been defined create

possible solutions to it. Seine et al. (2011) suggested building a conceptual

solution/model to a problem initially (Alpha version) then using the information

created in this stage to design an actual system prototype (Beta version), essentially a

simulation.

In AR while carrying out an exploratory activity it is very easy to miss an

essential evaluative factor such as not interviewing the most important person

involved in the companies IT processes. Hence a researcher has to see past the

scenery to view the real environment. The researcher needs to create an

Inter-subjective model (which includes both subjective and objective factors).

“Design research projects are often performed in a specific application context and the resulting designs and design research contributions may be clearly

influenced by the opportunities and constraints of the application domain.

Additional research may be needed to generalize the research results to broader domains.” (Hevner &Chatterjee, 2010, p. 15).

Researchers and practitioners have to be included in an implementation project as this

allows the inclusion of practical as well as technical issues (Bulgacs, 2014a).

“Action design researchers bring their knowledge of theory and technological

advances, while the practitioners bring practical hypotheses and knowledge of

organizational work practices.” (Seine et al, 2011, p. 43). Action Research breaks

down into activities that have to be carried out to solve the problem situation

contextually. “Good design science research often begins by identifying and

representing opportunities and problems in an actual application

environment”(Hevner, 2007, p.89). The final IT

14


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

“artefact” can be viewed as the output of Action Research or Action Research can be

incorporated as a method used to design the “artefact” in Design Science (Seine et al.

2011). Seine described this as the Building, Intervention and Evaluation (BIE)

cycle. The evaluation phase is very important as this is the phase where other actors

can be included in the design process. The overall framework has to allow for

“aligning emerging design principles with their immediate and projected competence

management problems.“ (Seine et al. 2011, p. 48).

Due to the nature of the problem the focus cannot only be on designing

the model alone but some emphasis also needs to be placed on how the methodologies

behind designing the model were developed themselves (Brinkkemper, 1996).

“Researchers outline the accomplishments realized in the IT artefact and describe

the organizational outcomes to formalize the learning. These outcomes can be

characterized as design principles and with further reflection, as refinements to

theories that contributed to the initial design” (Seine et al. 2011, p.44).

The key to understanding the difference between Action Research and Design Science

is not complicated. Look at the titles themselves AR is methodology which is

actionable on and DS is scientific design or using scientific methods to design

something. Action Research requires a researcher to intervene with the system at

some point. In the Design Science process whether either assessing the current system

or when implementing/modifying the IT essentially an intervention takes place. When

comparing and integrating aspects of both the Action Research and Design Science

methodologies the model builder has to ensure contradictory evaluations are not

included in the new model, i.e. if Action Research suggests one type of solution but

Design Science suggests another an analysis will have to be carried out that defines

which evaluation method and solution will sit in the new model better. The model

created has to be able to allow for unanticipated consequences not only on

technological design but also in the working environment.

This is not a paradigm building exercise although some aspects of

paradigm building, particularly in relation to writing the article, are included (Iivari et

al. 1998). Most of the paradigmatic constructs concerning this methodology were

established in Bulgacs (2013) ITIP papers.

4.3 Action research

Due to Action Research’s reactive nature there are several different interpretations

(O’Brien, 2001). Here we are not so interested in these interpretations more the

overall guiding philosophy of the approach. “AR combines theory generation with

researcher intervention to solve immediate organizational problems” (Seine et al,

2011, p. 39). After an initial analysis of the IS, reflection on the results is an essential

part of the AR process. (Cole et al. 2005). The methodology emanates from social

science (Goldkuhl, 2013) and relies on the ability of the person applying the method,

this is due to its participative nature (Baskerville & Myers, 2004). Hence it relies on

the intuition and assumptions made by the IT/IS specialist about what is going wrong

with an IT system and how to improve it (Wood-Harper, 1985).This is problematic

when attempting to remedy technological issues as there will be other IT specialists

elsewhere in the world using Action Research methodology (or a variation of) who

15


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

are coming up with completely different solutions (Wood-Harper & Avison, 2003). It

is essentially an anti-standardisation technique that holistically only propagates IT

standardisation and connectivity issues. The classic definition of AR is localised and

does not create generalisable knowledge (Goldkuhl, 2013).

“AR views organizations as a configuration of interacting variables, some of

which are highly interdependent; to introduce change into this configuration,

one begins with several possible points of intervention and discovers that change may require manipulation of several variables” (Cole et al. 2005, p. 329).

In Action Research it is assumed that you cannot know the best solution to a problem

until an analysis has been carried out (Baskerville, 1999, Coughlan & Coughlan,

2002). However as a researcher will be dealing with some form of standardised IT

system and there have been many publications in the subject it is very unlikely they

will come up with a completely original solution. Hence an experienced researcher

will have a general idea of what will fix the problem before it is diagnosed. Seine et

al. (2011, p. 45) stated “At the time of publication, we reasoned that the methodology

used, canonical action research provided little support for interweaving the building

of the IT artefact, intervening in the organization, and evaluating.”

A noticeable problem is those from a social science background choosing

social, cultural and political solutions to problems over technical ones. “Action

research in local situations is concerned not with social facts but with study of the

myths and meanings which individuals and groups attribute to their world and so

make sense of it.” (Checkland, 2000, p. 42.) Some researchers and practitioners state

that Action Research is a “flexible” technique whereas others argue that it is too open

to interpretation and lacks cohesive rules and processes (Avison, et al, 1999; Bulgacs,

2015; Holwell, 1997). When you consider that the entire issue revolves around using

technology to solve problems it soon becomes apparent how bizarre a position this is

to take. Essentially if you minimise the technological component of IT management,

which exact technology based problems are going to be solved? Soft Systems/Action

Research is already a quantitative methodology at heart, e.g. try to explain to someone

what an in-house IT system is without using technical jargon. Even though some

Action Researchers have tried to avoid a technical focus it clearly isn't possible.

Indeed this is one of the problems with the methodology, it doesn’t really seem to like

itself! Action Research practitioners use mental models to define what individuals are

doing within a process (Checkland, 2000), as mentioned, this is componentising the

issue. Many of those who have published in the subject appear to have lost sight of

this. For a comprehensive investigation no fundamental aspect of the IS being

evaluated can be sidelined or ‘black boxed’. In a way Action Research black boxes

everything initially and only opens the boxes when they are found to be relevant.

“Action research should be conducted in such a way that the whole process

is subsequently recoverable by anyone interested in critically scrutinizing the

research. This means declaring explicitly, at the start of the research, the intellectual frameworks and the process of using them which will be used to

define what counts as knowledge in this piece of research.”

(Checkland, 2000, p. 42.)

16


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

When considering an IT implementation project a model of the organisation and

processes has to be designed Action Research is a much better method to achieve this

than Design Science. What rules should be followed to make the organisational

model? Cole et al. state there are 4 variables associated with Action Research

approaches these are tasks, technology, structure and people. “Each variable may

have its own associated change strategies; however due to their high degree of

interdependence it is unlikely that any one can be changed without impacting others.”

(Cole et al. 2005, p. 329). Investigative actions to be carried out by a researcher

(based on behaviour and employees activities:

Source: Checkland (2000, pp. 21.)

The list above is basically strategy alignment i.e., What are the companies goals and

what is required of the technology? and has to include a competence and ability

assessment (Bulgacs, 2014b). “Properly executed, competence management ensures

that employees have access to the competences necessary for helping the organization

to reach its objectives.” (Seine et al, 2011, p. 45). Training people to interact with

technology in the “right” way i.e., we have all seen a family member or friend attempt

to use new technology by simply pressing any button on clicking on any link, then

making the claim “there is something wrong with this”. Strange as it may seem, from

a design perspective, they are actually correct. As the intention of technology is to

make peoples life easier. The next button pressed should indeed make the computer

do exactly what the user wants it too.

Susman and Evered’s five phases of Action Research methodology (Cole

et al. 2005, p. 331).

1. Diagnosing, is aimed at identifying of defining a problem.

2. Action Planning, involves considering alternative courses of action for solving

the problem

3. Action Taking, consists of selecting a course of action.

4. Evaluating, is aimed at studying consequences of action.

5. Specifying Learning, completes the loop by identifying general findings.

In essence the above steps are what everyone does when a problem arises and they

attempt to solve it.

17


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

Table 1 Canonical Action Research Criteria .

Source: Cole et al. 2004, p. 331.

Criterion 2 is Susman and Evered’s 5 phase model.

“Under the CPM, the researcher conducts an independent diagnosis of the

organization, plans actions based on that diagnosis, and then implements and

evaluates those change actions. Following a change intervention, the researcher

reflects on intervention outcomes and makes an explicit decision whether to proceed through an additional change cycle.” (Cole et al. 2005, p. 231).

The continual evaluation of the effects that environment and context (particularly

human-human and human-technology interaction) have on the design process is

something that is lacking in typical design led approaches (Greenberg & Buxton,

2008; Redish, 2007). “The iterations stop either when the organization decides to

adopt or reject the ensemble artefact, and/or when the contributions of additional

cycles are marginal.” (Seine et al, 2011, p. 42). Most notable is the fact that in Action

Research the change cycle generally either involves training of staff or modifying the

technology both of which are relatable to Design methodology. However from a

design perspective includes the introduction of a possible prototype IT artefact/system

(McLaren & Buijs, 2011).

4.4 Design Science

“Design Science “is fundamentally a problem-solving paradigm. It seeks to

create innovations that define the ideas, practices, technical capabilities, and

products through which the analysis, design, implementation, and use of

information systems can be effectively and efficiently accomplished”.

(Hevner and Chaterjee 2010, p.11).

Design Science research emanates from the engineering disciplines (Goldkuhl, 2013).

“Engineering research culture places explicit value on incrementally effective

applicable problem solutions” (Peffers et al. 2008, p. 49). “One of the defining features of the design science approach is that the evaluation of the new IS artefact

involves broadly answering the question ‘How well does it work?’ rather than merely

how valid or a reliable it is” (Mclaren & Buijs, 2011, p.3.). One of the advantages of

the Design Science approach is that it is a method familiar to those involved in design

18


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

of any description such as engineering, architecture and the arts (Hevner, 2007).

Which is to say the designer generally has some idea what the final artefact will be

(even a painter knows that the final outcome will not be a song but be a painting of

some description).

“Design, the act of creating an explicitly applicable solution to a problem, is an accepted research paradigm in other disciplines, such as engineering, it has been

employed in just a small minority of research papers published in our own best

journals to produce artefacts that are applicable to research or practice.” (Peffers et al. 2008, p. 49.)

Design science research aims to create prescribed solutions to problems utilising

standardised processes and techniques (Goldkuhl, 2013). “This articulation of the

class of problems, the class of solutions, and the design principles for this class

directly satisfied Action Design Research’s generalization principle.” (Seine et al.

2011, p 50). Historically the Action Research and Design Engineering paradigms

have evolved separately from each other (Cole et al. 2005).

“Justifying the value of a solution accomplishes two things: it motivates the

researcher and the audience of the research to pursue the solution and to accept

the results and it helps to understand the reasoning associated with the

researcher’s understanding of the problem. Resources required for this activity

include knowledge of the state of the problem and the importance of its solution.”

(Peffers et al. 2008, p.60).

“In the early 1990’s the IS community recognized the importance of Design Science

Research to improve the effectiveness and utility of the IT artefact in the context of

solving real-world business problems.” (Hevner & Chaterjee, 2010, p.9). As with

many engineering projects initially Hevner at al. (2004) did not include a theorize

and justify phase. “The main result from design research is the artefacts designed”

(Goldkuhl, 2013, p. 10). However how is an Engineer supposed to conceptualise a

technical solution to a problem with out “theorizing”. This is a major oversight in

Goldkuhls study. The difference between an engineer and a social scientist

conceptualising a problem is that an engineer generally does not consider abstract

concepts. In many respects conceptual models are a form of knowledge engineering.

In the case of designing standardised IT implementation formulas and techniques

abstract concepts are nigh on useless. That is to say an engineer can only analyse

variable abstract factors they cannot evaluate them. Hence they will view any kind of

abstraction in designing a standardised model as pointless. “The main reason for this

lack of attention is probably due to the fact that conceptual modelling is more of an

‘art’ than a ‘science’ and therefore it is difficult to define methods and procedures”

(Robinson, 2008, p.281.). However design engineering is fed by behavioural research

e.g. ease of use.

19


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

Figure 3 Complementary nature of design science and behavioural science research

Source Hevner & Chatterjee (2010, p. 11)

Creating an IT implementation reference model creates interoperable cross discipline

knowledge see Figure 3. “Few DR [design research] efforts have attempted to balance

the conflicting demands of (1) addressing a class of problems, and (2) intervening in

authentic settings” (Seine et al. 2011, p. 39). In both Action Research and Design

Science there are guidelines and or rules that follow a logical sequence. That is to say

that information is required to complete an evaluation before the next step can be

taken, this is essentially a decision. Hence All the above Design Science and Action

Research guidelines and principles can be broken down into said decisions and

“componentised”. All that needs to be know by the researcher is “What information is

required to make the next decision and is this action or design related?”.

4.5 Componentisation

In the IS context componentisation is not a closed loop system. If the solution to an IT

problem includes behavioural aspects these can be included. “Models from the design

process can be divided into diagnosis-models (as-is) and design-models (to be)”

(Goldkuhl, 2013, p. 20). Defining conceptual objects in our mind is converting the

understanding of a problem into a component. We place these individual pieces of the

problem together to form the whole. Each component not only includes factors and

aspects as inputs and outputs but a function element that can be used to evaluate said

inputs and outputs. Essentially each component is used to make a decision.

The computerised based component function Figure 4 looks similar to a

mathematical based function but is not the same. The function of the component is

making decisions based on the users I/P (input). It is emulating thought process’s all

humans use. A notable difference between the two functions: Mathematically A + B =

C is fundamentally different to semantically stating blue and yellow becomes green.

There can me many inputs and outputs but more on this later.

20


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

Figure 4 Single component and function

Just as in rich picture building if a facet or connection between issues is identified as

being incorrect any single component can be removed or redesigned. This essentially

makes the systemic model dynamic not static as some have claimed (Checkland,

2000). The component in Figure 4, in this case, is asking if the condition of the

function is met. However this does not always have to be the case for the component

to decide if a workable output can be evaluated. Remember that the aim of the overall

system is to use the input data/information to reach a reasonable diagnosis/solution.

Do the input values meet the condition to active the output? This does not have to be a

simple yes/no decision. The function can be designed to work on percentages e.g. how

likely it is (due to previous inputs) that a solution can be evaluated. Due to this not all

components require actual data to me input by the user. Some components analyse

information rather than evaluate it. Due to advances in data science and predictive

modelling we are no longer in an age where predicting how people will react is such a

“grey” area (Guazzelli, et al. 2009; Shmueli & Koppius, 2011). An issue that has been

raised about the componentisation method is that they could be used to turn humans

into faceless functional automated entities (Bulgacs, 2014a, Iivari et al. 1998).

A messy problem that some claim cannot be solved using hard engineering

methods but only by soft systems thinking can clearly be approached from an

engineering viewpoint (Brinkkemper, 1996). Indeed this has happened many times.

What IS researchers from a sociological background haven’t grasped is that

engineering problems themselves (particularly in software) are not viewed as static

but dynamic. That is to say that a microchip has parameters it needs to work within

not just specific voltages. Currents have to be taken into account, what the computer

code is doing in previous chips, etc. Also as the complexity of software programs

grows so do the engineering principles that describe them. Hence engineering in this

case is not just about simplifying but also expanding limits and boundaries.

As we know humans like to pigeon hole objects/concepts and processes as a

way of describing/defining them. Essentially, as mentioned, what humans are doing

when they do this is componentising.

21


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

“Designed physical systems are distinguishable from natural systems by

virtue of their teleological causal component; physical systems are

designed with fitness of purpose in mind, created to pursue certain ends

and evaluated on the basis of conscious selection of alternatives.”

(Cole et al. 2005, p. 327).

Componentisation facilitates standardisation processes. The technique relates to

object oriented software design and the methodology Bulgacs (2013) utilised to create

an interactive sequential computer program. Componentisation takes an abstract

conceptual theory and via analysis and scientific method turns said theory into a set of

rules or guidelines which a researcher/practitioner can follow to aid in the

implementation of new technology and/or IT management methods and techniques.

SSM is initially very general, particularly rich picture design, it does not incorporate

specific factors easily. Componentising solves this problem. The components can be

connected in the same manner as a flow chart or block diagram. “We use the term

business intelligence to refer to inferences and knowledge discovered by applying

algorithmic analysis to acquired information.” (March & Hevner, 2007, p. 1032). This

essentially creates a conceptual road map of actions and procedures to carry out in

relation to implementing/evaluating/managing technology. The first stage of

componentisation in relation to the issues being addressed here is to acknowledge the

three distinct areas involved, those being human behaviour, technology and

organisation. From these three initial components all other sub-components can be

incorporated.

Figure 5 Componentisation Process

22


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

In Figure 5 the squares are the components themselves F1, F2, F3 & F4 are the

functions within. Each function is different, for instance in relation to information

systems the component with function F1 could be deciding if the problem is

technological, organisational or behaviour. Hence F2 could be the decision subsystem

that allows the researcher to evaluate technical issues. F3 could be the subsystem/set

of components that deals with organisational issues and F4 would then be the

component set that addresses behavioural issues. None of the functions should lead to

a decision that takes you out of the problem situation (if it does modify it so the

output brings it back). The boundary should have been defined while designing the

rich picture. Of course this doesn’t mean that the boundaries cannot be modified when

new information is discovered during the investigation. S1, S2 & S3 represent

solutions to individual problems after the evaluation. As can be seen F2, F3 and F4

are interconnected this allows for an issue that is initially mistakenly defined as

behavioural to be changed to either organisational or technological solution path when

misdiagnosis is noted. A decision path through Figure 5 could be: Input→ F1→ F4 →

F3→ F2 → S1. Of course this would depend on the decisions being made and the

information input into each component. Each function can request new information to

be input/supplied however for ease of explanation and clarity this has been omitted

from Figure 5.

“Organizational routines are intended to provide guidance to human action within

prescribed organizational contexts. Yet even such artefacts are appropriated and

adapted by humans in ways and for purposes that the designers may not have

envisioned” (Hevner & Chatterjee, 2010, p. 14).

One way to explain how actions are converted to components and functions is this:

Two workers are interacting with a process, one of them is happy the other sad. The

sad worker is more efficient than the worker who is happy. Hence the happy

individual is not interacting with the process as well as the person who is sad. Once

physical condition of the happy worker has been eliminated the assumption has to be

that they are working more slowly that the person who is sad because they are less

focused on the job. Hence emotional state is the factor that needs to be analysed. Why

does being happy make the worker less efficient? There are a set amount of reasons

that could cause this such as the happy worker is being distracted, are they

daydreaming or generally thinking about something else. The causes of the workers

happiness and sadness is irrelevant at this stage. In this scenario the function of

emotion is what affects efficiency. Essentially the problem has been factorised by the

process of elimination. Something some sociologist claim engineering methodology

isn’t able to do (Checkland, 2000). The answer to this problem is to make the happy

worker focus on the job and think less about the things that are making him happy.

This will probably make the worker sad but subsequently more efficient.

How the researcher wants to design their component based model is up to

them. As mentioned these are guidelines not strict rules. For instance a component is

not limited to the amount of inputs or outputs (see Figure 6). The researcher (after

defining the domain) need only be concerned about identifying, classifying then

placing the problem in the correct component that allows analysis to be conducted and

that the evaluation happens at the right time in said analysis path (Bulgacs, 2013,

Seine et al. 2011).

23


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

Figure 6 Multiple inputs and outputs

Figure 6 allows a much more complicated component system to be designed. Relating

to mathematics you could have A + B + C = O/P is < n, > n, or = n. Or even more

complex verbal evaluations such as O/P is either true, false or undecided (for

undecided the next component function can request more information if necessary).

Eventually if the decision making process that leads to a solution or diagnosis is

complex the researcher ends up with what is essentially a matrix or Eigen diagram.

Which will include multiple pathways and components inside components and

sub-systems within subsystems. This can all be mapped logically into a component

based diagram. The function can be as complicated as necessary. For instance the

function of a medical doctor is to heal people. This is obviously a complex function

and contains multiple sub-functions and systems.

Figure 7 Evaluation function as in the ITIP

Source: Bulgacs, S. (2014, p. 359)

From Figure 7: Q1. Is the first question asked, the user inputs the information/data

requested. It is stored in memory. In this case the function requires three sets of

24


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

information/data for the evaluation to process, hence two more questions Q2 and Q3

are asked. Once the user has input the information the function can carry out the

evaluation and then open the next question set. This process is repeated until the

program converges on a solution. As can be seen this connects together the decision

making diagram in Figure 1 and the componentisation diagram in Figure 7.

Essentially each function is asking what decision needs to be made and what

information is required to make the decision. The researcher/analyst needs to order

the questions in relation to what is perceived to be highest to lowest relevance.

However the order may need to be changed or an evaluation/component modified or

redefined later in the analysis. Essentially the information gained from asking one set

of questions selects the next set of questions asked (sequential). The Iterative IS/IT

design cycle needs to be adaptable to the contextual socio-political environment the

IT “artefact”/system is going to function within. The results of any system

intervention can be analysed and used to guide the design process and aid in

generating innovations. “Various forms of the organizational context are thus

inscribed into the artefact during its development and use.” (Seine et al. 2011, p. 40).

“The emerging artefact, as well as the theories ingrained in it, are continuously instantiated and repeatedly tested through organizational intervention and

subjected to participating members’ assumptions, expectations, and

knowledge. This highly participatory process builds organizational commitment and guides the eventual design of the ensemble artefact.”

(Seine et al. 2011, p. 42).

Any model created has to be understood and usable by both technologists and

managers (Hevner & Chaterjee, 2010). It is no good going all technological when an

average business manager needs to understand explanations and vice versa.

5 Methodology comparison.

Every company has a business architecture that can be used to describe all the

processes, tasks, activities, hierarchies, departments, functions etc. that exist within it

(McMillan, 2002). As stated each of these individual descriptions can be

componentized and connected using object oriented techniques. However consensus

on the steps/inter-connections of how the activities related to IT management and

implementation should be ordered is elusive (Seine at el. 2011). Peffers et al. (2008,

p.46.) conceptually componentised the steps utilised for design science research thus;

The DS process includes six steps:

1. Problem identification and motivation

2. Definition of the objectives for a solution

3. Design and development

4. Demonstration

5. Evaluation

6. Communication

25


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

Table 2 Design Science research Guidelines (Hevner & Chatterjee, 2010, p. 12)

Source: Hevner & Chatterjee, 2010, p. 12.

When the guidelines in Table 2 are compared to those used in Action Research the

similarities are evident. However Design Science focuses on solutions and

describing/defining the situation as a way to achieve this. In Action Research

description and definition are a goal in there own right. Historic explanations of both

Action Research and Design Science have been presented in a linear fashion

A→B→C→D. In reality in regards to IT/IS implementation and management the

steps could just as easily be A→C→B→D. Action Research particularly Multi-View

has attempted to incorporate this non linearity but not in a specific enough manner,

whereas Design Science is flexible in some aspects but in others far too rigid. It is

suggested that a researcher uses a non linear checklist, i.e., the order in which research

activities and analyses are carried out can vary depending on the information that is

required to make the next evaluation. Essentially the process of componentisation

means that you place all objects that are similar in nature in the same element

(irrespective of historic definition). That is identify stages that lead to correct

diagnosis of problem or set of problems (this includes the contextual situation and

environment). On initial investigation it is important to identify not only technical

characteristics but also behaviour and activity patterns (Checkland, 2000). This can be

described as breaking the initially defined main components down to sub-components

and identifying interconnections between.

26


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

For instance in Bulgacs’s ITIP program all issues that related to

organisation go into the organisational components of the program. This can be

broken down even further. Hence, if an issue is perceived/defined as both an

organisational and technological problem the program will evaluate whether the

solution is more likely technical or business process (from the answers already

supplied by the target or by asking a few more questions) and will follow the

appropriate path to diagnosis. Essentially creating an organisational and technological

issues sub-component. Following this logic the process can prioritise. So if the

solution to what was described as a technological problem were based more in the

organisational field it would be defined as an organisational, organisational,

technological issue. If the solution for an organisational issue was based more in the

technological field this could be defined as technological, technological,

organisational.

Table 3 Design Science research checklist

Source: Hevner & Chatterjee, 2010, p. 20)

As shown in Table 3 technologists may develop a prototype version of a system to

test before the actual implementation (McLaren & Buijs, 2011). For developers this is

usually standard procedure which relates to the test and analysis cycle of the final IT

system (March & Storey, 2008). However prototyping would only be considered at

the end of an Action Research investigation. In many cases it would appear that

Action

27


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

Researchers are relying on prescribed technical solutions or off the shelf products

rather than developing their own. But consider this, testing a prototype is intervening

in the situation and watching for reactions. As highlighted the major difference

between Design Science and the Action Research methodologies is that one is based

in social and the other in natural science. Obviously this involves massively different

paradigms and techniques but as the issue being addressed is solving IT problems we

already have some basic architecture to work with. For instance to solve any problem

an individual will have to follow a decision making process. As proven this process

can be mapped. We now have a base for combining the two methodologies.

6 Conclusion

Due to the purpose and scope of this paper there haven’t been any empirical cases

used for illustration and validation. The study has been conducted as a conceptual

inquiry. Its aim was to create the foundation for advanced model building using

software design techniques to aid in decision making. Neither the Action Research or

Design Science models can be described as wrong but technical aspects are missing

from AR and behavioural/organisational factors missing from DS. In context they are

both useful but essentially flawed. There are many commonalities in the processes

and guidelines both AR and DS utilise, indeed they share root topography. Above

some of these defining characteristics have been highlighted. Hence it is not sensible

to disregard aspects of either. More selecting which activities from both, alone or

combined, are the quickest and most efficient route to finding a solution to an IT

problem.

Some researchers have attempted to “distance” their work from that of

engineers preferring the fuzzy approaches of social science. However as soon as they

begin describing/defining an issue, process or object, as mentioned, they are

essentially componentising the problem. Some may argue that the componentisation

method is actually an object oriented software engineering design tool, which of

course it is. However it relates to artificial intelligence and the decision making

process and as we know human knowledge and intelligence is fuzzy.

“For findings to be accepted as part of the body of ‘scientific knowledge’

they have to be repeatable, time and again, by scientists other than those who first

discovered them.” (Checkland, 2000, p. 42.) This is a major flaw in much Action

Research as it offers no hard solutions. Hence how do you judge how successful an

intervention has been? This is solved by combining it with elements of Design

Science engineering and vice versa. Here a note has been taken from AR and it relates

to context. This is that how the researcher constructs their own methodology is totally

reliant on the actual problem being addressed. For standardisation of techniques and

processes expository descriptions of situations are only partially helpful. Where as

holistic technical explanations give researchers rigid parameters to work within

(Hevner et al, 2004). At this point in time less emphasis has to be placed on

expository definitions which mainly only explain the situation and more on technical

definitions that not only explain the problems but also offer hard solutions (Peffers, et

al. 2008).

28


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

“While theories can serve as sources of creative ideas, to insist that all design

research must be grounded on descriptive theories is unrealistic and even harmful

to the field when good design science papers are rejected in top journals due to lack

of a grounding theory.” (Hevner, 2007, p. 90).

To say that the IT implementation process can not be standardised if of course

nonsense. The technology itself will be a “standardised” system of some description

(Mclaren & Buijs, 2011). What those from a sociological and psychological

background have a problem with is attempting to predict what these standards will be.

It is believed that this is down to them not understanding the technology itself. Hence

avoiding the topic in discussions and analysis. Terms and descriptions used to define

human-technology interaction need to be consensually agreed (Brinkkemper, 1996;

Bulgacs, 2015), this however is beyond the scope of this paper. Those practicing the

discipline also need to accept that some historic models are dead ends. For instance

some journals are still publishing articles that relate to “testing” the Technology

Acceptance Model (TAM). As a method, which does not offer any solutions it is

generally accepted TAM is useless overall (Bagozzi, 2007; Benbesat and Barki, 2007;

Bulgacs, 2014a). A partial methodology or description is practically useless when

considered with other facets of the issue. “The artefact must eventually reflect

intended as well as unintended organizational consequences.” (Seine et al. 2011, p.

40). For instance sometimes fixing the company is what is required to “fix” the

individual. Hence a method that only addresses, say technical issues is undesirable

from a business complexity perspective (where costs are paramount). The model

designed has to be flexible however this does not mean it cannot be presented in

component format. As shown above each component in the method can have its

function modified, redesigned to even removed completely. The componentisation

methodology includes technical design aspects many have complained are lacking

from Action Research (Wieringa & Morali, 2012).

“More and more frequently business decisions are made relying on

information from computer-based analysis and recommendations.” (Hevner &

Chatterjee, 2010, p.14). The componentisation guidelines meet the criteria to form the

basis of new model in Information Systems management. The criteria being the

integration of Action Research and Design Science. It can not only be used to

diagnose issues but ultimately offer both soft and hard solutions to a problem. If no

exact solution can be found, due to say the company having unrealistic demands it can

offer best possible “improvement”. It proves that the methodologies can be combined

into a meta-model and, if not important for reaching a final decision, irrelevant facets

of both can be ignored .

.

29


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

References Abugabah, A. & Sanzogni, L. (2014) Exploring Factors Affecting End-user Performance

of Information Systems. International Journal of Infonomics, Vol 7, No.3,

pp. 956- 973. AIS (2013) Action Research and Design Research Integrations. Milano. Workshop and call

for papers. [online] http://www.vits.org/uploads/SigPrag2013/CfpSIGPrag2013.pdf.

(Accessed 26/7/14). Applegate, L. M., Konsynski, B. R., & Nunamaker, J. F. (1986). Model management

systems: Design for decision support. Decision Support Systems, Vol. 2 No.1,

pp. 81-91.

Avgerou, C. (2000) Information Systems: What Sort of Science is it? Omega, Vol. 28, No.5,

pp. 567-579.

Avison, D., Baskerville, R., & Myers, M. D. (2007). The Structure of Power in Action

Research Projects. In Information Systems Action Research (pp. 19-41).

Springer US.

Avison, D., Lau, F., Myers, M. & Nielsen, P. (1999) Action Research. Communications of the ACM, Vol.42, No.1. pp. 94-97.

Avison, D. & Wood-Harper, T.(1990a) Information Systems Development Research:

An Exploration of Ideas in Practice. The Computer Journal, Vol. 34, No. 2, pp. 98- 112.

Avison, D. & Wood-Harper, T (1990b) Multi-view: An Exploration in Information

Systems Development. Maidenhead: McGraw-Hill. Avison, D., Wood-Harper, T. & Vidgen, J. (1998) A Further Exploration into

Information Systems Development: The Evolution of Multiview2.

Information Technology & People, Vol. 11, No.2, pp.124-139.

Bagozzi, R.P. (2007) The Legacy of the Technology Acceptance Model and a Proposal

for a Paradigm Shift. Journal of the Association for Information Systems,

Vol. 8, No. 4, Article 7, pp.244–254.

Basden, A. & Wood-Harper, T. (2006) A Philosophical Discussion of the Root Definition

in Soft Systems Thinking: An Enrichment of CATWOE. Systems Research and

Behavioural Science. Vol. 23, No. 1, pp. 61- 87.

Baskerville, R. (1999) Investigating Information Systems with Action Research. Communications of the AIS, Vol.2, No. 19, pp. 1- 32.

Baskerville R, Pries-Heje J, Venable J (2009) Soft design science methodology, in

Proceedings DESRIST ’09, Malvern

Baskerville, R. & Myers, M., D. (2004) Special Issue on Action Research in Information

Systems: Making IS Research Relevant to Practice-Foreword. MIS Quarterly.

Vol. 28, No.3, pp. 329-335.

Bell, S. & Wood-Harper, T. (2003) How to Set up Information Systems a Non-Specialists

Guide to the Multi-View Approach.. USA: Earthscan Publications.

Benbesat, I. and Barki, H. (2007) Quo Vadis, TAM? Journal of the Association for Information Systems, Vol. 8, No. 10, pp.211–218.

Brinkkemper, S. (1996). Method engineering: engineering of information systems

development methods and tools. Information and software technology, Vol. 38, No.4, pp. 275-280.

Bulgacs, S.(2013) The First Phase of Creating a Standardised International Innovative

Technological Implementation Framework/Software Application. The International Journal of Business and Systems Research, Vol. 7, No. 3, pp. 250-255.

Bulgacs, S.(2014a) The Second Phase of Creating a Standardised International Information

Technology Implementation, Modification and Maintenance Software Application:

The ITIP Project. The International Journal of Business and Systems Research,

Vol. 8, No. 1, pp. 145-178.

Bulgacs, S.(2014b) The Third Phase of Creating a Standardised International


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

Information Technology Implementation, Modification and Maintenance Software

Application: The ITIP Project. The International Journal of Business and Systems

Research, Vol. 8, No. 2, pp. 315-378.

Bulgacs, S. (2014c) Developing a Standardised Information System/IT

Implementation Management Tool/Method. [online] https://independent.academia.edu/SimonBulgacs (Accessed 26/1/15).

Bulgacs, S.(2015) The Fourth Phase of Creating a Standardised International

Information Technology Implementation, Modification and Maintenance Software Application: The ITIP Project. The International Journal of Business and Systems

Research, Vol. 9, No. 1, pp. 1-31.

Burstein, F. & Gregor, S. (1999) The Systems Development or Engineering Approach

to Research in Information Systems: An Action Research Perspective.

Proceedings The 10TH Australasian Conference on Information Systems.

Australia, pp. 122- 135.

Cater-Steel, A., Rout, T. and Toleman, M. (2005) Addressing the Challenges of Replication

Surveys in Software Engineering Research, IEEE.

Checkland, P. (1993) Systems Thinking, Systems Practice, John Wiley and Sons, West

Sussex, England. Checkland, P. (2000) Soft Systems Methodology: A Thirty Year Retrospective. Systems

Research and Behavioural Science, Vol. 17, No.1, pp. 11-58.

Cole R, Purao S, Rossi M, Sein M (2005) Being Proactive: Where Action Research meets Design Research, Proceedings of the Twenty-Sixth International Conference on

Information Systems, Las Vegas, p 325-336

Conradi, R., Fernstrom, C. and Fugetta, A. (1994) A Conceptual Framework for Evolving Software Processes, in Finkelstein, A., Kramer, J. and Bashar, A.N. (Eds.):

Software Process Modelling and Technology, John Wiley and Sons, West

Sussex, England. Coughlan, P., & Coghlan, D. (2002) Action research for operations management.

International Journal of Operations & Production Management, Vol. 22, No. 2,

pp. 220-240. Davis, F.D. (1986) A Technology Acceptance Model for Empirically Testing New End-User

Information Systems: Theory and Results. Doctoral dissertation, MIT Sloan

School of Management, Cambridge, MA. Desanctis, G., & Gallupe, R. B. (1987). A foundation for the study of group decision

support systems. Management science, Vol. 33, No, 5, pp. 589-609.

Fichman, R.G. (1992) Information Technology Diffusion: A Review of Empirical Research,

ICIS (92) Proceedings of the Thirteenth International Conference on Information

Systems, University of Minnesota, Minneapolis, USA, pp.195–206.

Goldkuhl G (2013) Action research vs. design research: using practice research as a lens

for comparison and integration, accepted to the 2nd Workshop on IT Artefact

Design & Workpractice Improvement, Tilburg

Gössler, G., Graf, S., Majster-Cederbaum, M., Martens, M., & Sifakis, J. (2007). An

approach to modelling and verification of component based systems. In SOFSEM

2007: Theory and Practice of Computer Science (pp. 295-308). Springer Berlin

Heidelberg.

Greenberg, S., & Buxton, B. (2008). Usability evaluation considered harmful (some of the time). In Proceedings of the SIGCHI Conference on Human

Factors in Computing Systems, pp. 111-120.

Guazzelli, A., Stathatos, K., & Zeller, M. (2009). Efficient deployment of predictive analytics

through open standards and cloud computing. ACM SIGKDD Explorations

Newsletter, Vol. 11, No, 1, pp.32-38.

Hasselbring, W. (2000) Information system integration. Communications of the

ACM, Vol 43, No.6, pp. 32-38.

Hasselbring, W. (2002) Component-Based Software Engineering. In S.K. Chang (ed.):

Handbook of Software Engineering and Knowledge Engineering, vol. 2, World


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

Scientific Publishing, New Jersey, pp. 289-305.

Henderson, J.C. and Venkatraman, N. (1993) ‘Strategic alignment: leveraging

information technology for transforming organizations’, IBM Systems Journal,

Vol. 32, No. 1, pp.4–16.

Hevner, A. (2007) A Three Cycle View of Design Science Research. Scandinavian

Journal of Information Systems, Vol. 19, No. 2, pp. 87-92.

Hevner A, & Chatterjee S (2010) Design research in information systems. Theory and

practice, Springer, New York

Hevner, A.R., March, S.T., Park, J. & Ram, S.(2004) Design Science in Information Systems

Research. MIS Quarterly, Vol. 28, No. 1, pp. 75-105.

Holwell, S. E. (1997) Soft systems methodology and its role in information systems,

Ph.D. Dissertation, Lancaster University, UK. Hsu, C.H. and Lin, J.C.C. (2008) Acceptance of Blog usage: the roles of technology

acceptance, social influence and knowledge sharing motivation. Information

and Management, No. 45, pp.65–74. Hu, X., Zeigler, B.P. & Mittal, S (2005) Variable Structure in DEVS Component-Based

Modelling and Simulation. Simulation, Vol. 81, No. 2, pp. 91-102.

Iivari, J., Hirscheim, R. & Klein, H.(1998) A Paradigmatic Analysis Contrasting

Information Systems Development Approaches and Methodologies.

Information Systems Research, Vol.9, No.2, pp. 164-193.

Järvinen P (2007) Action research is similar to design science, Quality &

Quantity, Vol 41, p 37–54

King, R. and He, J. (2006) A Meta-analysis of the Technology Acceptance Model.

Information and Management, May, Vol. 43, No. 6, pp.740–755 [Sourced from

Google Scholar 11/11/11].

Lee A (2007) Action is an artifact: What action research and design science offers

each other, in Kock N, (Ed. 2007) Information Systems Action Research. An Applied View of Emerging Concepts and Methods, Springer.

Leek, T. & Peng, R. (2015) What is the Question? Science, Vol. 347, No. 6228,

pp. 1314-1315. Legris, P., Ingham, J. and Collette, P. (2002) Why do People Use Information Technology?

A Critical Review of the Technology Acceptance Model. Information &

Management, Vol. 40, No. 2003, pp.191–204. Liew, A. and Sundaram, D. (2005) ‘Complex decision making processes: their model and

support’, Proceedings of the 38th Hawaii International Conference on System

Sciences 2005. Lin, C. T., & Lee, C. S. G. (1991). Neural-network-based fuzzy logic control and

decision system. Computers, IEEE Transactions on, Vol. 40, No. 12,

pp. 1320-1336.

Mamdani, E. H., & Assilian, S. (1975). An experiment in linguistic synthesis with

a fuzzy logic controller. International journal of man-machine studies,

Vol. 7, No. 1, pp. 1-13.

March, S. & Hevner A. (2007) Integrated Decision Support Systems: A Data

Warehousing Perspective. Decision Support Systems, Vol. 43, No. 2007,

pp. 1031-1043.

March, S. & Storey, V. (2008) Design Science in the Information Systems Discipline: An Introduction to the Special Issue on Design Science Research. MIS Quarterly,

Vol. 32, No. 4, PP. 725-730.

McLaren, T. & Buijs, P. (2011). A design science approach for developing information

systems research instruments. [online] http://www.rug.nl/staff/p.buijs/design_science

approach_for_developing_isr_instruments.pdf (accessed 24/5/15).

McManus, J., & Wood-Harper, T. (2007) Understanding the Sources of Information Systems Project Failure. Management Services, 51(3), pp. 38-43.

McMillan, E. (2002) Considering Organisation Structure and Design from a Complexity

Perspective, Open University, Milton Keynes.


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

Melville, N., Kraemer, K. and Gurbaxani, V. (2004) Information Technology and

Organizational Performance: An Integrative Model of IT Business Value. MIS

Quarterly, Vol. 28, No. 2, pp.283–322.

Mitroff, I & Silvers, A (2008) Dirty Rotten Strategies: How We Trick Ourselves into

Solving the Wrong Problems Precisely, Stanford, California: Stanford

Business Books.

Monk, A & Howard, S (1998) The rich picture: a tool for reasoning about work context.

Interactions, Vol. 5, No 2), pp. 21–30. Myers, M.D. (1995) A Disaster for Everyone to See: An Interpretive Analysis of a Failed IS

Project. Accounting Management and Information Technology, Vol. 5, No.4,

pp.185-201.

O'Brien, R. (2001), “An Overview of the Methodological Approach of Action Research”, In Roberto Richardson (Ed.) “Theory and Practice of Action Research” Brazil:

Universidade Federal da Paraíba http://www.web.ca/~robrien/papers/arfinal.html,

(Accessed 20/4/2015)

Orlikowski, W.J. and Iacono, C.S. (2001) ‘Research commentary: desperately seeking the

‘IT’ in it research – a call to theorizing the IT artefact’, Information Systems

Research, Vol. 12, No. 2, pp.121–134.

Peffers, K. Tuunanen, T., Rothenberger, M. & Chatterjee, S. (2008) A Design Science

Research Methodology for Information Systems Research. Journal of

Management Information Systems. Vol .24, No. 3, pp. 45-78.

Pries-Heje, J & Baskerville, R. (2008) The Design Theory Nexus. MIS Quarterly.

Vol. 32, No. 4, pp. 731-755.

Powell, T.C. and Dent-Micallef, A. (1997) Information Technology as Competitive Advantage: The Role of Human, Business and Technology Resources. Strategic

Management Journal, Vol. 18, No. 5, pp.375–405.

Rapoport, R. N. (1970) Three Dilemmas in Action Research with Special Reference

to the Tavistock Experience. Human Relations, Vol. 23, No.6, pp. 499-513. Robey, D. and Boudreau, M.C. (1999) Accounting for Contradictory Organizational

Consequences of Information Technology: Theoretical Directions and

Methodological Implications. Information Systems Research, Vol. 10, No. 2, pp.167–185.

Robinson, S. (2008). Conceptual modelling for simulation Part I: definition and

requirements. Journal of the operational research society Vol. 59, No. 3,

pp. 278-290.

Sawang,S. (2008) Innovation Implementation Effectiveness: A Multi-organizational Test of

Klein Conn and Sorra’s Model. Ph.D Thesis, Queensland University of

Technology.

Schepers, J. and Wetzels, M. (2006) A Meta-analysis of the Technology Acceptance Model:

Investigating Subjective Norm and Moderation Effects. Information and

Management, Vol.44, No. 2007, pp.90-103.

Shmueli G, & Koppius O (2011) Predictive analytics in information systems research.

Management Inform. Systems Quart. Vol. 35, No. 3, pp. 553 – 572.

Seine, M., Henfridsson,O., Purao, S. & Lindgren, R. (2010) Action Design Research. MIS Quarterly, Vol. 36, No. 1, pp. 37- 56.

Sheffield, J. (2005) Systemic knowledge and the V-model. Int. J. Business Information

Systems, Vol.1, Nos. 1/2, pp.83–101. Stahl, G. (2000) Collaborative Information Environments to Support Knowledge

Construction by Communities. AI Society, Vol. 14, No. 1, pp.1–27.

Stenmark, D. (2013) Distrust in Information Systems Research: A Need for Stronger Theoretical Contributions to Our Discipline. IEE Computer Society. Proceedings:

46th Hawaii Conference on System Sciences, pp. 4532-4540.

Straub Jr., D.W. and Burton-Jones, A. (2007) Veni, Vidi, Vici: Breaking the TAM Logjam. Journal of the Association for Information Systems, Article 5, Vol. 8, No. 4,

pp.223–229.


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Review O

nly

Tan, P. (2013) Students Adoptions and Attitudes towards Electronic Placement Tests: a

UTAUT Analysis. American Journal of Computer Technology and Application,

Vol.1, No. 1, pp. 14-23.

Time-Management-Guide.com (2015) [online] http://www.time-management-

guide.com/decision-tree.html (accessed 22 March 2015). Turner, M., Kitchenham, B., Brereton, P., Charters, S. and Budgen, D. (2010) Does the

Technology Acceptance Model Predict Actual Use? A Systematic Literature

Review. Information and Software Technology, No. 52, pp.463–479. Redish, J. (2007) Expanding usability testing to evaluate complex systems. Journal

of Usability Studies, Vol. 2, No. 3, pp. 102-111.

Venkatesh, V., Morris, M.G., Davis, G.B. and Davis, F.D. (2003) User Acceptance

of Information Technology: Toward a Unified View. MIS Quarterly, Vol. 27, No. 3, pp.425–478.

Vidgen, R., Wood-Harper, T. & Wood, R. (1993) A Soft Systems Approach to Information

Systems Quality. Scandinavian Journal of Information Systems, Vol. 5, No.1, pp 97-112.

Volta, A. (1800). On the electricity excited by the mere contact of conducting substances of

different kinds. In a letter from Mr. Alexander Volta, FRS Professor of Natural Philosophy in the University of Pavia, to the Rt. Hon. Sir Joseph Banks, Bart.

KBPRS. Philosophical transactions of the Royal Society of London, pp. 403-431.

Walsham, G (1995) Interpretive Case Studies in IS Research: Nature and Method.

European Journal for Information Systems, Vol. 4, pp 74-78.

Wells, M.A. (2012) Organisational Change and Acceptance: Perspectives of the Technology

Acceptance Model. in Vaidya, K. (Ed.): Inter-Organizational Information

Systems and Business Management: Theories for Researchers, IGI Global,

Pennsylvania, USA.

White, S. E., Dittrich, J. E., & Lang, J. R. (1980). The effects of group decision-

making process and problem situation complexity on implementation

attempts. Administrative Science Quarterly, Vol. 25, No. 3, pp. 428-440. Wieringa R, Morali A (2012) Technical action research as a validation method in

information systems design science, Proceedings DESRIST 2012, LNCS 7286, Springer, Berlin

Wixom, B.H. and Todd, P.A. (2005) A Theoretical Integration of User Satisfaction and

Technology Acceptance. Information Systems Research, Vol. 16, No. 1, pp.85–102.

Wood-Harper, T. (1985) Research Methods in Information Systems: Using Action Research.

Mumford et al., Eds. Elsevier Science Publishers: Holland. Wood-Harper, A. T., & Avison, D. E. (2003). Bringing Social and Organisational

Issues into Information Systems Development: The Story of Multi-view. in

Clarke, S., Coakes, E., Hunter, M. & Wenn, A (eds.) Socio-technical and Human Cognition Elements of Information Systems. London: Information

Science Publishing, pp. 5-21.

Wood-Harper, T. & Wood, B. (2005) Multi-view as Social Informatics in action: Past,

Present and Future. Information Technology and People, Vol. 18, No. 1,

pp. 26-32.

Xiangrong, L. (2010) Hierarchical Decision Making with Supply Chain Applications,

PhD thesis, Drexel University, North America.

Zadeh, L. A. (1996). Fuzzy logic= computing with words. Fuzzy Systems, IEEE

Transactions on, Vol. 4, No. 2, pp. 103-111.


123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

A Component Based Conceptual Methodology and Holistic Framework for IT System Implementation and Management. Combining Both the Action Research and Design Science Methodologies

Documents