Gachet, A. and P. Haettenschwiler (2003) "Developing Intelligent Decision Support Systems: A Bipartite Approach", in Palade V., Howlett R.J.

, Lakhmi J. (eds) Knowledge-Based Intelligent Information and Engineering Systems, proceedings of the 7th KES Conference, Springer-Verlag (LNAI 2774), Berlin Heidelberg, Germany: pp. 87-93

Developing Intelligent Decision Support Systems: A Bipartite Approach

Alexandre Gachet, Pius Haettenschwiler
Department of Informatics University of Fribourg Faucigny 2 1700 Fribourg Switzerland {alexandre.gachet|pius.haettenschwiler}@unifr.ch

Abstract. The construction of an intelligent decision support system borrows concepts from two fields: software engineering and knowledge engineering. Yet the development processes of the purely technical components of the system and of the knowledge base of the DSS are very different in terms of development time, paradigms, tools, technical evolutions and the expertise required by the developer. In this paper, we propose an innovative approach taking these fundamental differences into consideration. The novelty of this bipartite approach lies in the clear and generic separation between the container of the DSS (responsible for the software engineering part) and the contents of the DSS (responsible for the knowledge engineering part).

1. Introduction
The DSS community recognizes that traditional software development life cycles, such as the (modified) waterfall model, the spiral model, evolutionary prototyping, or other models borrowed from software engineering [1], do not adequately encompass all the specifics of a DSS development process. Therefore, different authors propose customized models for developing DSS [for example, 2, 3-8]. Interestingly enough, none of these approaches predominate and the various DSS development processes usually remain very distinct and project-specific 1. We believe that this absence of consensus is due to the fact that each author tends to propose development solutions strongly inspired by his or her own background and experiences. Researchers coming from the mathematics and/or OR side of the DS field focus on high-level modeling tasks and underestimate purely technical software development issues, while researchers coming from the computer science side focus on system development concepts and underestimate the higher level decision making approaches. For example, previous studies in the DS field focused on the comparison between the SDLC and prototyping development models [9, 10], but failed to address
1

A complete study of the limitations of these DSS development processes is beyond the scope of this article and would have to be the subject of a different paper.

the structural design issues of a DSS as a whole. Indeed, a DSS is intrinsically about decision support and about a system, and these two main components should be treated equally during the development process.

Knowledge Engine delegate/propagate read/write

Container (with GUI)

Contents

DSS Software Framework

DSS Generator

Data

Model

DSS Tools

DBMS

MBMS

software development

management composition

Fig. 1. A clear separation between the container and the contents of a DSS

In this paper, we propose an innovative approach to reconcile the two sides of the field. The cornerstone of our approach is the clear separation between what we call the container of the DSS and the contents of the DSS. Figure 1 proposes an integrated view of our proposition. This bipartite approach decouples the development processes of (a) the purely technical components of the DSS and (b) the knowledge base of the DSS. Moreover, it improves the independent reuse of the container and the contents. As the underlying technologies (for example, programming languages on the container side and modeling systems on the contents side) evolve in very different ways, this clear separation can greatly increase productivity when developing specific DSS. This approach is especially targeted at intelligent DSS, which we describe as DSS allowing the decision maker to modify, complete, or refine decision suggestions provided by the system, before sending them back to the system for validation. The system again improves, completes, and refines the suggestions of the decision maker and sends them back to her for validation. The whole process then starts again, until a consolidated solution is generated [11].

