the enabling role of web services in information system development practices

ORI GIN AL ARTICLE

The enabling role of Web services in informationsystem development practices: a grounded theory study

Francesco Virili Æ Maddalena Sorrentino

� Springer-Verlag 2008

Abstract This study presents a grounded theory analysis of a case study in the

banking industry with a view to showing the enabling role of ‘‘Web services’’

technology in information system development practices. The grounded theory

analysis of the Cashier Management System development project at the Central

Europe Bank (a pseudonym) shows that Web services technology is a key tech-

nological enabler for more agile forms of IS development, characterized by

incremental analysis, requirements revision, requirements emerging in use and

incremental implementation. In particular, an initial in-depth analysis phase, con-

ducted in a traditional way, is then followed, during system development, by several

iterative phases of requirements revision/addition, in fulfilment of emerging or

previously unplanned user needs discovered along the way. Such system develop-

ment practices, enabled by the Web services technology and influenced by a variety

of contextual factors, cover a middle ground between methodical and amethodical

development processes.

This paper is the outcome of a joint effort from the two authors, who worked in close collaboration. This

version is to be attributed to Maddalena Sorrentino for the last section, and to Francesco Virili for the rest

of the paper, but Maddalena gave a substantial contribution in all the phases of research, elaboration and

presentation of intermediate results. The initial idea originating this contribution was first proposed as an

ECIS research in progress (Bello, Sorrentino and Virili 2002), to evolve at later stages and for different

workshops, including (Virili and Sorrentino 2004) and (Sorrentino and Virili 2005).

F. Virili (&)

Dipartimento Impresa Ambiente e Management,

Universita degli Studi di Cassino, Via S. Angelo, 03043 Cassino, Italy

e-mail: [email protected]

M. Sorrentino (&)

Dipartimento di Scienze Economiche, Aziendali e Statistiche,

Universita degli Studi di Milano, Via Conservatorio 7, 20122 Milan, Italy

e-mail: [email protected]

123

Inf Syst E-Bus Manage

DOI 10.1007/s10257-008-0097-x

Keywords Web services � Information system development methods �Grounded theory � Incremental analysis � Incremental development

1 Introduction

The so-called ‘‘Web services’’ is a rapidly emerging standard architecture for

distributed componentized software applications over the Web (Alonso et al. 2003).

Simply stated, the use of the Web services standards makes it possible to assemble a

software application with several independent parts (software components), each

accessible over the Web. Using Web services, programmers can compose a

‘‘virtual’’ software application like a puzzle, by accessing the different pieces (Web

services) over the Web, independently of their physical location.1

The aim of this study is to investigate whether the adoption of Web services

technology could make a difference in system development: do Web services

disclose new ways of developing software? If yes, Why? How? This question is

important, because Web services is nowadays one of the IT innovations attracting

the highest levels of investments, with little or no empirical studies on its impact

over system development practices. Nevertheless, this important question is still

unanswered: the next section will show how recent studies on web-based system

development are reporting contradicting results, as for whether ‘‘Web work’’

practices are actually different from traditional information system development

(ISD) practices2 or not.

To shed new light on this issue, we provide here one of the first in-depth

investigations of a commercial ‘‘Web services’’ software development project in the

banking industry. By using grounded theory analysis (Strauss and Corbin 1998), a

descriptive theoretical framework of the system development process enabled by

Web services is formulated. Its main finding is the identification of the fundamental

enabling role of the Web services technology on system development. In fact, Web

services technology, being based on XML, is shown to be characterized by

‘‘extensible serialization’’, which in turn is shown to be the fundamental enabler of

new practices in systems analysis (incremental analysis, requirements revision,

requirements emerging in use) and in systems implementation (incremental

implementation), taking into account the role of contextual elements, such as the

1 Web services is not the only technical solution available to this aim: standards like EDIFACT, COM

and many others are actually available. For a discussion, see for example K. Turowski, Spezifikation und

Standardisierung von Fachkomponenten Wirtschaftstinformatik 43(3), 2001, pp 269–281. The use of the

WWW infrastructure for inter-application communication is also not entirely new, as it can be viewed as

an evolution of B2B applications like e-marketplaces (Rossignoli C. The contribution of transaction cost

theory and other network-oriented techniques to digital markets, Information Systems and E-BusinessManagement 2007, doi:10.1007/s10257-007-0063-z; Rossignoli C and Mola L. E.M.P. As Enabler Of

New Organisational Architectures: An Italian Case Study, Proceedings of the Bled eCommerce Con-ference, 2004).2 In this paper the terms ‘‘traditional’’ and ‘‘classical’’ ISD practices will be used interchangeably. For an

extensive definition and discussion, see Baskerville R, Levine L, Balasubramanian R, Pries-Heje J and

Slaughter S. ‘‘Is Internet-Speed Software Development Different?’’ IEEE Software (20:6), Nov–Dec

2003, pp 70–77.

F. Virili, M. Sorrentino

123

http://dx.doi.org/10.1007/s10257-007-0063-z

target organization and its environment, the project team and application software

peculiarities.

In definitive, the Web services system development practices analysed here

materialize in the potential ability to build complex systems in a shorter, cheaper

and more flexible way in comparison with traditional system development practices.

1.1 Relevance and related works

1.1.1 The debate on changing ISD practices

There is growing evidence that Web projects ‘‘at Internet time’’ are often carried on

in ways different to those characterizing traditional ISD (Baskerville et al. 2003;

Baskerville and Pries-Heje 2001, 2002). Nevertheless, systematic patterns of change

in traditional system development practices, as a long-lasting consequence of recent

experiences with web system development, are still far from being fully understood.

In a recent study on agile system development practices named ‘‘short-cycle system

development’’ (Baskerville and Pries-Heje 2004) write: ‘‘We do not currently

understand the essential characteristics of short-cycle system development that are

enduring in actual ISD practices. The field appears to be in a state of transition’’.

The first studies on the subject (Baskerville and Pries-Heje 2001), triggered a

sparkling debate at IRIS 2003 (Glass 2003), advancing the idea that web system

development may constitute a new and quite different kind of ISD process. The

opposite view was that ‘‘golden rules’’ of classical ISD practices still hold for web

system development: there is nothing really new in web work, nothing that has not

already been experienced in the past (Kautz and Nørbjerg 2003).

The debate on web system development is still wide open, and not nearly enough

evidence have yet been collected to formulate a definitive solution.

1.1.2 Do classical ISD practices need revision?

In principle, there are two evident reasons to suggest, with the necessary prudence,3

that ‘‘classical’’ ISD practices may need revision.

First: organizational evolution. Classical ISD approaches were conceived in a

different era. Only a fraction of the organizations that existed in the 1970s

have survived up to today: for example, de Geus and Senge 1997 reports that

one-third of the companies listed in the 1970 Fortune 500 had disappeared by

1993. Those that survived, have often evolved into quite different ones, in

comparison with the past. An appealing and thought provoking contribution

by Truex et al. 1999 invites us to reflect on the need for continuous adaptation

of the ‘‘emergent’’ organizations that are increasingly common in several

industries nowadays. In consequence, modern system design should often be

characterized by continuous redevelopment to avoid ‘‘freezing’’ a changing

3 This issue is made more complex by the indeterminacy of factors like: (1) The wide range of ISD

methods and initiatives now available; (2) The non-existence of a unique definition of ‘‘classical’’ ISD

