Jörg Becker
email: joerg.becker@ercis.uni-muenster.de

Christoph Ahrendt

André Coners
email: coners@fh-swf.de

Burkhard Weiß
email: burkhard.weiss@ercis.uni-muenster.de

Axel Winkelmann
email: axel.winkelmann@ercis.uni-muenster.de

Christoph Arendt

/ Burkhard

Modeling and Analysis of Business Process Compliance

Keywords: Compliance, Business Process Modeling, Business Process Management, Governance, Finance

Managing business process compliance is a highly important topic in the financial sector. Various scandals and last but not least the financial crisis have caused many new constraints and legal regulations that banks and financial institutions need to face. Based on a domain-specific semantic business process modeling notation, we propose a new approach to modeling and analysis of business process compliance through the use of compliance building block patterns and business rules. These business process compliance

INTRODUCTION

Although no general understanding of "compliance" exists, it can be understood as conforming to a rule such as a specification, a policy or a standardized procedure. In this context, "Business Process Compliance" (BPC) management is a new research field that addresses the coordination of business process management (BPM) and compliance [START_REF] Rinderle-Ma | Business Process Compliance[END_REF]. Regulations and laws force service companies to ensure compliant business processes (Basel Committee on Banking Supervision 2004). We therefore address business compliance rules for banks in this article because the automatic identification and analysis of financial sector processes, with regard to their alignment, with new compliance requirements, is still an unsolved problem.

Huge efforts are being spent on the actual modeling of business processes, but justified benefits in the analysis and usage of process models are rare (Becker et al. 2010d). It turns out that automated analysis of process models is hardly possible with standard business process modeling languages. Nevertheless, this is especially desirable, since many regulations have to be considered and new regulations require an ongoing analysis of business processes.

Hence, this paper aims at formalizing compliance-related business rules in a semantic way that is easily understood by compliance experts, while at the same time enabling banks to automatically check for these business rules in semantic business process models. We do this by proposing a business rule-based extension of SBPML, a semantic business process modeling notation that was developed specifically for the financial sector and represents an intuitive modeling approach for non-BPM experts [START_REF] Becker | Developing a Business Process Modeling Language for the Banking Sector -A Design Science Approach[END_REF]Becker et al. 2010b;Becker et al. 2010c;Becker et al. 2010e).

STATE OF THE ART IN MODELING AND ANALYSIS OF BUSINESS PROCESS COMPLIANCE

In Information Systems Research, business rules are considered as self-contained scientific objects [START_REF] Herbst | Ansätze zur Klassifikation von Geschäftsregeln[END_REF]. The core elements of the business rules approach have been determined by the BRG in their business rules manifesto (Business Rules Group 2003), which was later enhanced by OMG (Object Management Group 2006). According to [START_REF] Scheer | Geschäftsprozessmanagement für das Unternehmen von morgen[END_REF] they are " […] guidelines or business practices […], that affect or guide the behavior of companies.

Behavior means […], with which processes (how) and with which resources (whereby), which goods are produced." They can be of internal and external origin (e.g. laws). In this context, business rules shall be regarded as normative instructional statements that are distinguished by their specifying character, related to their process execution [START_REF] Hay | Defining Business Rules -What are They Really?[END_REF]. The fundamental purpose of business rules lies in securing conformity of business processes within legal and other guidelines, as well as verification of conformity.

By means of this specification, business rules can be created and transferred to business rules management systems (BRMS) [START_REF] Hoheseil | Temporale Geschäftsprozessmodellierung[END_REF]. Rule editors support the creation, validation and simulation of business rules by providing an appropriate development environment. These rules can subsequently be stored in a repository, which is available to form the basis for process management. These rules are particularly effective with regard to controlling processes, if they are combined with operational systems, like ERP or workflow management systems, for example, via web services that access the BRMS during execution, using the output of rule analysis, to determine the follow-up actions [START_REF] Grob | Rule-Based Control of Business Processes -A Process Mining Approach[END_REF].

With the help of business rules, process execution logic, stored in operative systems, can be transferred into BRMS and can be stored independently from its type and place of future application [START_REF] Endl | Regelbasierte Entwicklung betrieblicher Informationssysteme: Gestaltung flexibler Informationssysteme durch explizite Modellierung der Geschäftslogik[END_REF]). This allows advantages in flexibility, so that modifications of business rules in the operating departments are possible, for example, in order to adapt to changing conditions, like legal formalities. Furthermore, a centralized storage of control logic avoids the problem of a variety of different implementations of the same business rules in different application systems. Business processes have to provide valid and consistent control logic, in order to enable purposeful execution of processes and to avoid process anomalies on an instance level. The supervision and enforcement of these defined business rules, using BRMS, immediately intends to enforce existing (internal or external) guidelines of process instances.

Different language constructs can be used to design business rules [START_REF] Scheer | Geschäftsprozessmanagement für das Unternehmen von morgen[END_REF]. One possibility is to use simple IF-THEN-rules or their derived extensions of ECA-rules (event-condition-action) or ECAA-rules (event-conditionaction-alternative) [START_REF] Hanson | Rule Condition Testing and Action Execution in Ariel[END_REF]). Another possibility is the Business Process Compliance Language (BPCL) [START_REF] Wörzberger | Checking Correctness and Compliance of Integrated Process Models[END_REF], which defines inclusion, precedence and existence conditions for business rules. However, all of these constructs can only partially be applied to very different types of business rules (not just regarding process control flows, but also business objects used in a process, as well as resources), not all of them are easily understood by business process compliance officers (e.g. BPCL) and all of these only support semantic interpretation on a very abstract level, since a predefined ontology for a domain-specific vocabulary is missing.

According to El Kharbili et al. (2008a) andEl Kharbili et al. (2008b), successful BPC implementation:

• requires an integrated approach, reflecting the entire BPM lifecycle, • should support compliance verification beyond simple control flow aspects,

• needs an intuitive graphical notation for compliance requirements that is also com-prehend¬ible for non-experts and Winkelmann

• should support the application of semantic technologies for the definition, implementation and execution of automated compliance verification.

Hence, for the purpose of BPC management, we propose to develop a semantic approach to BRM that allows for intuitive modeling and analysis of business process compliance. Since especially the last two aspects target at an easy to use semantic modeling and analysis language and our focus is on the financial sector, we will build upon the Semantic Business Process Modeling Language (SBPML) notation [START_REF] Becker | Developing a Business Process Modeling Language for the Banking Sector -A Design Science Approach[END_REF]Becker et al. 2010d;Becker et al. 2010e), which we will describe briefly next.

SBPML AS AN APPROACH TO SEMANTIC BUSINESS PROCESS MODELING AND ANALYSIS

SBPML was originally developed since researchers identified an inefficiency of generic process modeling languages in terms of modeling and analysis of business processes in the financial sector (Becker et al. 2010d). As a result, it focuses on an economic, domain-specific and thus semantic modeling approach, based on reusable process building blocks that are designed specifically for modeling and analysis of activities and processes in banks [START_REF] Becker | Developing a Business Process Modeling Language for the Banking Sector -A Design Science Approach[END_REF][START_REF] Weiß | A Metamodel Based Perspective on the Adaptation of a Process Modeling Language to the Financial Sector[END_REF]. The process modeling notation consists of four views, comprising a process view ("how is a service delivered?"), a business object view ("what is processed or produced?"), an organizational view ("who is involved in the process?") and a resource view ("what resources are used?") (cf. Figure 1). The core constructs of this language are domain-specific process building blocks (PBB), which have an integrating role by connecting all views (cf. Figure 1). A PBB represents a certain set of activities (e.g. "Enter Data into IT" or "Archive Document / Information") within an administrative process and applies a domain-specific vocabulary. PBBs are atomic, have a well-defined level of abstraction and are semantically specified by a domain concept. PBBs belong to the process view and represent the lowest abstraction level of a process model. Processes are represented as a sequential flow of PBBs. PBBs are contained within different variants of sub processes. The sub processes, representing the activities of just one organizational unit, are in turn part of a larger process, which usually involves multiple organizational units and thus multiple sub processes (cf. Figure 1). Additional facts about the processes can be collected with the help of attributes (e.g. "Duration" for the PBB "Enter Data into IT"), assigned to each PBB. They establish a connection to the business object, organizational and resource view.