2. The Container
The container is responsible for the system part of the DSS. Its development follows the traditional life cycles described in software engineering. A typical development cycle for a container lasts a few months, up to a couple of years. Due to the dynamic and rapidly changing nature of programming languages and software engineering paradigms, containers are naturally subject to continuous, short-lived, and deep changes in the underlying technology. Two system attributes of DSS are precustomization and customizability [12]. Precustomization is defined formally as "the degree to which, and the manner in which, at the time it is delivered to the user, some or all of the features of a DSS have already been tailored to the specific decision making environment it is intended to support." Customizability is defined formally as "the degree to which, and the manner in which, a DSS empowers its users to specialize it as needed to fit the environment it supports." On the one hand, highly precustomized systems are attractive because they are already tailored to specific decision situations and decision makers, which is a central objective to many views of DSS [2]. On the other hand, highly customizable systems are attractive because they can achieve customization while requiring less effort by the developer than would constructing a precustomized system. Customization is also necessary to continuously adapt the system to new use cases and evolving requirements. Given the very broad nature of DSS today, it is impossible to design a perfect DSS that would be both highly precustomized and highly customizable. However, as these two system attributes are well understood in software engineering, it remains possible to apply them to the container of the DSS. To reach that goal, the basic functionalities of a containerincluding those of the user interfaceshould not depend on any specific contents. Instead, the container should act as a kind of generic, empty shell offering low-level foundations for the contents. Then, specific requirements (covering the system architecture or the user interface) can be added by taking advantage of the customizable nature of the container. Gachet [13] extends Sprague's classification of DSS development tools [4, 14] with a new component well adapted to design precustomized and customizable containers. This component is called a DSS software framework. For example, the DS laboratory at the University of Fribourg, Switzerland, is working on a Java- and Jini-based software framework for developing distributed cooperative DSS [15]. As shown in Figure 1, it still remains possible to design containers using traditional DSS generators or DSS tools. Separating the container from the contents raises many issues. To be successful, a container that should be reusable with different contents must definitely concentrate on generic decision support activities, such as specification of decision situations; definition of decision support tasks; generation of alternatives; analysis, documentation, and comparison of the alternatives; multi-criteria evaluation of the alternatives; support of the final choice using a preferences model, etc. The container should focus on these generic stages of a typical decision making process, rather than on specific details dealing with mathematical, relational, dimensional, document-, rule- or logic-based concepts.

3. The Contents
The contents are responsible for the knowledge base of the DSS and can be designed according to various paradigms (model-based, rule-based, document-based, databased, knowledge-based, etc.). Their development is evolutionary and follows the declarative methods of knowledge engineering. A typical evolution cycle for the contents can last a few years, up to a few decades. Well-defined contents should be extensible and reusable in different containers. Contents represent critical assets for an organization. Knowledge bases often formalize many years of experience and expertise in the various domains of an organization. They are in continuous evolution and build a sort of corporate memory. To maximize its usefulness, this knowledge should be highly reusable, that is to say "available in the right forms to the right entities at the right times for the right costs" [16]. Contents are considered as reusable if they can be coupled with different containers. Unlike containers, the technology underlying contents development is less subject to rapid changes. Thus, as container and contents do not evolve at the same pace, they should definitely be loosely coupled. Otherwise, changes in the container technology could imply unnecessary changes in contents, and vice versa. According to Marakas [8], "[by] knowledge, we mean the rules, heuristics, boundaries, constraints, previous outcomes, and any other "knowledge" that may have been programmed into the DSS by its designers or acquired by the DSS through repeated use". A domain-specific knowledge base is mostly based on data and models, which are traditionally managed by database management systems (DBMS) and model base management systems (MBMS). For example, the DS laboratory at the University of Fribourg has been developing DSS for crisis management in the food supply sector since 1991. Two Swiss Federal Offices use these DSS: the Swiss Federal Office for Agriculture and the Swiss Federal Office for National Economic Supply. The contents of these DSS are based on statistical and expert data coming from various sources. This data is imported, organized, cleaned, and stored in relational database management systems. The contents of these DSS also use optimization models of the Swiss food supply sector. The model base contains models for animal and plant production, models for supplies management, and models for import/export balancing.

4. The Interface Layer Between Contents and Container

