RÉGIMEN DE RECURSOS CONTRA LA DOCUMENTACIÓN QUE RIGE LA CONTRATACIÓN

Market mechanisms, being sets of rules governing transaction process and participants’ behavior, are models of processes and procedures that are implemented with other components in e-procurement systems (e.g. online auction systems and e-negotiation systems). Mechanism design aims to build concrete models with different rules and parameters, such as preference representation and information revelation. These models are then implemented in concrete systems with other supporting models and tools, such as analytical support and visualization support. In a review of e- negotiation systems, Kersten and Lai (2007) discussed three design issues: model, architecture and configuration. Mechanism design and implementation become a system design issue, i.e. how the models are represented and specified, how they are related to other system components, and how they interact with users and other system components.

In this section, mechanism design in economics and system design in information systems are linked to address the issues in mechanism design and implementation. The Invite platform which supports the implementation of varies mechanisms is then introduced.

2.5.1 Mechanism design and system design

Markets and market mechanisms have been the interest of economists, particularly those who study auction theory (Milgrom 2004), experimental economics (Smith 2003), and market design (Roth 2002). A general market system involves economic environment, individual preferences and behavior, mechanism, outcomes and performance (Smith 2003). Auction theorists use mathematics and logic to design various types of auction models (i.e., mechanisms) and study their features (e.g. Gächter and Riedl 2005; Gallien and Gupta 2007; Engelbrecht-Wiggans and Katok 2008).

Economists seek mechanisms which are incentive compatible; that is, the bidders can achieve the best possible result when they truthfully reveal all private information the mechanism requires (Maskin 2007). Typically the market participants are assumed to behave according to the economic

theory axioms (i.e., rationality, risk aversion, opportunistic behavior). Furthermore, they are homogenous with the exception of their endowment (e.g. funds available) and preferences.

In behavioral economic research, the main purpose is to design and experimentally validate market mechanisms which are implemented in the simplest form of information systems. In these systems, the embedded model (i.e. the mechanism) is of main concern, and user interface and system features are not the focus due to the homogeneity of market participants. The effort is to use mechanism, which are as much as possible devoid of any additional features due to user interface, data visualization tools or decision support aids.

From the information systems (IS) view, e-procurement is an IT artifact in which market mechanisms are implemented and which also includes many components that help its users using these mechanisms and conduct auxiliary activities. A number of such artifacts or systems have been developed to support e-procurement transactions (Croom and Brandon-Jones 2005; Minahan 2005; Talluri, Narasimhan et al. 2007).

Design science approach has been adopted in IS research to study the process, methods and models that can be used to build artifacts (March and Smith 1995; Hevner, March et al. 2004). A number of guidelines has been provided with some exemplars (Hevner, March et al. 2004; March and Storey 2008). It aims at producing generic system solutions to practical problems, while the type of system solutions proposed by a design researcher is a class of systems, or “meta-systems” (Walls, Widmeyer et al. 1992; Livari 2003). E-procurement transactions vary with regard to the products/services, participants and procedures. Thus, a class of e-procurement systems is needed to facilitate these different transactions, requiring different design and implementation. When implementing auction and negotiation mechanisms in e-procurement systems, they become different types of systems.

Vahidov (2006; 2012) suggested that a “what” (e.g. what type of systems) question may need to be specified or answered before asking the “how” question. He thus proposed a framework for

structuring representation of IT artifacts with two dimensions: perspectives and categories. Systems can be represented from four perspectives or layers, including: analytical, synthetic, technological, and implementation. They can also be categorized depending on their motivation, structure, behavior, and instantiation. This framework has been applied to represent e-negotiation systems (see Chapter 7 in Vahidov 2012).

2.5.2 Invite platform and mechanism implementation

Different mechanisms can be implemented in the same environment or platform to build different e- procurement systems with the same user interface. Only a few platforms support the implementation or deployment of different mechanisms. For instance, CNSS (Benyoucef, Alj et al. 2001), SilkRoad (Ströbel 2003) and Meet2Trade (Weinhardt, van Dinther et al. 2005) support various auction mechanisms by setting different parameters. Invite (Kersten, Law et al. 2004; Kim, Kersten et al. 2006) was initially developed to support negotiation mechanisms but recently has been extended to support auction mechanisms (Kersten, Pontrandolfo et al. 2011; Kersten, Pontrandolfo et al. 2012).

Invite is designed as a typical three-tier Web application illustrated in Figure 2-4. It is based on a database management system in the persistency layer, a Web-enabled application server in the business logic layer, and Web browser technology in the presentation layer.

Figure 2-4. Architecture of the Invite platform (Kersten, Law et al. 2004)

The Invite platform separates user data from system data into two databases, i.e. the system and user database. This facilitates model implementation and data analysis. The platform consists of the

negotiation controller, page composers and components that together determine and generate model instances, protocol instances and user interfaces.

Design patterns are “descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context” (Gamma, Johnson et al. 1994, p. 13). The Invite platform adopts a Model-View-Controller (MVC) design pattern which has its roots in Smalltalk (Reenskaug 1978-79; Burbeck 1987), incorporating the transitions and rules (controllers), functional elements (models), and information representation and user interface (views). Figure 2-5 demonstrates the Invite platform with MVC design.

Figure 2-5. MVC design of the Invite platform (Kersten, Pontrandolfo et al. 2011)

The model represents data and the logic that governs access to and updates of this data. The view specifies how the data contents of a model should be presented. The controller translates interactions with the view into actions to be performed by the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.

and execution rules. The mechanisms which incorporate the actions, interactions and their rules in a process can be decomposed into activities, procedures and rules; different configurations or sets of these elements are instantiations of these mechanisms. The user interface can be decoupled and implemented with different technologies, resulting in different system features such as tabular or graphical views of bids or offers.

Invite adopts a component-based software development approach. This allows extending or adding components to the component-base and assembling selected components for the design and deployment of many different protocols depending on the protocol specification. The rules are implemented with a database-driven approach (Wu 2009).

The underlying theory of transaction protocol design and implementation allows system designers to implement various mechanisms by configuring and reusing MVC components (Kersten and Lai 2007). A variety of mechanisms can be implemented in this platform, including: bilateral negotiations, multi-bilateral negotiations, and single-attribute or multi-attribute auctions.