Scholarly article on 2,5-dianilino-N-phenyl-1,4-benzoquinone imine 21086-81-7 from Chemische Berichte p. 910

Info Systems J (2000) 10, 167–193

167

Transforming information systems

development through computer-aided

systems engineering (CASE): lessons

from practice

Tom Butler

National University of Ireland, University College Cork, Ireland, email: tbutler@aﬁs.ucc.ie

Abstract. In dealing with the challenges posed by the ongoing problem of devel-

oping and integrating an evermore complex and diverse range of information

systems in a timely manner, practitioners continue to grapple with important issues

such as increasing developer productivity and bringing quality improvements to

the process and product of systems development. Many organizations have

adopted computer-aided systems engineering (CASE) tools with such outcomes

in mind. With few exceptions, previous research into the phenomenon of CASE

adoption and use has been survey based in the main, and has resulted in some

confusion over the beneﬁts to be derived from the use of CASE tools within the

systems development process. This paper extends previous work as part of an

interpretive, case-based research strategy to examine the adoption and use of

integrated CASE (I-CASE) in a single organization. Such an approach facilitates

a deeper understanding of the impact that CASE exerts on the process and

product of systems development. Based on the experience of practitioners in the

organization studied, a set of recommendations is presented. The ﬁndings of this

study also lend support to the view that an I-CASE development platform does

indeed have the potential to exert a positive impact on the development process

and its product.

Keywords: computer-aided systems engineering (CASE), rapid application devel-

opment (RAD), organizational change, systems development process

INTRODUCTION

Signiﬁcant challenges face information systems practitioners as they enter the ﬁrst decade of

the new millennium. True, certain aspects of this predicament are traceable to the ‘software

crisis’ of the 1960s and 70s – the Y2K problem was, for example, one hangover from this era–

168

T Butler

however, the bulk of today’s problems present their own unique challenges for organizations

endeavouring to develop new and ever more complex information systems. Radical improve-

ments in the productivity and quality of the systems development process are deemed

necessary to meet these challenges; furthermore, in the face of an increasing scarcity of

developers, computer-aided systems engineering (CASE) is considered by many to be the

‘silver bullet’ that will help resolve the new ‘software crisis’ in organizations that grapple with

the task of developing bespoke systems. Off-the-shelf applications (Bansler & Havn, 1994),

outsourcing (McFarlan & Nolan, 1995) and enterprise resource planning systems (ERP)

(Deloitte & Touche, 1997) are presented as alternative solutions to this problem. However,

Holland etal. (1999) argue that organizations will still need to look beyond generic solutions,

such as ERP, if they are to leverage information technology (IT) for competitive advantage. It

is also the case that organizations operating in particular industry segments will have idio-

syncratic information system (IS) needs that can only be met by the development of ‘bespoke’

systems.

Over the past two decades, researchers have argued that information systems development

methodologies (ISDM) help practitioners improve both the process and product of systems

development (Blum, 1994), whereas others have questioned whether the methodology move-

ment has achieved these goals (for example, see Fitzgerald, 1994). CASE tools provide auto-

mated support for systems development methodologies (Folkes & Stubenvoll, 1994). As with

the methods they automate, arguments have been made that CASE tools increase developer

productivity and bring efﬁciency and quality improvements to the development process and its

product (Banker & Kauffman, 1991; Parkinson, 1990). Nevertheless, these claims have not

been entirely vindicated, and questions have been raised as to the beneﬁts that accrue from

the adoption of CASE in organizations (Kemerer, 1992; Sumner & Ryan, 1994).

Researchers argue that the development process is not well understood (Lewis, 1994; Butler

& Fitzgerald, 1997); unfortunately, the same is said of CASE-enabled systems development

(Guinan etal., 1997). Certainly, the mixed ﬁndings of extant research on CASE adoption and

use support this argument. Much of this research has been survey based and falls prey to

criticisms such as those levelled at similar research conducted on other aspects of systems

development (for examples, see Markus & Robey, 1988; Orlikowski, 1993; Cavaye, 1995).

Qualitative interpretive research approaches are therefore indicated as appropriate to capture

the ‘rich picture’ of systems development in organizations (Cavaye, 1995; Myers, 1995; cf.

Butler & Fitzgerald, 1997; Butler, 1998a,b). Accordingly, this study adopts an interpretive, case-

based research strategy and uses and extends the model and framework of ‘CASE adoption

and use’ proposed by Orlikowski (1993) to guide both the research endeavour and the pre-

sentation of its ﬁndings. This approach facilitates the attainment of the research objective,

which is to investigate the organizational content, contexts and processes surrounding the

successful implementation and use of CASE in organizations.

After the brief literature review in the next section, the research objective is outlined and

research questions posed. The interpretive research approach used to attain this objective

and to answer these questions is then described. The case report is presented and an analy-

sis of the ﬁndings follows in which an extended version of Orlikowski’s (1993) framework is

Transforming information systems development through CASE

169

used with associated narratives to provide in-depth descriptions of the salient issues found to

be pertinent to CASE adoption and use in the organization studied. The ﬁnal section then dis-

cusses the study’s ﬁndings and conclusions and ends with several recommendations for

research and practice.

A REVIEW OF RESEARCH ON THE INTRODUCTION AND BENEFITS OF CASE

FOR INFORMATION SYSTEMS DEVELOPMENT

The challenges that confront practitioners in the development of organizational information

systems have prompted many to seek means to improve the productivity, quality and rigour of

the systems development process and its product. CASE tools have long been considered to

be a potential vehicle for easing systems development-related problems and bottlenecks

(Banker & Kauffman, 1991; Orlikowski, 1993). A recent IFIP (WG 8.1) working conference on

the systems development process emphasized the importance of CASE tools and delineated

the contribution they can make to the development process (Prakash etal., 1993). Accord-

ingly, it was pointed out that the development process has become strongly inﬂuenced by the

use of CASE (Györkös & Rozman, 1993). Are these claims for the importance and utility of

CASE in the development process valid? The following brief review of research on CASE

offers mixed results and suggests that such claims appear to have little basis in fact.

Designing large-scale complex information systems that are free of problems demands a

systematic approach (Song & Osterweil, 1994). Wood-Harper etal. (1985) argue that the sys-

tematic analysis and design of an information system requires a systems development

methodology. The role of CASE is to give automated support to such a methodology (Folkes

& Stubenvoll, 1994). According to Jayaratna (1994), over 1000 brand name methodologies

are in use all over the world. Correspondingly, since the introduction of CASE in the mid-

1980s, the number of CASE tools has proliferated; in 1990, for example, Parkinson (1991)

estimated that there were in excess of 1000 in existence. As with claims for the methodolo-

gies which they automate, Aaen etal. (1992) report that improved standardization, more efﬁ-

cient systems development procedures and improved systems quality resulted from CASE

use. Banker & Kauffman (1991) found that CASE tools increase developer productivity (see

also Norman & Nunamaker, 1989; Orlikowski, 1993; Finlay & Mitchell, 1994; Dahanayake et

al., 1996). In addition, CASE use is reported to have a positive inﬂuence on both the devel-

opment function within organizations, by providing productivity and quality enhancements to

the development process, and on individual developers, by increasing their effectiveness and

engendering the development of positive attitudes (Finlay & Mitchell, 1994). Other touted ben-

eﬁts of CASE include its ability to facilitate software re-engineering and reuse and in its pro-

vision of an adaptable and consistent development platform for developers (Norman &

Nunamaker, 1989; Iivari, 1996).

Although CASE has promised much, research has shown that it has failed to deliver on its

promises. Folkes & Stubenvoll (1992), for example, indicate that the reported beneﬁts of CASE

are not being realized; they cite the Butler Cox Report to illustrate that the introduction of

170

T Butler

CASE in organizations has led to a reduction in the quality of systems produced. Recent

research also lends support to the view that practitioners are disillusioned with CASE; Kemerer

(1992) reports that 70% of CASE tools are not used 1year after their introduction and only

5% are widely used, but not to their full capacity. Recent studies indicate that the situation

may not be as bad as Kemerer suggests; nevertheless, this body of research indicates that

about one-third of all organizations who adopt CASE abandon its use within 2years of acquir-

ing it (Isoda etal., 1995; Rader etal., 1995). Possible reasons for this are indicated by Sumner

& Ryan (1994), who, on the basis of a survey of CASE users, argue that development activ-

ities such as logical modelling, prototyping, generating design documentation, creating

modular program design speciﬁcations and design training are not made easier by the use of

CASE tools. These ﬁndings led Sumner & Ryan (1994, p. 19) to suggest that ‘CASE is simply

another technology which automates a series of isolated systems design tasks, without

addressing the underlying need for improving the systems design process.’ Obviously, these

conﬂicting conclusions in research on the topic make it difﬁcult to decide whether CASE has

had an overall beneﬁcial or detrimental effect on the structure and quality of the development

process and its product. Guinan etal. (1997) provide some insights as to why this may be so.

They argue that the use of CASE in itself makes very little difference, related factors such as

training, project size, design quality and the integrated use of CASE tools all contribute to the