DEVELOPING ARTIFACTS FOR MODELING COMPLIANCE-RELATED BUSINESS RULES IN SBPML

Through a literature review we identified business rule types that are used in the context of BPC in banks. According to [START_REF] Sadiq | Modeling Control Objectives for Business Process Compliance[END_REF] they include:

• flow tags, which represent rules regarding the business process control flow and thus the execution of certain activities in a process (e.g. order of activities, existence of certain activities etc.),

• time tags, which represent rules that depict temporal conditions or restraints within process flows (e.g. maximum time that may be needed to respond to a customer request),

• resource tags, which represent rules regarding the used resources, when executing a certain activity (e.g. authorization rules for IT systems or restrictions separations of duties within a process flow) and • data tags, which represent rules regarding the (business object) data, used throughout a process (e.g. data like the name of the credit applicant that must be contained in a credit application).

Concerning the SBPML notation, there are business rules that refer to the process view solely (flow tags and time tags), the business object view, possibly in conjunction with the process view (data tags) and the resource view, as well as the organizational view, possibly in conjunction with the process view (resource tags). Since time tags can only be evaluated during run-time and not on the level of process models, they will not be considered further. Regarding different flow tags, we follow [START_REF] Awad | Visualization of Compliance Violation in Business Process Models[END_REF], who have concentrated on identifying and describing process control flow business rules for BPMN (Business Process Modeling Notation).

According to [START_REF] Awad | Visualization of Compliance Violation in Business Process Models[END_REF], control flow business rules define the sequence, in which activities can or should be performed. Generally, predecessor relations (Activity A "leads to" Activity B) and successor relations (Activity A "precedes" Activity B) are established, but also existence (inclusion) or non-existence constraints should be depicted. In addition, depending upon an activity's position within a process or sequence of activities, different scopes can be defined. The sequence, as well as the existence or non-existence of activities, is defined within a certain "scope" of an entire process. The scope of a constraint can either be "global", or with respect to another activity "before" or "after" that activity, or with respect to two other activities between those two activities.

Fig. 2. Basic Control Flow-Related Business Compliance Rules

In Figure 2 (a) Activity A must be part of a process; in (b) Activity A may not be part of the entire process. (c) describes the classical successor constraint, (e) the predecessor constraint. In (d) Activity A may not be executed before Activity B is finished; in (f) Activity B may not be executed after Activity A is finished. (g) and (h) describe the non-existence constraint of Activity B between Activity A and Activity C, with the difference that Activity A and Activity C in (g) are in a successor relationship, whereas they are in a predecessor relationship in (h) (cf. Becker et al. 2010a).

Fig. 3. Complex Control Flow-Related Business Compliance Rules

Figure 3 depicts further, more complex standard business rule patterns. In (k), in contrast to (d), Activity B must not be part of a process in all cases. However, if Activity B is used in a process, Activity A may not be executed before Activity B is finished. In (i) and (j) we suggest the use of a "'Variable Activity" PBB to define direct sequences. In (j) Activity A must be a direct predecessor of Activity B or vice versa Activity B must be a direct successor of Activity A. In (i), through the use of the global scope, we are able to define that Activity A must be the first activity within an entire process. Similarly, one could also predefine the last activity that must be at the end of a process. In addition, these rules may not only be applied to activities in the SBPML notation, but also to processes, sub processes and sub process variants ((l), (m), (n), (o), (p), (q)). Through the combination of these simple patterns, more complex patterns can also be derived.

From a resource tag based view with its corresponding organizational view and resource view in the SBPML terminology, further rules can be specified. For resources in terms of the SBPML resource view in general, IT compliance of an IT system, as a resource used during a business process, can be modeled and analyzed, although we will not focus on IT compliance within this article. Focusing on the organizational view of the SBPML terminology, there are two further very common compliance requirements, which need to be captured by business rules. These are the application of a four-eyes-principle (cf. Figure 4 (w)), where one person executes Activity A as a "maker" and a second person as the "checker" verifies, if Activity A was done correctly and the aspect of separation of duties for certain activity sequences (cf. Figure 4 (s), (t), (u), (v)). Finally, the data tag view with its corresponding business object view in the SBPML terminology requires further types of compliance business rules to be modeled (cf. Figure 5). According to [START_REF] Namiri | Pattern-based Design and Validation of Business Process Compliance[END_REF], the following data tag rules are important (cf. Figure 6):

a "completeness check" (x) is important to verify, if all mandatory fields or attributes of a data or business object have been completed (e.g. check if all necessary information is provided in a credit application), a "plausibility check" (y) is important to verify, if fields or attributes of a data or business object are plausible (e.g. valid address information), a "n-way-check" (z) is important to verify, if fields or attributes of data or business objects are the same (e.g. if the birth date is the same on the personal identification card as well as on the credit application).

Besides these business rules, related to certain types of business objects, Zoet et al. ( 2009) also define "effect sequencing" ((aa), (ab), (ac), (ad)). Effect sequencing describes that business objects, which have certain characteristics, imply further activities to be executed (e.g. credit requests for more than 75,000 € must receive an additional vote inside a bank).

These specified business rules can all be applied to SBPML process models, since the rules only use predefined patterns of activities that are also the basis of the SBPML specification.

Fig. 6. SBPML Compliance View

Since all these business rules will usually be maintained by a compliance officer, with expertise in the area of compliance management on an enterprise level, as opposed to a process modeler, with expertise in business process management and especially process modeling, we propose to add a compliance view to the SBPML views. This should be linked to all existing views and should give the compliance officer the ability to model, maintain and analyze the compliance business rules with respect to the available elements, used in all other existing views (cf. Figure 6).

CONCLUSION

Undoubtedly, the automatic enforcement of compliance and compliant business processes is a very important topic in the financial sector. This is especially due to the different scandals, financial crisis and the ongoing regulation debate that will lead to new rules and laws on national and international levels. Therefore, an automated analysis of existing process models is a prerequisite for ensuring BPC. In identifying relevant business rule design patterns, we provide a basis for instantiations, based on the SBPML notation for banks, but also for other notations. The instantiation of the generic rules will allow for an automatic identification of design patterns in process models in banks (cf. [START_REF] Becker | Supporting Business Process Compliance in Financial Institutions -A Model-Driven Approach[END_REF]) and hence for the discovery of critical compliance issues. At this stage of research, we believe these results to be valid for most purposes in banks. However, in a next step, we are going to further evaluate our findings with the help of various SBPML process models from different banks. Furthermore, by testing the theoretical concepts in practical depth, we may also add new process compliance business rules to our business process compliance pattern library.

Sciences he was Principal at Horváth & Partners Management Consultants and responsible for the business segment Business Process Management. André Coners has more than 10 years professional experience as a Management Consultant regarding Strategic Management, Business Process Management and Controlling. He has published several books and articles on strategic management, process mining, activity based costing, cost management and process management and can be contacted via e-mail at coners@fh-swf.de.

Burkhard Weiß works as a Research Associate at the Chair for Information Systems and Information Management at the European Research Center for Information Systems (ERCIS) at the University of Muenster in Germany. After his studies in Information Systems, at the University of Muenster in 2007, he has lead many research projects in the financial sector with a focus on semantic business process modeling languages and innovative approaches to automate business process analysis in banks. Since 2008, he heads the Competence Center "BPM in Financial Industries" at the ERCIS and his research has received significant funding for its relevance and novelty to the banking sector from several banks in Germany and Russia. In 2010, he has received a PhD scholarship grant from the DZ BANK Foundation, which specifically promotes his research on business process analysis and business process optimization. He can be contacted via e-mail at burkhard.weiss@ercis.uni-muenster.de.