At the highest level, the thin interface layer between the container and the contents is realized in the DSS component referred to as the knowledge engine. The knowledge engine is traditionally considered as the "brains" of the DSS. "The data and the models come together here to provide the user with a useful application that supports the decision context at hand." [8]. This classical view of the knowledge engine is represented in Figure 1 by the read/write relationship between the contents and the knowledge engine. In our innovative approach, we extend the role of this component by adding a delegate relationship between the container and the knowledge engine. This is necessary if we want to decouple the container from the contents. We said in

Section 2 that the container should act as a kind of empty shell offering low-level foundations for the contents. To reach that goal, the container cannot deal directly with the contents (that is, the data and the models), hence the delegation of the highlevel stages of a decision process (mentioned in Section 2) to the knowledge engine. Of course, the knowledge engine then needs to provide handles to allow the container to communicate with it. For example, the DS laboratory at the University of Fribourg is combining the Java- and Jini-based DSS software framework (mentioned in Section 2) with the contents of the DSS for crisis management in the food supply sector (mentioned in Section 3) via a knowledge engine called LPL2 [17]. This knowledge engine is able to retrieve the data and to compute model optimizations. Furthermo re, it provides a clean API allowing the Java-based container to interact with it. In that sense, the container is completely decoupled from the contents. At a lower-level, this interface layer between the container and the contents is realized in components called decision support objects [15, 18]. Decision support objects (DSO) can be informally described as reusable software envelopes placed by the container at the disposal of the contents. The natural object-oriented approach of DSO simplifies the task of the decision makers and increases their efficiency. The concept of DSO is a central one in this interface layer. As a well-defined object, a DSO fits perfectly in an object-oriented software paradigm on the container side. It can easily be exchanged in a distributed environment. As a decision support object, a DSO remains closely related to the specifics of a decision making process. On the contents side, it encapsulates a business logic centered on decision support. A container could offer a basic set of precustomized DSO for basic decision contexts (for example, DSO encapsulating dimensions, facts, hypotheses, tasks, exogenous decisions, etc.), yet should remain customizable in the sense that specific DSO could be added at a later time for a specific decision context. When loading contents, the knowledge engine simply fills the empty DSO provided by the container with the appropriate data and model components. The container then lets the user organize the DSO according to the decision context and delegates all the decisionmaking tasks (such as knowledge retrieval or alternative generation) to the knowledge engine. This concept is in line with modern approaches to DSS, which advocate a synergy between the decision support and knowledge management processes of the organization [19]. On the one hand, decision making processes driven by the container generate new knowledge (in the form of new DSO), whose business logic is eventually stored in the contents by the knowledge engine (the write relationship in Figure 1). On the other hand, knowledge management activities influence the creation of new decision models to be adopted, which are eventually loaded by the knowledge engine from the contents (the read relationship in Figure 1) and propagated to the container in a new DSO (the propagate relationship in Figure 1). In our approach, DSO representing tasks precisely allow the DSS users to (re)shape the decision space and, thus, the underlying decision process. First, decision assistants can clearly specify, manage, and organize their respective tasks in the container; then, model experts can prepare relevant models and procedures to fulfill the tasks in the contents. The task DSO represents a kind of interface for the management of tuning parameters used in the models. This interface provides two views: one for the decision assistant
2

http://www.virtual-optima.com/

(using the container) and one for the model expert (influencing the contents). The communication between users and DSS builders is formalized through these views and allows for future developments initiated by both sides [15]. In that sense, the knowledge engine is the cornerstone of a bi-directional and loosely coupled communication between the container and the contents of the DSS, ensuring that the data, the models and the container remain dynamic components.