success of CASE adoption and use. In addition, Lorin (1996) outlines several obstacles to the

adoption and implementation of CASE, namely CASE tool scalability, organizational problems,

developer skills and competencies, up-front cost and proof of payback; these factors are

argued by Lorin (1996) to mitigate against the successful adoption and use of CASE tools.

Table1 provides an analysis and comparison of the reported beneﬁts of CASE; also listed are

several factors which are argued to have an impact upon the adoption, implementation and

use of CASE.

Research rationale, objective and questions

It is clear that in order to resolve the contradictory ﬁndings of previous research a compre-

hensive and unequivocal description of the organizational content, contexts and processes

that lead to the successful implementation and use of CASE is required. This task is con-

founded by the manner in which CASE as an information technology in itself has evolved

since the early 1990s; hence, it may be that problems and deﬁciencies of a technical nature

with earlier CASE products may not now exist. There is also the relative effectiveness of upper

and lower CASE in solving ‘wicked problems’ (Post etal., 1999); Lorin (1996) argues that the

payback from lower CASE tools do not scale in the short term, and that the payback

from upper CASE tools, which focus on analysis, design and detailed design, may be much

greater – but here again there is the problem of delayed payback. With few exceptions (for

examples, see Banker & Kauffman, 1991; Orlikowski, 1993; Finlay & Mitchell, 1994; Post

etal., 1999), there is little evidence in previous research of an effort to differentiate between

different types of CASE tools [e.g. upper, lower and integrated CASE (I-CASE)], to say nothing

Transforming information systems development through CASE

171

Table 1. Reported beneﬁts of CASE use vs. reported drawbacks

Reported beneﬁts of CASE

Adoption implementation and use issues associated with CASE

The use of case:

No proof of payback (Lorin, 1996)

Provides a formal and standardized

approach to systems development

(Folkes & Stubenvoll, 1994; Lorin, 1996)

Provides an adaptable and consistent

development platform(Norman &

Nunamaker, 1989; Iivari, 1996)

Multiple CASE products and confusion of alternatives, e.g. different

technologies/methodologies/features (Post etal., 1999)

Steep learning curves (Lorin, 1996)

Non-scalability of tools (Lorin, 1996)

Non-integration of tools (Sumner & Ryan, 1994; Guinan etal., 1997)

Training (Guinan etal., 1997)

Results in more efﬁcient development )

procedures (Aaen etal., 1992)

Cultural resistance (Orlikowski, 1993; Finlay & Mitchell, 1994)

Existing practices

Improves the quality of the development

Existing tools

process and its product (Aaen etal., 1992) Organization variables (Orlikowski, 1993; Lorin, 1996; Post etal.,

Improves developer productivity (Norman &

Nunamaker, 1989; Banker & Kauffman,

1991; Dahanayake etal., 1996; Orlikowski,

1993; Finlay & Mitchell, 1994)

1999)

User reactions

Up front costs

Organization size

Facilitates software re-engineering and reuse Pilot project requirements (Guinan etal., 1997)

(Norman & Nunamaker, 1989; Iivari, 1996) Suitable project size (Guinan etal., 1997)

Reduces development costs (Lorin, 1996)

Primacy of design quality (Guinan etal., 1997)

of identifying tool functionality, particular vendors and so on. Taken together, then, all this is

suggestive of the need for further in-depth empirical research. Orlikowski (1993) argued

that empirical research of a qualitative nature was required to contribute to a deeper under-

standing of the phenomenon and to verify her grounded theory-based CASE research frame-

work – to a large extent, this call remains unanswered. Although Orlikowski (1993) did not

explicitly call for such, a constructivist approach to research captures holistically the content,

context and process of the socially constructed reality that is organizational life (Lincoln &

Guba, 1985; Butler, 1998a,b); this study adopts such an approach.

It has been suggested that studies of the organizational consequences of information tech-

nology should not rely on simple causal models; rather, theoretical models that capture the

social and technical complexity of the phenomenon and which emphasize ‘empirical ﬁdelity’

are advocated (Markus & Robey, 1988; Robey & Azevedo, 1994). Chervany (1973) argues

that empirical investigations of IS-related problems require a research framework that aids in

the identiﬁcation and examination of a phenomenon’s various dimensions and provides a

structure for correlating and synthesizing the results of independent research. Furthermore,

Teng & Galletta (1991) maintain that a young ﬁeld, such as IS, requires ‘pretheory’ frame-

works to guide research activities while en route to theory development. Although these argu-

ments provide explicit support for the use of a framework such as that proposed by Orlikowski

(1993), a philosophical argument that is congruent with this study’s ontological and episte-

mological stance is also forthcoming. For example, constructivist philosophers such as

172

T Butler

Heidegger (1976) and Gadamer (1975) comment on the importance of preunderstanding in

guiding the investigation of social phenomena. In a research context, this preunderstanding

allows a researcher to form hypotheses or expectations regarding the phenomenon so that

questions may be posed and a dialogue entered into with the object in order to conﬁrm, modify

or refute such expectations (Butler, 1998a,b). Orlikowski’s (1993) model of the process and

context of CASE adoption and use in organizations contributes to this researcher’s preun-

derstanding of the phenomenon as it captures suitably the complex socially constructed nature

of CASE adoption and use.

This study’s primary objective is to investigate the organizational content, contexts and

processes surrounding the successful implementation and use of CASE in one organization

and to document the issues that lead to this success. Here, success is deﬁned in terms of

the continued and widespread productive use of the technology in the organization concerned.

Given this study’s primary objective, and considering the model of Orlikowski (1993) and the

ﬁndings of previous research, the three following research questions (RQ) act to guide this

investigation.

RQ1. What are the critical issues that IS managers and practitioners must pay particular

attention to in the adoption, implementation and use of CASE?

•

RQ2. Does the use of CASE have an overall positive or negative effect on the process and

product of systems development?

•

RQ3. What types of CASE technologies are capable of delivering these beneﬁts?

•

The following section proposes a constructivist research approach for the study of the

phenomenon.

A CONSTRUCTIVIST RESEARCH APPROACH

Systems development is, in essence, a multidimensional change process that presents itself

simultaneously within several related social environments or contexts – as a reality it is socially

constructed (Visala, 1991; cf. Orlikowski, 1993). Furthermore, these environments give rise to

a complex web of social conditions and factors that shape and inﬂuence the process and its

product (Kling & Scacchi, 1982). The fundamental perspective of constructivist philosophy

posits that reality is socially constructed (Berger & Luckmann, 1966; Connolly & Keutner,

1988); hence, research into social phenomena should be interpretivist in orientation so that

contextualized meaning can be revealed in order to enable socially based phenomena to be

understood (Lincoln & Guba, 1985). This paper on the adoption and use of CASE in Telecom

Éireann is informed by the constructivist research paradigm of Guba & Lincoln (1994). Accord-

ingly, it uses a hermeneutic research method, in conjunction with the qualitative research tech-

niques advocated by the constructivist paradigm.

Hermeneutics is deﬁned as the theory or philosophy of the interpretation of meaning

(Bleicher, 1980). Interpretation here involves entering into the interpretative norms of a com-

munity; while meaning here operates and is to be found within the historical contexts of

Transforming information systems development through CASE

173

the interpreter and interpreted (Gadamer, 1975; Butler, 1998a). Following Connolly & Keutner

(1988), Butler (1998a,b) argues that the philosophies of Heidegger (1976) and Gadamer

(1975) are constructivist; Guba & Lincoln (1994) have also appropriated this label for their

research paradigm in the social sciences. As Table2 illustrates, the constructivist ontological

and epistemological perspectives of Guba & Lincoln (1994) accord well with the phenome-

nological hermeneutics of Heidegger (1976) and Gadamer (1975). However, while Guba &

Lincoln (1994) advocate the use of the hermeneutic method, they fail to offer a description of

an interpretive research method that draws on the tenets of hermeneutic philosophy. This

study applies the hermeneutic method articulated by Butler (1998a,b), in that it incorporates

the hermeneutic ‘circle of understanding’ and the Socratic, Hegelian and reductionist/analyt-

ical dialectics as its prime methodological techniques. The basic form of communication

among social actors is the personal narrative (Bruner, 1990); hence, Ricoeur (1981) argues

that social action and situations can be read as texts. Researchers therefore require a set of

interpretive principles to guide them in their interpretations of social phenomena (Butler,

Table 2. Ontological, epistemological and methodological perspectives of phenomenological hermeneutics

Perspective

Description

Ontological and epistemological

stance

In ontological terms, the hermeneutic perspective posits that realities are

constructed from multiple, intangible mental constructions that are socially and

experientially based, local and speciﬁc in nature, and dependent on their form

and content on the individual persons or groups holding the constructions.

In epistemological terms, the investigator and the object of investigation are

interactively linked so that the ‘ﬁndings’ are literally created as the investigation

proceeds (see Guba & Lincoln, 1994).

Hermeneutic perspectives on

method

It is the task of the researcher as human instrument to reconstruct the social world

of the phenomena under study utilizing his/her own ideographically informed

interpretations (Lincoln & Guba, 1985). Hence, in methodological terms the

variable and personal nature of socially constructed reality suggests that

individual constructions can be elicited and reﬁned only through interactions

between and among investigator and respondents. The problem that confronts

the hermeneutic researcher is how to effect this process and render accounts of

subjectively intended meaning objective in the face of the fact that they are

mediated by the interpreter’s own subjectivity. Butler (1998a,b) illustrates that

this process involves the use of the hermeneutic techniques such as the ‘circle

of understanding’ and the Socratic, Hegelian, and Reductionist forms of

dialectic. Interpretive principles, such as those proposed by Madison (1988), are

applied to help achieve this aim and to bring the required rigour to the process.

Taken together, the application of these techniques and interpretive principles

constitute what has been described as the hermeneutic method (Butler,

1998a,b). The ﬁnal aim of the hermeneutic method, then, is to distil a

consensus reconstruction of social actors’ constructions that is more informed

and sophisticated than any of the preceding constructions (see Guba & Lincoln,

1994; cf. Erlandson etal., 1993).

174

T Butler

1998a,b; Klein & Myers, 1999). Following Butler (1998a,b), Madison’s (1988) interpretive prin-

ciples) were adopted to inform the conduct of the research and data analysis in the present

study. Basically, Madison (1988) argues that researchers should ensure that their interpreta-

tions are coherent, comprehensive, penetrating and thorough. In addition, interpretations

should be appropriate, should be in agreement with the research context, should be sugges-

tive and raise questions that stimulate further research and, ﬁnally, should exhibit potential in

their implications (for an in-depth description of this topic, see Butler, 1998a,b).

Lincoln & Guba (1985) argue that the constructs of reliability, objectivity, internal validity and

external validity are inappropriate for a constructivist approach to research; therefore, they

propose an alternative set of concepts with which to evaluate the rigour of interpretive studies

in order to establish their ‘trustworthiness’. According to Erlandson etal. (1993, pp. 132), ‘Trust-

worthiness is established in a [constructivist study] by the use of techniques that provide truth

value through credibility, applicability through transferability, consistency through dependabil-

ity, and neutrality through conﬁrmability.’ Although the interpretive principles of Madison (1988,

p. 28) informed the interpretive process and ensured the rigour of the researcher’s interpre-

tations by guaranteeing that ‘the judgements arrived at [were] not gratuitous or the result of

subjective whim’, the concepts of Lincoln & Guba (1985) were applied to provide an ‘objec-

tive’ evaluation the of research product and its trustworthiness (Butler, 1998a,b; cf. Klein &

Myers, 1999).

Constructivism and phenomenological hermeneutics in the IS ﬁeld

Boland (1985) was one of the ﬁrst within the IS ﬁeld to speciﬁcally advocate phenomenologi-

cal hermeneutics as a valid interpretive approach for research on the phenomenon of infor-

mation systems development. Myers (1995), Westrup (1994) and Visala (1991) have also

recommended that hermeneutic philosophy inform research in this area, whereas Lee (1993,

1994) has championed the use of hermeneutics in broader research contexts within the ﬁeld.

Therefore, following research that began with Boland (1985) and Winograd & Flores (1986),

and more recently with Introna (1997), this study adopted the phenomenological perspective

of Heidegger (1976) and integrated it with the hermeneutic philosophy of Gadamer (1975) in

order to provide a philosophical basis for its constructivist research approach. Table2 presents

the ontological, epistemological and methodological perspectives of phenomenological

hermeneutics. This approach incorporates the hermeneutic method, as described by Butler

(1998a,b), to operationalize the research strategy described herein.

Implementation of the Research Strategy

In keeping with the tenets of the constructivist paradigm, a qualitative case-based research

strategy was adopted; this approach involved an exploratory single-case study (Stake, 1994).

Purposeful sampling was used throughout (Marshall & Rossman, 1989; Patton, 1990). The

case design used has been described by Yin (1989) as ‘posthoc longitudinal research’. The

investigation of the selected case was conducted through the use of individual interview and

Transforming information systems development through CASE

175

documentary sources over an initial period of 1month in 1996, with a subsequent follow-up

study of the company-wide implementation of the I-CASE workbench some 2years later.

Some 19 interviews were conducted with IS managers, IT professionals in the organization’s

quality unit, the project manager of the rapid application development (RAD) team, and

the analysts, programmers and user representative who constituted the team who used the

I-CASE workbench to develop the system concerned. The general interview guide approach

was chosen as being the most appropriate for this particular study – here, a semistructured

interview strategy was chosen (Patton, 1990) – and each interview was up to 2hours in

length. Additional data collection methods used included documentary evidence and informal

participant observation and discussion. During the data analysis phase, the hermeneutic

techniques of the ‘circle of understanding’ and the Socratic, Hegelian and reductionist/ana-

lytic dialectics were operationalized using the data analysis methods of content and constant

comparative analysis (see Patton, 1990; Calloway & Ariv, 1991). Elements of Orlikowski’s

(1993) model were used as ‘seed categories’ to prime the hermeneutic ‘preunderstanding’

of the phenomenon in order to identify and understand the ‘whole-part’ relationships

that emerged from the interview transcripts and other documentary sources. The technique

of data reduction and display was also used to meta-analyse the qualitative data (see

Miles & Huberman, 1994). Finally, the case report approach was used to write up the research

ﬁndings.

Being a member of the organization chosen for study, the author was what Bødker &

Pedersen (1991) have termed a ‘cultural insider’. Hence, as a member of the general busi-

ness constituency and an IT professional, he was intimate with several of the subuniverses

of reality that comprised the overall institutional reality (see Berger & Luckmann, 1966). This

provided ‘human instrument’ of Lincoln & Guba (1985) with valuable insights into the organi-

zation’s culture and climate, and this greatly aided in the interpretation of the case.

A CASE STUDY OF THE INTRODUCTION OF CASE FOR RAPID APPLICATION

DEVELOPMENT IN TELECOM ÉIREANN

The organization chosen for study is Telecom Éireann (now eircom), the Republic of Ireland’s

national telecommunications company (telco). It is a state-owned company with two minority

shareholders: Telia, a Swedish telco, and KPN, a Dutch telco. Telecom Éireann provides uni-

versal telecommunications services within Ireland, and presently enjoys a monopoly in

many of its service areas. There are over 10 companies in the Telecom Group, the majority

of whom are wholly owned subsidiaries. As of 1999, Telecom employed approximately 11500

staff. In 1994–5, the company formulated its plans to transform its core operational business

processes under the umbrella of the planned Operational Support System (OSS). Telecom’s

IS function was charged with the development of an ambitious portfolio of information systems

which were to constitute the OSS, one of these systems is the Generic Appointment System

(GAS).

176

T Butler

An overview of the generic appointment system

The Generic Appointment System grew out of a business need in one key area of the Telecom

Éireann’s operations – its telephone repair service. Business managers across the organiza-

tion recognized the need to introduce efﬁciencies into the manner in which repair service work-

loads were managed and associated service appointments made with customers. It was hoped

that the introduction of this information system would eliminate the occurrence of unproduc-

tive visits by operational staff to customer premises when customers were absent. The GAS

would also assist supervisors in their task of allocating workloads to their repair teams, which

consist of operational staff. Both groups therefore had a keen interest in the development and

implementation of this system as it had an impact upon some of their basic functions. The

GAS also supports the operation of the company’s 10 fault-handling and repair centres. As a

distributed IS, the GAS is a client–server application using eight Oracle relational data bases

that serve up to 180 windows-based PC terminals in fault-handling centres around Ireland,

and a further 400 in operational depots nationwide. The CASE-supported RAD approach saw

development take place within the 3-month time period set for the project; however, the imple-

mentation of the ﬁrst phase of the GAS took a further 6months and was completed in late

1996. The GAS project came in on time and on budget.

The GAS development project as a pilot study for the IS function’s implementation

of the information engineering facility’s I-CASE workbench

Although the business management within the company had articulated a need for a customer

appointments system, the chief stimulus for the development of the GAS arose out of an inter-

nal need within the IS function. In response to the challenge posed by the development of the

OSS, senior IS managers recognized that development teams needed to produce modular

maintainable systems in a rapid manner. IS managers also wanted to maximize the produc-

tivity of a ﬁxed developer resource and skillset and to maintain product quality. Although the

IS function had a brief but unproductive experience with structured systems and design

method (SSADM), the return to ad hoc development practices was equally unsatisfactory. That

said, the GAS project manager reported that because of a range of development-related

issues support grew for the acquisition and use of a ‘common/generic development environ-

ment that we could use, cradle to grave, to give a total life cycle coverage.’ Subsequent to a

rigorous vetting procedure by the IS function’s quality team, a computer-aided systems engi-

neering (CASE) workbench called the information engineering facility (IEF) was acquired from

Texas Instruments to meet this requirement.

IEF is an integrated CASE (I-CASE) workbench that operationalizes and automates the

associated information engineering methodology (Martin, 1990) using a set of tightly inte-

grated tools. Essentially, it provides architectural (planning), conceptual (structured design

modelling), external (prototyping), implementation (procedure writing, code generation and

hardware) and execution (integration of the product into hardware, target data bases, exist-

ing applications and data networks) layers that map onto the information engineering (IE)

Transforming information systems development through CASE

177

methodology (Texas Instruments, 1992). Besides the productivity improvements promised by

IEF, IS function managers also viewed the introduction of IEF as a means to improve the

quality of the development process and product and to quickly re-engineer and maintain devel-

opment applications. Although initial tests of IEF were favourable, IS managers were mindful

of the function’s previous experience with SSADM; a rigorous test of IEF’s capabilities and

suitability to purpose was deemed necessary in order to assess its potential fully. There was

also the question of the cost of the investment, which was estimated at £250000 for the

planned company-wide implementation of IEF. Hence, a decision was made to use IEF to

develop rapidly an information system from the existing backlog of projects using a minimum

of licenced IEF-based workstations. A senior IS manager, who was responsible for the bulk

of systems development at the time and who championed CASE use, selected ‘a small, non-

critical project’, the generic appointments system, to test fully the systems development capa-

bilities of IEF (from conceptual to execution layers) within a real development environment

and with a minimum of cost. A 3-month deadline was set for the development of the project’s

core requirements within one operational area; full corporate-wide implementation would then

be effected at a later date.

ANALYSIS OF THE RESEARCH FINDINGS

This study uses Orlikowski’s (1993) Process Model of Organisational Change Around CASE

Tools to provide insights into and report on the present interpretivist study on the introduction,

adoption and use of CASE in Telecom Éireann. Orlikowski’s model (see Figure 1) describes

the complex web of inﬂuences between process and context in CASE adoption and use and

captures the effect that such factors have on the various participants in the adoption and use

process. For example, the external environmental, organizational and IS contexts are all

argued to inﬂuence IS managers’ attitudes toward and expectations of CASE. These individ-

uals in turn formulate IS function policy on the adoption and use of CASE with reference to

the aforementioned contexts. Orlikowski (1993) maintains that this leads to signiﬁcant process

and context change around CASE adoption and use. The outcomes of CASE adoption and

use are, in turn, dependent on the preceding actions, policies and practices and, consequently,

exert a considerable inﬂuence on the social contexts mentioned. Table A1 in Appendix A arrays

the model’s descriptive categories into a framework that provides a synopsis of the research

ﬁndings under each of the categories indicated by the model. Because existing framework

proposed by Orlikowski (1993) failed to capture all the dimensions found to be of signiﬁcance

in explicating the phenomenon within the context of the present study, Table3 describes con-

cepts and associated research ﬁndings that provide additional descriptive dimensions. These

new dimensions expand the section titled ‘Adopting and Using CASE Tools’ in Orlikowski’s

original framework (see Table A1) and is labelled accordingly in Table3. Extended narratives

are utilized to describe particular aspects of the introduction of I-CASE referenced in Tables

A1 and 3 that have been found to be relevant in this organization and which help to answer

the research questions posed.

178

T Butler

Figure1. Orlikowski’s process of organizational change around CASE tools. Arrows: 1, inﬂuence of context on IS man-

agers’ actions as condition for adoption of CASE tools; 2, reinforcement or change of context as IS managers’ actions

are changed by it; 3, conditions that lead IS managers to acquire CASE tools; 4, inﬂuence of context on acquisition and

assimilation of CASE tools; 5, reinforcement of change of context as the CASE tools are assimilated; 6, acquisition and

assimilation of CASE tools lead to certain experiences; 7, inﬂuence of context on reactions of key players around use

of CASE tools; 8, reinforcement of change of context as players are inﬂuenced by the context.

In terms of the constructivist research approach described in this paper, the various ele-

ments of the extended framework are conceptualized as ‘parts’ of the hermeneutic ‘whole’

that is the socially constructed world (as it relates to systems development and CASE) of IS

managers, developers and users in Telecom Éireann. An understanding of the ‘whole’ can

only be achieved by a consideration of each of the ‘parts’ in context as they relate to the

‘whole’ and vice versa. It is only through cycling through the ‘whole–part’ relationships, i.e. by

applying the ‘circle of understanding’ and by engaging in a dialectic with the phenomenon,

can one come to understand the content, context and process of CASE adoption and use in

this organization (cf. Davis etal., 1992). Hence, using the model proposed by Orlikowski (1993)

(in Figure 1) as a starting point and then examining individual elements of the framework (in

Tables A1 and 3) and how they relate to it, the phenomenon of CASE adoption and use in

Telecom Éireann can be apprehended and understood. It is using such an approach that the

following subsections answer the research questions posed earlier.

Table 3. An Extension of the CASE framework: additional descriptive concepts to the adoption and use process

Categories

Concepts

Research data

I-CASE adoption

and use process

Team selection and make up

Training

The development team was selected on the basis of previous experience, skills and attitudes towards

working in a co-operative manner with fellow developers and participating users

Training was conducted in-house at the development site. It consisted of 3weeks intensive instruction in

the relevant areas of the IE methodology and in the IEF tool set. The user representative was also

trained along with the developers in anticipation of his active participation in the development process. A

consultant from Texas Instruments was to stay on site for 3months to continue training on a hands-on

basis along with providing technical support and troubleshooting expertise

Development approach

A rapid application approach was used within a 3-month deadline. This centred on the prototyping

(external layer) facilities of IEF. The sequenced, structured SDLC approach implicit in IE and IEF was

dropped in favour of a prototype-driven approach to development

I-CASE tools used

Data and process modelling, prototyping, procedure writing and code generator and testing

The project was very tightly controlled and monitored; however, the project manager found it difﬁcult to

time-box prototyping activities because of the creative nature of this aspect of the development process

Individual and group sessions for requirements analysis involving both participatory design (PD) and joint

application design (JAD). User representative and programmer participated in the analysis process

Vendor support proved to be vital in the use of I-CASE during development: in supporting developers, get

to grips with and understand its features; and in solving unforeseen technical problems in the

implementation and execution layers, namely application programme use of the network layer protocol

(DECnet) to communicate with Oracle over the local area network. Vendor response time to queries was

of the order of 1–2h turnaround, so little time was wasted in unproductive problem-solving activities

The bug-trace facility helped developers understand the functionality of IEF as well as locate bugs in the

application under development

Project management

Requirements analysis

Vendor support

Testing

Resolution of additional

problems and miscellaneous

issues

Developers found that translating the analysis ﬁndings to CASE modelling conventions problematic and

would have preferred more CASE support in this area. The prototyping tools were considered to be ‘the

jewel in the crown’ of IEF: these allowed all the beneﬁts associated with prototyping (improved user–

developer communication, etc.) to be realized. Simultaneous development of application subsets or

modules was afforded by IEF – these was deemed to be one of its major strengths; however, it proved

to be a complex activity and developers felt that more experience was required to take full advantage of

this feature. Retroﬁtting of design features into the GAS application was made easy because of the

tight integration of each of the tools or layers; several major changes were effected rapidly leading to

ncreased developer and customer satisfaction with IEF

180

T Butler

Critical issues in the adoption and use process in Telecom Éireann (RQ1)

Table3 provides an overview of the issues that help answer research question 1. The follow-

ing narratives explore these issues under the general headings of project team selection, the

development approach used, group commitment and buy-in, and vendor support in the adop-

tion and use process.

Selection and training of the rapid application development team

A development project team was chosen with the special needs of this development endeav-

our in mind, i.e. team members were selected on the basis of perceived disposition towards

issues of demarcation and previously observed commitment to conﬂict avoidance. As the GAS

was to be integrated with the existing Fault Handling System (FHS), two experienced analysts

with prior experience in development of the FHS were chosen, along with a programmer who

had worked on a related project. Both analysts possessed experience and skills in such diverse

areas as traditional systems analysis and design, programming, computer hardware and tech-

nical aspects of network communications. As with all IS development within the organization,

a user project manager and a user representative were appointed to participate in the devel-

opment of this IS; these individuals had a wide range of experience in the operational areas

encompassed by the proposed system. User groups provided pools of experienced users,

from the operational areas of interest, to participate with the development team so as to gen-

erate, reﬁne and validate the user requirements and system prototypes. The impact of this

participative approach to development, which involved a combination of both joint application

development (JAD) and participatory design (PD), was commented on by the development

project manager, who stated that ‘the appointments system development was really driven by

the user group.’ Thus, the careful selection of team members allowed IS managers to elimi-

nate the possibility that the pilot testing of what was an extremely expensive investment would

not fail as a result of poor selection of the project team. Once the team was selected, 3weeks

of on-site training took place with a consultant from the I-CASE vendor, Texas Instruments,

who remained on site for the 3-month project. Intensive hands-on training was afforded to all

team members, including the user representative; nevertheless, steep learning curves (see

Lorin, 1996) were encountered and continued to mark the team’s learning experience with IEF.

On the rapid application development (RAD) approach used

The development approach adopted was consistent with extant RAD approaches described

in the literature, namely a RAD approach uses small autonomous teams in prototyping-

enabled joint application development with user participation (Subramanian & Zarnich, 1996).

The IEF development environment supports a structured approach to development built

around the systems development life cycle (SDLC) approach. However, the GAS project team

adopted a customized RAD approach for the development of the appointments system. Basi-

cally, prototyping was the primary mechanism used to reﬁne user requirements and to design

Transforming information systems development through CASE

181

system functionality; developers omitted certain design procedures embodied within IEF

deemed not to be relevant. This prototyping approach worked well with IEF and was approved

of by the IEF consultant, who was a member of the project team. However, the project manager

experienced some difﬁculties with the project management of the I-CASE-enabled RAD

approach, namely ‘a structured approach to project management along the lines of the

SDLC didn’t work . . . it didn’t match what [the developers] were doing in reality on the

ground’ . . . ‘We found on the GAS that anything that took longer than one week to track was

too hard to control. We need to break down the task into smaller modules, but we found that

that was not possible.’ Hence, the enhanced creativity that the I-CASE tools brought to the

development process caused project management headaches. Essentially, the project

manager found it difﬁcult to estimate and manage development activities that were evolu-

tionary and creative in nature – here, the difﬁculty centred mainly on the use of user-led

prototyping.

The development of a consensus approach to CASE use

According to all members of the development team, the project was well managed, co-

ordinated and controlled; a strong positive relationship was in evidence between the

development project manager and the development team. The project manager realized that

because existing development-related roles were heavily demarcated within the IS function,

there was the potential for intrateam conﬂict to develop between analysts and programmers

on the one hand and between the participating user and developers on the other. Before the

commencement of training on IEF, the project manager met with the proposed team to develop

a consensus approach to CASE use. Whereas the analysts and programmers had their own

areas of speciality, and were expected to contribute accordingly, there was to be no special-

ization in development-related activities associated with the use of IEF; as the project manager

put it, ‘the difﬁculty was going to be that if team members are working on the same project,

doing the same development tasks and getting different pay . . . and if objections are raised

and normal procedures had to be adhered to, then, for example, analysts would have to write

a spec for the programmers, etc.; however, analysts could write pseudo-code in IEF faster . . . I

couldn’t ask them to do that.’ The consensus approach applied to the user representative also

because he was a highly experienced technician and was therefore expected to participate

fully with the developers in almost all aspects of systems development. In fact, it was he who

was responsible for the technical implementation of the GAS. Hence, as one team member

put it, ‘we developers came together and agreed a common approach to the system’s

development . . . no “us and them”, either within the team or between developers and

users . . . nevertheless, it must be said that IEF has the potential for conﬂict.’ It was clear that

the consensus approach adopted by the development project manager and his team created

a development climate and subculture that effectively mitigated any problems that may have

arisen because of ‘demarcation’ issues between analysts and programmers when using IEF,

as such issues marked much of the existing organizational culture and climate in relation to

staff practices.

182

T Butler

On the importance of vendor support

The need for comprehensive vendor support also ﬁgured highly in this project. Training aside,

vendor assistance was required throughout this project in both support and troubleshooting

functions; for example, a joint vendor–developer approach was taken in the analysis and

design stage because of the difﬁculty developers had in translating the results of the require-

ments analysis interviews into the data and process models required by the I-CASE platform.

The client–server architecture used was also new to developers and problems existed

with: (i) the integration of the data base server for the GAS and the existing fault handling

system; (ii) the transmission protocols supported by the CASE environment; and (iii) difﬁcul-

ties with optimizing client–server performance. The solutions to these problems warranted a

signiﬁcant level of vendor support as the I-CASE workbench’s support for proprietary stan-

dards was less than satisfactory and needed an experienced hand to ‘make things work like

it said in the manual.’ One developer commented on this; ‘the signalling protocols were obsta-

cles, in that one was DEC’s, the other IEF’s, at the end of the day we had 3–4weeks of very

technical assistance from TI to get the systems to work together . . . now that we are aware

of the type of problems that can arise, we can cut down on the time spent resolving them in

future by getting vendor advice in advance.’ It is clear that the signiﬁcant technical obstacles

that arose would not have been difﬁcult to overcome for novice CASE users without vendor

assistance.

Assessing the beneﬁts: the impact and outcome of I-CASE adoption and use (RQ2)

As the analysis on the consequences for adopting and using CASE tools in Table A1 indi-

cates, the introduction and use of IEF I-CASE environment elicited positive reactions from

developers, IS managers and users alike. Similarly, the promise of increased developer pro-

ductivity and process and product improvements within the context of a RAD-based develop-

ment project were also delivered upon in the GAS project. For example, one developer stated

that ‘the IEF development environment was absolutely superb, there was enormous savings

in terms of coding, and programme management was enabled’; yet another stated that CASE

‘afforded better communication with the users through its modelling and prototyping facilities’

and the resultant system ‘was more maintainable, better documented, better developed

because of the support IEF offered.’ This developer also stated that ‘[IEF was] very powerful

and versatile in the area [of data and process modelling] as models are built with an integrity

that was maintained throughout.’ The importance of such a structured, yet ﬂexible, develop-

ment tool was proven when developers accomplished a major change to the functionality of

the GAS in a record time – ‘it was a credit to the power of IEF that the changes demanded

by the unions were accomplished in just one day.’ Nevertheless, one developer pointed out

that although ‘the CASE workbench went from systems analysis to code generation really well,

however, [it was a weakness that] the requirements analysis and its documentation were not

addressed or integrated into the CASE workbench.’ This statement points to a potential weak-

Transforming information systems development through CASE

183

ness of CASE, one not easily resolved, as the project manager stated, because the transla-

tion of written requirements into modelling conventions has always plagued analysts – ‘no tool

is going to do that for you, it’s all down to the experience of the analyst and his ability to inter-

pret what users’ requirements are.’

In 1998, some 2years after the initial study, a follow-up investigation revealed that IEF had

been adopted as the IS function’s application development environment (ADE) of choice for

in-house ‘bespoke’ systems development within the organization; and for the OSS in particu-

lar. Thus, the initial management goal of introducing a function-wide development environment

was said to realized. IS managers interviewed stated that the subsequent roll-out of IEF across

the IS function was facilitated by the lessons learned from the adoption and use IEF on the

GAS project. In addition, two analysts on the GAS/IEF project were promoted to the position

of project manager as part of a strategy to integrate their knowledge and experience from the

use of IEF in the pilot project to the development of new systems within the organization using

the I-CASE workbench. An IS function manager involved in the selection and introduction of

IEF stated that, ‘without IEF or COOL:Gen, or whatever they are calling it now – by the way,

it’s not called CASE anymore, now it’s application development environments or ADEs –

re-engineering the fault handling system and integrating the GAS fully into the new version of

the [FHS] could have been a monumental task.’ He added that ‘if we hadn’t gone down the

IEF road when we did, we would have been in a right mess. With the shortage of staff here

and the number of new systems we have to implement, the transformation of the company

would have been slowed down considerably and IT would have had to shoulder the blame.’

This IT professional pointed out that because of idiosyncratic business requirements the IS

function had to build proprietary systems, and would be using COOL:Gen, Sterling Software’s

new IEF-based ADE, for these projects. He also indicated that other approaches to applica-

tion development and procurement were adopted, VIZ ‘we’ve also gone to Telia and KPN to

transfer in some of their systems, and we’ll be using SAP and other canned software for

support activities such as logistics and ﬁnancial reporting.’

IS managers and developers in Telecom are of the opinion that the tight integration of IEF’s

tools and facilities has led to maintenance costs being trimmed signiﬁcantly as a result of the

capabilities of IEF to cascade changes made at early stages of the development life cycle

through to the ﬁnished product. Developers in the GAS project stated that IEF’s test features

also added greatly to the relative ease with which post-development changes were made to

the system. In other development projects, including the evolution of the GAS, IEF’s capabil-

ities have been argued to have a considerable impact upon lowering post-development costs.

It was also reported by IS managers that the important productivity gains which accrued

through CASE in the GAS project (where a fully developed system was produced within a 3-

month period) were replicated in subsequent projects. So too were the improvements in

user–developer communication experienced during the development of the GAS. Overall, IT

professionals were of the opinion that CASE helped them produce systems of a higher quality

and which require less maintenance; they also said that it allowed systems to evolve and to

be re-engineered to meet changing business needs.

184

T Butler

I-CASE tools that increase developer productivity and associated beneﬁts (RQ3)

The effectiveness of the structured methodology embodied in the IEF CASE workbench,

coupled with its prototyping ability, won the praise of all members of the development team:

‘the methodology does enforce a rigorous approach to development, it was really good.’ In

the previous section, IS managers and developers attested to the beneﬁts that accrued from

CASE use on the GAS project. Although the data and process modelling tools won special

praise, the prototyping techniques supported by IEF were universally acclaimed as being

critical to the success of the GAS development project. For example, IEF’s prototyping capa-

bilities proved to be invaluable as, in the words of one developer, ‘the effort put into the require-

ments analysis was too restricted . . . the prototyping facility allowed us to compensate for this