Axel Winkelmann received his PhD and Post-Doctoral Qualification (Habilitation) at the University of Muenster in Germany. In 2009, he was appointed as an Interim Professor on Business Information Systems at the University of Koblenz-Landau. He is currently an Interim Professor at the Institute of Information Systems at the University of Muenster and a researcher at the European Research Center for Information Systems (ERCIS). His research interests include Business Information Systems, Business Transformations and Business Process Management with an emphasis on the service sector including retail, finance, and telecommunication. He has written numerous books and international conference and journal articles on these topics and is engaged with various research institutions and universities. He can be contacted via e-mail at axel.winkelmann@ercis.uni-muenster.de.

Fig. 1 .

 1 Fig. 1. SBPML Views, Model Types and Levels of Abstraction of the Process View

Fig. 4 .

 4 Fig. 4. Resource-Related Business Compliance Rules

AUTHOR BIOGRAPHIES

Jörg Becker is a Full Professor and Head of the Department of Information Systems at the University of Muenster in Germany. He is the Managing Director of the European Research Center for Information Systems (ERCIS) and Editor in Chief of the international journal Information Systems and e-Business Management, while also serving on various editorial boards. His works have appeared in several journals (e.g. Communications of the AIS, Information Systems Journal, Scandinavian Journal of Information Systems) and were presented at international conferences (e.g. ICIS, ECIS, AMCIS). His research interests include information management, process management, retail IS and strategic IT-management consulting. He can be contacted via e-mail at joerg.becker@ercis.uni-muenster.de.

Christoph Ahrendt currently works as a Junior Consultant at Horváth & Partners Management Consultants within the Competence Center "Process Management & Organization." During his studies in Information Systems, at the University of Muenster, he focused his research on the area of business process management and in particular on the area of business process compliance. After his studies, in 2010, he was accepted to the Horváth Bachelor Program. He can be contacted via e-mail at chris.a@uni-muenster.de.

André Coners is a Professor at the South Westphalia University of Applied Sciences in Germany. Before joining the South Westphalia University of Applied


Björn Johansson
email: bjorn.johansson@ics.lu.se

Diffusion of Open Source ERP systems development: How Users are Involved

Keywords: Requirements Engineering, Enterprise Resource Planning, ERP, Open Source, Standard systems, user involvement. 2 Project Open, Night Labs, Openbravo and Open Source

Open Source receives high attention among organizations today, and there is also a growing interest on Open Source Enterprise Resource Planning (OS ERP) systems. Open source development is often considered having a high level of involvement from stakeholders in adopting organizations. However, it depends on for the first what is meant by stakeholders, but also what is meant by involvement. In the area of ERP development stakeholder involvement is defined as to what extent users of the system are involved in the development of the standardized software package. The way this is done differs between different vendors but it can be summarized as dealing with management of requirements. In this paper we explore how requirements management is done in development of OS ERP. To do this, we use a theoretical base on requirements management in the ERP field from which we investigate stakeholder involvement in four organizations and the development of it's respectively OS ERP system. The basic question asked was: how are end-users of OS ERPs involved in the development of OS ERP. From the investigation we present a general picture of the requirements management process in the OS ERP area. The main conclusion is that end-users are not involved to the extent first expected and when comparing with proprietary ERP development a tendency towards a similar approach to requirements management in OS ERP development was discovered.

INTRODUCTION

Many organizations implement enterprise resource planning (ERP) systems from the view that they will obtain an advantage over its competitor [START_REF] Verville | ERP Acquisition Planning: A Critical Dimension for Making the Right Choice[END_REF], by for instance getting better and faster access to information stored. However, there are organizations that are resistant because ERP implementation takes time and costs a lot of money, while there is also a high risk that it may fail [START_REF] Daneva | Understanding Success and Failure Profiles of ERP Requirements Engineering: an Empirical Study[END_REF]The Standish Group, 1995;[START_REF] Verville | ERP Acquisition Planning: A Critical Dimension for Making the Right Choice[END_REF]. This has created an interest in developing ERPs in the open source (OS) area. The open source ERP development could be seen as an alternative to traditional ERP proprietary systems available today. [START_REF] Rapp | Increased Interest for Open Source[END_REF] suggests that OS have grown large and states that it continues to grow strongly as more and more organizations become interested in how they can benefit from OS in their organization. However, the same thing can also be stated about ERPs. But, the question is then if combing open source and ERPs is that a doable and beneficial combination for organizations. It can be claimed that if it should be, development probably needs to be done with closeness to its users. An interesting question to ask is therefore to what extent and how users are involved in OS ERP development.

According to [START_REF] Fitzgerald | The Transformation of Open Source Software[END_REF] open source development differ from "ordinary" software development since the first phases of planning, analysis and design usually has no clear borders, and is performed by a single developer or a small group of developers. This is explained in a survey by [START_REF] Zhao | Quality assurance under the open source development model[END_REF], showing that a large proportion of projects in OS are developed by self-interest and only a small part are developed in response to different organizational needs. [START_REF] Lemos | Open Source ERP grows up[END_REF] states that OS ERP is a growing market, and that there is a growing commercial interest in it. [START_REF] Fitzgerald | The Transformation of Open Source Software[END_REF] argues that since OS projects will be more commercial, a greater level of structure and control in development is needed. [START_REF] Sommerville | Software Engineering[END_REF] supports this by observing that in development of large systems, such as ERPs, the high complexity is a major problem. [START_REF] Young | Effective Requirements Practices[END_REF] provides the following view of requirements management in software development: "We often record requirements in a disorganized manner, and we spent far too little time verifying what we do record. We allow change to control us, rather than establishing mechanisms to control change. In short, we fail to establish a solid foundation for the system or software that we intend to build ".

From this discussion the question which is discussed in this paper is: How are endusers involved in the development of Open Source ERPs? To answer this, a description of four OS ERP developer organizations and their respectively OS ERP system are presented (section 2). Section 3 then presents an analysis on how requirements management is done in the four organizations. The final section then presents some conclusions on the question how end-users are involved in development of OS ERP and some future research directions in that area.

Strategies, and the interviewee has the following role: Founder, CEO, product manager, and product manager.

Project Open

Project Open develops an OS ERP system with the same name. They also offer various types of consulting services relating to adaptation of the system within organizations (beyond normal support). Project Open's development is highly controlled and are usually based on customer requirements and direct funding from customers. The main source for requirements is individual customers. However, they also take into account requirements from potential customers. Project Open has a limited scale of development that starts from self-initiated projects without involving a customer. These projects are based on experience from past client projects. Some requirements also arise internally from own ideas, and to a limited extent requirements are gained from the community around Project Open. Prioritization of stakeholders was described as:

"Well, you know everybody who basically finance and sponsor development, will be considered in the first place." (Founder of Project Open) The majority of requirements are gathered in meetings with representatives of the customer and users related to a specific customer project. During these meetings, they usually organize a workshop at the customer organization place for development of requirements with users. Requirements are also partly obtained from the community forums on sourceforge.net, but, since the community does not provide any funding, this source of requirement is not of high priority. At the moment Project Open also works with building a repository of requirements from four other projects, and plans to post them on a website to avoid having to start from scratch with future similar requirements. During customers' workshops, cost estimates on requirements are created. After this Project Open develops and uses prototypes to visualize requirements which they later on discuss with the customer. It usually leads to decisions about how to continue. If there is a need for requirements prioritization due to various constraints, the customer always has the last word. In situations where they feel they need more feedback about a specific requirement within a short period of time, they tend to repeat the workshop activities, as described by the founder of Project Open in the following way:

"In some very rare cases we sometime would need to organize like a second workshop to dive deep into particular questions that have come up during this stage and only then these are required -when we talk about more complex extensions, configuration of workflows and so on."

Project Open visualize requirements through prototypes, besides this they also describe them in conjunction with a form of use cases. This is done to make sure that requirements are understood correctly, and to make it possible to have feedback on requirements from the customer. During the requirements engineering process changes in requirements are managed through an iterative process. During requirements engineering activities documentation of requirements are done in parallel, by formulating requirements in a specific document. This documentation is then used as a manual for the system.

Night Labs

Night Labs is an organization that develops OS products and offers consulting services in the OS software development field. They develop an OS ERP system called JFire. Night Labs provide their own support and adjustments of their own developed systems.

Software development by Night Labs is divided into different projects, each project having its own requirements management process. Requirements are gained by talking to the customer. This is the major source of requirements, the idea is to have customers to describe requirement from the context of usage. Requirements are also obtained from a community forum where developers and users can discuss and also provide feedback on requirements. Requirements are also gained from discussions within Night Labs. They also analyze requirements in competing systems. Night Labs put great importance to investigate whether requirements are specific to a specific customer or if it is possible to adjust them to fit more customers. Recycling of requirements is done by analyzing requirements of modules that they already have developed for a specific customer. They then investigate whether it is possible to implement the system and making it useful for another customer, with or without changes. The CEO of Night Labs says:

"Of course it happens sometimes, that we think: 'Ah, this is very specific´ then we implement it specifically and then maybe later someone else comes with more of the same thing, and only sometimes minor changes and then of course we go back and take the previous project, and analyze what can we pull out".

Night Labs state that dependent on the development situation there is to some extent different demand on management of requirements. An individual project often gathers a larger amount of requirements in the beginning. After receiving some feedback the major changes primarily relates to contextual changes because it was misunderstood from the beginning. If several projects run in parallel, it could mean that requirements to a higher extent will be gained during the projects because of overlaps between the projects' requirements. It is also stated that requirements continuously comes from the community. Once Night Labs have gathered a variety of requirements for a project, they try to investigate how the requirements can be implemented and provide feedback to customers aiming at resolving uncertainties. At Night Labs they argue that customers usually do not provide adequate information about their demands so they could implement requirements directly. The CEO states that:

"In this situation we basically have most of the requirements analysis at the beginning and then we have during the project only analyses of maybe misunderstanding and adapting to the requirements, to fit the needs of the customer better".

To handle this situation they therefore develop use cases which they use when discussing requirements with customers. These use cases are then used to verify that all requirements are consistent with what the customer wants and expects. This activity takes place regularly. The CEO, however, said that there often is confusion and it is important to work closely with the customer throughout the process to quickly ensure that they are on the right track. Night Labs also present prototypes consisting of an early version of implemented requirements for the customer, to obtain feedback confirming that their understanding of the requirement is correct. If constraints arise regarding implementation of a number of requirements within the same project, Night Labs conduct priority activities focusing on deciding on what requirements to be implemented first. They present the situation for the customer, after which the customer should select the items to be prioritized. However, sometimes they need to do the requirements prioritization by themselves. The prioritization is then based primarily on the basis of what benefits the project most and what implemented requirement benefits the largest number of users. The CEO says:

"So we have to invest from our own money, so we have to decide if this is a benefit for the project in general, for us as a company, whether it benefits" a wide range of users or whether if it is a very, very individual thing".

Developed use cases have the roles as both contract and documentation between Night Labs and the customer. Regarding communication within the community forums this communication is automatically saved and stored on a wiki. Customers may self-prioritize requirements they consider most important in their projects but Night Labs has to interact and say what is possible, considering all necessary constraints. The CEO describes this in the following way:

"Of course we make constraints, if he says: 'I want something' and we know that for this something, something else needs to be done and he says: 'Ah, but this I want later' then we have to tell him: 'Yeah, sorry, but you can't build the roof without first building the house'."

Night Labs in a similar way involve the community by constantly showing were in the process of implementing a requirement they are and collecting feedback from the community in that matter. Changes on requirements are handled in what is termed as "Change Request". These changes are handled differently depending on what stage the project are in when they are discovered. If changes occur before implementation has started they are according to Night Labs not a big problem. But, if there is a change in requirements that have already been implemented, it is a bigger problem. Night Labs then solve this problem by dealing with it in the next version of the system.

Openbravo

Openbravo is an organization that develops the OS ERP system Openbravo ERP. Special customization and other services around Openbravo ERP are done by partners who are scattered around the world.

Depending on type of development there is a variation on how requirements are gathered. Requirements come from partners, the community related to Openbravo, as well as internally. Partners are seen as the main source of requirements for future development of Openbravo ERP. Requirements management is done through close contact with the originator of the project and is constantly ongoing. All sources, however, plays a role, a product manager at Openbravo describes it as:

"Our Requirements are driven of what the partner's need, but also" in a large part by what we believe need to be done to strategically move the product forward and provide a best of breed platform for developers."

If there is a partner involved in future development of requirements, this is discussed in meetings and/or forums with the partner. Another way of requirements gathering is by monitoring community forums. After the specific context for the requirements is described, requirements are visualized by various forms of prototyping in order to produce feedback, and to confirm that the resulting requirements are correct. These are then presented either for customers or for the whole community, through meetings, forums and blogs. The prototypes are mainly based on requirements from external stakeholders. However, on some occasions, prototypes are developed from internally gained requirements; based on what developer at Openbravo think users want to see in the system. The prototypes in that case also aim at generating feedback from potential users. The product manager gave the following description of the process:

"We actually start our requirements gathering from the perspective of what will the user see, what interface, what screen the user will be presented with and the workflows, and we work backwards from there."

Prioritization of requirements is sometimes done by a partner. This is the case if the partner provides money for specific functionality to be implemented. If so, there is a discussion with the partner in order to reach an agreement over what should be done. But, in most cases requirements prioritization are based on what they believe is best for users, however, sometimes they let users vote on what requirements should be implemented. Openbravo is working on what they call its backlog which is a list of requirements and its priority. This backlog consists of three pillars: the first pillar is "maintain" that aims at constantly keep Openbravo far ahead among the competitors, which is described by the product manager as:

"One is that we want to maintain our competitive edge and also that with our partners."

The second pillar is "Delight" which aims at increasing ease of use for users of Openbravo ERP. Described by the product manager as:

"That is we want to develop features and functionality that would delight our users (...)".

The last pillar is "Monetize" which aims to provide an economic value to the product, which is described by the product manager in the following way:

"These are features that allow Openbravo and its partners to make money." When a partner is involved a specification of the requirements are developed before implementation begins. The specifications are posted on a forum where feedback can be obtained and were Openbravo developers are able to direct questions about the requirement to the partner. Documentation of requirements continues the whole time during the project and is done in parallel with development. Openbravo is aware of the fact that requirements changes and therefore has Openbravo, according to the product manager, a flexible approach to managing change. However, when implementation has started changes become more complex. Changes are handled through the forum, where developers and other stakeholders, according to the product manager, can have a dialogue about change:

"And we have a very interactive approach in defining the requirements for our customers, and while that is going on, any change is permissible, until the point that we start development (...)".

Open Source Strategies

Open Source Strategies is an organization that develops Opentaps and whose purpose is to promote OS development in general. They also provide consulting services, mainly related to adjustments of Opentaps, but also on evaluating, testing, certification, training in development and integration of the software.

The main sources for requirements are, according to a product manager for Opentaps, users of the system and the Opentaps related community. However, some requirements are gained internal, during own development when the system is used by themselves. Opentaps also have customer projects where customers are responsible for presenting requirements. These customer projects have the highest priority. Gathering of requirements are in part concentrated to the start of the project. The major part of requirements is collected at the beginning by discussions with the customer and its users. All requirements from the collection add up to what the product manager termed as an issue-tracker. However, the product manager adds that new requirements arise during the project, primarily through the monitoring of community forums, but also internally during the time they develop the system. The gathering of requirements is done in various ways, for instance by being contacted by users who produce their own needs; these are then discussed to develop a stringent set of demands. The product manager said:

"Then basically we would go to the user and discuss exactly what they're looking for, and we would put it usually on an issue tracker to describe what their requirements are."

Sometimes Opentaps create prototypes that are presented to the community and based on these prototypes experience on requirements is gained. In addition Opentaps sometimes also use scenarios describing the context as they have understood it during discussions with users. They then use the scenarios to achieve feedback on requirements and its context. Reuse of requirements is also an aspect of their requirements management, which is described by the product manager in the following way:

"In this way it's a bit like a city: each building in the city represents the requirements of its residents at one point, and the buildings are reused and modified over time to meet new requirements".

At Opentaps changes in requirements are handled by introducing changes in the system, which then undergoes testing and thereafter are documented. This may be due to the iterative process they use, which the product manager describes as:

"It is just an iterative process of the system being used of people and shown to people and their feedback gets incorporated and the system is modified."

Requirements are undergoing discussions and various tests with the customer to ensure that requirements are correctly understood. Stakeholders in the community forums also provide feedback through the various scenarios presented in the forums. The requirements prioritization that takes place depends on various factors based on whether it is a customer project or not. For customer projects, the customer has the final say regarding what requirements should be prioritized. If not, prioritization of requirements is done from the number of users that Opentaps believe would have the function, or depending on the number of users who have contacted them and asked for a specific function. The product manager said:

"So for example, a lot of people will come to us and say 'you know we would like this" and that, if it is something we think will benefit a lot of users we will give it a higher priority". Documentation of Opentaps then takes place after the functionality has been implemented. This documentation is then used as user manuals and to preserve requirements for future use. This is described by the product manager in the following way:

"Usually after the feature has been implemented, for the purpose of allowing other people to use the feature and also documenting the requirements for later use".

ANALYSIS AND DISCUSSION

The following section highlights both similarities and differences in how end-users are involved in development of the four organizations respectively OS ERP system. The description above is analyzed and discussed from literature around software requirements under the following headings: 1) requirements elicitation, 2) requirements analysis and negotiation, 3) requirements documentation, 4) requirements validation, and 5) requirements changes.

Requirements elicitation

It is possible to distinguish similarities and differences in how the different organizations collect requirements. Three of the organizations have a more concentrated collection of requirements at the start of the project. However, there is then an ongoing less extensive requirements elicitation in all cases. Openbravo differs from the other organizations since it has a continuously requirements gathering process where they constantly repeat their activities to gather requirements. The requirements management process in all four organizations suggest that they take into account changes on requirements related to its context, just like [START_REF] Hickey | Elicitation technique selection: how do experts do it?[END_REF] as well as Kotonya and Sommerville (1998) state being necessary. This is also in line with the statement from [START_REF] Eriksson | Requirements engineering for IT-systems[END_REF] who argues that it is difficult to gather all requirements at one single point. All interviewees claim that the organizations focus a lot on customers when gathering requirements, just like [START_REF] Davis | Just enough requirements management: where software development meets marketing[END_REF] describes as the key stakeholders in a system development project. However, it is only Open Source Strategies, which explicitly says that they interact directly with users when they discuss requirements. The other organization seems to more indirectly discuss requirements with other stakeholders and not directly involve end-users. It is also stated that requirements are gained internally within the organizations, except in the Project Open case. All organizations use community forums to develop standards to some degree, however, the extent of their importance as a source for requirements differ between the different organizations. Project Open does not involve the community in the requirements gathering to any large extent, while others take more account of different communities. There is no clear idea of what types of stakeholders that are involved in the community forums. But, it is possible to speculate that it probably involves different groups of stakeholders, including users. This may explain why organizations do not directly approach the users to gather requirements. The community may also consist of developers and other stakeholders. It can be assumed that a high interest in the system is needed for any stakeholders to be active in the community. Therefore, there is possibly a mismatch between various stakeholders involved on the forums. The prioritization of stakeholders is consistent within the organizations, since all are taking the greatest account of the one that provides funding. Group Meetings is also a regular feature of the organizations, however, Project Open uses workshops instead. Both activities were based on individual group meetings with discussions between stakeholders and developers. Furthermore, it is possible to distinguish differences in what activities and technologies that they choose in their requirements elicitation process. These differences can be explained from [START_REF] Jiang | Combining Requirements Engineering Techniques -Theory and Case Study[END_REF] who argue that the choice of techniques may be different because of stakeholders' knowledge, or from [START_REF] Hickey | Elicitation technique selection: how do experts do it?[END_REF] as well as [START_REF] Zowghi | Requirements Elicitation: A survey of techniques, approaches and tools[END_REF], whom argue that selection of technologies is based on the context for the requirements. Reuse of requirements is done only in three of the organizations. Recycling is most pronounced in Project Open, which has built storage of requirements from previous projects, to avoid repeating the process to develop similar requirements. This is in line with [START_REF] Robertson | Mastering the requirements process[END_REF] who argue that recycling can be the basis for new requirements. Night Labs only reuse requirements from already implemented modules, however, despite that changes are usually required to be made on the requirement. Their reuse demands insights into parts of the system. Reuse of Open Source Strategies takes place over time, without any specific plan. In Openbravo reuse is not a widespread activity, the reuse of requirements that is done is done primarily through the reuse of code. Table 1 provides an overview of requirements elicitation in the different organizations.

Activities/ Techniques

Workshops,

Group meetings, community forums.

Reuse of requirements

Building up a stock of readymade requirements from previous projects that must be used when having related demands, to avoid the need to repeat the process. However, changes are often required.

Re-use of requirements is done by analysis of previous projects with similar requirements. Requires usually small changes.

No reuse of requirements. Some reuse exists when requirements change. Previous requirements can be the basis for new demands.

Where do demands come from?

Customers, potential customers, internal, community.

Customers, internal, community, market analysis

Partners, community, internally

Customers, users, community

Requirements analysis and negotiation

The use of prototypes is one way among the organizations to analyze requirements. The prototypes are presented to various stakeholders to identify problems. This is consistent with the view that [START_REF] Kotonya | Requirements engineering: Processes and techniques[END_REF] give on the analysis and negotiation phase. However, Night Labs differ since they do not use prototypes. Within all organizations there are also other activities designed to create discussion about requirements. Three of the organizations are following group meetings, while Project Open uses workshops to discuss the same issue. Both activities promote discussion of requirements but they differ to some extent. Workshops are seen as a more formal and structured activity than group meetings, however, both types of discussion activities are designed to arrive at agreement on requirements. All organizations use a systematic approach to analyze requirements and describe the context for requirements, but also to find out if they have developed legally ok requirements. This is consistent with one of the main activities in the analysis phase that [START_REF] Sommerville | Requirements engineering: a good practice guide[END_REF], [START_REF] Kotonya | Requirements engineering: Processes and techniques[END_REF] as well as [START_REF] Wiegers | Software Requirements[END_REF] chooses to emphasize, claiming that this are distinctive part of the analysis and negotiation phase in requirements management. It is common for developer to prioritize customer requirements in the projects they are involved in. The organizations involved in internal projects gives priority based on what would benefit a major part of users. This statement is consistent with [START_REF] Karlsson | Software requirements prioritizing, the Second International Conference on Requirements Engineering[END_REF] who describes, the importance of stressing customer satisfaction when prioritize requirements. Prioritization in Openbravo is mainly based on what they call "Monetize", which basically means that requirements that allow Openbravo and its partners to make a profit should be prioritized. The negotiating process in the described organizations is consistent with the structure [START_REF] Kotonya | Requirements engineering: Processes and techniques[END_REF] present in which a discussion, prioritization and agreement are included. Table 2 gives an overview of how the analysis and negotiation of requirements are done at the various organizations.

Requirements documentation

Requirements documentation in Project Open, Night Labs and Openbravo is done in an ongoing fashion during development projects. The ongoing documentation is a way of dealing with changes among requirements and to be more flexible. The documentation process in Open Source Strategies differs, and documentation is done first after requirements have been implemented. The aim of the documentation varies between the organizations. However, all organizations except Openbravo are using the documentation as a base for user manuals. Night Labs documentation is also used as a contract between them and their customers. Openbravo are using the documentation as a support to developers. The way documentation is done also differs to some extent, however, they all document requirements in what they call a requirements specification. Night Labs in addition also document requirements in use cases, which is in line with what [START_REF] Eriksson | Requirements engineering for IT-systems[END_REF] describes as one way of using use cases. An overview of requirements documentation in the organizations is shown in Table 3.