5. Conclusion
Given that a DSS is intrinsically about decision support and about a system, its development process naturally borrows concepts from two fields: software engineering and knowledge engineering. This paper showed that the development processes of the purely technical components of the system and of the knowledge base of the DSS are very different in terms of development time, paradigms, tools, technical evolutions and the expertise required by the developer. Consequently, we proposed a bipartite approach, whose cornerstone is the clear separation between the container of the DSS (responsible for the system part) and the contents of the DSS (responsible for the knowledge base). We extended the role of the DSS component referred to as the knowledge engine to turn it into an interface layer between the container and the contents. This innovative approach still has a few limitations that should be dealt with in the future. First, it gives quite a bit of responsibility to the knowledge engine component, which has to be able to communicate with both the container and the contents of the DSS. To our knowledge, the LPL modeling system is the only knowledge engine offering these capabilities today. Then, this approach relies on the traditional view of the knowledge base of a DSS, based on data and models. However, newer DSS paradigms, such as document-driven DSS [20], do not necessarily use data and models, and it remains to be shown if our approach still holds for such paradigms.

References
1. 2. McConnell, S.: Rapid development : taming wild software schedules, Redmond, Wash.: Microsoft Press. xix, 647 p. (1996). Keen, P.G.W. and Scott Morton, M.S.: Decision support systems : an organizational perspective. Addison-Wesley series on decision support, Reading, Mass.: Addison-Wesley Pub. Co. xv, 264 (1978). Alter, S.L.: Decision support systems : current practice and continuing challenges. Addison-Wesley series on decision support., Reading, Mass.: Addison-Wesley Pub. xvi, 316 (1980). Sprague, R.H. and Carlson, E.D.: Building effective decision support systems, Englewood Cliffs, N.J.: Prentice-Hall. xx, 329 (1982). Blanning, R.W.: The functions of a decision support system. Information and Management. 2(September) (1979) 71-96.

3.

4. 5.

6. 7.

8. 9.

10.

11.

12.

13.

14. 15.

16. 17.

18. 19. 20.

Courbon, J.-C., Drageof, J., and Tomasi, J.: L'approche volutive. Informatique et Gestion. 103(Janvier-Fvrier) (1979). Turban, E.: Decision support and expert systems : management support systems. 4th ed, Englewood Cliffs, N.J.: Prentice Hall. xxv, 887, 36, 7 (1995). Marakas, G.M.: Decision support systems in the twenty-first century, Upper Saddle River, N.J.: Prentice Hall. xxi, 506 (1999). Alavi, M. and Napier, N.H.: An Experiment in Applying the Adaptive Design Approach to DSS Development. Information and Management. 7(1) (1984). Mahmood, M.A. and Medewitz, J.N.: Impact of Design Methods on Decision Support System Success: An Empirical Assessment. Information and Management. 9(3) (1985) 137-151. Haettenschwiler, P.: Neues anwenderfreundliches Konzept der Entscheidungsuntersttzung, in Gutes Entscheiden in Wirtschaft, Politik und Gesellschaft, vdf Hochschulverlag AG: Zurich (1999) 189-208. Silver, M.: Systems that support decision makers : description and analysis. John Wiley information systems series, Chichester ; New York: Wiley. xvii, 254 (1991). Gachet, A.: Software frameworks for developing decision support systems: a new component in the classification of DSS development tools . Journal of Decision Systems (2003) [in press]. Sprague, R.H.: A framework for the development of decision support systems . MIS Quarterly. 4(4) (1980) 1-26. Gachet, A. and Haettenschwiler, P.: A Jini-based software framework for developing distributed cooperative decision support systems . Software Practice and Experience. 33(3) (2003) 221-258. Holsapple, C.W.: Knowledge Management Support of Decision Making. Decision Support Systems. 31(1) (2001) 1-3. Huerlimann, T.: Mathematical Modeling and Optimization, An Essay for the Design of Computer-Based Modeling Tools. Applied Optimization. Vol. 31, Dordrecht: Kluwer Academic Publishers (1999). Haettenschwiler, P., Moresino, M., and Schroff, A.: Rapid prototyping of decision support system. in ICSC Symposium. Tenerife (1998). Carlsson, C. and Turban, E.: Decision Support System: Directions for the Nest Decade. Decision Support Systems. 33(2) (2002) 105-110. Power, D.J.: Decision support systems : concepts and resources for managers, Westport, Conn.: Quorum Books. xvi, 251 (2002).