. . . [it] gave users a sense of presence and ownership of the system . . . they could actually

see the changes they recommended.’ According to the user representative, who actively used

the CASE tools, ‘what was perceived as a requirement, quite often was not, prototyping drove

[the actual requirements] out . . . what we started out with and ended up with was totally dif-

ferent’. However, as another developer commented, ‘the prototype couldn’t functionally do any-

thing . . . it was very good in a cognitive sense, but we had to describe how the data ﬂows

would take place’; this was perceived as being a drawback, but not signiﬁcant so as to detract

from the overall effectiveness of the prototyping approach adopted. The scripting tool that

allowed developers to write pseudo-code and the code generator which integrates the output

from this tool and the data modelling, process modelling, and prototyping tools were also con-

sidered to be key components of IEF. To avoid the undesirable consequences of developers

handcrafting generated code, and thus threatening the integrity of a particular software version

and losing the beneﬁts of CASE in terms of documentation and version control, the project

manager put a policy in place to the effect that any and all changes would be made before

the code generation stage. Despite the positive comments on the capabilities of IEF’s code

generator, developers pointed out that the code generated might not be optimal for all appli-

cations. A case in point here was that while IEF was being used by an Israeli software vendor

to develop a mainframe-based application for Telecom Éireann developers had to handcraft

the code because database performance factors mandated high-speed access and retrieval

of data, something that IEF’s code generator could not guarantee. Thus, developers and IS

managers were all too aware that the structure and efﬁciency of the code output from IEF’s

code generator might not be suitable for all applications. The technical problems that arose

in the GAS project also called into question IEF’s ability to support proprietary network pro-

tocols and different database management systems. On a positive note, IEF’s test and debug

tool won special praise from experienced developers, who noted how quickly problems were

identiﬁed and resolved.

In the ﬁnal analysis, it was IEF’s tool integration that was commented on by developers and

IS managers; tight integration of tools that implemented the IE methodology was, according

to practitioners, IEF’s major strength.

Transforming information systems development through CASE

185

DISCUSSION AND CONCLUSIONS

Previous research has cast doubt on the beneﬁts of CASE use. The present interpretivist

investigation joins several recent studies – both quantitative and qualitative – in arguing that

CASE has the potential to improve developer productivity and the quality of both the process

and product of systems development (for examples, see Norman & Nunamaker, 1989; Finlay

& Mitchell, 1994; Dahanayake etal., 1996; Iivari, 1996). It was seen that a multitude of con-

textual factors exerts both positive and negative inﬂuences on the ability of developers to

realize these beneﬁts. For example, in accordance with Bruner’s (1990) observations on the

formation and inﬂuence of social actors’ subjective ‘intentional states’, it was observed that

IS manager and developer attitudes towards and commitment to the use of I-CASE were

shaped by cultural inﬂuences emanating from the immediate IS context (for example, the

project management style that incorporated a consensus approach to I-CASE use by ana-

lysts, programmer and user representative), from the organizational context (for example, the

participative policy on decision making and the use of JAD and PD approaches, previous

experience with SSADM), and from the environmental context (for example, the support and

advice obtained from the I-CASE vendor). This accords well with model proposed by Orlikowski

(1993). One point worth noting, however, is that because the development team was specially

selected to participate in what was, in essence, a pilot study on I-CASE adoption and use, it

is difﬁcult to predict the impact that other less well-disposed or skilled developers would have

had in a project such as this. Following Orlikowski (1993), it is not unreasonable to surmise,

though, that developer attitudes and cultural inﬂuences within an organization would be sig-

niﬁcant determinants in achieving the beneﬁts associated with CASE use. This proved to be

the case as IEF and later COOL:Gen (IEF’s newest variant) were formally adopted by the IS

function for use in all ‘bespoke’ in-house development; it was clear, also, that the CASE imple-

mentation process beneﬁted from the lessons learned in the pilot project as IS managers used

them to mitigate potential negative contextual inﬂuences. In addition, the beneﬁts attributed to

CASE use in the pilot project supported what was a signiﬁcant investment in IEF (over

£250000, according to one IS manager) by the IS function in 1996–7; this investment was

expanded signiﬁcantly when the IS function decided to migrate to COOL:Gen.

Beyond Orlikowski’s model of CASE adoption and use

Although the model proposed by Orlikowski (1993) provides an adequate framework from

which to conceptualize CASE adoption and use, this study illustrates that it requires exten-

sion (see Table3) in order to describe explicitly important characteristics of the phenomenon.

In response to the research questions posed, previous sections have highlighted several

salient issues found to be critical for CASE adoption and use. It was seen, for example, that

the prototyping tools were central to the successful use of the I-CASE workbench within the

context of the RAD development approach adopted (cf. Agresti, 1986). Team selection and

make-up were also important. Developers found that the tools provided to implement the IE-

based data and process modelling were easy to use and well integrated with the other CASE

186

T Butler

tools in the workbench. The ﬂexibility and ease of use of the scripting tool and code genera-

tor drew special praise from developers and end-users alike; so too did the testing and trace

tool (cf. Post etal., 1999). However, on the down side, developers found that translating the

analysis ﬁndings to CASE modelling conventions problematic and would have preferred CASE

support in this area also. Finally, there were several technical issues with the CASE-devel-

oped end-product that required signiﬁcant problem solving on behalf of both analysts and

CASE vendor alike. All in all, the web of relationships that relates context to process, and

which are mapped by Orlikowski’s model, were very much in evidence. The analytical frame-

work presented in Tables3 and A1, coupled with the sections which a nswer the research

questions, reveal that signiﬁcant reciprocal inﬂuences existed between the external, organi-

zational and IS contexts and social actors involved in the process of CASE adoption and use.

Nevertheless, in the present paper, these issues are described with a ﬁner degree of granu-

larity than in the original study by Orlikowski (1993), this should render the study’s ﬁndings

more accessible to practitioners and researchers.

Radical and incremental change around CASE

It is clear that in Telecom Éireann the nature of change associated with CASE was radical in

terms of the pilot project, but incremental in terms IEF’s roll-out across the division responsi-

ble for bespoke IS development. Unlike the rationale for CASE adoption in Orlikowski’s two

organizations, IS managers in Telecom intended to radically change the process by which

systems were developed, reduce costs and increase productivity, but only in speciﬁc areas.

Other elements of Telecom’s IT strategy also addressed the productivity problem, namely

through the outsourcing of IS development projects, the use of customizable application soft-

ware, and the introduction of ERP products such as Systemanalyse and Programmentwick-

lung (SAP). One of the major concerns of IS managers in Telecom here was to ensure that

post-development modiﬁcations and maintenance activities for in-house developed ‘bespoke’

systems would be performed rapidly and with a minimum of effort; this applied also to out-

sourced applications developed using IEF.

The well-articulated fears that technological tools such as CASE (see Cooley, 1987) would

result in the deskilling of developers did not appear to have an effect on the CASE-related

attitudes of IS managers, analysts or programmers in this company. It was clear from events

in Telecom Éireann that developers were keen to ease the burden of pressures put on them

by the organizational requirement to develop an ambitious portfolio of complex systems in a

rapid manner; they seemed unconcerned by a possible loss of skills. Rather, programmers,

whose skills appeared to be most under threat, welcomed the opportunity to broaden their

development-related knowledge and competencies and perform analysis and design activities

– this was true of analysts also, who saw an opportunity to participate throughout the devel-

opment process and exercise more control over the attributes of the eventual product. In many

respects, one of the unintended consequences of the adoption and use of CASE was to have

developers focus more on the area of analysis and design which, according to Jarke & Pohl

(1993) and Jayaratna (1990), is the source of many of the problems associated with the devel-

Transforming information systems development through CASE

187

opment process. Nevertheless, a down side for developers is the likelihood that their mobility

across the IT industry could be limited if they are tied to a particular CASE tool and if they

have been unable to develop a broader skills base. However, because of the limitations of

CASE code generators to produce tight efﬁcient code, the demand for programming skills is

unlikely to decline, as is the demand for IT professionals, which was not as strong in the early

1990s when much previous qualitative research on the topic was conducted.

SUMMARY OF FINDINGS

Table4 summarizes this study’s ﬁndings and provides sound advice for practitioners. In addi-

tion, the issues dealt with in the table help highlight the answers to the research questions

posed in earlier sections. To recap, the ﬁrst section of Table4 provides several recommenda-

tions to practitioners on the measures taken to help maximize successful outcomes to the

process of CASE adoption, implementation and use (RQ1); while the second section lists

several of the beneﬁts that accrued from CASE use in this organization (RQ2). In respect of

the third research question posed, it is clear from this study’s ﬁndings that a well-integrated

CASE tool set, with comprehensive modelling, versatile prototyping and well-engineered code

Table 4. Beneﬁts of CASE use and recommendations for practitioners

Management recommendations and checklist for CASE adoption implementation and use

Adopt an open, participatory style of project management

Carefully select project team participants

Facilitate developer and user commitment to the use of the I-CASE and to the development project

Develop a consensus among developers by the project team

Use a pilot project to test the suitability of the I-CASE platform

Ensure that the CASE tool set is easy to use, customizable, well integrated and includes prototyping and code

generation tools as standard

Focus development activities around prototyping

Ensure that post-development changes are made at the modelling stage to maintain the integrity and maintainability

of systems

Adopt a participative approach to development incorporating both JAD and PD

Ensure that comprehensive vendor training and post-training support for all project team members

Develop and maintain a strong relationship with the vendor at both IS function management and project team level

Suggested beneﬁts of I-CASE

Allows more focus on the problem area of analysis and design

Enables signiﬁcant gains in developer productivity

Reduces development time

Reduces development costs

Reduces maintenance costs

Improves user–developer communication

Results in a higher quality and better maintained product

Allows systems to evolve and be re-engineered to meet changing business needs

188

T Butler

generation and testing features, is required if the beneﬁts associated with CASE are to be

realized (RQ3).

Limitations and future research

One of the obvious limitations of this study is that it is conﬁned to one case; however, Stake

(1994), Mintzberg (1979) and Lincoln & Guba (1985) point out that much can be learned from

a single case, especially when reﬁning theory or in helping to establish the limits of gener-

alizability. Constructivists do not use the latter concept; instead, they focus on transferring the

ﬁndings to other social contexts. Accordingly, the transferability of this study’s research ﬁnd-

ings and conclusions is argued to be dependent on the ability of the researcher as a human

instrument to capture the socially constructed reality of the organization under study. While

the present case and its ﬁndings attempts to represent this ‘reality’, care needs to be exer-

cised when interpreting and transferring this study’s results. That said, further empirical

research is required to validate the extended framework and to indicate areas where altera-

tion is required when it is applied in speciﬁc research contexts.

One ﬁnal point of note is that the translation of requirements statements into data and

process models is one area that CASE does not deal with effectively (a similar claim could

be made in respect of object-oriented models). This is an interpretive process and calls on

the experience and skill of seasoned analysts. It is worthwhile to suggest that case-based

reasoning (CBR) technologies could be integrated into an I-CASE product to provide a knowl-

edge base for the identiﬁcation of data entities, processes and so on (for an overview of the

use of CBR technologies in organizational contexts, see Davenport & Prusak, 1998). This

would allow CASE to support what is a complex interpretive process.

In conclusion, then, the ‘rich picture’ offered in previous sections of this paper provides

insights into the complex network of contextual inﬂuences at work in the adoption and use of

CASE for systems development. Simplistic models of CASE adoption and use have not, in

the past, fully captured the phenomenon in all its richness. The extended CASE research

framework, as presented herein, provides an appropriate point of departure for future studies

and helps contribute towards a cumulative body of knowledge on the phenomenon.

R E F E R E N C E S

Aaen, I., Siltanen, A., Sørensen, C. & Tahvanainen, V.P.

(1992) A tale of two countries: CASE experiences and

expectations. In: The Impact of Computer Supported

Technologies on Information Systems Development,

Kendall, K., Lyytinen, K. & De Gross, J.I. (eds), pp. 61–

91. North Holland, Amsterdam.

engineering: an empirical study. MIS Quarterly, 15, 375–

401.

Bansler, J.P. & Havn, E. (1994) Information systems devel-

opment with generic systems. In: Proceedings of the

Second European Conference on Information Systems,

Baets, W.R.J. (ed.), Part IV, pp. 707–715. Nijenrode

University Press, Breukelen, Holland.

Agresti, W. (1986) New Paradigms for Software Develop-

ment. IEEE Computer Society Press. Washington, DC.

Berger, P. & Luckmann, T. (1966) The Social Construction

of Reality – a Treatise in the Sociology of Knowledge.

Doubleday, Garden City, NY.

Banker, R.D.

& Kauffman, R.J. (1991) Reuse and

productivity in integrated computer-aided software

Transforming information systems development through CASE

189

Bleicher, J. (1980) Contemporary Hermeneutics: Herme-

neutics as Method, Philosophy and Critique. Routledge

and Keegan Paul, London.

Dahanayake, A.N.W., Sol, H.G. & Dietz, J.L.G. (1996) Auto-

mated tool design to improve the practice of methods

use. In: Proceedings of the 4th BCS Conference on

Information Systems Methodologies: Lesson Learned

Blum, B.I. (1994) A taxonomy of software development

methods. Communications of the ACM, 37 (11), 82–94.

Bødker, K. & Pedersen, J. (1991) Workplace cultures:

looking at artifacts, symbols and practices. In: Design at

Work: Collaborative Design of Computer Systems,

Greenbaum, J. & King, M. (eds), pp. 121–136. Lawrence

Erlbaum Associates, Hillsdale, NJ.

from the Use of Methodologies, Jayaratna, N.

&

Fitzgerald, B. (eds), pp. 117–128. University College

Cork, Ireland.

Davenport, T.H. & Prusak, L. (1998) Working Knowledge;

How Organisations Manage What They Know. Harvard

Business School Press, MA.

Boland, R.J. (1985) Phenomenology: a preferred approach

to research in information systems. In: Research Me-

thods in Information Systems, Mumford, E., Hirschheim,

R., Fitzgerald, G. & Wood-Harper, T. (eds), pp. 193–201.

Elsevier Science Publications, The Netherlands.

Bruner, J. (1990). Acts of Meaning. Harvard Business

Press. Cambridge, MA.

Davis, G.B., Lee, A.S., Nickles, K.R., Chatterjee, S.,

Hartung, R. & Wu, Y. (1992) Diagnosis of an informa-

tion system failure; A framework and interpretive pro-

cess. Information and Management, 23 (5), 293–318.

Deloitte and Touche (1997) 1996 CIO Survey: Major Pack-

ages. Deloitte and Touche LLP, http://www.dttus.com.

Erlandson, D.A., Harris, E.L., Skipper, B.L. & Allen, S.D.

(1993). Doing Naturalistic Inquiry: a Guide to Methods.

Sage Publications, London.

Butler, T. (1998a) Towards a hermeneutic method for inter-

pretive research in information systems. Journal of

Information Technology, 13, 285–300.

Finlay, P.N. & Mitchell, A.C. (1994) Perceptions of the ben-

eﬁts from the introduction of CASE: an empirical study.

MIS Quarterly, 18 (4), 353–369.

Butler, T. (1998b) Philosophy and method: an application

of hermeneutic theory for interpretive research in the

social sciences. ESRC Working Paper No 09/98,

National University of Ireland at Cork (UCC), Cork.

Butler, T. & Fitzgerald, B. (1997) An empirical model of the

information systems development process. In: Training

and Education of Methodology Practitioners and

Researchers, Jayaratna, N., Fitzgerald, B., Wood-

Harper T. & Larrasquet, J.-M. (eds), pp. 53–64/ Springer-

Verlag, London.

Fitzgerald, B. (1994) The systems development dilemma:

whether to adopt formalised systems development

methodologies or not? In: Proceedings of the Second

European Conference on Information Systems, Baets,

W.R.J. (ed.), Part IV, pp. 691–706. Nijenrode University

Press, Breukelen.

Folkes, S. & Stubenvoll, S. (1992). Accelerated Systems

Development. Prentice Hall. Hemel Hempstead,

Hertfordshire.

Calloway, L.J. & Ariv, G. (1991) Developing and using a

qualitative methodology to study relationships among

designers and tools. In: Information Systems Research:

Contemporary Approaches and Emergent Traditions,

Proceedings of the IFIP Tc8/WG 8.2 Working Confer-

ence, Nissen, H., Klein H.K. & Hirschheim, R. (eds),

pp. 175–193. Elsevier Science Publishers,. The

Netherlands.

Gadamer, H.G. (1975). Truth and Method. The Seabury

Press. NY.

Guba, E.G. & Lincoln, Y.S. (1994) Competing paradigms in

qualitative research. In: Handbook of Qualitative

Research, Denzin, N.K. & Lincoln, Y.S. (eds), pp. 105–

117. Sage Publications, CA.

Guinan, P.J., Cooprider, J. & Sawyer, S. (1997) The effec-

tive use of automated application development tools.

IBM Systems Journal, 36, 124–139.

Cavaye, A.L.M. (1995) User participation in system devel-

opment revisited. Information and Management, 28,

311–323.

Györkös, J. & Rozman, I. (1993) Assessment and control

of the requirements elicitation process in an CASE envi-

ronment. In: Information System Development Process;

Proceedings of the IFIP WG8.1 Working Conference

on the Information Systems Development Process,

Prakash, N., Rolland C. & Pernici, B. (eds), pp. 135–227.

Elsevier Science Publications, The Netherlands.

Heidegger, M. (1976). Being and Time. Harper & Row, NY.

Holland, C.P., Light, B. & Kawalek, P. (1999) Beyond enter-

prise resource planning projects: innovative strategies

Chervany, N.L. (1973) Discussion comments for empirical

studies of management information systems. Data

Base, Winter, 5 (2–4), 180–181.

Connolly, J.M.

& Keutner, T. (1988) Introduction. In:

Hermeneutics Versus Science? Three German Views,