principles; (3) the ambiguity and generality of expressions like ‘‘web system development’’.

Information system development practices

123

organization with a fixed information system.4 The ‘‘classical’’ IS lifespan

(analysis, design, operation and maintenance, obsolescence, substitution) is

based on the assumption that a well-specified system could be well-designed

and then ‘‘frozen’’ and operated for a long time (at least a few years) before

becoming obsolete. In an ‘‘emergent’’ organization it may be impossible to

define a ‘‘perfect’’ set of system specifications, even after a deep and careful

initial stage of analysis.

Second: infrastructural evolution. Systems operating in global, unbounded

networks (like the Internet) might be inherently different is compared with

typical systems that were available when ‘‘classical’’ ISD practices were

originated. Consequently, contemporary systems may require different ISD

practices. This argument is developed in (Lyytinen et al. 1998).

1.1.3 Web services as enabling technology

Besides organizational evolution and infrastructural evolution, a third-order of

reasons could contribute to change classical ISD practices: the availability of new

software technologies and architectures, and particularly the emerging ‘‘Web

services’’ standards and tools. Our study shows how the availability of ‘‘Webservices’’ standards and tools is disclosing new ways of building information systems.

Such an argument may seem quite dated and somehow naıve. In particular, it

may appear to resemble the ‘‘technological imperative’’ perspective of the first

empirical works in the field (Markus and Robey 1988). Nevertheless, the descriptive

theoretical framework, grounded in observation, developed here, evidences the

fundamental enabling role of technology itself in software development practices.

Actually, the causal link is neither elementary nor unique: Web services technology

is a necessary, but not sufficient causal factor of change in ISD practices. Our study

shows how, besides technology, further fundamental factors are involved, including

software project market environment, cultural factors, completion speed, software

quality and related risk issues.

1.1.4 Web services: introduction

Web services is a component-based software architecture like DCOM or CORBA,

where the elementary building blocks are called ‘‘basic services’’ (Papazoglou and

Georgakopoulos 2003). Unlike DCOM or CORBA, Web services is XML-based,

therefore software systems based on Web services can make use of the Web

infrastructure. For an introduction on Web services application concepts refer to

Iyer et al. 2003; early strategies of adoption and use of Web services for enterprise

application integration are briefly outlined in Arsanjani et al. 2003 and analysed in

more depth in Alonso et al. 2003.

4 Continuous redevelopment shows affinities, but is distinct from the logic of ‘‘cultivation’’, as inherited

by the program of social studies launched by Claudio Ciborra. This logic is discussed in the context of the

public administration in De Marco M and Sorrentino M, Sowing the seeds of IS cultivation in public

service organisations. Journal of Information Technology, 22(2), 2007, pp 184–191.


123

Web services technology has three key attributes, that make it particularly

appropriate to our study (as opposed, for example, to a more generic reference to

‘‘web work’’): it is new, relevant and specific.

1. Web services is new: the first official standard reference architecture for Web

services was only recently published by the World Wide Web Consortium

(Booth et al. 2004). Significant design and standardization efforts are still

underway in the market.

2. Web services is relevant: the rapid prevailing of the ‘‘Web services’’ architecture

originally proposed by Microsoft and IBM among several concurrent standards

was characterized by a substantial amount of investment by all the major actors

in the industry. In Bello et al. 2002, it is argued that Web services may have great

potential for building dynamically adaptive information systems. As for the

market relevance, the Web services technology is attracting significant global

investments at a growing pace, in many industries (Rogers 2005).

3. Web services is specific: expressions like ‘‘web work’’ or ‘‘web development’’

are so broad and generic to include very different activities, ranging from

building a simple collection of html static pages to developing a complex,

XML-based multi-tier client–server system. In focusing on Web services we

refer to a family of technologies with very well-defined characteristics. Web

services is XML-based and component-based. As will be seen, some of the

peculiarities of the system development process under observation are related to

these specific characteristics.

1.2 Research question and paper structure

Our research question is the outcome of the arguments evidenced above. The

sparkling debate about traditional ISD practices evolution, together with the recent

appearance of ‘‘Web services’’ as a new, potentially relevant and specific

technology for agile development of web systems, naturally raises the question:

What are the peculiarities of ‘‘Web services’’ ISD practices?This study gives an answer to this question by formulating a descriptive

theoretical framework of a ‘‘Web services’’ ISD process, grounded on observation

of one of the first commercial ISD projects based on Web services, in the European

banking industry.

The paper is organized as follows: Sect. 2 describes the research methodology

adopted. Section 3 is dedicated to the grounded theory analysis of the case under

observation. This is discussed in Sect. 4, where it is compared and contrasted with

other recent research findings. The paper concludes in Sect. 5 outlining implications

for researchers and practitioners.

2 Research methodology

Given the exploratory nature of the research question, we opted for an in-depth case

study (Yin 1994). The research question is exploratory because it aims at obtaining


123

a thick description of the Web services ISD process, with no specific theory-

informed hypotheses to test: therefore, in the data collection phase, a particular

attention had to be devoted towards selecting and examining the potentially relevant

information sources, without any preliminary indication for causal relationships,

operational variables selection and model building.

An appraisal of immaterial and contextual factors like cultural aspects,

organizational attitudes and quality of relationships in the software development

teams were considered to be important, suggesting the use of a single in-depth case

study for theoretical elaboration.5

As shown below, a number of semi-structured interviews were conducted to

collect relevant information. Interview texts and relevant documents were then

analysed and coded according to the grounded theory methodology, following in

particular the detailed directions given in Strauss and Corbin 1998.6

Grounded theory analysis is particularly appropriate to our study for two orders

of reasons.

First, in several cases it has proven successful in conducting a rigorous in-depth

qualitative analysis of single-case studies: see e.g. (Orlikowski 1993) for an

exemplar GT-based work in the IS field. The direct link between theory and data

makes it possible to easily verify the existence and ‘‘density’’ of empirical

justifications grounding theoretical concepts.

Second, ‘‘grounded’’ theory is directly generated by empirical data and not

connected a priori to pre-existing theories. This aspect makes it particularly

appropriate for investigating an exploratory research question like ours.7

Therefore, by the correct application of the ‘‘grounded theory’’ methodological

framework it is possible to ensure that the theoretical description appropriately

5 The use of case study methodology in social sciences was thoroughly discussed also in Eisenhardt KM

‘‘Building Theories From Case Study Research.’’ The Academy of Management Review 14(4), October

1989, pp 532–550, raising the issue if better grounding theories on a single case (more in-depth and

focused on qualitative and contextual aspects—‘‘better stories’’) or on several cases, (more shallow and

focused on theoretical sampling -‘‘better constructs’’) (Gibb Dyer W Jr and Wilkins A ‘‘Better Stories Not

Better Constructs to Generate Better Theory: A Rejoinder to Eisenhardt.’’ The Academy of ManagementReview 16(3) 1991, pp 613–619); (Eisenhardt KM ‘‘Better Stories and Better Constructs: The Case for

Rigor and Comparative Logic.’’ The Academy of Management Review 16(3) 1991, pp 620–627).6 In addition, to better understand the technical and organizational complexity of the project, the

researchers could take advantage of the strong technical background and the right ‘‘feeling’’ for promising

investigative directions of the project manager, who actively participated in theory generation and