Requirements changes

All organizations are working continuously to cope with changes that occur during the requirements engineering process, which is consistent with the picture [START_REF] Kotonya | Requirements engineering: Processes and techniques[END_REF] give as necessary when dealing with requirements. This suggests that all organizations are aware of that the context of requirements is changing, as several authors point out [START_REF] Davis | Just enough requirements management: where software development meets marketing[END_REF][START_REF] Eriksson | Requirements engineering for IT-systems[END_REF][START_REF] Kotonya | Requirements engineering: Processes and techniques[END_REF]. All organizations are taking account of changes if they occur before the development is initiated, while there are clear discrepancies in how they work to manage these changes later in development. It is possible to distinguish the two organizations, Labs Night and Openbravo, from the other since they have distinct techniques to manage changes and change requests. Project Open and Open Source Strategies does not have an explicit technique to manage change. However, they deal with changes by having an iterative approach. Table 5 gives an overview of the process of requirements changes in the organizations. Summing up the description above which was based on the interviews, but also on the analysis of similarities and dissimilarities also presented above, give the following summary. Regarding requirements elicitation, it can be stated that concentrated requirements gathering takes place at the beginning of the projects. But, there are also an ongoing requirements gathering during development of the projects. Involved stakeholders are customers, community, and internal stakeholders. Customers of the developed product are the prioritized stakeholder group. The major technique used for requirements elicitation is group meetings and workshops, and community forums. There is also to some extent a reuse of requirements from previous projects.

During the analysis and negotiation phase group meetings and workshops, and prototypes are used to analyze requirements. In customer projects the prioritization is done by the customer. In internal projects the prioritization is done from the perspective of what will be most beneficial for the biggest part of users. Negotiating activities are done during the analysis of requirements. All companies consult stakeholders, both through structured discussion activities, and through more informal approaches.

Requirements documentation is ongoing in many parts of the requirements management process. The documentation is then often used as a user manual or act as a base for the user manual. To a high extent the documentation builds on requirements specifications.

Requirements validation is an ongoing process, Reviews of requirements and prototypes are used to validate requirements. In the process the community and users are involved.

Regarding requirements changes is this done continuously until the development is initiated and has started.

Conclusions and future research

The research presents a representation of requirements management processes in Open Source ERP development. From this some conclusions can be drawn on the question asked in the paper, which are: How are end-users involved in the development of Open Source ERPs?

Requirements elicitation is done as a concentrated collection of requirements in the beginning of the development project, followed by a concurrent less extensive requirement collection during the project. There is also a reuse of requirements from previous projects. From the question on end-users involvement it can be concluded that users are involved but not to a higher extent than in other standardized software package development. There is a tendency that end-users are involved to a higher extent than in proprietary ERP development. However, if critical reflect on this it can be said that this tendency is to a very high extent similar to involvement in customization/configuration of proprietary ERP software package.

There are a number of different ways in which stakeholders are involved. The most common techniques consist of personal meetings with customers, aiming at creating discussions about requirements. Community forums are used to stimulate dialogue about context of requirements and produce feedback on specific requirements. Prototypes are used to show stakeholders how work is progressing and to ensure that the requirements corresponding to stakeholder needs. Requirements are then visualized to users and analyzed through close meetings in which they also are negotiated upon.

It can also be concluded that to some extent are end-users involved in prioritization of requirements, however, interesting to notice is that prioritization to a high extent builds on what the developing OS ERP organizations see as beneficial for them. In other words, if the customer pays for implementation of the specific requirement or if they see that they will earn money from the implementation in another way, for instance gaining a competitive advantage in relation to competitors in the OS ERP space, the specific requirement will be prioritized.

The research shows that there is a structured requirements management process in the development of open source ERPs. Future research on how this process is related to the often stated benefit, flexibility of Open Source ERPs, would be interesting to conduct.

Table 1 .

 1 Requirements elicitation

	Organization	Project Open	Night Labs	Openbravo	Open Source
					Strategies
	Description	Requirements	Requirements	Requirements	Requirements
		gathering begins	gathering take	gathering take	gathering take
		with a high	mainly place in	mainly place in	place in an
		number of	the beginning of	the beginning of	ongoing
		requirements	customer	customer	fashion.
		gathered from	projects with	projects with	However, the
		the customer at	customers and	customers and	majority of
		the beginning of	their users, but	their users, but	requirements
		the project. The	there is also an	there is also an	are collected, at
		community plays	ongoing	ongoing	the beginning of
		no significant	gathering of	gathering of	projects.
		role in gathering	requirements	requirements
		of requirements.	from the	from the
			community.	community.

Table 2 .

 2 Requirements analysis and negotiation

	Organization	Project Open	Night Labs	Openbravo	Open Source
					Strategies
	Description	Analysis of	By holding	When a	Discusses and
		requirements is	discussions with	prototype is	shows the
		done through	stakeholders	produced, they	customer
		discussions with	sorting out	present it to the	functions in a
		the customer, as	confusion on	community and	prototype,
		part of the	requirements.	partners who	collect
		workshops	Takes place	provide	feedback. This
		conducted when	when a variety	feedback.	is done after a
		gathering	of requirements		set of demands
		requirements.	has been		is developed.
			developed.

Table 4 .

 4 Requirements validation

	Organization	Project Open	Night Labs	Openbravo	Open Source
					Strategies
	Description	Collect	Collect	Partners are	Through
		feedback on	feedback and	closely involved	discussion with
		requirements	discuss it with	in the	the customer
		and discuss it	the customer	development, and	and the
		with the	and the	through frequent	community.
		customer in an	community	contact with the	This is done at
		ongoing	regularly during	community,	the end of the
		fashion.	the project.	feedback on	requirements
				requirements is	management
				discussed	process.
				frequently.
	Activities /	Review,	Community	Community	Community
	Techniques	prototypes, use	forums,	forums, reviews,	Forum, Review,
		cases.	reviews,	prototypes.	test-case.
			prototypes, use
			cases.

Table 5 .

 5 Requirements changes

	Organization Project Open	Night Labs	Openbravo Open Source
					Strategies
	Description	Changes	Changes are	Changes are	The work is
		occurring early	considered if	generally	done in an
		in the	related	allowed	iterative
		development	requirement	before	process that
		project are	not have been	development	allows that
		taken into	implemented,	starts. Then	changes in
		account more	otherwise	it's up to the	requirements
		or less directly.	changes are	one who	can be
		After	managed in the	request the	handled.
		development	next version of	change on	Changes are
		has started	the system.	requirement	implemented
		only minor	Change request	to take	directly in the
		changes are	is used to	decisions.	system.
		considered.	manage	The forums
			changes.	are used to
				manage
				changes.

Acknowledgement

I would like to thank my former students Alexander Persson and Oscar Sjöcrona at department of Informatics, Lund University for their assistance with helping me collecting the data for this research.

University and a Bachelor degree in Business Informatics from Jönköping International Business School. He defended his doctoral thesis "Deciding on Sourcing Option for Hosting of Software Applications in Organisations" in 2007. Currently he works as an Associate Senior Lecturer at the Department of Informatics at School of Economics and Management, Lund University. Before that he had a Post Doc position for three years at Center for Applied ICT at Copenhagen Business School, within the 3gERP project (http://www.3gERP.org). He is a member of the IFIP Working Group on Diffusion, Adoption and Implementation of Information and Communication Technologies (IFIP TC8 WG8.6), the IFIP Working Group on Enterprise Information Systems (IFIP TC8 WG8.9) and the research networks: VITS Work practice development, IT usage, Coordination and Cooperation and KiO Knowledge in Organizations.

To provide support for the developer to communicate changes.

To ensure the requirements and provide assistance to users.

Requirements validation

All organizations except Open Source Strategies use prototypes to get feedback on requirements they have developed. Project Open does not address the community in relation to feedback on developed requirements, while the rest do so. Even if all, except Open Source Strategies, use prototypes the way they use prototypes differs. What differs is the way they present a specific prototype. Three of the organizations have validation activities that are repeated during the requirements engineering process, which is in line with [START_REF] Wiegers | Software Requirements[END_REF] as well as Loucopolous and Karakostas (1995) description of doing validation activities throughout the entire requirements engineering process. However, Open Source Strategies differs since they perform this activity only at the end of the development project. All organizations have a discussion with the customer aiming at validating requirements. The community is also involved in validation of requirements, except in Project Open, which consistently excludes the community from the entire requirements management process. A common feature of organizations is that they perform the various activities in order to check whether they have got the requirements right, which is consistent with the view that [START_REF] Kotonya | Requirements engineering: Processes and techniques[END_REF][START_REF] Kotonya | Requirements engineering: Processes and techniques[END_REF][START_REF] Sailor | System Engineering: An introduction[END_REF] describes as one characteristic of the validation phase.


Nikhil Srinivasan

Jan Damsgaard

The Adoption of Web 2.0 platforms

Keywords: web 2.0, adoption, social network, diffusion

In this paper we study the adoption of Web 2.0 platforms. Existing theoretical approaches to understand the adoption of IT are critically reexamined for their applicability in the Web 2.0 domain. We find that the two basic assumptions of traditional approaches 1) the unit of analysis is a person and 2) the technology´s primary utility is personal, does not hold for Web 2.0 platforms. Instead, we argue, the appropriate unit of adoption is the social network and the utility stems mainly from collective use.

INTRODUTION

Web 2.0 platforms have in very short time integrated into people´s lives both socially and professionally. A Web 2.0 platform is loosely defined as an aggregation of technologies such as blogs, wiki's, mash-ups, social bookmarking sites, and others that are build around social relations that individuals establish or confirms with each other for the purpose of communication, collaboration and coordination of information, knowledge and activities [START_REF] O'reilly | Design patterns and business models for the next generation of software[END_REF]. A web 2.0 platform is inherently a participative environment where the consumers of information and knowledge are simultaneously the co-creators and consumers of information and knowledge [START_REF] Parameswaran | Research issues in social computing[END_REF].

Web 2.0 has attracted the attention of researchers, practitioners and organizations alike. One reason is that the estimated value of a platform, for example Facebook is worth $11.5 Billion according to Bloomberg Business Week (March 3, 2010 edition) and the revenue made on ads is enormous, so the value of predicting and understanding which platform succeeds and why is substantial. However before we are overwhelmed by the success of a few platforms we must remember that most Web 2.0 platforms never gain much attention and become abandoned after the first colonists realize that too few are following to make the platform viable. Most settlers therefore move on leaving behind a "ghost town" platform of forgotten passwords, profiles that are never updated, and connection requests that are never granted.

Academic studies have examined the adoption of specific Web 2.0 technologies [START_REF] Hester | Innovating with organizational wikis: factors facilitating adoption and diffusion of an effective collaborative knowledge management system[END_REF]) and employed popular and widely acknowledged models such as Diffusion of Innovation (DOI) [START_REF] Rogers | Diffusion of innovations Free Pr[END_REF], Technology Acceptance (TAM) or Unified Theory of Acceptance and Use of Technology (UTAUT) [START_REF] Davis | User acceptance of computer technology: A comparison of two theoretical models[END_REF][START_REF] Venkatesh | User acceptance of information technology: Toward a unified view[END_REF]) that have proven themselves in the past. However many extend DOI and TAM to cover Web 2.0 platforms without revisiting the basic assumptions of the models and their acclaimed validity domain [START_REF] Sledgianowski | USING SOCIAL NETWORK SITES: THE EFFECTS OF PLAYFULNESS, CRITICAL MASS AND TRUST IN A HEDONIC CONTEXT[END_REF]. One profound difference is that Web 2.0 platforms only have value when many are using them, which is not paramount for many previous IT applications that were perfectly useful for an individual alone e.g. word processing. This weighty difference is often neglected. Therefore Web 2.0 represents a paradigm shift in IT and as such traditional models of adoption and diffusion may not readily apply. The central point of departure is thus the following research question.

How to understand the adoption of Web 2.0 platforms? The remainder of this paper is organized the following way. In the next section we describe Web 2.0 platforms and review the classical diffusion literature and pinpoint some of the limitations of an extension of their validity domain. In the third section we propose the social network lens as a better explanatory vehicle for understanding and predicting the adoption and diffusion of Web 2.0 platforms. Finally we make some conclusions and discuss the potential implications of our work.

THE NATURE OF WEB 2.0 PLATFORMS

In this section we first summarize and discuss the literature surrounding web 2.0 platforms and we then review the literature in adoption and diffusion literature.

2.1

Web 2.0 platforms Web 2.0 platforms refer to technological and social infrastructures that are used to support specific and generalized modes of communication and collaboration between distributed individuals that share a common interest. Web 2.0 platforms are often referred to as social media platforms. Social media have been described as having the unique feature of "active creation of content by their users or members" (Scott et al. 200,O'Reilly 2005) where the creation of content takes place through the building and maintaining of social relations. Technologies such as wikis, blogs, podcasts, folksonomies, mash-ups, social networks, virtual-worlds and crowd-sourcing are also referred to as web 2.0 technologies (Andriole 2010).

Revisiting classical adoption and diffusion theory

The diffusion and adoption of technologies have been examined from two broad perspectives. The first perspective focuses on the personal adoption of a technology. The second perspective focuses on the spread of a technology among a group of people.

The individual adoption of a technology is based on two broad theories from social psychology i.e. the theory of reasoned action [START_REF] Fishbein | Belief, attitude, intention, and behavior: An introduction to theory and research Addison-Wesley[END_REF]) and the theory of planned behavior [START_REF] Ajzen | From intentions to actions: A theory of planned behavior[END_REF]. The first work by Davis, Bagozzi and others (1989;[START_REF] Davis | Perceived usefulness, perceived ease of use, and user acceptance of information technology[END_REF] was referred to as the technology acceptance model (TAM). TAM has been applied across cultures [START_REF] Straub | Testing the technology acceptance model across cultures: A three country study[END_REF], gender [START_REF] Gefen | Gender differences in the perception and use of e-mail: An extension to the technology acceptance model[END_REF], extended with social influence [START_REF] Malhotra | Extending the technology acceptance model to account for social influence: theoretical bases and empirical validation[END_REF], accounted for task-technology fit [START_REF] Dishaw | Extending the technology acceptance model with tasktechnology fit constructs[END_REF], and other extensions. A comprehensive review performed by [START_REF] Venkatesh | User acceptance of information technology: Toward a unified view[END_REF] compared 8 different user acceptance models and synthesized them into a comprehensive model referred to as the Unified Theory of Acceptance and Use of Technology (UTAUT). Since an extensive review of the theory is beyond the scope of the paper please refer to Venkatesh [START_REF] Venkatesh | Dead or alive? The development, trajectory and future of technology adoption research[END_REF][START_REF] Venkatesh | User acceptance of information technology: Toward a unified view[END_REF]) and the special issue of JAIS for a more extensive literature review. Broadly speaking within the individual technology acceptance literature characteristics such as habit, self-efficacy, experience, task relevance, and others are primary and important determinants of behavior regarding individual technology adoption and use [START_REF] Davis | Perceived usefulness, perceived ease of use, and user acceptance of information technology[END_REF][START_REF] Venkatesh | User acceptance of information technology: Toward a unified view[END_REF].