Connolly J.M. & Keutner, T. (eds), pp. 1–67. University of

Notre Dame Press, IN.

Cooley, M. (1987) Architect or Bee? the Human Price of

Technology. The Hogarth Press, London.

190

T Butler

for competitive advantage. In: Proceedings of the 7th

European Conference on Information Systems, Pries-

Heje, J., Ciborra, C., Kautz, K., Valor, J., Christiaanse,

E., Avison, D. & Heje, C. (eds), pp. 288–301. Copen-

hagen Business School, Denmark.

Lorin, H. (1996). Doing IT Right. Manning Publications,

Greenwich.

Madison, G.B. (1988). The Hermeneutics of Postmoder-

nity: Figures and Themes. Indiana University Press,

Bloomﬁeld, IN.

Iivari, J. (1996) Why are CASE tools not used? Communi-

cations of the ACM, 39 (10), 94–103.

Markus, L. & Robey, D. (1988) Information technology

and organisational change: causal structure in

theory and research. Management Science, 34, 583–

598.

Introna, L.D. (1997). Management, Information and Power:

a Narrative for the Involved Manager. MacMillan Press,

London.

Martin, J. (1990). Information Engineering, Vols I, II and III.

Prentice Hall. Englewood Cliffs, NJ.

Isoda, S., Yamamoto, S., Kuroki, H. & Oka, A. (1995)

Evaluation and introduction of the structured methodol-

ogy and a CASE tool. Journal of Systems Software, 28,

49–58.

Marshall, C. & Rossman, G.B. (1989). Designing Qualita-

tive Research. Sage Publications, CA.

McFarlan, W. & Nolan, R. (1995) How to manage an IT out-

sourcing alliance. Sloan Management Review, Winter,

31 (2), 9–23.

Jarke, M. & Pohl, K. (1993) Vision driven system engi-

neering. In: Information System Development Process;

Proceedings of the IFIP WG8.1 Working Conference on

the Information Systems Development Process,

Prakash, N., Rolland, C. & Pernici, B. (eds), pp. 3–20.

Elsevier Science Publications, The Netherlands.

Jayaratna, N. (1990) Systems analysis: the need for a

better understanding. International Journal of Informa-

tion Systems Management, 10, 228–234.

Miles, M.B. & Huberman, A.M. (1994). Qualitative Data

Analysis: an Expanded Sourcebook, 2nd edn. Sage

Publications, CA.

Mintzberg, H. (1979) An emergent strategy of ‘direct

research’. Administrative Science Quarterly, 24, 582–

589.

Myers, M.D. (1995) Dialectical hermeneutics: a theoretical

framework for the implementation of information system.

Information Systems Journal, 5, 51–70.

Jayaratna, N. (1994). Understanding and Evaluating

Methodologies, NIMSAD:

a Systematic Framework.

McGraw-Hill, London.

Norman, R.J. & Nunamaker, Jr, J.F. (1989) CASE produc-

tivity perceptions of software engineering professionals.

Communications of the ACM, 32, 1102–1108.

Orlikowski, W.J. (1993) CASE tools as organizational

change: investigating incremental and radical changes

in systems development. MIS Quarterly, 17, 309–340.

Parkinson, J. (1990) Making CASE work. In: Case on

Trial, Spur, K.& Layzell, P. (eds), pp. 213–242. Wiley,

Chichester.

Kemerer, C.F. (1992) How the learning curve affects CASE

tool adoption. IEEE Software, May, 23–28.

Klein, H.K. & Myers, M. (1999) A set of principles for con-

ducting and evaluating interpretive ﬁeld studies in infor-

mation systems. MIS Quarterly, 23, 67–94.

Kling, R. & Scacchi, W. (1982) The web of computing:

computing technology as social organisation. In:

Advances in Computers, Vol. 21, pp. 1–90. Academic

Press, New York.

Patton, M.Q. (1990). Qualitative Evaluation and Research

Methods. Sage Publications, London.

Lee, A.S. (1993) Electronic mail as medium for rich com-

munication: an empirical investigation using hermeneu-

tic interpretation. In: Proceedings of the Fourteenth

International Conference on Information Systems,

DeGross, J.I., Huff, S.L. and Munro, M.C. (eds), pp. 13–

21. Orlando, FL.

Post, G.V., Kagan, A., Keim, & Robert, T. (1999) A struc-

tural equation evaluation of CASE tools attributes.

Journal of Management Information Systems, 15,

215–234.

Prakash, N., Rolland, C. & Pernici, B. (eds) (1993) Infor-

mation system development process. In: Proceedings of

the IFIP WG 8.1 Working Conference on the Informa-

tion Systems Development Process. Elsevier Science

Publications, The Netherlands.

Lee, A.S. (1994) The Hermeneutic circle as a source of

emergent richness in the managerial use of electronic

Mail. In: Proceedings of the Fifteenth International

Conference on Information Systems, pp. 129–140.

Vancouver, BC.

Rader, J., Brown, A.W. & Morris, E.J. (1995) Operational

use of CASE integration: an investigation of the state of

practice. Journal of Systems Software, 28, 58–68.

Robey, D. & Azevedo, A. (1994) The organizational and

cultural context of systems implementation: case ex-

Lewis, P.J. (1994) Information – Systems Development.

Pitman Publishing, London, UK.

Lincoln, Y.S. & Guba, E.G. (1985) Naturalistic Inquiry.

Sage, Beverly Hills, CA.

Transforming information systems development through CASE

191

perience from Latin America. Accounting, Management

and Information Technologies, 4, 23–37.

Westrup, C. (1994) Practical understanding: hermeneutics

and teaching the management of information systems

development using a case study. Accounting, Manage-

ment and Information Technology, 4, 39–58.

Ricoeur, P. (1981) The model of the text: meaningful action

considered as a text. In: Hermeneutics and the Human

Sciences, Thompson, J.B. (ed.), pp. 197–221. Cam-

bridge University Press, Cambridge.

Winograd, T. & Flores, F. (1986). Understanding Comput-

ers and Cognition: a New Foundation for Design. Ablex

Publishing Corporation, Norwood, NJ.

Song, X. & Osterweil, L.J. (1994) Experience with an

approach to comparing software design methodologies.

IEEE Transactions on Software Engineering, 20,

364–384.

Wood-Harper, A.T., Antill, L. & Avison, D.E. (1985). Infor-

mation Systems Deﬁnition: the Multiview Approach.

Blackwell Scientiﬁc Publications, Oxford.

Stake, R.E. (1994) Case studies. In: Handbook of Quali-

tative Research, Denzin N.K. & Lincoln, Y.S. (eds),

pp. 236–247. Sage Publications, CA.

Yin, R.K. (1989) Research design issues in using the case

study method to study management information

systems. In: The Information System Research Chal-

lenge: Qualitative Research Methods, Vol. 1, Cash, J.I.

& Lawrence, P.R. (eds), pp. 1–6. Harvard Business

School, Boston, MA.

Subramanian, G.H. & Zarnich, G.E. (1996) An examina-

tion of some software development effort and produc-

tivity determinants in ICASE tool projects. Journal

of Management Information Systems, 12 (4), 143–

160.

Biography

Sumner, M. & Ryan, T. (1994) The impact of CASE: can it

achieve critical success factors. Journal of Systems

Management, June, 16–21.

Tom Butler is a College Lecturer in Management In-

formation Systems at University College Cork (UCC).

Formerly a telecommunications engineer with Telecom

Éireann (now eircom), Tom has a wealth of practical ex-

perience in the IT industry. He holds an MSc in Informa-

tion Systems from the National University of Ireland and is

currently completing his PhD at UCC. His research inter-

ests encompass the design, development and implemen-

tation of IS and include such topics as the use of CASE,

user participation, organizational change and the role of IT

competencies in the provision of IT infrastructures. He is

also interested in the application of interpretive methods

for research in IS. His research has been published and

presented at a number of international conferences and

he has several book and journal publications.

Teng, J.T.C. & Galletta, D.F. (1991) MIS research directions:

a

survey of researcher’s views. Data Base,

Winter/Spring, 53–62.

Texas Instruments (1992) IEF Technical Description—

Methodology and Technical Overview. Technical Report.

Texas Instruments, Dallas, TX.

Visala, S. (1991) Broadening the empirical framework of

information systems research. In: Information Systems

Research: Contemporary Approaches and Emergent

Traditions, Proceedings of the IFIP Tc8/WG 8.2 Working

Conference, Nissen, H., Klein, H.K. & Hirschheim, R.

(eds), pp. 347–364. Elsevier Science Publishers, The

Netherlands.

APPENDIX A

TableA1. Organizational change around CASE tools in Telecom Éireann (adapted from Orlikowski, 1993)

Article Doi

DOI: 10.1046/j.1365-2575.2000.00081.x

Source and publish data:

Authors:

Article abstract of DOI:10.1046/j.1365-2575.2000.00081.x

Full text of DOI:10.1046/j.1365-2575.2000.00081.x

Products guided by the article

R&D Labs maybe for 21086-81-7

Relevant to this article

Hot Product