actually co-authored other reports and papers produced by this research.7 One could wonder whether theoretical concepts were actually emerging from data (and not imported

from pre-existing theories) in this study, as it should be according to the GT methodology. In facts, data

collection was based on a pre-existing questionnaire and informing theory was initially used to motivate

the exploration and later to discuss the findings. Actually, as shown in the next section, the open

questionnaire was intended just to launch the descriptive exploration, it was very broad and open to any

kind of free interpretation and contribution; on the other side, existing literature was used with care during

the final discussion, according to the indications given by Strauss and Corbin themselves: ‘‘When an

investigator has finished his or her data collection and analysis and is in the writing stage, the literature

can be used to confirm findings and, just the reverse, findings can be used to illustrate when the literature

is incorrect, is overly simplistic, or only partially explains the phenomena’’ (Strauss AL and Corbin J

Basics of qualitative research: techniques and procedures for developing grounded theory (2nd edn) Sage

Publications, Thousand Oaks, 1998, pp 52–53).


123

reflects the empirical setting (type EE generalization: from data to description) and

that the theoretical framework is actually generated by the data description (type ET

generalization: from description to theory). These two types of generalization are

thoroughly discussed in (Lee and Baskerville 2003).

2.1 Site selection

Given the limited spread of Web services technology in the banking sector at the

time the research was first embarked upon (Bello et al. 2002), gaining access to a

fully fledged Web services development project proved quite difficult. At the time, a

major Swiss bank (here referred to as the Central Europe Bank, CE Bank) was

engaging in an important initiative to redesign a part of its front-office application

portfolio using Web services technology. An early description of the system

appeared in (Virili and Sorrentino 2004). The new software application (Cashier

Management Systems, CMS) was devised to replace a pre-existing, partially

automated CMS supporting the bank’s cashiers in counter transactions like cash

withdrawals, deposit of valuable items and similar. The CE Bank looks at cashier

services as a non-critical complement to its primary business, private banking. In

fact, its core banking services are actually issued in the area of investment

management and portfolio management. Consequently, the new CMS was chosen as

an ideal low-risk ‘‘test-bed’’ to test the ‘‘Web services’’ technology: even in case of

failure, the bank’s core business activities would not be affected. Nevertheless,

reliability, security and quality of service were still primary requisites of the new

software solution.

The CE Bank’s information system is managed internally by the IT Division. The

development of new retail banking applications was partially outsourced to an

external software developer specialising in financial and retail banking systems. The

project team included both the bank’s and the provider’s specialists.

2.2 Data collection

Data was collected by way of semi-structured interviews and document reviews.

The interviews took the form of a series of very broad, open-ended questions based

largely on the questionnaire developed by Baskerville and Pries-Heje 2001. Some

adaptation was effected with a view to better focusing on the particular subject

under consideration. The interview was structured in five main parts:

1. information on the interviewee and the organization;

2. software development methods and tools;

3. software applications;

4. teams and people;

5. problems and challenges.

Interviews and field observations were supplemented with internal documents—

mainly technical literature—made available by the bank and by external sources. In

the first round, carried out between September 2003 and February 2004, a total


123

number of 11 interviews were conducted. On average, each interview lasted about

2 h. Two people were interviewed twice. The team leader was present at all the

interviews and actively intervened when necessary.

Five of the nine interviewees were bank employees while four worked for the

software company. Here follows the list of the interviewees.

From the bank:

– the IT executive;

– two project managers/functional analysts;

– two IS architects and integration managers.

From the software company:

– three members of the project team;

– the team leader.

The two researchers conducted together the interviews at the bank site. One of

the researchers took notes of the interviews using a laptop computer while the other

took hand-written notes. Later, the notes taken by the two researchers were re-

examined and compared. The final text of each interview was generated after

comparison and integration of the two different sources.

2.3 Data analysis

Grounded theory analysis is essentially based on two activities: open coding (the

identification and labelling of particular concepts in text passages) and axial coding

(the definition of the relationships between concepts). This process was carried out

with the help of a well-known software application for text analysis (Muhr and

Friese 2004).

In an initial phase, after transcription and comparison, all the interviews were

printed out and carefully examined to make sense of the general content and

meaning of the texts. Then, in order to generate some initial concepts—together

with their specific properties and dimensions—and to discover the basic relation-

ships between them, a detailed analysis was carried out. To this end, the two

researchers analysed and discussed line by line and even word by word a first batch

of interviews, taking notes and writing memos along the lines suggested by Strauss

and Corbin 1998 (see, in particular, Chapter 5, ‘‘Analysis Through Microscopic

Examination of Data’’).

After about 13 months from the first interviews, open and axial coding had

generated a list of three main categories (i.e. families of concepts) and 298 concepts

linked by relationships in 13 different networks. Finally, a few selected networks

have been redrawn with a specialized concept mapping software (IHMC Cmap

Tools, version 4.17), to improve the graphical clarity and effectiveness while

keeping the original content and structure of the original networks.

The outcome of both data collection and data analysis was validated together

with the software company team leader.

In the rest of the paper selected outcomes from this empirical study are

presented.


123

3 Grounded theory analysis: selected outcomes

The outcome of the grounded theory analysis is essentially constituted by a list of

concepts grouped into categories and subcategories, with multiple hierarchical

levels. During axial coding, categories and concepts are linked by relationships into

several networks of concepts. The most significant networks of concepts generated

through the empirical analysis of the European Central Bank were:

1. The context: bank organization and its environment, project team and

application software peculiarities.

2. The Web services technology and its properties.

3. The software development process and its main phases/activities.

These three core areas will now be shown in some detail, mentioning the rest of

the analysis outcomes only occasionally.8 Our attention will be directed in particular

to the most important concepts/properties, where the importance is expressed in

terms of so-called ‘‘groundedness’’, i.e. the number of citations (the number of times

a concept/property was mentioned during interviews) and in terms of so-called

‘‘density’’, i.e. the number of links to other concepts/properties.

3.1 The context: bank organization and its environment

Figures 1 and 2 give a portrait of the CE Bank and its environment, in terms of

concepts, properties and relations as emerging from the grounded theory analysis of

the interviews.

The graph in Fig. 1 is mainly the outcome of ‘‘scenario’’ interviews with the

bank’s Chief Information Officer (CIO) and with the bank’s information strategies

executive, integrated with some internal documents and finally assessed with the

project leader. Concepts and their properties are here represented by rectangles.

Properties are linked to pertaining concepts by the ‘‘is property of’’ relationship.

Concept and properties are organized in a hierarchy. In Fig. 1 ‘‘CE Bank’’ is a sub-

concept of the higher-level ‘‘Swiss bank’’ concept, as evidenced by the ‘‘is a’’

relationship The ‘‘CE Bank’’ concept is also characterized by the properties (from

left to right) ‘‘private banking as core business’’, ‘‘part of a primary financial

group’’, ‘‘multi-language’’, ‘‘with several branches and subsidiaries’’, ‘‘industry

leader (third in the home country)’’.

Each concept or property is ‘‘grounded’’ in one or more text passages, as

indicated by the first of the two numbers shown in the label, measuring

‘‘groundedness’’. The second number is the so-called ‘‘density’’, showing the

number of links with other concepts/properties. For example: the concept ‘‘CE

Bank’’, shown in the middle of Fig. 1, has groundedness 2, and density 11.

Groundedness 2 is related to two text passages with a description of the bank: the

first is in the interview with the bank’s CIO (Sect. 1, rows 9:82); the second is from

8 Indeed, besides the three networks of concepts related to the core categories, the researchers built

several additional networks, along with their mutual relationships. The three categories evidenced here

were selected as the most significant and investigated in more detail.


123

a technical document made available by the bank (rows 4:8). Density is 11 because

there are 11 relationships with other concepts/properties (of which only nine are

visible in Fig. 1 for the sake of clarity).

Figure 1 shows that the CE Bank is a Swiss bank: its national traits have

important reflections on cultural aspects like reliability, attention to order and

Fig. 1 Central Europe Bank organization and its environment: key characteristics in terms of concepts,properties and relations

Fig. 2 The influence of ‘‘private banking as core business’’ on a few important Cashier ManagementSystem requirements


123

formal procedures. CE Bank, though retaining its national cultural traits, has several

branches and subsidiaries in different countries, making it a multi-language

organization, which is also part of a primary international financial group.

The bank’s core business is private banking: CE Bank is among the top three

industry leaders in its country.

During the observation period, there was an ongoing cost restructuring initiative,

as a reaction to a recent market and industry crisis. The causal link between recent

market and industry crisis and cost restructuring is evidenced by the causal

relationship ‘‘is cause of’’ in the bottom left part of Fig. 1.

In Fig. 2 some organizational and contextual effects on the CMS are shown. The

chain of consequences departs from ‘‘private banking as core business’’. CE Bank

typical customers do not usually go to the counter for small and frequent retail

transactions (like e.g. bill payments, small cash withdrawals, etc). The typical

customer of a private bank rarely asks for cashier services; cash transactions are

usually more complex and higher-amount than in traditional banks. In Fig. 2, a

property of ‘‘private banking as core business’’ is ‘‘few cashier transactions, high

amount’’, with four main consequences (bottom part of the graph, from left to right):

first, the bank’s losses due to system errors may be very high, originating a need for

high levels of system reliability; second, reliability and correctness should be

ensured by a particularly advanced set of accurate and automated checks on each

transaction; third, losses from systems errors are charged to the IS department, to

make IS people directly responsible for software defects; fourth, fraud prevention is

particularly important and high levels of system security are required.

In Fig. 2 a second property of ‘‘private banking as core business’’ is ‘‘connection

to 42 world markets’’, with a causal link towards ‘‘high connectivity system’’: given

the nature of the bank’s core business, involving global trading of a rich variety of

financial products, the CMS has to be connected to the principal world financial

systems.

3.2 The context: project team and application software peculiarities

The CMS project was actually a partnership between the bank and an external

software company, named here ‘‘SmartCo’’. SmartCo is a niche software company

specialized in system integration in the banking industry.9 SmartCo is lean and

informal, as opposed to CE Bank, that was one of the few Swiss banks to build

internally its information system. At the time of the interview, the CE Bank

Information Systems Department had about 50 full-time employees specialized in

different areas of development and it was beginning to open to the market,

launching partnerships with external companies and also recurring to consultancies,

body rental and project works (17 temporary positions were opened).

9 From a memo written during interviews: ‘‘In SmartCo just one person (Marco) is the company holder,the company CEO and the project leader. The organizational aspects of the project (i.e. coordinationmechanisms, task assignment, centralization, specialization, formalization, control, evaluation, hierarchy…) are strictly connected with SmartCo characteristics, like dimension, market approach, business model(custom solutions), nature of the company (originally similar to a one-man company)’’.


123

Figure 3 below shows how the CMS project was organized in three different

teams working in close collaboration.

From left to right, the host/CICS project team, mainly composed by bank IS

people, was responsible for describing and incorporating the legacy host services in

the Enterprise Architecture Integration (EAI) system; the MQ/Candle EAI projectteam, composed by the bank EAI experts supported by the SmartCo project leader

and by a senior developer, was specialized in configuring and managing the EAI

infrastructure; the WS/XML hub project team, mainly composed by SmartCo

software developers, was responsible for developing Web services and user

interface of the CMS.

The project teams were working in close collaboration, giving raise to an

interesting mix of two different approaches to IS development. The cultural,

organizational and even technical diversity of the project was actually reflected by

ISD practices, as underlined in the following sections.

Figure 3 shows that the project is multi-platform, both in the technical and in the

organizational sense.

The project was conducted by the SmartCo team leader with a combination of

flexibility and strong leadership: ‘‘There is the team leader deciding who does what

(though in a very flexible way and on the basis of competences and ‘‘vision’’ of each

team member); but everybody can see everything. Each one writes a different piece

of code and interacts with the other developers. We are only in 4, and everybody

Fig. 3 Overview on the CMS project, composed by three main project teams


123

reminds who did what. The team leader has the responsibility of the whole and is

also a supervisor’’ (Elena, SmartCo developer10).

The CIO talks about a ‘‘high flexibility in project conduction’’: ‘‘In comparison

with our previous internal ISD projects, this was more a ‘‘pilot project’’, conducted

with higher flexibility; there was a relationship of strong collaboration with

SmartCo’’ (From the bank’s CIO interview).

The expression ‘‘pilot project’’, is from the actual words of the bank’s CIO,

which we found particularly meaningful (‘‘in-vivo code’’11), as shown here below in

Fig. 4.

The causal chain from ‘‘using a new technology’’ (groundedness 3) to

‘‘challenge’’ (groundedness 2) to ‘‘Pilot project’’ shows that using Web services

to develop the CMS was perceived as a new and challenging task, even a kind

of pioneering experience. More specifically, interviewees said that the CMS was

the ‘‘first project’’ in the bank based on Web services. They called it a ‘‘highly

relevant project as for IT innovation’’: working in partnership with SmartCo, the

bank was actually learning a new way of developing systems (‘‘IS Dept

‘‘insemination’’: learning effect’’), with a great potential of innovation. The

whole ‘‘insemination’’ process,12 in which the two companies where learning

Fig. 4 Cashier Management Systems project as a ‘‘pilot project’’

10 The team leader was present during this interview and he intervened for better specifying his role.11 ‘‘In conceptualizing, we are abstracting. Data are broken down into discrete incidents, ideas, events

and acts and are the given a name that represents and stands for these. The name may be one placed on the

objects by the analyst because of the imagery or meaning they evoke when examined comparatively and

in context, or the name may be taken from the words of respondent themselves. The latter are often

referred to as ‘‘in vivo codes’’ (Glaser and Strauss 1967)’’ (Strauss AL and Corbin J Basics of qualitativeresearch: techniques and procedures for developing grounded theory (2nd edn) Sage Publications,

Thousand Oaks, 1998 p 105).12 The word ‘‘insemination’’ is quite peculiar: it is actually an ‘‘in vivo’’ term, reflecting the Italian

expression ‘‘inseminazione’’ actually used by the interviewees.


123

from each other, was based on strong trust relationship: the concept of ‘‘Trust

relationship/partnership with external software company’’ has the highest

groundedness in Fig. 4, being mentioned in four different passages of text by

different subjects. On the other side of the coin, the CMS project was

characterized by more ‘‘frequent error and changes’’ than previous projects by

the bank. High error rate is potentially associated with high risk for the bank.

Therefore, to reduce risk in case of failure, the project was confined to a safe

and limited application area: cashier management services. Cashier management

has only a small direct impact on core business for CE Bank (‘‘no core business

to reduce risk’’).

