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