Research " INFORMATION ENGINEERING IMPLEMENTATION ISSUES: AN INFORMATION SYSTEMS MANAGER''''S PERSPECTIVE " pdf

INFORMATION ENGINEERING IMPLEMENTATION ISSUES: AN INFORMATION SYSTEMS MANAGERS’ PERSPECTIVE to software development which imposes a rigorous discipline on the systems development process

This manuscript has been reproduced from the microfilm master UMI films the text directly from the original or copy submitted Thus, some thesis and dissertation copies are in typewriter face, while others may

be from any type of computer printer

The quality of this reproduction is dependent upon the quality of the

copy submitted Broken or indistinct print, colored or poor quality illustrations and photographs, print bleedthrough, substandard margins, and improper alignment can adversely affect reproduction

In the unlikely event that the author did not send UMI a complete manuscript and there are missing pages, these wili be noted Also, if unauthorized copyright material had to be remeved, a note will indicate the deletion

Oversize materials (e.g., maps, drawings, charts) are reproduced by sectioning the original, beginning at the upper left-hand corner and continuing from left to right in equal sections with small overlaps Each original is also photographed in one exposure and is included in reduced form at the back of the book

Photographs included in the original manuscript have been reproduced xerographically in this copy Higher quality 6" x $" biack and white photographic prints are available for any photographs or illustrations appearing in this copy for an additional charge Contact UMI directly

to order

UMI

A Beil & Howell information Company

300 North Zeeb Road Ann Arbor Mi 48106-1346 USA

313/761-4700 800.521-0600

The members of the Committee approve the doctoral

dissertation of Patrick T Hogan

Supervising Professor

Ỷ

by PATRICK T HOGAN

Presented to the Faculty of the Graduate School of

The University of Texas at Arlington in Partial Fulfillment

of the Requirements for the Degree of

DOCTOR OF PHILOSOPHY

THE UNIVERSITY OF TEXAS AT ARLINGTON

December 1994

UMI Microform Edition 9521915 Copyright 1995, by UMI Company All rights reserved This microform edition is protected against unauthorized

copying under Title 17, United States Code

UMI

300 North Zeeb Road Ann Arbor, MI 48103

supervising professor, Dr M K Raja, has been a key individual in my development from early in the doctoral program As part of the dissertation project, we drove to many corporate meetings relating to Information Engineering Without the contribution of his many contacts

in industry and his excellent insights on systems development, this thesis would not have been possible

The other members of the dissertation committee raised thought-provoking questions, provided useful suggestions and supported the project in many ways Dr L L Schkade has always encouraged me, and has provided me with the conceptual foundation in systems with which to conduct this study He was instrumental in my entry to the doctoral program, and began to cultivate a research spirit in me from those early days

Dr Peter Mykytyn has always made time to answer my questions, and has raised critical and important questions of his own about the study which have been very helpful in focusing my research efforts

Dr Craig Slinkman has provided me with a thorough background in data modeling, which is necessary to perform research in Information Engineering With regards to this

methodology and data analysis, were extremely useful

Dr John Hassell has always had an open door and has welcomed my seemingly endless questions during the doctoral program He has shared his professional contacts unselfishly, and has truly enabled me to seek my own level of success As the graduate advisor and my minor field representative for the dissertation, his suggestions have been worthwhile and saved me a great deal of effort

I would like to express my gratitude to Dr Frank Navratil and the Wasmer Fund at John Carroll University for their support and for partially funding the research conducted in this study

I would also like to express my gratitude to the many corporate systems analysts and data modelers who consented to interviews during the development of this research, as well

as the many IS managers who participated in this project I am especially thankful to Kent Anderson, without whose contributions the research project could not have been completed

It is very difficult to accomplish a professional endeavor without support from one’s family My wife, Terry, supported me in so many ways Throughout the doctoral program, when I was working without pause, she would try to make sure that all the other family details were taken care of I am thankful to have had her by my side My children, Lindsay and Brian, have given up the company of their father on many occasions I certainly

appreciate the many sacrifices of my family

iv

important part of his life’s ambitions My dear mother has stood by my decision to return to graduate school and has provided support throughout the program

October 28, 1994

INFORMATION ENGINEERING IMPLEMENTATION ISSUES:

AN INFORMATION SYSTEMS MANAGERS’ PERSPECTIVE

to software development which imposes a rigorous discipline on the systems development process The practitioner press has provided experiences of success and failure in

Information Engineering implementation, but these are anecdotal in nature and are not the results of scientific study To remedy this situation, this study systematically searches a broad base of literature to develop a comprehensive model to represent the implementation of

a technical innovation like Information Engineering The model includes many of the significant factors found in the studies reviewed in the literature The model was empirically tested in a field study through the use of a pre-tested questionnaire, and the results

statistically analyzed with the method bivariate regression

vi

ABSTRACT cành HH nong nà Hà TH HT Tà 08010 00101 LIST OF ILLUSTRATIONS - chì HH HH HH nh LIST OF TABLUES - HH HH ng TH Hà Hà HH HC HH Hà HH ghiu Chapter

94900101 0(9)0101515

The SpecifÍC ÍsSUe€ - - 5À SH TH HH HH TH HH ng ghe Huy 010088 0007Ẽ0Ẽ078867 6 Prior Implementation Research - cm

hệ .ìJ89) 0.0000 Research Plan and Organization of the Study - cce ce, REVIEW OF THE LITERATURE - nen re ÍntroduCtÏOH «co HH TH HH HH HH HC TT Backgroundd sành HH HH HH HH th HE TH TH ngà tin Methods and Methodologles - - HH re Methodology Defined - -ó- c2 cà HH HH TH HH ngư Impact of Methodologiies «sàng ng ng 1kp

A Need for Inecreased RiBOT cà HH HH HH ng Information EngÌn€€ring << can HH HH HH HH Hee

Innovation Defined ch HH HH HH nh HH ng nh Hee Technical versus Admimistrative InnovatiO'S c«-ce.eesee Initiation versus Implementation sec

An Organizational Change/Process Model of the Implementation of a Technological Ínnovation - - -< cty Process SfUÏ€S HH HH HH Ho TH KH Tàn HH hư Process Theory of Change - SH HH ng ngư Organizational Change ÏsSu€s . o- 5< cà sec Se sen ky Organizational Change Research HH, Information Engineering as Organizational Change - Normative Research Model - - s- csccHHnHHHYt H n 4 Hrg

vi

Factor SfUÏ€S HH 2 9T HH nh TH T gn trrh 43 Management SuppOFt sàn HH HH HH ng HH He 43 Management Support-Model Ì -.- co eeeeeres 45 User ParticipatÏOT - - cá HH TH ng TH HH HH tt 45 User Participation -Model 2 - che 50 Training and Education Ăn ng ngưng 50 Training and Education-Model 3 - «+ c«se<e« 31 Change AB€nCY ch HH HH HH HH ng TH tr 52 Change Agency-Model 4 - Hàng HH ni 53

Task Changes 53

F49 bo nh 59

Measures of Success in Implementation Research -«‹ 59

THE )20/90599)09 cm 60

Nature Of The Researchh - - HH HH HH HH TH Tnhh Hư 60 The Research Quesfion -.- Ác à c1“ HH TH HH HH 60 8: cac 0 61

Hypotheses - nhàn HH HH Hy 01110181104 08174 64 Management Support-Hypothesis Ì Hee 64 User Participation-Hypothesis 2 - óc riờg 64 Training and Education-Hypothesis 3 - -ceeceeieereee 64 Change Agency-Hypothesis 4 nhe 64 Task Changes-Hypothesis Š SH Hye 64 Design Of The Survey Instrument :cccccssssesesssesessessesesseeeneneeeseseeeeees 65 Measurement .cccccssseecsscsssecssescseccsseecneesessesseeesesessssssssesreevessesareoesesesenees 67 Managpement SuppOrt nàn H001 ke 67 Commiitmen( - ö Ác HH ng HH ngưng 67 PartiCipatÏOn - HH HH HH HH Hàn TH Hà Hưng 68 Acceptance/Utilizationr «cty 68 User Participation -s- s0 12 7 69 Needs Solicitation -. 5c nàng gen 69 ;) 0 ÔÔÔÔÔÔÔ 69 Acceptance/UtilizatiOn - 7s tietieieererieesree 69 Change AgenCy .- cà chen 1010101141111 xe 70 Change Agency CycÌ€ cà HH1 rren 70 Training and Educational Requiremenits . sec 71 0-3 72 Knowledge TrannSÍST Án HH H1 rn 72 Technical Training - ng tr nhi 72 User Training and Support «sen 72

viii

Task Changes 73 IE-Based Management -.- s5 Site 74 Increased Interaction - sec HH 0 re 74 ReinfOrC€Im€TIL . 5< Sàn HH TH Hưng 4 0 01 08116 306 74 IE-Based Development nen, 75 Successful Implementation of Information Engineering 75 Level of Success Am 76 Research Strategy - HH2 111010111 1m 1e re 76 Research Method sàn HH ng in 80 Survey MeaSUF€S ó0 0001101110 01 1see §0 Pilot Study _ cằeeeHeHheHH ri 81 Sample ceeiieiiehieeheehheiheeieree 84 Validity And Reliability che, men 85 External ValidÏty - HH HH Hàn g1 86 Content and Construct VaÌidity - nà HH ng gà 87 Reliability .Ăe.eeiHehheieiiree 90 b1) 0-8 90 Single test (Internal consIstency) cccceeeereeirrerrrrre 91 Reliability Calculations - Hee re 92 Intermal Validity 00000 94

kì L3114218i/[oi:1: 0 95 Administration Of The Questionnaires án 96

IV DATA ANALYSIS AND RESULTS ccccesssssecssesteeessssessesessesneessesssenes 100

Overview Of Analytical Approach - «sen 6 100 Bivariate Regression AnÌYSIS - chen HH e4 100 Method - So neeeeeexee —— 100

;c¬) 017 101 Summary of Resulfs - cành 0112111011 7 trà 104

60) 52713 106 Observed Empirical Relationships . - «che 106 Management Support - che re 106 User ParticipatiOn - cà HH 011010114011 11101011 111 107 Training and Education - Ăn Sen 10t 107 Change Agency -: c1 T1 001404 111 111 re 108 Task Changes 0 109

ix

B FREQUENCY AND SUMMARY STATISTICS OF QUESTIONNAIRE

i2 — 118 21:08:96 1007 124

1 Organizational Change/Process Model for Management Science

System Implementation s5: Sen 11.1 te 40

2 Organizational Change/Process Model for Information Systems

Implementation cccssssssessssesessssesessesessenssssassnesssssecseeesnecnsnssnsseseseeesenneates 41

3 Organizational Change/Process Model Adapted for Information

Engineering Implementation .cccscssssessesseeseeseessneneessseceeenenseeseeenenenseeneses 42

4 Components of the Organization .cssscscsesessesesssssssseesseneenerenserersnensteesenertenenes 54

5 Organizational Change/Process Model Adapted for Information

Engineering Implementation .csscsssesssesesesseseceerseeneeseeeseneensecneeserenesenens 62