Finally, the executive responsible for IT integration strategies pointed out

another interesting aspect of the pilot project: the possibility to ‘‘incorporate’’ in

the CMS much more corporate ‘‘knowledge’’ than in the past. As noticed above,

in private banks like CE Bank, cashier management services are not based on

simple, standardized, high-volume, low-amount transactions; CMS transactions

are often personalized, combined and adapted in many different and complex

ways. With the pre-existing semi-automated CMS, the typical cashier needed a

particular expertise and sensibility to fulfil customer requests, to be acquired

with experience and time. The CMS pilot project, based on a much more

sophisticated, but still flexible enough system, could potentially disclose new

ways of storing and diffusing corporate knowledge ‘‘IT for corporate knowledge

diffusion’’.

3.3 Properties of the Web services technology

After giving an overview of contextual elements and their influence of the CMS

project, our attention is now shifted to the Web services technology.

Figure 5 represents some of the key characteristics of the Web services

technology, as perceived by the CMS project teams members.

In the bottom part of the graph, the Web services technology shows two peculiar

properties: ‘‘extensible data serialization’’, and ‘‘platform independence’’.

Having groundedness 2, the property ‘‘extensible data serialization’’, was

mentioned two times in the interviews:

1. ‘‘Probably the system could have been written without Web services but

components configuration and data serialization would have been much longer.

We should have built very complex DCOM components’’ (Paolo, senior

programmer).

2. ‘‘Without Web services it would have been much more difficult, in particular

data serialization and component configuration. We should have built

components calling other components’’ (Paolo, senior programmer).

Basically, ‘‘extensible data serialization’’ is the technical feature enabling the

possibility to extend a Web services software component, adding new features,

without affecting pre-existing applications and users (‘‘incremental implementation

of the contract’’: see below). This property is not present in other component-based


123

technologies like DCOM. Working with DCOM the only way to extend a pre-

existing component is to build a new component with extended functionalities,

calling itself the old component for the old ones. This is the sense of sentence 2

above. Extensible data serialization affects in complex ways the versioning of

software applications based on Web services. For an in-depth technical discussion

see Erl et al. 2008.

Similarly, the property ‘‘platform independence’’, with groundedness 4, was

mentioned four times during interviews. Here are the relative quotes:

1. ‘‘The news with Web services is the fact that they are not chained to

platforms—operating systems and programming languages’’ (Elena, junior

programmer).

2. ‘‘There is no more the need to configure a server in a rigid way, you are not

limited anymore by platform. I do not have anymore limits in using a

communication gate’’ (Paolo, senior programmer).

3. ‘‘With Web services there is no more the limit of having to configure an

application by using a port. You are much more flexible. You are not limited by

platform type, because HTTP and SOAP are standard’’ (Paolo, senior

programmer).

4. ‘‘In Web services there are also points of strength: platform and language

independence’’ (Rita, junior programmer).

Fig. 5 Web services technology key properties and their enabling role


123

The ‘‘is enabling’’ relationship indicates the enabling role of the property ‘‘XML-

based’’ for the properties of ‘‘platform independence’’ and of ‘‘extensible

serialization’’.

3.4 Enabling effects of Web services technology: general view

In Fig. 6 a first general view is given of the enabling effects that result from the fact

that WS is XML-based. In particular, the upper part of the figure shows once again

that the property ‘‘XML-based’’ enables ‘‘platform independence’’ and ‘‘extensible

data serialization’’. In order to appreciate the role that these two factors play in the

ISD process, the process as a whole may be divided—in accordance with traditional

mainstream Software Engineering literature (see, for example Sommerville 2000,

Chapter 3)—into two main categories/macrophases: ‘‘system analysis and design’’

and ‘‘implementation, testing and operation’’.

As Fig. 6 shows, ‘‘platform independence’’ is mainly associated with system

‘‘implementation, testing and operation’’ (see Fig. 7 and accompanying discussion)

while ‘‘extensible data serialisation’’ has an enabling effect in relation to

‘‘incremental implementation of the contract’’, ‘‘simplified versioning’’ and

‘‘reusability’’.

The key property of Fig. 6, which is visible in the middle of the diagram, is

named ‘‘Incremental implementation of the contract (WSDL component interface)’’.

Fig. 6 The enabling role of Web services in the ISD process: how the key property ‘‘XML-based’’affected other properties and activities in the CMS project


123

Software contracts were originally devised to ensure reliability in object oriented

software design (Meyer 1992). In component-based applications, contracts play an

important role in communicating to potential consumers (i.e. users of the software

component) the functional properties of the component itself (Crnkovic et al.

2002).13

Usually (e.g. in DCOM or CORBA component-based technologies), a contract

cannot be extended incrementally. Once published, it is somehow ‘‘freezed’’

forever. Instead, the Web services technology, being based on XML (see previous

section), gives the possibility to change a software contract anytime, even afterpublishing the contract. This extensibility is easily accomplished just by adding new

content to the XML description of the contract, thanks to ‘‘native’’ XML

extensibility.

This means that a contract can be extended incrementally and is not ‘‘freezed’’ as

it is usual with traditional component-based systems. ‘‘Incremental implementation

of the contract’’ is a fundamental enabler for ISD practices: as discussed below, it is

deeply affecting both system analysis and design (Fig. 7), and system implemen-

tation (Fig. 8).

Fig. 7 The enabling role of Web services in the ISD process: how it affected system analysis and designin the CMS project

13 In particular, ‘‘…a contract lists the global constraints that the component will maintain (the invariant).

For each operation within the component, a contract also lists the constraints that must be met by the

client (the pre-condition), and that the component promises to establish in return (the post-condition). The

pre-condition, the invariant and the post-conditions constitute the specification of a component’s

behaviour’’ (Crnkovic I, Hnich B, Jonsson T and Kiziltan Z ‘‘Specification, Implementation, and

Deployment of Components,’’ Communications of the ACM 45(10) 2002, p. 37).


123

3.5 How ‘‘Web services’’ technology affected system analysis and design

Figure 7 shows the enabling effects of ‘‘Incremental implementation of the

contract’’ on system ‘‘analysis and design’’. The grounded theory analysis revealed

how, among the numerous concepts shown in the diagram, the most prominent one

(both in terms of groundedness: 6 and density: 8) was ‘‘requirements revision’’

(Fig. 7, top left). The possibility of revising and changing software requirements

originally formulated during system analysis was explicitly mentioned six times by

five different interviewees.14

Recall from Figs. 5 and 6 that ‘‘requirements revision’’ is enabled by ‘‘extensible

serialization’’, an exclusive property of Web services in the components family, due

to the fact that Web services is ‘‘XML-based’’. Some of the interviewees had

previous experiences with other component-based software technologies like

DCOM and CORBA and explicitly recognized the difference. Not only ‘‘require-

ments revision’’ (top left side of Fig. 7), but also new ‘‘specifications emerging in

use’’ (just below in Fig. 7) are enabled by Web services, as explicitly stated three

times.

‘‘Requirements revision’’, with groundedness 6, is one of the concepts most

frequently and explicitly mentioned during interviews:

1. ‘‘About 30% of the requirements initially stated during analysis were later

revised’’ (CE Bank CIO).

Fig. 8 The enabling role of Web services in the ISD process: how it affected system implementation,testing and operation in the CMS project

14 i.e. By everyone in the team except the system architect and one junior developer who had lower