The second perspective on the spread technology exists at a broader level and examines the factors that contribute to and the manner in which technologies diffuse across a population of potential adopters similar to the spread of a virus. [START_REF] Rogers | Diffusion of innovations Free Pr[END_REF] named adopter categories that characterize the nature of the adopters along a Sigmoid curve of innovation adoption and places them in four categories; innovators, early majority, late majority and laggards. Since the work of Rogers, DOI theory has been extensively applied in IS [START_REF] Attewell | Technology diffusion and organizational learning: The case of business computing[END_REF][START_REF] Moore | Development of an instrument to measure the perceptions of adopting an information technology innovation[END_REF][START_REF] Mustonen-Ollila | Why organizations adopt information system process innovations: a longitudinal study using Diffusion of Innovation theory[END_REF]. However despite its extensive application and popularity, DOI has also received some criticism [START_REF] Lyytinen | What's wrong with the diffusion of innovation theory?[END_REF][START_REF] Lyytinen | Inter-organizational information systems adoption -a configuration analysis approach[END_REF]) noting that DOI may not be sophisticated enough to address complex IT. DOI theory is especially effective at examining singular, monolithic technologies or well-defined systems with a apparent function such as TV sets or coffee makers [START_REF] Lyytinen | What's wrong with the diffusion of innovation theory?[END_REF]. Such technologies typically rely on economies of scale on the supply side and the use of the system on the demand side is fairly independent of others use of the same technology. For instance, the use of a coffee maker is pretty straight forward and your usage is fairly independent of other individuals' use of coffee makers. Furthermore, mass production on the supply side drives prices down leading to wider diffusion. As such, DOI theory is successful in examining the diffusion of simple technologies as an aggregated phenomenon across a population of would be adopters.

Nikhil Srinivasan/ Jan Damsgaard

2.3

Revisiting the assumptions of TAM and DOI

In the TAM and DOI approach to the adoption of innovations and technologies, individual characteristics are the primary determinant of individual adoption and use behavior. In examining the adopter population, individuals are treated as relatively isolated from the group thereby separating them from the social setting in which they are embedded. By treating individuals as independent in their adoption behavior, the TAM and DOI perspectives do not focus on the interplay between users and between user behaviors [START_REF] Benbasat | Quo vadis, TAM[END_REF]). Furthermore, TAM and associated theories of adoption do not explain why parts of the population are more likely to adopt the technology or service and the other parts of the population less so despite sharing similar individual characteristics [START_REF] Lyytinen | Inter-organizational information systems adoption -a configuration analysis approach[END_REF]. While they do a good job of explaining why specific individuals adopt technologies and services, they do a relatively poor job of understanding and explaining why others do not adopt the technology or service despite being similar and belonging to the same pool of potential adopters [START_REF] Lyytinen | Inter-organizational information systems adoption -a configuration analysis approach[END_REF].

Differentiating Web 2.0 Platforms

Web 2.0 platforms as infrastructures bind social networks together through which existing and new social relations are established and maintained. Due to network effects inherent in web 2.0 platforms the social relationships and transactions are not mobile and individuals are relegated to adoption of web 2.0 platform based on similar adoptions by members of his or her social network. Consequently, the adoption of a web 2.0 platform by an individual is subordinated to the adoption of web 2.0 platforms by the social network. The superior predictor of the use of web 2.0 platforms by an individual is consequently the social network that a specific person belongs to and not some personal traits or fit with a specific platform as DOI and TAM models would assume.

Individuals may probe web 2.0 platforms in search of the most appropriate one but the social network can only adopt a single web 2.0 platform due to the network externalities associated with it. We therefore need to shift the unit of analysis from the singular person to the social network. The individual user may prefer a different platform but adoption would lead to online social exclusion and therefore the individual is obliged to adopt the same platform as the social network regardless of personal preferences and past experiences (analogously a goose may prefer to fly a different way but will lose its flock if it does so). Behavior in such platforms is not coordinated but rather based on informal rules and spontaneity that govern interactions and is similar to social norms. Similarly behavior and knowledge in web 2.0 platforms is conditional on the use of the system by others.

INSIGHTS FROM SOCIAL NETWORK RESEARCH

Social network literature highlights the role of friends, family and coworkers in driving the adoption and the diffusion of technologies and services [START_REF] Siam | Effect Of Network Relations On The Adoption Of Electronic Trading Systems[END_REF][START_REF] Sykes | Model of Acceptance with Peer Support: A Social Network Perspective to Understand Employees' System Use[END_REF][START_REF] Vannoy | The social influence model of technology adoption[END_REF][START_REF] Vilpponen | Electronic Word-of-Mouth in Online Environments: Exploring Referral Network Structure and Adoption Behavior[END_REF]). Furthermore, it also highlights the manner in which the embeddedness of individuals in networks increases the likeliness of adoption. To do this it relies on characteristics, relationships between individuals, and the structure of the social network that people are embedded in. Individuals replicate their real-world social relationships in web 2.0 platforms (Wellman et al. 1996). However web 2.0 based social networks are often incompatible with each other as they both increase the visibility of social networks and makes the communication boundaries between them transparent.

As we have characterized adoption and diffusion process of social media services as a network phenomenon, we are agnostic about the boundaries of the network. Social networks on web 2.0 platforms are exceptionally large and the ease of forming and maintaining relationships makes a clear demarcation of network boundaries conceptually and practically impossible. As such, in the context of web 2.0 platforms, social media services and social networks, it is important to examine both a specific social network and the global network of social networks. Social networks are important in social media service since they are likely the first and major sources of influence in adoption decisions. Global networks of social networks unlike single social networks focus on all the relationships that might exist between all the social networks in a specific demarcated system that exist on a specific Web 2.0 platform. For instance, a social network around fridge door magnet collectors on Facebook would be a specific social network while the global network would be the all the social networks existing on Facebook and all the relationships between the active social networks. The local configuration of relationships and the social network's adoption of technology represents a "we-intention" (Bagozzi 2007) on part of the social network. The local configuration of relationships can be described in a variety of ways ranging from traditional social network analytic measures to more generalized measures of social structure.

CONCLUSIONS

In this research-in-progress we examined social networks´ adoption of Web 2.0 platforms. The social network is an emergent entity of many individuals and their relations, yet it cannot be reduced to its constituent parts. Individualistic model that focus on adoption of such services by the individual user are less suitable for such analysis since they ignore the emergent properties of the social network and privilege the "parts" instead of the "whole". A social network perspective drives us to examining groups of related individuals in examining adoption web 2.0 platforms. The social network lens drives us towards examining relations and relational structures that comprise groups and social networks. The primary question that emerges from the use of the network lens is; how do social network characteristics influence adoption of web 2.0 platforms? While previous research may have examined web 2.0 and social media service adoption through the individualistic lens, they have included certain social network components in their analysis. Our question privileges the social network perspective above the individual and consequently the social network characteristics are not merely mediators or moderators but rather the independent determinant in adoption of web 2.0 platforms. This approach accommodates the puzzling fact that many people adopt several Web 2.0 platforms even though this is both ineffective and troublesome. An apparent anomaly that cannot be explained by the classical diffusion and adoption models but our approach provides a plausible explanation. Namely that the adopting unit for Web 2.0 platforms is the social network and since a person naturally belongs to multiple platforms she will have to adopt several platforms -in principle one for each social network that she feels part of and wishes to contribute to. Consequently a person may very well adopt several Web 2.0 platforms.

AUTHOR BIOGRAPHIES

Nikhil Srinivasan is a Post-doc at the Department of Information Technology Management at the Copenhagen Business School. His research takes place in the context of the dynamic and ever-evolving nature of human interaction in technology mediated environments. Specific interests in this domain include social network structures in knowledge communities and social media platforms and their effects on performance, and the role of networks in diffusion information and innovations. He can be reached at ns.caict@cbs.dk or at http://nsrinivasan.net

Professor Jan Damsgaard (JD) is the head of the department of IT management, Copenhagen Business School, Denmark. He holds a Ph.D. in Information Systems and a Master's degree in Computer Science and Psychology. His research focuses on the diffusion and implementation of networked technologies such as e-business, intranet, social media, and mobile services. Common for networked technologies is that they only become valuable through massive adoption. In much of his work JD combines business and technological perspectives. JD has worked and done research at numerous foreign institutions in the USA, China, Finland and Australia. JD can be reached at damsgaard@cbs.dk or at http://www.cbs.dk/staff/damsgaard/