ORI GI NAL ARTI CLE

The enabling role of Web services in information

system 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 fullment of emerging or
previously unplanned user needs discovered along the way. Such system develop-
ment practices, enabled by the Web services technology and inuenced 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 rst 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: francesco.virili@eco.unicas.it
M. Sorrentino (&)
Dipartimento di Scienze Economiche, Aziendali e Statistiche,
Universita` degli Studi di Milano, Via Conservatorio 7, 20122 Milan, Italy
e-mail: maddalena.sorrentino@unimi.it
1 3
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) practices
2
or not.
To shed new light on this issue, we provide here one of the rst 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 nding is the identication 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, Spezikation und
Standardisierung von Fachkomponenten Wirtschaftstinformatik 43(3), 2001, pp 269281. 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-Business
Management 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 denition 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), NovDec
2003, pp 7077.
F. Virili, M. Sorrentino
1 3
target organization and its environment, the project team and application software
peculiarities.
In denitive, the Web services system development practices analysed here
materialize in the potential ability to build complex systems in a shorter, cheaper
and more exible 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 eld appears to be in a state of transition.
The rst 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 Nrbjerg 2003).
The debate on web system development is still wide open, and not nearly enough
evidence have yet been collected to formulate a denitive 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 reect 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 denition of classical ISD
principles; (3) the ambiguity and generality of expressions like web system development.
Information system development practices
1 3
organization with a xed information system.
4
The classical IS lifespan
(analysis, design, operation and maintenance, obsolescence, substitution) is
based on the assumption that a well-specied 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
dene a perfect set of system specications, 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 Web
services standards and tools is disclosing newways 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 rst
empirical works in the eld (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 sufcient 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 briey outlined in Arsanjani et al. 2003 and analysed in
more depth in Alonso et al. 2003.
4
Continuous redevelopment shows afnities, 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 184191.
F. Virili, M. Sorrentino
1 3
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 specic.
1. Web services is new: the rst ofcial standard reference architecture for Web
services was only recently published by the World Wide Web Consortium
(Booth et al. 2004). Signicant 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 signicant global
investments at a growing pace, in many industries (Rogers 2005).
3. Web services is specic: 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 clientserver system. In focusing on Web services we
refer to a family of technologies with very well-dened 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 specic 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 specic
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 rst 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 ndings. 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
Information system development practices
1 3
a thick description of the Web services ISD process, with no specic 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 eld. The direct link between theory and data
makes it possible to easily verify the existence and density of empirical
justications 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 532550, raising the issue if better grounding theories on a single case (more in-depth and
focused on qualitative and contextual aspectsbetter 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 Management
Review 16(3) 1991, pp 613619); (Eisenhardt KM Better Stories and Better Constructs: The Case for
Rigor and Comparative Logic. The Academy of Management Review 16(3) 1991, pp 620627).
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 ndings. 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 nal discussion, according to the indications given by Strauss and Corbin themselves: When an
investigator has nished his or her data collection and analysis and is in the writing stage, the literature
can be used to conrm ndings and, just the reverse, ndings 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 5253).
F. Virili, M. Sorrentino
1 3
reects 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 rst embarked upon (Bello et al. 2002), gaining access to a
fully edged Web services development project proved quite difcult. 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-ofce 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 banks 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 banks 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 Banks 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 nancial and retail banking systems. The
project team included both the banks and the providers 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 ve 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 eld observations were supplemented with internal documents
mainly technical literaturemade available by the bank and by external sources. In
the rst round, carried out between September 2003 and February 2004, a total
Information system development practices
1 3
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 nal 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
identication and labelling of particular concepts in text passages) and axial coding
(the denition 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 conceptstogether
with their specic properties and dimensionsand 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 rst 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 rst 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.
F. Virili, M. Sorrentino
1 3
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 signicant 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
banks Chief Information Ofcer (CIO) and with the banks information strategies
executive, integrated with some internal documents and nally 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 nancial
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 rst 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
rst is in the interview with the banks 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 signicant and investigated in more detail.
Information system development practices
1 3
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 reections 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 inuence of private banking as core business on a few important Cashier Management
System requirements
F. Virili, M. Sorrentino
1 3
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 nancial group.
The banks 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):
rst, the banks 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 banks core business, involving global trading of a rich variety of
nancial products, the CMS has to be connected to the principal world nancial
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. coordination
mechanisms, 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).
Information system development practices
1 3
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 project
team, composed by the bank EAI experts supported by the SmartCo project leader
and by a senior developer, was specialized in conguring 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 reected 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
exibility and strong leadership: There is the team leader deciding who does what
(though in a very exible 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
F. Virili, M. Sorrentino
1 3
reminds who did what. The team leader has the responsibility of the whole and is
also a supervisor (Elena, SmartCo developer
10
).
The CIO talks about a high exibility in project conduction: In comparison
with our previous internal ISD projects, this was more a pilot project, conducted
with higher exibility; there was a relationship of strong collaboration with
SmartCo (From the banks CIO interview).
The expression pilot project, is from the actual words of the banks 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 specically, interviewees said that the CMS was
the rst 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 qualitative
research: 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, reecting the Italian
expression inseminazione actually used by the interviewees.
Information system development practices
1 3
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 conned 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 full customer requests, to be acquired
with experience and time. The CMS pilot project, based on a much more
sophisticated, but still exible 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 inuence 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 conguration 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 difcult, in particular
data serialization and component conguration. 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
F. Virili, M. Sorrentino
1 3
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
platformsoperating systems and programming languages (Elena, junior
programmer).
2. There is no more the need to congure 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 congure an
application by using a port. You are much more exible. 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
Information system development practices
1 3
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 rst 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 gure 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 dividedin 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, simplied 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
F. Virili, M. Sorrentino
1 3
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 after
publishing 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 design
in 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 specication of a components
behaviour (Crnkovic I, Hnich B, Jonsson T and Kiziltan Z Specication, Implementation, and
Deployment of Components, Communications of the ACM 45(10) 2002, p. 37).
Information system development practices
1 3
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
ve 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 specications 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.
F. Virili, M. Sorrentino
1 3
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 elds 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 modications to initial requirements during project development.
Examples of changes intervened along the way: at the beginning customer
interactions were very well-dened, 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 denition. Web services forgives more easily your errors or holes
in analysis, thanks to XML extensibility. For example, the denition of a
currency value requires a series of complex rules that were actually dened
incrementally in various cycles of analysis revision. Software versioning is well
managed. But, like in every project, the more is dened 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
denition, 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 rst 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 denition 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
Information system development practices
1 3
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
rst release (Elena, SmartCo Developer).
2. Whenever I am requested for new functionalities, I just add them, and I can
make modications 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 changedToday 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
signicantly 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 gure.
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
F. Virili, M. Sorrentino
1 3
more agile forms of IS development, even under the CE Banks stringent quality
standards. Our study suggests that Web services-based system development may
offer signicant 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 nally able to provide an afrmative 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 ndings 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 ve additional disciplined practices, usually
adopted in traditional ISD contexts: Auditing, Milestones, Compliance with the
banks ISD standards, Documentation, Traditional goal-driven in-depth analysis.
Figure 9 shows that the CE Bank software development process observed here
does not t precisely into either of the two categories, i.e. amethodical and
methodical processes (Truex et al. 2000).
Short-cycle
Software Process
(Baskerville et al. 2004)
Prototyping
Release orientation
Parallel development
Criticality of architecture
Case study
Software Process
Amethodical
systems
development
Methodical
systems
development
Prototyping
Release orientation
Parallel development
Criticality of architecture
Auditing
Milestones
Compliance with the banks ISD
standards
Documentation
Traditional, goal-driven, in-depth
initial analysis
Fig. 9 Comparison between the two studies
Information system development practices
1 3
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 specicities 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), convincingly
15
shows how
ve fundamental contextual factors may be essential for nding a right balance
between the two extremes of agility (amethodical processes) and discipline
(methodical processes). The ve critical factors are the projects size, criticality,
personnel, dynamism and culture, shown here below in Fig. 10.
According to the authors,
Of the ve 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 reects 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).
F. Virili, M. Sorrentino
1 3
By rating a project along each of the ve 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 5456).
By using the ve Boehm and Turners reference factors depicted in Fig. 10, it is
possible to appreciate (besides the fundamental enabling role of the Web services
technologies, not evidenced in Boehms framework), the inuence 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 signicant size of the average IS development projects; nally, 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 signicant efforts in these ve 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 from
Boehm and Turner 2004, Fig. 6-1
Information system development practices
1 3
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 a
strategic partnership with an agile methods company to serve as near-term trainers,
codevelopers, and mentors for your staff (Boehm and Turner 2004, pp 159160,
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 banks 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 projects criticality and projects 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 factorsparticularly dynamism, culture, personnel, project size and
project criticalityhave 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 rst 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 rst outcome is the empirical evidence of a signicant enabling role of the
Web services technology for IS development practices. Our study suggests that
Web services-based system development may offer signicant 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 conrms that contextual factorsparticularly dynamism, culture, person-
nel, project size and project criticalityplay a central role for the migration towards
F. Virili, M. Sorrentino
1 3
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 conrmed in the future may have signicant 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 nd 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:4858
Baskerville R, Pries-Heje J (2001) Racing the e-bomb: how the Internet is redening 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 4968
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 282291
Baskerville R, Pries-Heje J (2004) Short cycle time system development. Inf Syst J 14(3):237264
Information system development practices
1 3
Baskerville R, Levine L, Balasubramanian R, Pries-Heje J, Slaughter S (2003) Is Internet-speed software
development different? IEEE Softw 20(6):7077
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 439449
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
architectureW3C 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) Specication, implementation, and deployment of
components. Commun ACM 45(10):3540
Crozier M, Friedberg H (1977) Lacteur et le syste`me. 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):184191
Eisenhardt KM (1989) Building theories from case study research. Acad Manage Rev 14(4):532550
Eisenhardt KM (1991) Better stories and better constructs: the case for rigor and comparative logic. Acad
Manage Rev 16(3):620627
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):613619
Glass R (2003) A mugwumps-eye view of web work: choosing a point of entry into a contemporary
software development debate. Commun ACM 46(8):2123
Iyer B, Freedman J, Gaynor M, Wyner G (2003) Web services: enabling dynamic business networks.
Commun Assoc Inf Syst 11:525554
Kautz K, Nrbjerg 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):221243
Levi K, Arsanjani A (2002) A goal-driven approach to enterprise component identication and
specication. Commun ACM 45(10):4552
Little T (2005) Context-adaptive agility: managing complexity and uncertainty. IEEE Softw 22(3):2835
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:241253
Markus ML, Robey D (1988) Information technology and organizational change: causal structure in
theory and research. Manage Sci 34(5):583599
Meyer B (1992) Applying design by contract. Computer 25(10):4051
Muhr T, Friese S (2004) Users manual for ATLAS.ti 5.0, 2nd edn. Scientic Software Development,
Berlin
Orlikowski W (1993) CASE tools as organizational change: investigating incremental and radical
changes in system development. MIS Q 17(3):309340
Papazoglou MP, Georgakopoulos D (2003) Service oriented computing: introduction. Commun ACM
46(10):2528
Perrone V (1998) Does trust matter? Exploring the effects of interorganizational and interpersonal trust on
performance. Organ Sci 9(2):141159
Peters T (1991) Thriving on chaos. HarperCollins, New York
Rogers S (2005) World Wide Web services software 20052009 forecast: let the races begin. Doc
#33418. IDC, Framingham, pp 126
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, 2123 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, 68 June 2005
F. Virili, M. Sorrentino
1 3
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):117123
Truex D, Baskerville R, Travis J (2000) Amethodical system development: the deferred meaning of
system development methods. Account Manage Inf Technol 10:5379
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
Information system development practices
1 3