visibility on system analysis during the project.


123

2. ‘‘Back-end application development is changed in that you have to ‘‘think of’’

the service instead of ‘‘thinking of’’ the procedure (for example in services to be

exposed you have to include many more fields than you are actually needing at

the moment, for future eventual uses). It is easier to write services than

procedures. Back-end applications are the same. Instead for front-end

applications everything changes. Furthermore, it is possible to introduce much

more modifications to initial requirements during project development.

Examples of changes intervened along the way: at the beginning customer

interactions were very well-defined, but it was not the same for functional

modules with no direct relation with customer, like margin reports’’ (Renzo, CE

Bank functional analyst).

3. ‘‘It is possible to build a reduced initial version of the user interface, adding

continuously new functionalities along the way. This facilitates going back to

requirements definition. Web services forgives more easily your errors or holes

in analysis, thanks to XML extensibility. For example, the definition of a

currency value requires a series of complex rules that were actually defined

incrementally in various cycles of analysis revision. Software versioning is well

managed. But, like in every project, the more is defined initially, the better’’

(Rita, SmartCo software developer).

4. ‘‘If the problem (to correct during debugging) was in the code, there are no

differences; if instead the problem was in the analysis, in requirements

definition, then with Web services it is much easier. Web services software is

easier to ‘‘measure’’ from error handling point of view, and it allows you to

identify and remove conceptual errors more easily’’ (Rita, SmartCo software

developer).

5. ‘‘Nowadays there are requirements that are fundamental for the first release,

while others after’’ (Bepi, CE Bank functional analyst).

Two interviewees declared that, by using Web services, system analysis, though

still detailed and accurate, is somewhat less deep than before and is frequently

updated during development iterations (‘‘incremental analysis’’):

1. ‘‘The phases are the same, but depth and openness have changed’’ (Bepi, CE

Bank functional analyst).

2. ‘‘In analysis there were only a few details about the interactions bank-customer.

There was just a draft of functional analysis that was enriched along the way,

and this helped us to take opportunities that we were not able to take at the

beginning’’ (Renzo, CE Bank functional analyst).

To summarize, the grounded theory outcome depicted in Fig. 7 illustrates how

the CMS development project, based on Web services, was characterized by a

traditional initial phase of system analysis, with the definition of system

requirements. Nevertheless, thanks to the enabling effect of Web services, it was

possible to revise about 30% of the initial requirements during implementation. A

continuous revisions of the initial systems requirements was in act during system

implementation (requirements revision). Moreover, some new requirements were


123

added in consideration of unpredicted end-user needs emerged during implemen-

tation (incremental analysis).

3.6 How ‘‘WS technology’’ affected ‘‘system implementation,

testing and operation’’

Figure 8 shows the ISD macrophase of ‘‘Implementation, testing and operation’’

and the enabling role of the WS technology in it.

Once again, the WS feature ‘‘Incremental implementation of the contract’’ (see top

left) plays an important enabling role, opening the way to incremental development. In

the context represented by Fig. 8, incremental implementation, which was mentioned

by all the software developers and by one functional analyst, constituted the most

prominent concept (groundedness: 6, density: 5). Here are the some quotes:

1. 1.’’No one among the Web services of the CMS is the now same as it was at

first release’’ (Elena, SmartCo Developer).

2. ‘‘Whenever I am requested for new functionalities, I just add them, and I can

make modifications with no hassle’’ (Elena, SmartCo Developer).

3. ‘‘(using Web services) we are working like before (i.e. using traditional

component-based technologies), but with more easiness of adaptation to

changing user needs’’ (SmartCo project leader).

4. ‘‘The phases of software development are not changed. One point in favour of

Web services is that it is much easier to extend, enrich the user interface. It is

possible to ‘‘expose’’ new methods just when one becomes aware of it, even if it

was not planned at the beginning. This depends on the fact that ‘‘under’’ Web

services there is XML which is extensible, and Web services tend to maintain

this extensibility. We continued to add stuff to initial versions of Web services

along the way’’ (Rita, SmartCo software developer).

5. ‘‘The phases are the same, but depth and openness have changed…Today one

starts from a basic, detailed design, to enrich it along time’’ (Bepi, CE Bank

functional analyst).

In incremental development, software coding is based on small incremental

additions, and it is achieved by working in collaboration with architects and system

engineers, paying attention to user needs, cultivating and stimulating user initiatives

all within a culture of innovation and open mindedness. Host development is

significantly different from (and more complex than) client-side development. The

latter is characterized by easier development of the single software components,

which are quite independent from each other and can be developed and tested

separately. On the down side, the overall management of distributed components,

including their orchestration and tracing, poses new problems, including the need to

handle a higher-level of infrastructural complexity. According to one functional

analyst, incremental development was not as viable in the past as it is today. Most of

these aspects are associated with the property of ‘‘platform independence’’,

represented in the top right of the figure.

To sum up, the grounded theory analysis of the CMS development project at the

CE Bank shows that Web services technology is a key technological enabler for


123

more agile forms of IS development, even under the CE Bank’s stringent quality

standards. Our study suggests that Web services-based system development may

offer significant opportunities in terms of incremental analysis, requirements

revision, requirements emerging in use and incremental implementation.

4 Discussion: system development practices enabled by Web services

We are finally able to provide an affirmative answer to our initial question: in the

case under investigation, the adoption of Web services actually made a difference in

system development practices. In this section, the outcome of the grounded theory

analysis reported above is discussed in comparison with related studies.

4.1 Between amethodical and methodical processes

By contrasting these findings with related studies, it is possible to notice the

presence in the CE Bank case of the four essential ‘‘agile’’ practices observed by

(Baskerville and Pries-Heje 2004) in ‘‘short-cycle development’’: Prototyping,

Release orientation, Criticality of architecture and Parallel development. In

addition, however, there appear five additional ‘‘disciplined’’ practices, usually

adopted in traditional ISD contexts: Auditing, Milestones, Compliance with the

bank’s ISD standards, Documentation, Traditional goal-driven in-depth analysis.

Figure 9 shows that the CE Bank software development process observed here

does not fit precisely into either of the two categories, i.e. amethodical and

methodical processes (Truex et al. 2000).

Short-cycleSoftware Process

(Baskerville et al. 2004)

• Prototyping

• Release orientation

• Parallel development

• Criticality of architecture

Case studySoftware Process

Amethodicalsystems

development

Methodicalsystems

development

• Prototyping

• Release orientation

• Parallel development

• Criticality of architecture

• Auditing• Milestones

• Compliance with the bank’s ISD

standards

• Documentation

• Traditional, goal-driven, in-depth

initial analysis

Fig. 9 Comparison between the two studies


123

Therefore, the Web services system development practices observed here seem to

cover a middle ground between traditional ISD practices (methodical, disciplined)

and short-cycle development practices (amethodical, agile) (Baskerville and Pries-

Heje 2004).

This new class of ISD practices may conjugate features of methodical and

amethodical development. Its adoption has technical enablers (the Web services

technology properties observed in Sects. 3.1 and 3.2) and contextual enablers (the

organizational and environmental factors observed in Sects 3.3, 3.4, 3.5 and 3.6).

Such contextual factors include the specificities of the organization and its

environment, its culture, the project team and the nature of the software application.

A few studies on agile development can provide a useful reference framework to

better understand how the enabling effects observed here could actually work.

4.2 The role of the contextual factors: cultural change towards agility

