Platform and auxiliary models

Different market mechanisms can be implemented in the same environment or platform to build various e-procurement systems with the same user interface. Invite (Kersten, Law et al. 2004) 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).

The Invite platform adopts a Model-View-Controller (MVC) design pattern (Reenskaug 1978- 79; Burbeck 1987), incorporating the transitions and rules (controllers), functional elements (models), information representation and user interface (views). The model represents data and the logic that governs access 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.

This design allows for the separation of the user interface from the embedded process models 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. 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 multi-attribute auctions.

In multi-attribute auctions, the problems are more complicated due to the availability of many alternatives and the implicitness of the buyer’s preferences. The bidders are allowed to make trade- offs among different attributes and are also required to make progressive bids. If the buyer’s preferences are completely disclosed, then decision support on generating admissible bids and calculating their values is helpful (e.g. Bichler 2000; Chen-Ritzo, Harrison et al. 2005; Strecker 2010). However, if the buyer’s preferences are not explicitly provided, then more advanced supporting models and tools are required, such as the identification of admissible bids based on the bound values on each attribute, evaluation of bids based on values of each attribute and visualization of the bidding process. Empirical studies have shown user heterogeneity, in terms of their bidding strategies and behavior, and suggested providing decision support in auctions (Bapna, Goes et al. 2004).

Similarly, a number of ENSs have been developed to implement various negotiation mechanisms (e.g. Kersten and Noronha 1999; Thiessen 2002). E-negotiation studies have also designed and tested various auxiliary models that provide different forms of support, including: analytical support, communication support and visualization support (e.g. Kersten and Noronha 1999; Swaab, Postmes et al. 2002; Schoop, Jertila et al. 2003; Weber, Kersten et al. 2006; Gettinger, Koeszegi et al. 2012). Their results suggest that these supporting features and tools are useful in e- negotiations: analytical support helps users to identify and use their preferences in decision making;

communication support mediates and facilitates offer and message exchange between the participants; and, visualization support presents and predicts the negotiation process. It also indicates that the effectiveness of these tools requires certain conditions and they can be complementary to each other.

Figure 4-5 demonstrates the implementation of these two types of mechanisms with other supplementary models (e.g. analytical support, communication support and visualization support) in Invite.

Figure 4-5. Implementation of MARA and MBMN in the Invite platform

These two mechanisms are the core models that are implemented through a generic procedure. They are supported by auxiliary models and tools. All these models are built as executable components, which can be invoked and integrated by the controller. Depending on the transaction situations (e.g. settings of rules and parameters), the model components are used to generate different composite components (e.g. activities in auction and negotiation such as bid/offer construction). These components may generate information that can be transmitted from the web server to the web browser on the user’s computer (e.g. recent bids/offers), while they may also require the user’s input

Model

Mechanisms Auxiliary

View

Controller

Information display Navigation MBMN MARA Analytic Communication Execution Visualization Inference engine Rules Parameters Web server Web browser

and requests from the browser (e.g. specifications of a new bid). The different views (information display and navigations) are implemented with the view components. The page composers combine the model components and view components to obtain, generate and display the required information.

Following the design framework proposed by Vahidov (see Chapter 6 & 7 2012), Invite is a synthetic meta-artifact, through which the technical meta-systems can be designed and implemented. This distinction allows the specification of the requirements and system design at different levels of layers. Depending on the requirements and purposes of the systems, various mechanisms, features and their configurations can be implemented. In this research, the focus is on mechanism design, implementation and comparison. Thus, the systems can be discrepant mainly at the process model level and mechanism specifications (i.e. different mechanisms). The system functions and features can be implemented on higher levels without affecting the process and mechanism design. The different implementation of the mechanisms is then represented with the design characteristics of the systems. This allows the comparison of different mechanisms using the systems as the instrument in which the mechanisms are embedded. By controlling or eliminating the differences in the design characteristics of the systems, the differences in mechanism design can be examined.

In document Three Studies on Multi-attribute Market Mechanisms in E-procurement (Page 80-83)