Gachet, A. (2002) "A New Vision for Distributed Decision Support Systems", in Adam F., Brézillon P., Humphreys P., Pomerol J.-C. (eds) Decision Making and Decision Support in the Internet Age, proceedings of the DSIage 2002 Conference, Oak Tree Press, Cork, Ireland: pp. 341-352
A New Vision for Distributed Decision Support Systems Alexandre Gachet University of Fribourg Faucigy 2 1700 Fribourg Switzerland
[email protected] Many mission-critical, decision-making situations happen in dynamic, rapidly changing, and often unpredictable distributed environments. Military, governmental, and medical contexts are examples of such situations, which can be characterized by highly decentralized, up-to-date data sets coming from various sources. Unlike other decisionmaking tools, DSSs designed for such situations are challenged by the need to access this decentralized data at any time, from anywhere, under tight time constraints. ABSTRACT:
This paper proposes a new vision for distributed DSSs in such contexts. Its main contribution consists in confronting the existing knowledge in the area of distributed DSSs with new, emerging distributed technologies. It formulates six assumptions leading to a new definition of distributed DSSs. An example scenario illustrates these assumptions. KEY WORDS:
distributed DSS, decentralized network topologies, distributed technologies
1. An example scenario The Federal Office for Agriculture from an imaginary country uses a Decision Support System (DSS) for crisis management in the food supply sector. This system is based on statistical values, and expert data coming from various sources, and managed by a relational database management system. It is also based on optimization models of the agriculture of this country, managed by a proprietary model base management system. All this data is stored in a powerful and efficient centralized server. The set of mathematical solvers used as the knowledge engine are running on a centralized cluster of fast CPUs, which use a variety of techniques for replication, recovery, and load balancing to keep the system in a consistent state. The various users - decision-makers, decision assistants, facts updaters, model experts, internal and external consultants, etc. - can access the DSS using client applications with high-quality, customizable user interfaces. The top managers of the Federal Office for Agriculture are very proud of this system: its development was very long and expensive, but they are convinced that the resulting product was worth it. Thankfully, the country did not experience any major food supply crisis since the system has been installed, but the managers successfully tested it during various simulations. On a sunny Friday, a veterinarian discovers several animals suffering foot-andmouth disease in a large farm. After a few hours of investigation, it appears that the disease is already spreading out to other farms in the country. The day after, on Saturday, one of the top decision-makers of the Federal Office for Agriculture decides to organize an emergency meeting and convenes with several decision assistants, facts updaters, model experts and domain experts. Some experts accidentally meet on the train or on the plane and think that it would be productive to be able to use the DSS from there. The first participants arrive a few hours later and gather in a meeting room. The decision-maker is in a hurry and decides to begin the meeting right away, instead of waiting for participants coming from distant parts of the country. All the participants have a powerful, state-of-the-art laptop with a fast CPU, a lot of memory, and two network cards (hardwired and wireless). However, when they try to connect to the Internet to access the DSS, they realize that the room does not provide enough network plugs. One of the decision assistants proposes to use the wireless cards to create a wireless LAN, and to use only one of the hardwired plug to set-up a gateway between this wireless LAN and the Internet. The other participants rate the idea as excellent. However, nobody really knows how to set-up the necessary gateway. The decision-maker is growing impatient and asks his secretary to call one of the system engineers. In the meantime, the participants succeed in the easiest part of the process: setting-up the wireless LAN. Ten minutes later, the secretary comes back, saying that all the system engineers are busy upgrading the server software and performing maintenance tasks on the network. The decision-maker is thrown into a panic: how is it possible that these
maintenance tasks are happening today? The secretary calmly answers that it is Saturday, that this maintenance phase has been planned weeks ago, and that the servers and the network will be down until Monday. The decision-maker is devastated: the Office spent millions to design this decision support system and it becomes completely useless, just because server upgrades and network maintenance were planned the day it was really needed. Moreover, all the experts are equipped with state-of-the-art laptops containing all the necessary information (model experts came with their models, facts updaters came with up-to-date data, domain experts came with different exogenous decisions, etc.), all these laptops can be connected on a wireless LAN, but it remains impossible to use the decision support system, because of one single failure point : the centralized server...
2. Distributed DSS and data communication Many authors define the architecture of a DSS in terms of various components (Sprague, 1980; Bonczek, Holsapple, and Whinston, 1981). Turban (1995) mentions that the various components of a traditional DSS and/or its users do not have to be in one location. They can be dispersed both geographically and organizationally throughout an organization and its environment. Figure 1 expresses his view of a distributed computer system.
Figure 1. Distributed Computer Architecture according to Turban (1995)
This distributed architecture possesses five main characteristics: 1.
Computers are dispersed throughout a single organization or several organizations; 2. Computers are connected by a data communication system; 3. A common database is shared by all, but additional databases may exist; 4. All computers are centrally co-ordinated with an information resource management plan; 5. Input and output operations are done within user departments. Turban's distributed architecture is typical of a centralized network topology (Figure 2A). The primary advantage of centralized systems is their simplicity, which is an important factor for DSS development (short development time and better manageability). However, the main drawback of centralization is that everything is in only one place. As a consequence, there is no fault-tolerance, no location independence, and poor extensibility. Amongst others, two network topologies can improve this situation: (1) a decentralized topology (Figure 2C), and (2) a hybrid topology (Figure 2B) combining centralized and ring topologies (Minar, 2002).
Figure 2. Three common network topologies
Decentralized systems have almost the exact opposite characteristics as centralized systems: they are fault-tolerant, location independent, and extensible. However, they tend to be difficult to manage and, consequently, more difficult to implement. On the other hand, a hybrid topology combining centralized and ring topologies is easier to manage and to implement (many tools and techniques for replication, recovery, and load balancing use this hybrid topology and are well established in theory as well as in practice). However, the resulting system will remain a kind of compromise, and will not be as fault-tolerant, as location independent, and as extensible as a truly decentralized architecture.
Our vision of distributed decision support systems confronts the existing knowledge in the area of distributed DSSs with new, emerging distributed technologies allowing the design of distributed, decentralized DSSs easier to manage and to implement.
3. A new, decentralized vision
3.1. Decision support systems and technology Silver (1991) notices that the DSS community has always shown great interest in the underlying technology. Builders of early systems - for example, Scott Morton (1971) - had to overcome significant technological obstacles to create their DSSs. Much of the initial effort focused on hardware and software for the user interface. Not by chance, the advent of interactive computing coincided with that of DSSs, and the birth of personal computing was contemporaneous with DSSs' rapid growth. The same kind of situation is happening today with distributed DSSs: implementers of such systems have to overcome significant technological obstacles to create their distributed DSSs. Much of the current effort focuses on network management. And, hopefully, the advent of new service-based or device-based distributed technologies (such as Sun Microsystem's Jini, Microsoft's Universal Plug and Play, Hewlett-Packard's Chai, or even Bluetooth1) will coincide with that of new distributed DSSs.
3.2. Assumptions Our reflection relies on six assumptions shaping our vision for distributed, decentralized decision support systems. A tentative definition of distributed DSSs is given at the end. 3.2.1. A distributed DSS is not necessarily data intensive Alter (1977) defined seven categories of DSSs but noted that "the taxonomy can be collapsed into a simple dichotomy between data-oriented and model-oriented systems." Data-oriented (or data intensive) DSSs emphasize access to and manipulation of large databases of structured data, and especially a time-series of internal company data and, sometimes, external data (Power, 2000). This category of DSSs is very popular because of the momentum gained by Executive Information 1 The official web sites of these technologies offer the most up-to-date information. The URLs are http://www.jini.org/ (Jini), http://www.UPnP.org/ (Universal Plug and Play), http://www.hp.com/products1/embedded/ (Chai), and http://www.bluetooth.com/ (Bluetooth).
Systems (EIS) and data warehousing, which are two examples of data-driven DSSs. Such systems need centralized, large database management systems and powerful processors to manipulate the very large databases used. The traditional architecture of Figure 1 does make sense for such data-driven DSSs. However, many mission-critical decision-making situations are not necessarily data intensive. For example, military, governmental and medical contexts can be characterized by highly decentralized, up-to-date small data sets coming from different sources. The example scenario is inspired by a real DSS whose centralized database (with complete agricultural data) is not bigger than a few tenths of megabytes. These small data sources can easily be managed by small DBMS on personal computers or even powerful laptops. The challenge, then, is to connect these data sources together when needed. 3.2.2. In a distributed DSS, two data units which are not semantically related can always be physically stored in different storage devices The possibility to centralize data in large, powerful databases is often viewed as a convenient solution to improve data consistency, control, and productivity. For example, a clothing retailer with over 300 stores in the United States can really benefit from the centralization of the data of all its stores. The top managers can then perform sophisticated analyses within a reasonable time frame on a data set of several hundreds of gigabytes to extract information about trends, performance, and inventory stocks, for example. This kind of centralization makes sense because all the data of the centralized database are semantically related2 (as the 300 stores of this clothing retailer sell articles from the same catalogue). However, centralization may be unnecessary in other situations, especially with systems which are not data intensive (assumption 1). In our example scenario, the designers of the DSS centralized all the data and the models "in a powerful, efficient central server"; moreover, the mathematical solvers are "running on a centralized cluster of fast CPUs", as according to the hybrid topology (ring + centralized) introduced in section 2. In this context, data and models are not semantically related, and even some subsets of the overall database are not semantically related (for example, data about plant production is not semantically related to data about animal production). Is it legitimate, in such a situation, to physically centralize semantically unrelated data units just because they are stored in a faster, more efficient, and more powerful hardware device? Not always. In the example scenario, it appears that all sets of semantically related data units are managed by a specific role (facts updaters are responsible for well-defined subsets of the data, model managers are responsible for the models, experts are responsible for exogenous decisions, etc.) It also appears that many persons representing these roles had up-to-date data on their laptops. All these "state-of-the-art" devices were easily 2 In this paper, two data units are semantically related is they belong to the same expertise domain. In this example, all the data of this clothing retailer belong to cloths sales.
connected together on a wireless LAN. However, as the designers of the system chose to physically centralize data (for easier management), they introduced single points of failure in the system. Had the system been designed to allow the laptops to communicate together, the system would have been slower, maybe, but it would have worked. 3.2.3. A distributed DSS is based on the global, distributed architecture of the Internet The Internet, as we know it today, is one of the best representations of the technical advances that happened in distributed computing in the last ten years. This world-wide system of computer networks offering a public, co-operative, and selfsustaining facility accessible to hundreds of millions of people makes the development of specific data communication systems much easier. The pervasive IP protocol hides many low-level details and allows developers to concentrate on the high-level requirements of their information systems. According to Power (2002), "the public Internet is creating communication links for many types of interorganizational systems, including DSS." The important point to note here is that the architecture of the Internet goes far beyond a simple centralized architecture. The Internet is truly a dynamic environment with resources growing and shrinking, going on- and offline, moving from one location to another one, assembling and disassembling knowledge communities in a globally unpredictable way. The advantages of a distributed DSS running on a global, distributed architecture are twofold: on the one hand, it enhances communication and information exchange from various expertise domains. This increased knowledge reusability is essential in a DSS. A decision problem is rarely completely new and can often reuse parts of the knowledge used to solve past problems. On the other hand, a DSS is only useful if it is able to quickly generate quality alternatives. The flexibility offered by a global, distributed architecture allows precisely a DSS to retrieve and combine data, models and other types of knowledge under tight time constraints, amongst the currently available knowledge sources, to generate the required decision alternatives. Rather than relying on simplified architectures, a distributed DSS should adopt this dynamic and global structure with its own resources. The idea here is not to use a centralized or hybrid topology on top of the Internet, but to design a truly decentralized topology, which mimics the decentralized topology of the Internet. Device-based distributed technology (like Microsoft's Universal Plug and Play, or HP's Chai) or service-based distributed technologies (like Sun Microsystems' Jini) enable the implementation of such architectures. The situation of the example scenario presented above would be much different if the resources of the DSS could be moved from a device to another in a transparent way, if the system could find several routes to different processors, if the system could stay up and running even if
some resources are momentarily unavailable, etc. Of course, this assumption is only applicable if the data used by the system are also decentralized (assumption 2). 3.2.4. A distributed DSS can survive on an unreliable network As explained above, traditional distributed DSSs do not use simplified architectures because DSS implementers think that these architectures are conceptually better than decentralized architectures (assumption 3), but because they are easier to implement and to manage. Until recently, it was very difficult for a decentralized system to deal with fault-tolerance, unpredictability, and unreliability. However, recent advances in distributed computing provide new technologies, like Sun Microsystem's Jini, which encapsulate many low-level details and offer a global and reliable distributed framework on top of an unreliable network. The advantages of a distributed DSS, able to survive on an unreliable network, are evident for timecritical, heterogeneous, and highly decentralized decision contexts. Military contexts are good examples of such situations: even if the communication network does not work 100% because of some unknown glitch in the system, it remains essential that the DSS continues to provide as much information as possible. The designers of the DSS used in the scenario example chose a centralized architecture because they thought that it would be more robust and easier to manage than a decentralized, and possibly unreliable architecture. However, the drawback of this approach is that it introduces single points of failure in the system. 3.2.5. A distributed DSS enhances mobility The notion of distributed computing associated with the notion of mobility leads to the notion of field computing, which is an essential part of the anytime/anywhere usage configuration (Gachet, 2001). Indeed, personal digital assistants (PDA) and hand-held computers that easily fit in a suit-jacket pocket are now powerful enough to enhance the idea of distributed and mobile computing. Tomorrow's decisionmakers and decision assistants will carry their knowledge with them, in hand-held computers or in many other kinds of devices. The emergence of mobile computing, and mobile technologies such as Bluetooth, change the basic (and often inflexible) communication structures between hardware devices. Mobile systems can only succeed if devices are able to communicate in a dynamic and flexible way. The decision assistants of the example scenario, musing about the possibility to use the DSS on the train or on the plane, illustrate this situation. "Using the system" means nothing more than connecting the devices of the people present to exchange information. Indeed, what is the advantage of a mobile system if each component has to connect to a centralized and potentially unreachable server, because the underlying network is unreliable (assumption 4)? Does that make sense, if the mobile devices are themselves able to store the data concerning their respective owners in a decentralized way (assumption 2)? Probably not. In this context,
mobility is not a feature of a distributed DSS; it is a basic requirement to fulfil the promise of the other assumptions presented in the preceding sections. 3.2.6. A distributed DSS does not replace face-to-face meetings; it promotes and enhances them This assumption tries to establish a distinction between distributed DSSs and global virtual teams (GVT) or collaborative virtual environments. GVT members rarely meet face-to-face, which rises challenges involving people and technology. Dubé and Paré (2001) mention that while technology is fundamental to GVTs, leaders should remember that face-to-face meetings are an alternative. In that sense, a distributed system should never discourage users to meet in person. According to Hackathorn and Keen (1981), decisions may be individual, group, or organizational tasks. When it comes to group or organizational tasks, a distributed DSS should be considered as a convenient alternative when its users and/or components cannot be at the same place at the same time, not as a replacement. The example scenario is a good illustration of this phenomenon: like many decision-makers, the decisionmaker of the scenario prefers a face-to-face meeting with his staff when things have come to a crisis. However, everybody needs the support of the DSS to make decisions and, consequently, wants to use the system as a convenience tool. Had the system been up and running, it would have provided strong material for discussion and rational decision-making, as well as communication aids. However, this assumption is only conceivable if the distributed DSS runs in a mobile environment (assumption 5). Decision-makers and decision assistants are already equipped with powerful hand-held devices capable of storing data, at least for systems that are not data intensive (assumption 1). As soon as these devices are able to connect together to build a heterogeneous network when their owners meet, they will improve (and promote) the quality of face-to-face meetings.
4. Definition Based on the six assumptions presented above, the following tentative definition can be given for a distributed decision support system: A distributed decision support system is a collection of devices or services that are organized in a dynamic, unreliable and unpredictable network of hardware and software entities working co-operatively for a common decision support purpose. Figure 3 illustrates a possible distributed DSS corresponding to this definition. This figure is only an example. The wireless and hardwired connections between the components could be represented in many different ways. The aim of this figure is to show that a component can virtually be connected with any other component (laptop with PC, laptop with database, PC with PDA, PC with database, PC with printer, etc.) Figure 3 could describe the network topology of the DSS used in the
example scenario. All the participants attend with their laptops and/or hand-held computers connected together using a wireless LAN. The participants stored on their devices up-to-date information that can be shared between the participants. So, if the owners of laptop 1, laptop 2 and PDA meet on the plane, for example, they can form an impromptu community and begin to use the system with the available data and the available computing power of the laptops (using a decentralized topology). In the conference room, they meet other participants, whose devices will join their community, in a dynamic and self-managed way, thanks to technologies like Sun Microsystems' Jini.
Figure 3. A possible configuration of a distributed DSS
5. Conclusion This paper showed that, on the one hand, many decision-making situations are not necessarily data and computing intensive and, consequently, do not necessarily need centralized super-processors and large database management systems. On the other hand, these same decision-making situations happen in dynamic, rapidly changing, and often unpredictable distributed environments. Thus, the need to connect different hardware and software components in a flexible and transparent way inspired the following six assumptions about distributed decision support systems, leading to a tentative definition of such systems: 1. 2.
A distributed DSS is not necessarily data intensive In a distributed DSS, two data units which are not semantically related can always be physically stored in different storage devices
3.
A distributed DSS takes advantage of the global, distributed architecture of the Internet 4. A distributed DSS can survive on an unreliable network 5. A distributed DSS enhances mobility 6. A distributed DSS does not replace face-to-face meetings; it promotes and enhances them Recent advances in distributed computing and mobile technology should make possible the implementation and easier management of distributed DSSs conforming to these six assumptions in a near future. As an example, the DS lab at the University of Fribourg, Switzerland, is working on a software framework for developing distributed co-operative DSSs, using the Jini technology. As mentioned by Sprague and Carlson (1982), it is widely known that DSSs must be flexible to respond to the dynamic nature of decision-making environments. If supporting a changing environment is a design objective, then building a non-restrictive DSS may be what is needed. "Work anywhere, anytime is the new paradigm. The need for speed makes it imperative for employees to team up and share information." (Hamilton et al., 1996)
References ALTER, S. L. A Taxonomy of Decision Support Systems, Sloan Management Review, 19(1) (Fall), 1977, p. 39-56. BONCZEK, R.H., HOLSAPPLE, C.W., WHINSTON, A.B. Foundations of Decision Support Systems, Academic Press, New York, 1981. DUBÉ, L., PARÉ, G. Global Virtual Teams, Communications of the ACM, 44(12) (Dec.), 2001, p. 71-73. GACHET, A. A Framework for Developing Distributed Cooperative Decision Support Systems – Inception Phase, 2001 Informing Science Conference, Kraków, Poland, 2001. (http://ecommerce.lebow.drexel.edu/eli/pdf/GachetEBKAFrame.pdf) HACKATHORN, R.D., KEEN, P. G. W. Organizational strategies for personal computing in Decision Support Systems, MIS Quarterly, 5(3) (Sept.), 1981, p. 233-242. HAMILTON, J., BAKER S., VLASIC B. The New Workplace, Business Week, 29 April, 1996. MINAR, N. Distributed System Topologies. World Wide Web, http://www.openp2p.com/pub/a/p2p/2001/12/14/topologies_one.html, January 2002. POWER, D. J. Supporting Decision-Makers: An Expanded Framework. World Wide Web, http://dssresources.com/papers/supportingdm/sld001.htm, version 1.0, December 15, 2000. SCOTT M ORTON, M.S. Management Decision Systems, Division of Research, Graduate School of Business Administration, Harvard University, Boston, Massachusetts, 1971.
SILVER, M.S. Systems that Support Decision Makers – Description and Analysis, John Wiley & Sons Ltd, Chichester, England, 1991. SPRAGUE, R. H. A framework for the development of Decision Support Systems, MIS Quarterly, 4(4)(Dec.), 1980, p. 1-26. SPRAGUE, R. H., CARLSON, E. D. Building Effective Decision Support Systems, Prentice-Hall, Englewood Cliffs, New Jersey, 1982. TURBAN, E. Decision Support and Expert Systems: Management Support Systems, Englewood Cliffs, Prentice Hall, 1995.