Did the organization and its environment, its culture, the project team and the nature

of the software application really matter for the adoption of the new practices

observed here? How?

A recent contribution from (Boehm and Turner 2004), convincingly15 shows how

five fundamental contextual factors may be essential for finding a right balance

between the two extremes of agility (amethodical processes) and discipline

(methodical processes). The five critical factors are the project’s size, criticality,

personnel, dynamism and culture, shown here below in Fig. 10.

According to the authors,

‘‘Of the five axes in the polar graph, Size and Criticality are similar to the factors

used by Alistair Cockburn (Cockburn 2002) to distinguish between the lighter-

weight Crystal methods (towards the centre of the graph) and heavierweight Crystal

methods (towards the periphery). The Culture axis reflects the reality that agile

methods will succeed better in a culture that ‘‘thrives on chaos’’(Peters 1991) than

one that ‘‘thrives on order’’, and vice-versa.

The other two axes are asymmetrical in that both agile and plan-driven methods

are likely to succeed at one end, and only one of them is likely to succeed at the

other. For Dynamism, agile methods are at home with both high and low rates of

change, but plan-driven methods prefer low rates of change.

The Personnel scale refers to the extended Cockburn method skill rating scale […].

Here the asymmetry is that while plan-driven methods can work well with both high

and low skill levels, agile methods require a richer mix of higher-level skills […].16

15 The book is very pragmatic and targeted to ‘‘perplexed software and management professionals’’ (p.

XX, preface) more than to academic researchers; though, it is founded on deep and extensive empirical

evidence, and also very well connected with existing literature on the topic.16 ‘‘For example, a plan-driven project with 15% Level 2 and 3 people and 40% Level 1B people would

initially use [15% Level 2 and 3 people to plan the project, but reduce the number thereafter. An agile

project would have everybody working full-time, and the 15% Level 2s and 3s would be swamped trying

to mentor the 40% Level 1Bs and the remaining Level 1As while trying to get their own work done as

well’’ (Boehm B and Turner R Balancing Agility and Discipline: A Guide for the Perplexed. Addison-

Wesley, Boston, 2004, p 57).


123

By rating a project along each of the five axes, you can visibly evaluate its home

ground relationships. If all the ratings are near the centre, you are in agile method

territory. If they are at the periphery, you will best succeed with a plan-driven

approach’’ (Boehm and Turner 2004, pp 54–56).

By using the five Boehm and Turner’s reference factors depicted in Fig. 10, it is

possible to appreciate (besides the fundamental enabling role of the Web services

technologies, not evidenced in Boehm’s framework), the influence of the contextual

factors shown above by our grounded theory analysis of the CMS project at CE

Bank.

In a typical, traditional CE Bank ISD project, all of the factors are convergent

towards the adoption of traditional, well disciplined methods: the national and

organizational culture, with strong values and positive attitudes towards prudence,

order and discipline; the relatively low dynamism; the high skill of CE Bank IS

personnel; the significant size of the average IS development projects; finally, the

high criticality of the typical bank systems.

The opportunity represented by the emergence and adoption of a new technology

(Web services) potentially enabling more agile forms of development, could not

have been caught by the bank, without significant efforts in these five contextual

dimensions. In other words, the bank, to respond to a higher environmental

dynamism embracing more agile forms of development, needed to consider options

like a different cultural approach, a smaller average project size, a way to reduce or

hedge system criticality. In such cases,

Fig. 10 Dimensions affecting the positioning between agile and plan-drive methods, elaboration fromBoehm and Turner 2004, Fig. 6-1


123

‘‘One option would be to start on a long-term internal effort to upgrade your staff

and change your culture. But a quicker and less risky approach would be to enter astrategic partnership with an agile methods company to serve as near-term trainers,

codevelopers, and mentors for your staff’’ (Boehm and Turner 2004, pp 159–160,

italic added).

The strategy followed by the CE Bank to adopt more agile forms of IS

development (as enabled by the Web services technology) was just along these

lines. To use the live words of the bank’s CIO (see Sect. 3.2), the CMS project

partnership with SmartCo was a way for the bank to ‘‘inseminate development’’,

creating a small, mixed team in which not only new technologies, but also new

programming and management styles were contaminating traditional system

development practices within the bank IS department. In this light, also the

decision of limiting the CMS project to a ‘‘side’’ activity of the bank (i.e. cashier

management) has now evident implications for agility: it had the positive effects of

both reducing project’s criticality and project’s size, moving towards the centre in

the two left axes of Fig. 10, just towards the adoption of more agile ISD practices.

To summarize: for the migration from traditional to more agile, hybrid forms of

IS development, besides the technical characteristics of Web services, also the

contextual factors—particularly dynamism, culture, personnel, project size and

project criticality—have shown to play a relevant role. The CMS project partnership

between the CE Bank and the SmartCo software company, besides the decision to

reduce the size and impact of the ‘‘pilot’’ project, was particularly effective to

unlash the potential enabling effects of the Web services technology towards more

agile forms of development, by leveraging a new ‘‘mixed’’ culture, a recombination

and evolution of personnel skill and competences, a smaller project size, a reduced

criticality, a higher dynamism.

5 Conclusions: implications for research and for practice

This study represents one of the first extensive empirical analyses of a system

development project based on Web services in the banking sector. The grounded

theory analysis offers at least two distinct outcomes, particularly novel and relevant

for IS research.

The first outcome is the empirical evidence of a significant enabling role of the

‘‘Web services’’ technology for IS development practices. Our study suggests that

Web services-based system development may offer significant opportunities in

terms of incremental analysis, requirements revision, requirements emerging in use

and incremental implementation. The system development practices observed here

are somehow characterized by some degree of ‘‘disciplined agility’’, laying in the

middle ground between traditional ISD practices (methodical, disciplined) and

short-cycle development practices (amethodical, agile).

The second outcome is that, in full concordance with some of the latest studies on

the subject, the descriptive theoretical framework generated by our empirical

analysis confirms that contextual factors—particularly dynamism, culture, person-

nel, project size and project criticality—play a central role for the migration towards


123

‘‘disciplined’’ agility. The CMS project partnership between the CE Bank and the

SmartCo software company, besides the decision to reduce the size and impact of

the ‘‘pilot’’ project, was particularly effective to unlash the potential enabling effects

of the Web services technology.

The implications for research are quite straightforward: we are showing that

technology matters, playing a fundamental enabling role towards the adoption of

more agile IS development practices. Our study adds to the existing studies on

agility and opens an entirely new path research: there is a need of further studies and

investigations to better understand the enabling role of Web services technology, in

different projects, contexts and in comparison with alternative technologies.

On the other side, there may be further ‘‘soft’’ factors that could matter.

Particularly interesting and worth of further research is in this regards the role of

uncertainty (Little 2005; Thompson 1967), power (Crozier and Friedberg 1977) and

trust (Perrone 1998) in the numerous processes of negotiation that took place at

various levels during system design and development.

In this work, the adoption of more agile forms of development are shown to be

dependent both from technology and from organization and context. Our message

‘‘technology matters’’, if confirmed in the future may have significant implications

for practice, orienting in conformity IT investments and IS strategies when the

adoption of more agile IS development practices is concerned.

New paths of investigation, related to this research and particularly relevant for

practice are rapidly emerging, including service-oriented architectural design and

management issues, and the dilemma of granularity, i.e. how to choose the

appropriate level of componentization (Levi and Arsanjani 2002).

Acknowledgements We are grateful to Richard Baskerville and Duane Truex for their interest,

encouragement and stimulation, and particularly to Jan Pries-Heje for his substantial help and direction.

Richard and Jan initially introduced us to grounded theory analysis tools and techniques, and let us use

their questionnaires for interviews as a model; later on, Jan read and commented early drafts of the paper,

managing to find some time for discussion on different occasions. We would like to warmly thank Marco

Cavallari, from TeamLab inc. Most of the ideas and concepts presented here were actually originated and

shaped during passionate discussions with him. Francesco would like to acknowledge support from

DIAM (Dipartimento Impresa, Ambiente e Management, Universita degli Studi di Cassino), expressing

his gratitude to Prof. Andrea Pontiggia, in general and also in particular, for suggesting the use of the

Cmap Tools software. Thanks also to Giacomo Di Gennaro for his friendly contribution on early drafts

revision and Elena Beccalli for her lovely and competent support.

References

Alonso G, Kuno H, Casati F, Machiraju V (2003) Web services: concepts, architectures and applications.

Springer, Berlin

Arsanjani A, Hailpern B, Martin J, Peri T (2003) Web services: promises and compromises. ACM Queue

1:48–58

Baskerville R, Pries-Heje J (2001) Racing the e-bomb: how the Internet is redefining information system

development methodology. In: Russo L, Fitzgerald B, DeGross J (eds) Realigning research and

practice in IS development: the social and organisational perspective. Kluwer, New York, pp 49–68

Baskerville R, Pries-Heje J (2002) Information system development @ Internet speed: a new paradigm in

the making! In: Tenth European conference on information systems. Gdansk, Poland, pp 282–291

Baskerville R, Pries-Heje J (2004) Short cycle time system development. Inf Syst J 14(3):237–264


123

Baskerville R, Levine L, Balasubramanian R, Pries-Heje J, Slaughter S (2003) Is Internet-speed software

development different? IEEE Softw 20(6):70–77

Bello M, Sorrentino M, Virili F (2002) Web services and emergent organizations. Opportunities and

challenges for IS development. In: Tenth European conference on information systems. Gdansk,

Poland, pp 439–449

Boehm B, Turner R (2004) Balancing agility and discipline: a guide for the perplexed. Addison-Wesley,

Boston

Booth D, Haas H, McCabe F, Newcomer E, Champion M, Ferris C, Orchard D (eds) (2004) Web services

architecture—W3C working group note. http://www.w3.org/TR/ws-arch/. Cited 11 Feb 2004

Cockburn A (2002) Agile software development. Addison-Wesley, Boston

Crnkovic I, Hnich B, Jonsson T, Kiziltan Z (2002) Specification, implementation, and deployment of

components. Commun ACM 45(10):35–40

Crozier M, Friedberg H (1977) L’acteur et le systeme. Editions de Seuil, Paris

de Geus A, Senge P (1997) The living company. Harvard Business School Press, Boston

De Marco M, Sorrentino M (2007) Sowing the seeds of IS cultivation in public service organisations. J Inf

Technol 22(2):184–191

Eisenhardt KM (1989) Building theories from case study research. Acad Manage Rev 14(4):532–550

Eisenhardt KM (1991) Better stories and better constructs: the case for rigor and comparative logic. Acad

Manage Rev 16(3):620–627

Erl T, Haas H, Karmarkar A, Liu K, Orchard D, Tost A, Walmsley P, Yalcinalp LU (2008) Web service

contract design and versioning for SOA. Prentice Hall PTR, Indianapolis

Gibb Dyer W, Wilkins A Jr (1991) Better stories not better constructs to generate better theory: a

rejoinder to Eisenhardt. Acad Manage Rev 16(3):613–619

Glass R (2003) A mugwump’s-eye view of web work: choosing a point of entry into a contemporary

software development debate. Commun ACM 46(8):21–23

Iyer B, Freedman J, Gaynor M, Wyner G (2003) Web services: enabling dynamic business networks.

Commun Assoc Inf Syst 11:525–554

Kautz K, Nørbjerg J (2003) Persistent problems in information system development: the case of the

World Wide Web. In: Eleventh European conference on information systems, Naples, Italy

Lee A, Baskerville R (2003) Generalizing generalizability in information systems research. Inf Syst Res

14(3):221–243

Levi K, Arsanjani A (2002) A goal-driven approach to enterprise component identification and

specification. Commun ACM 45(10):45–52

Little T (2005) Context-adaptive agility: managing complexity and uncertainty. IEEE Softw 22(3):28–35

Lyytinen K, Rose G, Welke R (1998) The brave new world of development in the internetworking

computing architecture (interNCA): or how distributed computing platforms will change system

development. Inf Syst J 8:241–253

Markus ML, Robey D (1988) Information technology and organizational change: causal structure in

theory and research. Manage Sci 34(5):583–599

Meyer B (1992) Applying design by contract. Computer 25(10):40–51

Muhr T, Friese S (2004) User’s manual for ATLAS.ti 5.0, 2nd edn. Scientific Software Development,

Berlin

Orlikowski W (1993) CASE tools as organizational change: investigating incremental and radical

changes in system development. MIS Q 17(3):309–340

Papazoglou MP, Georgakopoulos D (2003) Service oriented computing: introduction. Commun ACM

46(10):25–28

Perrone V (1998) Does trust matter? Exploring the effects of interorganizational and interpersonal trust on

performance. Organ Sci 9(2):141–159

Peters T (1991) Thriving on chaos. HarperCollins, New York

Rogers S (2005) World Wide Web services software 2005–2009 forecast: let the races begin. Doc

#33418. IDC, Framingham, pp 1–26

Rossignoli C (2007) The contribution of transaction cost theory and other network-oriented techniques to

digital markets. Inf Syst e-Bus Manage. doi:10.1007/s10257-007-0063-z

Rossignoli C, Mola L (2004) E.M.P. as enabler of new organisational architectures: an Italian case study.

In: Proceedings of the 17th Bled eCommerce conference, Bled, Slovenia, 21–23 June 2004

Sommerville I (2000) Software engineering, 6th edn. Addison-Wesley, New York

Sorrentino M, Virili F (2005) Web services system development: a grounded theory study. In:

Proceedings of the 18th Bled eCommerce conference, Bled, Slovenia, 6–8 June 2005


123

http://www.w3.org/TR/ws-arch/

http://dx.doi.org/10.1007/s10257-007-0063-z

Strauss AL, Corbin J (1998) Basics of qualitative research: techniques and procedures for developing

grounded theory, 2nd edn. Sage Publications, Thousand Oaks

Thompson JD (1967) Organizations in action. McGraw-Hill, New York

Truex DP, Baskerville R, Klein H (1999) Growing systems in emergent organizations. Commun ACM

42(8):117–123

Truex D, Baskerville R, Travis J (2000) Amethodical system development: the deferred meaning of

system development methods. Account Manage Inf Technol 10:53–79

Virili F, Sorrentino M (2004) Making stable systems grow with Web services: a case study. In:

Proceedings of the IFIP WG 8.2 Organizations and Society in Information Systems (OASIS)

Workshop, Seattle

Yin R (1994) Case study research. Design and methods. Sage Publications, Thousand Oaks


123

the enabling role of web services in information system development practices

Documents