6 Research Model of Information Engineering [mplementation 63

7 The Variable Of Management Support Operationalized .- - +: 68

8 The Variable of User Participation Operationalized -. - so esnserereeres 70

9, The Variable of Change Agency Operationalized -. -eesesreeeerrrre 71

10 Training and Educational Requirements Operationalized -«- 74

11 Task Changes Operationalized «ship 75

xi

1 Variables and Scales in the Pilot and National Questionnaires - 83

2 Calculated Reliabilities of Independent Variable Scales In the Survey Instrument 93

3 Comparison of Source List, Sample Used and Responses by Industry 99

4 Bivariate Regression Results for Independent Variable - Management Support 101

5 Bivariate Regression Results for Independent Variable - User Participation 102

6 Bivariate Regression Results for Independent Variable - Training and Education 103

7 Bivariate Regression Results for Independent Variable - Change Agency 103

8 Bivariate Regression Results for Independent Variable - Task Changes 104

9 Summary of Bivariate Regression R€sulÌfS . s5 sang 105

xii

The General Issue The computer industry has experienced a brief but nonetheless active life The first workable general purpose computer, the ENIAC, was purchased by the United States

government in 1946 At the time, it was believed that only six of these machines would ever

be needed In the nearly 50 intervening years, there have been continuous, and frequently major, improvements in computer hardware capability This is particularly true in hardware development, where the history is one of astounding success The power and speed of the hardware has continued to increase almost exponentially through successive “generations,” with no apparent end in sight As the processing capabilities of the computer have steadily increased, so has the price-per-processing-operation steadily declined during the same period The result has been a phenomenal growth in the acquisition of computers by business and industry

After organizations acquire large computer installations, their attention naturally turns

to the utilization of these general purpose computing machines in their business This deployment requires the development of software components However, the history of software development has not enjoyed the same good fortune as that of hardware In fact, while there are some modest advances in software development, there are many failures The

Science Committee organized the Garmisch Conference to focus its attention on the problems

of software, and to discuss possible techniques which might lead to their solution The organizers saw a need for “software manufacture to be based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering” (Naur and Randell, 1969, p.13)

Another approach to solve the problems of software, was the automation strategy, which has had a long history in the computing field An early voice in this respect is the CODASYL systems committee, circa mid-1950s, whose objectives read: “To strive to build

up an expertise in, and to develop, advanced languages and techniques for data processing, with the aim of automating as much as possible of the process currently thought of as

systems analysis, design and implementation” (cited in Teichroew and Sayani, 1971)

While the Garmisch Conference organizers wished for the emergence of a more rigorous form of ‘software engineering,’ and the CODASYL systems committee desired full systems automation, it would be decades before these wishes and desires would be fulfilled However, through the efforts of Dijkstra (1968) and others the field of information systems software development progressed from an ad hoc collection of techniques, to more structured methods More recently, software development has enjoyed the rapid growth of what may be termed formal methodologies, many of which are rather sophisticated (Olle et al., 1982, 1983) These software development methodologies act to prescribe the behavior of

Despite the emergence of numerous, so-called methodologies, systems are still built today, that solve the wrong problem or no problem at all Many systems are underutilized,

do not meet their potential, or fail to be used at all (Lucas, Ginzberg and Schultz, 1990) Other systems are built that are hopelessly difficult to understand and use, or inefficient, or incorrect or unreliable These failures are not localized in just one phase of the software development process, but are evident throughout the cycle These failures are exhibited in every stage: in requirements analysis, specification, design, programming and certainly in maintenance (Jackson, 1992) Practitioner publications chronicles the intractable woes of software development, the demand for business-critical applications, the growing backlog of aging COBOL systems that require maintenance, and the shortage of quality software developers (Amoroso and Zawacki, 1992) Additional software development problems noted include lack of integration, lack of timely delivery, and a growth in system costs Despite transformations in computing and hardware environments, for some organizations there exists a shortfall in software development methodology (Van De Velde, 1992) Some have even gone so far as to claim that the problems in software development have reached the level of a software crisis (Amoroso and Zawacki, 1992)

While many organizations may have adopted the formalized procedures set forth in

methodologies such as Structured Systems Analysis (Gane and Sarson, 1979; DeMarco, 1978), the resulting systems still have high failure rates Early software development

frameworks by the developer Research has indicated that software development

methodologies have been implemented in a piecemeal fashion in many organizations

(Friedman and Cornford, 1989) Additionally, developers in practice may not follow the methodology in detail (Westrup, 1993) This may be one reason for the limited success of methodologies in actual software development

However, there is a new concept in the systems development field which would seem

to offer great promise for assisting information systems managers in imposing a rigorous discipline on the systems development process This promising approach is referred to as Information Engineering, and it could represent a renewed hope for the emergence of a more rigorous form of ‘software engineering’ sought after by the Garmisch Conference organizers

in 1968, as well as the full systems automation goal proposed by the CODASYL systems committee in the 1950s Information Engineering was originally developed in the early 1970s by Clive Finkelstein and Edgar Codd while they were at IBM (Finkelstein, 1989, 1992) In the mid 1980s, Information Engineering was popularized by James Martin (1990a, 1990b, 1990c), and he assisted in the development of Information Engineering into an integrated, full lifecycle approach with automated tool support in the late 1980s One concise definition of Information Engineering which captures its general notion is that of its co- originator, Clive Finkelstein He states,

with no knowledge of computers, but instead with an expert knowledge of their business

- in conjunction with expert systems which provide rapid feedback to management for refinement of the strategic plans (Finkelstein, 1989)

Finkelstein, furthermore, points out that Information Engineering is based on a

mathematically solid conceptual foundation since it evolved from relational theory

More commonly, Information Engineering is defined by its four levels James Martin (1990a, 1990b, 1990c) has summarized these four levels as follows:

e Information Strategy Planning: applied to the enterprise as a whole

e Business Area Analysis: in which data models and process models are built for a business area Different teams may analyze different business areas concurrently

e Business System Design: Systems are designed with the help of automated tools that employ the information stored during the information strategy planning and business area analysis process

e Construction: Systems are constructed with the help of automated tools such as code generators, which are coupled to the system design tools (Martin, 1990a)

In addition to its levels, Information Engineering has certain characteristics, as set out

by James Martin Information Engineering applies its techniques to the enterprise as a whole,

as opposed to the previous practice of focusing on individual projects This approach helps identify for development, the systems with maximum strategic value to the organization

systems Information Engineering emphasizes the identification of common data entities and rules, which can result in a high degree of reusable design and reusable code Finally, the common repository of Information Engineering is coupled with automated tools for planning, analysis, design and construction This makes the practical application of Information Engineering feasible, and provides a necessary control mechanism to ensure complete, consistent and continuous application of the approach by the developer (Martin, 1990a)

When an organization adopts the Information Engineering approach for systems development, it must select a methodology and an automated Computer Aided Software Engineering (CASE) toolset which supports Information Engineering The methodology establishes formalized procedures for software development, which are in accordance with the principles of Information Engineering These procedures are very detailed in nature, and offer support for every task Furthermore, the procedures of the methodology assist the development team members and managers by mandating the proper steps to take, in what order the steps are to be taken, as well as providing quality criteria for all deliverables Some organizations develop their own methodologies, while many have adopted one of the

packaged methodologies offered by vendors, such as Information Engineering Methodology (IEM), offered by James Martin & Co In order to implement Information Engineering, a CASE tool that integrates the multiple levels of Information Engineering is a practical necessity Most companies have adopted one of the packaged CASE toolsets offered by

In recent years, Information Engineering has moved from research and development

to practical applications in the workplace Trade publications have chronicled a growing number of success stories involving organizations that have made a strong commitment to Information Engineering technology (Anderson, 1992; Aouad et al., 1993; Desmond, 1992; Huff and Copeland, 1993; Nash, 1992; Robins, 1991; Stevens, 1992; Sweeney, 1993) One industry in particular, the insurance industry, has received attention in the practitioner press for its successes in Information Engineering implementation (Conning, 1993; Daniele, 1992; Francett, 1992; Kastrud, 1991; Truglio, 1993) For example, Massachusetts Mutual Life Insurance Co (MassMutual) has reported great success with Information Engineering which has been established as the standard process for developing new applications MassMutual restructured its information systems by developing a plan in the form of a systems

architecture that covered all aspects of technology as it related to business requirements This architecture, which incorporates the Information Engineering approach, unites the corporate business vision, and resulting strategies, to all technology initiatives The

MassMutual Information Engineering approach implementation has offered intangible benefits such as optimization of existing staff talents and enhancing the IS staff's career development opportunities (Pouliot, 1992, Daboul, 1991) The favorable publicity

surrounding high-profile Information Engineering implementations such as MassMutual have helped to encourage dramatic increases in Information Engineering adoption Data modeling

discussing Information Engineering utilization and investment indicate that many

organizations have begun to implement Information Engineering technology

Despite the publicized success stories, the successful implementation of Information Engineering technology is by no means assured American Airlines’ division, AMR

Information Services, has suffered a major systems development failure in Confirm, a large reservation system it was developing for its Information Consortium (Intrico) partners Information Engineering was utilized in the project, and major difficulties in code generation were experienced (Wilder, 1992) If Information Engineering technology is to live up to its full potential, managers will require an understanding of how to promote successful

implementation

The practitioner press has provided guidelines to increase the odds of success with Information Engineering (Jaakkola, 1991, Kerr, 1991, Martin, 1992) However, these guidelines are based on experiences and opinions These experiences are anecdotal in nature, and are not the results of scientific study Empirical evidence is needed to answer critical questions about the most effective means of implementing Information Engineering in organizations Few empirical studies have been performed on the issues involved in the implementation of complex systems development methodological approaches Little is known about the types of problems encountered and the methods that have been found to be effective in dealing with those problems The lack of empirical research on this topic is

This study seeks to fill that void by gathering data about the experiences of American companies in establishing and managing a systems development approach for complex systems Such a study is even more valuable to the extent that it is rooted in theory Poor theory development and inadequate measurement of constructs have plagued IS research in a wide variety of topics (Dickson et al., 1982) As Keen (1980) has argued, the lack of a cumulative tradition in IS is one of the serious issues facing the field Yet, without a shared set of definitions, topics and concepts, there can be no cumulative tradition (Keen, 1980) It

is also clear that well-defined constructs based on theory, and the operationalization of these constructs through measures with high degree of validity and reliability is a prerequisite for the beginning of a cumulative tradition The definition for innovation proposed by Van de Ven (1986), and adopted in the current study, suggests that an innovation is an idea or product which is new to the relevant unit of adoption Since Information Engineering is a new and different approach to systems development for an assimilating organization, it can clearly be viewed as an innovation Furthermore, technical innovations concern new

technologies, products and services, and have had a tremendous impact on firms and

industries (Utterback, 1974) Asa result, innovation theory related to technical innovations from the field of management can provide the reference discipline for this empirical study of Information Engineering

Innovation Theory

Review of the innovation literature reveals that innovation has a complex, over-time nature in organizations As a result, the process approach of study is appropriate (Markus and Robey, 1988) Research has indicated that the innovation process in organizations consists of a typical sequence of two main phases, Initiation and Implementation The activities involved in these two phases are quite disparate, and the demarcation line between them is the decision to adopt (Zaltman, Duncan, and Holbek, 1973; Rogers,1983) Imple- mentation commences with the decision to adopt, and consists of all the events, actions, and decisions involved in putting an innovation into use (Rogers, 1983) Since a systems

development approach such as Information Engineering is a specific instance of an

innovation to the organization, the implementation issues relating to Information Engineering

as an innovation is appropriate as the focus of this study

Prior Imp! ion

The Information Engineering approach consists of hardware, software, data, and procedures, and utilizes people in its activities Therefore, for study and research purposes, Information Engineering can be considered similar to an information system The body of work performed on the implementation issues relating to technical innovations such as operations research, management information systems, and computer integrated manu- facturing is quite significant There are many similarities between the implementation issues

of information systems and the Information Engineering development approach, and

information systems research can be used as a foundation for research in Information

Engineering This research on information systems implementation has been divided into three segments: theory, factor research, and process studies (Lucas, 1981) Theory research puts forth propositions about implementation, while factor research searches for individual factors which may be associated with implementation success Process research recognizes that different time elements exist in implementation, and seeks relationships among the various participants with reference to these time elements Despite the fact that numerous individual studies of information systems implementation have addressed a number of potential variables, there is a lack of consensus in the field on a single implementation strategy which will result in success (Lucas, 1994)

Furthermore, research has demonstrated that introducing a complex, technically advanced information system into an entity, often results in changes at levels of the firm other than that of the target subsystem Indeed, many systems are contemplated for the very purpose of effecting change at multiple levels of the firm When the impact of the system’s implementation radiates out beyond the target subsystem, organizational change occurs Therefore, the implementation of large, complex information systems must be managed, and researched, at the organization level, rather than the local, subsystem level

Given the lack of a standard implementation strategy identified in the literature, boundaries need to be established for the purposes of research in this study of Information Engineering implementation It is necessary, then, to develop an implementation model, for use in researching systems development approaches, that builds on prior research in

information systems, and integrates the different types of models - theory, factor and process

An implementation model that integrates theory and process models can be constructed by drawing from the works of the following:

© Dale Zand and Richard Sorensen (1975) who extend the theory of change, developed

by Lewin (1947, 1952) and Schein (1964), to management science systems, along

with

e@ Robert Zmud and James Cox (1979) who view information system implementation as

an organizational change process

Additionally, in recent research, Wanda Orlikowski suggested that the implementation of the Information Engineering approach should properly be viewed as a process of organizational change over time It is a tenet of this study to derive a model of the implementation process, based on organizational change from management science, information systems, and

computer integrated manufacturing research, and apply that model to research on the systems development approach Information Engineering

Research Question What important variables are present when Information Engineering succeeds within organizational units? The dependent variable in this study is the information systems

manager’s perception of the success of the implementation of Information Engineering The degree of success, or non-success, in Information Engineering implementation is a self- reported measure The independent variables consist of the five proposed causal variables identified in the review of innovation literature: management support; user participation;

change agency; training and education; and structural and task changes

First, a comprehensive, normative implementation model is developed from a review

of management science, information systems, and computer integrated manufacturing

research Second, through the use of a panel of experts that normative model is extended for use in studying the implementation of the systems development approach Information

Engineering Third, the normative Information Engineering implementation model is

empirically tested in a field study Fourth, the empirical results are analyzed using statistical methods such as bivariate regression Finally, the research concludes with a discussion of the significance of the findings, the study’s limitations, and future directions of research in this

area.

REVIEW OF THE LITERATURE

Introducti This chapter first presents a definition of software development methodology and then presents an overview of the software development approach under consideration in this study, Information Engineering The second part of this chapter presents a definition of innovation, and then proposes a three-stage model of implementation based on an organi- zational change process This stage model can be applied to a technical innovation such as the implementation of Information Engineering Third, the technological innovation

literature is reviewed to yield five factors that may relate to the degree of perceived success

of Information Engineering implementation in organizations This leads to five hypotheses

on expected relationships between each of the factors and the degree of perceived success of the Information Engineering implementation in organizations

Background

Computer-based information systems have been in practical commercial use since

1954 Since that time organizations have designed and built many applications for which the computer is an extremely valuable tool Early in its history many large and medium-sized organizations harnessed the power of the computer to automate such functions as payroll, accounts payable, accounts receivable, general ledger accounting, and inventory control

14

During the creation of these early EDP transaction processing systems development practices consisted primarily of an ad hoc collection of techniques These techniques were eventually packaged up and held out to practitioners under the label of ‘methodologies’ The use of the term ‘methodology’ may appear to indicate the formal structuring of the overall process of systems development, but in most cases this was not the case Instead, it was often a mere change in terminology, from the term method, because it sounded more formal (Friedman and Cornford, 1989) Included among the numerous methodologies are Structured Systems

Analysis (SSA), (Gane and Sarson, 1979; DeMarco, 1978), SADT (Ross and Schoman, 1977), Information Systems and Analysis of Change (ISAC) (Lundeberg, Goldkuhl, and Nilsson, 1981), and others A lengthy description of such techniques is beyond the scope of this study; however, some of them are more fully described in Wasserman (1980)

Methods and Methodologies Methodology Defined The term "methodology" is used very loosely in the literature of information systems Literally, methodology means the organization (Jogos) of the right way (methodos: Greek for following a path) This would suggest that methodologies are approaches for the con- struction of new methods Unfortunately, the etymological roots have not guided the actual use of the word (Hirschheim and Klein, 1992) A brief analysis of the various meanings of methodology in the IS literature follows

Checkland (1972) defines methodology as "an explicit, ordered, non-random way of carrying out an activity independent of the content of that activity” This is subsequently

elaborated upon by distinguishing between method and methodology A methodology is “a set of principles of method which in any particular situation have to be reduced to a method uniquely suited to that particular situation” A methodology can be conceived of as inter- mediate in status between a philosophy and a technique, or method A methodology will lack the precision of a technique but will be a firmer guide to action than a philosophy Where a technique tells you “ how” and a philosophy tells you “what”, a methodology will contain elements of both “what” and “how” (Checkland, 1981)

Welke (1983), in a detailed treatment of the information systems development

process, defines a methodology as “a comprehensive procedural framework directed towards accomplishing a particular change in the object system” An object system is the focus of the development activity A methodology is composed of predetermined sets of tasks which are grouped into stages according to some prespecified set of methods which uses various tools and techniques Tasks are defined as single pieces of work which usually have predeter- mined deliverables associated with them Stages are sets of prespecified tasks undertaken to obtain some needed intermediate result Techniques are ways of accomplishing certain goals through the performance of simple steps, essentially human skills and tools Tools are specific objects or operations employed in the use of a particular technique, which can exist independently from the techniques which use them A method is defined as a description of a specified technique in some symbolic language

Gibson and Hughes (1994) promulgate the definition that “methodology is an

architectural framework grounded in the organization’s infrastructure that is based on a

common philosophy.” This is opposed to methods which are considered protocols, either graphical or textual in nature, for use in modeling objects, activities and associations of the organization Furthermore, a technique is considered a way of employing a modeling method

to portray organizational aspects, whereas a tool is an instrument for the implementation of the modeling methods (Gibson and Hughes, 1994)

Both Checkland's and Welke's definitions of methodology, as well as Gibson and Hughes’ definition, share a view that sees the concept of methodology as more compre- hensive than the term method, which implies techniques and/or tools This conception of methodology appears to be widely used and accepted by the information systems community, even though it is not necessarily consistent with the standard dictionary definition, where method is seen as a way of doing something; and methodology, the study or science of methods (Hirschheim and Klein, 1992) Maddison et al (1983) suggest that information systems methodologies came about as a collection of methods which proved to be valuable They suggest that where methods were successful, their originators and practitioners may have enhanced their supporting practices, techniques and tools, thus forming a methodology Such a definition helps to illustrate how methodologies have come about

Impact of Methodologies Methodologies are applied to control the efficiency and effectiveness of the software development process (Sol, 1983) Methodologies serve to set out a pattern of behavior for developers and users during the development process Simultaneously, they aid managerial control by making the intermediate results of this process more visible to managers through

the use of phases and milestones Unlike other professions, there is no widely recognized and enforced certification of information systems practitioners In fact, systems analysts are not trained professionally They do not receive the formal instruction in exercising professional judgment that occurs in apprenticeships, teaching hospitals, public accounting, or clerking for

a judge It is therefore difficult for systems analysts to deal with situations that require professional judgments

In this void, methodologies perform several very important control functions At the most fundamental level, they serve as a simple codification of experience Systems develop- ment is thereby improved through the systematic application of techniques that remind developers of aspects of improvement which should be considered (Westrup, 1993)

However, methodologies have developed considerably further than this fundamental level Two main trends can be seen First, a systematic development of techniques such as entity relationship diagrams, data flow diagrams and the like has occurred, and these techniques can serve aS a common reference among developers, over the life of a system Second, this common reference is enforced by a cookbook-like prescription of the stages that must be followed for the successful completion of a project This prescriptive format gives

developers support as to what steps to take at various points in the process of development Moreover, it provides managerial oversight of this process by presenting a series of

milestones to be completed At this secondary level, methodologies can be expected to enhance the successful implementation of systems development projects (Westrup, 1993)

By way of example, the application of structured techniques did have a positive impact on the development process By reducing the scope for error and by making error detection and correction easier, structured methods could increase the predictability of the systems development process Structured methods could also substantially reduce the costs

of systems development, particularly in the areas of testing, maintaining and enhancing systems The main impact of structured programming on the programming process lay in its ability to reduce the dependence on any individual programmer Standardized working methods, as opposed to individual ‘clever tricks', and increased clarity and readability of programs meant that the programming work could be more easily transferred between one programmer and another (Friedman and Cornford, 1989)

A Need for Increased Rigor Indeed, some have suggested that it is necessary to go further yet in terms of

improving control through the utilization of systems methodologies One group seeks to improve existing methodologies slowly through the provision of CASE tool support and the assimilation of features from either more advanced other methodologies or though an

improvement in the theoretical descriptive power of the existing development techniques (Olle et al., 1982, 1983, 1986, 1988) Indeed, some indications show that existing method- ologies do not prescribe procedures in full, and, in some cases, without adequate safeguards

in place, automation may even result in reduced rigor by allowing the invocation of less explicit meta-rules These rules are assumed by developers in their actions, but require detailed description in order to occur successfully through automation (Ryan, 1988) These

concerns pave the way for a second, more ambitious viewpoint This group desires to move from the mere support of information systems development by methodology to a more rigorous prescription of the same process using automation This could be achieved by utilizing increasingly sophisticated methodologies and integrated CASE tools (Couger et al., 1982) This increased sophistication goes well beyond the accepted meaning of the term methodology Indeed, this sophisticated approach forms an umbrella framework over the software development process, and would simultaneously support several development methods and techniques One such sophisticated approach to software development is called Information Engineering Information Engineering is a philosophy of integrated software development and management It involves the integration and coordination of strategic planning, systems analysis, design, construction, implementation, and maintenance through the use of computer systems Information Engineering provides a way of organizing the entire systems development and maintenance process to achieve greater efficiency, improved quality, faster system development, and enhanced flexibility in meeting the changing needs

of the systems users The capabilities of Information Engineering go well beyond those of a commonly accepted methodology, and this approach to software development is the focal point of this study

1ufoination Ensineeri

In the early 1980s, a new discipline called Information Engineering was enabled by the widening acceptance of the relational model and technological advances in Computer Aided Software Engineering (CASE) Information Engineering extends the development life

cycle to encompass strategic planning, as well as analysis and design Information Engi- neering represents a more comprehensive approach to systems development since it is data driven as well as procedure driven This dual focus allows the developer to concentrate the model building activity on the more stable facet of an organization, its data, as well as its activities This more rigorous development approach was first introduced by Clive Finkel- stein (1989, 1992) and was later popularized by James Martin (1990a 1990b 1990c)

The key to the power of Information Engineering is found in its degree of integration Information Engineering is an integrated set of tasks and techniques that support the entire systems development process Techniques are mechanisms, such as types of diagrams, used

to carry out tasks While many of the techniques used in Information Engineering originated elsewhere, Information Engineering clearly defines how deliverables from one technique relate to deliverables from other techniques within and across development stages Infor- mation Engineering operates from the following set of precepts (Texas Instruments Incor-

porated, 1992):

a Information is a corporate resource

°* a A comprehensive and cohesive approach for modeling information

requirements is essential

a Methods must encourage objectivity

a Techniques must foster communication

e 8 Automation is a requirement

ae | Reusability must be maximized

eg Business needs change

Information Engineering provides a comprehensive approach for meeting the

information needs of a business or an organization The most complete systems development approach devised to date, it encompasses all phases of the software life cycle including tech- niques for performing strategic information planning, analysis, design and system construc- tion Its range extends from analyzing business objectives through building executable programs in a target environment Conceived with automation in mind, Information Engi- neering envisions a central repository, automated diagramming tools, automated mapping of objects within and across diagrams, and automatic code generation This represents a truly comprehensive support facility

Information Engineering yields highly reliable systems geared to specific needs, while also addressing the greater good of the entire business The benefits of such a compre- hensive approach are clear when compared to the traditional approaches of building systems With a cohesive set of techniques applied to all aspects of development, application times diminish, maintenance costs drop significantly, and quality dramatically improves

Information engineers seek to understand an enterprise by building a representation of the business and its workings This representation, a business model, includes three primary and equally important components (Texas Instruments Incorporated, 1992):

es Business data (information)

ằẰằŠẼẽ Business activities (processes)

° u Interaction between the two

Initially conceptual and general, the model gradually becomes more concrete and detailed as it evolves so that the core elements of computerized systems - data, activities and interaction - eventually emerge as databases, dialogs and programs Information Engineering helps developers understand data, activities and their interaction on an abstract level Its method is to capture information at the highest possible level of abstraction and to incre- mentally refine each element until all of them combine to form executing applications The approach to Information Engineering is based on the principle of "divide and conquer” Developers address successively smaller portions of the business model as the level of detail increases, thus reducing each task to a manageable size

Classical Information Engineering methodology includes seven stages (Texas Instruments Incorporated, 1992):

a Information Strategy Planning (ISP),

e s Business Area Analysis (BAA),

es Business System Design (BSD),

` Technical Design (TD),

eu Construction,

e a Transition, and

s N Production

The first five stages correspond to the traditional system development stages Two additional stages, Transition and Production, address the movement of executing applications into production and the monitoring of applications once the system becomes operational

In theory, the seven stages execute like a waterfall cascading down so that all of one stage is completed before another stage begins In actual practice, however, this classical view rarely conforms to the realities of life Successful practice of Information Engineering relies on an understanding of both the approach and how it can be adapted to specific real- world situations In order to reach the degree of integration envisioned under Information Engineering, the following is required (Texas Instruments Incorporated, 1992):

° nf An encyclopedia to store the model's meaning, independent of presentation

° a A methodology to define the blueprints for integrity

a Automatic transformation of objects between levels of abstraction to

accomplish integrity

| Consistency checking within and across toolsets to ensure integrity

Furthermore, to attain a truly seamless interface requires that (Texas Instruments Incor- porated, 1992):

° 8 Complete programs can be generated from analysis and design specifications

° Business concepts remain directly linked to programming results