07 Jan What’s in a Decision

A decision by any other name would feel as risky

Take any class of software and you can find some structures or processes that you can associate back to some human-like structure or processes. To keep this more simple and relevant, I am focused on looking at systems that are fundamentally designed to replicate more complex cognitive tasks. Decision Support Systems (DSS) fit into this category. DSS structure is of particular interest here since it requires some scheme of encoding the information necessary to help people make informed decisions. This encoding scheme can be alternately described as a KR scheme. The model base component in DSS supports a form of reasoning or logic that has similarities with rule-based and case-based KR schemes. A more mathematical approach to similar classes of problems is available in reactive systems (Aceto 2007).

Understanding Context Cross-Reference
Click on these Links to other posts and glossary/bibliography references

Section 8 #17

Table of Context

In addition to serving as models for knowledge representation, DSS look and act like expert systems in several ways. The importance of maintaining a dialog with users is a significant similarity. In this section, we shall look at some of these similarities, see how they coincide with our understanding of human reasoning and deciding patterns, and decide if we should add them to our tool chest. DSS can be designed to perform these tasks:

• Support decision making in complex, poorly structured or unstructured domains.
• Support decision making from more than one perspective (boss/worker).
• Support decisions that are stand-alone or interdependent (committee).
• Support the intelligence gathering, design, and choice phases.
• Support a variety of decision-making processes.                           (Sprague, 1986)

DSS Components

DSS have the three major components pictured below. permanent storage is usually an RDBMS (relational database management system) a graph database or a big data repository. We use terms like Relational and Graph to describe certain kinds of DBMSs. Database management systems, which are compared in Section 9, are common to many kinds of applications other than DSS. Model bases are also found in other, mostly AI-oriented applications. Dialog Generation Management Systems (DGMS) are unique to DSS software. These systems may include the following components:

 

• Explanation Utility: Forwards user input, then outlines model processes and rules used to  generate a solution and guidance
• Hypothesis Engine: elaborates sample hypotheses into problem specific possibilities tailored to the question
• Analysis Engine: Decomposes the problem into discrete elements for downstream model exploration
• Model Exploration Engine: Matches problem elements with model elements, non-model elements and missing elements
• Noise Filter and Detectors: Determines if non-model elements are noise or necessary
• Solution Engine: Applies input constraints to each hypothesis and compares with the models to prioritize solutions
• Validation Utilities: Performs feasibility and suitability checks on generated solutions based on feasibility rules
• Guidance Generator: Uses solution implementation constraints to provide users actionable guidance

The DGMS may contain more or less than this, and it can reside on the cloud, a server on premise, or a workstation or device (if it is compact enough). Model base management systems will be described in a later post.

DSS Model

One of the most useful constructs we derive from Decision Support System work is the need for dialog generation and management software (DGMS). This illustration shows a DSS model using a DGMS component: The value of a dialog management system is to facilitate interaction between the user and the DSS. Feedback becomes critically important when you have naive or untrained users, complex data, and/or complex models. While these systems have different components, the core processes and process flows may be remarkably similar.

This table compares the structures of typical tiered applications, DSS and DGMS:

DSS Example

An actual system built for a large catalog printing company, described briefly in section 7, is a good example of a DSS with complex dialog management: Objective The objective is to find the most cost effective way to get millions of catalogs for dozens of vendors to millions of potential customers within prescribed delivery-date windows. Opportunity The opportunity is to combine shipments of the catalogs from different vendors to get postal discounts and maximize shipping efficiency to minimize freight costs.

Challenge

The challenge is to keep absolutely within the postal discount schedule of discounts based on the weight and destination of each catalog, to keep strictly within the published shipping rates, to keep carefully within the time windows that vendors have described as flexible, and to keep absolutely within the time windows that vendors describe as inflexible. I’ll describe the approach to this challenge, showing how the dialog makes it possible to leverage the strengths of the computer and the expert. The DSS Approach The dialog between the system and the expert begins with a set of model-adjustment screens. These allow users to describe the unique characteristics of the current batch of catalogs as well as adjustments that need to be made to the seasonal model for mail facility efficiency and shipping schedules.

The system then analyzes the constraints and delivers a proposed approach for achieving efficiencies that translate into cost savings for the current week of mailing. The next part of the dialog uses visual symbols (two-dimensional drawings) of trucks going to each of the destinations, with special color codes to indicate if the truck needs to be expedited or if the truck cannot arrive on time for the prescribed time window. To participate in the dialog, the user uses a mouse pointer to click on a truck. Clicking on the truck shows the user all the characteristics of that truck. Armed with this information, the user can selectively alter the characteristics of the truck, all trucks to that destination, or one or more collections of catalogs proposed for shipment on that truck. Because of the visual nature of the system and the multiple points of dialog between the system and the users, the business achieves high levels of efficiency that translate directly into cash savings. The system pays for itself several times each year.

Service-Oriented Architecture as Black Boxes

Correlation between DSS and multi-tiered systems architecture is worth considering in this context. Decision support systems can be diagrammed as collections of “black boxes” in tiers, each with its own operations.

These independent components can receive input, process it, then deliver results. In the model of the human brain described in Section 1, we saw how the brain can be characterized in a similar way, though the connections between the separate components are more complex and numerous. For the sake of this argument, let us consider the ubiquity of connections between the different areas of the brain as providing bandwidth – in other words, faster and more complete input and output rather than something fundamentally different than the communication between black boxes in a Client/Server (C/S) or DSS application. If we can make this leap with integrity, the correlation between thought and computation becomes much easier to envision.

In the brain, we have areas that process images and sound as they come in (the UI), we have correlating areas that process associations (middle tier), and we have the knowledge base in the frontal lobe and elsewhere (back end).

For decision support systems, models, rules and knowledge are what’s in a decision. Keeping them each in independent, separately managed components, makes such systems more adaptable and more robust. I’ll go a bit deeper in my next few posts.

Click below to look in each Understanding Context section

Leave This Blank:Leave This Blank Too:Do Not Change This:

Your email: