Final Report Decision Components And Patterns
- 1 Decision Components and Patterns
- 1.1 Introduction
- 1.2 The Core Components and the "Event" Pattern
- 1.3 The Question and the "Statement with Variable" Pattern
- 1.4 The Options and the "Filter" and "Aggregation" Patterns
- 1.5 The Metrics and the "Normalizer", "Weighting" and "Aggregation" Patterns
- 1.6 The Assessment and the "Ordering" Pattern
- 1.7 The Choice and the "Selection" Pattern
- 1.8 Summary
Decision Components and Patterns
Before moving to the actual modelling of different formats, we need to consider the theoretical implications of what a decision actually is (cf. the theoretical background given in the state-of-the-art section above). For instance, what are the primary components of a decision? For our purposes, we are interested in a decision format capable of representing a generic decision, independent of any particular domain, and we'd like the format to be relatively concise and understandable to a wide audience. Yet, we'd also like to represent enough information to allow a person who was not involved to appreciate more than just the final result. Moreover, what was the question being asked? What options were considered? On what basis were the options evaluated? (For a preliminary example in XML of the types of decision components described below, see the Common Decision Exchange Protocol (CDEP) version 4 and the examples located at CDEP Examples.)
How do we think about these aspects, and subsequently model these components? One solution is to look for patterns. Is the component something that is entirely unique to decision-making or is it similar to components used in other designs. Perhaps there is a design solution already addressing this pattern. If not, at least the identification of the pattern suggests other examples to aid with the design and allows us to develop a modeling solution which has the potential to be reused.
So let's consider the bare bones components of a decision and the implied patterns that exist in those components to drive our design.
The Core Components and the "Event" Pattern
The core components, i.e. the bare minimum, of a decision are those which you must know to gain any usefulness. If I say that "A decision has been made.", what would you need to know for this information to be of any use to you? Certainly, you'd like to know what was decided, which consists of two parts, first what question was being asked and second what was the answer. You'd also probably like to know who made the decision and when. So the core components are (a) the question, (b) the answer, (c) the decider, and (d) the date/time of the decision.
Is there any underlying pattern to these core components? These components are basically the who, what, and when components that are used in many domains. For example, in news syndication, they show up in rss feeds as the author, title/description, and date tags. The Dublin Core represents these basic components. These components are used in many situational awareness standards, such as Cursor on Target and UCore.
These core components could be considered part of an Event pattern, where an Event is anything that happens or could happen involving, for purposes of decision-making, a person or other entity capable of making a decision. An Event pattern would include the representation of the who, what, where, when components. GeoRSS might be a good example of this.
So in our decision format, we should expect to design a component that includes such an abstract conceptual pattern of an Event.
The Question and the "Statement with Variable" Pattern
Before a decision is made, there is an underlying question that is being asked. The decision process is designed to answer the question. A question can be phrased as a statement with a variable where the variable represents an unknown item. The decision process results in the variable being assigned to one or more known items. This pattern occurs regularly in all sorts of situations where one is inquiring, such as in search queries.
The Question could be considered a case of an abstract conceptual pattern we can call Statement with Variable.
The Options and the "Filter" and "Aggregation" Patterns
For the question to appear as a decision question, the context must be one where the decision-maker has some control over the answer and there are reasonable options. If the decision-maker has no control then it's not really a decision. Similarly, if there are no reasonable options or only one reasonable option, then there is effectively no decision. So a decision normally implies multiple options. An option is simply one item among a category of items, any of which could be assigned as the answer to the question.
From this perspective, an option is something that satisfies the minimum criteria for being a reasonable answer to the question. This is a familiar pattern which occurs whenever we filter things. For example, when we search on the web, we put in keywords or other filtering criteria which we hope will provide a set of reasonable answers to our query. This could be called a Filter pattern. Also the options may need to be aggregated in some manner, for example in the form of a list. So we should expect to see a Filter pattern and potentially an Aggregation pattern to enable the representation of options.
The Metrics and the "Normalizer", "Weighting" and "Aggregation" Patterns
Another aspect of decision-making is that there should be some rational basis for the decision, some rationale. If the decision is random or entirely arbitrary, then we normally think that the decision-maker has abdicated their responsibility. For the decision to be rational, there needs to be some reasonable measures. The measures should be identified, measurable and comparable in some fashion. For example, cost can be measured in dollars and many things have a defined cost. For those things which don't have a defined cost, a cost must be defined, if one wishes to use cost to measure all the options. Some measures are objective and some subjective, but for a measure to serve as a rational discriminator among options (re)usable by automated processes the measure must have some scale and some repeatable process for determining the value and a way to state that value.
Metrics occur in any domain where one must discriminate among items based on a common set of criteria. Metrics are an important component of the Filter pattern mentioned above under Options. To filter or discriminate, one must have options and metrics which can be used to compare the options. Items must be compared consistently within a given metric, but also the metrics must be compared with each other. For example, if cost and quality are the metrics, then how do we compare these different metrics to come up with an overall evaluation. What scale do we use that allows this cross-comparison? Cost may be represented in dollars but quality may be represented a low/medium/high. For us to compare the two, we may need to consider cost as low/medium/high or else come up with a dollar representation of quality. This effort to develop a common scale can be considered a Normalize pattern which occurs whenever two or more items must be compared across different aspects with different scale.
Note that metrics are related to the options because they are derived from perceived characteristics of the options. For example, if the options are purchasable items, then the items have a cost and a perceived quality. Often the qualities are generic and apply to almost anything, but sometimes the metrics are specific to a given domain. Either way, the options are considered to have these characteristics, otherwise these metrics wouldn't be useful for discrimination.
Another aspect of metrics is that they may not all be given the same weight by the decision maker. For example, the decision-maker may consider cost more important than quality, or vice versa. This is a "Weighting" pattern which involves a common scale to adjust the relative importance of different criteria.
Also the Aggregation pattern recurs here where multiple metrics may need to be combined into one set or list.
In short, Metrics imply the abstract conceptual patterns for Normalizing, Weighting, and Aggregation and the Metrics participate in the larger Filter pattern.
The Assessment and the "Ordering" Pattern
The assessment is where the metrics are used to discriminate the options based on the perceived qualities of those options. Although the assessment is more of an action than an information format, the results of the assessment are important for the information format. In the simplest sense, the representation of the assessment might simply be an ordering of the list of options. So this presents an "Ordering" pattern, which occurs whenever there is a way to derive an overall comparison of items to say one is greater than another based on some scale.
The Choice and the "Selection" Pattern
Finally, after the metrics are applied to the options generating an ordered assessment, the decision-maker must make a choice. The decision-maker may feel that the metrics are sufficiently objective, comprehensive and well-defined to allow the decision-maker to simply approve the top choice as the answer. Or the decision-maker may feel that the metrics were sufficient to aid in the decision process, but not sufficient to overcome the need for the decision-maker to consider other factors or otherwise do a reassessment and so choose an option further down the list. Either way, the selection of the decision-maker must be noted in the information format.
This is the abstract conceptual "Selection" pattern and occurs wherever one or more items must be selected among many.
The above has been an initial look at key components of decisions and which generic conceptual patterns they imply in terms of information representation. The mapping of the components to their implied patterns is an important step for helping to proceed with the modeling of these components as reusable patterns following the eXtreme Design approach.
Ref: Initial Thoughts on Decision Components were here. Ref: Some earlier revised thoughts on this page are at Decision Components Revision 02